Two new wireless-related working groups met for the first time during IETF 65:
- NETLMM – working on a protocol for network-based, localized mobility management
- EMU – working on an update of EAP-TLS to improve interoperability and bring it to standards track, standardization of an EAP method using shared keys, and an EAP method using password databases.
In addition, there were BOFs related to mobility and wireless:
- 16NG (met for the second time) – discussing work needed by IEEE, WiMax, and WiBro to put IPv6 over 802.16e
- HOAKEY – discussing work to standardize the EAP application key hierarchy for handover, backend AAA work for preauthentication, and AAA key distribution for services.
In this review, we will discuss two working groups that are about done with their charter deliverables: the MOBIKE WG and the 6LOWPAN WG. MOBIKE is in the Security Area and 6LOWPAN is in the Internet Area.
The MOBIKE working group was chartered to define modifications to the IKEv2 mutual authentication and key exchange protocol that allow a moving node or a node with multiple interfaces to switch local addresses without having to re-establish their IKEv2 and IPsec security associations. The protocol does not apply to IKEv1. The working group confined their work to tunnel-mode SAs, transport-mode SAs were explicitly declared out of scope. The work is expected to be most useful for VPN clients, so that they can move between wireless access points or between multiple wireless interfaces – for example WLAN and GPRS – without having to establish new security associations. Although the protocol supports use of multiple addresses on both ends, only one pair of addresses (client side, VPN-gateway side) may be used at a time. The protocol does not support dynamic load balancing between addresses.
The initiator of the IKEv2 SA, typically a remote VPN client is responsible for deciding what pair of addresses to use. The VPN gateway simply tells the client what addresses it has available but does not initiate an update of the client’s IPsec SAs until the client requests it. The protocol includes two features designed to handle explicit security concerns associated with mobility and multihomed hosts. A return routability check is included so that a VPN gateway can optionally check whether the client is, in fact, reachable at the addresses it has specified. This prevents a redirection attack, in which a fully authenticated client-attacker provides addresses where another node is reachable, to which the attacker then redirects traffic. An explicit mechanism for excluding Network Address Translators (NATs) and other address translators such as IPv4/IPv6 gateways is included.
This mechanism is primarily for site-to-site VPNs and other cases where NATs and other middleboxes that modify addresses are known not to be present, and any modification of the IP address can be considered an attack. The working group has produced two documents, one on design considerations (an Informational document) and another defining the protocol itself (for Proposed Standard). Both documents have passed IETF last call and are in the RFC Editor’s queue. At IETF 65, the working group discussed remaining items, principally a modification of the PFKEY interface to reduce overhead of IPsec SA movements and tunnel overhead, and a possible new item, the Bound End to End Tunnel (BEET) draft, which had been proposed as a work item initially but was deferred until the initial work was complete.
The working group decided to drop the PFKEY goal due to lack of implementation interest. BEET provides limited tunnel mode semantics for IPsec ESP when the ESP security association is end-to-end, rather than end-to-middle, as in VPNs. The working group has decided to close since there was also not enough interest in continuing work on BEET.
The 6lowpan WG was chartered to work on the problem of transmitting IPv6 packets over 802.15.4 low power wireless networks. These networks are characterized by a bit rate of 20 to 250 kbps in the frequency range of 900 to 2400 MHz. The link layer is almost but not entirely like standard 802.11 networks, but the range is much more limited. Also, since broadcast is expensive, it is necessary to avoid multicasting wherever possible.
The deliverables for the working group were to produce a problem statement, describing why the standard default IPv6 to Ethernet binding needs changing, and a solution document, describing modifications to various aspects of sending IPv6 packets over 802.15.4 links. The problem statement document is complete, and the solution document is undergoing final discussion. 802.15.4 nodes are allowed to have 16 bit MAC addresses in order to save space in link layer frames.
The solution document specifies a way to generate the interface identifier part of the IPv6 address (bottom 64 bits) using a 16 bit instead of an EUI-64 bit MAC address. Since the MTU for 802.15.4 frames is below the minimum MTU for IPv6 packets, fragmentation, and reassembly mechanisms are defined. Modifications to stateless address autoconfiguration that suppress multicast are also specified.
Finally, a stateless header compression algorithm is presented to reduce the header overhead of IPv6 packets. At IETF 65, the working group discussed a few remaining items in the solution draft, and possible recharter items. Node configuration and setup for 802.15.4 nodes was discussed as a possible recharter item. The idea here is to reduce further the need for human intervention to automate connecting sensors and other non-human interfaced devices to the network. Security configuration is especially a concern.
The development of a specification for layer-2 mesh routing was also discussed as a charter item. The idea would be to investigate a MANET routing protocol such as AODV and see what would be needed to adapt it to setting up Layer 2 meshes. Although specifications are available for mesh routing of 802.15.4 networks, the specifications are difficult for developers to access. Another possible recharter topic is the a set of recommendations for applications, such as service discovery or application protocols such as SNMP. Finally, working on security threats and solutions was discussed. The working group has established a Wiki as an experiment in recording discussion and design ideas that don’t end up in the working group documents. The Wiki can be accessed at http://6lowpan.tzi.org.