OpenBSD 3.8: Hackers of the Lost RAIDby Federico Biancuzzi
It's release time again for OpenBSD! The upcoming 3.8 will include some wonderful features for network gurus (trunking, tracking wireless roaming users, interface groups, a new ipsec configuration tool, and failover of ipsec links), a great rework of
malloc() that will provide further security protections by default, and the first version of bioctl--a universal RAID management interface.
With so many goodies to taste, Federico Biancuzzi contacted a large group of developers and assembled this long, long interview.
OpenBSD 3.8 is the first release that supports network interface aggregation, using the virtual
trunk(4) interface. How does it work?
Reyk Floeter: With
trunk(4), you can combine one or more ports as into one virtual network interface. A port could be any physical Ethernet or wireless interface, and it's even possible to add other trunks as ports. The trunk driver will send outgoing traffic with a specific algorithm over the attached ports, which depends on the actual trunk protocol. The first release in OpenBSD 3.8 supports a simple round-robin protocol; outgoing packets are distributed over the ports in a circular way. Furthermore, incoming packets from any attached port are forwarded into the receive queue of the virtual trunk interface.
trunk(4) is supported by most of the actual intelligent network switches and some other operating systems, but everyone uses a different name; i.e., HP calls a trunk a Trunk and Cisco calls it Ether Channel, while Linux is using bonding as its name.
trunk(4) provides several possible benefits. The first one is a slightly improved performance, because the traffic could be distributed over several physical network interfaces. You could get more than 100Mbit/s with a fast Ethernet trunk, even more than 1G/s with a gigabit trunk. The most interesting feature of trunk is failover on layer 2. The trunk will continue to work if you remove the network cable of an attached port, as long as there're other running ports attached to the trunk. The interface link states are used to detect inactive ports and to skip them in the round-robin scheduling.
Example of a trunk using two
sk(4) gigabit adapters:
# ifconfig sk0 up # ifconfig sk1 up # ifconfig trunk0 create trunkport sk0 trunkport sk1 # ifconfig trunk0 192.168.1.200 netmask 255.255.255.0 up
What improvements and new features do you plan to develop with it?
Reyk Floeter: I already improved some minor things like interface flags and ifconfig behaviour. Now it's possible to add VLANs to the trunk with a full-size MTU, if all the attached ports are supporting oversized Ethernet frames (802.1q defines some extra bytes prepended to the Ethernet header for VLAN ID and priority). With the current trunk driver in OpenBSD 3.8, the MTU of a VLAN is limited to 1,496 bytes.
An interesting improvement of
trunk(4) in OpenBSD-current is a full support for multicast. With multicast support you'll be able to use things like IPv6, hostapd, or even
carp(4). Using the CARP- protocol over trunk is a very interesting feature to extend the failover capabilities of OpenBSD. For example, a redundant firewall setup using
carp + pfsync(4) will support layer 2 redundancy with trunk as well; that's a way to keep your system "always on."
Work for IEEE 802.3ad LACP is in progress because it's important for interoperability with some network gear. It will be an optional trunk protocol in addition to the default round-robin scheduler. While starting the implementation of LACP, I noticed that I don't like it very much because it's a typical overengineered IEEE approach ... but it will be there, and I think it will be the most simplified but fully functional implementation.
Marc Espie recently had an interesting idea for using trunk to realize roaming between wireless and wired networks. This sounds weird, but the idea is simple--many people are using their wireless notebooks to do common work like hacking, browsing, and any kind of communications. But sometimes it is necessary to make some bulk transfers, like large file downloads or even system updates. I'm currently extending
trunk(4) with an "active failover" mode, using multiple ports with a hierarchic priority; i.e., my ThinkPad's
em(4) Gigabit Ethernet interface will be used as the master port with the highest priority, and the
ath(4) wireless interface will be the failover interface in a virtual trunk. Whenever I unplug the Ethernet cable, the trunk will exclusively switch to the wireless interface and vice versa without resetting the running network connections. From the network side of view, this will be the same as a wireless station roaming between different APs in one collision domain.
How is your battle to get free access to specifications and redistributable firmware for WiFi chipsets going? Does this release include any new drivers or firmware?
Reyk Floeter: OpenBSD 3.8 will not add support for any new wireless network drivers. Work has been concentrated on improving the existing wireless drivers and our interpretation of the net80211 layer. Some commands have been added to ifconfig, and some cleanup has been done. It's funny that we removed more lines from net80211 than we added to during the last release cycle indeed.
Nevertheless, the battle for new wireless drivers is not over. Work for some new drivers and new chipset revisions is in progress. We got some amazing support from some vendors during the last month, and we'll be able to support their a/b/g chipsets very soon. But I have to note that we didn't get any documentation or hardware from wireless chipset vendors in the US, yet.
You have implemented the Inter-Access Point Protocol (IAPP). Now we can use
hostapd to handle communication between different 802.11 wireless access points running in Host AP mode. This means that we could create a network of APs and track roaming users. How does it work concretely?
Reyk Floeter: I started the implementation of
hostapd(8) some months ago to add this IAPP protocol. It's still a very basic implementation and does not support the full protocol yet. Currently, an access point using hostapd sends an IAPP notification to an internal multicast or broadcast group every time a new station has been successfully associated. Other hostapds listening to this multicast or broadcast group will be able to remove any allocated resources for this station, which will improve their availability. Additionally, it's possible to do central logging of any station movements in the wireless network in real time, using a hostapd listening to the IAPP messages.
Does it offer any new opportunity for WiFi attackers?
Reyk Floeter: No, it will not make it worse than IEEE 802.11 already is. But
hostapd(8) provides some great features to improve wireless network security. After the c2k5 hackathon, I added support for "Event Rules." They provide a powerful mechanism to trigger certain actions when receiving specified IEEE 802.11 frames. Human-readable event rules in
hostapd.conf(5), similar to the packet filter rules in
pf.conf(5), will be helpful to implement proactive wireless network monitoring, also known as WIDS/WIPS (wireless intrusion detection/prevention system). With
hostapd(8) I keep in track of what's going on in my wireless networks using a central logging server listening to the multicast group. In some setups, where nobody else is allowed to run an accesspoint, I even use
hostapd to send deauthentication frames to stations associated to rogue accesspoints and to detect and log the rogue access points.