Netlmm V. Narayanan Internet-Draft L. Dondeti Expires: September 9, 2006 QUALCOMM, Inc. March 8, 2006 Network-Based Mobility (NETMOB) for End Hosts draft-vidya-netlmm-netmob-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The requirements for Network-based Local Mobility Management protocol [8] indicate the need to develop a protocol where mobility management within an administratively defined local domain is done by network entities without the involvement of the end host, referred to as a Mobile Station in this document. This document proposes one method of providing network- based mobility for mobile stations in a simple and scalable manner. Narayanan & Dondeti Expires September 9, 2006 [Page 1] Internet-Draft NetMob March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. NetMob Location Update (NLU) . . . . . . . . . . . . . . . 8 4.2. NetMob Location Acknowledgement . . . . . . . . . . . . . 9 4.3. Newly Defined Mobility Options . . . . . . . . . . . . . . 10 4.3.1. Multiple Bindings Option . . . . . . . . . . . . . . . 11 4.4. IPv4 Home Address Option . . . . . . . . . . . . . . . . . 12 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. IP Address Configuration . . . . . . . . . . . . . . . . . 12 5.1.1. Static IP Addresses . . . . . . . . . . . . . . . . . 13 5.1.2. DHCP Address Assignment . . . . . . . . . . . . . . . 13 5.1.3. Stateless IPv6 Address Configuration . . . . . . . . . 13 5.2. Mobile Station Operation . . . . . . . . . . . . . . . . . 14 5.3. Mobility Proxy Agent Operation . . . . . . . . . . . . . . 14 5.3.1. Advertising Prefixes and Sending Router Advertisements . . . . . . . . . . . . . . . . . . . . 14 5.3.2. Sending NetMob Location Updates . . . . . . . . . . . 15 5.3.3. Receiving NetMob Location Acknowledgements . . . . . . 16 5.3.4. Error Processing . . . . . . . . . . . . . . . . . . . 17 5.4. Local Mobility Agent Operation . . . . . . . . . . . . . . 17 5.4.1. Receiving NetMob Location Updates and Sending NetMob Location Acknowledgements . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. NETMOB threats, mitigation mechanisms and strategies . . . 19 6.1.1. Attacks on NLUs and NLAs . . . . . . . . . . . . . . . 19 6.1.2. Attacks by MPAs: MPAs are trusted entities . . . . . . 20 6.1.3. Attacks by MSs . . . . . . . . . . . . . . . . . . . . 21 6.2. Per-MS security associations at MPAs and LMAs are not required . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Narayanan & Dondeti Expires September 9, 2006 [Page 2] Internet-Draft NetMob March 2006 1. Introduction The requirements for Network-based Local Mobility Management protocol [8] indicate the need to develop a protocol where mobility management within an administratively defined local domain is done by network entities without the involvement of the end host, referred to as a Mobile Station in this document. This document proposes one method of providing network-based mobility for mobile stations in a simple and scalable manner. This document describes the use of tunnels between edge entities, the Mobility Proxy Agents (MPAs), and the Local Mobility Agent (LMA). Within the network served by a single LMA, the MS does not need to undergo a change in IP address as it moves among relevant MPAs. Each MPA registers its IP address with the LMA as the location of the MS. When the MS moves to a different MPA, the new MPA will register the location of the MS, so that the packets destined to the MS will arrive at the new MPA. Local mobility managed as described in this document allows the mobile station to retain an IP address as it moves through the local topology. This preserves existing connections and enhances global mobility by reducing the number of re-registrations required. The protocol defined in this document is designed to support both IPv4 and IPv6 addresses of mobile stations. The network entities are, however, expected to support IPv6. Note that any IPv4-IPv6 network transition mechanisms itself are outside the scope of this document. This document describes the signaling between MPAs and LMAs required to maintain state about the location (in this context, location of an MS is the MPA that serve the MS) of the MSs and also explains the incoming and outgoing data paths. This document further describes how the signaling messages are secured. 1.1. Motivation Several solution drafts have already been written for NETLMM. This draft is quite similar in architecture to the already proposed drafts. We summarize the differences between the solution outlined in this draft and other drafts proposed to provide an understanding for the motivation of this draft. Narayanan & Dondeti Expires September 9, 2006 [Page 3] Internet-Draft NetMob March 2006 Protection of NETLMM signaling This draft proposes the use of an SA between the Mobility Proxy Agent and the Local Mobility Agent to secure the signaling messages exchanged between the two entities. The draft also provides supporting text to explain why a per-MS SA is not needed to secure the signaling. Reverse Tunneling This draft provides the capability to selectively perform reverse tunneling of traffic between the MPA and LMA. IPv4 and IPv6 MS Support This draft provides extensions to support IPv4 Mobile Stations along with IPv6 MSs. Simultaneous Bindings This draft provides support for simultaneous bindings for an MS at the LMA. This functionality would be critical to support make- before-break scenarios and can be added to the base protocol in a simple manner. Neighbor Discovery Protocol Operation The solution proposed here does not require any changes to IPv6 Neighbor Discovery Protocol. Prefix Registration Although the draft does not provide details on prefix registration, it has been written in a manner that allows easy extensibility for prefix registration. Cellular standards such as 3gpp and 3gpp2 assign a unique prefix to a Mobile Station, thereby making prefix registration support critical for NETLMM deployment in such scenarios. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC- 2119 [1]. In addition, this document uses the following terms: Narayanan & Dondeti Expires September 9, 2006 [Page 4] Internet-Draft NetMob March 2006 Mobility Proxy Agent An edge IP entity (such as an Access Router) that performs the signaling for mobility management of a Mobile Station associated with it and serves as a tunnel endpoint for data sent and/or received by the Mobile Station. Mobile Station An IPv4 or IPv6 end host that has an IP address belonging to the global prefix of an LMA. NetMob services will be available to these devices within a NETLMM domain. Local Mobility Agent An IP entity (such as a Core Router) that performs mobility management within the NETLMM domain. NETLMM Domain A region served by a given LMA. There may be several MPAs advertising the global prefixes belonging to that LMA within that domain. The MS does not change its IP address within the domain. Regional Home Address (RHoA) The IP address of the MS in the NETLMM domain. This address belongs to a global prefix on the LMA. This address remains unchanged within the NETLMM domain. Local Address (LoA) The IP address of the MPA with which the MS is associated. This is the address to which the LMA creates a binding for the RHoA of a given MS - it serves as the tunnel endpoint to send data corresponding to the RHoA of the MS. 3. Protocol Overview The NetMob protocol allows a Mobile Station to roam within a NETLMM domain seamlessly without resulting in a change to the IP address of the MS. A NETLMM domain may be administratively defined, consisting of a number of MPAs and LMAs. The protocol itself runs between MPAs and LMAs; no end host involvement is required. The MPAs and LMAs MUST support IPv6 in order to support the NetMob protocol. The LMA may be dual-stacked to support IPv4 MSs. The protocol itself is IPv6-based, even though it supports IPv4 Regional Home Addresses for Narayanan & Dondeti Expires September 9, 2006 [Page 5] Internet-Draft NetMob March 2006 the MSs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Core Network | | +----+ +----+ +--+ | | |AAA | |DHCP| |CN| | | +----+ +----+ +--+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | +----+ +----+ +----+ |LMA1| |LMA2| |LMA3| +----+ +----+ +----+ / \ / \ / \ / \ / \ / \ +----+ +----+ +----+ +----+ |MPA1| |MPA2| |MPA3| |MPA4| +----+ +----+ +----+ +----+ / \ / \ / \ / \ / \ / \ / \ / \ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | /:\ /:\ : : : : +--+ +--+ |MS| |MS| +--+ +--+ Figure 1: NetMob Architecture Figure 1 shows a possible network architecture for this protocol. Shown are several MPAs and LMAs. Multiple base stations may be associated with an MPA as shown. Multiple MPAs may be associated with the same LMA. Further, an MPA may be served by more than one LMA. It can be envisioned that there are a pool of LMAs in the network that may serve one or more MPAs. The links shown between the MPAs and the LMAs only illustrate an example association between the corresponding entities and does not imply physical or logical links. There may be multiple hops between an MPA and an LMA that serves the MPA for local mobility. Narayanan & Dondeti Expires September 9, 2006 [Page 6] Internet-Draft NetMob March 2006 When a MS first enters the domain, the MS acquires an IP address in the domain. Each MPA may advertise the global prefixes of one or more LMAs in the domain for those MSs using stateless IPv6 autoconfiguration [2]. In the case of IP address assignment via DHCPv4 or DHCPv6, the DHCP server may be configured to provide an IP address for the MS on the subnet/prefix of one of the LMAs. More details about IP address configuration for MSs is described in Section 5.1. Once an IP address has been configured by or assigned to the MS, the MPA corresponding to the MS sends a NetMob Location Update (NLU) to the LMA associated with it. Depending on the topology, it is possible for a given MPA to have connectivity to multiple LMAs, in which case, a particular LMA may be statically or dynamically assigned for a given MS. Such LMA assignment procedures itself are outside the scope of this draft. The NLU message contains the IP address of the MS (called Regional Home Address, RHoA) and that of the MPA sending the message (called the Local Address, LoA) so that the LMA can maintain a binding of the two addresses. The LMA creates a mapping of the RHoA and LoA in order to be able to forward packets to the MS. The MPA may explicity request a reverse tunnel to be set up for the RHoA, in order for packets from the MS to be sent via the LMA. The LMA must send a NetMob Location Acknowledgement (NLA) message in response to the NLU message. The NLA carries information about the status and lifetime of the binding. The NetMob protocol described in this document also allows mobile network prefixes to be registered with the LMA, in order to provide mobility management for mobile routers and networks. The protocol allows registration of both IPv4 and IPv6 prefixes. When the MS moves and associates with another MPA that also advertises the prefix of the same LMA, it does not have to reconfigure a new IP address. The new MPA may also advertise other prefixes belonging to other LMAs. The MPA SHOULD include all the prefixes advertised by it in every RA so that an MS whose RHoA already belongs to one of the prefixes advertised by the MPA, does not configure a new IP address based on the RA. When the MS associates with an MPA that no longer advertises the prefix of the LMA that was managing the mobility of the MS thus far, it will obtain a new IP address. At that point, the MS may use a global mobility management protocol for session continuity to applications. This procedure itself is outside the scope of this document. Narayanan & Dondeti Expires September 9, 2006 [Page 7] Internet-Draft NetMob March 2006 4. Message Formats 4.1. NetMob Location Update (NLU) The NetMob Location Update (NLU) message is used by a Mobility Proxy Agent to register a Local Address (LoA) corresponding to the Regional Home Address (RHoA) of a Mobile Station. The NLU is carried in the Mobility Header described in [3]. The NLU message uses the MH Type TBD (to be assigned by IANA). The format of the Mobility Data field in the Mobility Header is as follows for the NLU. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|R|M|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: NetMob Location Update NLU Fields Sequence Number A 16-bit unsigned integer used to sequence and match NetMob Location Updates with NetMob Location Acknowledgements. Acknowledge (A) The Acknowledge (A) bit is set by the MPA to request an NLA in response to the NLU. Reverse Tunnel (R) The Reverse Tunnel (R) bit is set by the MPA to request the LMA to set up a reverse tunnel for the RHoA-LoA binding. Narayanan & Dondeti Expires September 9, 2006 [Page 8] Internet-Draft NetMob March 2006 Multiple Bindings (M) The Multiple Bindings (M) bit is used by the MPA to indicate the request for multiple simultaneous bindings for the RHoA. Prefix Registration (P) The Prefix Registration (P) bit is used to indicate that the NLU/NLA is registering prefixes corresponding to an MS. Reserved 4 bits in lenth. MUST be set to 0 and ignored on reception. Lifetime The value of the lifetime field indicates the lifetime for the RHoA-LoA binding requested by the MPA. 16 bits in length. Mobility Options A variable length field of such length that the Mobility Header is an integer multiple of 8 octets long. The following options are considered valid in the NLU. Alternate Care-of-address option Multiple Bindings option Mobile Network Prefix option IPv4 Mobile Network Prefix option 4.2. NetMob Location Acknowledgement The NetMob Location Acknowledgement (NLA) is sent by a Local Mobility Agent (LMA) in response to a NetMob Location Update (NLU) received from an MPA. The NLA is a Mobility Header message with MH Type value TBD. The format of the Mobility Data in the MH for NLA is as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |R|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Narayanan & Dondeti Expires September 9, 2006 [Page 9] Internet-Draft NetMob March 2006 Figure 3: NetMob Location Acknowledgement NLA Fields Sequence Number A 16-bit unsigned integer used to sequence and match NetMob Location Updates with NetMob Location Acknowledgements. This value MUST be copied from the NLU corresponding to which this NLA is sent. Status The status of the NLA, 8 bits in length. The following values are defined for the NLA. 0 - Success 129 - IP_ADDR_REQD 130 - DUP_ADDR 131 - REVERSE_TUNNEL_SETUP_FAILED Reverse Tunnel (R) The Reverse Tunnel (R) bit is set by the LMA to instruct the MPA to always use a reverse tunnel for the RHoA-LoA binding. The LMA MAY override the MPA's request for no reverse tunnel in the corresponding NLU by setting this bit in the NLA. Reserved 8 bits in length. MUST be set to 0 and ignored on reception. Lifetime A 16-bit unsigned integer used to specify the lifetime of the RHoA-LoA binding. The MPA MUST set the lifetime for the corresponding RHoA binding to the value specified in this field. 4.3. Newly Defined Mobility Options Narayanan & Dondeti Expires September 9, 2006 [Page 10] Internet-Draft NetMob March 2006 4.3.1. Multiple Bindings Option This mobility option has the type of value TBD. This option MAY be sent when the 'M' bit in the NLU is set to 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Multiple Bindings Option MBO Fields Type 8 bits in length. Set to TBD (to be assigned by IANA). Length Length of the option, excluding the Type and Length fields. The value MUST be set to 4 bytes. Duplicate (D) Set to indicate request for duplicated data packets on all currently valid bindings corresponding to the RHoA. Reserved 15 bits in length. MUST be set to 0 and ignored on reception. Lifetime Remaining lifetime of the old RHoA-LoA binding that the current NLA would have replaced if the 'M' bit in the NLA was not set. This field is 16 bits in length. Narayanan & Dondeti Expires September 9, 2006 [Page 11] Internet-Draft NetMob March 2006 4.4. IPv4 Home Address Option The IPv4 Home Address Option is carried by an IPv6 Destination Option Extension Header. It is used to carry the IPv4 RHoA of an MS. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPv4 Home Address Option Option Fields Option Type Set to TBD (to be assigned by IANA). Length Length of the option, excluding the Type and Length fields. The value MUST be set to 4 bytes. IPv4 Address The IPv4 Regional Home Address (RHoA) of the MS on behalf of which the NLU is being sent by the MPA. 5. Protocol Details This section covers in detail the operation of the proposed NetMob protocol. 5.1. IP Address Configuration A Mobile Station entering a NETLMM domain for the first time may have a static or a dynamically assigned IP address. The dynamic IP address may either be obtained via DHCP or stateless IPv6 autoconfiguration (for IPv6 MSs). This section provides some details Narayanan & Dondeti Expires September 9, 2006 [Page 12] Internet-Draft NetMob March 2006 on each of these modes of IP address acquisition. 5.1.1. Static IP Addresses An MS MUST use a statically assigned IP address belonging to an IPv4 subnet or IPv6 prefix of one of the LMAs serving the NETLMM domain. When the MS associates with an MPA that does not advertise the subnet or prefix to which the MS's address belongs, it must reconfigure its address to the subnet or prefix advertised by the LMA corresponding to the new MPA. When the MS has a statically assigned IP address, the MPA may learn of the MS's IP address in one of many ways. The MPA may learn about the IP address during network access authentication, if the type of authentication allows that. It may also be sent in an IP message from the MS to the MPA -- the form of such a message is outside the scope of this document. The MPA may also learn the IP address upon receiving the first IP packet from that MS, based on the source address of the packet. However, it should be noted that in that case, packets sent to the MS may not reach it, due to a lack of state in the LMA at that time. 5.1.2. DHCP Address Assignment The MS may be assigned an IP address using DHCPv4 or DHCPv6 when it enters a NETLMM domain. When DHCP is used to assign addresses, the DHCP server must be able to assign an IP address belonging to the IPv4 subnet or IPv6 prefix of one of the LMAs serving that domain. If DHCP relay agents are present in the path between the MS and the DHCP server, the relay agents must be able to request an IP address for the MS on the prefix of one of the LMAs in the domain. When the MS uses DHCP to obtain an IP address, the MPA may serve as the DHCP Relay and learn of the IP address during the DHCP process. It is also possible to use any of the methods mentioned in the section above to learn the IP address of the MS. 5.1.3. Stateless IPv6 Address Configuration An IPv6 MS may configure an IP address using stateless autoconfiguration as described in [4] and [2]. In this case, the MPAs in a domain MUST advertise global prefixes belonging to one or more LMAs in that domain. Also, the MPAs MUST NOT advertise any global prefixes that do not belong to one of the LMAs in that domain. Further, an MPA SHOULD include all the global prefixes advertised by it in every Router Advertisement (RA) that is sent. Section 5.3.1 contains additional considerations on RAs sent on the local link of the MS. Narayanan & Dondeti Expires September 9, 2006 [Page 13] Internet-Draft NetMob March 2006 The MS will autoconfigure an IP address from the advertised prefixes using standard IPv6 stateless autoconfiguration. The MPA may learn of the MS's IP address via mechanisms described in Section 5.1.1 above. 5.2. Mobile Station Operation The MS is not required to support any specific changes in order to support this protocol. The described NetMob protocol handles local mobility in the NETLMM domain in a manner that is transparent to the MS. The MPA performing the location updates on behalf of the MS, however, needs to learn the IP address of the MS when the MS associates with it (or when the MS is about to associate with it). This document does not mandate a method by which the MPA may learn the IP address of the MS. The MPA may learn the IP address of the MS at the time of association via L2 mechanisms. Alternately, the MS may send a message to the MPA containing its IP address. The definition or use of such a message is outside the scope of this document. The MPA may also learn about the MS upon receiving the first data packet from it. The last approach, of course, has the disadvantage that until the MS sends a data packet, any CN sending packets to the MS will be unable to reach it. 5.3. Mobility Proxy Agent Operation 5.3.1. Advertising Prefixes and Sending Router Advertisements The MPA is responsible for sending NLUs for any MS that is associated with it and has an IP address belonging to any of the global prefixes advertised by the MPA. The MPA MUST only advertise global prefixes belonging to one or more LMAs in the domain. The MPA MUST NOT advertise any global prefix on its own. If the MPA is serving as a DHCP Relay for MSs that request IP addresses via DHCP, it MUST request an IP address for the MS from one of the global prefixes it advertises. The same global prefixes MUST NOT be advertised by more than one LMA in a given NETLMM domain. This does not address any redundancy configurations that may be present in the domain. The MPA may learn about the global prefixes it is allowed to advertise either dynamically or via static configuration. The method of learning those prefixes itself is outside the scope of this document. The LMA may be serving IPv4 and/or IPv6 subnets/prefixes. The MPA and LMA MUST support IPv6 transport in order to support the NetMob protocol outlined in this document. An MS cannot distinguish between an MPA and a non-MPA router Narayanan & Dondeti Expires September 9, 2006 [Page 14] Internet-Draft NetMob March 2006 advertising prefixes. Thus, if non-MPA routers advertise prefixes other than those supported by an LMA, MSs may configure an IP address that no MPA would register with an LMA and as a result NetMob services will be unavailable to the MS. Furthermore, even if non-MPA routers advertise prefixes supported by an LMA, an MS associating with such routers will not have NetMob services. In order to avoid this, non-MPA routers MUST NOT advertise prefixes other than those supported by an LMA; non-MPA routers MUST NOT allow host associations. 5.3.2. Sending NetMob Location Updates An MPA, when it learns about an MS with an IP address belonging to one of the subnets or global prefixes served by one of the LMAs in the domain and advertised by itself, MUST send a NetMob Location Update (NLU) message to the LMA. If it learns of an MS with an IP address that does not belong to a global prefix advertised by the MPA, it MUST NOT create an NLU message for that MS. If the MPA is registering an IPv6 RHoA, the NLU MUST contain Home Address Destination Option as defined in [3] containing the RHoA of the MS. If the MPA is registering an IPv4 RHoA, the NLU MUST contain the IPv4 Home Address Destination Option as defined in Section 4.4. Separate NLUs SHOULD be used to register an IPv4 and an IPv6 RHoA of a dual-stacked MS. If the MPA expects to receive an acknowledgement from the LMA about the receipt and processed status of the NLU, it MUST set the 'A' bit in the NLU to 1. If the source address of the NLU is not the address the MPA wishes to use as the LoA to receive traffic sent to the MS, it MUST include its preferred LoA in the Alternate Care-of-address Mobility Option defined in [3]. If the MPA needs a reverse tunnel [5] to be set up between itself and the LMA, it MUST set the 'R' flag to indicate that. The reverse tunnel allows data from the MS to be routed through the LMA to other destinations. Without a reverse tunnel, the MPA may directly route the data to its destination. The 'R' flag SHOULD be set to 0 to indicate no reverse tunneling. If the MS moved to the MPA from a previous MPA under the same LMA, the MPA MAY set the 'M' bit in the NLU to request multiple bindings for the RHoA of the MS, at the LMA. This may be needed to satisfy certain make-before-break scenarios for latency sensitive applications. The mechanism by which an MPA learns about the old MPA of the MS is outside the scope of this specification. If the 'M' bit is set in the NLU, the MPA MAY include the Multiple Bindings Mobility Option in the NLU. When the Multiple Bindings Mobility Option is present in the NLU, the 'D' bit must be set depending on whether the MPA requires the LMA to send duplicate data for the MS to both the Narayanan & Dondeti Expires September 9, 2006 [Page 15] Internet-Draft NetMob March 2006 old and new MPAs or not. The MPA MUST set the 'D' bit to 1 to indicate that the LMA must duplicate the data on all the local addresses bound to the RHoA of the MS. The MPA MUST set the 'D' bit to 0 to indicate that the LMA only needs to send subsequent data destined to the MS to the new LoA of the MS. The MPA SHOULD also set the desired lifetime value in the 'Lifetime' field of the Multiple Bindings Mobility Option. This value of the lifetime indicates the duration for which the MPA is requesting the old binding to be kept active at the LMA. Note that this is different from the lifetime value in the NLU message itself - the lifetime in the NLU is the lifetime for which the MPA requests the LMA to keep the new RHoA-LoA binding alive, while the lifetime in the Multiple Bindings Mobility Option is the duration for which the MPA requests the LMA to keep the previous LoA active for the RHoA. The MPA MAY set this 'Lifetime' field to 0, in which case, the lifetime for multiple bindings at the LMA will default to 3 seconds. The MPA MAY send an NLU with the 'M' bit set without the Multiple Bindings Mobility Option to request the LMA to continue to accept packets coming from the MS via the old LoA without duplicating packets sent to the MS to the old LoA. In this case, the lifetime of the multiple bindings will default to 3 seconds. In order to request multiple bindings with a lifetime greater than 3 seconds in this case, the MPA MUST include the Multiple Bindings Mobility Option with the 'D' bit set to 0 and the 'lifetime' set to the desired value. Modification and replay attacks of NetMob messages is a concern. NetMob assumes the presence of an IPsec SA between the LMA and MPA. A transport mode ESP SA with NULL encryption, and HMAC-SHA-1-96 for integrity protection, and replay protection turned on, MUST be used to protect NLUs and NLAs. MPAs and LMAs MUST accept ESP encapsualted NLUs and NLAs only using policy control (for example using IPsec SPD with source address and the TBD MH types for NLAs and NLUs at the MPAs and LMAs, respectively). See [6]. The MPA MUST encapsulate NLUs with the ESP SA it shares with the destination LMA. If the MPA sets the 'A' bit to 1 in the NLU and it did not receive an NLA within Initial_NLA_Timeout, it SHOULD retransmit the NLU with a new sequence number to the LMA. Retransmissions MUST be exponentially rate limited by doubling the timeout interval upon every retransmission. The maximum number of retransmissions SHOULD be limited to 3. 5.3.3. Receiving NetMob Location Acknowledgements The MPA MUST discard any messages of MH type MH_NLA_IANA_TBD that are not ESP encapsulated. After decapsulation, integrity and replay Narayanan & Dondeti Expires September 9, 2006 [Page 16] Internet-Draft NetMob March 2006 verification, the MPA MUST verify the source address of the received NLA against the source address in the corresponding IPsec SPD entry. If any of the verifications fail, the MPA MUST silently discard the NLA. The MPA MUST verify that the sequence number of the NLA matches the sequence number for an outstanding NLU sent for this RHoA; if the sequence numbers do not match, the MPA MUST silently discard the packet. When the MPA receives an NLA in response to an NLU, it MUST check the value in the Code field to determine whether the NLU was successfully processed at the LMA and if the binding was successfully created for the RHoA of the MS. A value of 0 in the Code field implies success. The value of the Lifetime field in the NLA MUST be recorded as the lifetime of the RHoA-LoA binding. If the R bit was set in the NLA, the MPA MUST use a reverse tunnel to the LMA for the RHoA corresponding to the binding. If the value of the Code field is greater than 128, indicating an error, the MPA SHOULD process the error code as explained in section Section 5.3.4 below. 5.3.4. Error Processing If the MPA received an NLA with a status code greater than 128, it SHOULD determine the error from the value of the error code. If the code was set to "IP_ADDR_REQD", the MPA SHOULD send another NLU, including either the Home Address Destination Option or IPv4 Home Address Destination Option specifying the IPv6 or IPv4 RHoA of the MS. If the MPA received an NLA with the code "DUP_ADDR", the MPA MUST NOT provide NetMob services for the MS that owns the corresponding RHoA. If the MPA received an NLA with the code "REVERSE_TUNNEL_SETUP_FAILED", it MAY send another NLU for the same RHoA with the R bit set to 0. 5.4. Local Mobility Agent Operation 5.4.1. Receiving NetMob Location Updates and Sending NetMob Location Acknowledgements The LMA MUST discard any messages of MH type MH_NLU_IANA_TBD that are not ESP encapsulated. After decapsulation, integrity and replay verification, the LMA MUST verify the source address of the received NLU against the source address in the corresponding IPsec SPD entry. If any of the verifications fail, the LMA MUST discard the NLU. Narayanan & Dondeti Expires September 9, 2006 [Page 17] Internet-Draft NetMob March 2006 The NLU MUST contain either the Home Address Destination Option or the IPv4 Home Address Destination Option. If neither of these options are present in the NLU, it MUST return an NLA with the code "IP_ADDR_REQD". If both these options are present, it SHOULD ignore the second option and only process the first attached option. If no binding exists for the RHoA specified in the NLU and the RHoA is an IPv6 address, the LMA MUST perform a proxy duplicate address detection (DAD) on the local link for the RHoA. If DAD for the RHoA succeeds, it MUST proceed with processing the NLU and create a binding between the RHoA and the LoA specified in the NLU. If DAD for the RHoA fails, the LMA MUST return an NLA with the code "DUP_ADDR". If the R bit is set in the NLU, the LMA MUST set up a reverse tunnel for the binding. If the reverse tunneling set up failed at the LMA, it MUST return an NLA with the code "REVERSE_TUNNEL_SETUP_FAILED". If a binding was successfully created for an IPv6 RHoA, the LMA MUST perform proxy NDP to defend the IP address and attract packets sent to the RHoA to itself. If a binding was successfully created for an IPv4 RHoA, the LMA MUST perform proxy ARP to defend the IP address and attract packets sent to the RHoA to itself. If a binding already exists for the RHoA specified in the NLU, the LMA MUST check to see if the 'M' bit in the NLU is set. If the 'M' bit is set, the LMA MUST add the LoA to the existing binding for the RHoA. Further, if the 'M' bit is set, the LMA MUST check to see if the Multiple Bindings Mobility Option is present in the NLU. If present, the value of the lifetime field in the option SHOULD be noted as the remaining lifetime of the corresponding old LoA-RHoA binding. Also, if the 'D' bit is set in the Multiple Bindings Mobility Option, the LMA SHOULD set up packet duplication for all LoAs corresponding to the RHoA. If the Multiple Bindings Mobility Option is not present in the NLU, or if the lifetime value in the Multiple Bindings Mobility Option is zero, the remaining lifetime of the corresponding old LoA-RHoA binding MUST be set to the default of 3 seconds. If no binding exists for the RHoA specified in the NLU, the LMA MUST ignore the value of the M bit and create a new binding for the RHoA. In this case, the LMA MUST also ignore the Multiple Bindings Mobility Option, if present. The LMA SHOULD always send an NLA in response to an NLU. Further, if the 'A' bit was set to 1 in the NLU, the LMA MUST send an NLA corresponding to the NLU. The sequence number in the NLA MUST be copied from that in the NLU. If the NLU was successfully processed, Narayanan & Dondeti Expires September 9, 2006 [Page 18] Internet-Draft NetMob March 2006 the Code value in the NLA MUST be set to 0. If the LMA local policy mandates the use of reverse tunnels, the LMA MUST set the R bit in the NLA to 1 to instruct the MPA to use a reverse tunnel for the RHoA. The LMA MUST encapsulate NLAs with the ESP SA it shares with the destination MPA. 6. Security Considerations We discuss the various threats to the NetMob entities and the protocol in the following and summarize additional assumptions for the correct operation of the protocol. 6.1. NETMOB threats, mitigation mechanisms and strategies NetMob provides seamless mobility management by LMAs and MPAs without the involvement of MSs. The NetMob architecture consists of the following entities: MSs, BSs, MPAs and LMAs. The BS is responsible for L2 access, and the MPA is responsible for initiating a tunnel with the relevant LMA so packets from CNs to an MS are tunneled by the LMA to the MPA with which the MS is currently associated with. Optionally, a reverse tunnel may be set up in order for packets from the MS to be sent via the LMA. The NetMob protocol itself is used to establish a forward, and optionally a reverse, between an MPA and an LMA, for each MS associated with the MPA. The MPA sends an NLU for any MS that has has an IP address belonging to any of the global prefixes advertised by the MPA (the prefix itself belongs to an LMA in the domain). The LMA accepts all well-formed NLUs, after verifying whether the MS is using a unique IP address within the NETLMM domain and sends an NLA. It then proceeds to replace the old MPA-MS binding with the new one, or if the M bit is set in new NLU, the old binding is kept alive for a short duration (see Section Section 5.4.1 for full details). 6.1.1. Attacks on NLUs and NLAs Threat: NLUs and NLAs may be modified or replayed by an attacker. Furthermore, bogus NLUs and NLAs may be introduced by an attacker. An attacker may introduce send bogus NLUs or NLAs or modify or replay legitimate NLUs or NLAs to disrupt service. These attacks result in creation of half-open tunnels either at MPAs or LMAs. In case of legitimate MSs, a legitimate NLU may eventually be sent by an MPA to the LMA. However, it is plausible for an attacker to delete or Narayanan & Dondeti Expires September 9, 2006 [Page 19] Internet-Draft NetMob March 2006 modify those NLUs to continue disruption of service. There is no real mitigation strategy against deleting NLU or NLA messages, but modification and replay attacks on NLUs and NLAs, and introduction of bogus messages can be detected and prevented by authentication and replay protection of NLU and NLA messages between each MPA and LMA. Note further that within the NETLMM domain it is plausible for an observer to gather information about MS-MPA bindings even if NLUs and NLAs are encrypted, and thus confidentiality of those messages is not essential. This is because the traffic between the LMAs and MPAs and furthermore the traffic between the MPAs and the BSs may not be encrypted. Furthermore, entities within the NETLMM domain may also be able to determine MS to MPA bindings by observing L2 headers. 6.1.1.1. Integrity and replay protection of NetMob messages NetMob messages, NLUs and NLAs, MUST be integrity protected using IPsec ESP with NULL encryption and HMAC-SHA-1-96. Replay protection MUST be supported. Each LMA establishes an IPsec ESP SA with each associated MPA. We observe that a per-MS security association is not required to protect NetMob messages as there is no added value for the additional complexity. LMAs only accept ESP protected NLUs and MPAs only ESP protected NLAs. LMAs MUST NOT accept non ESP protected NLUs and MPAs MUST NOT accept non ESP protected NLAs. When an LMA receives an ESP encapsulated NLU, it verifies the integrity checksum and whether the packet is a replay. It then proceeds to verify the source address of the NLU against the expected source address as per the IPsec security policy database (SPD). The ESP SA lookup is itself based on the SPI in the received packet and subsequent policy verification is against the contents of the SPD. If any of the verifications fail, the NLU MUST be dropped. Similar to the LMA operation, when an MPA receives an ESP encapsulated NLA, it verifies the integrity checksum and whether the packet is a replay. If then proceeds to verify the source address of the NLA against the source address in the SPD of the ESP SA. If any verifications fail, the NLA MUST be silently dropped. 6.1.2. Attacks by MPAs: MPAs are trusted entities Threat: An MPA may send a bogus NLU to an LMA requesting a tunnel to be setup for any MS. However, it would still be plausible for an authenticated MPA to send bogus NLUs. While certain mitigation strategies may be enacted to Narayanan & Dondeti Expires September 9, 2006 [Page 20] Internet-Draft NetMob March 2006 detect and perhaps delete SAs corresponding to misbehaving MPAs, it is simpler to assume that in the NetMob architecture, the MPAs are trusted to send legitimate NLUs and accept well-formed NLAs. 6.1.3. Attacks by MSs 6.1.3.1. Assumptions We assume that L2 access authentication is mandatory for all NetMob hosts. Specifically, the BS MUST enforce access control by requiring an SA to be setup between the BS and the MS. Generally, confidentiality is not required, but most L2 technologies support confidentiality. In the absence of confidentiality protection, NetMob hosts can monitor each other's L3 traffic and movements rather easily. This facilitates attacks such as address stealing discussed later in this section. Note that even with confidentiality protection, L2 traffic can be monitored and hosts may be able to observe each other's movements and thus location privacy from other NetMob hosts is hard to achieve. 6.1.3.2. Stealing IP addresses by MSs Protection of NLUs and NLAs with ESP does not prevent an MS from claiming an IP address (RHoA) that does not belong to it as its own IP address. This is due to the fact that the SA used to protect the NLU and NLA do not correspond to the RHoA of the MS. However, it is not unreasonable to expect the network to have other means of verifying the IP address of the MS when supporting a network controlled mobility management protocol. In the following, we provide a few pointers to mitigate the risk of an MS stealing an IP address belonging to another node. 6.1.3.2.1. IP Address Validation at the MPA For statically assigned IP addresses, the MPA may maintain a MAC-IP address mapping and ensure that the MAC address used by the MS corresponds to the respective IP address in its list. Of course, this still has the vulnerability that an MS could spoof both the MAC address and the IP address. When the IP address is assigned via DHCP, the MPA may serve as the DHCP Relay. The MPA may use DHCP authentication with the DHCP server in this case and make a note of the IP address assigned by the DHCP Server to the MS. In this case, NetMob services must only be provided to that IP address corresponding to the MS. When the MS configures an IPv6 address via stateless Narayanan & Dondeti Expires September 9, 2006 [Page 21] Internet-Draft NetMob March 2006 autoconfiguration, the MPA SHOULD use SEND to verify the IP address, prior to providing NetMob services to the MS. Finally, note that the LMA also verifies duplicate use of IPv6 addresses by running IPv6 DAD protocol. 6.2. Per-MS security associations at MPAs and LMAs are not required It is interesting to note that per-MS SAs at MPAs and LMAs are not required. First, either with a per-MS SA or a single SA between an MPA and an LMA, attacks by external entities are mitigated. Notice further that the only threat that remains is that of an MPA sending bogus requests. Since the MS is not to be involved in the NetMob protocol, the LMA is the only entity that can detect and deal with a duplicate NLU for a given MS if an MPA is indeed misbehaving. AAA servers which might help establish per-MS SAs cannot detect whether a given MS is in fact associated with an MPA that asks for the MS's key. This is due to the fact that an access authentication and MS- AAA interaction may not always be necessary each time an MS associates with a new BS and a MPA. 7. IANA Considerations This document will register with the IANA the protocol parameters set out in Section 4; details of these registrations will appear in a later version of the draft. 8. Acknowledgments The authors would like to thank Ted Hardie, Jun Wang, AC Mahendran, Raymond Hsu, Gavin Horn, Pete Barany and others in Qualcomm for their reviews and comments on this document. 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Narayanan & Dondeti Expires September 9, 2006 [Page 22] Internet-Draft NetMob March 2006 [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [6] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 9.2. Informative References [8] Kempf, J., "Requirements and Gap Analysis for IP Local Mobility", draft-ietf-netlmm-nohost-req-00 (work in progress), February 2006. [9] Kempf, J., "Problem Statement for IP Local Mobility", draft-ietf-netlmm-nohost-ps-00 (work in progress), February 2006. Narayanan & Dondeti Expires September 9, 2006 [Page 23] Internet-Draft NetMob March 2006 Authors' Addresses Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Narayanan & Dondeti Expires September 9, 2006 [Page 24] Internet-Draft NetMob March 2006 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan & Dondeti Expires September 9, 2006 [Page 25]