Mobile IP Working Group Jari T. Malinen INTERNET DRAFT Franck Le 2 March 2001 Charles E. Perkins Category: Standards Track Nokia Research Center Mobile IPv6 Regional Registrations draft-malinen-mobileip-regreg6-01.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes Mobile IPv6 regional registration as an optional extension to Mobile IPv6. Regional registration introduces visited-domain mobility agent functionality for proxying a public care-of-address which remains the same while the mobile node moves in the visited domain. This reduces the binding update signaling latency for the mobile node and signaling load outside the visited domain. The protocol defines regional mobility capability negotiation, regional binding update signaling, and regional-aware data routing through a hierarchy of visited-domain mobility agents. The protocol allows for an arbitrary point in the visited-domain hierarchy to distribute the connection-state maintenance between several mobility agents. IPSec AH is used for securing the protocol as in basic Mobile IPv6. Malinen, Le, Perkins Expires 2 November 2001 [Page 1] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 Contents Status of This Memo 1 Abstract 1 1. Introduction 3 2. Terms 4 3. Protocol Operation Overview 5 3.1. Movement to a new Link . . . . . . . . . . . . . . . . . 7 3.2. Visited-domain capability discovery . . . . . . . . . . . 8 3.3. Regional Registrations signaling . . . . . . . . . . . . 8 3.4. Regional-Aware Data Routing . . . . . . . . . . . . . . . 10 4. Protocol Extensions 11 4.1. Router Advertisement modifications . . . . . . . . . . . 12 4.2. Regional CoA Extension . . . . . . . . . . . . . . . . . 12 4.3. Regional Binding Update . . . . . . . . . . . . . . . . . 14 4.4. Previous Access Router Sub-Option . . . . . . . . . . . . 14 5. New requirements for IPv6 Nodes 15 5.1. Visited Domain Router Requirements . . . . . . . . . . . 16 5.2. Mobile Node Requirements . . . . . . . . . . . . . . . . 16 6. IANA Considerations 16 7. Security Considerations 16 A. Changes to the previous version 18 B. Regional Registrations Security 19 B.1. Trust delegation . . . . . . . . . . . . . . . . . . . . 20 B.2. Key distribution principles . . . . . . . . . . . . . . . 20 B.3. The full per -mobile trust delegation model . . . . . . 21 B.3.1. Regional Registrations Key Distribution . . . . . 21 B.3.2. Anti replay attacks . . . . . . . . . . . . . . . 21 B.3.3. Key Material Destination Option . . . . . . . . . 22 B.4. "trust delegated to edge routers" security model . . . . 23 B.4.1. Security Association Acquisition from AAA . . . . 23 B.4.2. Movement to a new Link . . . . . . . . . . . . . 25 B.4.3. Anti replay attacks . . . . . . . . . . . . . . . 25 B.5. Forwarding Modes and comparison of these different modes from a security point of view . . . . . . . . . . . . . . . 26 Addresses 28 Malinen, Le, Perkins Expires 2 November 2001 [Page 2] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 1. Introduction Mobile IPv6 regional registration reduces the binding update signaling latency and the signaling load for a mobile node moving within the same visited domain. The latency is reduced by localizing binding updates to the visited domain and the signaling load is reduced by using a regional-aware router for a proxy care-of-address, as seen by hosts outside the visited domain. The protocol re-uses the general idea of regional registrations for Mobile IPv4 [3], but is a different IPv6-specific protocol. The regional care-of address can be in an arbitrary node in the visited domain, not just in an edge router or the gateway mobility agent highest in the hierarchy. The selection of a particular regional care-of address is done by the mobile node from a list of addresses advertised by the access router. The regional binding update is transported over an arbitrary-depth tree hierarchy of regional-aware routers up to the closest possible router in the hierarchy. This router is the crossover between the old path from the gateway router to the previous access router and from the gateway router to the new access router. The protocol supports network-controlled selection of the crossover router which hides the inner structure of the hierarchy and enables constant-length signaling independent of the depth of the hierarchy. The regional registration protocol does not require modifications to any network elements other than the mobile node and the regional-aware routers. These modifications are optional additions to basic Mobile IPv6. Non-regional-aware routers, hosts, home agents, and mobile nodes can interoperate with regional-aware entities without change. The added routing state maintenance in the visited domain is minimal. It does not involve the routing tables at all; all per-mobile state is kept in the regional binding cache. This data structure is internal to the regional mobility agent and can re-use the existing binding cache. Security is provided with the same signaling protection extensions as in the basic Mobile IP. However, for an efficient MN-visited domain signaling security, dynamic security association acquisition and usage is discussed Appendix B. A special anycast address represents the visited domain and the visited-domain part of the obtained key material is propagated within the anycast group. Malinen, Le, Perkins Expires 2 November 2001 [Page 3] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 This protocol defines the regional registration signaling for IPv6 and it can be used in combination with other components of the general smooth hand-over framework [6] for gaining cost-efficient signaling. In such a combination, the mobile node sends the message over the wireless interface encapsulated with the state transfer SHIN option up to the access router. The encapsulating header may carry e.g. buffering [7] or header compression [5] state transfer signaling needed for smooth and efficient handovers. 2. Terms 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 [2]. In addition, this document uses the following terms: Access Router The closest router to the mobile node in the visited domain that the mobile node uses to access the network. Crossover Router When a mobile node is performing a regional registration, the Crossover Router is the router where the old path leading to a mobile node and the new path cross, i.e. the regional router in the hierarchy where a connection state change is needed to maintain an up-to-date communication path to the mobile node. Gateway Mobility Agent The software module implementing regional registrations in the gateway router. Gateway Router A router controlling the regional care-of-address of a mobile node which may be located anywhere in the physical hierarchy. Highest Router Router used in a visited domain as the root of a physical hierarchy; The visible hierarchy for a mobile node is thus rooted at the gateway router possibly below the highest router. Home Binding The binding cache entry in a home agent used for storing home registration state. Malinen, Le, Perkins Expires 2 November 2001 [Page 4] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 Home Registration Sending a binding update to the home agent to create a home binding. Regional-aware Router Router that supports regional registrations. Regional Binding Cache A conceptual data structure in regional-aware routers; it is keyed on the home address of a mobile node and contains the care-of-address, lifetime, flags, security association, and network interface as data elements. All regional routing state is contained in this entry. Regional Care-of-address A care-of-address, as seen from outside the visited domain, used to locate a mobile node. Remains the same while the mobile node does regional binding updates within a visited domain. Regional Mobility Agent The software module implementing regional registrations in a regional-aware router. Visited Domain A domain that is visited by the mobile node; a set of subnets usually administered by one entity. In this document, all routers in a visited domain are assumed to have a security association with one another. This terminology is intended to conform to those that have been used in Mobile IP and other Internet protocols. Basic Mobile IPv6 terminology is used as defined in [4]. 3. Protocol Operation Overview A foreign domain advertises its capability for regional registrations with a newly defined router advertisement flag. When entering a visited domain for the first time, the mobile node registers with its home domain. During or after this registration, the mobile node can perform a regional registration. A regional registration establishes a regional care-of-address that is seen from outside the visited domain as the mobile node's primary care-of-address. This address is controlled by one of the visited-domain routers and the mobile node obtains the address from a list of Regional CoA extensions (Section 4.2), attached to the router advertisement. Malinen, Le, Perkins Expires 2 November 2001 [Page 5] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 ________ +------------+ / \ +--------------------+ | Home Agent |------( Internet )----| Corresponding node | +------------+ \________/ +--------------------+ | | regional \ | care-of-address + +------------------------+ | | Gateway Mobility Agent | | | (GMA) | | +------------------------+ | / \ | 1./ \ | / \ | +------------------+ +--------+ | | Crossover Router | | Router | | +------------------+ +--------+ \ / \ \ Visited 1./ \ 2. / Domain / \ / +----------+ +--------+ | | Previous | | New | | | Access | | Access | | | Router | | Router | | +----------+ +--------+ | ^ ^ | |1. |2. | | | | +-+ +-+ (on-link) primary | | | ---> | | care-of-address | +-+ +-+ + Mobile Mobile / Node Node Figure 1: Hierarchy of regional-aware routers After obtaining a regional care-of-address, the mobile node stores the current visited domain identity, and sends binding updates to its home agent and corresponding nodes. The mobile node uses the regional care-of-address as the alternate care-of-address when sending basic Mobile IPv6 binding updates to nodes outside the visited domain. Malinen, Le, Perkins Expires 2 November 2001 [Page 6] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 While staying within the visited domain, the mobile node MAY send regional binding updates for the duration of its home binding. The mobile node may also send ordinary binding updates to the home agent or to corresponding nodes at any time. Figure 1 illustrates a typical regional registration scenario. The mobile node sends a regional binding update to the crossover router which updates its connection state from the old path to the new path. The gateway router is the crossover router during the first regional registration (signal 1). After this (signal 2), the crossover may exist lower in the hierarchy. The regional binding update is a modified Binding Update destination option. It updates the regional binding cache entries of a mobile node in regional-aware router hierarchy. The binding update also enables the visited domain to decide the crossover router. The mobile node attaches additional information to this binding update such that a regional-aware router can decide from it whether it is a crossover router. The regional binding cache is used for regional data routing, forwarding of encapsulated or source-routed Mobile IPv6 data packets to the mobile node. The binding cache entries are deleted by timeout or by de-registration. The semantics of this is identical to that in basic Mobile IPv6. 3.1. Movement to a new Link When entering a new foreign link, with the same or another visited domain, the mobile node performs movement detection and uses router discovery to discover new routers as defined in Mobile IPv6. The mobile node may also receive a handover indication from the link layer and consequently send a router solicitation. Similarly, the mobile node may receive an unsolicited router advertisement containing the indication that handover is imminent. The mobile node also performs visited domain detection as an additional part of the movement detection of basic Mobile IPv6. The mobile node uses as visited domain identity a ``visited domain routers'' anycast address. This is derived from the selected regional care-of-address in the router advertisement option (Section 4.1) and used for detecting movement to a new visited domain. This identity MUST be unique. The anycast address is formed from the prefix in the regional care-of-address extension and a host number 0 (TBD). The prefix can e.g. be shorter than the actual prefix of the regional care-of-address in the gateway router. Such a shorter prefix can Malinen, Le, Perkins Expires 2 November 2001 [Page 7] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 thus contain many regional care-of-addresses in the same visited domain. When the mobile node changes its regional care-of-address, or when the selected regional care-of-address is not in the router advertisement of the new access router, the mobile node SHOULD behave as if it arrived to a new visited domain. This avoids the situation where the crossover router would be beyond the GMA in the hierarchy. The mobile node then selects its primary care-of-address, which is on the same link as is the access router, as defined in Mobile IPv6. The address is co-located to the mobile node together with its routing identity, its home address, and used as the target for local communication between the visited domain and the mobile node. The mobile node MAY also use this address as the care-of-address in its binding updates for corresponding nodes within the visited domain. 3.2. Visited-domain capability discovery The router advertisement from a regional-aware router contains flags to indicate the supported capabilities. The supported capability flag for regional registrations is the `I' bit in the Reserved1 field of the Mobile IPv6 Modified Router Advertisement Message's Modified Prefix Information Option [4]. If the `I' bit is set, the mobile node SHOULD make use of regional registration. In this case, the mobile node selects its regional care-of-address from the one or more regional care-of-address extensions in the router advertisement. 3.3. Regional Registrations signaling When entering the visited domain, the mobile node performs a home registration in combination with the first regional binding update. The regional binding update MAY be an outer encapsulator around the home registration binding update. The regional binding update is a modified Mobile IPv6 binding update destination option. It propagates upwards hop-by-hop through a hierarchy of regional-aware routers to a router controlling the selected regional care-of-address. There may be regional-unaware routers between adjacent regional-aware routers in a hierarchy. The regional care-of-address can be an address of the visited domain router or an address from a pool of regional care-of-addresses controlled by a router. Association between such a care-of-address Malinen, Le, Perkins Expires 2 November 2001 [Page 8] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 and a router within the visited domain, selected as target of the first regional binding update, is implementation-specific. The destination address in the IP header of the regional binding update at the sending mobile node is the ``visited domain routers'' anycast address. It MAY also be the IP address of the access router. A packet sent to this address is first received by the regional-aware access router. There MUST be a home address destination option in the IPv6 packet carrying the regional binding update as with basic Mobile IPv6. The regional binding update is then propagated to the next-higher regional-aware router by encapsulation. The encapsulating header around the regional binding update or around the returned binding acknowledgement MAY carry key material within the anycast group as described in Appendix B. When the regional binding update is re-sent from the receiving router up to the next higher router, each regional-aware router establishes or updates its regional binding cache entry for the mobile node. The key to the entry is the home address, and the care-of-address is the source address of the regional binding update received from the next lower regional-aware router. In the access router, the care-of-address is the sending link address of the mobile node. Implementation of the regional binding cache can reuse the basic Mobile IPv6 binding cache entry with a new `I' flag set. Since the network controls the crossover router selection, the responding visited domain target router is not known to the mobile node. It sends the packet to the anycast address or the unicast address of the router. The packet is received by the router from which the mobile node received the router advertisement. The regional care-of-address MUST be inserted as a alternate care-of-address sub-option of the regional binding update. The `A' bit MUST be set and the `H' bit MUST NOT be set. The mobile node appends the previous access router sub-option (Section 4.4) to the regional binding update. This sub-option identifies the previous access router so that each router can locally decide whether it is the crossover router. When the signal is propagated upwards, the first router that has the previous access router among its descendants is the crossover router. When this sub-option is absent, the regional binding update propagates up to the gateway mobility agent. To know its descendants, a regional-aware router maintains a list of all of its descendants. How this list is configured is out of the scope of this protocol; it can be statically configured from a parameter file, for example. Alternatively, a mobile router can set the 'R' bit in the regional binding update to join the hierarchy as a leaf router. Then, a descendant list entry is established with a Malinen, Le, Perkins Expires 2 November 2001 [Page 9] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 lifetime, and the mobile router marks the upper regional router as a father router. After a successful regional binding update, a basic Mobile IPv6 binding acknowledgement is returned to the mobile node back through the hierarchy. In case of signaling where anycast address is used all the way through the hierarchy, a binding acknowledgement SHOULD be sent to the MN and to the anycast address. A successful regional registration is denoted by a new success status value 1. This denotes regional-aware success; status value 0 denotes regional-unaware success. In the latter case, the receiving node accepted the binding update as any corresponding node would. The mobile node can thus send regional binding updates to any node and recognize regional-awareness of the other end from this status value. This gives the protocol robustness against mis-configured regional-aware routers. The mobile node SHOULD NOT send binding updates with the regional care-of-address to regular nodes until it has received the regional-aware success status value 1. If the regional-aware router fails to accept the regional registration, it returns a Reason Unspecified status value 128 in the binding acknowledgement. However, if the mobile node does not receive status value 1 from the gateway mobility agent, the mobile node MUST re-send a binding updates with the primary care-of-address. A regional-aware mobile node MAY support mobile multi-homing, i.e. the mobile node MAY register more than one home address simultaneously with one or more home agents. Operation of these addresses occur independently, i.e. as if there were multiple mobile nodes within the same physical host. The mobile node MUST NOT register more than one care-of-address for each home address. If regional-aware propagation uses unicast addresses, the regional binding update is re-generated in each intermediate router. If the first target is anycast address, the propagation MAY change into unicast-based inside visited domain or it MAY remain anycast-based. A discussion on differencies with these modes is in Appendix B 3.4. Regional-Aware Data Routing Since the regional care-of-address is in the visited domain, packets targeted to it go through the regional-aware routing hierarchy from the GMA towards the mobile node. The other direction is not affected by regional registrations. When a corresponding node sends data packets to a mobile node to which it does not yet have an entry in its binding cache, these Malinen, Le, Perkins Expires 2 November 2001 [Page 10] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 packets are intercepted by the home agent and encapsulated to the registered care-of-address mobile node, as specified in the basic Mobile IPv6. However, this care-of-address is the regional care-of-address. For tunneled packets, the regional care-of-address of the mobile node is selected as the target for the outer encapsulation header. The router which controls that regional care-of-address decapsulates the tunneled packets. The destination of the encapsulated packet is the home address of the mobile node. If there is an entry in the regional binding cache for this home address, the router SHOULD re-encapsulate these packets to the corresponding lower care-of-address. This is in the next lower regional-aware router or in the mobile node if the forwarder is the access router. Thus, the data packets SHOULD get re-capsulated at each regional-aware router on their way down the hierarchy. If the lower regional-aware router is at link-distance from the forwarding regional-aware router, or a routing protocol maintains host-based routes between regional-aware routers, the router MAY forward these packets simply by using host-based routes. The forwarding MAY also use other methods such that the packet propagation occurs as with the above methods. A method of forwarding is local to a router in a way that multiple methods of forwarding can be used in a visited domain without a negotiation mechanism. 4. Protocol Extensions The following protocol extensions are defined: - A modification to the Modified Router Advertisement Message to indicate whether the visited domain supports regional registrations (the `I' bit) (Section 4.1). - A regional care-of-address extension to the router advertisement (Section 4.2). - A modification to the Binding Update destination option to indicate whether the option is a Regional Binding Update (the `I' bit) (Section 4.3). - An previous access router sub-option for the binding update (Section 4.4). Malinen, Le, Perkins Expires 2 November 2001 [Page 11] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 4.1. Router Advertisement modifications The router advertisement, as defined in the basic Mobile IPv6, contains additionally the `I' bit and the visited domain identity in the Modified Prefix Information Option of the Router Advertisement Message. The format of the new Modified Prefix Information Option is the following: 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 | Prefix Length |L|A|R|I|Rsrvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Modified Prefix Information Option I Indicates regional registrations support. The Rsvrd1 field is here a 4-bit field instead of the 5 bits Reserved1 prior to adding the `I' bit. Other fields are as described in the Mobile IPv6 and the Neighbor Discovery [8] documents. 4.2. Regional CoA Extension The router advertisement may contain one or more visited-domain care-of-addresses from which the mobile node chooses a regional care-of-address. Each such address is advertised in a Regional CoA Extension of the modified Router Advertisement. The format of the regional CoA extension is the following : Malinen, Le, Perkins Expires 2 November 2001 [Page 12] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 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 | Prefix Length | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Regional Care-of-Addresses | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Regional CoA extension Type 6, TBD (skippable) Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. This field MUST be 3. Lifetime The time the advertised CoA is valid in the visited domain. Prefix Length An 8 bit unsigned integer. This denotes prefix length of the ``visited domain routers'' anycast address where the prefix is taken from the regional care-of-address and the host number is 0 (TBD). One of these options MUST identify the visited domain. Prefix length fields in the other regional CoA options in the same router advertisement MUST be zero. Index Index describing which of the global prefixes can be used with this address. 1 denotes the first prefix in the advertisement. Special value 0 denotes that this address applies to all prefixes. The options SHOULD be ordered so that regional CoA extensions associated with a given prefix are immediately after that prefix. Regional Care-of-Address The advertised address, which MUST be a global IPv6 address from the visited domain. Malinen, Le, Perkins Expires 2 November 2001 [Page 13] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 4.3. Regional Binding Update The Regional Binding Update is a Mobile IP Binding Update with the following modifications. In the Reserved field after the flags field, there will be the following additional bit. Description of extensions to the BU option: I Indicates regional registrations support. This implies that the receiving router will use the BU information to establish or maintain a regional binding cache entry. The bit is the first bit from the Reserved field of the Mobile IPv6 Binding Update destination option. Previous Access Router Sub-Option A sub-option for determining the crossover router. 4.4. Previous Access Router Sub-Option The previous access router sub-option is used by the network to determine the crossover router. A crossover router address is obtained from the IP header source address of the router advertisement. The mobile node remembers this for the previous router and uses it to create an previous access router sub-option. 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 | PathId | PathCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Previous access router | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Previous Access Router Sub-option Malinen, Le, Perkins Expires 2 November 2001 [Page 14] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 Type 5, TBD (skippable) Length 8-bit unsigned integer. The length of the sub-option (including the type and length fields) in units of 8 octets. PathId 8-bit unsigned integer. This optional field identifies a route for one mobile node with multiple routes within a visited domain from the edge router to GMA.ix from the PathCount 8-bit unsigned integer. Identifies the number of path branches on the path of a regional binding update. This optional field is also used for multiple routes support. A crossover functionality can e.g. propagate regional binding updates to the GMA if the PathCount is greater than one. Previous access router The IP address of the previous access router as seen by the mobile node. There is no requirement for alignment of the Previous Access Router sub-option. The previous access router sub-option is valid in the Binding Update destination option. The previous access router contains the IPv6 address of the access router as seen by the mobile node. It is used to identify the crossover router in the visited domain regional router graph. This is done by comparing the previous access router to the known descendants when the regional binding update gets forwarded upward in the tree of regional-aware routers. When the router finds the previous access router in its list of descendants, it is the crossover router. 5. New requirements for IPv6 Nodes The presented option requires modifications to the visited-domain routers and to the mobile node. The option does pose no new requirements to the home agent, to correspondent nodes, or to other network elements than to the regional-aware routers in the visited domain. Malinen, Le, Perkins Expires 2 November 2001 [Page 15] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 5.1. Visited Domain Router Requirements The support of the protocol is optional to basic Mobile IPv6; elements can function in both regional-aware and regional-unaware visited domains. Introducing regional-aware routers to a visited domain does not mandate the use of regional registrations. The regional-aware access router MUST be capable of advertising regional registration support. The router MUST be capable of maintaining regional binding cache entries based on regional binding updates. These routers MUST route the data packets to the regional-registered mobile nodes so that a mobile node can recognize the use of route optimization from the presence of a routing header, as described in Section 3.4. 5.2. Mobile Node Requirements A regional non-aware mobile node can operate in a regional-aware network. The regional-aware mobile node SHOULD select a regional care-of-address and send a regional binding update accordingly. 6. IANA Considerations The presented protocol does require the addition of one skippable option type to the router advertisement [8] and one skippable sub-option type to the Binding Update destination option. Also, the protocol requires two modifications from the Modified Router Advertisement Message`s Prefix Information Option, one bit in its Reserved1 field, from the format specified in the basic Mobile IPv6 [4]. The protocol also needs one new bit from the Reserved field of the Mobile IPv6 Binding Update option. The Binding Acknowledgement would need one new regional-aware success code, with a proposed value of 1 to be added to the list of known status field values. A host number for the ``visited domain routers'' anycast address would be needed. The value 0 is suggested. 7. Security Considerations The regional-aware mobile node SHOULD use a mobile-visited-domain key for authentication. The IPSec authentication header (AH) is used for security as in basic Mobile IPv6. In regional signaling, the mobile node and visited domain share a security association, in form of a Malinen, Le, Perkins Expires 2 November 2001 [Page 16] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 mobile-visited-domain key for IPSec. The mobile-visited-domain key is obtained when entering the visited domain and transported to the visited domain routers and to the mobile node. The protocol in this document assumes that the routers have a way to authenticate messages based on anycast security associations. The usage of AAAL as a source of unique SPIs among all visited domain routers, as explained in Appendix A, is utilized to enable the use of anycast address -based security association identification. As long as the visited domain anycast address -based SPD entries are not created by means other than specified, this allows for the use of anycast security association in this particular case. A challenge-response -based replay service for aycast in this case is also introduced. Malinen, Le, Perkins Expires 2 November 2001 [Page 17] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 References [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] Eva Gustafsson, A. Jonsson, and C. Perkins. Mobile IP Regional Registration. draft-ietf-mobileip-regtun-03.txt, July 2000. (work in progress). [4] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 2000. [5] R. Koodli, M. Tiwari, and C. Perkins. Header Compression State Relocation in IP Mobile Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-rhoc-hcompr6-00.txt, July 2000. [6] Rajeev Koodli and Charles E. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-02.txt, November 2000. [7] G. Krishnamurthi, R. Chalmers, and C. Perkins. Buffer Management for Smooth Hand-Overs in Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-krishnamurthi-mobileip-ipv6buf-00.txt, July 2000. [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [9] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys for Mobile IP (work in progress). draft-ietf-mobileip-aaa-key-03.txt, September 2000. A. Changes to the previous version This version introduces an anycast address to represent the visited domain as a distributed network endpoint in addition to supporting the unicast-based approach of the previous version. A one message-exchange multi-level signaling is efficient e.g. when the mobile node needs to communicate both with the access router Malinen, Le, Perkins Expires 2 November 2001 [Page 18] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 and the gateway mobility agent (GMA). The other changes address problems mentioned in earlier working group minutes, in security and in providing uniqueness of the visited domain identity. - This version distributes the network endpoint of communication identifying it with an anycast address. A common security association per mobile node can be used in the visited domain when key material received from AAAv6 is propagated to members of the anycast group, as described in Appendix B. This change also preserves the cost-efficiency of having a single message exchange with the deep hierarchy while now providing a fully specified security option. - The regional forwarding now is based on encapsulation or host-based routes. Other methods specified elsewhere may also be used. The earlier regional forwarding of route-optimized packets is now separated into another draft. - The router advertisement now also uniquely identifies the visited domain with the special ``visited domain routers'' anycast address. This address is formed using prefix of the regional care-of-address and a host number 0 (TBD). Thus, no visited domain identifier is used in this version from the prefix information option. The same anycast address is used by the mobile node to send the regional binding update to the distributed endpoint, the destination IP address of the regional binding update. - The unicast address of the advertising router can also be used as a destination of a regional binding update. Internally this means a different propagation of the regional binding update but does not require any extra negotiation between the mobile node and the access router. The mobile node can now send the regional binding update to either to the unicast or to the anycast address. - A security appendix now describes a temporary security association acquisition and propagation mechanisms with alternative regional binding update propagation schemes. These give the visited domain builder several configuration options while remaining transparent to the mobile node. B. Regional Registrations Security Mobile IPv6 Regional Registrations signaling is secured using Authentication Header using binding updates as with Mobile IPv6 home registration binding updates. However, since the communicating parties in sending regional binding updates are the mobile node Malinen, Le, Perkins Expires 2 November 2001 [Page 19] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 and regional routers, a static security association can not be assumed between mobile node and each visited domain in a scalable solution. Regional registrations security considers scalable acquisition of the needed security association(s) and their use with Authenitcation Header -based security. This document specifies mechanisms and extensions to the Mobile IP Binding Update, and binding acknowledgements messages that can be used to distribute such security information to the mobile node and visited domain. B.1. Trust delegation A mobile-visited domain security association can be obtained in a multiple ways, depending on availability of mechansims and policy requirements of the visited domain. The visited domain can also provide open access. A regional-aware visited domain can view trust delegation in two distinct ways. A full per-mobile trust delegation from an authorization center provides trust from a key distribution center in form of per-mobile session key material to every regional-aware router which participates to regional signaling. This can be used when propagating a regional binding update unmodified to the crossover router. A model with trust propagated to the edge routers of a visited domain can be used with a policy where the more static intra-visited-domain security associations are used for protecting the propagated regional binding update. In this case the regional signals are re-transmitted from intermediate regionals routers using new authentication header. A benefit is that the visited domain does not need to have per-mobile security associations in all routers making the visited domain more scalable for a very large number of mobile nodes. B.2. Key distribution principles Security credentials for mobile-visited domain security associations can be obtained in a multiple ways. One way is to assume an AAA-based key distribution and use mechanisms like AAA registration keys for Mobile IP [9]. The latter provides two key distribution schemes for getting temporary session keys for the mobile node and a router. If trust is delegated to the edge routers, and no per-mobile key distribution inside the visited domain is desired, a regional binding update is propagated by recreating it with authentication headers used between adjacent regional routers. The regional binding acknowledgement is then propagated in a similar way back to the edge Malinen, Le, Perkins Expires 2 November 2001 [Page 20] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 router which finally re-sends the binding acknowledgement to the mobile node using the mobile-visited-domain security association. An intra-visited-domain key distribution mechanism may be applied with regional signaling, if full per-mobile trust delegation is desired. A regional binding update is propagated with its original authentication header to the crossover router, encapulated with an outer IP header and a key distribution option. The two modes have the same signaling behavior seen from the mobile node. Thus the visited domain administrator can locally configure either of the modes without it being visible to mobile nodes. B.3. The full per -mobile trust delegation model B.3.1. Regional Registrations Key Distribution A regional-aware gateway router with the selected regional care-of-address MAY communicate with the AAAv6 local authority during the first regional binding update into a visited domain, depending on the local requirements for authorizing network access. The visited domain MAY provide temporary access rights for regional registrations while the AAA infrastructure is generating a reply to the authorization request. When the AAA has granted access, the access to the visited domain is decisively granted. AAAv6 is expected to provide temporary key material for the mobile node and the visited domain to be used in subsequent regional authentications. As mentioned previously, many solutions currently exist like AAA registration keys for Mobile IP IP [9]. This material is provided for the mobile node in combination with a Binding Acknowledgement, and also for the visited domain. The latter is then propagated together with regional registration signaling in a key material destination option. This option is inserted to the outer encapsulation header when propagating subsequent regional binding updates or binding acknowledgements inside the visited domain. It can be protected with IPsec using intra-visited-domain security associations. Or as an alternative, the intermediate routers retrieve the user specific session key from the AAA-L which also stores it. B.3.2. Anti replay attacks Anti replay attacks can not be provided by the Sequence number specified in the Authentication Header protocol since this requires Malinen, Le, Perkins Expires 2 November 2001 [Page 21] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 all the intermediate routers to have synchronized counters which is difficult. Instead, nonces SHOULD be used to provide anti replay attacks: The mobile node takes the Local Challenge citedraft-ietf-perkins-aaav6, sent in Router advertisements messages, as an input to the authentication data computation of the regional binding update message. The Local challenge is then included in the Regional Binding Update and the access router first ensures the freshness of the message by verifying that the Local Challenge carried in the Binding Update message is a recent one. This Local Challenge is also encapsulated with the Regional Binding Update message until the cross over router which ensures freshness of the message by verifying that the authentication data takes into account the recent Local Challenge carried in the message. The mobile node SHOULD also generate a Host Challenge that is also included in the Binding Update message as a destination option and encapsulated until the cross over router which tales that Host Challenge as an imput when computing the authentication data of the Binding Acknowledgement message. The Host Challenge is then sent back in the Binding Acknowledgement message and the mobile node can thus verify the freshness of the reply from the access router by making sure the authentication data computationtook this Host Challenge into consideration. B.3.3. Key Material Destination Option This is a possible extension to carry the user specific key between the intermediate routers. The message carrying this extension should be encrypted and intergrity protected by using intra domain security (e.g. IPsec) 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 | Alg | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Key Material Destination Option Malinen, Le, Perkins Expires 2 November 2001 [Page 22] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 Type TBD (skippable), one for key request, one for key reply Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Alg 8-bit algorithm indication as specified for the Authentication Header. Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. SPI 32-bit Security Parameter Index value. Key Encrypted key material of at most 1024 octets. As an alternative, the intermediate routers can retrieve the user specific session key fro the AAA-L: this requires only security associations between intermediate routers and AAA-L whereas the propagation of the user keys requires security associations between all the intermediate routers. B.4. "trust delegated to edge routers" security model This section describes another alternative of a security model where Regional Registration could deployed securely. This solution is more scalable requiring only user specific security association between the MN and the Access routers and then relying on intra domain security to authenticate the regional binding update within the visited domain. B.4.1. Security Association Acquisition from AAA When entering a visited domain, the mobile node performs a home registration in combination with the first regional binding update: The mobile node computes some authentication data (e.g. from a Local challenge sent to the Hosts in Router advertisments messages, from a Home Challenge generated by the Home domain for anti replay attacks [1], and using the Long term key shared between the mobile node and its Home domain), and adds a Regional Registration key request in the regional binding update. The destination address in the IP header of the regional binding update at the sending mobile node is the source address of the router Malinen, Le, Perkins Expires 2 November 2001 [Page 23] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 advertisement containing the selected regional care-of-address or the anycast address identifying the visited domain. The receiving Access Router, due to the presence of the authentication extension, forwards the message to the AAA-L, which invokes the AAA-H for entity authentication: the serving system wants to make sure the user is a valid one before giving him access to its network resources. If the Home agent is in the home network, this AAA invocation to the Home domain may include the Home Binding Update [1] to the Home Agent. If Home agent is dynamically assigned in the home network, AAA-H assigns the Home agent and sends a Binding update to the assigned Home agent. These are possible optimizations to save round trips between the visited and home domain reducing time delay and load over the network. In such cases, the home binding update may indicate the regional care of address as the alternate care-of-address and if regional registration fails (e.g. RcoA is not valid), the mobile node will update the Home agent. Once authentication succeeded, thanks to the keying material, AAA-L can compute a regional registration key K wich is specific to the mobile node. AAA-L sends it to the Access Router with the keying material destined to the mobile node for it to be able to derive K. The access router then sends the Binding Acknowledgement with some extension carrying the keying material to the mobile node which will derive K and create a regional binding update authenticated using K. As another optimization, since in wireless networks, radio resources are limited, the Access router, on receipt of the network access authorization from AAA-L, knows the mobile node is valid and can perform regional registration thus saving one additional round trip over the air interface. The access router sends a new binding update to the next-hop cross over router to create the binding between the mobile node home address and the access router care of address. This binding update is authenticated using a intra domain security association: Access Router and Cross over router share a key which can be set up in different ways and is operator dependant. This key is not user specific. The Cross over router propagates the binding update until the GMA using as previously intra domain security. Thus, only Access routers needs to maintain user specific security asociations which is more scalable than having user specific security associations up to the GMA requiring the GMA to maintain the security associations for all the users it is serving. Malinen, Le, Perkins Expires 2 November 2001 [Page 24] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 B.4.2. Movement to a new Link When entering a new foreign link within the same domain, the mobile node sends a regional binding update authenticated using K. The receiving access router can either retrieves the key from the previous access router indicated by the mobile node or from the AAA-L. The latter option only requires security association between access router and AAA-L whereas the first option also needs security association between Access routers. The access router then verifies the authenticity of the binding update message and if succeeded, it sends binding update messages up to the crossover router using intra domain security. Alternatively, if so wished by trust delegation policy, the binding update can be propagated to the crossover router with the original authentication header, and with an outer encapsulation containing a key material destination option (Section B.3.3) with the distributed key encrypted using intra domain security. Each router decapsulating this option inserts it to its security policy database prior to using it for authenticating the regional binding update. B.4.3. Anti replay attacks Between the mobile node and the access router, since the access router creates the binding acknowledgement message to the mobile node, replay protection can be provided by various methods: Timestamps: The MN and the access router verify the freshness of the messages by making sure that the timestamp used is the current one. Sequence number: Authentication header has a Sequence number to provide anti replay service. This counter is one possibility and in such cases, when mobile node moves to a new link, the new serving access router when retrieving the user specific key K, also needs to retrieve the value of this sequence number from the previous access router. Nonces: The mobile node can take the Local challenge [1] sent in Router Advertisements messages as an input to the AH authentication data of regional binding update messages. The access router ensures freshness of binding update message from the mobile node by verifying that the local challenge included in the Request is a recent one. The mobile also generates a Host Challenge that will be included in the authentication data of the Binding update and binding acknowledgement messages. This way, the host can verify the freshness of the reply from the access router. Malinen, Le, Perkins Expires 2 November 2001 [Page 25] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 B.5. Forwarding Modes and comparison of these different modes from a security point of view First, as described in the security models in the previous section, the Access Router can either re-create new binding update message or encapsulate the mobile node's binding update message to perform regional registration within the visted domain. The trust model is different but in both cases, the MN needs to rely on the intra domain security of the visted domain: Either to re-create binding update message in the "trust delegated to edge routers model" or to distribute the keys to the different intermediate routers in the "full per-mobile trust delagation model". These two models also differ on a scalability point of view: the "trust delegated to edge routers model" only requires user specific security associations between mobile nodes and access routers whereas the "full per-mobile trust delegation model" requires user specific security associations between all the intermediate routers from the Access router serving the MN up to the GMA. This may requires many security associations to be maintained in particularly for the GMA and thus may have some scalability issues. In addition, a visited domain can be administratively configured to different forwarding schemes. The visited domain can forward the regional binding update and acknowledgement by receiving and re-sending them between intermediate regional routers. This can take place when the mobile node initially sends the regional binding update either to the advertising router's unicast or to the anycast address. Also, the regional binding update, sent to the anycast address can be forwarded unmodified to the crossover router. In the case of RBU re-sending, the key distribution principle of delegation to the edge routers is used. This enables two different modes of key propagation where a session key is acquired either from the previous access router or from the AAAL. Session keys are not propagated deeper into the visited domain so the state space for a large number of mobile nodes is smaller than in the full trust delegation mode. Also, network topology is not revealed in this case since the binding acknowledgements seem to come from the edge routers. In the full trust delegation mode we use the anycast-based unmodified RBU forwarding. This provides direct mobile node authentication in the crossover with a fast forwarding of the unmodified RBU. It also results in propagating the key material, either in-line with the key material destination option, or by asking the key from the AAAL in each router. This can be considered inefficient in a large visited Malinen, Le, Perkins Expires 2 November 2001 [Page 26] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 domain. Since the mobile node in this case directly gets replies from crossover routers, the visited domain topology is revealed. Malinen, Le, Perkins Expires 2 November 2001 [Page 27] Internet Draft Mobile IPv6 Regional Registrations 2 March 2001 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Jari T. Malinen Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2355 Phone: +1-650 625-2986 E-mail: jmalinen@iprg.nokia.com E-mail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Malinen, Le, Perkins Expires 2 November 2001 [Page 28]