idnits 2.17.00 (12 Aug 2021) /tmp/idnits51801/draft-ietf-mip6-radius-04.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 1789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1813. 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 (February 25, 2008) is 5198 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 1626 == Unused Reference: '22' is defined on line 1735, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1743, 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') ** Obsolete normative reference: RFC 3588 (ref. '4') (Obsoleted by RFC 6733) ** 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') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '10') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '16') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '17') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '19') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '20') (Obsoleted by RFC 7155) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 Internet-Draft Bridgewater Systems 4 Intended status: Standards Track K. Chowdhury 5 Expires: August 28, 2008 Starent Networks 6 H. Tschofenig 7 Siemens 8 February 25, 2008 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-04.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 August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines new attributes to facilitate Mobile IPv6 45 operationrs using RADIUS infratstructure. The operations include 46 bootstrapping of information required by the Mobile and the interface 47 between the Home Agent and the RADIUS server used to assist MIP6 48 operations. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. RADIUS Transaction in Integrated Scenario . . . . . . . . 7 56 3.2. RADIUS Transactions in Split Scenario . . . . . . . . . . 8 57 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 11 58 4.1. MIP6-Feature-Vector . . . . . . . . . . . . . . . . . . . 11 59 4.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 11 60 4.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 11 61 4.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 11 62 4.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 11 63 4.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 12 64 4.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 12 65 4.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 12 66 4.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 12 67 4.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 12 68 4.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 13 69 4.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 13 70 4.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 13 71 4.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 13 72 4.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Use of existing RADIUS Attributes . . . . . . . . . . . . . . 14 74 5.1. User-Name . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.2. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 14 77 5.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . . . 14 78 5.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . 14 79 5.6. Session-Timeout . . . . . . . . . . . . . . . . . . . . . 14 80 5.7. Message Authenticator . . . . . . . . . . . . . . . . . . 15 81 6. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. MIP6-Feature-Vector Attribute . . . . . . . . . . . . . . 16 83 6.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 17 84 6.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 18 85 6.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 19 86 6.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 20 87 6.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 21 88 6.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 22 89 6.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 23 90 6.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 24 91 6.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 24 92 6.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 25 93 6.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 25 94 6.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 26 95 6.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 26 96 6.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 27 97 7. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 29 98 7.1. Use of RADIUS in Integrated Scenario (MSA=ASA) . . . . . . 29 99 7.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 29 100 7.1.2. HA allocation in the ASP (visited network) . . . . . . 31 101 7.2. Use of RADIUS In Split Scenario (MSA!=ASA) . . . . . . . . 31 102 7.2.1. Mobile Service Provider and Mobile Service 103 Authorizer are the same entity. . . . . . . . . . . . 31 104 7.2.2. Mobile Service Provider and Mobile Service 105 Authorizer are different entities. . . . . . . . . . . 34 106 8. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 35 107 8.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 35 108 8.2. Service Authorization . . . . . . . . . . . . . . . . . . 35 109 8.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 36 110 8.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 36 111 8.5. Provisioning of Configuration Parameters . . . . . . . . . 36 112 9. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 37 113 10. Diameter Considerations . . . . . . . . . . . . . . . . . . . 40 114 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 115 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 116 12.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 42 117 12.2. New Registry: Mobility Capability . . . . . . . . . . . . 42 118 12.3. Addition of existing values . . . . . . . . . . . . . . . 42 119 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 44 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 44 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 124 Intellectual Property and Copyright Statements . . . . . . . . . . 47 126 1. Introduction 128 This document covers two aspects of MIP6 operations: bootstrapping of 129 information required by a Mobile IPv6 Mobile using the AAA 130 infrastructure and the interaction between the MIPv6 HA and the AAA 131 infrastructure. 133 Mobile IPv6 specification [10] requires a Mobile Node (MN) to perform 134 registration with an HA with information about its current point of 135 attachment (Care-of Address). The HA creates and maintains binding 136 between the MN's HOA and the MN's Care-of Address. 138 In order to register with a HA, the MN needs to know some information 139 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 140 prefix Length and security related information in order to secure the 141 Binding Update. 143 The aforementioned set of information may be statically provisioned 144 in the MN. However, static provisioning of this information has its 145 drawbacks. It increases provisioning and network maintenance burden 146 for the operator. Moreover, static provisioning does not allow load 147 balancing, failover, opportunistic home link assignment etc. For 148 example, the user may be accessing the network from a location that 149 may be geographically far away from the preconfigured home link; the 150 administrative burden to configure the MN's with the respective 151 addresses is large and the ability to react on environmental changes 152 is minimal. In these situations static provisioning may not be 153 desirable. 155 Dynamic assignment of Mobile IPv6 home registration information is a 156 desirable feature for ease of deployment and network maintenance. 157 For this purpose, the RADIUS infrastructure, which is used for access 158 authentication, can be leveraged to assign some or all of the 159 necessary parameters. The RADIUS server in the Access Service 160 Provider (ASP) or in the Mobility Service Provider's (MSP) network 161 may return these parameters to the AAA client. The AAA client might 162 either be the NAS, in case of the integrated scenario, or the HA, in 163 case of the split scenario. The terms integrated and split are 164 described in the terminology section and were introduced in [11]. 166 The second aspect of MIP6 and RADIUS interworking is the interaction 167 between the HA and the AAA using the RADIUS AAA protocols. From a 168 mobility service provider (MSP) perspective, it is important to 169 verify that the MN is authenticated and authorized to utilize Mobile 170 IPv6 service and that such services are accounted for. Thus, prior 171 to processing the Mobile IPv6 registrations, the HA, participates in 172 the authentication of the MN to verify the MN's identity. The HA 173 alsoparticipates in the Mobile IPv6 authorization process involving 174 the RADIUS infrastructure. The HA, due to its role in traffic 175 forwarding, may also perform accounting for the Mobile IPv6 service 176 provided to the MN. This document specifies the interaction between 177 the HA and the RADIUS server and aligns with the work done in with 178 the Diameter specifications described in [12]. 180 2. Terminology 182 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [1]. 186 General mobility terminology can be found in [13]. The following 187 additional terms, as defined in [11], are used in this document: 189 Access Service Authorizer (ASA): 191 A network operator that authenticates a mobile node and 192 establishes the mobile node's authorization to receive Internet 193 service. 195 Access Service Provider (ASP): 197 A network operator that provides direct IP packet forwarding to 198 and from the end host. 200 Mobility Service Authorizer (MSA): 202 A service provider that authorizes Mobile IPv6 service. 204 Mobility Service Provider (MSP): 206 A service provider that provides Mobile IPv6 service. In order to 207 obtain such service, the MN must be authenticated and authorized 208 to obtain the Mobile IPv6 service. 210 Split Scenario: 212 A scenario where the mobility service and the network access 213 service are authorized by different entities. 215 Integrated Scenario: 217 A scenario where the mobility service and the network access 218 service are authorized by the same entity. 220 3. Solution Overview 222 This document addresses the authentication, authorization and 223 accounting functionality required by MIPv6 bootstrapping and 224 Authentication as outlined in the MIPv6 bootstrapping problem 225 statement document (see [11]). As such, the AAA functionality for 226 the integrated and the split scenario needs to be defined. This 227 requires the ability to offer support for the HA to AAA server and 228 the network access server(NAS) to AAA server communication. 230 To highlight the main use cases, we briefly describe the integrated 231 and the split scenarios in Section 3.1 and Section 3.2, respectively. 233 3.1. RADIUS Transaction in Integrated Scenario 235 In the integrated scenario MIPv6 bootstrapping is provided as part of 236 the network access authentication procedure. Figure 1 shows the 237 participating entity. 239 +---------------------------+ +-----------------+ 240 |Access Service Provider | |ASA/MSA/(/MSP) | 241 |(Mobility Service Provider)| | | 242 | | | +-------+ | 243 | +-------+ | | |Remote | | 244 | |Local | RADIUS | | |RADIUS | | 245 | |RADIUS |-------------------------|Server | | 246 | |Proxy | | | +-------+ | 247 | +-------+ | | ^ | 248 | ^ ^ | | |RADIUS | 249 | | | | | | | 250 | | | | | v | 251 | RADIUS| | | +-------+ | 252 | | | +-------+ | | |Local | | 253 | | | RADIUS |Home | | | |Home | | 254 | | +------->|Agent | | | |Agent | | 255 | | |in ASP | | | +-------+ | 256 | v +-------+ | +-----------------+ 257 +-------+ IEEE | +-----------+ +-------+ | 258 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 259 |Node |----------+-|RADIUS |---|Server | | 260 | | PANA,... | |Client | | | | 261 +-------+ DHCP | +-----------+ +-------+ | 262 +---------------------------+ 264 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 266 In the typical Mobile IPv6 access scenario as shown above, the MN 267 attaches in the ASP's network. During this network attachment 268 procedure, the NAS/RADIUS client interacts with the MN. As shown in 269 Figure 1, the authentication and authorization happens via a RADIUS 270 infrastructure. 272 At the time of authorizing the user for IPv6 access, the RADIUS 273 server in the MSA detects that the user is authorized for Mobile IPv6 274 access. Based on the MSA's policy, the RADIUS server may allocate 275 several parameters to the MN for use during the subsequent Mobile 276 IPv6 protocol interaction with the HA. 278 Depending on the details of the solution interaction with the DHCPv6 279 server may be required, as described in [2]. 281 3.2. RADIUS Transactions in Split Scenario 283 In the split scenario, Mobile IPv6 bootstrapping is not provided as 284 part of the network access authentication procedure. Other RADIUS 285 transactions such as authentication and authorization, accounting and 286 parameter configuration for MIP6 service is provided by the HA to 287 RADIUS transactions. 289 The Mobile IPv6 RADIUS transaction are executed with the Mobility 290 Service Provider when desired by the MN. Two variations can be 291 considered: 293 1. the MSA and the MSP are the same entity. 295 2. the MSA and the MSP are different entities. 297 Since scenario (2) is the more generic scenario we show it in 298 Figure 2. 300 +----------------------+ 301 | | 302 |Mobility +-------+ | 303 |Service |Remote | | 304 |Authorizer |RADIUS | | 305 |(MSA) |Server | | 306 | +-------+ | 307 +---------------^------+ 308 | 309 |RADIUS 310 | 311 | 312 +---------------------------------|------+ 313 |Mobility Service Provider (MSP) v | 314 +-------+ | +-----------+ +-------+ | 315 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 316 |Node |-------------|RADIUS |-------------- |RADIUS | | 317 | | IKEv2 | |Client | |Proxy | | 318 +-------+ | +-----------+ +-------+ | 319 +----------------------------------------+ 321 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 322 MSP) 324 As shown in Figure 2 the interaction between the RADIUS client and 325 the RADIUS server is triggered by the protocol interaction between 326 the MN and the HA/RADIUS client using IKEv2 [14] or MIPv6 327 Authentication Protocol [3]. The important aspect is, however, that 328 for these two approaches several different authentication and key 329 exchange solutions are available. To establish IPsec security 330 associations, protecting of Mobile IPv6 signaling messages IKEv2 is 331 used [14]. IKEv2 supports EAP-based authentication, certificates and 332 pre-shared secrets. For protecting using the MIPv6 Authentication 333 Protocol [3] a mechanism has been designed that is very similar to 334 the one used by Mobile IPv4. 336 The ability to use different credentials has an impact on the 337 interaction between the HA (acting as a Diameter client) and the 338 RADIUS Server. For that reason this document illustrates the usage 339 of these authentication mechanisms with different subsections for: 341 o IKEv2 usage with EAP 343 o IKEv2 usage with certificates and pre-shared secrets 345 o MIPv6 Authentication Protocol 347 For accounting of Mobile IPv6 services provided to the MN, this 348 specification uses the accounting application defined in [4]. 350 Additionally, the MN might instruct the RADIUS server (via the HA) to 351 perform a dynamic DNS update. 353 4. RADIUS Attribute Overview 355 4.1. MIP6-Feature-Vector 357 The MIP6-Feature-Vector when included in an Access-Request packet is 358 used by the NAS or the HA to indicate supported MIP6 features. For 359 example, a NAS uses this attribute to indicate whether it can provide 360 a local home agent. 362 When included in an Access-Accept packet, the MIP6-Feature-Vector is 363 used by the RADIUS Server to indicate supported MIP6 features and to 364 select advetized feature by the NAS. For example, if the NAS 365 indicated support for local home agent assignment, the RADIUS server 366 authorizes the NAS to support local home agent assignment by echoing 367 the setting the same flag in the Access-Accept packet. 369 4.2. MIP6-HA Attribute 371 In the case of bootstrapping, the RADIUS server may decide to assign 372 a HA to the MN that is in close proximity to the point of attachment 373 (e.g., as determined by the NAS-ID). There may be other reasons for 374 dynamically assigning HAs to the MN, for example to share the traffic 375 load. The attribute also contains the prefix length so that the MN 376 can easily infer the Home Link prefix from the HA address. 378 The MIP-Home-Agent-Address AVP contains the IPv6 address of the Home 379 Agent. The Home Agent address is the same as in the received BU 380 message. 382 4.3. MIP6-HA-FQDN Attribute 384 The RADIUS server may assign an FQDN of the HA to the MN. The mobile 385 node can perform DNS query with the FQDN to derive the HA address. 387 4.4. MIP6-HL-Prefix Attribute 389 For the same reason as the HA assignment, the RADIUS server may 390 assign a Home Link that is in close proximity to the point of 391 attachment (NAS-ID). The MN can perform [10] specific procedures to 392 discover other information for Mobile IPv6 registration. 394 4.5. MIP6-HOA Attribute 396 In the bootstrapping case, the RADIUS server may assign a HOA to the 397 MN. This allows the network operator to support mobile devices that 398 are not configured with static addresses. The attribute also 399 contains the prefix length so that the MN can easily infer the Home 400 Link prefix from the HA address. 402 In the case of interaction with the HA, the MIP6-HOA contains the 403 Home Agent assigned IPv6 Home Address of the Mobile Node. 405 If the MIP6-HOA AVP contains unspecified IPv6 address (0::0) in a 406 request message, then the Home Agent expects the RADIUS server to 407 assign the Home Address in a subsequent reply message. In case the 408 RADIUS server assigns only a Home Network Prefix to the Mobile Node 409 the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address 410 MUST be set to zero. 412 4.6. MIP6-DNS-MO Attribute 414 By using this payload the RADIUS client instructs the RADIUS server 415 to perform a dynamic DNS update. When this payload is included in 416 the reverse direction, i.e., from the RADIUS server to the RADIUS 417 client, it informs about the status of the dynamic DNS update. When 418 the payload is sent from the RADIUS client to the RADIUS server then 419 the response MUST include the MIP6-DNS-MO attribute. 421 4.7. MIP6-Careof-Address 423 The MIP6-Careof-Address contains the IPv6 Care-of Address of the 424 Mobile Node. The Home Agent extracts this IP address from the 425 received BU message. 427 4.8. MIP6-MN-AAA-SPI 429 The MIP6-MN-AAA-SPI attribute contains an SPI code extracted from the 430 Mobility Message Authentication Option included in the received BU 431 message. 433 4.9. MIP6-Authenticator 435 The MIP6-Authenticator contains the Authenticator Data from the 436 received BU message. The Home Agent extracts this data from the MN- 437 AAA Mobility Message Authentication Option included in the received 438 BU message and sends it to the RADIUS Server. 440 The RADIUS server computes its own version of the Authenticator Data 441 from the received MIP6-MAC-Mobility-Data (see below) and compares it 442 to the value received in the MIP6-Authenticator from the HA. If the 443 values match then the Mobile Node is authenticated. 445 4.10. MIP6-MAC-Mobility-Data 447 The MIP6-MAC-Mobility-Data contains the calculated MAC_Mobility_Data, 448 as defined in [3]. 450 4.11. MIP6-Timestamp 452 The MIP6-Timestamp contains the timestamp value from the Mobility 453 message replay protection option, defined in [3]. The Home Agent 454 extracts this value from the received BU message, if available. 456 The support for replay protection is an optional feature in [3]. 457 When the RADIUS server checks the timestamp provided by the MN via 458 the HA and recognizes a clock-drift (outside a locally defined replay 459 protection window) then it MUST initiate the re-synchronization 460 procedure by returning an Access-Accept packet with Result-Code set 461 to MIP6-TIMESTAMP-MISMATCH and attaches the MIP6-Timestamp including 462 it's current time back to the HA. 464 4.12. MIP6-MN-HA-SPI 466 The MIP6-MN-HA-SPI is part of a group of attributes used with the 467 MIPv6 Authentication Protocol. The attributes contains an SPI code 468 provided by the RADIUS server for the Mobile IPv6 MN-HA. 470 4.13. MIP6-Algorithm-Type 472 The MIP6-Algorithm-Type is part of a group of attributes used with 473 the MIPv6 Authentication protocol and contains Algorithm identifier 474 for the associated Mobile IPv6 MN-HA Authentication Option. The 475 Diameter server selects the algorithm type. Existing algorithm types 476 are defined in RFC 4004 that also fulfill current RFC 4285 477 requirements. 479 4.14. MIP6-Replay-Mode 481 The MIP6-Replay-Mode is part of a group of attributes used with the 482 MIPv6 Authentication protocol and contains the replay modes as 483 defined in RFC4004 to be used by the HA. 485 4.15. MIP6-Nonce 487 The MIP6-Nonce is part of a group of attributes used with the MIPv6 488 Authentication protocol and contains the nonce to send to the Mobile. 490 5. Use of existing RADIUS Attributes 492 5.1. User-Name 494 If authentication via IKEv2 is used then the User-Name attribute 495 SHALL be set to the IDi payload received in the IKE_AUTH exchange. 497 5.2. Service-Type 499 If the HA uses Service-Type(6) is SHALL set its value to "Framed"(2). 501 5.3. NAS-Port-Type 503 In order for the AAA to distingiues the source of the Access-Request 504 NAS-Port-Type(61) is used as follows: 506 When the Access-Request originates from an MIP6 HA, NAS-Port-Type 507 MUST be included and its value set to HA6(IANA-TBD1). 509 5.4. Calling-Station-Id 511 In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) 512 to send the MN's COA to the AAA. If used, the string value of the 513 Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. 515 5.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 517 To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize 518 the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. The 519 first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, 520 and the next up to 32 octets are stored into the MS-MPPE-Send-Key. 521 The encryption of these attributes is described in [5]. 523 5.6. Session-Timeout 525 The use of Session-Timeout attribue during bootstrapping operations 526 is covered by various RFC's. 528 The use of Session-Timeout attribute during the EAP exchanges between 529 the HA and the RADIUS server are as per [6]. 531 In the case of the RADIUS server sending Session-Timeout to the HA in 532 the Access-Accept packet, the HA SHALL use this time as the MIP 533 Registration Lifetime. 535 5.7. Message Authenticator 537 The use of Message Authenticator is mandated during EAP AAA 538 procedures by [6]. In the case of the HA sending an Access-Request 539 where EAP is not used, then the HA MUST also include the Message 540 Autheticator attribute in the Access-Request packet. 542 6. RADIUS attributes 544 This section defines format and syntax for the attribute that carries 545 the Mobile IPv6 parameters that are described in the previous 546 section. 548 The attributes MAY be present in Access-Request, Access-Accept, and 549 Accounting-Request packets. 551 6.1. MIP6-Feature-Vector Attribute 553 Exactly one of this attribute MUST be sent by the NAS or HA in an 554 Access-Request packet to inidcate support for MIP6. 556 Exactly one of this attribute MUST be sent by the RADIUS server in an 557 Access-Accept packet to indicate support for MIP6 and to select 558 features advetized by the NAS or the HA. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | MIP6 Features Vectors | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | MIP6 Features Vectors cont. | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | MIP6 Features Vectors cont. | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Type: 572 MIP6-FV-TYPE to be defined by IANA. 574 Length: 576 = 10 octets 578 Feature Flags: 580 This field is of type String. Supporting the following values: 582 MIP6_INTEGRATED (0x0000000000000001) 584 When this flag is set by the NAS then it means that the 585 Mobile IPv6 integrated scenario bootstrapping functionality 586 is supported by the NAS. When this flag is set by the 587 RADIUS server then the Mobile IPv6 integrated scenario 588 bootstrapping is supported by the RADIUS server. 590 LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) 592 When this flag is set by the NAS then a local home agent can 593 be assigned to the MN. When this flag is set by the 594 Diameter server then the assignment of location HAs is 595 authorized by the Diameter server. 597 RO_SUPPORTED (0x0000000800000000) 599 Route optimization is supported. When the Home Agent sets 600 this bit, it indicates support for the route optimization. 601 If this bit is unset in the returned Mobility-Capability 602 AVP, the HAAA does not authorize route optimization for the 603 MN. 605 In a case the Home Agent or the HAAA cannot authorize the 606 use of route optimization then the Home Agent will send a 607 Binding Acknowledgement with a Status Code set to 608 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This 609 Status Code indicates that the binding registration 610 succeeded but the Home Agent will fail all possible 611 subsequent route optimization attempts because of 612 subscription or operator policy. 614 6.2. MIP6-HA Attribute 616 One or more of this attribute MAY be sent by the NAS to the RADIUS 617 server in an Access-Request packet as a proposal by the NAS to 618 allocate a local HA to the MN. 620 One or more of this attribute MAY be sent by the RADIUS server to the 621 NAS in an Access-Accept packet. The attribute carries the HA address 622 that may be assigned to the MN. 624 [EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO 625 Attribute sent by the NAS to the RADIUS server in an Access-Request 626 packet as a hint to suggest a dynamic HA that may be assigned to the 627 MN. The RADIUS server MAY use this value or may ignore this 628 suggestion. 630 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 631 FQDN SHOULD appear in accounting packets to indicate the identity of 632 the serving HA for this session. 634 One and only one of this attribute SHALL be sent to the RADIUS server 635 by the HA. The value is set to the value of the Home Agent address 636 recieved in the BU. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type | Length | Reserved | Prefix-Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | IPv6 address of assigned HA | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | IPv6 address of assigned HA cont. | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | IPv6 address of assigned HA cont. | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | IPv6 address of assigned HA cont. | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | IPv6 address of assigned HA cont. | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | IPv6 address of assigned HA cont. | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Type: 658 MIP6-HA-TYPE to be defined by IANA. 660 Length: 662 = 28 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 IPv6 address of assigned HA: 675 128-bit IPv6 address of the assigned HA. 677 6.3. MIP6-HA-FQDN Attribute 679 One or more instance of this attribute MAY be sent by the NAS to the 680 RADIUS server in an Access-Request packet as a hint to suggest a 681 dynamic HA that may be assigned to the MN. The RADIUS server MAY use 682 this value or may ignore this suggestion. 684 One or more of this attribute is sent by the RADIUS server to the NAS 685 in an Access-Accept packet. The attribute carries the FQDN of the 686 assigned HA. 688 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 689 MIP6-HA SHOULD appear in accounting packets to indicate the identity 690 of the serving HA for this session. 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Type | Length | FQDN of the assigned HA ..... 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Type: 700 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 702 Length: 704 Variable length. 706 FQDN of the assigned HA: 708 The data field MUST contain a FQDN as described in [15]. 710 6.4. MIP6-HL-Prefix Attribute 712 This attribute is sent by the RADIUS-MIP server to the NAS in an 713 Access-Accept packet and carries the assigned Home Link prefix. 715 This attribute MAY be sent by the NAS to the RADIUS server in an 716 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 717 attribute as a hint to suggest a Home Link prefix that may be 718 assigned to the MN. The RADIUS server MUST use this value if it 719 accepts the NAS's HA suggestion. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Type | Length | Reserved | Prefix-Length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | | 727 | | 728 | Home Link Prefix | 729 | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Type: 733 ASSIGNED-HL-TYPE to be defined by IANA. 735 Length: 737 >= 4 octets + the minimum length of a prefix. 739 Reserved: 741 Reserved for future use. The bits MUST be set to zero by the 742 sender, and MUST be ignored by the receiver. 744 Prefix-Length: 746 This field indicates the prefix length of the Home Link. 748 Home Link Prefix: 750 Home Link prefix (upper order bits) of the assigned Home Link 751 where the MN should send binding update. 753 6.5. MIP6-HOA Attribute 755 This attribute is sent by the RADIUS server to the NAS in an Access- 756 Accept packet. The attribute carries the assigned Home IPv6 Address 757 for the MN. 759 This attribute MAY be sent by the NAS to the RADIUS server in an 760 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 761 attribute as a hint to suggest a Home Address that may be assigned to 762 the MN. The RADIUS server MUST use this value if it accepts the 763 NAS's HA suggestion. 765 If available at the NAS, this attribute SHOULD appear in the 766 accounting packets so that the IPv6 addressed used for this session 767 is known in the accounting stream. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type | Length | Reserved | Prefix-Length | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | 775 | | 776 | Assigned IPv6 HOA | 777 | | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Type: 781 ASSIGNED-HOA-TYPE to be defined by IANA. 783 Length: 785 = 20 octets. 787 Reserved: 789 Reserved for future use. The bits MUST be set to zero by the 790 sender, and MUST be ignored by the receiver. 792 Prefix-Length: 794 This field indicates the prefix length of the Home Link. 796 Assigned IPv6 HOA: 798 IPv6 HOA that is assigned to the MN. 800 6.6. MIP6-DNS-MO Attribute 802 The MIP6-DNS-MO attribute is used for triggering a DNS update by the 803 RADIUS server and to return the result to the RADIUS client. The 804 request MUST carry the MN's FQDN but the attribute carried in 805 response to the request MAY not carry a FQDN value. 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Type | Length | Reserved-1 | Status | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 |R| Reserved-2 | FQDN ... 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Type: 817 DNS-UPDATE-TYPE to be defined by IANA. 819 Length: 821 Variable length. 823 Reserved-1: 825 Reserved for future use. The bits MUST be set to zero by the 826 sender, and MUST be ignored by the receiver. 828 Status: 830 This 8 bit unsigned integer field indicates the result of the 831 dynamic DNS update procedure as defined in [7]. This field 832 MUST be set to 0 and ignored by the RADIUS server when the 833 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 834 server. When the MIP6-DNS-MO is provided in the response, 835 values of the Status field less than 128 indicate that the 836 dynamic DNS update was performed successfully by the RADIUS 837 server. Values greater than or equal to 128 indicate that the 838 dynamic DNS update was not successfully completed. The 839 following values for the Status field are currently defined: 841 0 DNS update performed 843 128 Reason unspecified 845 129 Administratively prohibited 847 130 DNS Update Failed 849 R flag: 851 If this bit for the R flag is set then the RADIUS client 852 requests the RADIUS server to remove the DNS entry identified 853 by the FQDN included in this attribute. If not set, the RADIUS 854 client is requesting the RADIUS server to create or update a 855 DNS entry with the FQDN specified in this attribute and the 856 Home Address carried in another attribute specified in this 857 document. 859 Reserved-2: 861 Reserved for future use. The bits MUST be set to zero by the 862 sender, and MUST be ignored by the receiver. 864 FQDN of the MN: 866 In an Access-Request packet the data field MUST contain a FQDN. 867 In an Access-Accept packet the data field MAY contain an FQDN. 868 FQDN is described in [15]. 870 6.7. MIP6-Careof-Address 872 This attribute is available to be sent from the HA to the RADIUS 873 Server. The value of the attribute is the IPv6 addresss of the 874 Care-of Address of the MN extracted from the BU message. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type | Length | Reserved | Prefix-Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 | | 883 | Assigned IPv6 COA | 884 | | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Type: 889 ASSIGNED-MIP6-CAREOF-ADDRESS-TYPE to be defined by IANA. 891 Length: 893 = 20 octets. 895 Reserved: 897 Reserved for future use. The bits MUST be set to zero by the 898 sender, and MUST be ignored by the receiver. 900 Prefix-Length: 902 This field indicates the prefix length of the COA Link. 904 Assigned IPv6 COA: 906 IPv6 COA that is assigned to the MN. 908 6.8. MIP6-MN-AAA-SPI 910 Is available to be sent in an Access-Accept packet from the RADIUS 911 server to he HA. It is part of a group of attributes used with the 912 MIPv6 Authentication Protocol and contains the Security Parameter 913 Index used to reference the MN-HA mobility security association. 915 This attribute MUST be present in an Access-Request sent from the HA 916 to the RADIUS Server when using MIPv6 Authentication Protocol. 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Type | Length | SPI | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | SPI cont. | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Type: 928 ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA. 930 Length: 932 6 octets 934 Integer representing a Security Parameter Index. 936 6.9. MIP6-Authenticator 938 This attribute is sent from the HA to the RADIUS server and contains 939 the Authenticator data from the BU message. The HA extract the data 940 form the MN-AAA Mobility Message Authentication Option if included in 941 the received BU message. 943 This attribute MUST be present in an Access-Request sent from the HA 944 to the RADIUS Server when using MIPv6 Authentication Protocol. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Type | Length | Authenticator Data | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Authenticator Data cont .... 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Type: 956 ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA. 958 Length: 960 Variable length 962 String. An octetstring representing authenticator data. 964 6.10. MIP6-MAC-Mobility-Data 966 Attribute is sent from the HA to the RADIUS Server. The attribute 967 contains the calculated MAC_Mobility_Data as defined in [3]. 969 This attribute MUST be present in an Access-Request sent from the HA 970 to the RADIUS Server when using MIPv6 Authentication Protocol. 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type | Length | MAC Mobility Data | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | MAC Mobility Data cont .... 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 Type: 982 ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA. 984 Length: 986 Variable length 988 String. An octetstring representing authenticator data. 990 6.11. MIP6-Timestamp 992 This attribute is sent from the HA to the RADIUS server when 993 performing MIP6 Authentication protocol. The attribute MUST appear 994 in the Access-Request if the attribute is present in the Mobility 995 message replay protection. Otherwise the attribute MUST NOT appear 996 in the Access-Request packet. 998 TBD there is an issue here. In the diameter protocol, if there is a 999 time mismatch we return a result code that states that there was a 1000 time mistmatch and we return this value. In RADIUS land we return an 1001 Access-Reject but we cant really return any other attributes. 1003 6.12. MIP6-MN-HA-SPI 1005 Is available to be sent in an Access-Accept packet from the RADIUS 1006 server to he HA. It is part of a group of attributes used with the 1007 MIPv6 Authentication Protocol and contains the Security Parameter 1008 Index used to reference the MN-HA mobility security association. 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type | Length | SPI | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | SPI cont. | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 Type: 1019 ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA. 1021 Length: 1023 6 octets 1025 Integer representing a Security Parameter Index. 1027 6.13. MIP6-Algorithm-Type 1029 Is available to be sent in an Access-Accept packet from the RADIUS 1030 server to the HA. It is part of a group of attributes used with the 1031 MIPv6 Authentication protocol and contains the algorith type. 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Type | Length | enumeration | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | enumeration cont. | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Type: 1043 ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA. 1045 Length: 1047 6 octets 1049 Integer representing an enumeration as supported by [16]: 1051 2: HMAC-SHA-1 [8] 1053 6.14. MIP6-Replay-Mode 1055 Is available to be sent in an Access-Accept packet from the RADIUS 1056 server to the HA. It is part of a group of attribute used with the 1057 MIPv6 Authentication protocol and contains the replay mode as defined 1058 in RFC4004 to be used by the HA. 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Type | Length | enumeration | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | enumeration cont. | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Type: 1070 ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA. 1072 Length: 1074 6 octets 1076 Integer representing an enumeration as supported by [16]: 1078 1: None. 1080 2: Timestamps. 1082 3: Nonces. 1084 6.15. MIP6-Nonce 1086 Is available to be sent in an Access-Accpet packet from the RADIUS 1087 Server to the HA. It is part of a group of attributes used with the 1088 MIPv6 Authentication protocol and contains the nonce to send to the 1089 MN. 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Type | Length | nonce | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | .... 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Type: 1101 ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA. 1103 Length: 1105 Variable length 1107 String. A binary string repesenting a nonce. 1109 7. Message Flows 1111 7.1. Use of RADIUS in Integrated Scenario (MSA=ASA) 1113 This section is based on [2] and uses the previously defined RADIUS 1114 attributes. 1116 7.1.1. HA allocation in the MSP 1118 RADIUS is used to authenticate the MN, to authorize it for the 1119 mobility service and to send information about the assigned HA to the 1120 NAS. 1122 | 1123 --------------ASP------>|<--ASA+MSA-- 1124 | 1125 +----+ +------+ +-------+ +-------+ 1126 | | |RADIUS| | | | | 1127 | | |Client| | | | | 1128 | MN | |NAS/ | | DHCP | |Home | 1129 | | |DHCP | | Server| |RADIUS | 1130 | | |Relay | | | |Server | 1131 +----+ +------+ +-------+ +-------+ 1132 | | | | 1133 | 1 | 1 | | 1134 |<------------->|----------------------->| 1135 | | | | 1136 | | 2 | | 1137 | |<-----------------------| 1138 | | | | 1139 | 3 | | | 1140 |-------------->| | | 1141 | | | | 1142 | | 4 | | 1143 | |------------>| | 1144 | | | | 1145 | | 5 | | 1146 | |<------------| | 1147 | | | | 1148 | 6 | | | 1149 |<--------------| | | 1150 | | | | 1152 HA allocation in the MSP 1154 In step (1), the MN executes the normal network access authentication 1155 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 1156 acts as an authenticator in "pass-through" mode, i.e., the endpoint 1157 of the authentication dialogue is the MN's home RADIUS server. This 1158 is the typical scenario in case the messages involved in the 1159 authentication protocol are transported in EAP. 1161 As per [6], the NAS encapsulates/decapsulates EAP packets into/from 1162 RADIUS packets until an Access-Response (either an Access-Accept or 1163 an Access/Reject packet is received by the NAS). This concludes the 1164 network access authentication phase. 1166 If the NAS has the ability to support MIP6 Bootstrapping it includes 1167 the MIP6-Feature-Vector in the first Access-Request message and 1168 indicates whether it supports MIP6 bootstrapping and/or local home 1169 agent assignment by setting the appropriate flags therein. 1171 If the NAS indicates support for Local home agent assignment, then it 1172 may also include the MIP6-HA Attribute(s) and/or MIP6-HA-FQDN 1173 Attribute(s) as a proposal to the RADIUS server of the HA to assign 1174 in the ASP. 1176 In step (2), the RADIUS server sends an Access-Accept packet with the 1177 MIP6-Feature-Vector with the Local Home Agent Assignment flag set or 1178 cleared. If the flag is cleared then the RADIUS server needs to 1179 provide one or more Home Agent(s) to be assigned to the MN. If the 1180 flag is set, then it indicates to the NAS that it can assign HA to 1181 the MN; the RADIUS server may also include one or mroe HA addresses 1182 thus indicating that the NAS can either allocate a local HA or one 1183 specified by the RADIUS server. 1185 In step (3) the MN sends a DHCPv6 Information Request message to 1186 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 1187 for the Home Network Identifier Option shall be included in that 1188 message. The Home Network Identifier Option should have id-type of 1189 1, the message is a request to discover home network information that 1190 pertains to the given realm, i.e., the user's home domain (identified 1191 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 1192 identify itself to the DHCP server. 1194 In step (4) the DHCP relay agent forwards this request to the DHCP 1195 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 1196 message. This option carries the RADIUS MIP6-HA Attribute from the 1197 Access-Accept packet. If the NAS recieved the MIP6-HA-FQDN in the 1198 Access-Accept it peforms a DNS lookup to resolve the MIP6-HA address. 1200 In step (5), the DHCP server identifies the client (by DUID) and 1201 finds out that it requests HA information in the MSP (by the Home 1202 Network Identifier Option = 1). The DHCP server extracts the HA 1203 address from OPTION_MIP6-RELAY-Option and places it into Home Network 1204 Information Option in the Reply message. 1206 In step (6), the Relay Agent forwards the Reply Message to the MN. 1207 On reception of this message, the HA address or the FQDN of the HA is 1208 available at the MN. 1210 7.1.2. HA allocation in the ASP (visited network) 1212 This scenario is similar to the one described in Section 6.1.1. The 1213 difference is in step (4), where the type-id field in the Home 1214 Network Identifier Option is set to zero, indicating that a HA is 1215 requested in the ASP instead of in the MSP. Thus, the information 1216 received by the home RADIUS server, via the DHCP relay, in the 1217 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 1218 server allocates a HA from its list of possible HAs and returns it in 1219 the Reply message (Home Network Information Option). 1221 7.2. Use of RADIUS In Split Scenario (MSA!=ASA) 1223 7.2.1. Mobile Service Provider and Mobile Service Authorizer are the 1224 same entity. 1226 The assumption in this scenario is that the MN has the domain name of 1227 the MSP preconfigured. 1229 In this scenario there is no relationship between the network access 1230 authentication procedure and the MIPv6 bootstrapping procedure. 1232 In order to learn the IP address of the HA, the MN either performs a 1233 DNS lookup of the HA Name or a DNS lookup by service name. In the 1234 first case, the MN is preconfigured with the FQDN of the HA, and thus 1235 sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request 1236 for IPv6 address of HA). A DNS reply message is returned by the DNS 1237 server with the HA address. 1239 The MN then runs IKEv2 [17] with the HA in order to set up IPsec SAs 1240 (MN-HA). As part of this,the MN authenticates itself to the RADIUS 1241 server in the MSA domain, and obtains authorization for mobility 1242 service (including the Home Address). 1244 The MN shares credentials with the RADIUS server in the MSA domain. 1245 The RADIUS communication between the HA and the this RADIUS server is 1246 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 1247 within IKEv2 [17], the MN is authenticated and authorized for the 1248 IPv6 mobility service and is also assigned a HOA. 1250 The setup of SAs and mutual authentication between MN and AAAH using 1251 RADIUS (and EAP) is similar to the one described for Diameter 1252 protocol in [12]. The described mechanism ensureas that common 1253 keying material will be available at the MN and HA after successful 1254 completion. 1256 ----------------------------ASP--------->|<-----MSA/MSP 1258 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 1259 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 1260 +----+ +----+ +--------------------+ 1262 MN HA Remote RADIUS server 1263 -- -- -------------------- 1264 IKE_SA_INIT 1265 <------------------------------> 1267 HDR, SK{IDi,[CERTREQ,] [IDr,] 1268 SAi2, TSi, TSr} 1269 -------------------------------> 1270 RADIUS Access-Request(EAP-Response) 1271 ----------------------------------> 1272 RADIUS Access-Challenge(EAP-Request) 1273 <----------------------------------- 1274 HDR, SK {IDr, [CERT,] AUTH, 1275 EAP } 1276 <------------------------------- 1277 HDR, SK {EAP} 1278 --------------------------------> 1279 RADIUS Access-Request(EAP-Response) 1280 ----------------------------------> 1281 RADIUS Access-Challenge(EAP-Request) 1282 <----------------------------------- 1283 HDR, SK{EAP-Request} 1284 <------------------------------- 1285 HDR, SK{EAP-Response} 1286 --------------------------------> 1287 RADIUS Access-Request(EAP-Response) 1288 ----------------------------------> 1289 ... ... 1291 RADIUS Access-Accept(EAP-Success) 1292 <------------------------ 1294 HDR, SK{EAP-Success} 1295 <------------------------------- 1296 HDR, SK{AUTH} 1297 -------------------------------> 1298 HDR, SK {AUTH, SAr2, TSi, TSr } 1299 <------------------------------- 1301 Split Scenario Exchange 1303 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 1304 defined in the IKEv2 specification [17], negotiating crypto 1305 algorithms and running DH key exchange). IKEv2 supports integration 1306 with EAP. The MN indicates its desire to use EAP by not including 1307 the AUTH payload in the third message. However, it indicates its 1308 identity (NAI) by using the IDi field. If the HA supports EAP for 1309 authentication, as per [6] it forwards the identity to the Remote 1310 RADIUS server by sending a RADIUS Access-Request packet containing 1311 the identity in the EAP-Payload AVP and in the RADIUS User-Name 1312 attribute. Based on this identity, the Remote RADIUS server chooses 1313 authentication method and sends the first EAP-Request in the RADIUS 1314 Access-Challenge packet. During the EAP authentication phase, the HA 1315 relays EAP packets between the MN and the Remote RADIUS server. If 1316 the authentication succeeds and if the MN is authorized to use Mobile 1317 IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept 1318 packet containing the EAP-Success and the AAA-Key derived from the 1319 EAP authentication method. EAP authentication methods that do not 1320 derive keys are not recommended. This key is used by both MN and HA 1321 to generate the AUTH payload. In subsequent messages, MN and HA 1322 setup IPsec SAs for Mobile IPv6. 1324 7.2.2. Mobile Service Provider and Mobile Service Authorizer are 1325 different entities. 1327 The HA address discovery is performed as described in Section 6.2.1. 1329 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 1331 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 1332 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 1333 +----+ +----+ |RADIUS| |RADIUS| 1334 |Proxy | |Server| 1335 +------+ +------+ 1337 MSP#MSA Exchange 1339 The scenario is similar to previously described scenarios with the 1340 difference of utilizing AAA roaming agreements between the MSP and 1341 the MSA. 1343 8. Goals for the HA-AAA Interface 1345 Here, we follow the classification and labels listed in the MIPv6- 1346 AAA-Goals document [18]. 1348 8.1. General Goals 1350 G1.1-G1.4 Security 1352 These are standard requirements for a AAA protocol - mutual 1353 authentication, integrity, replay protection, confidentiality. IPsec 1354 can be used to achieve the goals. Goal G1.5 regarding inactive peer 1355 detection needs further investigations since heartbeat messages do 1356 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 1358 8.2. Service Authorization 1360 G2.1. The AAA-HA interface should allow the use of Network Access 1361 Identifier (NAI) to identify the MN. The User-Name attribute can be 1362 used for the purpose to carry the NAI. 1364 G2.2 The HA should be able to query the AAAH server to verify Mobile 1365 IPv6 service authorization for the MN. Any node implementing RADIUS 1366 functionality[9] can possibly initiate a request message. In 1367 combination with the ability of the RADIUS protocol to carry EAP 1368 messages [6] , our solution will enable an HA to query a RADIUS 1369 server and verify MIPv6 authorization for the MN. 1371 G2.3 The AAAH server should be able to enforce explicit operational 1372 limitations and authorization restrictions on the HA (e.g., packet 1373 filters, QoS parameters). Work in progress in the area, including 1374 NAS-Filter-Rule, RADIUS quality of service support, prepaid 1375 extensions etc. is performed. The relevant attributes may be reused 1376 for providing required functionality over the AAAH-HA interface. 1378 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 1379 session by the AAAH server, e.g., authorization lifetime, extension 1380 of the authorization lifetime and explicit session termination by the 1381 AAAH server side. 1383 The attribute Session-Timeout may be sent in Access-Challenge or 1384 Access-Accept packet by the RADIUS server, thus limiting the 1385 authorization session duration. In order to reauthenticate/ 1386 reauthorize the user, the Termination-Action attribute can be 1387 included, with value 1, meaning the NAS should send a new RADIUS- 1388 Request packet. Additional AVPs for dealing with pre-paid sessions 1389 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 1390 specified in RADIUS prepaid extension. Exchanging of application 1391 specific authorization request/answer messages provides extension of 1392 the authorization session (e.g., Authorize Only Access-Request sent 1393 by the HA (NAS) to the RADIUS server). Initiation of the re- 1394 authorization by both sides could be supported. Both sides could 1395 initiate session termination - the RADIUS server by sending 1396 Disconnect message [19]. 1398 8.3. Accounting 1400 G3.1 The AAA-HA interface must support the transfer of accounting 1401 records needed for service control and charging. These include (but 1402 may not be limited to): time of binding cache entry creation and 1403 deletion, octets sent and received by the MN in bi-directional 1404 tunneling, etc. 1406 The requirements for accounting over the AAAH-HA interface does not 1407 require enhancements to the existing accounting functionality. 1409 8.4. MN Authentication 1411 G4.1 The AAA-HA interface MUST support pass-through EAP 1412 authentication with the HA working as EAP authenticator operating in 1413 pass-through mode and the AAAH server working as back-end 1414 authentication server. 1416 These issues require the functionality of AAAH server working as a 1417 back-end authentication server and HA working as NAS and EAP 1418 authenticator in pass-through mode for providing a MN authentication. 1419 This document suggests this mode of operation in the context of the 1420 relevant scenarios. 1422 8.5. Provisioning of Configuration Parameters 1424 G5.1 The HA should be able to communicate to the AAAH server the HOA 1425 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 1426 update on behalf of the MN). 1428 This document describes needed AVPs for this purpose, see section 1429 "DNS Update Mobility Option Attribute" 1431 9. Table of Attributes 1433 The following tables provides a guide to which attributes may be 1434 found in RADIUS packet and in what number. 1436 The following defines the meaning of the notation used in the following 1437 tables: 1439 0 An instance of this attribute MUST NOT be present. 1440 1 Exactly one instance of this attribute MUST be present 1441 0-1 Zero or one instance of this attribute MAY be present. 1442 0+ Zero or more instance of this attriubte MAY be present 1444 The table below describes the RADIUS messages used for bootstrapping and are 1445 exchanged between the NAS and the RADIUS Server. 1447 Request Accept Reject Challenge Type Attribute 1448 1 1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1449 0+[ac] 0+[a] 0 0 MIP6-HA-TYPE MIP6-HA 1450 0+[ac] 0+[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN 1451 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix 1452 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1453 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO 1455 Notes: 1457 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 1459 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 1460 then these attributes MUST also be present in the Access-Request. 1461 If the RADIUS server accepts the NAS suggestion for the HA, then 1462 the RADIUS server MUST also include the values received for these 1463 attributes in the Access-Accept. 1465 [c] If these attributes are present in an Access-Request, then 1466 LOCAL_HOME_AGENT_ASSIGNMENT flag of the MIP6-Feature-Vector MUST be set. 1467 Otherwise these attributes are ignored. 1469 The following tables lists the commands and attributes used in the interaction 1470 between the HA and RADIUS server. Each table corresponds to the different 1471 authentication modes supported. These attributes are in addition to the any 1472 other attributes specified by an other specification (for example, RADIUS EAP) 1474 Table of attributes for IKEv2 and certificate or PSK-based Authentication: 1476 Request Accept Reject Challenge Type Attribute 1477 1 0 0 0 61 NAS-Port-Type 1478 0-1 0 0 0 80 Message-Authenticator 1479 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1480 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1481 0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1482 0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1483 0-1 0 0 0 MIP6-HA-TYPE MIP6-HA 1484 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1485 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1486 0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1487 0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1488 0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1489 0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1490 0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1492 Table of attributes for IKEv2 and EAP-based Authentication: 1494 Request Accept Reject Challenge Type Attribute 1495 1 0 0 0 61 NAS-Port-Type 1496 1 0 0 0 80 Message-Authenticator 1497 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1498 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1499 0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1500 0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1501 0-1 0 0 0 MIP6-HA-TYPE MIP6-HA 1502 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1503 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1504 0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1505 0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1506 0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1507 0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1508 0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1510 Table of attribute for MIPv6 Authentication Protocol: 1512 Request Accept Reject Challenge Type Attribute 1513 1 0 0 0 61 NAS-Port-Type 1514 0-1 0 0 0 80 Message-Authenticator 1515 0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector 1516 1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA 1517 1 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address 1518 0-1 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI 1519 1 0 0 0 MIP6-HA-TYPE MIP6-HA 1520 0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator 1521 0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data 1522 0-1 0 0-1[x] 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp 1523 0 1 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI 1524 0 1 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type 1525 0 1 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode 1526 0 1 0 0 MIP6-NONCE-TYPE MIP6-Nonce 1528 [x] THIS IS A PROBLEM. CANT HAVE ATTRIBS IN REJECT. 1530 As used in accounting packets: 1532 Request Interim Stop Type Attribute 1534 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 1535 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 1536 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 1537 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 1538 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 1540 10. Diameter Considerations 1542 When used in Diameter, the attributes defined in this specification 1543 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 1544 attribute compatibility space). No additional Diameter Code values 1545 are therefore allocated. The data types and flag rules for the 1546 attributes are as follows: 1548 +---------------------+ 1549 | AVP Flag rules | 1550 |----+-----+----+-----|----+ 1551 | | |SHLD| MUST| | 1552 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 1553 -------------------------------|----+-----+----+-----|----| 1554 MIP6-HA Address | M | P | | V | Y | 1555 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 1556 MIP6-HL-Prefix OctetString| M | P | | V | Y | 1557 MIP6-HOA Address | M | P | | V | Y | 1558 MIP6-DNS-MO OctetString| M | P | | V | Y | 1559 -------------------------------|----+-----+----+-----|----| 1561 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 1562 have no special translation requirements for Diameter to RADIUS or 1563 RADIUS to Diameter gateways; they are copied as is, except for 1564 changes relating to headers, alignment, and padding. See also [4] 1565 Section 4.1 and [20] Section 9. MIP6-HA and HOA-IPv6 must be 1566 translated between their RADIUS representation of String to a 1567 Diameter Address format which requires that the AddressType field be 1568 set to 2 for IP6 (IP version 6) 1570 What this specification says about the applicability of the 1571 attributes for RADIUS Access-Request packets applies in Diameter to 1572 AA-Request [20] or Diameter-EAP-Request [21]. What is said about 1573 Access-Challenge applies in Diameter to AA-Answer [20] or Diameter- 1574 EAP-Answer [21] with Result-Code AVP set to 1575 DIAMETER_MULTI_ROUND_AUTH. 1577 What is said about Access-Accept applies in Diameter to AA-Answer or 1578 Diameter-EAP-Answer messages that indicate success. Similarly, what 1579 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1580 Answer or Diameter-EAP-Answer messages that indicate failure. 1582 What is said about Accounting-Request applies to Diameter Accounting- 1583 Request [20] as well. 1585 11. Security Considerations 1587 Assignment of these values to a user should be based on successful 1588 authentication of the user at the NAS and/or at the HA. The RADIUS 1589 server should only assign these values to a user who is authorized 1590 for Mobile IPv6 service (this check could be performed with the 1591 user's subscription profile in the Home Network). 1593 The NAS and the HA to the RADIUS server transactions must be 1594 adequately secured. Otherwise there is a possibility that the user 1595 may receive fraudulent values from a rogue RADIUS server potentially 1596 hijacking the user's Mobile IPv6 session. 1598 These new attributes do not introduce additional security 1599 considerations besides the ones identified in [9]. 1601 12. IANA Considerations 1603 12.1. Registration of new AVPs 1605 This specification defines the following new RADIUS attributes: 1607 MIP6-Feature-Vector is set to MIP6-FV-TYPE 1609 MIP6-HA is set to MIP6-HA-TYPE 1611 MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE 1613 MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE 1615 MIP6-HOA is set to MIP6-HOsA-TYPE 1617 MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE 1619 12.2. New Registry: Mobility Capability 1621 For MIP6-FV-TYPE flag values must be generated: 1623 Token | Value | Description 1624 ----------------------------------+----------------------+------------ 1625 MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] 1626 LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] 1627 Available for Assignment via IANA | 2^x | 1629 Allocation rule: Only numeric values that are 2^x (power of two) are 1630 allowed based on the allocation policy described below. 1632 Following the policies outlined in [1] new values with a description 1633 of their semantic for usage with the MIP6-Feature-Vector AVP together 1634 with a Token will be assigned after Expert Review initiated by the 1635 O&M Area Directors in consultation with the DIME working group chairs 1636 or the working group chairs of a designated successor working group. 1637 Updates can be provided based on expert approval only. A designated 1638 expert will be appointed by the O&M Area Directors. No mechanism to 1639 mark entries as "deprecated" is envisioned. Based on expert approval 1640 it is possible to delete entries from the registry. 1642 12.3. Addition of existing values 1644 A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) 1646 13. Acknowledgements 1648 We would like to thank the following individuals for their review and 1649 constructive comments during the development of this document: 1651 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1652 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1654 14. References 1656 14.1. Normative References 1658 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1659 Levels", BCP 14, RFC 2119, March 1997. 1661 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1662 Integrated Scenario", 1663 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 1664 progress), July 2007. 1666 [3] Patel, A., "Authentication Protocol for Mobile IPv6", 1667 draft-patel-mip6-rfc4285bis-00 (work in progress), 1668 October 2006. 1670 [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1671 "Diameter Base Protocol", RFC 3588, September 2003. 1673 [5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1674 RFC 2548, March 1999. 1676 [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1677 In User Service) Support For Extensible Authentication Protocol 1678 (EAP)", RFC 3579, September 2003. 1680 [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1681 draft-ietf-mip6-bootstrapping-split-07 (work in progress), 1682 July 2007. 1684 [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1685 for Message Authentication", RFC 2104, February 1997. 1687 [9] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1688 Authentication Dial In User Service (RADIUS)", RFC 2865, 1689 June 2000. 1691 14.2. Informative References 1693 [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1694 IPv6", RFC 3775, June 2004. 1696 [11] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1697 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1699 [12] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", 1700 draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), 1701 October 2005. 1703 [13] Manner, J. and M. Kojo, "Mobility Related Terminology", 1704 RFC 3753, June 2004. 1706 [14] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1707 IKEv2 and the revised IPsec Architecture", 1708 draft-ietf-mip6-ikev2-ipsec-08 (work in progress), 1709 December 2006. 1711 [15] Mockapetris, P., "Domain names - implementation and 1712 specification", STD 13, RFC 1035, November 1987. 1714 [16] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1715 August 2002. 1717 [17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1718 RFC 4306, December 2005. 1720 [18] Giaretta, G., "AAA Goals for Mobile IPv6", 1721 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1722 September 2006. 1724 [19] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1725 "Dynamic Authorization Extensions to Remote Authentication Dial 1726 In User Service (RADIUS)", RFC 3576, July 2003. 1728 [20] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1729 Network Access Server Application", RFC 4005, August 2005. 1731 [21] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1732 Authentication Protocol (EAP) Application", RFC 4072, 1733 August 2005. 1735 [22] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1736 "DNS Security Introduction and Requirements", RFC 4033, 1737 March 2005. 1739 [23] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1740 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1741 Agents", RFC 3776, June 2004. 1743 [24] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1744 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1745 April 1997. 1747 Authors' Addresses 1749 Avi Lior 1750 Bridgewater Systems 1751 303 Terry Fox Drive, Suite 100 1752 Ottawa, Ontario 1753 Canada K2K 3J1 1755 Phone: +1 613-591-6655 1756 Email: avi@bridgewatersystems.com 1758 Kuntal Chowdhury 1759 Starent Networks 1760 30 International Place 1761 Tewksbury, MA 01876 1762 US 1764 Phone: +1 214-550-1416 1765 Email: kchowdhury@starentnetworks.com 1767 Hannes Tschofenig 1768 Siemens 1769 Otto-Hahn-Ring 6 1770 Munich, Bavaria 81739 1771 Germany 1773 Email: Hannes.Tschofenig@siemens.com 1775 Full Copyright Statement 1777 Copyright (C) The IETF Trust (2008). 1779 This document is subject to the rights, licenses and restrictions 1780 contained in BCP 78, and except as set forth therein, the authors 1781 retain all their rights. 1783 This document and the information contained herein are provided on an 1784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1786 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1787 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1788 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1791 Intellectual Property 1793 The IETF takes no position regarding the validity or scope of any 1794 Intellectual Property Rights or other rights that might be claimed to 1795 pertain to the implementation or use of the technology described in 1796 this document or the extent to which any license under such rights 1797 might or might not be available; nor does it represent that it has 1798 made any independent effort to identify any such rights. Information 1799 on the procedures with respect to rights in RFC documents can be 1800 found in BCP 78 and BCP 79. 1802 Copies of IPR disclosures made to the IETF Secretariat and any 1803 assurances of licenses to be made available, or the result of an 1804 attempt made to obtain a general license or permission for the use of 1805 such proprietary rights by implementers or users of this 1806 specification can be obtained from the IETF on-line IPR repository at 1807 http://www.ietf.org/ipr. 1809 The IETF invites any interested party to bring to its attention any 1810 copyrights, patents or patent applications, or other proprietary 1811 rights that may cover technology that may be required to implement 1812 this standard. Please address the information to the IETF at 1813 ietf-ipr@ietf.org. 1815 Acknowledgment 1817 Funding for the RFC Editor function is provided by the IETF 1818 Administrative Support Activity (IASA).