idnits 2.17.00 (12 Aug 2021) /tmp/idnits49998/draft-ietf-mip6-radius-03.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, updated by RFC 4748 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1329. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 18, 2007) is 5297 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) -- Looks like a reference, but probably isn't: 'RFC TBD' on line 1152 == Unused Reference: '19' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1259, but no explicit reference was found in the text == Outdated reference: draft-ietf-mip6-bootstrapping-integrated-dhc has been published as RFC 6611 == Outdated reference: draft-ietf-mip6-bootstrapping-split has been published as RFC 5026 ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '12') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '15') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '16') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '17') (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 Internet-Draft Bridgewater Systems 4 Intended status: Standards Track K. Chowdhury 5 Expires: May 21, 2008 Starent Networks 6 H. Tschofenig 7 Siemens 8 November 18, 2007 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-03.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 May 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 A Mobile IPv6 node requires a home agent(HA) address, a home 45 address(HOA), and IPsec security association with its HA before it 46 can start utilizing Mobile IPv6 service. RFC 3775 requires that some 47 or all of these parameters are statically configured. Ongoing work 48 aims to make this information dynamically available to the mobile 49 node. An important aspect of the Mobile IPv6 bootstrapping solution 50 is to support interworking with existing authentication, 51 authorization and accounting (AAA) infrastructure. This document 52 defines new attributes to facilitate Mobile IPv6 bootstrapping via a 53 RADIUS infrastructure. This information exchange may take place as 54 part of the initial network access authentication procedure or as 55 part of a separate protocol exchange between the mobile node, the HA 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. MIP6-Feature-Vector . . . . . . . . . . . . . . . . . . . 9 67 4.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9 68 4.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9 69 4.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9 70 4.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9 71 4.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 10 72 4.7. Use of existing RADIUS Attributes . . . . . . . . . . . . 10 73 4.7.1. User-Name . . . . . . . . . . . . . . . . . . . . . . 10 74 4.7.2. Service-Type . . . . . . . . . . . . . . . . . . . . . 10 75 4.7.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . 10 76 4.7.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . 10 77 4.7.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . 10 78 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. MIP6-Feature-Vector Attribute . . . . . . . . . . . . . . 11 80 5.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 12 81 5.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 13 82 5.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 14 83 5.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 15 84 5.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 16 85 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 18 86 6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 18 87 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 18 88 6.1.2. HA allocation in the ASP (visited network) . . . . . . 20 90 6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 20 91 6.2.1. Mobile Service Provider and Mobile Service 92 Authorizer are the same entity. . . . . . . . . . . . 20 93 6.2.2. Mobile Service Provider and Mobile Service 94 Authorizer are different entities. . . . . . . . . . . 23 95 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 24 96 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 24 97 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 24 98 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 25 99 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 25 100 7.5. Provisioning of Configuration Parameters . . . . . . . . . 25 101 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 26 102 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 27 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 105 11.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 29 106 11.2. New Registry: Mobility Capability . . . . . . . . . . . . 29 107 11.3. Addition of existing values . . . . . . . . . . . . . . . 29 108 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 31 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 113 Intellectual Property and Copyright Statements . . . . . . . . . . 34 115 1. Introduction 117 Mobile IPv6 specification [6] requires a Mobile Node (MN) to perform 118 registration with an HA with information about its current point of 119 attachment (Care-of Address). The HA creates and maintains binding 120 between the MN's HOA and the MN's Care-of Address. 122 In order to register with a HA, the MN needs to know some information 123 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 124 prefix Length and security related information in order to secure the 125 Binding Update. 127 The aforementioned set of information may be statically provisioned 128 in the MN. However, static provisioning of this information has its 129 drawbacks. It increases provisioning and network maintenance burden 130 for the operator. Moreover, static provisioning does not allow load 131 balancing, failover, opportunistic home link assignment etc. For 132 example, the user may be accessing the network from a location that 133 may be geographically far away from the preconfigured home link; the 134 administrative burden to configure the MN's with the respective 135 addresses is large and the ability to react on environmental changes 136 is minimal. In these situations static provisioning may not be 137 desirable. 139 Dynamic assignment of Mobile IPv6 home registration information is a 140 desirable feature for ease of deployment and network maintenance. 141 For this purpose, the RADIUS infrastructure, which is used for access 142 authentication, can be leveraged to assign some or all of the 143 necessary parameters. The RADIUS server in the Access Service 144 Provider (ASP) or in the Mobility Service Provider's (MSP) network 145 may return these parameters to the AAA client. The AAA client might 146 either be the NAS, in case of the integrated scenario, or the HA, in 147 case of the split scenario. The terms integrated and split are 148 described in the terminology section and were introduced in [7]. 150 2. Terminology 152 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [1]. 156 General mobility terminology can be found in [8]. The following 157 additional terms, as defined in [7], are used in this document: 159 Access Service Authorizer (ASA): 161 A network operator that authenticates a mobile node and 162 establishes the mobile node's authorization to receive Internet 163 service. 165 Access Service Provider (ASP): 167 A network operator that provides direct IP packet forwarding to 168 and from the end host. 170 Mobility Service Authorizer (MSA): 172 A service provider that authorizes Mobile IPv6 service. 174 Mobility Service Provider (MSP): 176 A service provider that provides Mobile IPv6 service. In order to 177 obtain such service, the MN must be authenticated and authorized 178 to obtain the Mobile IPv6 service. 180 Split Scenario: 182 A scenario where the mobility service and the network access 183 service are authorized by different entities. 185 Integrated Scenario: 187 A scenario where the mobility service and the network access 188 service are authorized by the same entity. 190 3. Solution Overview 192 This document addresses the authentication, authorization and 193 accounting functionality required by MIPv6 bootstrapping as outlined 194 in the MIPv6 bootstrapping problem statement document (see [7]). As 195 such, the AAA functionality for the integrated and the split scenario 196 needs to be defined. This requires the ability to offer support for 197 the HA to AAA server and the network access server(NAS) to AAA server 198 communication. 200 To highlight the main use cases, we briefly describe the integrated 201 and the split scenarios in Section 3.1 and Section 3.2, respectively. 203 3.1. Integrated Scenario 205 In the integrated scenario MIPv6 bootstrapping is provided as part of 206 the network access authentication procedure. Figure 1 shows the 207 participating entity. 209 +---------------------------+ +-----------------+ 210 |Access Service Provider | |ASA/MSA/(/MSP) | 211 |(Mobility Service Provider)| | | 212 | | | +-------+ | 213 | +-------+ | | |Remote | | 214 | |Local | RADIUS | | |RADIUS | | 215 | |RADIUS |-------------------------|Server | | 216 | |Proxy | | | +-------+ | 217 | +-------+ | | ^ | 218 | ^ ^ | | |RADIUS | 219 | | | | | | | 220 | | | | | v | 221 | RADIUS| | | +-------+ | 222 | | | +-------+ | | |Local | | 223 | | | RADIUS |Home | | | |Home | | 224 | | +------->|Agent | | | |Agent | | 225 | | |in ASP | | | +-------+ | 226 | v +-------+ | +-----------------+ 227 +-------+ IEEE | +-----------+ +-------+ | 228 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 229 |Node |----------+-|RADIUS |---|Server | | 230 | | PANA,... | |Client | | | | 231 +-------+ DHCP | +-----------+ +-------+ | 232 +---------------------------+ 234 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 236 In the typical Mobile IPv6 access scenario as shown above, the MN 237 attaches in the ASP's network. During this network attachment 238 procedure, the NAS/RADIUS client interacts with the MN. As shown in 239 Figure 1, the authentication and authorization happens via a RADIUS 240 infrastructure. 242 At the time of authorizing the user for IPv6 access, the RADIUS 243 server in the MSA detects that the user is authorized for Mobile IPv6 244 access. Based on the MSA's policy, the RADIUS server may allocate 245 several parameters to the MN for use during the subsequent Mobile 246 IPv6 protocol interaction with the HA. 248 Depending on the details of the solution interaction with the DHCPv6 249 server may be required, as described in [2]. 251 3.2. Split Scenario 253 In the split scenario, Mobile IPv6 bootstrapping is not provided as 254 part of the network access authentication procedure. The Mobile IPv6 255 bootstrapping procedure is executed with the Mobility Service 256 Provider when desired by the MN. Two variations can be considered: 258 1. the MSA and the MSP are the same entity. 260 2. the MSA and the MSP are different entities. 262 Since scenario (2) is the more generic scenario we show it in 263 Figure 2. 265 +----------------------+ 266 | | 267 |Mobility +-------+ | 268 |Service |Remote | | 269 |Authorizer |RADIUS | | 270 |(MSA) |Server | | 271 | +-------+ | 272 +---------------^------+ 273 | 274 |RADIUS 275 | 276 | 277 +---------------------------------|------+ 278 |Mobility Service Provider (MSP) v | 279 +-------+ | +-----------+ +-------+ | 280 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 281 |Node |-------------|RADIUS |-------------- |RADIUS | | 282 | | IKEv2 | |Client | |Proxy | | 283 +-------+ | +-----------+ +-------+ | 284 +----------------------------------------+ 286 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 287 MSP) 289 As shown in Figure 2 the interaction between the RADIUS client and 290 the RADIUS server is triggered by the protocol interaction between 291 the MN and the HA/RADIUS client using IKEv2 (see [3] and [9]). The 292 HA / RADIUS Client interacts with the RADIUS infrastructure to 293 perform authentication, authorization, accounting and parameter 294 bootstrapping. The exchange is triggered by the HA and an 295 interaction with the RADIUS infrastructure is initiated. When the 296 protocol exchange is completed then the HA needs to possess the 297 Mobile IPv6 specific parameters (see [7]). 299 Additionally, the MN might instruct the RADIUS server (via the HA) to 300 perform a dynamic DNS update. 302 4. RADIUS Attribute Overview 304 4.1. MIP6-Feature-Vector 306 The MIP6-Feature-Vector when included in an Access-Request packet is 307 used by the NAS to indicate supported MIP6 features. For example, 308 the NAS uses this attribute to indicate whether it can provide a 309 local home agent. 311 When included in an Access-Accept packet, the MIP6-Feature-Vector is 312 used by the RADIUS Server to indicate supported MIP6 features and to 313 select advetized feature by the NAS. For example, if the NAS 314 indicated support for local home agent assignment, the RADIUS server 315 authorizes the NAS to support local home agent assignment by echoing 316 the setting the same flag in the Access-Accept packet. 318 4.2. MIP6-HA Attribute 320 The RADIUS server may decide to assign a HA to the MN that is in 321 close proximity to the point of attachment (e.g., as determined by 322 the NAS-ID). There may be other reasons for dynamically assigning 323 HAs to the MN, for example to share the traffic load. The attribute 324 also contains the prefix length so that the MN can easily infer the 325 Home Link prefix from the HA address. 327 4.3. MIP6-HA-FQDN Attribute 329 The RADIUS server may assign an FQDN of the HA to the MN. The mobile 330 node can perform DNS query with the FQDN to derive the HA address. 332 4.4. MIP6-HL-Prefix Attribute 334 For the same reason as the HA assignment, the RADIUS server may 335 assign a Home Link that is in close proximity to the point of 336 attachment (NAS-ID). The MN can perform [6] specific procedures to 337 discover other information for Mobile IPv6 registration. 339 4.5. MIP6-HOA Attribute 341 The RADIUS server may assign a HOA to the MN. This allows the 342 network operator to support mobile devices that are not configured 343 with static addresses. The attribute also contains the prefix length 344 so that the MN can easily infer the Home Link prefix from the HA 345 address. 347 4.6. MIP6-DNS-MO Attribute 349 By using this payload the RADIUS client instructs the RADIUS server 350 to perform a dynamic DNS update. When this payload is included in 351 the reverse direction, i.e., from the RADIUS server to the RADIUS 352 client, it informs about the status of the dynamic DNS update. When 353 the payload is sent from the RADIUS client to the RADIUS server then 354 the response MUST include the MIP6-DNS-MO attribute. 356 4.7. Use of existing RADIUS Attributes 358 4.7.1. User-Name 360 If authentication via IKEv2 is used then the User-Name attribute 361 SHALL be set to the IDi payload received in the IKE_AUTH exchange. 363 4.7.2. Service-Type 365 If the HA uses Service-Type(6) is SHALL set its value to "Framed"(2). 367 4.7.3. NAS-Port-Type 369 In order for the AAA to distingiues the source of the Access-Request 370 NAS-Port-Type(61) is used as follows: 372 In the split scenario when the Access-Request originates from an MIP6 373 HA, NAS-Port-Type MUST be included and its value set to HA6(IANA- 374 TBD1). 376 4.7.4. Calling-Station-Id 378 In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) 379 to send the MN's COA to the AAA. If used, the string value of the 380 Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. 382 4.7.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 384 To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize 385 the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [4]. The 386 first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, 387 and the next up to 32 octets are stored into the MS-MPPE-Send-Key. 388 The encryption of these attributes is described in [4]. 390 5. RADIUS attributes 392 This section defines format and syntax for the attribute that carries 393 the Mobile IPv6 parameters that are described in the previous 394 section. 396 The attributes MAY be present in Access-Request, Access-Accept, and 397 Accounting-Request packets. 399 5.1. MIP6-Feature-Vector Attribute 401 Exactly one of this attribute MUST be sent by the NAS in an Access- 402 Request packet to inidcate support for MIP6. 404 Exactly one of this attribute MUST be sent by the RADIUS server in an 405 Access-Accept packet to indicate support for MIP6 and to select 406 features advetized by the NAS. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | MIP6 Features Vectors | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | MIP6 Features Vectors cont. | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MIP6 Features Vectors cont. | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Type: 420 MIP6-FV-TYPE to be defined by IANA. 422 Length: 424 = 10 octets 426 Feature Flags: 428 This field is of type String. Supporting the following values: 430 MIP6_INTEGRATED (0x0000000000000001) 432 When this flag is set by the NAS then it means that the 433 Mobile IPv6 integrated scenario bootstrapping functionality 434 is supported by the NAS. When this flag is set by the 435 Diameter server then the Mobile IPv6 integrated scenario 436 bootstrapping is supported by the RADIUS server. 438 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 440 When this flag is set by the NAS then a local home agent can 441 be assigned to the MN. When this flag is set by the 442 Diameter server then the assignment of location HAs is 443 authorized by the Diameter server. 445 5.2. MIP6-HA Attribute 447 One or more of this attribute MAY be sent by the NAS to the RADIUS 448 server in an Access-Request packet as a proposal by the NAS to 449 allocate a local HA to the MN. 451 One or more of this attribute MAY be sent by the RADIUS server to the 452 NAS in an Access-Accept packet. The attribute carries the HA address 453 that may be assigned to the MN. 455 [EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO 456 Attribute sent by the NAS to the RADIUS server in an Access-Request 457 packet as a hint to suggest a dynamic HA that may be assigned to the 458 MN. The RADIUS server MAY use this value or may ignore this 459 suggestion. 461 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 462 FQDN SHOULD appear in accounting packets to indicate the identity of 463 the serving HA for this session. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type | Length | Reserved | Prefix-Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | IPv6 address of assigned HA | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | IPv6 address of assigned HA cont. | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | IPv6 address of assigned HA cont. | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | IPv6 address of assigned HA cont. | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | IPv6 address of assigned HA cont. | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | IPv6 address of assigned HA cont. | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Type: 484 MIP6-HA-TYPE to be defined by IANA. 486 Length: 488 = 21 octets 490 Reserved: 492 Reserved for future use. The bits MUST be set to zero by the 493 sender, and MUST be ignored by the receiver. 495 Prefix-Length: 497 This field indicates the prefix length of the Home Link. 499 IPv6 address of assigned HA: 501 128-bit IPv6 address of the assigned HA. 503 5.3. MIP6-HA-FQDN Attribute 505 One or more instance of this attribute MAY be sent by the NAS to the 506 RADIUS server in an Access-Request packet as a hint to suggest a 507 dynamic HA that may be assigned to the MN. The RADIUS server MAY use 508 this value or may ignore this suggestion. 510 One or more of this attribute is sent by the RADIUS server to the NAS 511 in an Access-Accept packet. The attribute carries the FQDN of the 512 assigned HA. 514 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 515 MIP6-HA SHOULD appear in accounting packets to indicate the identity 516 of the serving HA for this session. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Length | FQDN of the assigned HA ..... 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Type: 526 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 528 Length: 530 Variable length. 532 FQDN of the assigned HA: 534 The data field MUST contain a FQDN as described in [10]. 536 5.4. MIP6-HL-Prefix Attribute 538 This attribute is sent by the RADIUS-MIP server to the NAS in an 539 Access-Accept packet. The attribute carries the assigned Home Link 540 prefix. 542 This attribute MAY be sent by the NAS to the RADIUS server in an 543 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 544 attribute as a hint to suggest a Home Link prefix that may be 545 assigned to the MN. The RADIUS server MUST use this value if it 546 accepts the NAS's HA suggestion. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | Length | Reserved | Prefix-Length | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 | | 555 | Home Link Prefix | 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Type: 561 ASSIGNED-HL-TYPE to be defined by IANA. 563 Length: 565 >= 4 octets + the minimum length of a prefix. 567 Reserved: 569 Reserved for future use. The bits MUST be set to zero by the 570 sender, and MUST be ignored by the receiver. 572 Prefix-Length: 574 This field indicates the prefix length of the Home Link. 576 Home Link Prefix: 578 Home Link prefix (upper order bits) of the assigned Home Link 579 where the MN should send binding update. 581 5.5. MIP6-HOA Attribute 583 This attribute is sent by the RADIUS server to the NAS in an Access- 584 Accept packet. The attribute carries the assigned Home IPv6 Address 585 for the MN. 587 This attribute MAY be sent by the NAS to the RADIUS server in an 588 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 589 attribute as a hint to suggest a Home Address that may be assigned to 590 the MN. The RADIUS server MUST use this value if it accepts the 591 NAS's HA suggestion. 593 If available at the NAS, this attribute SHOULD appear in the 594 accounting packets so that the IPv6 addressed used for this session 595 is known in the accounting stream. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type | Length | Reserved | Prefix-Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 | | 604 | Assigned IPv6 HOA | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Type: 610 ASSIGNED-HOA-TYPE to be defined by IANA. 612 Length: 614 = 20 octets. 616 Reserved: 618 Reserved for future use. The bits MUST be set to zero by the 619 sender, and MUST be ignored by the receiver. 621 Prefix-Length: 623 This field indicates the prefix length of the Home Link. 625 Assigned IPv6 HOA: 627 IPv6 HOA that is assigned to the MN. 629 5.6. MIP6-DNS-MO Attribute 631 The MIP6-DNS-MO attribute is used for triggering a DNS update by the 632 RADIUS server and to return the result to the RADIUS client. The 633 request MUST carry the MN's FQDN but the attribute carried in 634 response to the request MAY not carry a FQDN value. 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length | Reserved-1 | Status | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |R| Reserved-2 | FQDN ... 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Type: 646 DNS-UPDATE-TYPE to be defined by IANA. 648 Length: 650 Variable length. 652 Reserved-1: 654 Reserved for future use. The bits MUST be set to zero by the 655 sender, and MUST be ignored by the receiver. 657 Status: 659 This 8 bit unsigned integer field indicates the result of the 660 dynamic DNS update procedure as defined in [3]. This field 661 MUST be set to 0 and ignored by the RADIUS server when the 662 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 663 server. When the MIP6-DNS-MO is provided in the response, 664 values of the Status field less than 128 indicate that the 665 dynamic DNS update was performed successfully by the RADIUS 666 server. Values greater than or equal to 128 indicate that the 667 dynamic DNS update was not successfully completed. The 668 following values for the Status field are currently defined: 670 0 DNS update performed 672 128 Reason unspecified 674 129 Administratively prohibited 676 130 DNS Update Failed 678 R flag: 680 If this bit for the R flag is set then the RADIUS client 681 requests the RADIUS server to remove the DNS entry identified 682 by the FQDN included in this attribute. If not set, the RADIUS 683 client is requesting the RADIUS server to create or update a 684 DNS entry with the FQDN specified in this attribute and the 685 Home Address carried in another attribute specified in this 686 document. 688 Reserved-2: 690 Reserved for future use. The bits MUST be set to zero by the 691 sender, and MUST be ignored by the receiver. 693 FQDN of the MN: 695 In an Access-Request packet the data field MUST contain a FQDN. 696 In an Access-Accept packet the data field MAY contain an FQDN. 697 FQDN is described in [10]. 699 6. Message Flows 701 6.1. Integrated Scenario (MSA=ASA) 703 This section is based on [2] and uses the previously defined RADIUS 704 attributes. 706 6.1.1. HA allocation in the MSP 708 RADIUS is used to authenticate the MN, to authorize it for the 709 mobility service and to send information about the assigned HA to the 710 NAS. 712 | 713 --------------ASP------>|<--ASA+MSA-- 714 | 715 +----+ +------+ +-------+ +-------+ 716 | | |RADIUS| | | | | 717 | | |Client| | | | | 718 | MN | |NAS/ | | DHCP | |Home | 719 | | |DHCP | | Server| |RADIUS | 720 | | |Relay | | | |Server | 721 +----+ +------+ +-------+ +-------+ 722 | | | | 723 | 1 | 1 | | 724 |<------------->|----------------------->| 725 | | | | 726 | | 2 | | 727 | |<-----------------------| 728 | | | | 729 | 3 | | | 730 |-------------->| | | 731 | | | | 732 | | 4 | | 733 | |------------>| | 734 | | | | 735 | | 5 | | 736 | |<------------| | 737 | | | | 738 | 6 | | | 739 |<--------------| | | 740 | | | | 742 HA allocation in the MSP 744 In step (1), the MN executes the normal network access authentication 745 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 746 acts as an authenticator in "pass-through" mode, i.e., the endpoint 747 of the authentication dialogue is the MN's home RADIUS server. This 748 is the typical scenario in case the messages involved in the 749 authentication protocol are transported in EAP. 751 As per [11], the NAS encapsulates/decapsulates EAP packets into/from 752 RADIUS packets until an Access-Response (either an Access-Accept or 753 an Access/Reject packet is received by the NAS). This concludes the 754 network access authentication phase. 756 If the NAS has the ability to support MIP6 Bootstrapping it includes 757 the MIP6-Feature-Vector in the first Access-Request message and 758 indicates whether it supports MIP6 bootstrapping and/or local home 759 agent assignment by setting the appropriate flags therein. 761 If the NAS indicates support for Local home agent assignment, then it 762 may also include the MIP6-HA Attribute(s) and/or MIP6-HA-FQDN 763 Attribute(s) as a proposal to the RADIUS server of the HA to assign 764 in the ASP. 766 In step (2), the RADIUS server sends an Access-Accept packet with the 767 MIP6-Feature-Vector with the Local Home Agent Assignment flag set or 768 cleared. If the flag is cleared then the RADIUS server needs to 769 provide one or more Home Agent(s) to be assigned to the MN. If the 770 flag is set, then it indicates to the NAS that it can assign HA to 771 the MN; the RADIUS server may also include one or mroe HA addresses 772 thus indicating that the NAS can either allocate a local HA or one 773 specified by the RADIUS server. 775 In step (3) the MN sends a DHCPv6 Information Request message to 776 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 777 for the Home Network Identifier Option shall be included in that 778 message. The Home Network Identifier Option should have id-type of 779 1, the message is a request to discover home network information that 780 pertains to the given realm, i.e., the user's home domain (identified 781 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 782 identify itself to the DHCP server. 784 In step (4) the DHCP relay agent forwards this request to the DHCP 785 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 786 message. This option carries the RADIUS MIP6-HA Attribute from the 787 Access-Accept packet. If the NAS recieved the MIP6-HA-FQDN in the 788 Access-Accept it peforms a DNS lookup to resolve the MIP6-HA address. 790 In step (5), the DHCP server identifies the client (by DUID) and 791 finds out that it requests HA information in the MSP (by the Home 792 Network Identifier Option = 1). The DHCP server extracts the HA 793 address from OPTION_MIP6-RELAY-Option and places it into Home Network 794 Information Option in the Reply message. 796 In step (6), the Relay Agent forwards the Reply Message to the MN. 797 On reception of this message, the HA address or the FQDN of the HA is 798 available at the MN. 800 6.1.2. HA allocation in the ASP (visited network) 802 This scenario is similar to the one described in Section 6.1.1. The 803 difference is in step (4), where the type-id field in the Home 804 Network Identifier Option is set to zero, indicating that a HA is 805 requested in the ASP instead of in the MSP. Thus, the information 806 received by the home RADIUS server, via the DHCP relay, in the 807 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 808 server allocates a HA from its list of possible HAs and returns it in 809 the Reply message (Home Network Information Option). 811 6.2. Split Scenario (MSA!=ASA) 813 6.2.1. Mobile Service Provider and Mobile Service Authorizer are the 814 same entity. 816 The assumption in this scenario is that the MN has the domain name of 817 the MSP preconfigured. 819 In this scenario there is no relationship between the network access 820 authentication procedure and the MIPv6 bootstrapping procedure. 822 In order to learn the IP address of the HA, the MN either performs a 823 DNS lookup of the HA Name or a DNS lookup by service name. In the 824 first case, the MN is preconfigured with the FQDN of the HA, and thus 825 sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request 826 for IPv6 address of HA). A DNS reply message is returned by the DNS 827 server with the HA address. 829 The MN then runs IKEv2 [12] with the HA in order to set up IPsec SAs 830 (MN-HA). As part of this,the MN authenticates itself to the RADIUS 831 server in the MSA domain, and obtains authorization for mobility 832 service (including the Home Address). 834 The MN shares credentials with the RADIUS server in the MSA domain. 835 The RADIUS communication between the HA and the this RADIUS server is 836 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 837 within IKEv2 [12], the MN is authenticated and authorized for the 838 IPv6 mobility service and is also assigned a HOA. 840 The setup of SAs and mutual authentication between MN and AAAH using 841 RADIUS (and EAP) is similar to the one described for Diameter 842 protocol in [13]. The described mechanism ensureas that common 843 keying material will be available at the MN and HA after successful 844 completion. 846 ----------------------------ASP--------->|<-----MSA/MSP 848 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 849 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 850 +----+ +----+ +--------------------+ 852 MN HA Remote RADIUS server 853 -- -- -------------------- 854 IKE_SA_INIT 855 <------------------------------> 857 HDR, SK{IDi,[CERTREQ,] [IDr,] 858 SAi2, TSi, TSr} 859 -------------------------------> 860 RADIUS Access-Request(EAP-Response) 861 ----------------------------------> 862 RADIUS Access-Challenge(EAP-Request) 863 <----------------------------------- 864 HDR, SK {IDr, [CERT,] AUTH, 865 EAP } 866 <------------------------------- 867 HDR, SK {EAP} 868 --------------------------------> 869 RADIUS Access-Request(EAP-Response) 870 ----------------------------------> 871 RADIUS Access-Challenge(EAP-Request) 872 <----------------------------------- 873 HDR, SK{EAP-Request} 874 <------------------------------- 875 HDR, SK{EAP-Response} 876 --------------------------------> 877 RADIUS Access-Request(EAP-Response) 878 ----------------------------------> 879 ... ... 881 RADIUS Access-Accept(EAP-Success) 882 <------------------------ 884 HDR, SK{EAP-Success} 885 <------------------------------- 886 HDR, SK{AUTH} 887 -------------------------------> 888 HDR, SK {AUTH, SAr2, TSi, TSr } 889 <------------------------------- 891 Split Scenario Exchange 893 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 894 defined in the IKEv2 specification [12], negotiating crypto 895 algorithms and running DH key exchange). IKEv2 supports integration 896 with EAP. The MN indicates its desire to use EAP by not including 897 the AUTH payload in the third message. However, it indicates its 898 identity (NAI) by using the IDi field. If the HA supports EAP for 899 authentication, as per [11] it forwards the identity to the Remote 900 RADIUS server by sending a RADIUS Access-Request packet containing 901 the identity in the EAP-Payload AVP and in the RADIUS User-Name 902 attribute. Based on this identity, the Remote RADIUS server chooses 903 authentication method and sends the first EAP-Request in the RADIUS 904 Access-Challenge packet. During the EAP authentication phase, the HA 905 relays EAP packets between the MN and the Remote RADIUS server. If 906 the authentication succeeds and if the MN is authorized to use Mobile 907 IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept 908 packet containing the EAP-Success and the AAA-Key derived from the 909 EAP authentication method. EAP authentication methods that do not 910 derive keys are not recommended. This key is used by both MN and HA 911 to generate the AUTH payload. In subsequent messages, MN and HA 912 setup IPsec SAs for Mobile IPv6. 914 6.2.2. Mobile Service Provider and Mobile Service Authorizer are 915 different entities. 917 The HA address discovery is performed as described in Section 6.2.1. 919 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 921 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 922 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 923 +----+ +----+ |RADIUS| |RADIUS| 924 |Proxy | |Server| 925 +------+ +------+ 927 MSP#MSA Exchange 929 The scenario is similar to previously described scenarios with the 930 difference of utilizing AAA roaming agreements between the MSP and 931 the MSA. 933 7. Goals for the HA-AAA Interface 935 Here, we follow the classification and labels listed in the MIPv6- 936 AAA-Goals document [14]. 938 7.1. General Goals 940 G1.1-G1.4 Security 942 These are standard requirements for a AAA protocol - mutual 943 authentication, integrity, replay protection, confidentiality. IPsec 944 can be used to achieve the goals. Goal G1.5 regarding inactive peer 945 detection needs further investigations since heartbeat messages do 946 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 948 7.2. Service Authorization 950 G2.1. The AAA-HA interface should allow the use of Network Access 951 Identifier (NAI) to identify the MN. The User-Name attribute can be 952 used for the purpose to carry the NAI. 954 G2.2 The HA should be able to query the AAAH server to verify Mobile 955 IPv6 service authorization for the MN. Any node implementing RADIUS 956 functionality[5] can possibly initiate a request message. In 957 combination with the ability of the RADIUS protocol to carry EAP 958 messages [11] , our solution will enable an HA to query a RADIUS 959 server and verify MIPv6 authorization for the MN. 961 G2.3 The AAAH server should be able to enforce explicit operational 962 limitations and authorization restrictions on the HA (e.g., packet 963 filters, QoS parameters). Work in progress in the area, including 964 NAS-Filter-Rule, RADIUS quality of service support, prepaid 965 extensions etc. is performed. The relevant attributes may be reused 966 for providing required functionality over the AAAH-HA interface. 968 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 969 session by the AAAH server, e.g., authorization lifetime, extension 970 of the authorization lifetime and explicit session termination by the 971 AAAH server side. 973 The attribute Session-Timeout may be sent in Access-Challenge or 974 Access-Accept packet by the RADIUS server, thus limiting the 975 authorization session duration. In order to reauthenticate/ 976 reauthorize the user, the Termination-Action attribute can be 977 included, with value 1, meaning the NAS should send a new RADIUS- 978 Request packet. Additional AVPs for dealing with pre-paid sessions 979 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 980 specified in RADIUS prepaid extension. Exchanging of application 981 specific authorization request/answer messages provides extension of 982 the authorization session (e.g., Authorize Only Access-Request sent 983 by the HA (NAS) to the RADIUS server). Initiation of the re- 984 authorization by both sides could be supported. Both sides could 985 initiate session termination - the RADIUS server by sending 986 Disconnect message [15]. 988 7.3. Accounting 990 G3.1 The AAA-HA interface must support the transfer of accounting 991 records needed for service control and charging. These include (but 992 may not be limited to): time of binding cache entry creation and 993 deletion, octets sent and received by the MN in bi-directional 994 tunneling, etc. 996 The requirements for accounting over the AAAH-HA interface does not 997 require enhancements to the existing accounting functionality. 999 7.4. MN Authentication 1001 G4.1 The AAA-HA interface MUST support pass-through EAP 1002 authentication with the HA working as EAP authenticator operating in 1003 pass-through mode and the AAAH server working as back-end 1004 authentication server. 1006 These issues require the functionality of AAAH server working as a 1007 back-end authentication server and HA working as NAS and EAP 1008 authenticator in pass-through mode for providing a MN authentication. 1009 This document suggests this mode of operation in the context of the 1010 relevant scenarios. 1012 7.5. Provisioning of Configuration Parameters 1014 G5.1 The HA should be able to communicate to the AAAH server the HOA 1015 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 1016 update on behalf of the MN). 1018 This document describes needed AVPs for this purpose, see section 1019 "DNS Update Mobility Option Attribute" 1021 8. Table of Attributes 1023 The following tables provides a guide to which attributes may be 1024 found in RADIUS packet and in what number. 1026 The following defines the meaning of the notation used in the following 1027 tables: 1029 0 An instance of this attribute MUST NOT be present. 1030 1 Exactly one instance of this attribute MUST be present 1031 0-1 Zero or one instance of this attribute MAY be present. 1032 0+ Zero or more instance of this attriubte MAY be present 1034 Request Accept Reject Challenge Type Attribute 1035 1 1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1036 0+[ac] 0+[a] 0 0 MIP6-HA-TYPE MIP6-HA 1037 0+[ac] 0+[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN 1038 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix 1039 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1040 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO 1042 Notes: 1044 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 1046 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 1047 then these attributes MUST also be present in the Access-Request. 1048 If the RADIUS server accepts the NAS suggestion for the HA, then 1049 the RADIUS server MUST also include the values received for these 1050 attributes in the Access-Accept. 1052 [c] If these attributes are present in an Access-Request, then 1053 LOCAL_HOME_AGENT_ASSIGNMENT flag of the MIP6-Feature-Vector MUST be set. 1054 Otherwise these attributes are ignored. 1056 As used in accounting packets: 1058 Request Interim Stop Type Attribute 1060 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 1061 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 1062 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 1063 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 1064 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 1066 9. Diameter Considerations 1068 When used in Diameter, the attributes defined in this specification 1069 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 1070 attribute compatibility space). No additional Diameter Code values 1071 are therefore allocated. The data types and flag rules for the 1072 attributes are as follows: 1074 +---------------------+ 1075 | AVP Flag rules | 1076 |----+-----+----+-----|----+ 1077 | | |SHLD| MUST| | 1078 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 1079 -------------------------------|----+-----+----+-----|----| 1080 MIP6-HA Address | M | P | | V | Y | 1081 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 1082 MIP6-HL-Prefix OctetString| M | P | | V | Y | 1083 MIP6-HOA Address | M | P | | V | Y | 1084 MIP6-DNS-MO OctetString| M | P | | V | Y | 1085 -------------------------------|----+-----+----+-----|----| 1087 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 1088 have no special translation requirements for Diameter to RADIUS or 1089 RADIUS to Diameter gateways; they are copied as is, except for 1090 changes relating to headers, alignment, and padding. See also [16] 1091 Section 4.1 and [17] Section 9. MIP6-HA and HOA-IPv6 must be 1092 translated between their RADIUS representation of String to a 1093 Diameter Address format which requires that the AddressType field be 1094 set to 2 for IP6 (IP version 6) 1096 What this specification says about the applicability of the 1097 attributes for RADIUS Access-Request packets applies in Diameter to 1098 AA-Request [17] or Diameter-EAP-Request [18]. What is said about 1099 Access-Challenge applies in Diameter to AA-Answer [17] or Diameter- 1100 EAP-Answer [18] with Result-Code AVP set to 1101 DIAMETER_MULTI_ROUND_AUTH. 1103 What is said about Access-Accept applies in Diameter to AA-Answer or 1104 Diameter-EAP-Answer messages that indicate success. Similarly, what 1105 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1106 Answer or Diameter-EAP-Answer messages that indicate failure. 1108 What is said about Accounting-Request applies to Diameter Accounting- 1109 Request [17] as well. 1111 10. Security Considerations 1113 Assignment of these values to a user should be based on successful 1114 authentication of the user at the NAS and/or at the HA. The RADIUS 1115 server should only assign these values to a user who is authorized 1116 for Mobile IPv6 service (this check could be performed with the 1117 user's subscription profile in the Home Network). 1119 The NAS and the HA to the RADIUS server transactions must be 1120 adequately secured. Otherwise there is a possibility that the user 1121 may receive fraudulent values from a rogue RADIUS server potentially 1122 hijacking the user's Mobile IPv6 session. 1124 These new attributes do not introduce additional security 1125 considerations besides the ones identified in [5]. 1127 11. IANA Considerations 1129 11.1. Registration of new AVPs 1131 This specification defines the following new RADIUS attributes: 1133 MIP6-Feature-Vector is set to MIP6-FV-TYPE 1135 MIP6-HA is set to MIP6-HA-TYPE 1137 MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE 1139 MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE 1141 MIP6-HOA is set to MIP6-HOsA-TYPE 1143 MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE 1145 11.2. New Registry: Mobility Capability 1147 For MIP6-FV-TYPE flag values must be generated: 1149 Token | Value | Description 1150 ----------------------------------+----------------------+------------ 1151 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 1152 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 1153 Available for Assignment via IANA | 2^x | 1155 Allocation rule: Only numeric values that are 2^x (power of two) are 1156 allowed based on the allocation policy described below. 1158 Following the policies outlined in [1] new values with a description 1159 of their semantic for usage with the MIP6-Feature-Vector AVP together 1160 with a Token will be assigned after Expert Review initiated by the 1161 O&M Area Directors in consultation with the DIME working group chairs 1162 or the working group chairs of a designated successor working group. 1163 Updates can be provided based on expert approval only. A designated 1164 expert will be appointed by the O&M Area Directors. No mechanism to 1165 mark entries as "deprecated" is envisioned. Based on expert approval 1166 it is possible to delete entries from the registry. 1168 11.3. Addition of existing values 1170 A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) 1172 12. Acknowledgements 1174 We would like to thank the following individuals for their review and 1175 constructive comments during the development of this document: 1177 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1178 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1180 13. References 1182 13.1. Normative References 1184 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1185 Levels", BCP 14, RFC 2119, March 1997. 1187 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1188 Integrated Scenario", 1189 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1190 progress), July 2007. 1192 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1193 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 1194 July 2007. 1196 [4] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1197 RFC 2548, March 1999. 1199 [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1200 Authentication Dial In User Service (RADIUS)", RFC 2865, 1201 June 2000. 1203 13.2. Informative References 1205 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1206 IPv6", RFC 3775, June 2004. 1208 [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1209 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1211 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 1212 RFC 3753, June 2004. 1214 [9] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1215 IKEv2 and the revised IPsec Architecture", 1216 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1217 December 2006. 1219 [10] Mockapetris, P., "Domain names - implementation and 1220 specification", STD 13, RFC 1035, November 1987. 1222 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1223 In User Service) Support For Extensible Authentication Protocol 1224 (EAP)", RFC 3579, September 2003. 1226 [12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1227 RFC 4306, December 2005. 1229 [13] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", 1230 draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), 1231 October 2005. 1233 [14] Giaretta, G., "AAA Goals for Mobile IPv6", 1234 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1235 September 2006. 1237 [15] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1238 "Dynamic Authorization Extensions to Remote Authentication Dial 1239 In User Service (RADIUS)", RFC 3576, July 2003. 1241 [16] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1242 "Diameter Base Protocol", RFC 3588, September 2003. 1244 [17] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1245 Network Access Server Application", RFC 4005, August 2005. 1247 [18] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1248 Authentication Protocol (EAP) Application", RFC 4072, 1249 August 2005. 1251 [19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1252 "DNS Security Introduction and Requirements", RFC 4033, 1253 March 2005. 1255 [20] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1256 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1257 Agents", RFC 3776, June 2004. 1259 [21] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1260 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1261 April 1997. 1263 Authors' Addresses 1265 Avi Lior 1266 Bridgewater Systems 1267 303 Terry Fox Drive, Suite 100 1268 Ottawa, Ontario 1269 Canada K2K 3J1 1271 Phone: +1 613-591-6655 1272 Email: avi@bridgewatersystems.com 1274 Kuntal Chowdhury 1275 Starent Networks 1276 30 International Place 1277 Tewksbury, MA 01876 1278 US 1280 Phone: +1 214-550-1416 1281 Email: kchowdhury@starentnetworks.com 1283 Hannes Tschofenig 1284 Siemens 1285 Otto-Hahn-Ring 6 1286 Munich, Bavaria 81739 1287 Germany 1289 Email: Hannes.Tschofenig@siemens.com 1291 Full Copyright Statement 1293 Copyright (C) The IETF Trust (2007). 1295 This document is subject to the rights, licenses and restrictions 1296 contained in BCP 78, and except as set forth therein, the authors 1297 retain all their rights. 1299 This document and the information contained herein are provided on an 1300 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1301 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1302 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1303 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1304 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1305 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1307 Intellectual Property 1309 The IETF takes no position regarding the validity or scope of any 1310 Intellectual Property Rights or other rights that might be claimed to 1311 pertain to the implementation or use of the technology described in 1312 this document or the extent to which any license under such rights 1313 might or might not be available; nor does it represent that it has 1314 made any independent effort to identify any such rights. Information 1315 on the procedures with respect to rights in RFC documents can be 1316 found in BCP 78 and BCP 79. 1318 Copies of IPR disclosures made to the IETF Secretariat and any 1319 assurances of licenses to be made available, or the result of an 1320 attempt made to obtain a general license or permission for the use of 1321 such proprietary rights by implementers or users of this 1322 specification can be obtained from the IETF on-line IPR repository at 1323 http://www.ietf.org/ipr. 1325 The IETF invites any interested party to bring to its attention any 1326 copyrights, patents or patent applications, or other proprietary 1327 rights that may cover technology that may be required to implement 1328 this standard. Please address the information to the IETF at 1329 ietf-ipr@ietf.org. 1331 Acknowledgment 1333 Funding for the RFC Editor function is provided by the IETF 1334 Administrative Support Activity (IASA).