Network Working Group J. Kempf, Ed. Request for Comments: 4831 DoCoMo USA Labs Category: Informational April 2007 Goals for Network-Based Localized Mobility Management (NETLMM) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractIn this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. 1. Introduction ....................................................2 1.1. Terminology ................................................2 2. NETLMM Functional Architecture ..................................3 3. Goals for the NETLMM Protocol ...................................3 3.1. Goal 1: Handover Performance Improvement ...................4 3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5 3.3. Goal 3: Location Privacy ...................................6 3.4. Goal 4: Limit Overhead in the Network ......................7 3.5. Goal 5: Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection Security ................................7 3.6. Goal 6: Link Technology Agnostic ...........................8 3.7. Goal 7: Support for Unmodified Mobile Nodes ................8 3.8. Goal 8: Support for IPv4 and IPv6 ..........................9 3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10 3.10. Goal 10: Localized Mobility Management Independent of Global Mobility Management ................10 3.11. Goal 11: Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access Gateway ..11 4. Security Considerations ........................................11 5. Acknowledgements ...............................................11 6. Normative References ...........................................12 7. Informative References .........................................12 8. Contributors ...................................................13
1], the basic problems that occur when a global mobility protocol is used for managing local mobility are described, and two currently used approaches to localized mobility management -- the host-based approach that is used by most IETF protocols, and the proprietary Wireless LAN (WLAN) switch approach used between WLAN switches in different subnets -- are examined. The conclusion from the problem statement document is that none of the approaches has a complete solution to the problem. While the WLAN switch approach is most convenient for network operators and users because it requires no software on the mobile node other than the standard drivers for WiFi, the proprietary nature limits interoperability, and the restriction to a single last-hop link type and wired backhaul link type restricts scalability. The IETF host-based protocols require host software stack changes that may not be compatible with all global mobility protocols. They also require specialized and complex security transactions with the network that may limit deployability. The conclusion is that a localized mobility management protocol that is network based and requires no software on the host for localized mobility management is desirable. This document develops a brief functional architecture and detailed goals for a network-based localized mobility management protocol (NETLMM). Section 2 describes the functional architecture of NETLMM. In Section 3, a list of goals that is desirable in the NETLMM protocol is presented. Section 4 briefly outlines Security Considerations. More discussion of security can be found in the threat analysis document . RFC 3753  and in . In addition, the following terms are related to the functional architecture described in Section 2: Localized Mobility Management Domain An Access Network in the sense defined in  in which mobility is handled by the NETLMM protocol. Mobile Access Gateway A Mobile Access Gateway (MAG) is a functional network element that terminates a specific edge link and tracks mobile node IP-level mobility between edge links, through NETLMM signaling with the Localized Mobility Anchor. The MAG also terminates host routed data traffic from the Localized Mobility Anchor for mobile nodes
currently located within the edge link under the MAG's control, and forwards data traffic from mobile nodes on the edge link under its control to the Localized Mobility Anchor. Local Mobility Anchor A Local Mobility Anchor (LMA) is a router that maintains a collection of host routes and associated forwarding information for mobile nodes within a localized mobility management domain under its control. Together with the MAGs associated with it, the LMA uses the NETLMM protocol to manage IP node mobility within the localized mobility management domain. Routing of mobile node data traffic is anchored at the LMA as the mobile node moves around within the localized mobility management domain. Section 2 of  describes three problems with using a global mobility management protocol for localized mobility management. Any localized mobility management protocol must naturally address these three problems. In addition, the side effects of introducing such a solution into the network need to be limited. In this section, we address goals for NETLMM, including both solving the basic problems (Goals 1, 2, and 3) and limiting the side effects (Goals 4+).
Some basic goals of all IETF protocols are not discussed in detail here, but any solution is expected to satisfy them. These goals are fault tolerance, robustness, interoperability, scalability, and minimal specialized network equipment. A good discussion of their applicability to IETF protocols can be found in . Out of scope for the initial goals discussion are Quality of Service (QoS) and dormant mode/paging. While these are important functions for mobile nodes, they are not part of the base localized mobility management problem. In addition, mobility between localized mobility management domains is not covered here. It is assumed that this is covered by the global mobility management protocols.
9] as the global mobility protocol (other mobility protocols require about the same or somewhat less), if a mobile node using address autoconfiguration is required to reconfigure on every move between links, the following signaling must be performed: 1) Link-layer signaling required for handover and reauthentication. For example, in 802.11 , this is the Reassociate message together with 802.1x  reauthentication using EAP. 2) Active IP-level movement detection, including router reachability. The Detecting Network Attachment (DNA) protocol  uses Router Solicitation/Router Advertisement for this purpose. In addition, if SEcure Neighbor Discovery (SEND)  is used and the mobile node does not have a certificate cached for the router, the mobile node must use Certification Path Solicitation/Certification Path Advertisement to obtain a certification path. 3) Two Multicast Listener Discovery (MLD)  REPORT messages, one for each of the solicited node multicast addresses corresponding to the link local address and the global address. 4) Two Neighbor Solicitation (NS) messages for duplicate address detection, one for the link local address and one for the global address. If the addresses are unique, no response will be forthcoming. 5) Two NS messages from the router for address resolution of the link local and global addresses, and two Neighbor Advertisement messages in response from the mobile node. 6) Binding Update/Binding Acknowledgement between the mobile node and home agent to update the care of address binding. 7) Return routability signaling between the correspondent node and mobile node to establish the binding key, consisting of one Home Test Init/Home Test and Care of Test Init/Care of Test. 8) Binding Update/Binding Acknowledgement between the correspondent node and mobile node for route optimization. Note that Steps 1-2 may be necessary, even for intra-link mobility, if the last-hop link protocol doesn't provide much help for IP handover. Steps 3-5 will be different if stateful address configuration is used, since additional messages are required to obtain the address. Steps 6-8 are only necessary when Mobile IPv6 is
used. The result is approximately 18 messages at the IP level, where the exact number depends on various specific factors, such as whether or not the mobile node has a router certificate cached before a mobile node can be ensured that it is established on a link and has full IP connectivity. In addition to handover related signaling, if the mobile node performs Mobile IPv6 route optimization, it may be required to renew its return routability key periodically (on the order of every 7 minutes), even if it is not moving, resulting in additional signaling. The signaling required has a large impact on the performance of handover, impacting Goal 1. Perhaps more importantly, the aggregate impact from many mobile nodes of such signaling on expensive shared links (such as wireless where the capacity of the link cannot easily be expanded) can result in reduced last-hop link capacity for data traffic. Additionally, in links where the end user is charged for IP traffic, IP signaling is not without cost. To address the issue of signaling impact described above, the goal is that handover signaling volume from the mobile node to the network should be no more than what is needed for the mobile node to perform secure IP-level movement detection, in cases where no link-layer support exists. Furthermore, NETLMM should not introduce any additional signaling during handover beyond what is required for IP- level movement detection. If link-layer support exists for IP-level movement detection, the mobile node may not need to perform any additional IP-level signaling after link-layer handover.
In order to reduce the risk from location privacy compromises as a result of IP address changes, the goal for NETLMM is to remove the need to change IP address as a mobile node moves across links in an access network. Keeping the IP address fixed over a large geographical region fuzzes out the resolution of the mapping between the IP subnets and geographical area, regardless of how small the natural deployment granularity may be. This reduces the chance that the attacker can deduce the precise geographic location of the mobile node.
3.5. Goal 5: Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection SecurityLocalized mobility management protocols that have host involvement may require an additional security association between the mobile node and the mobility anchor, and establishing this security association may require additional signaling between the mobile node and the mobility anchor (see  for an example). The additional security association requires extra signaling and therefore extra time to negotiate. Reducing the complexity of mobile-node-to-network security for localized mobility management can therefore reduce barriers to deployment and improve responsiveness. Naturally, such simplification must not come at the expense of maintaining strong security guarantees for both the network and mobile node. In NETLMM, the network (specifically, the MAG) derives the occurrence of a mobility event, requiring a routing update for a mobile node from link-layer handover signaling, or IP-layer movement detection signaling from the mobile node. This information is used to update routing for the mobile node at the LMA. The handover, or movement detection signaling, must provide the network with proper authentication and authorization so that the network can definitively identify the mobile node and determine its authorization. The authorization may be at the IP level -- for example, using something like SEND  to secure IP movement detection signaling -- or it at
the link level. Proper authentication and authorization must be implemented on link-layer handover signaling and/or IP-level movement detection signaling in order for the MAG to securely deduce mobile node movement events. Security threats to the NETLMM protocol are discussed in . The goal is that security for NETLMM mobile node mobility management should derive from IP network access and/or IP movement detection security, such as SEND or network access authentication, and not require any additional security associations or additional signaling between the mobile node and the network.
Identity Protocol (HIP)  and IKEv2 Mobility and Multihoming (MOBIKE)  are likely to need support in addition to Mobile IPv6 , and Mobile IPv4  support may also be necessary. Note that this goal does NOT mean that the mobile node has no software at all associated with mobility. The mobile node must have some kind of global mobility protocol if it is to move from one domain of edge mobility support to another and maintain session continuity, although no global mobility protocol is required if the mobile node only moves within the coverage area of the localized mobility management protocol or no session continuity is required during global movement. Also, if the last-hop link is a wireless link, every wireless link protocol requires handover support on the mobile node in the physical and medium access control layers, typically in the wireless interface driver. Information passed from the medium access control layer to the IP layer on the mobile node may be necessary to trigger IP signaling for IP handover. Such movement detection support at the IP level may be required in order to determine whether the mobile node's default router is still reachable after the move to a new access point has occurred at the medium access control layer. Whether or not such support is required depends on whether the medium access control layer can completely hide link movement from the IP layer. For cellular type wireless link protocols, the mobile node and network undergo an extensive negotiation at the medium access control layer prior to handover, so it may be possible to trigger a routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11  in which the decision for handover is entirely in the hands of the mobile node, IP-layer movement detection signaling from the mobile node may be required to trigger a routing update. The goal is that the localized mobility management solution should be able to support any mobile node that joins the link and that has an interface that can communicate with the network, without requiring localized mobility management software on the mobile node. Section 3.7), minimizing mobile node support for localized mobility means that ideally no IP version-specific changes should be required on the mobile node for localized mobility, and that global mobility protocols for both IPv4 and IPv6 should be supported. Any IP version-specific features should be confined to the network protocol.
3.11. Goal 11: Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access GatewayDifferent network operators may require different types of forwarding options between the LMA and the MAGs for mobile node data plane traffic. An obvious forwarding option that has been used in past IETF localized mobility management protocols is IP-IP encapsulation for bidirectional tunneling. The tunnel endpoints are the LMA and the MAGs. But other options are possible. Some network deployments may prefer routing-based solutions. Others may require security tunnels using IPsec Encapsulating Security Payload (ESP) encapsulation if part of the localized mobility management domain runs over a public access network and the network operator wants to protect the traffic. A goal of the NETLMM protocol is to allow the forwarding between the LMA and MAGs to be configurable depending on the particulars of the network deployment. Configurability is not expected to be dynamic, as in controlled by the arrival of a mobile node; but rather, configuration is expected to be similar in timescale to configuration for routing. The NETLMM protocol may designate a default forwarding mechanism. It is also possible that additional work may be required to specify the interaction between a particular forwarding mechanism and the NETLMM protocol, but this work is not in scope of the NETLMM base protocol. Section 3.3 and 3.5, focus on the former, because those are unique to network-based mobility management. The threat analysis document  contains a more detailed discussion of both kinds of threats, which the protocol design must address.
 Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.  Vogt, C., and Kempf, J., "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.  Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.  Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005.  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.  IEEE, "Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.  IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 2001.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.  Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.