idnits 2.17.00 (12 Aug 2021) /tmp/idnits53105/draft-ietf-mip6-radius-05.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 1923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1947. 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 27 instances of too long lines in the document, the longest one being 8 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 (July 14, 2008) is 5058 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 1721 == Unused Reference: '13' is defined on line 1795, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1869, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1873, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1877, but no explicit reference was found in the text == Outdated reference: draft-ietf-mip6-bootstrapping-integrated-dhc has been published as RFC 6611 ** Downref: Normative reference to an Informational draft: draft-patel-mip6-rfc4285bis (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 3579 (ref. '6') == Outdated reference: draft-ietf-mip6-bootstrapping-split has been published as RFC 5026 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '8') ** Downref: Normative reference to an Informational draft: draft-zorn-radius-logoff (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '10') ** Obsolete normative reference: RFC 3588 (ref. '12') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '14') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-dime-mip6-split has been published as RFC 5778 == Outdated reference: draft-ietf-dime-mip6-integrated has been published as RFC 5447 == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '22') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '23') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '24') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '25') (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-mip6-hiopt has been published as RFC 6610 -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '30') (Obsoleted by RFC 7155) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 14 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: January 15, 2009 Starent Networks 6 H. Tschofenig 7 Siemens 8 July 14, 2008 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-05.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 January 15, 2009. 38 Abstract 40 This document defines new attributes to facilitate Mobile IPv6 41 operations using RADIUS infrastructure. The operations include 42 bootstrapping of information required by the Mobile Node and the 43 interface between the Network Access Server, Home Agent and the 44 RADIUS server used to assist MIP6 operations. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 51 3.1. RADIUS Transaction in Integrated Scenario . . . . . . . . 7 52 3.2. RADIUS Transactions in Split Scenario . . . . . . . . . . 8 53 4. Use of existing RADIUS Attributes . . . . . . . . . . . . . . 11 54 4.1. User-Name . . . . . . . . . . . . . . . . . . . . . . . . 11 55 4.2. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 11 56 4.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 11 57 4.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . . . 11 58 4.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . 11 59 4.6. Session-Timeout . . . . . . . . . . . . . . . . . . . . . 11 60 4.7. Message Authenticator . . . . . . . . . . . . . . . . . . 12 61 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 13 62 5.1. MIP6-Feature-Vector Attribute . . . . . . . . . . . . . . 13 63 5.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 14 64 5.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 16 65 5.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 16 66 5.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 17 67 5.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 19 68 5.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 20 69 5.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 21 70 5.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 22 71 5.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 22 72 5.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 23 73 5.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 23 74 5.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 24 75 5.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 25 76 5.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 25 77 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 27 78 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA) . . . . . . 27 79 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 27 80 6.1.2. HA allocation in the ASP (visited network) . . . . . . 29 81 6.2. Use of RADIUS In Split Scenario . . . . . . . . . . . . . 29 82 6.2.1. Split using IKEv2 . . . . . . . . . . . . . . . . . . 29 83 6.2.2. Split and Mobile IPv6 Authentication Protocol . . . . 33 84 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 37 85 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 37 86 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 37 87 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 38 88 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 38 89 7.5. Provisioning of Configuration Parameters . . . . . . . . . 38 90 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 39 91 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 42 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 94 11.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 44 95 11.2. New Registry: Mobility Capability . . . . . . . . . . . . 44 96 11.3. Addition of existing values . . . . . . . . . . . . . . . 44 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 99 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 100 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 102 Intellectual Property and Copyright Statements . . . . . . . . . . 50 104 1. Introduction 106 This document covers two aspects of MIP6 operations: bootstrapping of 107 information required by a Mobile IPv6 Mobile using the AAA 108 infrastructure and the interaction between the Network Access 109 Server(NAS), MIPv6 Home Agent (HA) and the Authentication 110 Authorization and Accounting (AAA) infrastructure. 112 Mobile IPv6 specification [14] requires a Mobile Node (MN) to perform 113 registration with an HA with information about its current point of 114 attachment (Care-of Address). The HA creates and maintains binding 115 between the MN's Home Address (HOA) and the MN's Care-of Address. 117 In order to register with a HA, the MN needs to know some information 118 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 119 prefix Length and security related information in order to secure the 120 Binding Update. 122 The aforementioned set of information may be statically provisioned 123 in the MN. However, static provisioning of this information has its 124 drawbacks. It increases provisioning and network maintenance burden 125 for the operator. Moreover, static provisioning does not allow load 126 balancing, failover, opportunistic home link assignment etc. For 127 example, the user may be accessing the network from a location that 128 may be geographically far away from the preconfigured home link; the 129 administrative burden to configure the MN's with the respective 130 addresses is large and the ability to react on environmental changes 131 is minimal. In these situations static provisioning may not be 132 desirable. 134 Dynamic assignment of Mobile IPv6 home registration information is a 135 desirable feature for ease of deployment and network maintenance. 136 For this purpose, the RADIUS infrastructure, which is used for access 137 authentication, can be leveraged to assign some or all of the 138 necessary parameters. The RADIUS server in the Access Service 139 Provider (ASP) or in the Mobility Service Provider's (MSP) network 140 may return these parameters to the AAA client. The AAA client might 141 either be the NAS, in case of the integrated scenario, or the HA, in 142 case of the split scenario. The terms integrated and split are 143 described in the terminology section and are introduced in [15]. 145 The second aspect of MIP6 and RADIUS interworking is the interaction 146 between the HA and the AAA using the RADIUS AAA protocols. From a 147 mobility service provider (MSP) perspective, it is important to 148 verify that the MN is authenticated and authorized to utilize Mobile 149 IPv6 service and that such services are accounted for. Thus, prior 150 to processing the Mobile IPv6 registrations, the HA, participates in 151 the authentication of the MN to verify the MN's identity. The HA 152 also participates in the Mobile IPv6 authorization process involving 153 the RADIUS infrastructure. The HA, due to its role in traffic 154 forwarding, may also perform accounting for the Mobile IPv6 service 155 provided to the MN. This document specifies the interaction between 156 the NAS, HA and the RADIUS server and aligns with the work done in 157 with the Diameter specifications described in [16] and [17]. 159 2. Terminology 161 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [1]. 165 General mobility terminology can be found in [18]. The following 166 additional terms, as defined in [15], are used in this document: 168 Access Service Authorizer (ASA): 170 A network operator that authenticates a mobile node and 171 establishes the mobile node's authorization to receive Internet 172 service. 174 Access Service Provider (ASP): 176 A network operator that provides direct IP packet forwarding to 177 and from the end host. 179 Mobility Service Authorizer (MSA): 181 A service provider that authorizes Mobile IPv6 service. 183 Mobility Service Provider (MSP): 185 A service provider that provides Mobile IPv6 service. In order to 186 obtain such service, the MN must be authenticated and authorized 187 to obtain the Mobile IPv6 service. 189 Split Scenario: 191 A scenario where the mobility service and the network access 192 service are authorized by different entities. 194 Integrated Scenario: 196 A scenario where the mobility service and the network access 197 service are authorized by the same entity. 199 3. Solution Overview 201 This document addresses the authentication, authorization and 202 accounting functionality required by MIPv6 bootstrapping and 203 Authentication as outlined in the MIPv6 bootstrapping problem 204 statement document (see [15]). As such, the AAA functionality for 205 the integrated and the split scenario needs to be defined. This 206 requires the ability to offer support for the HA to AAA server and 207 the network access server(NAS) to AAA server communication. 209 To highlight the main use cases, we briefly describe the integrated 210 and the split scenarios in Section 3.1 and Section 3.2, respectively. 212 3.1. RADIUS Transaction in Integrated Scenario 214 In the integrated scenario MIPv6 bootstrapping is provided as part of 215 the network access authentication procedure. Figure 1 shows the 216 participating entities. 218 +---------------------------+ +-----------------+ 219 |Access Service Provider | |ASA/MSA/(/MSP) | 220 |(Mobility Service Provider)| | | 221 | | | +-------+ | 222 | +-------+ | | |Remote | | 223 | |Local | RADIUS | | |RADIUS | | 224 | |RADIUS |-------------------------|Server | | 225 | |Proxy | | | +-------+ | 226 | +-------+ | | ^ | 227 | ^ ^ | | |RADIUS | 228 | | | | | | | 229 | | | | | v | 230 | RADIUS| | | +-------+ | 231 | | | +-------+ | | |Local | | 232 | | | RADIUS |Home | | | |Home | | 233 | | +------->|Agent | | | |Agent | | 234 | | |in ASP | | | +-------+ | 235 | v +-------+ | +-----------------+ 236 +-------+ IEEE | +-----------+ +-------+ | 237 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 238 |Node |----------+-|RADIUS |---|Server | | 239 | | PANA,... | |Client | | | | 240 +-------+ DHCP | +-----------+ +-------+ | 241 +---------------------------+ 243 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 245 In the typical Mobile IPv6 access scenario as shown above, the MN 246 attaches in the ASP's network. During this network attachment 247 procedure, the NAS/RADIUS client interacts with the MN. As shown in 248 Figure 1, the authentication and authorization happens via a RADIUS 249 infrastructure. 251 At the time of authorizing the user for IPv6 access, the RADIUS 252 server in the MSA detects that the user is authorized for Mobile IPv6 253 access. Based on the MSA's policy, the RADIUS server may allocate 254 several parameters to the MN for use during the subsequent Mobile 255 IPv6 protocol interaction with the HA. 257 Depending on the details of the solution, interaction with the DHCPv6 258 server may be required, as described in [2]. 260 3.2. RADIUS Transactions in Split Scenario 262 In the split scenario, Mobile IPv6 bootstrapping is not performed as 263 part of the network access authentication procedure. Other RADIUS 264 transactions such as authentication and authorization, accounting and 265 parameter configuration for MIP6 service is provided by the HA to 266 RADIUS transactions. 268 The Mobile IPv6 RADIUS transaction are executed with the Mobility 269 Service Provider when desired by the MN. Two scenarios can be 270 considered: 272 1. The MSA and the MSP are the same entity. 274 2. The MSA and the MSP are different entities. 276 Since scenario (2) is the more generic scenario we show it in 277 Figure 2. 279 +----------------------+ 280 | | 281 |Mobility +-------+ | 282 |Service |Remote | | 283 |Authorizer |RADIUS | | 284 |(MSA) |Server | | 285 | +-------+ | 286 +---------------^------+ 287 | 288 |RADIUS 289 | 290 | 291 +---------------------------------|------+ 292 |Mobility Service Provider (MSP) v | 293 +-------+ | +-----------+ +-------+ | 294 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 295 |Node |-------------|RADIUS |-------------- |RADIUS | | 296 | | IKEv2 | |Client | |Proxy | | 297 +-------+ | +-----------+ +-------+ | 298 +----------------------------------------+ 300 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 301 MSP) 303 As shown in Figure 2 the interaction between the RADIUS client and 304 the RADIUS server is triggered by the protocol interaction between 305 the MN and the HA/RADIUS client using IKEv2 [19] or MIPv6 306 Authentication Protocol [3]. The important aspect is, however, that 307 for these two approaches, several different authentication and key 308 exchange solutions are available. To establish IPsec security 309 associations for the protection of Mobile IPv6 signaling messages, 310 IKEv2 is used [19]. IKEv2 supports EAP-based authentication, 311 certificates and pre-shared secrets. For protection of MObile IPv6 312 signaling messages using the MIPv6 Authentication Protocol [3] a 313 mechanism has been designed that is very similar to the one used by 314 Mobile IPv4. 316 The ability to use different credentials has an impact on the 317 interaction between the HA (acting as a RADIUS client) and the RADIUS 318 Server. For that reason this document illustrates the usage of these 319 authentication mechanisms with different subsections for: 321 o IKEv2 usage with EAP 323 o IKEv2 usage with certificates and pre-shared secrets 325 o MIPv6 Authentication Protocol 326 For accounting of Mobile IPv6 services provided to the MN, this 327 specification uses the RADIUS based accounting defined in [4]. 329 Additionally, the MN might instruct the RADIUS server (via the HA) to 330 perform a dynamic DNS update. 332 4. Use of existing RADIUS Attributes 334 4.1. User-Name 336 If authentication via IKEv2 is used then the User-Name attribute 337 SHALL be set to the IDi payload received in the IKE_AUTH exchange. 338 In the case of the Mobile IPv6 Authentication Protocol the User- 339 Name(1) attribute is set to the value received in the MN-NAI mobility 340 option as defined in [20]. 342 4.2. Service-Type 344 The HA uses Service-Type(6) to indicate whether the Access-Request 345 operation is for Authentication and Authorization or just 346 Authorization. 348 4.3. NAS-Port-Type 350 In order for the AAA to distinguish the source of the Access-Request 351 NAS-Port-Type(61) is used as follows: 353 When the Access-Request originates from an MIP6 HA, NAS-Port-Type 354 MUST be included and its value set to HA6(IANA-TBD1). 356 4.4. Calling-Station-Id 358 In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) 359 to send the MN's COA to the AAA. If used, the string value of the 360 Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. 362 4.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 364 To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize 365 the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. The 366 first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, 367 and the next up to 32 octets are stored into the MS-MPPE-Send-Key. 368 The encryption of these attributes is described in [5]. 370 4.6. Session-Timeout 372 The use of Session-Timeout attribute during bootstrapping operations 373 is covered by various RFC's. 375 The use of Session-Timeout attribute during the EAP exchanges between 376 the HA and the RADIUS server are as per [6]. 378 In the case of the RADIUS server sending Session-Timeout to the HA in 379 the Access-Accept packet, the HA SHALL use this time as the MIP 380 Registration Lifetime. 382 4.7. Message Authenticator 384 The use of Message Authenticator is mandated during EAP AAA 385 procedures by [6]. In the case of the HA sending an Access-Request 386 where EAP is not used, then the HA MUST also include the Message 387 Authenticator attribute in the Access-Request packet. 389 5. RADIUS attributes 391 This section defines format and syntax for the attribute that carries 392 the Mobile IPv6 parameters that are described in the previous 393 section. 395 The attributes MAY be present in Access-Request, Access-Accept, and 396 Accounting-Request packets. 398 5.1. MIP6-Feature-Vector Attribute 400 Exactly one of this attribute MUST be sent by the NAS or HA in an 401 Access-Request packet to inidcate support for MIP6. For example, a 402 NAS uses this attribute to indicate whether it can provide a local 403 home agent. 405 Exactly one of this attribute MUST be sent by the RADIUS server in an 406 Access-Accept packet to indicate support for MIP6 and to select 407 features advetized by the NAS or the HA. For example, if the NAS 408 indicated support for local home agent assignment, the RADIUS server 409 authorizes the NAS to support local home agent assignment by echoing 410 the setting the same flag in the Access-Accept packet. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Length | MIP6 Features Vectors | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | MIP6 Features Vectors cont. | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | MIP6 Features Vectors cont. | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Type: 424 MIP6-FV-TYPE to be defined by IANA. 426 Length: 428 = 10 octets 430 Feature Flags: 432 This field is of type String. Supporting the following values: 434 MIP6_INTEGRATED (0x0000000000000001) 435 When this flag is set by the NAS then it means that the 436 Mobile IPv6 integrated scenario bootstrapping functionality 437 is supported by the NAS. When this flag is set by the 438 RADIUS server then the Mobile IPv6 integrated scenario 439 bootstrapping is supported by the RADIUS server. 441 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 443 When this flag is set by the NAS then a local home agent can 444 be assigned to the MN. When this flag is set by the 445 Diameter server then the assignment of location HAs is 446 authorized by the Diameter server. 448 RO_SUPPORTED (0x0000000800000000) 450 Route optimization is supported. When the Home Agent sets 451 this bit, it indicates support for the route optimization. 452 If this bit is unset in the returned Mobility-Capability 453 AVP, the HAAA does not authorize route optimization for the 454 MN. 456 In a case the Home Agent or the HAAA cannot authorize the 457 use of route optimization then the Home Agent will send a 458 Binding Acknowledgement with a Status Code set to 459 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This 460 Status Code indicates that the binding registration 461 succeeded but the Home Agent will fail all possible 462 subsequent route optimization attempts because of 463 subscription or operator policy. 465 5.2. MIP6-HA Attribute 467 In the case of bootstrapping, the RADIUS server may decide to assign 468 a HA to the MN that is in close proximity to the point of attachment 469 (e.g., as determined by the NAS-ID). There may be other reasons for 470 dynamically assigning HAs to the MN, for example to share the traffic 471 load. The attribute also contains the prefix length so that the MN 472 can easily infer the Home Link prefix from the HA address. 474 In the case of bootstrapping, one or more of this attribute MAY be 475 sent by the NAS to the RADIUS server in an Access-Request packet as a 476 proposal by the NAS to allocate a local HA to the MN. 478 In the case of bootstrapping, one or more of this attribute MAY be 479 sent by the RADIUS server to the NAS in an Access-Accept packet. The 480 attribute carries the HA address that may be assigned to the MN. 482 [EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO 483 Attribute sent by the NAS to the RADIUS server in an Access-Request 484 packet as a hint to suggest a dynamic HA that may be assigned to the 485 MN. The RADIUS server MAY use this value or may ignore this 486 suggestion. 488 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 489 FQDN SHOULD appear in accounting packets to indicate the identity of 490 the serving HA for this session. 492 In the case of split, the MIP6-HA attribute contains the IPv6 address 493 of the Home Agent as received in the BU message. One and only one of 494 this attribute SHALL be sent by the HA to the RADIUS server. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | Reserved | Prefix-Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | IPv6 address of assigned HA | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IPv6 address of assigned HA cont. | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | IPv6 address of assigned HA cont. | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | IPv6 address of assigned HA cont. | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | IPv6 address of assigned HA cont. | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | IPv6 address of assigned HA cont. | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Type: 516 MIP6-HA-TYPE to be defined by IANA. 518 Length: 520 = 28 octets 522 Reserved: 524 Reserved for future use. The bits MUST be set to zero by the 525 sender, and MUST be ignored by the receiver. 527 Prefix-Length: 529 This field indicates the prefix length of the Home Link. 531 IPv6 address of assigned HA: 533 128-bit IPv6 address of the assigned HA. 535 5.3. MIP6-HA-FQDN Attribute 537 In the case of bootstrapping, one or more instance of this attribute 538 MAY be sent by the NAS to the RADIUS server in an Access-Request 539 packet as a hint to suggest a dynamic HA that may be assigned to the 540 MN. The RADIUS server MAY use this value or may ignore this 541 suggestion. 543 In the case of bootstrapping, one or more of this attribute is sent 544 by the RADIUS server to the NAS in an Access-Accept packet. The 545 attribute carries the FQDN of the assigned HA. The mobile node can 546 perform DNS query with the FQDN to derive the HA address. 548 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 549 MIP6-HA SHOULD appear in accounting packets to indicate the identity 550 of the serving HA for this session. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type | Length | FQDN of the assigned HA ..... 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Type: 560 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 562 Length: 564 Variable length. 566 FQDN of the assigned HA: 568 The data field MUST contain a FQDN as described in [21]. 570 5.4. MIP6-HL-Prefix Attribute 572 In the case of bootstrapping, this attribute MAY be sent by the NAS 573 to the RADIUS server in an Access-Request packet along with the 574 MIP6-HA and/or MIP6-HA-FQDN attribute as a hint to suggest a Home 575 Link prefix that may be assigned to the MN. The RADIUS server MUST 576 use this value if it accepts the NAS's HA suggestion. 578 In the case of bootstrapping, this attribute is sent by the RADIUS 579 server to the NAS in an Access-Accept packet and carries the assigned 580 Home Link prefix that is in close proximity to the point of 581 attachment (NAS-ID). The MN can perform [14] specific procedures to 582 discover other information for Mobile IPv6 registration. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Length | Reserved | Prefix-Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 | | 591 | Home Link Prefix | 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Type: 597 ASSIGNED-HL-TYPE to be defined by IANA. 599 Length: 601 >= 4 octets + the minimum length of a prefix. 603 Reserved: 605 Reserved for future use. The bits MUST be set to zero by the 606 sender, and MUST be ignored by the receiver. 608 Prefix-Length: 610 This field indicates the prefix length of the Home Link. 612 Home Link Prefix: 614 Home Link prefix (upper order bits) of the assigned Home Link 615 where the MN should send binding update. 617 5.5. MIP6-HOA Attribute 619 In the bootstrapping case, this attribute is sent by the RADIUS 620 server to the NAS in an Access-Accept packet. The attribute carries 621 the assigned Home IPv6 Address for the MN. This allows the network 622 operator to support mobile devices that are not configured with 623 static addresses. The attribute also contains the prefix length so 624 that the MN can easily infer the Home Link prefix from the HA 625 address. 627 This attribute MAY be sent by the NAS to the RADIUS server in an 628 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 629 attribute as a hint to suggest a Home Address that may be assigned to 630 the MN. The RADIUS server MUST use this value if it accepts the 631 NAS's HA suggestion. 633 In the case of split, in Access-Request packet, the MIP6-HOA contains 634 the IPv6 Home Address assigned by the HA to the MN. If the MIP6-HOA 635 AVP contains unspecified IPv6 address (0::0), then the Home Agent 636 expects the RADIUS server to assign the Home Address in a subsequent 637 Access-Accept packet. In case the RADIUS server assigns only a Home 638 Network Prefix to the Mobile Node the lower 64 bits of the MIP- 639 Mobile-Node-Address AVP provided address MUST be set to zero. 641 If available at the NAS, this attribute SHOULD appear in the 642 accounting packets so that the IPv6 addressed used for this session 643 is known in the accounting stream. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Type | Length | Reserved | Prefix-Length | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | | 651 | | 652 | Assigned IPv6 HOA | 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Type: 658 ASSIGNED-HOA-TYPE to be defined by IANA. 660 Length: 662 = 20 octets. 664 Reserved: 666 Reserved for future use. The bits MUST be set to zero by the 667 sender, and MUST be ignored by the receiver. 669 Prefix-Length: 671 This field indicates the prefix length of the Home Link. 673 Assigned IPv6 HOA: 675 IPv6 HOA that is assigned to the MN. 677 5.6. MIP6-DNS-MO Attribute 679 In the case of bootstrapping, the MIP6-DNS-MO attribute is included 680 by the NAS in an Access-Request packet and MUST set its value to the 681 MN's FQDN to indicate to the RADIUS server to perform a dynamic DNS 682 update. Upon receiving this attribute, the RADIUS server SHALL 683 perform a dynamic update of the DNS and MUST inlcude the MIP6-DNS-MO 684 attribute in the Access-Accept indicating the result of the dynmaic 685 DNS update. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | Reserved-1 | Status | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |R| Reserved-2 | FQDN ... 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Type: 697 DNS-UPDATE-TYPE to be defined by IANA. 699 Length: 701 Variable length. 703 Reserved-1: 705 Reserved for future use. The bits MUST be set to zero by the 706 sender, and MUST be ignored by the receiver. 708 Status: 710 This 8 bit unsigned integer field indicates the result of the 711 dynamic DNS update procedure as defined in [7]. This field 712 MUST be set to 0 and ignored by the RADIUS server when the 713 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 714 server. When the MIP6-DNS-MO is provided in the response, 715 values of the Status field less than 128 indicate that the 716 dynamic DNS update was performed successfully by the RADIUS 717 server. Values greater than or equal to 128 indicate that the 718 dynamic DNS update was not successfully completed. The 719 following values for the Status field are currently defined: 721 0 DNS update performed 723 128 Reason unspecified 725 129 Administratively prohibited 727 130 DNS Update Failed 729 R flag: 731 If this bit for the R flag is set then the RADIUS client 732 requests the RADIUS server to remove the DNS entry identified 733 by the FQDN included in this attribute. If not set, the RADIUS 734 client is requesting the RADIUS server to create or update a 735 DNS entry with the FQDN specified in this attribute and the 736 Home Address carried in another attribute specified in this 737 document. 739 Reserved-2: 741 Reserved for future use. The bits MUST be set to zero by the 742 sender, and MUST be ignored by the receiver. 744 FQDN of the MN: 746 In an Access-Request packet the data field MUST contain a FQDN. 747 In an Access-Accept packet the data field MAY contain an FQDN. 748 FQDN is described in [21]. 750 5.7. MIP6-Careof-Address 752 In the case of split, this attribute is sent from the HA to the 753 RADIUS Server and contains the IPv6 addresss of the Care-of Address 754 of the MN extracted from the BU message. 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type | Length | Reserved | Prefix-Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 | | 763 | Assigned IPv6 COA | 764 | | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Type: 768 ASSIGNED-MIP6-CAREOF-ADDRESS-TYPE to be defined by IANA. 770 Length: 772 = 20 octets. 774 Reserved: 776 Reserved for future use. The bits MUST be set to zero by the 777 sender, and MUST be ignored by the receiver. 779 Prefix-Length: 781 This field indicates the prefix length of the COA Link. 783 Assigned IPv6 COA: 785 IPv6 COA that is assigned to the MN. 787 5.8. MIP6-MN-AAA-SPI 789 In the case of split, this attribute MUST be present in an Access- 790 Request sent from the HA to the RADIUS Server when using MIPv6 791 Authentication Protocol. The MIP6-MN-AAA-SPI attribute contains an 792 SPI code extracted from the Mobility Message Authentication Option 793 included in the received BU message. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type | Length | SPI | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | SPI cont. | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Type: 805 ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA. 807 Length: 809 6 octets 811 Integer representing a Security Parameter Index. 813 5.9. MIP6-Authenticator 815 In the case of split, this attribute is sent from the HA to the 816 RADIUS server and contains the Authenticator data from the BU 817 message. The HA extract the data form the MN-AAA Mobility Message 818 Authentication Option if included in the received BU message. 820 Upon receiving this attribute from the HA, the RADIUS server computes 821 its own version of the Authenticator Data from the received MIP6-MAC- 822 Mobility-Data (see below) and compares it to the value received in 823 the MIP6-Authenticator from the HA. If the values match then the 824 Mobile Node is authenticated. 826 In the case of split, this attribute MUST be present in an Access- 827 Request sent from the HA to the RADIUS Server when using MIPv6 828 Authentication Protocol. 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Type | Length | Authenticator Data | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Authenticator Data cont .... 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Type: 840 ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA. 842 Length: 844 Variable length 846 String. An OctetString representing authenticator data. 848 5.10. MIP6-MAC-Mobility-Data 850 In the case of split, the MIP6-MAC-Mobility-Data attribute is sent 851 from the HA to the RADIUS Server. The attribute contains the 852 calculated MAC_Mobility_Data as defined in [3]. 854 This attribute MUST be present in an Access-Request sent from the HA 855 to the RADIUS Server when using MIPv6 Authentication Protocol. 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Length | MAC Mobility Data | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | MAC Mobility Data cont .... 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Type: 867 ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA. 869 Length: 871 Variable length 873 String. An OctetString representing authenticator data. 875 5.11. MIP6-Timestamp 877 The MIP6-Timestamp contains the timestamp value from the Mobility 878 message replay protection option, defined in [3]. The Home Agent 879 extracts this value from the received BU message, if available. 881 The support for replay protection is an optional feature in [3]. 882 When the RADIUS server checks the timestamp provided by the MN via 883 the HA and recognizes a clock-drift (outside a locally defined replay 884 protection window) then it MUST initiate the re-synchronization 885 procedure by returning an Access-Accept packet with Result-Code set 886 to MIP6-TIMESTAMP-MISMATCH and attaches the MIP6-Timestamp including 887 it's current time back to the HA. 889 In the case of split, this attribute is sent from the HA to the 890 RADIUS server when performing MIP6 Authentication protocol. The 891 attribute MUST appear in the Access-Request if the attribute is 892 present in the Mobility message replay protection. Otherwise the 893 attribute MUST NOT appear in the Access-Request packet. 895 [EDITOR'S NOTE] there is an issue here. In the diameter protocol, if 896 there is a time mismatch we return a result code that states that 897 there was a time mismatch and we return this value. In RADIUS land 898 we return an Access-Reject but we cant really return any other 899 attributes. 901 5.12. MIP6-MN-HA-SPI 903 In the case of split, the MIP6-MN-HA-SPI available to be sent in an 904 Access-Accept packet from the RADIUS server to he HA. It is part of 905 a group of attributes used with the MIPv6 Authentication Protocol and 906 contains the Security Parameter Index used to reference the MN-HA 907 mobility security association. 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Type | Length | SPI | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | SPI cont. | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Type: 919 ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA. 921 Length: 923 6 octets 925 Integer representing a Security Parameter Index. 927 5.13. MIP6-Algorithm-Type 929 In the case of split, the MIP6-Algorithm-Type is available to be sent 930 in an Access-Accept packet from the RADIUS server to the HA. It is 931 part of a group of attributes used with the MIPv6 Authentication 932 protocol and contains the algorithm type. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Type | Length | enumeration | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | enumeration cont. | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Type: 944 ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA. 946 Length: 948 6 octets 950 Integer representing an enumeration as supported by [22]: 952 2: HMAC-SHA-1 [8] 954 5.14. MIP6-Replay-Mode 956 In the case of split, the MIP6-Replay-Mode is available to be sent in 957 an Access-Accept packet from the RADIUS server to the HA. It is part 958 of a group of attribute used with the MIPv6 Authentication protocol 959 and contains the replay mode as defined in RFC4004 to be used by the 960 HA. 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Type | Length | enumeration | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | enumeration cont. | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Type: 972 ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA. 974 Length: 976 6 octets 978 Integer representing an enumeration as supported by [22]: 980 1: None. 982 2: Timestamps. 984 3: Nonces. 986 5.15. MIP6-Nonce 988 In the case of split, the MIP6-Nonce is available to be sent in an 989 Access-Accept packet from the RADIUS Server to the HA. It is part of 990 a group of attributes used with the MIPv6 Authentication protocol and 991 contains the nonce to send to the MN. 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Type | Length | nonce | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | .... 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Type: 1002 ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA. 1004 Length: 1006 Variable length 1008 String. A binary string representing a nonce. 1010 6. Message Flows 1012 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA) 1014 This section is based on [2] and uses the RADIUS attributes that are 1015 defined in this document. 1017 6.1.1. HA allocation in the MSP 1019 RADIUS is used to authenticate the MN, to authorize it for the 1020 mobility service and to send information about the assigned HA to the 1021 NAS. 1023 | 1024 --------------ASP------>|<--ASA+MSA-- 1025 | 1026 +----+ +------+ +-------+ +-------+ 1027 | | |RADIUS| | | | | 1028 | | |Client| | | | | 1029 | MN | |NAS/ | | DHCP | |Home | 1030 | | |DHCP | | Server| |RADIUS | 1031 | | |Relay | | | |Server | 1032 +----+ +------+ +-------+ +-------+ 1033 | | | | 1034 | 1 | 1 | | 1035 |<------------->|----------------------->| 1036 | | | | 1037 | | 2 | | 1038 | |<-----------------------| 1039 | | | | 1040 | 3 | | | 1041 |-------------->| | | 1042 | | | | 1043 | | 4 | | 1044 | |------------>| | 1045 | | | | 1046 | | 5 | | 1047 | |<------------| | 1048 | | | | 1049 | 6 | | | 1050 |<--------------| | | 1051 | | | | 1053 Figure 3: HA allocation in the MSP 1055 In step (1), the MN executes the network access authentication 1056 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 1057 acts as an authenticator in "pass-through" mode, i.e., the endpoint 1058 of the authentication dialogue is the MN's home RADIUS server. This 1059 is the typical scenario in case the messages involved in the 1060 authentication protocol are transported in EAP. 1062 As per [6], the NAS encapsulates/de-capsulates EAP packets into/from 1063 RADIUS packets until an Access-Response (either an Access-Accept or 1064 an Access/Reject packet is received by the NAS). This concludes the 1065 network access authentication phase. 1067 If the NAS has the ability to support MIP6 Bootstrapping it includes 1068 the MIP6-Feature-Vector in the first Access-Request message and 1069 indicates whether it supports MIP6 bootstrapping and/or local home 1070 agent assignment by setting the appropriate flags therein. 1072 If the NAS indicates support for local home agent assignment, then it 1073 may also include the MIP6-HA attribute(s) and/or MIP6-HA-FQDN 1074 attribute(s) as a proposal to the RADIUS server to indicate that the 1075 HA is to be assigned in the ASP. 1077 In step (2), the RADIUS server sends an Access-Accept packet with the 1078 MIP6-Feature-Vector with the Local Home Agent Assignment flag set or 1079 cleared. If the flag is cleared then the RADIUS server needs to 1080 provide one or more Home Agent(s) to be assigned to the MN. If the 1081 flag is set, then it indicates to the NAS that it can assign HA to 1082 the MN; the RADIUS server may also include one or more HA addresses 1083 thus indicating that the NAS can either allocate a local HA or one 1084 specified by the RADIUS server. 1086 In step (3) the MN performs home information discovery procedures as 1087 specified in [DHCPv6 for Home Info Discovery in MIPv6][hiopt]. The 1088 MN sends a DHCPv6 Information-request message including the Home 1089 Network Information option according to the stateless DHCPv6 1090 procedures [23] and [24]. The MN MUST also include the Option code 1091 for the Home Network Information option in the Option Request option 1092 in the request. The id-type of the Home Network Identifier Option is 1093 set to 1 indicating that the MN is requesting to discover the home 1094 network information that pertains to the given realm, i.e., the 1095 user's home domain (identified by the NAI of the MN). The 1096 OPTION_CLIENTID is set by the MN to identify itself to the DHCP 1097 server. 1099 In step (4) the DHCP relay agent forwards this request to the DHCP 1100 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 1101 message. This option carries the RADIUS MIP6-HA attribute received 1102 in the Access-Accept packet. 1104 In step (5), the DHCP server identifies the client (by DUID) and 1105 finds out that it requests HA information in the MSP (by the Home 1106 Network Identifier Option = 1). The DHCP server extracts the HA 1107 address from OPTION_MIP6-RELAY-Option and places it into Home Network 1108 Information Option in the Reply message. 1110 In step (6), the Relay Agent forwards the Reply Message to the MN. 1111 On reception of this message, the HA address or the FQDN of the HA is 1112 available at the MN. 1114 6.1.2. HA allocation in the ASP (visited network) 1116 This scenario is similar to the one described in Section 7.1.1. The 1117 difference is in step (4), where the type-id field in the Home 1118 Network Identifier Option is set to zero, indicating that a HA is 1119 requested in the ASP instead of in the MSP. Thus, the information 1120 received by the home RADIUS server, via the DHCP relay, in the 1121 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 1122 server allocates a HA from its list of possible HAs and returns it in 1123 the Reply message (Home Network Information Option). 1125 6.2. Use of RADIUS In Split Scenario 1127 In this section we present the call flows used in the Split scenario. 1128 In the Split scenario the MN can be authenticated and authorized for 1129 Mobile IPv6 by using IKEv2 or the Mobile IPv6 Authentication Protocol 1130 [3]. The authentication and or authorization takes place between the 1131 HA and the RADIUS server. 1133 6.2.1. Split using IKEv2 1135 This section describes IKEv2 based authentication and authorization 1136 for the SPLIT scenario using IKEv2 and EAP and IKEv2 with 1137 Certificates and Preshared Keys. 1139 6.2.1.1. IKEv2 and EAP 1141 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 1142 authenticate the MN. When EAP is used with IKEv2, the RADIUS EAP 1143 procedures, as defined in [6], are used. EAP methods that do not 1144 establish a shared key SHOULD NOT be used, as they are subject to a 1145 number of man-in-the-middle attacks as stated in Section 2.16 and 1146 Section 5 of RFC 4306 [25]. Attributes specific to Mobile IPv6 1147 bootstrapping are added to the AAA packets. 1149 Figure 4 shows the message flow involved during the authentication 1150 phase when EAP is used. 1152 ----------------------------ASP--------->|<-----MSA/MSP 1154 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 1155 | MN |<----------->| HA |<-------------------->| Home RADIUS Server | 1156 +----+ +----+ +--------------------+ 1158 Mobile Home RADIUS 1159 Node Agent Server 1160 | | | 1161 | HDR, SAi1, KEi, Ni (1) | | 1162 |-------------------------------->| | 1163 | | | 1164 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 1165 |<--------------------------------| | 1166 | | | 1167 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 1168 | [CP(CFG_REQUEST),] | | 1169 | SAi2, TSi, TSr} (3) | | 1170 |-------------------------------->| Access-Request | 1171 | | (EAP-Response) (4) | 1172 | |-------------------------->| 1173 | | | 1174 | | Access-Challenge | 1175 | | (EAP-Request) (5) | 1176 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<--------------------------| 1177 |<------------------------------- | | 1178 | | | 1179 | HDR, SK{EAP} | | 1180 |-------------------------------->|Access-Request(EAP-Res.) | 1181 | |-------------------------->| 1182 | | | 1183 | |Access-Challenge(EAP-Req.) | 1184 | HDR, SK{EAP-Request} |<--------------------------| 1185 |<--------------------------------| | 1186 | | | 1187 | HDR, SK{EAP-Response} | | 1188 |-------------------------------->|Access-Request (EAP-Res.) | 1189 | |-------------------------->| 1190 | ... | ... | 1191 | | | 1192 | |Access-Accept(EAP-Success) | 1193 | (6)|<--------------------------| 1194 | HDR, SK{EAP-Success} | | 1195 |<--------------------------------| | 1196 | | | 1197 | HDR, SK{AUTH} | | 1198 |-------------------------------->| | 1199 | | | 1200 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 1201 | SAr2, TSi, TSr} | | 1202 |<--------------------------------| | 1203 | | | 1205 Figure 4: Split Scenario Exchange Using IKEv2 and EAP 1207 Before this scenario started the MN has to know the IP address of the 1208 HA to use. The MN may be configured with the HA-IP address or the 1209 FQDN of the HA to use or with a mobility service name. In the case 1210 where the MN is configured with the domain name of the HA or a 1211 mobility service name, it uses DNS to resolve the IP address of the 1212 HA to use. Alternatively, MN could have received the information by 1213 performing a DHCP request as per [26] 1215 The MN and the HA start the interaction with an IKE_SA_INIT 1216 exchange(1)(2). In this phase cryptographic algorithms are 1217 negotiated, nonces and Diffie-Hellman parameters are exchanged. 1219 Exchange (3) starts the IKE_AUTH phase. This second phase of IKEv2 1220 authenticates the previous messages, exchanges identities and 1221 certificates and establishes the first CHILD_SA. It is used to 1222 mutually authenticate the MN (acting as an IKEv2 Initiator) and the 1223 HA (acting as an IKEv2 Responder). The identity of the user/MN is 1224 provided in the IDi field. The MN indicates its willingness to be 1225 authenticated via EAP by omitting the AUTH field in message (3) (see 1226 Section 2.16 of [25]). 1228 As part of the authentication process, the MN MAY request a Home- 1229 Address, a Home Prefix or suggests one, see [27], using a CFG_REQUEST 1230 payload in the exchange(3). 1232 The HA extracts the IDi field from exchange (3) and sends a RADIUS 1233 Access-Request packet(4) towards the authenticating RADIUS server. 1234 The User-Name(1) attribute is set to the value received in the IDi 1235 field and the EAP-Payload attribute contains a EAP-Response/ Identity 1236 with the identity extracted from the IDi field. The Access-Request 1237 packet is integrity protected by the Message-Authenticator(89) 1238 attribute. 1240 This message is routed to the MN's home RADIUS server/EAP server. 1241 The RADIUS server selects the EAP method and replies with the RADIUS 1242 Access-Challenge packet(5). Depending on the type of EAP method 1243 chosen, a number of Access-Request and Access-Challenge exchanges are 1244 conducted to execute the EAP method between the MN and the RADIUS 1245 server/EAP server. 1247 At the end of the EAP authentication phase, the RADIUS server 1248 indicates the result of the authentication by either sending an 1249 Access-Accept packet(6) containing EAP-Success or an Access-Reject 1250 packet containing EAP-Reject. The last IKEv2 message sent by the HA 1251 contains the Home Address or the Home Prefix. In the latter case, a 1252 CREATE_CHILD_SA exchange is necessary to setup IPSec SAs for Mobile 1253 IPv6 signaling. 1255 In some deployment scenarios, the HA may also acts as a IKEv2 1256 Responder for IPSec VPN access. A problem in this case is that the 1257 IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service 1258 or for IPSec VPN access service. A network operator needs to be 1259 aware of this limitation. The MN may provide a hint of the intended 1260 service, for example, by using different identities in the IKE_AUTH 1261 message for the IPSec VPN service and Mobile IPv6 service. However, 1262 the use of different identities during the IKEv2 negotiation is 1263 deployment specific. Another possibility is to make the distinction 1264 on the MN subscription basis. In this case the RADIUS server can 1265 inform the HA during the IKEv2 negotiation whether the MN is 1266 provisioned with an IPSec VPN access service or Mobile IPv6 service. 1268 Eventually, when the HA receives a Binding Update (BU), the HA 1269 authenticates and authorizes the MN. It is RECOMMENDED that the HA 1270 sends a RADIUS accounting request message every time it receives a 1271 BU. Alternatively, if the HA does not support RADIUS Accounting, it 1272 SHOULD send a User-Session-Notification packet as defined in [9] to 1273 inform the AAA server that the mobile ip session has termianted. 1275 6.2.1.2. IKEv2 and Certificates 1277 When IKEv2 is used with certificate-based authentication, the HA 1278 performs the authentication of the MN based on the received 1279 certificate. The RADIUS server is used to authorize the MN for the 1280 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 1281 message MUST correspond to the identity in the MN's certificate. 1282 This identity is then used by the HA to populate the User-Name(1) 1283 attribute in the succeeding Access-Request packet. The Service- 1284 Type(6) attribute is set to Authorize-Only and the RADIUS packet MUST 1285 be protected with the Message-Authenticator(89) attribute. Further 1286 PKI-related procedures such as certificate revocation checking are 1287 out of scope of this document. 1289 EDITOR's note: we have to differentiate the CERT case from the PSK 1290 case to the AAA. 1292 6.2.1.3. IKEv2 and Preshared Keys 1294 When IKEv2 is used with PSK-based initiator authentication, RADIUS is 1295 used to obtain the Pre-shared Key and authorize the MN for the Mobile 1296 IPv6 service. The IDi payload extracted from the IKE_AUTH message 1297 has to contain an identity that is meaningful for the RADIUS 1298 infrastructure, such as a Network Access Identifier (NAI), and is 1299 then used by the HA to populate the User-Name(1) attribute in the 1300 Access-Request packet. The Service-Type(6) is set to Authorize-Only. 1301 The HA includes TBD attribute that when present in an Access-Request 1302 packet acts as a hint to the RADIUS server that it MUST provide the 1303 Pre-Shared-Key in the Access-Accept packet. The Access-Request 1304 packet MUST be integrity protected by the Message-Authenticator(89) 1305 attribute. 1307 Upon receiving the Access-Request packet the RADIUS server replies 1308 with an Access-Accept or an Access-Reject if the MN is not authorized 1309 for MIP6 service. In the case of Access-Accept, if the RADIUS server 1310 received the TBD attribute (in the Access-Request) it SHALL include 1311 the Pre-Shared Key associated with the NAI received in the User- 1312 Name(1) attribute. The Pre-Shared key is delivered using the MS- 1313 MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. This 1314 attribute must be encrypted using the procedures defined in section 1315 3.5 of [10]. The Access-Accept MUST be integrity protected using 1316 Message-Authenticator(89) attribute. The Access-Accept packet may 1317 contain other MIP6 authorization attributes. 1319 EDITOR's note: The preshared key as defined in IKEv2 should not be 1320 delivered raw to the HA. Instead it should be hashed as defined in 1321 IKEv2: prf(Shared Secret,"Key Pad for IKEv2") section 2.15. To have 1322 the AAA server do this, the AAA server must be told what prf function 1323 to use. This can be achieved by sending the PRF function in the 1324 Access-Request. Recall the previous editor's note we need a hint to 1325 tell the AAA to fetch the key. This could be the hint. 1327 6.2.2. Split and Mobile IPv6 Authentication Protocol 1329 Figure 5 shows the message sequence between the MN, the HA and the 1330 RADIUS server during the registration when Mobile IPv6 Authentication 1331 Protocol is used. A BU and a Binding Acknowledgement (BA) messages 1332 are used in the binding registration process. 1334 Receiving a BU at the HA initiates a MIP6-Request to be sent to the 1335 RADIUS server. The RADIUS server in turn responds with an Access- 1336 Accept or an Access-Reject. The HA may assign a Home Address to the 1337 MN and provide it to the Diameter server in the MIP6-HOA attribute. 1339 According to [3] the MN uses the Mobile Node Identifier Option, 1340 specifically the MN-NAI mobility option (as defined in [20]) to 1341 identify itself. The HA MUST copy the MN-NAI mobility option value 1342 to the User-Name(1) attribute in the Access-Request packet. 1344 The procedure described in this specification for the Mobile IPv6 1345 Authentication Protocol is only needed for the initial BU received by 1346 the HA. When the HA receives subsequent BUs, they are processed 1347 locally in the HA using the MN-HA key received from the AAA. It is 1348 RECOMMENDED that the HA sends an accounting request packet or a User- 1349 Session-Notification packet as defined in [9] every time it receives 1350 a Binding Update. However, the HA MAY re-authorize the MN with the 1351 RADIUS server at any time depending on the deployment and the local 1352 policy. 1354 In the case where the BU contains the MN-AAA Mobile Message 1355 Authentication Option, the HA extracts the Mobility SPI from the 1356 Mobility Message Authentication Option and sends it to the RADIUS 1357 server in the MIP6-MN-AAA-SPI attribute. The HA also extract the 1358 Authentication Data from the Message Authentication Option and 1359 includes it in the Access-Request in the MIP6-Authenticator 1360 attribute. If the Mobility SPI has the well-know value HMAC-SHA1_SPI 1361 (see section 8 of [3]), then the hash_fn() is HMAC_SHA1. When 1362 HMAC_SHA1 is used, the BU is authenticate by the AAA using HMAC_SHA1 1363 authenticaiton. In that case, MAC_Mobility Data is calcualted by the 1364 HA as per [3] and included in the Access-Request packet in the MIP6- 1365 MAC-Mobility-Data attribute. The MIP6-Timestamp attribute is set to 1366 the value contained in the mobility message prelay protection option 1367 defined in [3] if available. If the MN-HA Authentication Option is 1368 included in the BU, the HA extract the SPI value and includes it in 1369 the Access-Request packet in the MIP6-MN-HA-SPI attribute. 1371 Upon receiving the Access-Request packet the RADIUS server uses the 1372 User-Name(1) attribute and the MIP6-MN-AAA-SPI attribute to fetch the 1373 AAA-KEY. The RADIUS server then uses that key and the data received 1374 in the MIP6-MAC-Mobility-Data attribute to compute its own version of 1375 the authentication data. The MN is authenticated if the 1376 authentication data computed matches the authentication data received 1377 in the Access-Request in the MIP6-Authenticator attribute. 1379 If the MN is authenticated and is authorized for MIP6 service, the 1380 RADIUS server responds back with an Access-Accpet otherwise it 1381 responds with an Access-Reject. In the case of Access-Accept and if 1382 the MIP6-MN-HA-SPI value was inclued in the Access-Request packet, 1383 the RADIUS server includes the MN-HA security association parameters 1384 associated with the MN-HA SPI and the NAI received in the User-Name 1385 attributes in the MS-MPPE-Recv-Key, MS-MPPE-Send-Key, MIP6-Algorithm- 1386 Type, MIP6-Replay-Mode, MIP6-Nonce. The MS-MPPE-Recv-Key, MS-MPPE- 1387 Send-Key must be encrypted using the procedures defined in section 1388 3.3 of [10]. The RADIUS Access-Accept packet MUST be integrity 1389 protected using Message-Authenticator(89) attribute. 1391 If the RADIUS server detected a replay attack when checking the MIP6- 1392 Timesampt received in the Access-Request fromt he HA. The RADIUS 1393 server SHAL respond back with an Access-Reject. 1395 In some architectures and network deployments the MN-HA security 1396 associations may be established as a result of a successful network 1397 access authentication. In such deployments, both MN and RADIUS 1398 server share the keying material required for computation and 1399 validation of the MN-HA Authentication Option, and a Security 1400 Parameter Index (SPI) for indexing an appropriate security 1401 association. Upon receiving a BU with only a MN-HA Authentication 1402 Option, the HA retrieves the keying material required for the 1403 computation and validation of the MN-HA Authentication Option from 1404 the RADIUS server. The RADIUS request packet sent by the HA MUST 1405 contain the Service-Type(6) attribute set to "Authorize-Only" and the 1406 MIP6-MN-HA-SPI set to the value of the SPI in the MN-HA 1407 Authentication Option. The RADIUS server uses the NAI and the SPI 1408 value to locate the matching security association for the MN-HA and 1409 return correct keying material back to the HA in the MS-MPPE-Recv- 1410 Key, MS-MPPE-Send-Key. The returned keying material MUST be 1411 encrypted using the procedure defined in section 3.3 [10]. The 1412 RADIUS Access-Accept packet MUST be integrity protected using 1413 Message-Authenticator(89) attribute. 1415 Mobile Home Diameter 1416 Node Agent Server 1417 | | | 1418 | | | 1419 | Binding Update |RADIUS Access-Request| 1420 |------------------------------------>|-------------------->| 1421 | (Mobile Node Identifier Option, | | 1422 | Mobility Message Replay Protection | | 1423 | Option, Authentication Option) | | 1424 | | | 1425 | | | 1426 | Binding Acknowledgement |RADIUS Access-Accept | 1427 | |or Access-Reject | 1428 |<------------------------------------|<--------------------| 1429 | (Mobile Node Identifier Option | | 1430 | Mobility Message Replay Protection | | 1431 | Option, Authentication Option) | | 1432 | | Acct-Request(start) | 1433 | |-------------------->| 1435 Figure 5: Mobile IPv6 Bootstrapping using the Mobile IPv6 1436 Authentication Protocol 1438 7. Goals for the HA-AAA Interface 1440 Here, we follow the classification and labels listed in the MIPv6- 1441 AAA-Goals document [28]. 1443 7.1. General Goals 1445 G1.1-G1.4 Security 1447 These are standard requirements for a AAA protocol - mutual 1448 authentication, integrity, replay protection, confidentiality. IPsec 1449 can be used to achieve the goals. Goal G1.5 regarding inactive peer 1450 detection needs further investigations since heartbeat messages do 1451 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 1453 7.2. Service Authorization 1455 G2.1. The AAA-HA interface should allow the use of Network Access 1456 Identifier (NAI) to identify the MN. The User-Name attribute can be 1457 used for the purpose to carry the NAI. 1459 G2.2 The HA should be able to query the AAAH server to verify Mobile 1460 IPv6 service authorization for the MN. Any node implementing RADIUS 1461 functionality[11] can possibly initiate a request message. In 1462 combination with the ability of the RADIUS protocol to carry EAP 1463 messages [6] , our solution will enable an HA to query a RADIUS 1464 server and verify MIPv6 authorization for the MN. 1466 G2.3 The AAAH server should be able to enforce explicit operational 1467 limitations and authorization restrictions on the HA (e.g., packet 1468 filters, QoS parameters). Work in progress in the area, including 1469 NAS-Filter-Rule, RADIUS quality of service support, prepaid 1470 extensions etc. is performed. The relevant attributes may be reused 1471 for providing required functionality over the AAAH-HA interface. 1473 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 1474 session by the AAAH server, e.g., authorization lifetime, extension 1475 of the authorization lifetime and explicit session termination by the 1476 AAAH server side. 1478 The attribute Session-Timeout may be sent in Access-Challenge or 1479 Access-Accept packet by the RADIUS server, thus limiting the 1480 authorization session duration. In order to reauthenticate/ 1481 reauthorize the user, the Termination-Action attribute can be 1482 included, with value 1, meaning the NAS should send a new RADIUS- 1483 Request packet. Additional AVPs for dealing with pre-paid sessions 1484 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 1485 specified in RADIUS prepaid extension. Exchanging of application 1486 specific authorization request/answer messages provides extension of 1487 the authorization session (e.g., Authorize Only Access-Request sent 1488 by the HA (NAS) to the RADIUS server). Initiation of the re- 1489 authorization by both sides could be supported. Both sides could 1490 initiate session termination - the RADIUS server by sending 1491 Disconnect message [29]. 1493 7.3. Accounting 1495 G3.1 The AAA-HA interface must support the transfer of accounting 1496 records needed for service control and charging. These include (but 1497 may not be limited to): time of binding cache entry creation and 1498 deletion, octets sent and received by the MN in bi-directional 1499 tunneling, etc. 1501 The requirements for accounting over the AAAH-HA interface does not 1502 require enhancements to the existing accounting functionality. 1504 7.4. MN Authentication 1506 G4.1 The AAA-HA interface MUST support pass-through EAP 1507 authentication with the HA working as EAP authenticator operating in 1508 pass-through mode and the AAAH server working as back-end 1509 authentication server. 1511 These issues require the functionality of AAAH server working as a 1512 back-end authentication server and HA working as NAS and EAP 1513 authenticator in pass-through mode for providing a MN authentication. 1514 This document suggests this mode of operation in the context of the 1515 relevant scenarios. 1517 7.5. Provisioning of Configuration Parameters 1519 G5.1 The HA should be able to communicate to the AAAH server the HOA 1520 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 1521 update on behalf of the MN). 1523 This document describes needed AVPs for this purpose, see section 1524 "DNS Update Mobility Option Attribute" 1526 8. Table of Attributes 1528 The following tables provides a guide to which attributes may be 1529 found in RADIUS packet and in what number. 1531 The following defines the meaning of the notation used in the following 1532 tables: 1534 0 An instance of this attribute MUST NOT be present. 1535 1 Exactly one instance of this attribute MUST be present 1536 0-1 Zero or one instance of this attribute MAY be present. 1537 0+ Zero or more instance of this attriubte MAY be present 1539 The table below describes the RADIUS messages used for bootstrapping and are 1540 exchanged between the NAS and the RADIUS Server. 1542 Request Accept Reject Challenge Type Attribute 1543 1 1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1544 0+[ac] 0+[a] 0 0 MIP6-HA-TYPE MIP6-HA 1545 0+[ac] 0+[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN 1546 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix 1547 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1548 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO 1550 Notes: 1552 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 1554 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 1555 then these attributes MUST also be present in the Access-Request. 1556 If the RADIUS server accepts the NAS suggestion for the HA, then 1557 the RADIUS server MUST also include the values received for these 1558 attributes in the Access-Accept. 1560 [c] If these attributes are present in an Access-Request, then 1561 LOCAL_HOME_AGENT_ASSIGNMENT flag of the MIP6-Feature-Vector MUST be set. 1562 Otherwise these attributes are ignored. 1564 The following tables lists the commands and attributes used in the interaction 1565 between the HA and RADIUS server. Each table corresponds to the different 1566 authentication modes supported. These attributes are in addition to the any 1567 other attributes specified by an other specification (for example, RADIUS EAP) 1569 Table of attributes for IKEv2 and certificate or PSK-based Authentication: 1571 Request Accept Reject Challenge Type Attribute 1572 1 0 0 0 61 NAS-Port-Type 1573 0-1 0 0 0 80 Message-Authenticator 1574 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1575 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1576 0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1577 0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1578 0-1 0 0 0 MIP6-HA-TYPE MIP6-HA 1579 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1580 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1581 0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1582 0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1583 0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1584 0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1585 0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1587 Table of attributes for IKEv2 and EAP-based Authentication: 1589 Request Accept Reject Challenge Type Attribute 1590 1 0 0 0 61 NAS-Port-Type 1591 1 0 0 0 80 Message-Authenticator 1592 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1593 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1594 0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1595 0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1596 0-1 0 0 0 MIP6-HA-TYPE MIP6-HA 1597 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1598 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1599 0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1600 0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1601 0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1602 0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1603 0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1605 Table of attribute for MIPv6 Authentication Protocol: 1607 Request Accept Reject Challenge Type Attribute 1608 1 0 0 0 61 NAS-Port-Type 1609 0-1 0 0 0 80 Message-Authenticator 1610 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1611 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1612 1 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1613 0-1 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1614 1 0 0 0 MIP6-HA-TYPE MIP6-HA 1615 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1616 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1617 0-1 0 0-1[x] 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1618 0 1 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1619 0 1 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1620 0 1 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1621 0 1 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1623 [x] THIS IS A PROBLEM. CANT HAVE ATTRIBS IN REJECT. 1625 As used in accounting packets: 1627 Request Interim Stop Type Attribute 1629 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 1630 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 1631 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 1632 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 1633 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 1635 9. Diameter Considerations 1637 When used in Diameter, the attributes defined in this specification 1638 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 1639 attribute compatibility space). No additional Diameter Code values 1640 are therefore allocated. The data types and flag rules for the 1641 attributes are as follows: 1643 +---------------------+ 1644 | AVP Flag rules | 1645 |----+-----+----+-----|----+ 1646 | | |SHLD| MUST| | 1647 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 1648 -------------------------------|----+-----+----+-----|----| 1649 MIP6-HA Address | M | P | | V | Y | 1650 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 1651 MIP6-HL-Prefix OctetString| M | P | | V | Y | 1652 MIP6-HOA Address | M | P | | V | Y | 1653 MIP6-DNS-MO OctetString| M | P | | V | Y | 1654 -------------------------------|----+-----+----+-----|----| 1656 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 1657 have no special translation requirements for Diameter to RADIUS or 1658 RADIUS to Diameter gateways; they are copied as is, except for 1659 changes relating to headers, alignment, and padding. See also [12] 1660 Section 4.1 and [30] Section 9. MIP6-HA and HOA-IPv6 must be 1661 translated between their RADIUS representation of String to a 1662 Diameter Address format which requires that the AddressType field be 1663 set to 2 for IP6 (IP version 6) 1665 What this specification says about the applicability of the 1666 attributes for RADIUS Access-Request packets applies in Diameter to 1667 AA-Request [30] or Diameter-EAP-Request [31]. What is said about 1668 Access-Challenge applies in Diameter to AA-Answer [30] or Diameter- 1669 EAP-Answer [31] with Result-Code AVP set to 1670 DIAMETER_MULTI_ROUND_AUTH. 1672 What is said about Access-Accept applies in Diameter to AA-Answer or 1673 Diameter-EAP-Answer messages that indicate success. Similarly, what 1674 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1675 Answer or Diameter-EAP-Answer messages that indicate failure. 1677 What is said about Accounting-Request applies to Diameter Accounting- 1678 Request [30] as well. 1680 10. Security Considerations 1682 Assignment of these values to a user should be based on successful 1683 authentication of the user at the NAS and/or at the HA. The RADIUS 1684 server should only assign these values to a user who is authorized 1685 for Mobile IPv6 service (this check could be performed with the 1686 user's subscription profile in the Home Network). 1688 The NAS and the HA to the RADIUS server transactions must be 1689 adequately secured. Otherwise there is a possibility that the user 1690 may receive fraudulent values from a rogue RADIUS server potentially 1691 hijacking the user's Mobile IPv6 session. 1693 These new attributes do not introduce additional security 1694 considerations besides the ones identified in [11]. 1696 11. IANA Considerations 1698 11.1. Registration of new AVPs 1700 This specification defines the following new RADIUS attributes: 1702 MIP6-Feature-Vector is set to MIP6-FV-TYPE 1704 MIP6-HA is set to MIP6-HA-TYPE 1706 MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE 1708 MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE 1710 MIP6-HOA is set to MIP6-HOsA-TYPE 1712 MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE 1714 11.2. New Registry: Mobility Capability 1716 For MIP6-FV-TYPE flag values must be generated: 1718 Token | Value | Description 1719 ----------------------------------+----------------------+------------ 1720 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 1721 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 1722 Available for Assignment via IANA | 2^x | 1724 Allocation rule: Only numeric values that are 2^x (power of two) are 1725 allowed based on the allocation policy described below. 1727 Following the policies outlined in [1] new values with a description 1728 of their semantic for usage with the MIP6-Feature-Vector AVP together 1729 with a Token will be assigned after Expert Review initiated by the 1730 O&M Area Directors in consultation with the DIME working group chairs 1731 or the working group chairs of a designated successor working group. 1732 Updates can be provided based on expert approval only. A designated 1733 expert will be appointed by the O&M Area Directors. No mechanism to 1734 mark entries as "deprecated" is envisioned. Based on expert approval 1735 it is possible to delete entries from the registry. 1737 11.3. Addition of existing values 1739 A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) 1741 12. Acknowledgements 1743 We would like to thank the following individuals for their review and 1744 constructive comments during the development of this document: 1746 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1747 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1749 13. References 1751 13.1. Normative References 1753 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1754 Levels", BCP 14, RFC 2119, March 1997. 1756 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1757 Integrated Scenario", 1758 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1759 progress), April 2008. 1761 [3] Patel, A., "Authentication Protocol for Mobile IPv6", 1762 draft-patel-mip6-rfc4285bis-00 (work in progress), 1763 October 2006. 1765 [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1767 [5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1768 RFC 2548, March 1999. 1770 [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1771 In User Service) Support For Extensible Authentication Protocol 1772 (EAP)", RFC 3579, September 2003. 1774 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1775 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 1776 July 2007. 1778 [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1779 for Message Authentication", RFC 2104, February 1997. 1781 [9] Zorn, G. and A. Lior, "User Session Tracking in RADIUS", 1782 draft-zorn-radius-logoff-11 (work in progress), February 2008. 1784 [10] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1785 and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", 1786 RFC 2868, June 2000. 1788 [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1789 Authentication Dial In User Service (RADIUS)", RFC 2865, 1790 June 2000. 1792 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1793 "Diameter Base Protocol", RFC 3588, September 2003. 1795 [13] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1796 Levkowetz, "Extensible Authentication Protocol (EAP)", 1797 RFC 3748, June 2004. 1799 13.2. Informative References 1801 [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1802 IPv6", RFC 3775, June 2004. 1804 [15] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1805 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1807 [16] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and 1808 M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to 1809 Diameter Server Interaction", draft-ietf-dime-mip6-split-10 1810 (work in progress), July 2008. 1812 [17] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1813 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1814 Server to Diameter Server Interaction", 1815 draft-ietf-dime-mip6-integrated-09 (work in progress), 1816 May 2008. 1818 [18] Manner, J. and M. Kojo, "Mobility Related Terminology", 1819 RFC 3753, June 2004. 1821 [19] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1822 IKEv2 and the revised IPsec Architecture", 1823 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1824 December 2006. 1826 [20] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1827 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1828 RFC 4283, November 2005. 1830 [21] Mockapetris, P., "Domain names - implementation and 1831 specification", STD 13, RFC 1035, November 1987. 1833 [22] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1834 August 2002. 1836 [23] Droms, R., "Stateless Dynamic Host Configuration Protocol 1837 (DHCP) Service for IPv6", RFC 3736, April 2004. 1839 [24] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1840 Carney, "Dynamic Host Configuration Protocol for IPv6 1841 (DHCPv6)", RFC 3315, July 2003. 1843 [25] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1844 RFC 4306, December 2005. 1846 [26] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options 1847 for Home Information Discovery in MIPv6", 1848 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 1850 [27] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1851 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1852 April 2007. 1854 [28] Giaretta, G., "AAA Goals for Mobile IPv6", 1855 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1856 September 2006. 1858 [29] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1859 "Dynamic Authorization Extensions to Remote Authentication Dial 1860 In User Service (RADIUS)", RFC 5176, January 2008. 1862 [30] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1863 Network Access Server Application", RFC 4005, August 2005. 1865 [31] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1866 Authentication Protocol (EAP) Application", RFC 4072, 1867 August 2005. 1869 [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1870 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1871 April 1997. 1873 [33] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1874 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1875 Agents", RFC 3776, June 2004. 1877 [34] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1878 "DNS Security Introduction and Requirements", RFC 4033, 1879 March 2005. 1881 Authors' Addresses 1883 Avi Lior 1884 Bridgewater Systems 1885 303 Terry Fox Drive, Suite 100 1886 Ottawa, Ontario 1887 Canada K2K 3J1 1889 Phone: +1 613-591-6655 1890 Email: avi@bridgewatersystems.com 1892 Kuntal Chowdhury 1893 Starent Networks 1894 30 International Place 1895 Tewksbury, MA 01876 1896 US 1898 Phone: +1 214-550-1416 1899 Email: kchowdhury@starentnetworks.com 1901 Hannes Tschofenig 1902 Siemens 1903 Otto-Hahn-Ring 6 1904 Munich, Bavaria 81739 1905 Germany 1907 Email: Hannes.Tschofenig@siemens.com 1909 Full Copyright Statement 1911 Copyright (C) The IETF Trust (2008). 1913 This document is subject to the rights, licenses and restrictions 1914 contained in BCP 78, and except as set forth therein, the authors 1915 retain all their rights. 1917 This document and the information contained herein are provided on an 1918 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1919 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1920 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1921 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1922 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1923 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1925 Intellectual Property 1927 The IETF takes no position regarding the validity or scope of any 1928 Intellectual Property Rights or other rights that might be claimed to 1929 pertain to the implementation or use of the technology described in 1930 this document or the extent to which any license under such rights 1931 might or might not be available; nor does it represent that it has 1932 made any independent effort to identify any such rights. Information 1933 on the procedures with respect to rights in RFC documents can be 1934 found in BCP 78 and BCP 79. 1936 Copies of IPR disclosures made to the IETF Secretariat and any 1937 assurances of licenses to be made available, or the result of an 1938 attempt made to obtain a general license or permission for the use of 1939 such proprietary rights by implementers or users of this 1940 specification can be obtained from the IETF on-line IPR repository at 1941 http://www.ietf.org/ipr. 1943 The IETF invites any interested party to bring to its attention any 1944 copyrights, patents or patent applications, or other proprietary 1945 rights that may cover technology that may be required to implement 1946 this standard. Please address the information to the IETF at 1947 ietf-ipr@ietf.org.