idnits 2.17.1 draft-ietf-mip6-radius-00.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 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1018. ** 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 (October 5, 2006) is 6411 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 956, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 960, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 964, 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 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Starent Networks 4 Expires: April 8, 2007 A. Lior 5 Bridgewater Systems 6 H. Tschofenig 7 Siemens 8 October 5, 2006 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-00.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 April 8, 2007. 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 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 existing authentication, authorization and 51 accounting infrastructure. This document defines the new attributes 52 to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. 53 This information exchange may take place as part of the initial 54 network access authentication procedure or as part of a separate 55 protocol exchange between the mobile node, the home agent and the AAA 56 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 . . . . . . . . . . . . . . . . . . . . . . 27 100 Intellectual Property and Copyright Statements . . . . . . . . 28 102 1. Introduction 104 Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform 105 registration with a Home Agent with information about its current 106 point of attachment (Care-of Address). The Home Agent creates and 107 maintains binding between the MN's Home Address and the MN's Care-of 108 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, 112 the 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 for 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 entity. 197 +---------------------------+ +-----------------+ 198 |Access Service Provider | |ASA/MSA/(/MSP) | 199 |(Mobility Service Provider)| | | 200 | | | +-------+ | 201 | +-------+ | | |Remote | | 202 | |Local | RADIUS | | |RADIUS | | 203 | |RADIUS |-------------------------|Server | | 204 | |Proxy | | | +-------+ | 205 | +-------+ | | ^ | 206 | ^ ^ | | |RADIUS | 207 | | | | | | | 208 | | | | | v | 209 | |RADIUS | | +-------+ | 210 | | | +-------+ | | |Local | | 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 for Mobile IPv6 232 access. Based on the MSA's policy, the RADIUS server may allocate 233 several parameters to the MN for use during the subsequent Mobile 234 IPv6 protocol interaction with the home agent. 236 Depending on the details of the solution interaction with the DHCPv6 237 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 (1) 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 / RADIUS Client interacts with the RADIUS 282 infrastructure to perform authentication, authorization, accounting 283 and parameter bootstrapping. The exchange is triggered by the home 284 agent and an interaction with the RADIUS infrastructure is initiated. 285 When the protocol exchange is completed then the home agent needs to 286 possess the Mobile IPv6 specific parameters (see [6]). 288 Additionally, the mobile node might instruct the RADIUS server (via 289 the 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 easily 300 infer the Home Link prefix from the Home Agent address. 302 4.2 Home Agent FQDN Attribute 304 The RADIUS server may assign an FQDN of the home address to the MN. 305 The mobile node can perform DNS query with the FQDN to derive the 306 home agent 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). The MN can perform [5] specific procedures to 313 discover other information for Mobile IPv6 registration. 315 4.4 Home Address Attribute 317 The RADIUS server may assign a Home Address to the MN. This allows 318 the network operator to support mobile devices that are not 319 configured with static addresses. The attribute also contains the 320 prefix length so that the MN can easily infer the Home Link prefix 321 from the Home Agent address. 323 4.5 DNS Update Mobility Option Attribute 325 By using this payload the RADIUS client instructs the RADIUS server 326 to perform a dynamic DNS update. When this payload is included in 327 the reverse direction, i.e., from the RADIUS server to the RADIUS 328 client, it informs about the status of the dynamic DNS update. When 329 the payload is sent from the RADIUS client to the RADIUS server then 330 the response MUST include the DNS Update Mobility Option attribute. 332 5. RADIUS attributes 334 This section defines format and syntax for the attribute that carries 335 the Mobile IPv6 parameters that are described in the previous 336 section. 338 The attributes MAY be present in Access-Accept, 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 length. 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 >= 4 octets + the minimum length of a prefix. 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 length. 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. 518 The following values for the Status field are currently 519 defined: 521 0 DNS update performed 523 128 Reason unspecified 525 129 Administratively prohibited 527 130 DNS Update Failed 529 R flag: 531 If this bit for the R flag is set then the RADIUS client 532 requests the RADIUS server to remove the DNS entry identified 533 by the FQDN included in this attribute. If not set, the RADIUS 534 client is requesting the RADIUS server to create or update a 535 DNS entry with the FQDN specified in this attribute and the 536 Home Address carried in another attribute specified in this 537 document. 539 Reserved-2: 541 Reserved for future use. All bits set to 0. 543 FQDN of the mobile node: 545 The data field MUST contain a FQDN as described in [9]. 547 6. Message Flows 549 6.1 Integrated Scenario (MSA=ASA) 551 This section is based on [2] and uses the previously defined RADIUS 552 attributes. 554 6.1.1 Home Agent allocation in the MSP 556 RADIUS is used to authenticate the mobile node, to authorize it for 557 the mobility service and to send information about the assigned home 558 agent to the NAS. 560 | 561 --------------ASP------>|<--ASA+MSA-- 562 | 563 +----+ +------+ +-------+ +-------+ 564 | | |RADIUS| | | | | 565 | | |Client| | | | | 566 | MN | |NAS/ | | DHCP | |Home | 567 | | |DHCP | | Server| |RADIUS | 568 | | |Relay | | | |Server | 569 +----+ +------+ +-------+ +-------+ 570 | | | | 571 | 1 | 1 | | 572 |<------------->|<---------------------->| 573 | | | | 574 | | | | 575 | 2 | | | 576 |-------------->| | | 577 | | | | 578 | | 3 | | 579 | |------------>| | 580 | | | | 581 | | 4 | | 582 | |<------------| | 583 | | | | 584 | 5 | | | 585 |<--------------| | | 586 | | | | 588 In step (1), the MN executes the normal network access authentication 589 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 590 acts as an authenticator in "pass-through" mode, i.e., the endpoint 591 of the authentication dialogue is the MN's home RADIUS server. This 592 is the typical scenario in case the messages involved in the 593 authentication protocol are transported in EAP. 595 The NAS encapsulates/decapsulates EAP packets into/from RADIUS 596 messages until an Access-Response (either an Access-Accept or an 597 Access/Reject packet is received by the NAS). This concludes the 598 network access authentication phase. 600 Depending on the RADIUS server configuration, the Home Agent Address 601 attribute or the the Home Agent FQDN attribute may be appended to the 602 Access-Accept message. In the latter case the MN needs to perform a 603 DNS query in order to discover the Home Agent address. 605 The Home Agent Address or Home Agent FQDN attribute is appended to 606 the access accept in case the home RADIUS server knows or has 607 allocated a HA to the access request (this is assumed in this 608 scenario). 610 In step (2) the MN sends a DHCPv6 Information Request message to 611 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 612 for the Home Network Identifier Option shall be included in that 613 message. The Home Network Identifier Option should have id-type of 614 1, the message is a request to discover home network information that 615 pertains to the given realm, i.e., the user's home domain (identified 616 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 617 identify itself to the DHCP server. 619 In step (3) the DHCP relay agent forwards this request to the DHCP 620 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 621 message. This option carries the RADIUS Home Agent Address Attribute 622 from the access accept message. 624 In step (4), the DHCP server identifies the client (by DUID) and 625 finds out that it requests home agent information in the MSP (by the 626 Home Network Identifier Option = 1). The DHCP server extracts the 627 home agent address from OPTION_MIP6-RELAY-Option and places it into 628 Home Network Information Option in the Reply message. 630 In step (5), the Relay Agent forwards the Reply Message to the Mobile 631 Node. On reception of this message, the home agent address or the 632 FQDN of the home agent is available at the MN. 634 6.1.2 Home Agent allocation in the ASP (visited network) 636 This scenario is similar to the one described in Section 6.1.1. The 637 difference is in step (2), where the type-id field in the Home 638 Network Identifier Option is set to zero, indicating that a Home 639 Agent is requested in the ASP instead of in the MSP. Thus, the 640 information received by the home RADIUS server, via the DHCP relay, 641 in the OPTION_MIP6-RELAY-Option (Information Request) is ignored. 642 The DHCP server allocates a home agent from its list of possible home 643 agents and returns it in the Reply message (Home Network Information 644 Option). 646 6.2 Split Scenario (MSA!=ASA) 648 6.2.1 Mobile Service Provider and Mobile Service Authorizer are the 649 same entity. 651 The assumption in this scenario is that the MN has the domain name of 652 the MSP preconfigured. 654 In this scenario there is no relationship between the network access 655 authentication procedure and the MIPv6 bootstrapping procedure. 657 In order to learn the IP address of the home agent, the MN either 658 performs a DNS lookup of the Home Agent Name or a DNS lookup by 659 service name. In the first case, the MN is preconfigured with the 660 FQDN of the HA, and thus sends a DNS request, where QNAME = name of 661 HA, QTYPE='AAAA' (request for IPv6 address of HA). A DNS reply 662 message is returned by the DNS server with the HA address. 664 The MN then runs IKEv2 with the HA in order to set up IPsec SAs 665 (MN-HA). As part of this,the MN authenticates itself to the RADIUS 666 server in the MSA domain, and obtains authorization for mobility 667 service (including the Home Address). 669 The MN shares credentials with the RADIUS server in the MSA domain. 670 The RADIUS communication between the HA and the this RADIUS server is 671 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 672 within IKEv2, the MN is authenticated and authorized for the IPv6 673 mobility service and is also assigned a home address. 675 The setup of SAs and mutual authentication between MN and AAAH using 676 RADIUS (and EAP) is similar to the one described for Diameter 677 protocol in [10]. The described mechanism ensureas that common 678 keying material will be available at the MN and HA after successful 679 completion. 681 ----------------------------ASP--------->|<-----MSA/MSP 683 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 684 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 685 +----+ +----+ +--------------------+ 687 MN HA Remote RADIUS server 688 -- -- -------------------- 689 IKE_SA_INIT 690 <------------------------------> 692 HDR, SK{IDi,[CERTREQ,] [IDr,] 693 SAi2, TSi, TSr} 694 -------------------------------> 695 RADIUS Access Request(EAP-Response) 696 ----------------------------------> 697 RADIUS Access Challenge(EAP-Request) 698 <----------------------------------- 699 HDR, SK {IDr, [CERT,] AUTH, 700 EAP } 701 <------------------------------- 702 HDR, SK {EAP} 703 --------------------------------> 704 RADIUS Access Request(EAP-Response) 705 ----------------------------------> 706 RADIUS Access Challenge(EAP-Request) 707 <----------------------------------- 708 HDR, SK{EAP-Request} 709 <------------------------------- 710 HDR, SK{EAP-Response} 711 --------------------------------> 712 RADIUS Access Request(EAP-Response) 713 ----------------------------------> 714 ... ... 716 RADIUS Access Accept(EAP-Success) 717 <------------------------ 719 HDR, SK{EAP-Success} 720 <------------------------------- 721 HDR, SK{AUTH} 722 -------------------------------> 723 HDR, SK {AUTH, SAr2, TSi, TSr } 724 <------------------------------- 726 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 727 defined in the IKEv2 specification, negotiating crypto algorithms and 728 running DH key exchange). IKEv2 supports integration with EAP. The 729 MN indicates its desire to use EAP by not including the AUTH payload 730 in the third message. However, it indicates its identity (NAI) by 731 using the IDi field. If the HA supports EAP for authentication, it 732 forwards the identity to the Remote RADIUS server by sending a RADIUS 733 Access-Request message containing the identity in the EAP-Payload AVP 734 and in the RADIUS User-Name attribute. Based on this identity, the 735 Remote RADIUS server chooses authentication method and sends the 736 first EAP-Request in the RADIUS Access-Challenge message. During the 737 EAP authentication phase, the HA relays EAP packets between the MN 738 and the Remote RADIUS server. If the authentication succeeds and if 739 the MN is authorized to use Mobile IPv6 service, the Remote RADIUS 740 server sends a RADIUS Access Accept message containing the EAP- 741 Success and the AAA-Key derived from the EAP authentication method. 742 EAP authentication methods that do not derive keys are not 743 recommended. This key is used by both MN and HA to generate the AUTH 744 payload. In subsequent messages, MN and HA setup IPsec SAs for 745 Mobile IPv6. 747 6.2.2 Mobile Service Provider and Mobile Service Authorizer are 748 different entities. 750 The HA address discovery is performed as described in Section 6.2.1. 752 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 754 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 755 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 756 +----+ +----+ |RADIUS| |RADIUS| 757 |Proxy | |Server| 758 +------+ +------+ 760 The scenario is similar to previously described scenarios with the 761 difference of utilizing AAA roaming agreements between the MSP and 762 the MSA. 764 7. Goals for the HA-AAA Interface 766 Here, we follow the classification and labels listed in the MIPv6- 767 AAA-Goals document [11]. 769 7.1 General Goals 771 G1.1-G1.4 Security 773 These are standard requirements for a AAA protocol - mutual 774 authentication, integrity, replay protection, confidentiality. IPsec 775 can be used to achieve the goals. Goal G1.5 regarding inactive peer 776 detection needs further investigations since heartbeat messages do 777 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 779 7.2 Service Authorization 781 G2.1. The AAA-HA interface should allow the use of Network Access 782 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 to verify Mobile 786 IPv6 service authorization for the mobile node. Any node 787 implementing RADIUS functionality can possibly initiate a request 788 message. In combination with the ability of the RADIUS protocol to 789 carry EAP messages, our solution will enable an HA to query a RADIUS 790 server and verify MIPv6 authorization for the MN. 792 G2.3 The AAAH server should be able to enforce explicit operational 793 limitations and authorization restrictions on the HA (e.g., packet 794 filters, QoS parameters). Work in progress in the area, including 795 NAS-Filter-Rule, RADIUS quality of service support, prepaid 796 extensions etc. is performed. The relevant attributes may be reused 797 for providing required functionality over the AAAH-HA interface. 799 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 800 session by the AAAH server, e.g., authorization lifetime, extension 801 of the authorization lifetime and explicit session termination by the 802 AAAH server side. 804 The attribute Session-Timeout may be sent in Access Challenge or 805 Access Accept message by the RADIUS server, thus limiting the 806 authorization session duration. In order to reauthenticate/ 807 reauthorize the user, the Termination-Action attribute can be 808 included, with value 1, meaning the NAS should send a new RADIUS- 809 Request packet. Additional AVPs for dealing with pre-paid sessions 810 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 811 specified in RADIUS prepaid extension. Exchanging of application 812 specific authorization request/answer messages provides extension of 813 the authorization session (e.g., Authorize Only Access Request sent 814 by the HA (NAS) to the RADIUS server). Initiation of the re- 815 authorization by both sides could be supported. Both sides could 816 initiate session termination - the RADIUS server by sending 817 Disconnect message. 819 7.3 Accounting 821 G3.1 The AAA-HA interface must support the transfer of accounting 822 records needed for service control and charging. These include (but 823 may not be limited to): time of binding cache entry creation and 824 deletion, octets sent and received by the mobile node in bi- 825 directional tunneling, etc. 827 The requirements for accounting over the AAAH-HA interface does not 828 require enhancements to the existing accounting functionality. 830 7.4 Mobile Node Authentication 832 G4.1 The AAA-HA interface MUST support pass-through EAP 833 authentication with the HA working as EAP authenticator operating in 834 pass-through mode and the AAAH server working as back-end 835 authentication server. 837 These issues require the functionality of AAAH server working as a 838 back-end authentication server and HA working as NAS and EAP 839 authenticator in pass-through mode for providing a mobile node 840 authentication. This document suggests this mode of operation in the 841 context of the relevant scenarios. 843 7.5 Provisioning of Configuration Parameters 845 G5.1 The HA should be able to communicate to the AAAH server the Home 846 Address allocated to the MN (e.g. for allowing the AAAH server to 847 perform DNS update on behalf of the MN). 849 This document describes needed AVPs for this purpose, see section 850 "DNS Update Mobility Option Attribute" 852 8. Table of Attributes 854 The following table provides a guide to which attributes may be found 855 in RADIUS message and in what number. 857 Request Accept Reject Challenge Attribute 859 0-1 0-1 0 0 Home Agent Address Attribute 860 0-1 0-1 0 0 Home Agent FQDN Attribute 861 0-1 0-1 0 0 Home Link Prefix Attribute 862 0-1 0-1 0 0 Home Address Attribute 863 0-1 0-1 0 0 DNS Update Mobility Option 864 Attribute 866 The following table defines the meaning of the above table entries. 868 0 This attribute MUST NOT be present. 869 0-1 Zero or one instance of this attribute MAY be present. 871 9. Security Considerations 873 Assignment of these values to a user should be based on successful 874 authentication of the user at the NAS and/or at the home agent. The 875 RADIUS server should only assign these values to a user who is 876 authorized for Mobile IPv6 service (this check could be performed 877 with the user's subscription profile in the Home Network). 879 The NAS and the home agent to the RADIUS server transactions must be 880 adequately secured. Otherwise there is a possibility that the user 881 may receive fraudulent values from a rogue RADIUS server potentially 882 hijacking the user's Mobile IPv6 session. 884 These new attributes do not introduce additional security 885 considerations besides the ones identified in [4]. 887 10. IANA Considerations 889 The following RADIUS attribute Type values MUST be assigned by IANA. 891 ASSIGNED-HA-ADDR-TYPE 893 ASSIGNED-HA-FQDN-TYPE 895 ASSIGNED-HL-TYPE 897 ASSIGNED-HOA-TYPE 899 DNS-UPDATE-TYPE 901 11. Acknowledgements 903 We would like to thank the following individuals for their review and 904 constructive comments during the development of this document: 906 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 907 Andreas Pashalidis, Rafa Marin Lopez. 909 12. References 911 12.1 Normative References 913 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 914 Levels", BCP 14, RFC 2119, March 1997. 916 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 917 the Integrated Scenario", 918 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 919 progress), June 2006. 921 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 922 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 923 March 2006. 925 [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 926 Authentication Dial In User Service (RADIUS)", RFC 2865, 927 June 2000. 929 12.2 Informative References 931 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 932 IPv6", RFC 3775, June 2004. 934 [6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 935 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 936 progress), May 2006. 938 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 939 RFC 3753, June 2004. 941 [8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 942 IKEv2 and the revised IPsec Architecture", 943 draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. 945 [9] Mockapetris, P., "Domain names - implementation and 946 specification", STD 13, RFC 1035, November 1987. 948 [10] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", 949 draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), 950 October 2005. 952 [11] Giaretta, G., "AAA Goals for Mobile IPv6", 953 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 954 September 2006. 956 [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 957 "DNS Security Introduction and Requirements", RFC 4033, 958 March 2005. 960 [13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 961 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 962 Agents", RFC 3776, June 2004. 964 [14] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 965 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 966 April 1997. 968 Authors' Addresses 970 Kuntal Chowdhury 971 Starent Networks 972 30 International Place 973 Tewksbury, MA 01876 974 US 976 Phone: +1 214-550-1416 977 Email: kchowdhury@starentnetworks.com 979 Avi Lior 980 Bridgewater Systems 981 303 Terry Fox Drive, Suite 100 982 Ottawa, Ontario 983 Canada K2K 3J1 985 Phone: +1 613-591-6655 986 Email: avi@bridgewatersystems.com 988 Hannes Tschofenig 989 Siemens 990 Otto-Hahn-Ring 6 991 Munich, Bavaria 81739 992 Germany 994 Email: Hannes.Tschofenig@siemens.com 996 Intellectual Property Statement 998 The IETF takes no position regarding the validity or scope of any 999 Intellectual Property Rights or other rights that might be claimed to 1000 pertain to the implementation or use of the technology described in 1001 this document or the extent to which any license under such rights 1002 might or might not be available; nor does it represent that it has 1003 made any independent effort to identify any such rights. Information 1004 on the procedures with respect to rights in RFC documents can be 1005 found in BCP 78 and BCP 79. 1007 Copies of IPR disclosures made to the IETF Secretariat and any 1008 assurances of licenses to be made available, or the result of an 1009 attempt made to obtain a general license or permission for the use of 1010 such proprietary rights by implementers or users of this 1011 specification can be obtained from the IETF on-line IPR repository at 1012 http://www.ietf.org/ipr. 1014 The IETF invites any interested party to bring to its attention any 1015 copyrights, patents or patent applications, or other proprietary 1016 rights that may cover technology that may be required to implement 1017 this standard. Please address the information to the IETF at 1018 ietf-ipr@ietf.org. 1020 Disclaimer of Validity 1022 This document and the information contained herein are provided on an 1023 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1024 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1025 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1026 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1027 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1028 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1030 Copyright Statement 1032 Copyright (C) The Internet Society (2006). This document is subject 1033 to the rights, licenses and restrictions contained in BCP 78, and 1034 except as set forth therein, the authors retain all their rights. 1036 Acknowledgment 1038 Funding for the RFC Editor function is currently provided by the 1039 Internet Society.