idnits 2.17.1 draft-chowdhury-mip6-radius-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1019. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (June 23, 2006) is 6514 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 957, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 961, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 965, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-01 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-02 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-06 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-00 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 K. Chowdhury 3 Internet-Draft Starent Networks 4 Expires: December 25, 2006 A. Lior 5 Bridgewater Systems 6 H. Tschofenig 7 Siemens 8 June 23, 2006 10 RADIUS Mobile IPv6 Support 11 draft-chowdhury-mip6-radius-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 25, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 A Mobile IPv6 node requires a home agent address, a home address, and 45 an IPsec security association with its home agent before it can start 46 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 47 these parameters are statically configured. Ongoing work aims to 48 make this information dynamically available to the mobile node. An 49 important aspect of the Mobile IPv6 bootstrapping solution is to 50 support interworking with the existing authentication, authorization 51 and accounting infrastructure. This document defines new attributes 52 that facilitate Mobile IPv6 bootstrapping via a RADIUS 53 infrastructure. This information exchange may take place as part of 54 the initial network access authentication procedure or as part of a 55 separate protocol exchange between the mobile node, the home agent 56 and the AAA infrastructure. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6 64 3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7 65 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9 66 4.1. Home Agent Address Attribute . . . . . . . . . . . . . . . 9 67 4.2. Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 9 68 4.3. Home Link Prefix Attribute . . . . . . . . . . . . . . . . 9 69 4.4. Home Address Attribute . . . . . . . . . . . . . . . . . . 9 70 4.5. DNS Update Mobility Option Attribute . . . . . . . . . . . 9 71 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Home Agent Address Attribute . . . . . . . . . . . . . . . 10 73 5.2. Home Agent FQDN Attribute . . . . . . . . . . . . . . . . 11 74 5.3. Home Link Prefix Attribute . . . . . . . . . . . . . . . . 11 75 5.4. Home Address Attribute . . . . . . . . . . . . . . . . . . 12 76 5.5. DNS Update Mobility Option Attribute . . . . . . . . . . . 13 77 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 15 79 6.1.1. Home Agent allocation in the MSP . . . . . . . . . . . 15 80 6.1.2. Home Agent allocation in the ASP (visited network) . . 16 81 6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 17 82 6.2.1. Mobile Service Provider and Mobile Service 83 Authorizer are the same entity. . . . . . . . . . . . 17 84 6.2.2. Mobile Service Provider and Mobile Service 85 Authorizer are different entities. . . . . . . . . . . 19 86 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 20 87 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 20 88 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 20 89 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 21 90 7.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 21 91 7.5. Provisioning of Configuration Parameters . . . . . . . . . 21 92 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 22 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 Intellectual Property and Copyright Statements . . . . . . . . . . 29 102 1. Introduction 104 The Mobile IPv6 specification [5] requires a Mobile Node (MN) to 105 perform registration with a Home Agent with information about its 106 current point of attachment (Care-of Address). The Home Agent 107 creates and maintains a binding between the MN's Home Address and the 108 MN's Care-of Address. 110 In order to register with a Home Agent, the MN needs to know some 111 information such as the Home Link prefix, the Home Agent Address, the 112 Home Address, the Home Link prefix Length and security related 113 information in order to secure the Binding Update. 115 The aforementioned set of information may be statically provisioned 116 in the MN. However, static provisioning of this information has its 117 drawbacks. It increases provisioning and network maintenance burden 118 for the operator. Moreover, static provisioning does not allow load 119 balancing, failover, opportunistic home link assignment etc. For 120 example, the user may be accessing the network from a location that 121 may be geographically far away from the preconfigured home link; the 122 administrative burden to configure the MN's with the respective 123 addresses is large and the ability to react on environmental changes 124 is minimal. In these situations static provisioning may not be 125 desirable. 127 Dynamic assignment of Mobile IPv6 home registration information is a 128 desirable feature for ease of deployment and network maintenance. 129 For this purpose, the RADIUS infrastructure, which is used for access 130 authentication, can be leveraged to assign some or all of the 131 necessary parameters. The RADIUS server in the Access Service 132 Provider (ASP) or in the Mobility Service Provider's (MSP) network 133 may return these parameters to the AAA client. The AAA client might 134 either be the NAS, in case of the integrated scenario, or the home 135 agent, in case of the split scenario. The terms integrated and split 136 are described in the terminology section and were introduced in [6]. 138 2. Terminology 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [1]. 144 General mobility terminology can be found in [7]. The following 145 additional terms, as defined in [6], are used in this document: 147 Access Service Authorizer (ASA): 149 A network operator that authenticates a mobile node and 150 establishes the mobile node's authorization to receive Internet 151 service. 153 Access Service Provider (ASP): 155 A network operator that provides direct IP packet forwarding to 156 and from the mobile node. 158 Mobility Service Authorizer (MSA): 160 A service provider that authorizes Mobile IPv6 service. 162 Mobility Service Provider (MSP): 164 A service provider that provides Mobile IPv6 service. In order to 165 obtain such service, the mobile node must be authenticated and 166 authorized to obtain the Mobile IPv6 service. 168 Split Scenario: 170 A scenario where the mobility service and the network access 171 service are authorized by different entities. 173 Integrated Scenario: 175 A scenario where the mobility service and the network access 176 service are authorized by the same entity. 178 3. Solution Overview 180 This document addresses the authentication, authorization and 181 accounting functionality required by the MIPv6 bootstrapping as 182 outlined in the MIPv6 bootstrapping problem statement document (see 183 [6]). As such, the AAA functionality for the integrated and the 184 split scenario needs to be defined. This requires the ability to 185 offer support for the home agent to AAA server and the network access 186 server to AAA server communication. 188 To highlight the main use cases, we briefly describe the integrated 189 and the split scenarios in Section 3.1 and Section 3.2, respectively. 191 3.1. Integrated Scenario 193 In the integrated scenario MIPv6 bootstrapping is provided as part of 194 the network access authentication procedure. Figure 1 shows the 195 participating entities. 197 +---------------------------+ +-----------------+ 198 |Access Service Provider | |ASA/MSA/(/MSP) | 199 |(Mobility Service Provider)| | | 200 | | | +-------+ | 201 | +-------+ | | |Remote | | 202 | | | RADIUS | | |RADIUS | | 203 | |RADIUS |-------------------------|Server | | 204 | |Proxy | | | +-------+ | 205 | +-------+ | | ^ | 206 | ^ ^ | | |RADIUS | 207 | | | | | | | 208 | | | | | v | 209 | |RADIUS | | +-------+ | 210 | | | +-------+ | | | | | 211 | | | RADIUS |Home | | | |Home | | 212 | | +------->|Agent | | | |Agent | | 213 | | |in ASP | | | +-------+ | 214 | v +-------+ | +-----------------+ 215 +-------+ IEEE | +-----------+ +-------+ | 216 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 217 |Node |----------+-|RADIUS |---|Server | | 218 | | PANA,... | |Client | | | | 219 +-------+ DHCP | +-----------+ +-------+ | 220 +---------------------------+ 222 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 224 In the typical Mobile IPv6 access scenario as shown above, the MN 225 attaches in a Access Service Provider's network. During this network 226 attachment procedure, the NAS/RADIUS client interacts with the mobile 227 node. As shown in Figure 1, the authentication and authorization 228 happens via a RADIUS infrastructure. 230 At the time of authorizing the user for IPv6 access, the RADIUS 231 server in the MSA detects that the user is authorized to use the 232 Mobile IPv6 service, too. Based on the MSA's policy, the RADIUS 233 server may allocate several parameters to the MN for use during the 234 subsequent Mobile IPv6 protocol interaction with the home agent. 236 Depending on the details of the solution, an interaction with the 237 DHCPv6 server may be required, as described in [2]. 239 3.2. Split Scenario 241 In the split scenario, Mobile IPv6 bootstrapping is not provided as 242 part of the network access authentication procedure. The Mobile IPv6 243 bootstrapping procedure is executed with the Mobility Service 244 Provider when desired by the mobile node. Two variations can be 245 considered: 247 1. the MSA and the MSP are the same entity. 249 2. the MSA and the MSP are different entities. 251 Since scenario (2) is the more generic scenario we show it in 252 Figure 2. 254 +----------------------+ 255 | | 256 |Mobility +-------+ | 257 |Service |Remote | | 258 |Authorizer |RADIUS | | 259 |(MSA) |Server | | 260 | +-------+ | 261 +---------------^------+ 262 | 263 |RADIUS 264 | 265 | 266 +---------------------------------|------+ 267 |Mobility Service Provider (MSP) v | 268 +-------+ | +-----------+ +-------+ | 269 |Mobile | MIPv6 / | |Home Agent/| RADIUS |Local | | 270 |Node |-------------|RADIUS |-------------- |RADIUS | | 271 | | IKEv2 | |Client | |Proxy | | 272 +-------+ | +-----------+ +-------+ | 273 +----------------------------------------+ 275 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 276 MSP) 278 As shown in Figure 2 the interaction between the RADIUS client and 279 the RADIUS server is triggered by the protocol interaction between 280 the mobile node and the home agent/RADIUS client using IKEv2 (see [3] 281 and [8]). The home agent (i.e., RADIUS client) interacts with the 282 RADIUS infrastructure in order to perform authentication, 283 authorization, accounting and parameter bootstrapping. The AAA 284 exchange is triggered by the home agent. When the protocol exchange 285 is completed then the home agent possesses the Mobile IPv6 specific 286 parameters (see [6]). 288 Additionally, the mobile node may instruct the RADIUS server (via the 289 home agent) to perform a dynamic DNS update. 291 4. RADIUS Attribute Overview 293 4.1. Home Agent Address Attribute 295 The RADIUS server may decide to assign a Home Agent to the MN that is 296 in close proximity to the point of attachment (e.g., determined by 297 the NAS-ID). There may be other reasons for dynamically assigning 298 Home Agents to the MN, for example to share the traffic load. The 299 attribute also contains the prefix length so that the MN can infer 300 the Home Link prefix from the Home Agent address. 302 4.2. Home Agent FQDN Attribute 304 The RADIUS server may assign an home agent address FQDN. The mobile 305 node can perform a DNS query with the FQDN to derive the home agent 306 address. 308 4.3. Home Link Prefix Attribute 310 For the same reason as the HA assignment, the RADIUS server may 311 assign a Home Link that is in close proximity to the point of 312 attachment (NAS-ID). 314 4.4. Home Address Attribute 316 The RADIUS server may assign a Home Address to the MN. This allows 317 the network operator to support mobile devices that are not 318 configured with static addresses. The attribute also contains the 319 prefix length so that the MN can easily infer the Home Link prefix 320 from the Home Agent address. 322 4.5. DNS Update Mobility Option Attribute 324 By using this payload the RADIUS client instructs the RADIUS server 325 to perform a dynamic DNS update. When this payload is included in 326 the reverse direction, i.e., from the RADIUS server to the RADIUS 327 client, it informs about the status of the dynamic DNS update. When 328 the payload is sent from the RADIUS client to the RADIUS server then 329 the response MUST include the DNS Update Mobility Option attribute. 331 5. RADIUS attributes 333 This section defines format and syntax for the attribute that carries 334 the Mobile IPv6 parameters that are described in the previous 335 section. 337 The attributes MAY be present in the Access-Accept and the 338 Accounting-Request. 340 5.1. Home Agent Address Attribute 342 This attribute is sent by the RADIUS server to the NAS in an Access- 343 Accept message. The attribute carries the assigned Home Agent 344 address. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | Reserved | Prefix-Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 | | 353 | IPv6 address of assigned Home Agent | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Type: 360 ASSIGNED-HA-ADDR-TYPE to be defined by IANA. 362 Length: 364 = 20 octets 366 Reserved: 368 Reserved for future use. All bits set to 0. 370 Prefix-Length: 372 This field indicates the prefix length of the Home Link. 374 IPv6 address of assigned Home Agent: 376 128-bit IPv6 address of the assigned Home Agent. 378 5.2. Home Agent FQDN Attribute 380 This attribute is sent by the RADIUS server to the NAS in an Access- 381 Accept message. The attribute carries the FQDN of the assigned home 382 agent. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type | Length | Reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | FQDN of the assigned home agent ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Type: 394 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 396 Length: 398 Variable. 400 Reserved: 402 Reserved for future use. All bits set to 0. 404 FQDN of the assigned home agent: 406 The data field MUST contain a FQDN as described in [9]. 408 5.3. Home Link Prefix Attribute 410 This attribute is sent by the RADIUS-MIP server to the NAS in an 411 Access-Accept message. The attribute carries the assigned Home Link 412 prefix. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | Reserved | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 | | 421 | Home Link Prefix | 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Type: 426 ASSIGNED-HL-TYPE to be defined by IANA. 428 Length: 430 Variable 432 Reserved: 434 Reserved for future use. All bits set to 0. 436 Home Link Prefix: 438 Home Link prefix (upper order bits) of the assigned Home Link 439 where the MN should send binding update. 441 5.4. Home Address Attribute 443 This attribute is sent by the RADIUS server to the NAS in an Access- 444 Accept message. The attribute carries the assigned Home IPv6 Address 445 for the MN. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | Reserved | Prefix-Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 | | 454 | Assigned IPv6 Home Address | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Type: 460 ASSIGNED-HOA-TYPE to be defined by IANA. 462 Length: 464 = 20 octets. 466 Reserved: 468 Reserved for future use. All bits set to 0. 470 Prefix-Length: 472 This field indicates the prefix length of the Home Link. 474 Assigned IPv6 Home Address: 476 IPv6 Home Address that is assigned to the MN. 478 5.5. DNS Update Mobility Option Attribute 480 The DNS Update Mobility Option attribute is used for triggering a DNS 481 update by the RADIUS server and to return the result to the RADIUS 482 client. The request MUST carry the mobile node's FQDN but the 483 attribute carried in response to the request MAY not carry a FQDN 484 value. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Length | Reserved-1 | Status | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |R| Reserved-2 | FQDN ... 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Type: 496 DNS-UPDATE-TYPE to be defined by IANA. 498 Length: 500 Variable 502 Reserved-1: 504 Reserved for future use. All bits set to 0. 506 Status: 508 This 8 bit unsigned integer field indicates the result of the 509 dynamic DNS update procedure. This field MUST be set to 0 and 510 ignored by the RADIUS server when the DNS Update Mobility 511 Option is sent from the RADIUS client to the RADIUS server. 512 When the DNS Update Mobility Option is provided in the 513 response, values of the Status field less than 128 indicate 514 that the dynamic DNS update was performed successfully by the 515 RADIUS server. Values greater than or equal to 128 indicate 516 that the dynamic DNS update was not successfully completed. 517 The following values for the Status field are currently 518 defined: 520 0 DNS update performed 522 128 Reason unspecified 524 129 Administratively prohibited 526 130 DNS Update Failed 528 R flag: 530 If this bit for the R flag is set then the RADIUS client 531 requests the RADIUS server to remove the DNS entry identified 532 by the FQDN included in this attribute. If not set, the RADIUS 533 client is requesting the RADIUS server to create or update a 534 DNS entry with the FQDN specified in this attribute and the 535 Home Address carried in another attribute specified in this 536 document. 538 Reserved-2: 540 Reserved for future use. All bits set to 0. 542 FQDN of the mobile node: 544 The data field MUST contain a FQDN as described in [9]. 546 6. Message Flows 548 6.1. Integrated Scenario (MSA=ASA) 550 This section is based on [2] and uses the previously defined RADIUS 551 attributes. 553 6.1.1. Home Agent allocation in the MSP 555 RADIUS is used to authenticate the mobile node, to authorize it for 556 the mobility service and to send information about the assigned home 557 agent to the NAS. 559 | 560 --------------ASP------>|<--ASA+MSA-- 561 | 562 +----+ +------+ +-------+ +-------+ 563 | | |RADIUS| | | | | 564 | | |Client| | | | | 565 | MN | |NAS/ | | DHCP | |Home | 566 | | |DHCP | | Server| |RADIUS | 567 | | |Relay | | | |Server | 568 +----+ +------+ +-------+ +-------+ 569 | | | | 570 | 1 | 1 | | 571 |<------------->|<---------------------->| 572 | | | | 573 | | | | 574 | 2 | | | 575 |-------------->| | | 576 | | | | 577 | | 3 | | 578 | |------------>| | 579 | | | | 580 | | 4 | | 581 | |<------------| | 582 | | | | 583 | 5 | | | 584 |<--------------| | | 585 | | | | 587 In step (1), the MN executes the normal network access authentication 588 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 589 acts as an authenticator in "pass-through" mode, i.e., the endpoint 590 of the authentication dialogue is the MN's home RADIUS server. This 591 is the typical scenario in case the messages involved in the 592 authentication protocol are transported in EAP. 594 The NAS encapsulates/decapsulates EAP packets into/from RADIUS 595 messages until an Access-Response (either an Access-Accept or an 596 Access/Reject packet is received by the NAS). This concludes the 597 network access authentication phase. 599 Depending on the RADIUS server configuration, the Home Agent Address 600 attribute or the Home Agent FQDN attribute may be appended to the 601 Access-Accept message. In the latter case the MN needs to perform a 602 DNS query in order to discover the Home Agent address. 604 The Home Agent Address or Home Agent FQDN attribute is appended to 605 the access accept in case the home RADIUS server knows or has 606 allocated a HA to the access request (this is assumed in this 607 scenario). 609 In step (2) the MN sends a DHCPv6 Information Request message to 610 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 611 for the Home Network Identifier Option shall be included in that 612 message. The Home Network Identifier Option should have id-type of 613 1, the message is a request to discover home network information that 614 pertains to the given realm, i.e., the user's home domain (identified 615 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 616 identify itself to the DHCP server. 618 In step (3) the DHCP relay agent forwards this request to the DHCP 619 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 620 message. This option carries the RADIUS Home Agent Address Attribute 621 from the access accept message. 623 In step (4), the DHCP server identifies the client and finds out that 624 it requests home agent information in the MSP (by the Home Network 625 Identifier Option = 1). The DHCP server extracts the home agent 626 address from OPTION_MIP6-RELAY-Option and places it into Home Network 627 Information Option in the Reply message. 629 In step (5), the Relay Agent forwards the Reply Message to the Mobile 630 Node. On reception of this message, the home agent address or the 631 FQDN of the home agent is available at the MN. 633 6.1.2. Home Agent allocation in the ASP (visited network) 635 This scenario is similar to the one described in Section 6.1.1. The 636 difference is in step (2), where the type-id field in the Home 637 Network Identifier Option is set to zero, indicating that a Home 638 Agent is requested in the ASP instead of in the MSP. Thus, the 639 information received by the home RADIUS server, via the DHCP relay, 640 in the OPTION_MIP6-RELAY-Option (Information Request) is ignored. 641 The DHCP server allocates a home agent from its list of possible home 642 agents and returns it in the Reply message (Home Network Information 643 Option). 645 6.2. Split Scenario (MSA!=ASA) 647 6.2.1. Mobile Service Provider and Mobile Service Authorizer are the 648 same entity. 650 The assumption in this scenario is that the MN has the domain name of 651 the MSP preconfigured. 653 In this scenario there is no relationship between the network access 654 authentication procedure and the MIPv6 bootstrapping procedure. 656 In order to learn the IP address of the home agent, the MN either 657 performs a DNS lookup of the Home Agent Name or a DNS lookup by 658 service name. In the first case, the MN is preconfigured with the 659 FQDN of the HA, and thus sends a DNS request, where QNAME = name of 660 HA, QTYPE='AAAA' (request for IPv6 address of HA). A DNS reply 661 message is returned by the DNS server with the HA address. 663 The MN then runs IKEv2 with the HA in order to set up IPsec SAs 664 (MN-HA). As part of this, the MN authenticates itself to the RADIUS 665 server in the MSA domain, and obtains authorization for mobility 666 service (including the Home Address). 668 The MN shares credentials with the RADIUS server in the MSA domain. 669 The RADIUS communication between the HA and the this RADIUS server is 670 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 671 within IKEv2, the MN is authenticated and authorized for the IPv6 672 mobility service and is also assigned a home address. 674 The setup of SAs and mutual authentication between MN and AAAH using 675 RADIUS (and EAP) is similar to the one described for the Diameter 676 protocol in [10]. The described mechanism ensures that common keying 677 material will be available at the MN and the HA after successful 678 completion. 680 ----------------------------ASP--------->|<-----MSA/MSP 682 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 683 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 684 +----+ +----+ +--------------------+ 686 MN HA Remote RADIUS server 687 -- -- -------------------- 688 IKE_SA_INIT 689 <------------------------------> 691 HDR, SK{IDi,[CERTREQ,] [IDr,] 692 SAi2, TSi, TSr} 693 -------------------------------> 694 RADIUS Access Request(EAP-Response) 695 ----------------------------------> 696 RADIUS Access Challenge(EAP-Request) 697 <----------------------------------- 698 HDR, SK {IDr, [CERT,] AUTH, 699 EAP } 700 <------------------------------- 701 HDR, SK {EAP} 702 --------------------------------> 703 RADIUS Access Request(EAP-Response) 704 ----------------------------------> 705 RADIUS Access Challenge(EAP-Request) 706 <----------------------------------- 707 HDR, SK{EAP-Request} 708 <------------------------------- 709 HDR, SK{EAP-Response} 710 --------------------------------> 711 RADIUS Access Request(EAP-Response) 712 ----------------------------------> 713 ... ... 715 RADIUS Access Accept(EAP-Success) 716 <------------------------ 718 HDR, SK{EAP-Success} 719 <------------------------------- 720 HDR, SK{AUTH} 721 -------------------------------> 722 HDR, SK {AUTH, SAr2, TSi, TSr } 723 <------------------------------- 725 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 726 defined in the IKEv2 specification, negotiating crypto algorithms and 727 running DH key exchange). IKEv2 supports integration with EAP. The 728 MN indicates its desire to use EAP by not including the AUTH payload 729 in the third message. However, it indicates its identity (NAI) by 730 using the IDi field. If the HA supports EAP for authentication, it 731 forwards the identity to the Remote RADIUS server by sending a RADIUS 732 Access-Request message containing the identity in the EAP-Payload AVP 733 and in the RADIUS User-Name attribute. Based on this identity, the 734 Remote RADIUS server chooses authentication method and sends the 735 first EAP-Request in the RADIUS Access-Challenge message. During the 736 EAP authentication phase, the HA relays EAP packets between the MN 737 and the Remote RADIUS server. If the authentication succeeds and if 738 the MN is authorized to use Mobile IPv6 service, the Remote RADIUS 739 server sends a RADIUS Access Accept message containing the EAP- 740 Success and the AAA-Key derived from the EAP authentication method. 741 EAP authentication methods that do not derive keys are not 742 recommended. This key is used by both MN and HA to generate the AUTH 743 payload. In subsequent messages, MN and HA setup IPsec SAs for 744 Mobile IPv6. 746 6.2.2. Mobile Service Provider and Mobile Service Authorizer are 747 different entities. 749 The HA address discovery is performed as described in Section 6.2.1. 751 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 753 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 754 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 755 +----+ +----+ |RADIUS| |RADIUS| 756 |Proxy | |Server| 757 +------+ +------+ 759 The scenario is similar to previously described scenarios with the 760 difference of utilizing AAA roaming agreements between the MSP and 761 the MSA. 763 7. Goals for the HA-AAA Interface 765 Here, we follow the classification and labels listed in the MIPv6- 766 AAA-Goals document [11]. 768 7.1. General Goals 770 G1.1-G1.4 Security 772 These are standard requirements for a AAA protocol - mutual 773 authentication, integrity, replay protection, confidentiality. IPsec 774 can be used to achieve the goals. Goal G1.5 regarding inactive peer 775 detection needs further investigations since heartbeat messages do 776 not exist in RADIUS (like in the Diameter case, Watch-Dog-Request/ 777 Answer). 779 7.2. Service Authorization 781 G2.1. The AAA-HA interface should allow the use of the Network 782 Access Identifier (NAI) to identify the mobile node. The User-Name 783 attribute can be used for the purpose to carry the NAI. 785 G2.2 The HA should be able to query the AAAH server in order to 786 verify Mobile IPv6 service authorization for the mobile node. Any 787 node implementing RADIUS functionality can possibly initiate a 788 request message. In combination with the ability of the RADIUS 789 protocol to carry EAP messages, the mechanisms described in this 790 document enable an HA to query a RADIUS server and verify MIPv6 791 authorization for the MN. 793 G2.3 The AAAH server should be able to enforce explicit operational 794 limitations and authorization restrictions on the HA (e.g., packet 795 filters, QoS parameters). Work in progress in the area, including 796 NAS-Filter-Rule, RADIUS quality of service support, prepaid 797 extensions etc. is performed. The relevant attributes may be reused 798 for providing required functionality over the AAAH-HA interface. 800 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 801 session by the AAAH server, e.g., authorization lifetime, extension 802 of the authorization lifetime and explicit session termination by the 803 AAAH server side. 805 The attribute Session-Timeout may be sent in Access Challenge or 806 Access Accept message by the RADIUS server, thus limiting the 807 authorization session duration. In order to reauthenticate/ 808 reauthorize the user, the Termination-Action attribute can be 809 included, with value 1, meaning the NAS should send a new RADIUS- 810 Request packet. Additional AVPs for dealing with pre-paid sessions 811 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 812 specified in RADIUS prepaid extension. Exchanging of application 813 specific authorization request/answer messages provides extension of 814 the authorization session (e.g., Authorize Only Access Request sent 815 by the HA (NAS) to the RADIUS server). Initiation of the re- 816 authorization by both sides could be supported. Both sides could 817 initiate session termination - the RADIUS server by sending 818 Disconnect message. 820 7.3. Accounting 822 G3.1 The AAA-HA interface must support the transfer of accounting 823 records needed for service control and charging. These include (but 824 may not be limited to): time of binding cache entry creation and 825 deletion, octets sent and received by the mobile node in bi- 826 directional tunneling, etc. 828 The requirements for accounting over the AAAH-HA interface does not 829 require enhancements to the existing accounting functionality. 831 7.4. Mobile Node Authentication 833 G4.1 The AAA-HA interface MUST support pass-through EAP 834 authentication with the HA working as EAP authenticator operating in 835 pass-through mode and the AAAH server working as back-end 836 authentication server. 838 These issues require the functionality of AAAH server working as a 839 back-end authentication server and HA working as NAS and EAP 840 authenticator in pass-through mode for providing a mobile node 841 authentication. This document suggests this mode of operation in the 842 context of the relevant scenarios. 844 7.5. Provisioning of Configuration Parameters 846 G5.1 The HA should be able to communicate to the AAAH server the Home 847 Address allocated to the MN (e.g. for allowing the AAAH server to 848 perform DNS update on behalf of the MN). 850 This document describes needed AVPs for this purpose, see section 851 "DNS Update Mobility Option Attribute" 853 8. Table of Attributes 855 The following table provides a guide to which attributes may be found 856 in RADIUS message and in what number. 858 Request Accept Reject Challenge Attribute 860 0-1 0-1 0 0 Home Agent Address Attribute 861 0-1 0-1 0 0 Home Agent FQDN Attribute 862 0-1 0-1 0 0 Home Link Prefix Attribute 863 0-1 0-1 0 0 Home Address Attribute 864 0-1 0-1 0 0 DNS Update Mobility Option 865 Attribute 867 The following table defines the meaning of the above table entries. 869 0 This attribute MUST NOT be present. 870 0-1 Zero or one instance of this attribute MAY be present. 872 9. Security Considerations 874 Assignment of MIPv6 specific parameters has to be based on a protocol 875 run between the participating parties with a successful outcome 876 (i.e., successful authentication and authorization). The RADIUS 877 server should only assign MIPv6 specific parameters to an end host 878 that is authorized for Mobile IPv6 service. This check could be 879 performed with the user's subscription profile in the Home Network. 881 The NAS and the home agent to the RADIUS server transactions must be 882 adequately secured. Otherwise there is a possibility that the user 883 may receive fraudulent values from a rogue RADIUS server potentially 884 hijacking the user's Mobile IPv6 session. 886 These new attributes do not introduce additional security 887 considerations besides the ones identified in [4]. 889 10. IANA Considerations 891 The following RADIUS attribute Type values MUST be assigned by IANA. 893 o ASSIGNED-HA-ADDR-TYPE 895 o ASSIGNED-HA-FQDN-TYPE 897 o ASSIGNED-HL-TYPE 899 o ASSIGNED-HOA-TYPE 901 o DNS-UPDATE-TYPE 903 11. Acknowledgements 905 We would like to thank the following individuals for their review and 906 constructive comments during the development of this document: 907 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 908 Andreas Pashalidis, Rafa Marin Lopez. 910 12. References 912 12.1. Normative References 914 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 915 Levels", BCP 14, RFC 2119, March 1997. 917 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 918 the Integrated Scenario", 919 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 920 progress), June 2006. 922 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 923 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 924 March 2006. 926 [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 927 Authentication Dial In User Service (RADIUS)", RFC 2865, 928 June 2000. 930 12.2. Informative References 932 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 933 IPv6", RFC 3775, June 2004. 935 [6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 936 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 937 progress), May 2006. 939 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 940 RFC 3753, June 2004. 942 [8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 943 IKEv2 and the revised IPsec Architecture", 944 draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. 946 [9] Mockapetris, P., "Domain names - implementation and 947 specification", STD 13, RFC 1035, November 1987. 949 [10] Korhonen, J., "Diameter MIPv6 Bootstrapping for the Integrated 950 Scenario", draft-ietf-dime-mip6-integrated-00 (work in 951 progress), June 2006. 953 [11] Giaretta, G., "Goals for AAA-HA interface", 954 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 955 January 2006. 957 [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 958 "DNS Security Introduction and Requirements", RFC 4033, 959 March 2005. 961 [13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 962 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 963 Agents", RFC 3776, June 2004. 965 [14] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 966 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 967 April 1997. 969 Authors' Addresses 971 Kuntal Chowdhury 972 Starent Networks 973 30 International Place 974 Tewksbury, MA 01876 975 US 977 Phone: +1 214-550-1416 978 Email: kchowdhury@starentnetworks.com 980 Avi Lior 981 Bridgewater Systems 982 303 Terry Fox Drive, Suite 100 983 Ottawa, Ontario 984 Canada K2K 3J1 986 Phone: +1 613-591-6655 987 Email: avi@bridgewatersystems.com 989 Hannes Tschofenig 990 Siemens 991 Otto-Hahn-Ring 6 992 Munich, Bavaria 81739 993 Germany 995 Email: Hannes.Tschofenig@siemens.com 997 Intellectual Property Statement 999 The IETF takes no position regarding the validity or scope of any 1000 Intellectual Property Rights or other rights that might be claimed to 1001 pertain to the implementation or use of the technology described in 1002 this document or the extent to which any license under such rights 1003 might or might not be available; nor does it represent that it has 1004 made any independent effort to identify any such rights. Information 1005 on the procedures with respect to rights in RFC documents can be 1006 found in BCP 78 and BCP 79. 1008 Copies of IPR disclosures made to the IETF Secretariat and any 1009 assurances of licenses to be made available, or the result of an 1010 attempt made to obtain a general license or permission for the use of 1011 such proprietary rights by implementers or users of this 1012 specification can be obtained from the IETF on-line IPR repository at 1013 http://www.ietf.org/ipr. 1015 The IETF invites any interested party to bring to its attention any 1016 copyrights, patents or patent applications, or other proprietary 1017 rights that may cover technology that may be required to implement 1018 this standard. Please address the information to the IETF at 1019 ietf-ipr@ietf.org. 1021 Disclaimer of Validity 1023 This document and the information contained herein are provided on an 1024 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1025 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1026 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1027 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1028 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1029 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1031 Copyright Statement 1033 Copyright (C) The Internet Society (2006). This document is subject 1034 to the rights, licenses and restrictions contained in BCP 78, and 1035 except as set forth therein, the authors retain all their rights. 1037 Acknowledgment 1039 Funding for the RFC Editor function is currently provided by the 1040 Internet Society.