idnits 2.17.1 draft-forsberg-seamoby-aaa-relocate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 194: '...ew access router SHOULD send a CT-Rep-...' RFC 2119 keyword, line 231: '...essage, the Nrtr SHOULD send a Context...' RFC 2119 keyword, line 235: '...n the event of an error, the MN SHOULD...' RFC 2119 keyword, line 376: '...message. The MN SHOULD be prepared to...' RFC 2119 keyword, line 407: '...ion error. In this case the MN SHOULD...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-12 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-02) exists of draft-koodli-mobileip-fastv6-01 -- Possible downref: Normative reference to a draft: ref. '6' -- Unexpected draft version: The latest known version of draft-koodli-mobileip-smoothv6 is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-04) exists of draft-koodli-seamoby-ct-03 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Seamoby Working Group Dan Forsberg 2 INTERNET DRAFT Rajeev Koodli 3 22 Feb 2002 Charles E. Perkins 4 Communication Systems Laboratory 5 Nokia Research Center 7 Context Relocation of AAA Parameters in IP Networks 8 draft-forsberg-seamoby-aaa-relocate-00.txt 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 This memo provides information for the Internet community. This 31 memo does not specify an Internet standard of any kind. Distribution 32 of this memo is unlimited. 34 Abstract 36 Network access authentication and authorization is used for 37 providing unabused access to users and for billing and accounting 38 purposes. AAA has been proposed as an infrastructure that could 39 provide such support. With AAA, an access router can be configured 40 with packet filtering rules to allow controlled access. However, in 41 a wireless network, a user's Mobile Node may change its access router 42 multiple times due to user mobility. Thus, packet filtering state 43 needs to be re-established at every access router the MN visits. An 44 efficient way to re-establish the access network policy enforcement 45 in the access routers is needed to reduce the AAA signaling in the 46 network and in the access link. This document provides a mechanism 47 based on context transfer to accomplish this ``seamless'' network 48 access during handovers. 50 Contents 52 Status of This Memo i 54 Abstract i 56 1. Introduction 2 58 2. Terminology 2 60 3. AAA Network Access Control State 3 62 4. Protocol Overview 4 64 5. AAA Context Transfer with Handover signaling 4 66 6. Message Formats 5 67 6.1. AAA Context Transfer Request ICMP Option . . . . . . . . 6 69 7. AAA Context Transfer Reply ICMP Option 6 70 7.1. AAA Context Transfer Request CTIN Suboption . . . . . . . 8 71 7.2. AAA Context Transfer CTIN-Ack Suboption . . . . . . . . . 8 72 7.3. AAA Acknowledgment Code Format . . . . . . . . . . . . . 8 74 8. Configurable Parameters 9 76 9. Security Considerations 9 78 10. IANA Considerations 9 80 11. Acknowledgments 9 82 Addresses 11 83 1. Introduction 85 Wireless access network providers need a way to authenticate 86 and authorize users for billing and accounting purposes. The AAA 87 infrastructure provides this kind of service for the provider in the 88 core network. For example, packet filtering can be used to block 89 access to the local network from unauthorized users. An access 90 network usually contains multiple access routers that route IP 91 packets to and from a user's Mobile Node (MN). During handover from 92 one access router to another, this packet filtering state needs to be 93 re-established in the new access router. 95 The AAA infrastructure is used to authenticate and authorize the 96 user for IP session(s), typically for a certain duration, called 97 session lifetime. The session controls packet filtering and thus a 98 user's access to the network. A user's mobile node may change the 99 access router many times during a single session. Thus, there needs 100 to be an efficient way to re-establish the packet filtering state in 101 the new access router without the need for elaborate signaling over 102 the AAA infrastructure. One possible way to avoid this signaling 103 is to use context transfers between the access routers to transfer 104 the required network access control state from the old router to the 105 new router and thus rebuild the packet filtering rules in the new 106 router for the user. Other possibility could be to consult the local 107 AAA agent about the user's AAA status. This requires additional 108 signaling compared to the context transfer and could slow down the 109 handover process. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 115 "silently ignore" in this document are to be interpreted as described 116 in RFC 2119 [3]. 118 We define the following terms for use in this document. 120 HAck Message The ICMP Handover Acknowledgment message, sent from 121 the New Router to the Previous Router, and defined 122 in [6]. 124 HI Message The ICMP Handover Initiate message, sent from the 125 Previous Router to the New Router, and defined in [6]. 127 New Router (Nrtr) The router to which the MN attaches after 128 handover 130 Previous Router (Prtr) The MN's default router prior to handover 131 New access address (Naddr) The access IP address of the Mobile 132 Node (MN) when attached to the link served by the New 133 Router 135 Previous access address (Paddr) The access IP Address of the 136 Mobile Node (MN) when attached to the link served by the 137 Previous Router 139 CTIN-Ack Message Any IPv6 message received by the mobile node 140 containing the CTIN-Ack Destination Option defined 141 in [8]. 143 CTIN Message Any IPv6 message sent by the mobile node containing 144 the CTIN Destination Option defined in [8]. 146 CT-Rep Message The Context Transfer Reply message, sent between 147 access routers, and defined in [8]. 149 CT-Req Message The Context Transfer Request message, sent between 150 access routers, and defined in [8]. 152 Network Access Identifier (NAI) The Network Access Identifier, 153 or NAI [1], is used in the Diameter protocol to extract 154 a user's identity and realm. The identity is used 155 to identify the user during authentication and/or 156 authorization, while the realm is used for message 157 routing purposes. 159 3. AAA Network Access Control State 161 In AAA infrastructure, the NAI is used as the user's identity 162 for network access. Sessions are identified with Session-Ids, 163 which are bound to the NAI and thus for a specific user. Each 164 session has a certain lifetime and state that depends on the result 165 code that the AAA infrastructure provides. In the first phase, 166 when the user requests network access, the state is STATE_PENDING. 167 STATE_OPEN is reached when the AAA infrastructure has successfully 168 authenticated and authorized the user's NAI. In STATE_OPEN the 169 access network uses a mechanism to identify packets to and from the 170 user's mobile terminal and filters out unauthorized packets. A 171 binding and identification between IP packets and the user's AAA 172 session is required for proper network access control. One possible 173 way to do this is to bind the session to the mobile terminal's 174 IP address(es) in the access network and use packet filtering 175 based on the(se) address(es). This document doesn't address the 176 issues with address spoofing. When a session is closed, the AAA 177 state becomes STATE_DISCON and packet filtering rules are updated. 178 Re-authentication can be used to increase the session lifetime. 180 In the rest of this document we simply call the state necessary 181 for network access ``AAA context'' or ``AAA state''. 183 4. Protocol Overview 185 When a suitable trigger arrives, the MN's previous access router 186 transfers the AAA access control state to the MN's new access router. 187 The examples of suitable triggers include an explicit message from 188 the MN, a message from a trusted network entity controlling handover, 189 a link layer indication about the MN's movement etc. The Prtr uses 190 the Context Transfer Reply (CT-Rep) message to include the AAA state 191 and send it to the new access router. The Nrtr, upon verifying the 192 security association with the sender (i.e., Prtr), installs the 193 received AAA context and allows the MN's packets to pass through. 194 The new access router SHOULD send a CT-Rep-Ack message back to the 195 previous access router containing the status of AAA context transfer. 197 When the MN attaches to the Nrtr, it does not engage in additional 198 AAA protocol exchanges. However, there might be a need to update 199 AAA entities in the backbone about the MN's current location. For 200 instance, the AAA agent in the MN's home domain (AAAH) may need to 201 be informed if the MN changes the local domain AAA agent (AAAL). For 202 this, there are two options, both of which are beyond the scope of 203 this document. First, the MN re-authenticates itself after handover. 204 Second, the Nrtr informs AAAL about the MN's new location. In 205 either case, it is imperative that the access router belonging to a 206 different AAA agent ensure the MN is properly authenticated. In any 207 case, a protocol such as Candidate Access Router discovery [9] may 208 be useful in such inter-domain handovers. 210 5. AAA Context Transfer with Handover signaling 212 In this section, we provide an illustration of how the AAA state 213 can be transferred along-with handover signaling between the access 214 routers. The AAA state contains variables that together form the 215 transferred context. There are two handover scenarios; first, the 216 Prtr transfers AAA context prior to the MN's attachment to the 217 Nrtr, and second, the transfer takes place subsequent to the MN's 218 attachment to Nrtr. 220 In the ``fast handover'' scenario, the previous router, 221 in response to either the network-initiated handover or the 222 mobile-initiated handover, includes the AAA context in a Predictive 223 Context Transfer (PCT) message. The trigger to the Prtr is sent in 224 the form of a Context Transfer Initiate (CTIN) message. A PCT is a 225 general-purpose message for transferring contexts and can itself be 226 sent using any appropriate handover message, such as a HI message. 228 The Nrtr follows the rules specified in [8] in processing the PCT 229 message, and then installs the AAA context. A successfull activation 230 of the AAA context allows the MN to continue sending its packets. In 231 response to the PCT message, the Nrtr SHOULD send a Context Transfer 232 Reply Acknowledgment (CT-Rep-Ack) message back to the Prtr. When 233 there is an error, the new access router sends a notification message 234 (CTIN-AcK) to the MN in which it includes the reason for unsuccessful 235 AAA context activation. In the event of an error, the MN SHOULD 236 re-initiate AAA signaling. 238 When predictive context transfer is either unavailable or fails, 239 the Nrtr fetches context subsequent to the MN's attachment to it. 240 In this ``basic handover'' scenario, the MN sends a CTIN message 241 containing its Previous IP address and Previous Router address to 242 the New Router as part of Neighbor Discovery or as an option in the 243 network access authentication message [2]. In response to the CTIN 244 message, recognizing that the required state is not available, the 245 Nrtr transmits a Context Transfer Request (CT-Req) message with AAA 246 sub option. And, the Prtr responds back with a Context Transfer 247 Reply (CT-Rep) message containing the actual AAA context information. 248 See [8] for the details. 250 Observe that always including the CTIN message with the AAA 251 suboption makes the operation robust. When the AAA context is 252 already present, the Nrtr would immediately allow the MN to send its 253 packets. When it is not available, for instance due to fast handover 254 protocol failure or simply due to unfavorable physical conditions, 255 the CTIN message with AAA suboption serves as a trigger to initiate 256 context transfer. 258 6. Message Formats 260 AAA options and suboptions are defined for use in several 261 different protocol message types: 263 1. as an option or a sub option to a HI, HAck, CT-Req, or CT-Rep 264 ICMPv6 messages. 266 2. as a suboption of an IPv6 destination option. 268 3. as an extension to a Mobile IPv4 registration request to be 269 processed by a Foreign Agent. 271 4. as an extension to some other seamless handover message to be 272 defined in the future for mobile nodes using IPv4. 274 The general format for the options is the same in all cases, as 275 shown in Figure 1. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | AAAOpt Type | AAAOpt Len | AAAOpt Data... 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: AAA Options, Suboptions and Extension Format 285 6.1. AAA Context Transfer Request ICMP Option 287 The AAAReq suboption is sent by Nrtr to Previous Router in the 288 CT-Req message to obtain AAA context on behalf of the mobile node. 290 1. Suboption Type: AAAReq-ICMP 292 2. Suboption Length: 0 294 Source address The IP address of the New Router 296 Destination Address The IP address of the Previous 297 Router 299 7. AAA Context Transfer Reply ICMP Option 301 The AAA Context Transfer Reply suboption (AAARep) is defined for 302 Prtr to transfer state to Nrtr in the HI or CT-Rep ICMP messages. 303 The AAARep suboption includes the necessary state for Nrtr to 304 seamlessly carry-over authentication and authorization state. 306 Ctxt Type An integer set to indicate AAA context 308 Ctxt Length Length of AAA context in 8 octets 310 AAA Context Profile Type 311 An IANA object that uniquely identifies the 312 type of AAA context present 314 Lifetime Remaining authorization lifetime in seconds 315 of the AAA session if in STATE_OPEN. 316 Remaining disconnect timeout in seconds if in 317 STATE_DISCON. Remaining authorization pending 318 lifetime in seconds if in STATE_PENDING. 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Ctxt Type | Ctxt Length | AAA Context Profile Type | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Lifetime | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | State | NAI len | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Session-Id len | NAI data... 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 ... 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Session-Id data... 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 2: AAA Reply Data Element 337 State State of the session: STATE_OPEN (1), 338 STATE_DISCON (2), STATE_PENDING (3), 339 STATE_IDLE (0). 341 STATE_OPEN denotes that the session is 342 authenticated. STATE_PENDING means that 343 the authentication process is pending. In 344 STATE_DISCON state the session is about to 345 expire. 347 NAI len NAI length in bytes. 349 Session-Id len 350 Session-Id length in bytes. 352 NAI data Network Access Identifier (NAI) [1]. 354 Session-Id data 355 Session-Id has the same format as the 356 Session-Id AVP data [4]. 358 If the Lifetime is zero, it indicates that Prtr cannot supply the 359 required client AAA context to Nrtr. 361 7.1. AAA Context Transfer Request CTIN Suboption 363 When the mobile node wishes to continue the same AAA session at 364 Nrtr, it sends the AAA Context Transfer Request (AAAReq) suboption in 365 a message addressed to Nrtr containing a CTIN Destination Option. 367 1. Suboption Type: AAAReq-CTIN 369 2. Suboption Length: 0 371 7.2. AAA Context Transfer CTIN-Ack Suboption 373 The AAA Context Transfer Acknowledge suboption (AAAAck) is defined 374 for inclusion in the CTIN-Ack IPv6 Destination Option, and is used 375 by Nrtr to respond to the mobile node. Note that CTIN-Ack is an 376 optional message. The MN SHOULD be prepared to accept packets 377 treated with feature contexts even when it does not receive a 378 CTIN-Ack message. 380 1. Suboption Type: AAAAck-CTIN-Ack 382 2. Suboption Length: 1 384 The AAAAck-CTIN-Ack message has a AAAAck Response Code. The 385 format is shown in Figure below. 387 7.3. AAA Acknowledgment Code Format 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 | AAAAck Code | 392 +-+-+-+-+-+-+-+-+ 394 Figure 3: AAA Context Transfer CTIN-Ack 395 Suboption (AAAAck) format 397 In this section, we define the various result codes sent back to 398 the MN in response to its request for AAA context transfer. 400 1. Code: 00 (AAA_CT_SUCCESSFUL) 401 This reply code denotes successful AAA context transfer and AAA 402 session state construction. 404 1. Code: 02 (AAA_CT_ERROR) 406 This reply code denotes AAA context transfer failure and/or 407 AAA session state construction error. In this case the MN SHOULD 408 reinitiate AAA signaling for network access. 410 8. Configurable Parameters 412 Every access router supporting the mobility extensions defined 413 in this document SHOULD be able to configure each parameter in 414 the following table. Each table entry contains the name of the 415 parameter, the default value, and the section of the document in 416 which the parameter first appears. 418 Parameter Name Default Value 419 ------------------- ---------------------- 420 AAA_CONTEXT_SAVE_TIME2 * CT-Req_REXMIT_TIME 421 AAA_CONTEXT_PURGE_TIME5 * CT-Req_REXMIT_TIME 422 CTIN_WAIT_TIME 1000 milliseconds 424 9. Security Considerations 426 All context transfer for AAA MUST be secured by use of the 427 Authentication suboption [7], or the IPv6 Authentication Header [5]. 428 Thus, no additional vulnerability has been introduced. 430 10. IANA Considerations 432 The AAA Profile Type described in this document needs IANA type 433 number assignment. 435 11. Acknowledgments 437 Stefano Faccin provided valuable feedback and input to this 438 document. 440 References 442 [1] B. Aboba and M. Beadles. The Network Access Identifier (work 443 in progress). Internet Draft, Internet Engineering Task Force, 444 November 1998. 446 [2] N. Asokan, P. Flykt, C. Perkins, and T. Eklund. AAA for IPv6 447 Network Access (work in progress). Internet draft, Internet 448 Engineering Task Force, 2001. 450 [3] S. Bradner. Key words for use in RFCs to Indicate Requirement 451 Levels. Request for Comments (Best Current Practice) 2119, 452 Internet Engineering Task Force, March 1997. 454 [4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER 455 Base Protocol (work in progress). Internet Draft, Internet 456 Engineering Task Force. 457 draft-calhoun-diameter-12.txt, December 1999. 459 [5] S. Kent and R. Atkinson. IP Authentication Header. Request for 460 Comments (Proposed Standard) 2402, Internet Engineering Task 461 Force, November 1998. 463 [6] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in 464 progress). Internet Draft, Internet Engineering Task Force. 465 draft-koodli-mobileip-fastv6-01.txt, October 2000. 467 [7] R. Koodli and C. Perkins. A Framework for Smooth Handovers 468 with Mobile IPv6 (work in progress). Internet Draft, Internet 469 Engineering Task Force. 470 draft-koodli-mobileip-smoothv6-01.txt, November 2000. 472 [8] R. Koodli and C. Perkins. A Context Transfer Framework for 473 Seamless Mobility (work in progress). Internet Draft, Internet 474 Engineering Task Force. 475 draft-koodli-seamoby-ct-03.txt, July 2001. 477 [9] D. Trossen and et al. Issues in candidate access router 478 discovery for seamless IP-level handoffs (work in progress). 479 Internet Draft, Internet Engineering Task Force, January 2002. 481 Addresses 483 Questions about this memo can also be directed to the authors: 485 Dan Forsberg 486 Communications Systems Lab 487 Nokia Research Center 488 Itamerenkatu 11-13 489 00180 HELSINKI 490 Finland 491 Phone: +358-50 483-9470 492 Fax: +358 718-036-227 494 Rajeev Koodli 495 Communications Systems Lab 496 Nokia Research Center 497 313 Fairchild Drive 498 Mountain View, California 94043 499 USA 500 Phone: +1-650 625-2359 501 EMail: rajeev.koodli@nokia.com 502 Fax: +1 650 625-2502 504 Charles Perkins 505 Communications Systems Lab 506 Nokia Research Center 507 313 Fairchild Drive 508 Mountain View, California 94043 509 USA 510 Phone: +1-650 625-2986 511 EMail: charliep@iprg.nokia.com 512 Fax: +1 650 625-2502