idnits 2.17.1 draft-ietf-mip6-radius-06.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 1914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1938. 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 20 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 (November 3, 2008) is 5646 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 1710 == Unused Reference: '13' is defined on line 1784, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1858, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1862, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1866, but no explicit reference was found in the text ** 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') ** 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: A later version (-17) exists of draft-ietf-dime-mip6-split-13 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-10 -- 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: A later version (-18) exists of draft-ietf-mip6-hiopt-17 -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '30') (Obsoleted by RFC 7155) Summary: 10 errors (**), 0 flaws (~~), 9 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: May 7, 2009 Starent Networks 6 H. Tschofenig 7 Nokia Siemens Networks 8 November 3, 2008 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-06.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 7, 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 . . . . . . . . . . . . . . . . . . 23 72 5.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 23 73 5.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 24 74 5.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 25 75 5.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 25 76 5.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 26 77 5.16. MIP6-Auth-Mode . . . . . . . . . . . . . . . . . . . . . . 27 78 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 28 79 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA) . . . . . . 28 80 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 28 81 6.1.2. HA allocation in the ASP (visited network) . . . . . . 30 82 6.2. Use of RADIUS In Split Scenario . . . . . . . . . . . . . 30 83 6.2.1. Split using IKEv2 . . . . . . . . . . . . . . . . . . 30 84 6.2.2. Split and Mobile IPv6 Authentication Protocol . . . . 33 86 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 36 87 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 36 88 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 36 89 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 37 90 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 37 91 7.5. Provisioning of Configuration Parameters . . . . . . . . . 37 92 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 38 93 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 40 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 96 11.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 42 97 11.2. New Registry: Mobility Capability . . . . . . . . . . . . 42 98 11.3. Addition of existing values . . . . . . . . . . . . . . . 42 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 101 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 102 13.2. Informative References . . . . . . . . . . . . . . . . . . 45 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 104 Intellectual Property and Copyright Statements . . . . . . . . . . 48 106 1. Introduction 108 This document covers two aspects of MIP6 operations: bootstrapping of 109 information required by a Mobile IPv6 Mobile using the AAA 110 infrastructure and the interaction between the Network Access 111 Server(NAS), MIPv6 Home Agent (HA) and the Authentication 112 Authorization and Accounting (AAA) infrastructure. 114 Mobile IPv6 specification [14] requires a Mobile Node (MN) to perform 115 registration with an HA with information about its current point of 116 attachment (Care-of Address). The HA creates and maintains binding 117 between the MN's Home Address (HOA) and the MN's Care-of Address. 119 In order to register with a HA, the MN needs to know some information 120 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 121 prefix Length and security related information in order to secure the 122 Binding Update. 124 The aforementioned set of information may be statically provisioned 125 in the MN. However, static provisioning of this information has its 126 drawbacks. It increases provisioning and network maintenance burden 127 for the operator. Moreover, static provisioning does not allow load 128 balancing, failover, opportunistic home link assignment etc. For 129 example, the user may be accessing the network from a location that 130 may be geographically far away from the preconfigured home link; the 131 administrative burden to configure the MN's with the respective 132 addresses is large and the ability to react on environmental changes 133 is minimal. In these situations static provisioning may not be 134 desirable. 136 Dynamic assignment of Mobile IPv6 home registration information is a 137 desirable feature for ease of deployment and network maintenance. 138 For this purpose, the RADIUS infrastructure, which is used for access 139 authentication, can be leveraged to assign some or all of the 140 necessary parameters. The RADIUS server in the Access Service 141 Provider (ASP) or in the Mobility Service Provider's (MSP) network 142 may return these parameters to the AAA client. The AAA client might 143 either be the NAS, in case of the integrated scenario, or the HA, in 144 case of the split scenario. The terms integrated and split are 145 described in the terminology section and are introduced in [15]. 147 The second aspect of MIP6 and RADIUS interworking is the interaction 148 between the HA and the AAA using the RADIUS AAA protocols. From a 149 mobility service provider (MSP) perspective, it is important to 150 verify that the MN is authenticated and authorized to utilize Mobile 151 IPv6 service and that such services are accounted for. Thus, prior 152 to processing the Mobile IPv6 registrations, the HA, participates in 153 the authentication of the MN to verify the MN's identity. The HA 154 also participates in the Mobile IPv6 authorization process involving 155 the RADIUS infrastructure. The HA, due to its role in traffic 156 forwarding, may also perform accounting for the Mobile IPv6 service 157 provided to the MN. This document specifies the interaction between 158 the NAS, HA and the RADIUS server and aligns with the work done in 159 with the Diameter specifications described in [16] and [17]. 161 2. Terminology 163 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [1]. 167 General mobility terminology can be found in [18]. The following 168 additional terms, as defined in [15], are used in this document: 170 Access Service Authorizer (ASA): 172 A network operator that authenticates a mobile node and 173 establishes the mobile node's authorization to receive Internet 174 service. 176 Access Service Provider (ASP): 178 A network operator that provides direct IP packet forwarding to 179 and from the end host. 181 Mobility Service Authorizer (MSA): 183 A service provider that authorizes Mobile IPv6 service. 185 Mobility Service Provider (MSP): 187 A service provider that provides Mobile IPv6 service. In order to 188 obtain such service, the MN must be authenticated and authorized 189 to obtain the Mobile IPv6 service. 191 Split Scenario: 193 A scenario where the mobility service and the network access 194 service are authorized by different entities. 196 Integrated Scenario: 198 A scenario where the mobility service and the network access 199 service are authorized by the same entity. 201 3. Solution Overview 203 This document addresses the authentication, authorization and 204 accounting functionality required by MIPv6 bootstrapping and 205 Authentication as outlined in the MIPv6 bootstrapping problem 206 statement document (see [15]). As such, the AAA functionality for 207 the integrated and the split scenario needs to be defined. This 208 requires the ability to offer support for the HA to AAA server and 209 the network access server(NAS) to AAA server communication. 211 To highlight the main use cases, we briefly describe the integrated 212 and the split scenarios in Section 3.1 and Section 3.2, respectively. 214 3.1. RADIUS Transaction in Integrated Scenario 216 In the integrated scenario MIPv6 bootstrapping is provided as part of 217 the network access authentication procedure. Figure 1 shows the 218 participating entities. 220 +---------------------------+ +-----------------+ 221 |Access Service Provider | |ASA/MSA/(/MSP) | 222 |(Mobility Service Provider)| | | 223 | | | +-------+ | 224 | +-------+ | | |Remote | | 225 | |Local | RADIUS | | |RADIUS | | 226 | |RADIUS |-------------------------|Server | | 227 | |Proxy | | | +-------+ | 228 | +-------+ | | ^ | 229 | ^ ^ | | |RADIUS | 230 | | | | | | | 231 | | | | | v | 232 | RADIUS| | | +-------+ | 233 | | | +-------+ | | |Local | | 234 | | | RADIUS |Home | | | |Home | | 235 | | +------->|Agent | | | |Agent | | 236 | | |in ASP | | | +-------+ | 237 | v +-------+ | +-----------------+ 238 +-------+ IEEE | +-----------+ +-------+ | 239 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 240 |Node |----------+-|RADIUS |---|Server | | 241 | | PANA,... | |Client | | | | 242 +-------+ DHCP | +-----------+ +-------+ | 243 +---------------------------+ 245 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 247 In the typical Mobile IPv6 access scenario as shown above, the MN 248 attaches in the ASP's network. During this network attachment 249 procedure, the NAS/RADIUS client interacts with the MN. As shown in 250 Figure 1, the authentication and authorization happens via a RADIUS 251 infrastructure. 253 At the time of authorizing the user for IPv6 access, the RADIUS 254 server in the MSA detects that the user is authorized for Mobile IPv6 255 access. Based on the MSA's policy, the RADIUS server may allocate 256 several parameters to the MN for use during the subsequent Mobile 257 IPv6 protocol interaction with the HA. 259 Depending on the details of the solution, interaction with the DHCPv6 260 server may be required, as described in [2]. 262 3.2. RADIUS Transactions in Split Scenario 264 In the split scenario, Mobile IPv6 bootstrapping is not performed as 265 part of the network access authentication procedure. Other RADIUS 266 transactions such as authentication and authorization, accounting and 267 parameter configuration for MIP6 service is provided by the HA to 268 RADIUS transactions. 270 The Mobile IPv6 RADIUS transaction are executed with the Mobility 271 Service Provider when desired by the MN. Two scenarios can be 272 considered: 274 1. The MSA and the MSP are the same entity. 276 2. The MSA and the MSP are different entities. 278 Since scenario (2) is the more generic scenario we show it in 279 Figure 2. 281 +----------------------+ 282 | | 283 |Mobility +-------+ | 284 |Service |Remote | | 285 |Authorizer |RADIUS | | 286 |(MSA) |Server | | 287 | +-------+ | 288 +---------------^------+ 289 | 290 |RADIUS 291 | 292 | 293 +---------------------------------|------+ 294 |Mobility Service Provider (MSP) v | 295 +-------+ | +-----------+ +-------+ | 296 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 297 |Node |-------------|RADIUS |-------------- |RADIUS | | 298 | | IKEv2 | |Client | |Proxy | | 299 +-------+ | +-----------+ +-------+ | 300 +----------------------------------------+ 302 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 303 MSP) 305 As shown in Figure 2 the interaction between the RADIUS client and 306 the RADIUS server is triggered by the protocol interaction between 307 the MN and the HA/RADIUS client using IKEv2 [19] or MIPv6 308 Authentication Protocol [3]. The important aspect is, however, that 309 for these two approaches, several different authentication and key 310 exchange solutions are available. To establish IPsec security 311 associations for the protection of Mobile IPv6 signaling messages, 312 IKEv2 is used [19]. IKEv2 supports EAP-based authentication, 313 certificates and pre-shared secrets. For protection of Mobile IPv6 314 signaling messages using the MIPv6 Authentication Protocol [3] a 315 mechanism has been designed that is very similar to the one used by 316 Mobile IPv4. 318 The ability to use different credentials has an impact on the 319 interaction between the HA (acting as a RADIUS client) and the RADIUS 320 Server. For that reason this document illustrates the usage of these 321 authentication mechanisms with different subsections for: 323 o IKEv2 usage with EAP 325 o MIPv6 Authentication Protocol using MN-AAA 327 Authentication schemes using IKEv2 with certificates and pre-shared 328 secrets; or MIPv6 Authentication Protocol using MN-HA only are not 329 covered by this document. 331 For accounting of Mobile IPv6 services provided to the MN, this 332 specification uses the RADIUS based accounting defined in [4]. 334 Additionally, the MN might instruct the RADIUS server (via the HA) to 335 perform a dynamic DNS update. 337 4. Use of existing RADIUS Attributes 339 4.1. User-Name 341 If authentication via IKEv2 is used then the User-Name attribute 342 SHALL be set to the IDi payload received in the IKE_AUTH exchange. 343 In the case of the Mobile IPv6 Authentication Protocol the User- 344 Name(1) attribute is set to the value received in the MN-NAI mobility 345 option as defined in [20]. 347 4.2. Service-Type 349 The HA uses Service-Type(6) to indicate whether the Access-Request 350 operation is for Authentication and Authorization or just 351 Authorization. 353 4.3. NAS-Port-Type 355 In order for the AAA to distinguish the source of the Access-Request 356 NAS-Port-Type(61) is used as follows: 358 When the Access-Request originates from an MIP6 HA, NAS-Port-Type 359 MUST be included and its value set to HA6(IANA-TBD1). 361 4.4. Calling-Station-Id 363 In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) 364 to send the MN's COA to the AAA. If used, the string value of the 365 Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. 367 4.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 369 To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize 370 the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. The 371 first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, 372 and the next up to 32 octets are stored into the MS-MPPE-Send-Key. 373 The encryption of these attributes is described in [5]. 375 4.6. Session-Timeout 377 The use of Session-Timeout attribute during bootstrapping operations 378 is covered by various RFC's. 380 The use of Session-Timeout attribute during the EAP exchanges between 381 the HA and the RADIUS server are as per [6]. 383 In the case of the RADIUS server sending Session-Timeout to the HA in 384 the Access-Accept packet, the HA SHALL use this time as the MIP 385 Registration Lifetime. 387 4.7. Message Authenticator 389 The use of Message Authenticator is mandated during EAP AAA 390 procedures by [6]. In the case of the HA sending an Access-Request 391 where EAP is not used, then the HA MUST also include the Message 392 Authenticator attribute in the Access-Request packet. 394 5. RADIUS attributes 396 This section defines format and syntax for the attribute that carries 397 the Mobile IPv6 parameters that are described in the previous 398 section. 400 The attributes MAY be present in Access-Request, Access-Accept, and 401 Accounting-Request packets. 403 5.1. MIP6-Feature-Vector Attribute 405 Exactly one of this attribute MUST be sent by the NAS or HA in an 406 Access-Request packet to inidcate support for MIP6. For example, a 407 NAS uses this attribute to indicate whether it can provide a local 408 home agent. 410 Exactly one of this attribute MUST be sent by the RADIUS server in an 411 Access-Accept packet to indicate support for MIP6 and to select 412 features advetized by the NAS or the HA. For example, if the NAS 413 indicated support for local home agent assignment, the RADIUS server 414 authorizes the NAS to support local home agent assignment by echoing 415 the setting the same flag in the Access-Accept packet. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length | MIP6 Features Vectors | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | MIP6 Features Vectors cont. | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | MIP6 Features Vectors cont. | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Type: 429 MIP6-FV-TYPE to be defined by IANA. 431 Length: 433 = 10 octets 435 Feature Flags: 437 This field is of type String. Supporting the following values: 439 MIP6_INTEGRATED (0x0000000000000001) 441 When this flag is set by the NAS then it means that the 442 Mobile IPv6 integrated scenario bootstrapping functionality 443 is supported by the NAS. When this flag is set by the 444 RADIUS server then the Mobile IPv6 integrated scenario 445 bootstrapping is supported by the RADIUS server. 447 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 449 When this flag is set by the NAS then a local home agent can 450 be assigned to the MN. When this flag is set by the 451 Diameter server then the assignment of location HAs is 452 authorized by the Diameter server. 454 RO_SUPPORTED (0x0000000800000000) 456 Route optimization is supported. When the Home Agent sets 457 this bit, it indicates support for the route optimization. 458 If this bit is unset in the returned Mobility-Capability 459 AVP, the HAAA does not authorize route optimization for the 460 MN. 462 In a case the Home Agent or the HAAA cannot authorize the 463 use of route optimization then the Home Agent will send a 464 Binding Acknowledgement with a Status Code set to 465 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This 466 Status Code indicates that the binding registration 467 succeeded but the Home Agent will fail all possible 468 subsequent route optimization attempts because of 469 subscription or operator policy. 471 5.2. MIP6-HA Attribute 473 In the case of bootstrapping, the RADIUS server may decide to assign 474 a HA to the MN that is in close proximity to the point of attachment 475 (e.g., as determined by the NAS-ID). There may be other reasons for 476 dynamically assigning HAs to the MN, for example to share the traffic 477 load. The attribute also contains the prefix length so that the MN 478 can easily infer the Home Link prefix from the HA address. 480 In the case of bootstrapping, one or more of this attribute MAY be 481 sent by the NAS to the RADIUS server in an Access-Request packet as a 482 proposal by the NAS to allocate a local HA to the MN. 484 In the case of bootstrapping, one or more of this attribute MAY be 485 sent by the RADIUS server to the NAS in an Access-Accept packet. The 486 attribute carries the HA address that may be assigned to the MN. 488 [EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO 489 Attribute sent by the NAS to the RADIUS server in an Access-Request 490 packet as a hint to suggest a dynamic HA that may be assigned to the 491 MN. The RADIUS server MAY use this value or may ignore this 492 suggestion. 494 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 495 FQDN SHOULD appear in accounting packets to indicate the identity of 496 the serving HA for this session. 498 In the case of split, the MIP6-HA attribute contains the IPv6 address 499 of the Home Agent as received in the BU message. One and only one of 500 this attribute SHALL be sent by the HA to the RADIUS server. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type | Length | Reserved | Prefix-Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | IPv6 address of assigned HA | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | IPv6 address of assigned HA cont. | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | IPv6 address of assigned HA cont. | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | IPv6 address of assigned HA cont. | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | IPv6 address of assigned HA cont. | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | IPv6 address of assigned HA cont. | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Type: 522 MIP6-HA-TYPE to be defined by IANA. 524 Length: 526 = 28 octets 528 Reserved: 530 Reserved for future use. The bits MUST be set to zero by the 531 sender, and MUST be ignored by the receiver. 533 Prefix-Length: 535 This field indicates the prefix length of the Home Link. 537 IPv6 address of assigned HA: 539 128-bit IPv6 address of the assigned HA. 541 5.3. MIP6-HA-FQDN Attribute 543 In the case of bootstrapping, one or more instance of this attribute 544 MAY be sent by the NAS to the RADIUS server in an Access-Request 545 packet as a hint to suggest a dynamic HA that may be assigned to the 546 MN. The RADIUS server MAY use this value or may ignore this 547 suggestion. 549 In the case of bootstrapping, one or more of this attribute is sent 550 by the RADIUS server to the NAS in an Access-Accept packet. The 551 attribute carries the FQDN of the assigned HA. The mobile node can 552 perform DNS query with the FQDN to derive the HA address. 554 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 555 MIP6-HA SHOULD appear in accounting packets to indicate the identity 556 of the serving HA for this session. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type | Length | FQDN of the assigned HA ..... 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Type: 566 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 568 Length: 570 Variable length. 572 FQDN of the assigned HA: 574 The data field MUST contain a FQDN as described in [21]. 576 5.4. MIP6-HL-Prefix Attribute 578 In the case of bootstrapping, this attribute MAY be sent by the NAS 579 to the RADIUS server in an Access-Request packet along with the 580 MIP6-HA and/or MIP6-HA-FQDN attribute as a hint to suggest a Home 581 Link prefix that may be assigned to the MN. The RADIUS server MUST 582 use this value if it accepts the NAS's HA suggestion. 584 In the case of bootstrapping, this attribute is sent by the RADIUS 585 server to the NAS in an Access-Accept packet and carries the assigned 586 Home Link prefix that is in close proximity to the point of 587 attachment (NAS-ID). The MN can perform [14] specific procedures to 588 discover other information for Mobile IPv6 registration. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Length | Reserved | Prefix-Length | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | | 596 | | 597 | Home Link Prefix | 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Type: 603 ASSIGNED-HL-TYPE to be defined by IANA. 605 Length: 607 >= 4 octets + the minimum length of a prefix. 609 Reserved: 611 Reserved for future use. The bits MUST be set to zero by the 612 sender, and MUST be ignored by the receiver. 614 Prefix-Length: 616 This field indicates the prefix length of the Home Link. 618 Home Link Prefix: 620 Home Link prefix (upper order bits) of the assigned Home Link 621 where the MN should send binding update. 623 5.5. MIP6-HOA Attribute 625 In the bootstrapping case, this attribute is sent by the RADIUS 626 server to the NAS in an Access-Accept packet. The attribute carries 627 the assigned Home IPv6 Address for the MN. This allows the network 628 operator to support mobile devices that are not configured with 629 static addresses. The attribute also contains the prefix length so 630 that the MN can easily infer the Home Link prefix from the HA 631 address. 633 This attribute MAY be sent by the NAS to the RADIUS server in an 634 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 635 attribute as a hint to suggest a Home Address that may be assigned to 636 the MN. The RADIUS server MUST use this value if it accepts the 637 NAS's HA suggestion. 639 In the case of split, in Access-Request packet, the MIP6-HOA contains 640 the IPv6 Home Address assigned by the HA to the MN. If the MIP6-HOA 641 AVP contains unspecified IPv6 address (0::0), then the Home Agent 642 expects the RADIUS server to assign the Home Address in a subsequent 643 Access-Accept packet. In case the RADIUS server assigns only a Home 644 Network Prefix to the Mobile Node the lower 64 bits of the MIP- 645 Mobile-Node-Address AVP provided address MUST be set to zero. 647 If available at the NAS, this attribute SHOULD appear in the 648 accounting packets so that the IPv6 addressed used for this session 649 is known in the accounting stream. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | Reserved | Prefix-Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | | 657 | | 658 | Assigned IPv6 HOA | 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Type: 664 ASSIGNED-HOA-TYPE to be defined by IANA. 666 Length: 668 = 20 octets. 670 Reserved: 672 Reserved for future use. The bits MUST be set to zero by the 673 sender, and MUST be ignored by the receiver. 675 Prefix-Length: 677 This field indicates the prefix length of the Home Link. 679 Assigned IPv6 HOA: 681 IPv6 HOA that is assigned to the MN. 683 5.6. MIP6-DNS-MO Attribute 685 In the case of bootstrapping, the MIP6-DNS-MO attribute is included 686 by the NAS in an Access-Request packet and MUST set its value to the 687 MN's FQDN to indicate to the RADIUS server to perform a dynamic DNS 688 update. Upon receiving this attribute, the RADIUS server SHALL 689 perform a dynamic update of the DNS and MUST inlcude the MIP6-DNS-MO 690 attribute in the Access-Accept indicating the result of the dynmaic 691 DNS update. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Length | Reserved-1 | Status | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |R| Reserved-2 | FQDN ... 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Type: 703 DNS-UPDATE-TYPE to be defined by IANA. 705 Length: 707 Variable length. 709 Reserved-1: 711 Reserved for future use. The bits MUST be set to zero by the 712 sender, and MUST be ignored by the receiver. 714 Status: 716 This 8 bit unsigned integer field indicates the result of the 717 dynamic DNS update procedure as defined in [7]. This field 718 MUST be set to 0 and ignored by the RADIUS server when the 719 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 720 server. When the MIP6-DNS-MO is provided in the response, 721 values of the Status field less than 128 indicate that the 722 dynamic DNS update was performed successfully by the RADIUS 723 server. Values greater than or equal to 128 indicate that the 724 dynamic DNS update was not successfully completed. The 725 following values for the Status field are currently defined: 727 0 DNS update performed 729 128 Reason unspecified 731 129 Administratively prohibited 733 130 DNS Update Failed 735 R flag: 737 If this bit for the R flag is set then the RADIUS client 738 requests the RADIUS server to remove the DNS entry identified 739 by the FQDN included in this attribute. If not set, the RADIUS 740 client is requesting the RADIUS server to create or update a 741 DNS entry with the FQDN specified in this attribute and the 742 Home Address carried in another attribute specified in this 743 document. 745 Reserved-2: 747 Reserved for future use. The bits MUST be set to zero by the 748 sender, and MUST be ignored by the receiver. 750 FQDN of the MN: 752 In an Access-Request packet the data field MUST contain a FQDN. 753 In an Access-Accept packet the data field MAY contain an FQDN. 754 FQDN is described in [21]. 756 5.7. MIP6-Careof-Address 758 In the case of split, this attribute is sent from the HA to the 759 RADIUS Server and contains the IPv6 addresss of the Care-of Address 760 of the MN extracted from the BU message. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | Reserved | Prefix-Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | | 768 | | 769 | Assigned IPv6 COA | 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Type: 775 ASSIGNED-MIP6-CAREOF-ADDRESS-TYPE to be defined by IANA. 777 Length: 779 = 20 octets. 781 Reserved: 783 Reserved for future use. The bits MUST be set to zero by the 784 sender, and MUST be ignored by the receiver. 786 Prefix-Length: 788 This field indicates the prefix length of the COA Link. 790 Assigned IPv6 COA: 792 IPv6 COA that is assigned to the MN. 794 5.8. MIP6-MN-AAA-SPI 796 In the case of split, this attribute MUST be present in an Access- 797 Request sent from the HA to the RADIUS Server when using MIPv6 798 Authentication Protocol. The MIP6-MN-AAA-SPI attribute contains a 799 SPI code extracted from the Mobility Message Authentication Option 800 included in the received BU message. 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Type | Length | SPI | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | SPI cont. | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Type: 811 ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA. 813 Length: 815 6 octets 817 Integer representing a Security Parameter Index. 819 5.9. MIP6-Authenticator 821 In the case of split, this attribute is sent from the HA to the 822 RADIUS server and contains the Authenticator data from the BU 823 message. The HA extract the data form the MN-AAA Mobility Message 824 Authentication Option if included in the received BU message. 826 Upon receiving this attribute from the HA, the RADIUS server computes 827 its own version of the Authenticator Data from the received MIP6-MAC- 828 Mobility-Data (see below) and compares it to the value received in 829 the MIP6-Authenticator from the HA. If the values match then the 830 Mobile Node is authenticated. 832 In the case of split, this attribute MUST be present in an Access- 833 Request sent from the HA to the RADIUS Server when using MIPv6 834 Authentication Protocol. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Authenticator Data | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Authenticator Data cont .... 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Type: 846 ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA. 848 Length: 850 Variable length 852 String. An OctetString representing authenticator data. 854 5.10. MIP6-MAC-Mobility-Data 856 In the case of split, the MIP6-MAC-Mobility-Data attribute is sent 857 from the HA to the RADIUS Server. The attribute contains the 858 calculated MAC_Mobility_Data as defined in [3]. 860 This attribute MUST be present in an Access-Request sent from the HA 861 to the RADIUS Server when using MIPv6 Authentication Protocol. 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Type | Length | MAC Mobility Data | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | MAC Mobility Data cont .... 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Type: 873 ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA. 875 Length: 877 Variable length 879 String. An OctetString representing authenticator data. 881 5.11. MIP6-Timestamp 883 The MIP6-Timestamp contains the timestamp value from the Mobility 884 message replay protection option, defined in [3]. The Home Agent 885 extracts this value from the received BU message, if available. 887 The support for replay protection is an optional feature in [3]. 888 When the RADIUS server checks the timestamp provided by the MN via 889 the HA and recognizes a clock-drift (outside a locally defined replay 890 protection window) then it MUST initiate the re-synchronization 891 procedure by returning an Access-Accept packet with Result-Code set 892 to MIP6-TIMESTAMP-MISMATCH and attaches the MIP6-Timestamp including 893 it's current time back to the HA. 895 In the case of split, this attribute is sent from the HA to the 896 RADIUS server when performing MIP6 Authentication protocol. The 897 attribute MUST appear in the Access-Request if the attribute is 898 present in the Mobility message replay protection. Otherwise the 899 attribute MUST NOT appear in the Access-Request packet. 901 [EDITOR'S NOTE] there is an issue here. In the diameter protocol, if 902 there is a time mismatch we return a result code that states that 903 there was a time mismatch and we return this value. In RADIUS land 904 we return an Access-Reject but we cant really return any other 905 attributes. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | Timestamp | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Timestamp cont. | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Type: 917 ASSIGNED-MIP6-TIMESTAMP-TYPE to be defined by IANA. 919 Length: 921 6 octets 923 Integer representing time since standard epoch of 1/1/1970 in 924 seconds. 926 5.12. MIP6-MN-HA-SPI 928 In the case of split, the MIP6-MN-HA-SPI available to be sent in an 929 Access-Accept packet from the RADIUS server to he HA. It is part of 930 a group of attributes used with the MIPv6 Authentication Protocol and 931 contains the Security Parameter Index used to reference the MN-HA 932 mobility security association. 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 | SPI | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | SPI cont. | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Type: 944 ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA. 946 Length: 948 6 octets 950 Integer representing a Security Parameter Index. 952 5.13. MIP6-Algorithm-Type 954 In the case of split, the MIP6-Algorithm-Type is available to be sent 955 in an Access-Accept packet from the RADIUS server to the HA. It is 956 part of a group of attributes used with the MIPv6 Authentication 957 protocol and contains the algorithm type. 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type | Length | enumeration | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | enumeration cont. | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Type: 969 ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA. 971 Length: 973 6 octets 975 Integer representing an enumeration as supported by [22]: 977 2: HMAC-SHA-1 [8] 979 5.14. MIP6-Replay-Mode 981 In the case of split, the MIP6-Replay-Mode is available to be sent in 982 an Access-Accept packet from the RADIUS server to the HA. It is part 983 of a group of attribute used with the MIPv6 Authentication protocol 984 and contains the replay mode as defined in RFC4004 to be used by the 985 HA. 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Type | Length | enumeration | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | enumeration cont. | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Type: 997 ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA. 999 Length: 1001 6 octets 1003 Integer representing an enumeration as supported by [22]: 1005 1: None. 1007 2: Timestamps. 1009 3: Nonces. 1011 5.15. MIP6-Nonce 1013 In the case of split, the MIP6-Nonce is available to be sent in an 1014 Access-Accept packet from the RADIUS Server to the HA. It is part of 1015 a group of attributes used with the MIPv6 Authentication protocol and 1016 contains the nonce to send to the MN. 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Type | Length | nonce | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | .... 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Type: 1028 ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA. 1030 Length: 1032 Variable length 1034 String. A binary string representing a nonce. 1036 5.16. MIP6-Auth-Mode 1038 The MIP6-Auth-Mode is of type enumerated and sent by the HA to the 1039 RADIUS server to indicate which procedural variant and credential to 1040 use when Authentication Protocol for MIP6 [3] is being used to 1041 authenticate the Binding Update. This specification defines only one 1042 value. 1044 If the RADIUS server does not support the Mobile IPv6 Authentication 1045 Protocol mode proposed by the HA, then the RADIUS server MUST fail 1046 the authentication/authorization by sending an Access-Reject packet 1047 to the HA. 1049 0 1 2 3 1050 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 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Type | Length | MIP6 Auth Mode | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | MIP6 Auth Mode cont. | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Type: 1059 ASSIGNED-MIP6-AUTH-MODE-TYPE to be defined by IANA. 1061 Length: 1063 6 octets 1065 Integer value representing the following values: 1067 1: MIP6_AUTH_MN_AAA 1069 All other values reserved. 1071 6. Message Flows 1073 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA) 1075 This section is based on [2] and uses the RADIUS attributes that are 1076 defined in this document. 1078 6.1.1. HA allocation in the MSP 1080 RADIUS is used to authenticate the MN, to authorize it for mobility 1081 service and to send information about the assigned HA to the NAS. 1083 | 1084 --------------ASP------>|<--ASA+MSA-- 1085 | 1086 +----+ +------+ +-------+ +-------+ 1087 | | |RADIUS| | | | | 1088 | | |Client| | | | | 1089 | MN | |NAS/ | | DHCP | |Home | 1090 | | |DHCP | | Server| |RADIUS | 1091 | | |Relay | | | |Server | 1092 +----+ +------+ +-------+ +-------+ 1093 | | | | 1094 | 1 | 1 | | 1095 |<------------->|----------------------->| 1096 | | | | 1097 | | 2 | | 1098 | |<-----------------------| 1099 | | | | 1100 | 3 | | | 1101 |-------------->| | | 1102 | | | | 1103 | | 4 | | 1104 | |------------>| | 1105 | | | | 1106 | | 5 | | 1107 | |<------------| | 1108 | | | | 1109 | 6 | | | 1110 |<--------------| | | 1111 | | | | 1113 Figure 3: HA allocation in the MSP 1115 In step (1), the MN executes the network access authentication 1116 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 1117 acts as an authenticator in "pass-through" mode, i.e., the endpoint 1118 of the authentication dialogue is the MN's home RADIUS server. This 1119 is the typical scenario in case the messages involved in the 1120 authentication protocol are transported in EAP. 1122 As per [6], the NAS encapsulates/de-capsulates EAP packets into/from 1123 RADIUS packets until an Access-Response (either an Access-Accept or 1124 an Access/Reject packet is received by the NAS). This concludes the 1125 network access authentication phase. 1127 If the NAS has the ability to support MIP6 Bootstrapping it includes 1128 the MIP6-Feature-Vector in the first Access-Request message and 1129 indicates whether it supports MIP6 bootstrapping and/or local home 1130 agent assignment by setting the appropriate flags therein. 1132 If the NAS indicates support for local home agent assignment, then it 1133 may also include the MIP6-HA attribute(s) and/or MIP6-HA-FQDN 1134 attribute(s) as a proposal to the RADIUS server to indicate that the 1135 HA is to be assigned in the ASP. 1137 In step (2), the RADIUS server sends an Access-Accept packet with the 1138 MIP6-Feature-Vector with the Local Home Agent Assignment flag set or 1139 cleared. If the flag is cleared then the RADIUS server needs to 1140 provide one or more Home Agent(s) to be assigned to the MN. If the 1141 flag is set, then it indicates to the NAS that it can assign HA to 1142 the MN; the RADIUS server may also include one or more HA addresses 1143 thus indicating that the NAS can either allocate a local HA or one 1144 specified by the RADIUS server. 1146 In step (3) the MN performs home information discovery procedures as 1147 specified in [DHCPv6 for Home Info Discovery in MIPv6][hiopt]. The 1148 MN sends a DHCPv6 Information-request message including the Home 1149 Network Information option according to the stateless DHCPv6 1150 procedures [23] and [24]. The MN MUST also include the Option code 1151 for the Home Network Information option in the Option Request option 1152 in the request. The id-type of the Home Network Identifier Option is 1153 set to 1 indicating that the MN is requesting to discover the home 1154 network information that pertains to the given realm, i.e., the 1155 user's home domain (identified by the NAI of the MN). The 1156 OPTION_CLIENTID is set by the MN to identify itself to the DHCP 1157 server. 1159 In step (4) the DHCP relay agent forwards this request to the DHCP 1160 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 1161 message. This option carries the RADIUS MIP6-HA attribute received 1162 in the Access-Accept packet. 1164 In step (5), the DHCP server identifies the client (by DUID) and 1165 finds out that it requests HA information in the MSP (by the Home 1166 Network Identifier Option = 1). The DHCP server extracts the HA 1167 address from OPTION_MIP6-RELAY-Option and places it into Home Network 1168 Information Option in the Reply message. 1170 In step (6), the Relay Agent forwards the Reply Message to the MN. 1171 On reception of this message, the HA address or the FQDN of the HA is 1172 available at the MN. 1174 6.1.2. HA allocation in the ASP (visited network) 1176 This scenario is similar to the one described in Section 7.1.1. The 1177 difference is in step (4), where the type-id field in the Home 1178 Network Identifier Option is set to zero, indicating that a HA is 1179 requested in the ASP instead of in the MSP. Thus, the information 1180 received by the home RADIUS server, via the DHCP relay, in the 1181 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 1182 server allocates a HA from its list of possible HAs and returns it in 1183 the Reply message (Home Network Information Option). 1185 6.2. Use of RADIUS In Split Scenario 1187 In this section we present the call flows used in the Split scenario. 1188 In the Split scenario the MN can be authenticated and authorized for 1189 Mobile IPv6 by using IKEv2 or the Mobile IPv6 Authentication Protocol 1190 [3]. The authentication and or authorization takes place between the 1191 HA and the RADIUS server. 1193 6.2.1. Split using IKEv2 1195 This section describes IKEv2 based authentication and authorization 1196 for the SPLIT scenario using IKEv2 and EAP. Use of IKEv2 with 1197 certificates or preshared keys is not in scope for this document. 1199 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 1200 authenticate the MN. When EAP is used with IKEv2, the RADIUS EAP 1201 procedures, as defined in [6], are used. EAP methods that do not 1202 establish a shared key SHOULD NOT be used, as they are subject to a 1203 number of man-in-the-middle attacks as stated in Section 2.16 and 1204 Section 5 of RFC 4306 [25]. Attributes specific to Mobile IPv6 1205 bootstrapping are added to the AAA packets. 1207 Figure 4 shows the message flow involved during the authentication 1208 phase when EAP is used. 1210 ----------------------------ASP--------->|<-----MSA/MSP 1212 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 1213 | MN |<----------->| HA |<-------------------->| Home RADIUS Server | 1214 +----+ +----+ +--------------------+ 1216 Mobile Home RADIUS 1217 Node Agent Server 1218 | | | 1219 | HDR, SAi1, KEi, Ni (1) | | 1220 |-------------------------------->| | 1221 | | | 1222 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 1223 |<--------------------------------| | 1224 | | | 1225 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 1226 | [CP(CFG_REQUEST),] | | 1227 | SAi2, TSi, TSr} (3) | | 1228 |-------------------------------->| Access-Request | 1229 | | (EAP-Response) (4) | 1230 | |-------------------------->| 1231 | | | 1232 | | Access-Challenge | 1233 | | (EAP-Request) (5) | 1234 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<--------------------------| 1235 |<------------------------------- | | 1236 | | | 1237 | HDR, SK{EAP} | | 1238 |-------------------------------->|Access-Request(EAP-Res.) | 1239 | |-------------------------->| 1240 | | | 1241 | |Access-Challenge(EAP-Req.) | 1242 | HDR, SK{EAP-Request} |<--------------------------| 1243 |<--------------------------------| | 1244 | | | 1245 | HDR, SK{EAP-Response} | | 1246 |-------------------------------->|Access-Request (EAP-Res.) | 1247 | |-------------------------->| 1248 | ... | ... | 1249 | | | 1250 | |Access-Accept(EAP-Success) | 1251 | (6)|<--------------------------| 1252 | HDR, SK{EAP-Success} | | 1253 |<--------------------------------| | 1254 | | | 1255 | HDR, SK{AUTH} | | 1256 |-------------------------------->| | 1257 | | | 1258 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 1259 | SAr2, TSi, TSr} | | 1260 |<--------------------------------| | 1261 | | | 1263 Figure 4: Split Scenario Exchange Using IKEv2 and EAP 1265 Before this scenario started the MN has to know the IP address of the 1266 HA to use. The MN may be configured with the HA-IP address or the 1267 FQDN of the HA to use or with a mobility service name. In the case 1268 where the MN is configured with the domain name of the HA or a 1269 mobility service name, it uses DNS to resolve the IP address of the 1270 HA to use. Alternatively, MN could have received the information by 1271 performing a DHCP request as per [26] 1273 The MN and the HA start the interaction with an IKE_SA_INIT 1274 exchange(1)(2). In this phase cryptographic algorithms are 1275 negotiated, nonces and Diffie-Hellman parameters are exchanged. 1277 Exchange (3) starts the IKE_AUTH phase. This second phase of IKEv2 1278 authenticates the previous messages, exchanges identities and 1279 certificates and establishes the first CHILD_SA. It is used to 1280 mutually authenticate the MN (acting as an IKEv2 Initiator) and the 1281 HA (acting as an IKEv2 Responder). The identity of the user/MN is 1282 provided in the IDi field. The MN indicates its willingness to be 1283 authenticated via EAP by omitting the AUTH field in message (3) (see 1284 Section 2.16 of [25]). 1286 As part of the authentication process, the MN MAY request a Home- 1287 Address, a Home Prefix or suggests one, see [27], using a CFG_REQUEST 1288 payload in the exchange(3). 1290 The HA extracts the IDi field from exchange (3) and sends a RADIUS 1291 Access-Request packet(4) towards the authenticating RADIUS server. 1292 The User-Name(1) attribute is set to the value received in the IDi 1293 field and the EAP-Payload attribute contains a EAP-Response/ Identity 1294 with the identity extracted from the IDi field. The Access-Request 1295 packet is integrity protected by the Message-Authenticator(89) 1296 attribute. 1298 This message is routed to the MN's home RADIUS server/EAP server. 1299 The RADIUS server selects the EAP method and replies with the RADIUS 1300 Access-Challenge packet(5). Depending on the type of EAP method 1301 chosen, a number of Access-Request and Access-Challenge exchanges are 1302 conducted to execute the EAP method between the MN and the RADIUS 1303 server/EAP server. 1305 At the end of the EAP authentication phase, the RADIUS server 1306 indicates the result of the authentication by either sending an 1307 Access-Accept packet(6) containing EAP-Success or an Access-Reject 1308 packet containing EAP-Reject. The last IKEv2 message sent by the HA 1309 contains the Home Address or the Home Prefix. In the latter case, a 1310 CREATE_CHILD_SA exchange is necessary to setup IPSec SAs for Mobile 1311 IPv6 signaling. 1313 In some deployment scenarios, the HA may also acts as a IKEv2 1314 Responder for IPSec VPN access. A problem in this case is that the 1315 IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service 1316 or for IPSec VPN access service. A network operator needs to be 1317 aware of this limitation. The MN may provide a hint of the intended 1318 service, for example, by using different identities in the IKE_AUTH 1319 message for the IPSec VPN service and Mobile IPv6 service. However, 1320 the use of different identities during the IKEv2 negotiation is 1321 deployment specific. Another possibility is to make the distinction 1322 on the MN subscription basis. In this case the RADIUS server can 1323 inform the HA during the IKEv2 negotiation whether the MN is 1324 provisioned with an IPSec VPN access service or Mobile IPv6 service. 1326 Eventually, when the HA receives a Binding Update (BU), the HA 1327 authenticates and authorizes the MN. It is RECOMMENDED that the HA 1328 sends a RADIUS accounting request message every time it receives a 1329 BU. Alternatively, if the HA does not support RADIUS Accounting, it 1330 SHOULD send a User-Session-Notification packet as defined in [9] to 1331 inform the AAA server that the mobile ip session has termianted. 1333 6.2.2. Split and Mobile IPv6 Authentication Protocol 1335 Figure 5 shows the message sequence between the MN, the HA and the 1336 RADIUS server during the registration when Mobile IPv6 Authentication 1337 Protocol is used. A BU and a Binding Acknowledgement (BA) messages 1338 are used in the binding registration process. 1340 Mobile IPv6 Authentication Protocol as specfied in [3] allows the 1341 initial BU to be protected using the MN-HA key or the MN-AAA key. 1342 Support for the use of MN-HA key to protected the initial BU is not 1343 in scope of this specification. 1345 Receiving a BU at the HA initiates a MIP6-Request to be sent to the 1346 RADIUS server. The RADIUS server in turn responds with an Access- 1347 Accept or an Access-Reject. The HA may assign a Home Address to the 1348 MN and provide it to the RADIUS server in the MIP6-HOA attribute. 1350 According to [3] the MN uses the Mobile Node Identifier Option, 1351 specifically the MN-NAI mobility option (as defined in [20]) to 1352 identify itself. The HA MUST copy the MN-NAI mobility option value 1353 to the User-Name(1) attribute in the Access-Request packet. 1355 The procedure described in this specification for the Mobile IPv6 1356 Authentication Protocol is only needed for the initial BU received by 1357 the HA. When the HA receives subsequent BUs, they are processed 1358 locally in the HA using the MN-HA key received from the AAA upon 1359 successful authentication and authorization. It is RECOMMENDED that 1360 the HA sends an accounting request packet upon each new BU update 1361 reauthentication. 1363 Upon receiving a BU containing the MN-AAA Mobile Message 1364 Authentication Option, the HA extracts the Mobility SPI from the 1365 Mobility Message Authentication Option and sends it to the RADIUS 1366 server in the MIP6-MN-AAA-SPI attribute. The HA also extract the 1367 Authentication Data from the Message Authentication Option and 1368 includes it in the Access-Request in the MIP6-Authenticator 1369 attribute. The HA includes the MIP6-Auth-Mode attribute in the 1370 Access-Request setting its value to MIP6_AUTH_MN_AAA indicating that 1371 the MN-AAA key is used as the credential protecting the BU. 1373 In the case of RADIUS based authentication, the Mobility SPI MUST be 1374 set the well-know value HMAC-SHA1_SPI (see section 8 of [3]). In 1375 this case the HA SHALL compute the MAC_Mobility Data as per [3] using 1376 HMAC_SHA1 as the hash_fn() and include the result in the MIP6-MAC- 1377 Mobility-Data attribute in the Access-Request. 1379 The HA inlcudes the MIP6-Authenticator attribute set to the 1380 authenticator data extracted from the MN-AAA Mobility Message 1381 Authentication Option contained in the BU message. 1383 The MIP6-Timestamp attribute is set to the value contained in the 1384 mobility message prelay protection option defined in [3] if 1385 available. 1387 Upon receiving the Access-Request packet from the HA, the RADIUS 1388 server MUST ensure that the MIP6-Auth-Mode attribute is present and 1389 set to MIP6_AUTH_MN_AAA. If not, the RADIUS Server SHALL respond 1390 with an Access-Reject packet which includes Error-Cause (101) 1391 attribute with value set to "Invalid Attribute Value". Upon 1392 receiving an Access-Reject with Error-Cause (101) attribute set to 1393 "Invalid Attribute Value", the HA SHALL reject the BU. 1395 The Access-Request packet MUST contain the MIP6-MN-AAA-SPI attribute 1396 with a SPI set the well-know value HMAC-SHA1_SPI (see section 8 of 1397 [3]). If not, the RADIUS server SHALL repond back to the HA with an 1398 Access-Reject packet contain Error-Cause (101) attribute set to 1399 "Missing Attribute". 1401 The RADIUS server uses the data received in the MIP6-MAC-Mobility- 1402 Data attribute to computes its own version of the Authenticator as 1403 per [3]. The RADIUS server compares the value computed to the value 1404 received in the MIP6-Authenticator. If the values don't match the 1405 RADIUS server SHALL respond back with an Access-Reject packet. 1407 If the MN is authenticated and is authorized for MIP6 service, the 1408 RADIUS server responds back with an Access-Accpet otherwise it 1409 responds with an Access-Reject. In the case of Access-Accept and if 1410 the MIP6-MN-HA-SPI value was inclued in the Access-Request packet, 1411 the RADIUS server includes the MN-HA security association parameters 1412 associated with the MN-HA SPI and the NAI received in the User-Name 1413 attributes in the MS-MPPE-Recv-Key, MS-MPPE-Send-Key, MIP6-Algorithm- 1414 Type, MIP6-Replay-Mode, MIP6-Nonce. The MS-MPPE-Recv-Key, MS-MPPE- 1415 Send-Key must be encrypted using the procedures defined in section 1416 3.3 of [10]. The RADIUS Access-Accept packet MUST be integrity 1417 protected using Message-Authenticator(89) attribute. 1419 If the RADIUS server detected a replay attack when checking the MIP6- 1420 Timestamp received in the Access-Request fromt he HA. The RADIUS 1421 server SHALL respond back with an Access-Reject. 1423 Mobile Home Diameter 1424 Node Agent Server 1425 | | | 1426 | | | 1427 | Binding Update |RADIUS Access-Request| 1428 |------------------------------------>|-------------------->| 1429 | (Mobile Node Identifier Option, | | 1430 | Mobility Message Replay Protection | | 1431 | Option, Authentication Option) | | 1432 | | | 1433 | | | 1434 | Binding Acknowledgement |RADIUS Access-Accept | 1435 | |or Access-Reject | 1436 |<------------------------------------|<--------------------| 1437 | (Mobile Node Identifier Option | | 1438 | Mobility Message Replay Protection | | 1439 | Option, Authentication Option) | | 1440 | | Acct-Request(start) | 1441 | |-------------------->| 1443 Figure 5: Mobile IPv6 Bootstrapping using the Mobile IPv6 1444 Authentication Protocol 1446 7. Goals for the HA-AAA Interface 1448 Here, we follow the classification and labels listed in the MIPv6- 1449 AAA-Goals document [28]. 1451 7.1. General Goals 1453 G1.1-G1.4 Security 1455 These are standard requirements for a AAA protocol - mutual 1456 authentication, integrity, replay protection, confidentiality. IPsec 1457 can be used to achieve the goals. Goal G1.5 regarding inactive peer 1458 detection needs further investigations since heartbeat messages do 1459 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 1461 7.2. Service Authorization 1463 G2.1. The AAA-HA interface should allow the use of Network Access 1464 Identifier (NAI) to identify the MN. The User-Name attribute can be 1465 used for the purpose to carry the NAI. 1467 G2.2 The HA should be able to query the AAAH server to verify Mobile 1468 IPv6 service authorization for the MN. Any node implementing RADIUS 1469 functionality[11] can possibly initiate a request message. In 1470 combination with the ability of the RADIUS protocol to carry EAP 1471 messages [6] , our solution will enable an HA to query a RADIUS 1472 server and verify MIPv6 authorization for the MN. 1474 G2.3 The AAAH server should be able to enforce explicit operational 1475 limitations and authorization restrictions on the HA (e.g., packet 1476 filters, QoS parameters). Work in progress in the area, including 1477 NAS-Filter-Rule, RADIUS quality of service support, prepaid 1478 extensions etc. is performed. The relevant attributes may be reused 1479 for providing required functionality over the AAAH-HA interface. 1481 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 1482 session by the AAAH server, e.g., authorization lifetime, extension 1483 of the authorization lifetime and explicit session termination by the 1484 AAAH server side. 1486 The attribute Session-Timeout may be sent in Access-Challenge or 1487 Access-Accept packet by the RADIUS server, thus limiting the 1488 authorization session duration. In order to reauthenticate/ 1489 reauthorize the user, the Termination-Action attribute can be 1490 included, with value 1, meaning the NAS should send a new RADIUS- 1491 Request packet. Additional AVPs for dealing with pre-paid sessions 1492 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 1493 specified in RADIUS prepaid extension. Exchanging of application 1494 specific authorization request/answer messages provides extension of 1495 the authorization session (e.g., Authorize Only Access-Request sent 1496 by the HA (NAS) to the RADIUS server). Initiation of the re- 1497 authorization by both sides could be supported. Both sides could 1498 initiate session termination - the RADIUS server by sending 1499 Disconnect message [29]. 1501 7.3. Accounting 1503 G3.1 The AAA-HA interface must support the transfer of accounting 1504 records needed for service control and charging. These include (but 1505 may not be limited to): time of binding cache entry creation and 1506 deletion, octets sent and received by the MN in bi-directional 1507 tunneling, etc. 1509 The requirements for accounting over the AAAH-HA interface does not 1510 require enhancements to the existing accounting functionality. 1512 7.4. MN Authentication 1514 G4.1 The AAA-HA interface MUST support pass-through EAP 1515 authentication with the HA working as EAP authenticator operating in 1516 pass-through mode and the AAAH server working as back-end 1517 authentication server. 1519 These issues require the functionality of AAAH server working as a 1520 back-end authentication server and HA working as NAS and EAP 1521 authenticator in pass-through mode for providing a MN authentication. 1522 This document suggests this mode of operation in the context of the 1523 relevant scenarios. 1525 7.5. Provisioning of Configuration Parameters 1527 G5.1 The HA should be able to communicate to the AAAH server the HOA 1528 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 1529 update on behalf of the MN). 1531 This document describes needed AVPs for this purpose, see section 1532 "DNS Update Mobility Option Attribute" 1534 8. Table of Attributes 1536 The following tables provides a guide to which attributes may be 1537 found in RADIUS packet and in what number. 1539 The following defines the meaning of the notation used in the following 1540 tables: 1542 0 An instance of this attribute MUST NOT be present. 1543 1 Exactly one instance of this attribute MUST be present 1544 0-1 Zero or one instance of this attribute MAY be present. 1545 0+ Zero or more instance of this attriubte MAY be present 1547 The table below describes the RADIUS messages used for bootstrapping and are 1548 exchanged between the NAS and the RADIUS Server. 1550 Request Accept Reject Challenge Type Attribute 1551 1 1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1552 0+[ac] 0+[a] 0 0 MIP6-HA-TYPE MIP6-HA 1553 0+[ac] 0+[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN 1554 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix 1555 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1556 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO 1558 Notes: 1560 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 1562 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 1563 then these attributes MUST also be present in the Access-Request. 1564 If the RADIUS server accepts the NAS suggestion for the HA, then 1565 the RADIUS server MUST also include the values received for these 1566 attributes in the Access-Accept. 1568 [c] If these attributes are present in an Access-Request, then 1569 LOCAL_HOME_AGENT_ASSIGNMENT flag of the MIP6-Feature-Vector MUST be set. 1570 Otherwise these attributes are ignored. 1572 The following tables lists the commands and attributes used in the interaction 1573 between the HA and RADIUS server. Each table corresponds to the different 1574 authentication modes supported. These attributes are in addition to the any 1575 other attributes specified by an other specification (for example, RADIUS EAP) 1577 Table of attributes for IKEv2 and EAP-based Authentication: 1579 Request Accept Reject Challenge Type Attribute 1580 1 0 0 0 61 NAS-Port-Type 1581 1 0 0 0 80 Message-Authenticator 1582 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1583 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1584 0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1585 0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1586 0-1 0 0 0 MIP6-HA-TYPE MIP6-HA 1587 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1588 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1589 0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1590 0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1591 0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1592 0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1593 0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1595 Table of attribute for MIPv6 Authentication Protocol: 1597 Request Accept Reject Challenge Type Attribute 1598 1 0 0 0 61 NAS-Port-Type 1599 0-1 0 0 0 80 Message-Authenticator 1600 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1601 1 0 0 0 MIP6-AUTH-MODE-TYPE MIP6-Auth-Mode 1602 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1603 1 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1604 1 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1605 1 0 0 0 MIP6-HA-TYPE MIP6-HA 1606 1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1607 1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1608 0-1 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1609 0 1 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1610 0 1 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1611 0 1 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1612 0 1 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1614 As used in accounting packets: 1616 Request Interim Stop Type Attribute 1618 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 1619 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 1620 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 1621 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 1622 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 1624 9. Diameter Considerations 1626 When used in Diameter, the attributes defined in this specification 1627 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 1628 attribute compatibility space). No additional Diameter Code values 1629 are therefore allocated. The data types and flag rules for the 1630 attributes are as follows: 1632 +---------------------+ 1633 | AVP Flag rules | 1634 |----+-----+----+-----|----+ 1635 | | |SHLD| MUST| | 1636 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 1637 -------------------------------|----+-----+----+-----|----| 1638 MIP6-HA Address | M | P | | V | Y | 1639 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 1640 MIP6-HL-Prefix OctetString| M | P | | V | Y | 1641 MIP6-HOA Address | M | P | | V | Y | 1642 MIP6-DNS-MO OctetString| M | P | | V | Y | 1643 -------------------------------|----+-----+----+-----|----| 1645 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 1646 have no special translation requirements for Diameter to RADIUS or 1647 RADIUS to Diameter gateways; they are copied as is, except for 1648 changes relating to headers, alignment, and padding. See also [12] 1649 Section 4.1 and [30] Section 9. MIP6-HA and HOA-IPv6 must be 1650 translated between their RADIUS representation of String to a 1651 Diameter Address format which requires that the AddressType field be 1652 set to 2 for IP6 (IP version 6) 1654 What this specification says about the applicability of the 1655 attributes for RADIUS Access-Request packets applies in Diameter to 1656 AA-Request [30] or Diameter-EAP-Request [31]. What is said about 1657 Access-Challenge applies in Diameter to AA-Answer [30] or Diameter- 1658 EAP-Answer [31] with Result-Code AVP set to 1659 DIAMETER_MULTI_ROUND_AUTH. 1661 What is said about Access-Accept applies in Diameter to AA-Answer or 1662 Diameter-EAP-Answer messages that indicate success. Similarly, what 1663 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1664 Answer or Diameter-EAP-Answer messages that indicate failure. 1666 What is said about Accounting-Request applies to Diameter Accounting- 1667 Request [30] as well. 1669 10. Security Considerations 1671 Assignment of these values to a user should be based on successful 1672 authentication of the user at the NAS and/or at the HA. The RADIUS 1673 server should only assign these values to a user who is authorized 1674 for Mobile IPv6 service (this check could be performed with the 1675 user's subscription profile in the Home Network). 1677 The NAS and the HA to the RADIUS server transactions must be 1678 adequately secured. Otherwise there is a possibility that the user 1679 may receive fraudulent values from a rogue RADIUS server potentially 1680 hijacking the user's Mobile IPv6 session. 1682 These new attributes do not introduce additional security 1683 considerations besides the ones identified in [11]. 1685 11. IANA Considerations 1687 11.1. Registration of new AVPs 1689 This specification defines the following new RADIUS attributes: 1691 MIP6-Feature-Vector is set to MIP6-FV-TYPE 1693 MIP6-HA is set to MIP6-HA-TYPE 1695 MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE 1697 MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE 1699 MIP6-HOA is set to MIP6-HOsA-TYPE 1701 MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE 1703 11.2. New Registry: Mobility Capability 1705 For MIP6-FV-TYPE flag values must be generated: 1707 Token | Value | Description 1708 ----------------------------------+----------------------+------------ 1709 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 1710 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 1711 Available for Assignment via IANA | 2^x | 1713 Allocation rule: Only numeric values that are 2^x (power of two) are 1714 allowed based on the allocation policy described below. 1716 Following the policies outlined in [1] new values with a description 1717 of their semantic for usage with the MIP6-Feature-Vector AVP together 1718 with a Token will be assigned after Expert Review initiated by the 1719 O&M Area Directors in consultation with the DIME working group chairs 1720 or the working group chairs of a designated successor working group. 1721 Updates can be provided based on expert approval only. A designated 1722 expert will be appointed by the O&M Area Directors. No mechanism to 1723 mark entries as "deprecated" is envisioned. Based on expert approval 1724 it is possible to delete entries from the registry. 1726 11.3. Addition of existing values 1728 A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) 1730 12. Acknowledgements 1732 We would like to thank the following individuals for their review and 1733 constructive comments during the development of this document: 1735 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1736 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1738 13. References 1740 13.1. Normative References 1742 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1743 Levels", BCP 14, RFC 2119, March 1997. 1745 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1746 Integrated Scenario", 1747 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1748 progress), April 2008. 1750 [3] Patel, A., "Authentication Protocol for Mobile IPv6", 1751 draft-patel-mip6-rfc4285bis-00 (work in progress), 1752 October 2006. 1754 [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1756 [5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1757 RFC 2548, March 1999. 1759 [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1760 In User Service) Support For Extensible Authentication Protocol 1761 (EAP)", RFC 3579, September 2003. 1763 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1764 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 1765 July 2007. 1767 [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1768 for Message Authentication", RFC 2104, February 1997. 1770 [9] Zorn, G. and A. Lior, "User Session Tracking in RADIUS", 1771 draft-zorn-radius-logoff-11 (work in progress), February 2008. 1773 [10] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1774 and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", 1775 RFC 2868, June 2000. 1777 [11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1778 Authentication Dial In User Service (RADIUS)", RFC 2865, 1779 June 2000. 1781 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1782 "Diameter Base Protocol", RFC 3588, September 2003. 1784 [13] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1785 Levkowetz, "Extensible Authentication Protocol (EAP)", 1786 RFC 3748, June 2004. 1788 13.2. Informative References 1790 [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1791 IPv6", RFC 3775, June 2004. 1793 [15] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1794 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1796 [16] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and 1797 M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to 1798 Diameter Server Interaction", draft-ietf-dime-mip6-split-13 1799 (work in progress), October 2008. 1801 [17] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1802 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1803 Server to Diameter Server Interaction", 1804 draft-ietf-dime-mip6-integrated-10 (work in progress), 1805 September 2008. 1807 [18] Manner, J. and M. Kojo, "Mobility Related Terminology", 1808 RFC 3753, June 2004. 1810 [19] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1811 IKEv2 and the revised IPsec Architecture", 1812 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1813 December 2006. 1815 [20] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1816 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1817 RFC 4283, November 2005. 1819 [21] Mockapetris, P., "Domain names - implementation and 1820 specification", STD 13, RFC 1035, November 1987. 1822 [22] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1823 August 2002. 1825 [23] Droms, R., "Stateless Dynamic Host Configuration Protocol 1826 (DHCP) Service for IPv6", RFC 3736, April 2004. 1828 [24] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1829 Carney, "Dynamic Host Configuration Protocol for IPv6 1830 (DHCPv6)", RFC 3315, July 2003. 1832 [25] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1833 RFC 4306, December 2005. 1835 [26] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options 1836 for Home Information Discovery in MIPv6", 1837 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 1839 [27] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1840 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1841 April 2007. 1843 [28] Giaretta, G., "AAA Goals for Mobile IPv6", 1844 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1845 September 2006. 1847 [29] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1848 "Dynamic Authorization Extensions to Remote Authentication Dial 1849 In User Service (RADIUS)", RFC 5176, January 2008. 1851 [30] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1852 Network Access Server Application", RFC 4005, August 2005. 1854 [31] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1855 Authentication Protocol (EAP) Application", RFC 4072, 1856 August 2005. 1858 [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1859 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1860 April 1997. 1862 [33] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1863 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1864 Agents", RFC 3776, June 2004. 1866 [34] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1867 "DNS Security Introduction and Requirements", RFC 4033, 1868 March 2005. 1870 Authors' Addresses 1872 Avi Lior 1873 Bridgewater Systems 1874 303 Terry Fox Drive, Suite 100 1875 Ottawa, Ontario 1876 Canada K2K 3J1 1878 Phone: +1 613-591-6655 1879 Email: avi@bridgewatersystems.com 1881 Kuntal Chowdhury 1882 Starent Networks 1883 30 International Place 1884 Tewksbury, MA 01876 1885 US 1887 Phone: +1 214-550-1416 1888 Email: kchowdhury@starentnetworks.com 1890 Hannes Tschofenig 1891 Nokia Siemens Networks 1892 Linnoitustie 6 1893 Espoo 02600 1894 Finland 1896 Phone: +358 (50) 4871445 1897 Email: Hannes.Tschofenig@gmx.net 1898 URI: http://www.tschofenig.priv.at 1900 Full Copyright Statement 1902 Copyright (C) The IETF Trust (2008). 1904 This document is subject to the rights, licenses and restrictions 1905 contained in BCP 78, and except as set forth therein, the authors 1906 retain all their rights. 1908 This document and the information contained herein are provided on an 1909 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1910 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1911 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1912 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1913 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1916 Intellectual Property 1918 The IETF takes no position regarding the validity or scope of any 1919 Intellectual Property Rights or other rights that might be claimed to 1920 pertain to the implementation or use of the technology described in 1921 this document or the extent to which any license under such rights 1922 might or might not be available; nor does it represent that it has 1923 made any independent effort to identify any such rights. Information 1924 on the procedures with respect to rights in RFC documents can be 1925 found in BCP 78 and BCP 79. 1927 Copies of IPR disclosures made to the IETF Secretariat and any 1928 assurances of licenses to be made available, or the result of an 1929 attempt made to obtain a general license or permission for the use of 1930 such proprietary rights by implementers or users of this 1931 specification can be obtained from the IETF on-line IPR repository at 1932 http://www.ietf.org/ipr. 1934 The IETF invites any interested party to bring to its attention any 1935 copyrights, patents or patent applications, or other proprietary 1936 rights that may cover technology that may be required to implement 1937 this standard. Please address the information to the IETF at 1938 ietf-ipr@ietf.org.