Travelling without Moving: 802.11 Access Points backed by Secure NETLMM Julien Laganier, Matthias Flege, Alf Zugenmaier, Anand Prasad DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 D-80687 Munich Germany
[email protected]
James Kempf, Jonathan Wood DoCoMo Communications Laboratories USA, Inc. 3240 Hillview Avenue Palo Alto, CA 94304-1201 USA
[email protected]
Abstract— In network-based localized mobility management (NETLMM), a mobile node is not involved in signalling related to mobility support, and keeps the same IP address after handoff from one link to another. The mobile node’s current access router acts as a mobility access gateway by sending Proxy Local Binding Updates to the local mobility anchor on behalf of the mobile node. Due to some properties of the NETLMM domain, implementing it efficiently using IEEE 802.11 radio access networks is not straightforward. This paper presents the challenges involved with such an implementation, presents solutions to them, and analyze the overall performance of the complete system.
I. I NTRODUCTION In the IP addressing model, each distinct link is numbered with a distinct topological subnet prefix. Thus, when a mobile node (MN) moves and attaches to a new link, it will change its subnet prefix, and hence its IP address. This change of IP address will disrupt communications based on upper layer protocols such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) which typically name communications endpoints with IP addresses. To cope with the issues introduced by mobility, host-based mobility management protocols such as Mobile IP [1] have been introduced. In these host-based mobility management protocols, a MN is given a home address which is routed towards a home agent lying in the home network of the MN. The MN keeps its home agent informed with its current topological IP address (denoted as care-of address in Mobile IP terminology). When the home agent receives a packet destined to the MN home address, it will tunnel this packet up to the MN care-of address. Thus, in spite of its movements, the MN can maintain reachability at its home address, and avoid disruption of existing communications bound to its home address. In network-based localized mobility management (NETLMM), a MN is not involved in signalling related to mobility support, and keeps the same IP address after handoff from one link to another as long as its stays in the same NETLMM domain. The MN’s current access router acts as a mobility access gateway (MAG) by sending
proxy Binding Update (pBU) messages to the local mobility anchor (LMA) on behalf of the MN. Due to constraints imposed by the NETLMM architecture and the IP addressing model, it is not straightforward to implement it efficiently using the 802.11 technology in the radio access network. This paper presents the challenges involved with such an implementation, presents solutions to them, and analyze the overall performance of the complete system. The paper is organized as follows: We will first give an overview of NETLMM in Section II. We will then present the challenges involved with the implementation of a secure NETLMM domain using 802.11 hotspots in Section III. In Section IV, we will continue with a performance measurements we did using an emulated 30ms Round Trip Time (RT T ) backhaul network. Finally, we will summarize our contribution and discuss possible further studies in Section V.
II. NETLMM OVERVIEW The Internet Engineering Task Force (IETF) already standardized several host-based mobility management protocols. It has however been suggested [2] that it would be desirable to have a localized mobility management protocol in which the host is not involved. The requirements for such a protocol have been analyzed [3], and it is shown that none of the existing protocols completely fulfills them. Accordingly, the IETF chartered the NETLMM working group (WG) to develop a mechanism for network-based localized mobility support of IPv6 nodes. Because it is network based, the MN is not required to implement new mechanism in its IP stack, or to change its IP address when it attaches to a new access router. To date, the WG has not adopted any of the individual submission as WG draft. However, two of these individual submissions [4], [5] are quite mature and likely to be as close as possible to the final solution the WG will eventually deliver. This paper discusses a NETLMM protocol isomorphic to these two proposals.
1095-2055/07/$25.00 ©2007 IEEE
A. Terminology •
•
•
•
•
•
Network-based Localized Mobility Management Domain (NETLMM domain) : An administrative domain spanning geographically contiguous link layer networks served by access routers acting as MAGs. Mobile Node (MN): The MN is an IPv6 node moving in the domain. Host software for network layer mobility management (e.g. MIPv6) is not required on the MN (but might nevertheless be present). Mobile Node Identifier (MN ID): The MN ID is an authenticated identifier of the MN used by the NETLMM protocol to identify a MN and index its NETLMM state. Mobility Access Gateway (MAG): The Mobile Node’s default router which sends and receives NETLMM mobility signaling on behalf of the MN. Local Mobility Anchor (LMA): A router located in the network-based localized mobility domain handling exchanged between that domain and the Internet. Correspondent Node (CN): The CN is an IPv6 node which communicates with the MN. It is used to measure impact of handoffs on communication performance.
B. Protocol Overview A typical usage scenario (with two MAGs only for the sake of simplicity) is shown in Figure 1. LMA
15ms
Core Network
MAG1
MAG2
MN
Fig. 1.
Usage scenario.
The LMA is configured with a global IPv6 prefix which will be subdivided into individual, per MN subnet prefixes. Each MAG will announce such a per MN subnet prefix to the corresponding MN using Router Advertisements (RA). The MAG sends pBU message to the LMA on behalf of the MN. When the MN moves from one MAG to another, it will initiate the DNA protocol [6] by sending a Router Solicitation (RS) to the All-routers multicast address (ff02::2). The MAG will reply to this RS with an RA containing the MN’s subnet prefix. Therefore, the MN will never see a different subnet
prefix, and conclude that it did not change link. Following this, the MN will not reconfigure its IP address. Because the IPv6 MN uses an unmodified IPv6 stack, the interface between a MN and its access router has to be preserved. This means that standard IPv6 should work seamlessly with the network-based localized mobility support. More specifically, the NETLMM protocol should support a MN implementing the mechanisms specified in: • • • • •
Neighbor Discovery for IP version 6 [7] IPv6 Stateless Address Autoconfiguration [8] Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [9] Secure Neighbor Discovery [10]. Cryptographically Generated Addresses [11].
For each MN present in the NETLMM domain, the LMA maintains a route pointing to the MAG serving the link to which the MN is attached. The packets to and from the MN are tunneled between the MAG and the LMA, using existing tunneling mechanisms (e.g. IP encapsulation within IP). For each of the MN attached to a given link, the MAG maintains a neighbor cache entry specifying how to deliver packets to the MN (e.g. its link layer address) [7], and update the LMA with a pBU message specifying that the MN is reachable via the MAG. The pBU contains the MN ID. The LMA confirms that the route ”MN reachable via MAG” has been installed by sending a proxy Binding Acknowledgment (pBAck) message containing the subnet prefix assigned to the MN. This MN assigned subnet prefix will subsequently be included in the prefix information option of RA messages [7] sent to the MN. The routing update process (PBU and PBack) takes about 1RT T between MAG and LMA to complete. When the MN attaches to a link of the domain, it discovers the link’s MAG and the per-MN subnet prefix it has been assigned by sending an RS and receiving from the MAG a RA [7], [6]. If it is the first attachment of the MN to that domain, it configures an IP address within that subnet prefix. Otherwise it will notice that the subnet prefix did not change, and keep the same IP address configured [6]. If, for one reason or another (e.g. link layer notification, Neighbor Unreachability Detection failure) the MAG detects that the MN has left the link, it will deregister the MN ID with the LMA by sending a pBU message containing the MN ID and a deregistration command (indicated by a zero lifetime). The LMA will then remove the routing entry pointing for this MN and acknowledge this deregistration with a pBAck message. In addition, to allow the detection of a MN which silently crashed, it is required that the MAG initiates for each of the locally attached MNs a periodic Neighbor Unreachability Detection procedure; if the MN cannot be reached, then the MAG should deregister the MN with the LMA as explained earlier. If the LMA receives from a MAG a pBU for a node that is still registered at an old MAG, the LMA must inform the old MAG that the MN has silently left its link by sending to it a pBAck message containing a delete command (indicated by a zero lifetime). The MAG then deletes local state for the MN and does not acknowledges this delete command.
When the MAG receives a tunneled packet from the LMA, it searches the packet destination address in the neighbor cache entry, and forward the packet to the link layer address recorded in the entry. When an LMA receives an IPv6 packet, it searches the packet destination address in the routing table. If the packet is destined to a MN registered in the NETLMM domain, then according to the routing table entry for that MN the packet is forwarded in the tunnel leading to the MAG at which the MN is registered. C. Architectural issues with the NETLMM subnet model Within the Internet addressing model, the link and subnet terms, have a tight relationship. Their generally admitted definitions are: • Link: a topological area of an IP network delimited by routers. • Subnet: a topological area of an IP network that uses the same unsubdivided address prefix. There has recently been protocol proposals achieving multilink subnets, i.e. the ability for a subnet to span multiple links. However, the consensus in the IETF has been, and remains, that one subnet spans only one link [12]. A straightforward approach to the design of NETLMM would have been to lay a single subnet on the entire NETLMM domain. That would ensure that the MN does not see layer 3 movements since the subnet would never change. However, such an approach would constitute a multi-link subnet, and is thus not deemed acceptable. Thus, the NETLMM addressing model is subject to the following two constraints: • The subnet of a MN does not change when the MN changes its attachment point in the domain. • The subnet of a MN does not span more than one link. Because of the first constraint, the subnet of a MN must be valid wherever in the domain the MN attaches to. However, because of the second constraint, the subnet cannot be valid at more than one such attachment points. Thus, the subnet of the MN has to follow the movements of the MN. This addressing model is denoted per-MN subnet model, and satisfies constraints of both the Internet and NETLMM architectures. But we will see that the choice of this addressing model is also conflicting with the use of a shared link layer (e.g. Ethernet, 802.11) as a last hop of the NETLMM domain. In the per-MN subnet model, two MNs always have different subnets. Hence, even though they might be attached to the same shared link layer, they will never communicate directly with global addresses. That happens since on-link determination will always conclude that they are attached to different link because it is based on subnet comparisons. They will however be able to communicate directly with link-local addresses. This is not problematic since link-local addresses are confined to one link and therefore it does not introduce multi-link subnet issues. There is however one problem that arises due to the use of Solicited-Node and All-Nodes multicast IPv6 addresses [13] as a destination address for sending unsolicited Neighbor Advertisement (NA) messages [7]. When one MN
sends such message, it can be received by other MNs on the same link which will, as a result, create a neighbor cache entry for the sender of the NA. If the NA contained as a target address one of the MN’s global unicast address, the receiver is then in a position to communicate directly with this global unicast address, even though it does not share a common subnet prefix (they are per-MN subnet prefixes). This is not a problem as long as these two MNs remain attached on the same link. But if later on one of the MN moves onto a different link, they will no longer be able to communicate directly and this will result in a communication failure, although they were using global addresses whose reachability should be maintained. This is not acceptable. III. I MPLEMENTATION C HALLENGES This section discusses the challenges of implementing NETLMM correctly, securely, and efficiently. A. Link Model In Section II-C we illustrated the problem of using per-MN subnet prefix over a shared link in the NETLMM context, which is exactly what we want to do: 802.11 is a shared link from the point of view of the IP layer. As a solution to this problem, we decided to turn the 802.11 shared link into a collection of point-to-point link between stations (i.e. MN) and access point (i.e. MAG) arranged in star topology centered around the access point. This is achieved by disabling 802.11 frames bridging at the access point. Doing so ensure that frames exchanged on one association are confined to that association: Unicast and multicast 802.11 frames sent on one association are never forwarded on another association by the 802.11 layer of the access point. With an Atheros based WiFi Network Interface Card (NIC) used as an access point and managed by the MadWifi driver [14], this is done by setting the IEEE80211 F NOBRIDGE flag for the access point via issuing the private ioctl() IEEE80211 PARAM APBRIDGE (20) with parameter 0 (zero). This ioctl() is issued with the command iwpriv ath0 setparam 20 0. B. Routing considerations As shown in Figure 2, when a MN handoff happens from an old MAG to a new MAG there is race condition between data packets for a MN being delivered at the new MAG before the LMA has informed the MAG of the MN’s subnet prefix with a pBAck message. In that case, the MAG will not have a route for the MN’s subnet prefix, and will hence forward these packets based on its default route, i.e. send them back to the LMA. This constitutes a transient routing loop, which will disappear as soon as the MAG receives the pBAck message and modifies its routing tables accordingly. Because it is only transient it has a limited potential to harm forwarding capacity in the NETLMM core network. Such transient routing loops can however harm applications since the MN stack will receive out-of-order TCP segments and real time applications will not be able to receive messages in time.
We solved this issue by having the MAG proactively set a route to the MN’s subnet prefix it receives in the RS sent by the MN. This allows to route packets to the MN via the WiFi interface prior to reception of the pBAck message, thus avoiding formation of transient routing loops. However, in the case of a MN first attachment to a given NETLMM domain, the MN would send an RS with a subnet prefix that was valid at his previous point of attachment, but is not valid in this NETLMM domain. Hence, the pBAck message would not contain the subnet prefix to which a route has been proactively set up. In that case, the MAG would remove that route and set an appropriate route to the MN subnet prefix received in the pBAck message. Another issue with routing is due to the absence of NETLMM specific routing mechanism on the MAG. When two MNs attached to the same MAG communicate together the packet will simply flow via the MAG. Later on, when one of the MN moves to a different MAG, the packet will then have to travel via the LMA. This introduces nonuniformity of packet delivery delay from one MN to another MN in the same domain. This is a source of jitter that badly impacts many streaming applications since they cannot determine accurately the amount of buffering that they need to perform. Thus, all packets exchanged between two MNs in the domain should always travels via the LMA, even though they might be attached to the same MAG. We achieve this by using policy routing. A MAG uses its usual routing table to route packets coming from the backhaul network, but uses a NETLMM specific routing table to route all packets received from the WiFi interface. This NETLMM specific routing table has only one entry, a default route via the tunnel interface to the LMA. Thus, all packets received from a MN are sent to the LMA, which fulfills our goal. The last issue lies in the fact that after a handoff, the MN will follow the DNA protocol and tries to discover the MAG and the link subnet prefix by sending an RS. The MAG cannot reply to the RS with an RA before it is informed by the LMA of the subnet prefix assigned to the MN. That would delay by one RT T completion of DNA, and therefore discovery of the new MAG link layer address by the MN. Hence, the MN would not be able to transmit packets for the same duration because it would try to transmit packets at the old MAG link layer address, and none of these packets would ever be delivered. The solution to this issue is to put the WiFi NIC on the MAG in promiscuous mode so that it receives all frames sent by MNs even though the destination link layer address of the frame is not configured on the NIC. C. Security considerations The threats on a public multi-access link running IPv6 Neighbor Discovery (ND) [15] are also present on radio access links of a NETLMM domain. Most of them are countered by the use of the Secure Neighbor Discovery (SEND) protocol [10]. A NETLMM deployment is subject to threats in three different areas. There are threats to the interface between LMA
and MAG, which can be dealt with by an appropriate use of network layer security (i.e. IPsec) to secure communications between LMA and MAG. This can be accomplished by configuring a pair of unidirectional IPsec SA between each MAG and LMA. There are also threats to the interface between MAG and MN, where a rogue MN could pretend to own the IP address of another MN to cause malicious redirections attacks in the NETLMM routing fabric. This attack is countered by the use of SEND [10] to secure the MN movement detection by the MAG. We mandate that every MN in the domain uses a public key to generate all of its IPv6 addresses (i.e. link-local and global addresses) using the Cryptographically Generated Address (CGA) [11] technique. A MN uses the same public key to generate all its IPv6 addresses. By doing so, we ensure that all the IPv6 addresses of a given MN are bound together with the SEND public key. This SEND public key is in turn used by the NETLMM infrastructure as a secure MN ID. A MAG will only trigger the NETLMM routing update process if it was able to verify that the MN owns the linklocal address used as a source address of the RS message it sends as part of the DNA procedure [6]. If it is the case it will send a pBU for that MN ID to the LMA. The LMA will in turn update routing for all the IPv6 addresses bound to that MN ID. The use of SEND has also implications on the addressing of MAGs in the domain. As per the DNA protocol, the MN will not execute again Duplicate Address Detection (DAD) after a handoff in the domain. This is because the MN will always receive the same subnet prefix in the RA and conclude that it did not changed link. Hence there seems to be no need for executing DAD again. However, in NETLMM the link did changed. Because the link is point-to-point the only new entity on the link is the MAG, and it is possible that a collision occurs between link local addresses of the MN and the MAG. One solution to this issue would be that in a given domain, each MAG also defends link-local addresses of other MAGs in the domain. This would ensure that when the MN first attaches to the NETLMM domain and execute DAD it is able to pro-actively detect collision that may happen with any MAG of the domain. However, since SEND requires a Neighbor Advertisement (NA) message defending an address to be signed with the SEND public key generating the CGA link-local address, that would mean that each MAG also need to know private keys of all other MAGs. Since this solution is quite complex and requires secure distribution of keying material to MAGs, we adopted a simpler solution in which all MAGs share a single SEND public-private key pair, and hence a single CGA. Therefore, if the MN executes DAD at his first attachment and concludes that there is no collision with the link-local address of the first MAG, a collision with any other MAG in the domain is impossible. D. Packets Loss due to Routing Update Latency As we saw earlier, after a MN handoff, the LMA begins to route packets at the new MAG after it received from the
35ms 6ms
LMA
pdate
ding
Bind ing U
y Bin men
ledg
prox y
now
Ac k
15ms
t
Link Up
MAG ol
d RtA v
RtS
