Seamoby Working Group Dan Forsberg INTERNET DRAFT Rajeev Koodli 22 Feb 2002 Charles E. Perkins Communication Systems Laboratory Nokia Research Center Context Relocation of AAA Parameters in IP Networks draft-forsberg-seamoby-aaa-relocate-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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract Network access authentication and authorization is used for providing unabused access to users and for billing and accounting purposes. AAA has been proposed as an infrastructure that could provide such support. With AAA, an access router can be configured with packet filtering rules to allow controlled access. However, in a wireless network, a user's Mobile Node may change its access router multiple times due to user mobility. Thus, packet filtering state needs to be re-established at every access router the MN visits. An efficient way to re-establish the access network policy enforcement in the access routers is needed to reduce the AAA signaling in the network and in the access link. This document provides a mechanism based on context transfer to accomplish this ``seamless'' network access during handovers. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page i] Internet Draft AAA Context relocate 22 Feb 2002 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 2 3. AAA Network Access Control State 3 4. Protocol Overview 4 5. AAA Context Transfer with Handover signaling 4 6. Message Formats 5 6.1. AAA Context Transfer Request ICMP Option . . . . . . . . 6 7. AAA Context Transfer Reply ICMP Option 6 7.1. AAA Context Transfer Request CTIN Suboption . . . . . . . 8 7.2. AAA Context Transfer CTIN-Ack Suboption . . . . . . . . . 8 7.3. AAA Acknowledgment Code Format . . . . . . . . . . . . . 8 8. Configurable Parameters 9 9. Security Considerations 9 10. IANA Considerations 9 11. Acknowledgments 9 Addresses 11 Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 1] Internet Draft AAA Context relocate 22 Feb 2002 1. Introduction Wireless access network providers need a way to authenticate and authorize users for billing and accounting purposes. The AAA infrastructure provides this kind of service for the provider in the core network. For example, packet filtering can be used to block access to the local network from unauthorized users. An access network usually contains multiple access routers that route IP packets to and from a user's Mobile Node (MN). During handover from one access router to another, this packet filtering state needs to be re-established in the new access router. The AAA infrastructure is used to authenticate and authorize the user for IP session(s), typically for a certain duration, called session lifetime. The session controls packet filtering and thus a user's access to the network. A user's mobile node may change the access router many times during a single session. Thus, there needs to be an efficient way to re-establish the packet filtering state in the new access router without the need for elaborate signaling over the AAA infrastructure. One possible way to avoid this signaling is to use context transfers between the access routers to transfer the required network access control state from the old router to the new router and thus rebuild the packet filtering rules in the new router for the user. Other possibility could be to consult the local AAA agent about the user's AAA status. This requires additional signaling compared to the context transfer and could slow down the handover process. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119 [3]. We define the following terms for use in this document. HAck Message The ICMP Handover Acknowledgment message, sent from the New Router to the Previous Router, and defined in [6]. HI Message The ICMP Handover Initiate message, sent from the Previous Router to the New Router, and defined in [6]. New Router (Nrtr) The router to which the MN attaches after handover Previous Router (Prtr) The MN's default router prior to handover Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 2] Internet Draft AAA Context relocate 22 Feb 2002 New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router CTIN-Ack Message Any IPv6 message received by the mobile node containing the CTIN-Ack Destination Option defined in [8]. CTIN Message Any IPv6 message sent by the mobile node containing the CTIN Destination Option defined in [8]. CT-Rep Message The Context Transfer Reply message, sent between access routers, and defined in [8]. CT-Req Message The Context Transfer Request message, sent between access routers, and defined in [8]. Network Access Identifier (NAI) The Network Access Identifier, or NAI [1], is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization, while the realm is used for message routing purposes. 3. AAA Network Access Control State In AAA infrastructure, the NAI is used as the user's identity for network access. Sessions are identified with Session-Ids, which are bound to the NAI and thus for a specific user. Each session has a certain lifetime and state that depends on the result code that the AAA infrastructure provides. In the first phase, when the user requests network access, the state is STATE_PENDING. STATE_OPEN is reached when the AAA infrastructure has successfully authenticated and authorized the user's NAI. In STATE_OPEN the access network uses a mechanism to identify packets to and from the user's mobile terminal and filters out unauthorized packets. A binding and identification between IP packets and the user's AAA session is required for proper network access control. One possible way to do this is to bind the session to the mobile terminal's IP address(es) in the access network and use packet filtering based on the(se) address(es). This document doesn't address the issues with address spoofing. When a session is closed, the AAA state becomes STATE_DISCON and packet filtering rules are updated. Re-authentication can be used to increase the session lifetime. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 3] Internet Draft AAA Context relocate 22 Feb 2002 In the rest of this document we simply call the state necessary for network access ``AAA context'' or ``AAA state''. 4. Protocol Overview When a suitable trigger arrives, the MN's previous access router transfers the AAA access control state to the MN's new access router. The examples of suitable triggers include an explicit message from the MN, a message from a trusted network entity controlling handover, a link layer indication about the MN's movement etc. The Prtr uses the Context Transfer Reply (CT-Rep) message to include the AAA state and send it to the new access router. The Nrtr, upon verifying the security association with the sender (i.e., Prtr), installs the received AAA context and allows the MN's packets to pass through. The new access router SHOULD send a CT-Rep-Ack message back to the previous access router containing the status of AAA context transfer. When the MN attaches to the Nrtr, it does not engage in additional AAA protocol exchanges. However, there might be a need to update AAA entities in the backbone about the MN's current location. For instance, the AAA agent in the MN's home domain (AAAH) may need to be informed if the MN changes the local domain AAA agent (AAAL). For this, there are two options, both of which are beyond the scope of this document. First, the MN re-authenticates itself after handover. Second, the Nrtr informs AAAL about the MN's new location. In either case, it is imperative that the access router belonging to a different AAA agent ensure the MN is properly authenticated. In any case, a protocol such as Candidate Access Router discovery [9] may be useful in such inter-domain handovers. 5. AAA Context Transfer with Handover signaling In this section, we provide an illustration of how the AAA state can be transferred along-with handover signaling between the access routers. The AAA state contains variables that together form the transferred context. There are two handover scenarios; first, the Prtr transfers AAA context prior to the MN's attachment to the Nrtr, and second, the transfer takes place subsequent to the MN's attachment to Nrtr. In the ``fast handover'' scenario, the previous router, in response to either the network-initiated handover or the mobile-initiated handover, includes the AAA context in a Predictive Context Transfer (PCT) message. The trigger to the Prtr is sent in the form of a Context Transfer Initiate (CTIN) message. A PCT is a general-purpose message for transferring contexts and can itself be sent using any appropriate handover message, such as a HI message. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 4] Internet Draft AAA Context relocate 22 Feb 2002 The Nrtr follows the rules specified in [8] in processing the PCT message, and then installs the AAA context. A successfull activation of the AAA context allows the MN to continue sending its packets. In response to the PCT message, the Nrtr SHOULD send a Context Transfer Reply Acknowledgment (CT-Rep-Ack) message back to the Prtr. When there is an error, the new access router sends a notification message (CTIN-AcK) to the MN in which it includes the reason for unsuccessful AAA context activation. In the event of an error, the MN SHOULD re-initiate AAA signaling. When predictive context transfer is either unavailable or fails, the Nrtr fetches context subsequent to the MN's attachment to it. In this ``basic handover'' scenario, the MN sends a CTIN message containing its Previous IP address and Previous Router address to the New Router as part of Neighbor Discovery or as an option in the network access authentication message [2]. In response to the CTIN message, recognizing that the required state is not available, the Nrtr transmits a Context Transfer Request (CT-Req) message with AAA sub option. And, the Prtr responds back with a Context Transfer Reply (CT-Rep) message containing the actual AAA context information. See [8] for the details. Observe that always including the CTIN message with the AAA suboption makes the operation robust. When the AAA context is already present, the Nrtr would immediately allow the MN to send its packets. When it is not available, for instance due to fast handover protocol failure or simply due to unfavorable physical conditions, the CTIN message with AAA suboption serves as a trigger to initiate context transfer. 6. Message Formats AAA options and suboptions are defined for use in several different protocol message types: 1. as an option or a sub option to a HI, HAck, CT-Req, or CT-Rep ICMPv6 messages. 2. as a suboption of an IPv6 destination option. 3. as an extension to a Mobile IPv4 registration request to be processed by a Foreign Agent. 4. as an extension to some other seamless handover message to be defined in the future for mobile nodes using IPv4. The general format for the options is the same in all cases, as shown in Figure 1. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 5] Internet Draft AAA Context relocate 22 Feb 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AAAOpt Type | AAAOpt Len | AAAOpt Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: AAA Options, Suboptions and Extension Format 6.1. AAA Context Transfer Request ICMP Option The AAAReq suboption is sent by Nrtr to Previous Router in the CT-Req message to obtain AAA context on behalf of the mobile node. 1. Suboption Type: AAAReq-ICMP 2. Suboption Length: 0 Source address The IP address of the New Router Destination Address The IP address of the Previous Router 7. AAA Context Transfer Reply ICMP Option The AAA Context Transfer Reply suboption (AAARep) is defined for Prtr to transfer state to Nrtr in the HI or CT-Rep ICMP messages. The AAARep suboption includes the necessary state for Nrtr to seamlessly carry-over authentication and authorization state. Ctxt Type An integer set to indicate AAA context Ctxt Length Length of AAA context in 8 octets AAA Context Profile Type An IANA object that uniquely identifies the type of AAA context present Lifetime Remaining authorization lifetime in seconds of the AAA session if in STATE_OPEN. Remaining disconnect timeout in seconds if in STATE_DISCON. Remaining authorization pending lifetime in seconds if in STATE_PENDING. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 6] Internet Draft AAA Context relocate 22 Feb 2002 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ctxt Type | Ctxt Length | AAA Context Profile Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | NAI len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Id len | NAI data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Id data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: AAA Reply Data Element State State of the session: STATE_OPEN (1), STATE_DISCON (2), STATE_PENDING (3), STATE_IDLE (0). STATE_OPEN denotes that the session is authenticated. STATE_PENDING means that the authentication process is pending. In STATE_DISCON state the session is about to expire. NAI len NAI length in bytes. Session-Id len Session-Id length in bytes. NAI data Network Access Identifier (NAI) [1]. Session-Id data Session-Id has the same format as the Session-Id AVP data [4]. If the Lifetime is zero, it indicates that Prtr cannot supply the required client AAA context to Nrtr. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 7] Internet Draft AAA Context relocate 22 Feb 2002 7.1. AAA Context Transfer Request CTIN Suboption When the mobile node wishes to continue the same AAA session at Nrtr, it sends the AAA Context Transfer Request (AAAReq) suboption in a message addressed to Nrtr containing a CTIN Destination Option. 1. Suboption Type: AAAReq-CTIN 2. Suboption Length: 0 7.2. AAA Context Transfer CTIN-Ack Suboption The AAA Context Transfer Acknowledge suboption (AAAAck) is defined for inclusion in the CTIN-Ack IPv6 Destination Option, and is used by Nrtr to respond to the mobile node. Note that CTIN-Ack is an optional message. The MN SHOULD be prepared to accept packets treated with feature contexts even when it does not receive a CTIN-Ack message. 1. Suboption Type: AAAAck-CTIN-Ack 2. Suboption Length: 1 The AAAAck-CTIN-Ack message has a AAAAck Response Code. The format is shown in Figure below. 7.3. AAA Acknowledgment Code Format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | AAAAck Code | +-+-+-+-+-+-+-+-+ Figure 3: AAA Context Transfer CTIN-Ack Suboption (AAAAck) format In this section, we define the various result codes sent back to the MN in response to its request for AAA context transfer. 1. Code: 00 (AAA_CT_SUCCESSFUL) Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 8] Internet Draft AAA Context relocate 22 Feb 2002 This reply code denotes successful AAA context transfer and AAA session state construction. 1. Code: 02 (AAA_CT_ERROR) This reply code denotes AAA context transfer failure and/or AAA session state construction error. In this case the MN SHOULD reinitiate AAA signaling for network access. 8. Configurable Parameters Every access router supporting the mobility extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears. Parameter Name Default Value ------------------- ---------------------- AAA_CONTEXT_SAVE_TIME2 * CT-Req_REXMIT_TIME AAA_CONTEXT_PURGE_TIME5 * CT-Req_REXMIT_TIME CTIN_WAIT_TIME 1000 milliseconds 9. Security Considerations All context transfer for AAA MUST be secured by use of the Authentication suboption [7], or the IPv6 Authentication Header [5]. Thus, no additional vulnerability has been introduced. 10. IANA Considerations The AAA Profile Type described in this document needs IANA type number assignment. 11. Acknowledgments Stefano Faccin provided valuable feedback and input to this document. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 9] Internet Draft AAA Context relocate 22 Feb 2002 References [1] B. Aboba and M. Beadles. The Network Access Identifier (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [2] N. Asokan, P. Flykt, C. Perkins, and T. Eklund. AAA for IPv6 Network Access (work in progress). Internet draft, Internet Engineering Task Force, 2001. [3] 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. [4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base Protocol (work in progress). Internet Draft, Internet Engineering Task Force. draft-calhoun-diameter-12.txt, December 1999. [5] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [6] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-fastv6-01.txt, October 2000. [7] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [8] R. Koodli and C. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ct-03.txt, July 2001. [9] D. Trossen and et al. Issues in candidate access router discovery for seamless IP-level handoffs (work in progress). Internet Draft, Internet Engineering Task Force, January 2002. Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 10] Internet Draft AAA Context relocate 22 Feb 2002 Addresses Questions about this memo can also be directed to the authors: Dan Forsberg Communications Systems Lab Nokia Research Center Itamerenkatu 11-13 00180 HELSINKI Finland Phone: +358-50 483-9470 Fax: +358 718-036-227 Rajeev Koodli Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2359 EMail: rajeev.koodli@nokia.com Fax: +1 650 625-2502 Charles Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 11]