--------------D93281A1916BB09071096D6D-- Mobile IP Working Group Rajeev Koodli INTERNET DRAFT Jari T. Malinen 23 April 2001 Communication Systems Laboratory Category: Standards Track Nokia Research Center Idle Mode Handover Support in Mobile IPv6 Networks draft-koodli-idle-mode-ctv6-00.txt Status of This Memo 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. This document is an individual submission for the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS:NORTELNET WORKS:COM mailing list. Distribution of this memo is unlimited. Koodli, Malinen Expires 23 October 2001 [Page i] Internet Draft Idle Mode Handover Support 23 April 2001 Contents Status of This Memo i 1. Introduction 2 2. Terminology 2 3. Reference Scenario 2 4. Idle Handover Considerations 3 5. Protocol Messages 5 5.1. Router Advertisement / AAAv6 local challenge . . . . . . 6 5.2. AAAv6 request . . . . . . . . . . . . . . . . . . . . . . 8 5.3. EAP paging response, and context transfer extensions . . 10 Addresses 13 Koodli, Malinen Expires 23 October 2001 [Page 1] Internet Draft Idle Mode Handover Support 23 April 2001 1. Introduction The purpose of this document is to investigate the problem space in idle mode handover surrounding network access authentication, paging and context transfers. Specifically, we consider the problem of expeditiously enabling an idle Mobile Node to regain authenticated network access. In addition, we also consider the problem of making any feature contexts available to the MN, so that it can resume its sessions in a seamless fashion. We propose a solution using simple extensions to paging messages that would allow us to meet our objectives without the need for any paging server or additional entries in the routing tables. 2. Terminology Mobile Node A host that attaches to a network, untethered or otherwise, and changes its point of attachment due to user mobility. Idle mode A state internal to a Mobile Node in which the MN is not in active packet transmission or reception. This definition assumes that it is possible for a MN to enter idle mode when it has an active traffic channel. Paging A mechanism by which a network locates a MN in idle mode, in order to, e.g., deliver an incoming packet [7]. Authentication The process by which an Access Router (AR) verifies the MN's credentials and grants (authorizes) network access [1]. Context Transfer The process by which state information pertaining to a MN is transferred from one AR to another, perhaps to facilitate seamless operation of applications running on the MN [8]. 3. Reference Scenario When a MN powers up in a visited domain and obtains link connectivity with the network, one of the things that need to happen before it obtains IP connectivity is network layer authentication. This is critical in order to provide unabused network access. The specification in [1] outlines a mechanism based on ICMP protocol which could be used in conjunction with other protocols, such as IPv6 address auto-configuration, and Mobile IPv6, in order to provide this kind of network layer authentication. One of the (successfull) results of this Koodli, Malinen Expires 23 October 2001 [Page 2] Internet Draft Idle Mode Handover Support 23 April 2001 protocol is that it enables a security association between a MN and its default Access Router (AR) and supplies both the entities the necessary security keys. The MN then uses this key in securing its communication whenever necessary with its AR. Once authorized to use the network prefix advertised by the AR, the MN may proceed to send IP packets. For instance, the MN may send a Binding Update to its Home Agent to inform about its new location. Note that for performance reasons, it is possible to combine the network authentication messages with this Binding Update, as proposed in [1]. Here, we assume a logical separation between the two protocols. Nevertheless, the MN may then engage in active packet transmission and reception, or it may remain idle. Observe that the MN may enter idle mode even while engaged in active communication due to the bursty nature of packet data communication. Subsequently, the MN undergoes a handover while in idle mode. The rest of this document is concerned with what transpires due to this idle mode handover. 4. Idle Handover Considerations We begin with a set of assumptions. First, we assume that a paging area consists of multiple ARs each with various subnets corresponding to potentially different access technologies. Each paging area is uniquely identified by an IP multicast group, whose members are the ARs that constitute the paging area. Second, a Mobile Node does not perform paging area registrations when inside the same paging area. The mechanisms by which a MN determines that it is within the boundary of the same paging area are beyond the scope of this document. It may make use of any mechanism; for example, it may make use of the paging area identifier typically advertised on the broadcast channel to determine its location with respect to the paging area. Third, an AR originates an IP paging message when it determines that it cannot deliver an IP packet to its MN. The mechanism by which an AR determines that a MN that was attached to it is no longer visible is not specified in this document. An AR may be able to realize this by, for example, explicit idle mode registrations or (implicitly) via timer expirations. Note that because of this assumption, we see no reason for a specialized paging server in our discourse. Note also that there is no need for additional routing table entries in this model. We consider the two idle mode scenarios outlined earlier. We start with the case where the MN moves without having initiated active data communication. Recall that the MN first establishes network connectivity. This means, at least the state corresponding to security association should be present at both the MN and its default AR. Let's assume that the MN moves to a subnet controlled by a different AR, but within the same Koodli, Malinen Expires 23 October 2001 [Page 3] Internet Draft Idle Mode Handover Support 23 April 2001 paging area. As mentioned earlier, we assume that the MN does not send a paging area registration message if operating within the same paging area. This assumption is necessary since a paging area registration may entitle the MN to IP connectivity, in which case, the routing of IP packets follows normal Mobile IP procedures. Now, if a packet arrives at the previous AR for the MN, the previous AR has to locate the MN in order to deliver the packet. We assume that an IP paging mechanism would be available for this purpose. Whereas the exact form and nature of such a protocol is not standardised yet, we will assume mechanisms outlined in [10], and identify extensions needed. Applying one of the concepts outlined in [10] here, the PAR uses a well-known paging multicast address to send the paging request. All the ARs within the paging area are members of this multicast group, and thus receive the paging request packet. Each AR then sends an unsolicited router advertisement that contains the MN's IP address established while connected to PAR. This message may trigger a Layer 2 (L2) paging on each AR in order to wake up the sleeping MN. The MN, once paged, has to determine that it has changed its AR by verifying the source address in the router advertisement, begin to formulate a new IP address, and then respond to the IP paging request. We identify multiple issues here. Every time an IP page arrives, link-layer paging (in those systems that provide such support) has to wake up all the MNs since the link-layer identity of the MN is not known. Each such MN then has to verify if it is the candidate in question by observing the appropriate field in the router advertisement message. For an already awake MN, this would be a routine router advertisement message, perhaps an extra message considering that normal unsolicited router advertisements are periodically sent. If the link-layer identity is available, it could be supplied in the IP paging message. This identity could be used, at least in a subset of all access networks, to send a link-layer page to only the particular MN in question. An alternative would be to send the router advertisement directly to the sleeping MN. This extension could reduce the amount of traffic generated due to paging. When the MN wakes up and realizes that it has changed its AR, it may be required to perform network access authentication described earlier. This procedure is potentially time-consuming given the delays in accessing the MN's home network AAA and the Home Agent. In order to minimize this delay, it is possible to transfer the key from PAR to all the potential ARs in the IP paging message. Recall that the MN first established authenticated network access with PAR. In the unsolicited router advertisement message that follows the IP paging message, each AR sends a local challenge requiring the MN to send a token that is a hash of network prefix advertised, a random number and the key that the MN possesses. Each AR uses the key supplied in the IP paging message to compute its own hash and allows network access if the token supplied Koodli, Malinen Expires 23 October 2001 [Page 4] Internet Draft Idle Mode Handover Support 23 April 2001 by the MN matches its computation. The MN may use the Embedded Data Option in the AAA request message in [1] to include this token as well as the Binding Update message. A new Local Challenge type allows the AR to determine the scope of the message, so that it does not further propagate the message unless necessary. The concept outlined in the previous paragraph can be extended to handle any generic contexts. Note that the MN may have established contexts at PAR due to active data comunication. These contexts are transferred to all the ARs in the paging area multicast group. In order to authorize the use of these contexts, each AR requires that the MN present a separate token consisting of all the feature context requests. The ``fortunate'' AR serving the MN after paging succeeds computes its own checksum before authorizing the use of transferred contexts. We propose using the SHIN option for this context transfer request. The SHIN message itself, similar to the Binding Update message, is carried as an Embedded Data Option. The new AR verifies that the checksum present in the SHIN matches its own computation and makes the contexts available to the MN. It then generates a SHREQ message to the PAR that originated the IP paging message in order to set up a forwarding path for packets arriving at PAR. The new AR may also include a status flag indicating authorization of contexts to the MN. The PAR may generate a SHREP message indicating the response for the SHREQ message. We mention that optimization is possible in expediting IP connectivity once the MN receives the page, i.e., the router advertisement. Once the MN learns of its new default router, it can send a normal IP packet with a tentative source address by encapsulating it in a new Neighbor Discovery message that indicates to the ND module in the receiver that the MN's IP address is tentative. This normal IP packet could be the AAAv6 packet for network access authentication. The receiver, i.e., the new AR in this case, would first examine if there is already an entry in its neighbor cache corresponding to the MN's tentative IP address. If there is none, the AR would process the rest of the packet, otherwise it behaves as if there was Duplicate Address Detection conflict as outlined in [11]. 5. Protocol Messages This section shows the new protocol messages used as extensions to AAAv6 [2] messages. In most cases, we also outline the ICMPv6 [4] messages contained in previous documents. 5.1. Router Advertisement / AAAv6 local challenge Recall that a paging entity sends a paging message to a multicast group specific for the paging area. This message is then received by access Koodli, Malinen Expires 23 October 2001 [Page 5] Internet Draft Idle Mode Handover Support 23 April 2001 routers in the paging area. A subsequent router advertisement message, described in this section, is sent out by each Access Router. This router advertisement is directed potentially to a group of mobile nodes possibly within reach of the router. The router advertisement as specified by Neighbor Discovery [9] is modified in order to support the extensions we propose here. This router advertisement contains address of the paged mobile node, a ``challenge'' which is a random number, and a sequence number used for associating the reply from the MN. The entire message appears as follows: Koodli, Malinen Expires 23 October 2001 [Page 6] Internet Draft Idle Mode Handover Support 23 April 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Router Advertisement Options | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type | Length | Sequence no | Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Router Advertisement / AAAv6 local challenge {1} IPv6 Header [5] {2} Router Advertisement [5, 6] {3} Router Advertisement Options A paging option contains one or more IP addresses paged. May include Target Link-layer address, Prefix Information Options, etc. {4} AAAv6 Challenge Option in the router advertisement Type 9 = ICMPv6 Router Advertisement Local Challenge Option Length 1 = Length in 8 octets including the type and length fields Koodli, Malinen Expires 23 October 2001 [Page 7] Internet Draft Idle Mode Handover Support 23 April 2001 Sequence Number a monotonically increasing integer that associates the IP address, Challenge and the Key tuple. The MN supplies this value in addition to the hash it generates to aid the AR in verifying the checksum computation. Reserved 0 = Ignored on reception Challenge This is a 32-bit random number generated by the access router and used to prevent replay attacks. 5.2. AAAv6 request This section describes the message the mobile node sends in response to AAAv6 local challenge message. This response includes a token to facilitate expedited network access authentication and also request for context transfer authorization. The message the MN sends is an ICMPv6 message of AAAv6 request type. This AAAv6 message contains one or more Embedded Data Options. Each Embedded Data Option (EDO) may contain sub types of EAP messages. [Note: We use EAP as a means of embedding authentication responses here]. This message contains a hash over mobile node's previous IP address and the challenge sent in the router advertisement. Since the paging message from the paging router to the access routers distributes the key known to the MN and the paging router, this key is now known by the new router which can verify whether the hash received is valid. If not, the packet is dropped and a diagnostics AAAv6 reply is returned. Koodli, Malinen Expires 23 October 2001 [Page 8] Internet Draft Idle Mode Handover Support 23 April 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}|Type=AAAv6req | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type=EDO |Subtype=EAP-res| Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | EAP types for paging, context transfer | | | + + | | Figure 2: AAAv6 request/EAP response/context transfer challenge {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [4] Type 151 (97h) [TBD] = AAAv6 Request Code 0 - For AAA request, not defined Checksum Calculated as defined in [4]. {3} AAAv6 Embedded Data Option [2] Type 8 (unskippable) = Embedded Data Option Koodli, Malinen Expires 23 October 2001 [Page 9] Internet Draft Idle Mode Handover Support 23 April 2001 Subtype 3 = EAP Response Length = Length of Embedded Data in octets. 5.3. EAP paging response, and context transfer extensions In this section, we provide generic EAP type structure to include the paging response for local challenge and to request context transfer support. Note that the request for context transfer can be a separate EDO by itself, in which case it would contain the SHIN message along with the Binding Update message. Here, we include the context transfer request as a part of the EAP type. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| Code |Sequence No | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Paging OR Context Transfer Responses | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: EAP paging or context transfer response Code 2 = Response Sequence Number The Sequence Number (called identifier in RFC 2284) field is one octet and aids in matching responses with requests [3]. This aids the AR in associating the hash (token) with the [IP address, random number, key] tuple it maintains. Koodli, Malinen Expires 23 October 2001 [Page 10] Internet Draft Idle Mode Handover Support 23 April 2001 Length 28 = Length of the whole EAP extension in octets. Type 19, 20 = Types for EAP-paging and EAP-CT respectively. Subtype 1 = Paging-or-CT local challenge response. Version 1 = The EAP protocol version. Reserved This field is set to zero and ignored on reception. Paging OR CT type For paging, contains a hash value using the MN-visited domain session key, taken over the local challenge sent in the paging message (Section 1) from the new acccess router. For context transfer, options such as SHIN or SHACK, passed between mobile node and access router, as a generic way of embedding them to ICMPv6 messages together with authentication-related data. Koodli, Malinen Expires 23 October 2001 [Page 11] Internet Draft Idle Mode Handover Support 23 April 2001 References [1] N. Asokan, P. Flykt, C. Perkins, and T. Eklund. AAA for IPv6 Network Access (work in progress). Internet draft, Internet Engineering Task Force, 2001. [2] 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. [3] L. Blunk and J. Vollbrecht. PPP Extensible Authentication Protocol (EAP). Request for Comments (Proposed Standard) 2284, Internet Engineering Task Force, March 1998. [4] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [7] J. Kempf. Paging Problem Statement(work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-paging-problem-statement-02.txt, February 2001. [8] O. Levkowetz and et al. Problem Description: Reasons For Doing Context Transfers Between Nodes in an IP Access Network (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-context-transfer-problem-stat-00.txt, February 2001. [9] 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. [10] B. Sarikaya, H. Haverinen, J. Malinen, and V. Magret. Mobile IPv6 Regional Paging(work in progress). Internet Draft, Internet Engineering Task Force, November 2000. [11] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Proposed Standard) 1971, Internet Engineering Task Force, August 1996. Koodli, Malinen Expires 23 October 2001 [Page 12] Internet Draft Idle Mode Handover Support 23 April 2001 Addresses Questions about this memo can also be directed to the authors: Rajeev Koodli Jari T. Malinen 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-2359 Phone: +1-650 625-2355 EMail: rajeev.koodli@nokia.com EMail: jmalinen@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Malinen Expires 23 October 2001 [Page 13]