idnits 2.17.1 draft-ietf-dime-mip6-split-08.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1528. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 28, 2008) is 5810 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-rfc4285bis-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-rfc4285bis (ref. '3') ** Obsolete normative reference: RFC 3588 (ref. '5') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4306 (ref. '8') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4005 (ref. '9') (Obsoleted by RFC 7155) == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-09 == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-06 == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-03 == Outdated reference: A later version (-28) exists of draft-ietf-dime-app-design-guide-06 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: November 29, 2008 J. Bournelle 7 Orange Labs 8 G. Giaretta 9 Qualcomm 10 M. Nakhjiri 11 Motorola 12 May 28, 2008 14 Diameter Mobile IPv6: Support for Home Agent to Diameter Server 15 Interaction 16 draft-ietf-dime-mip6-split-08.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 29, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 Mobile IPv6 deployments may want to bootstrap their operations 50 dynamically based on an interaction between the Home Agent and the 51 Diameter server of the Mobile Service Provider (MSP). This document 52 specifies the interaction between a Mobile IP Home Agent and that 53 Diameter server. 55 Several different mechanisms for authenticating a Mobile Node are 56 supported. The usage of the Internet Key Exchange v2 (IKEv2) 57 protocol allows different mechanisms, such as the Extensible 58 Authentication Protocol (EAP), certificates and pre-shared secrets to 59 be used. Furthermore, another method makes use of the Mobile IPv6 60 Authentication Protocol. In addition to authentication and 61 authorization, the configuration of Mobile IPv6 specific parameters 62 and accounting is specified in this document. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Application Identifiers . . . . . . . . . . . . . . . . . . . 7 69 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Support for Mobile IPv6 with IKEv2 and EAP . . . . . . . . 7 71 4.2. Support for Mobile IPv6 with IKEv2 and Certificates . . . 11 72 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared 73 Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4. Support for the Mobile IPv6 Authentication Protocol . . . 11 75 4.5. Mobile IPv6 Session Management . . . . . . . . . . . . . . 12 76 4.5.1. Session-Termination-Request . . . . . . . . . . . . . 12 77 4.5.2. Session-Termination-Answer . . . . . . . . . . . . . . 13 78 4.5.3. Abort-Session-Request . . . . . . . . . . . . . . . . 13 79 4.5.4. Abort-Session-Answer . . . . . . . . . . . . . . . . . 13 80 4.6. Accounting for Mobile IPv6 services . . . . . . . . . . . 13 81 4.6.1. Accounting-Request . . . . . . . . . . . . . . . . . . 14 82 4.6.2. Accounting-Answer . . . . . . . . . . . . . . . . . . 14 83 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP . . . . . 14 85 5.1.1. Diameter-EAP-Request . . . . . . . . . . . . . . . . . 14 86 5.1.2. Diameter-EAP-Answer . . . . . . . . . . . . . . . . . 15 87 5.2. Command Code for Mobile IPv6 with IKEv2 and 88 Certificate- and PSK-based Authentication . . . . . . . . 16 89 5.2.1. AA-Request . . . . . . . . . . . . . . . . . . . . . . 16 90 5.2.2. AA-Answer . . . . . . . . . . . . . . . . . . . . . . 17 91 5.3. Command Codes for Mobile IPv6 Authentication Protocol 92 Support . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.3.1. MIP6-Request-Message . . . . . . . . . . . . . . . . . 18 94 5.3.2. MIP6-Answer-Message . . . . . . . . . . . . . . . . . 19 95 6. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 6.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 23 97 6.2. Called-Station-Id AVP . . . . . . . . . . . . . . . . . . 23 98 6.3. MIP-MN-AAA-SPI AVP . . . . . . . . . . . . . . . . . . . . 23 99 6.4. MIP-MN-HA-SPI AVP . . . . . . . . . . . . . . . . . . . . 23 100 6.5. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . . 23 101 6.6. MIP-Home-Agent-Address AVP . . . . . . . . . . . . . . . . 24 102 6.7. MIP-Careof-Address AVP . . . . . . . . . . . . . . . . . . 24 103 6.8. MIP-Authenticator AVP . . . . . . . . . . . . . . . . . . 24 104 6.9. MIP-MAC-Mobility-Data AVP . . . . . . . . . . . . . . . . 24 105 6.10. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . . 24 106 6.11. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . . . . . . 25 107 6.12. MIP-MN-HA-MSA AVP . . . . . . . . . . . . . . . . . . . . 25 108 6.13. MIP-Algorithm-Type AVP . . . . . . . . . . . . . . . . . . 25 109 6.14. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . . 25 110 6.15. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 25 111 6.16. MIP-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 26 112 6.17. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 27 113 6.18. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 27 114 6.19. Chargeable-User-Identity AVP . . . . . . . . . . . . . . . 27 115 6.20. Coupled Accounting Model Accounting AVPs . . . . . . . . . 27 116 7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 28 117 7.1. Success . . . . . . . . . . . . . . . . . . . . . . . . . 28 118 7.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 28 119 8. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 28 120 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table . . 29 121 8.2. Coupled Accounting Model AVP Table . . . . . . . . . . . . 29 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 123 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 30 124 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 30 125 9.3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 31 126 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 31 127 9.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 31 128 9.6. Mobile IPv6 Status Codes . . . . . . . . . . . . . . . . . 31 129 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 130 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 131 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 132 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 133 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 135 Intellectual Property and Copyright Statements . . . . . . . . . . 36 137 1. Introduction 139 Performing the Mobile IPv6 protocol [1], requires the Mobile Node 140 (MN) to own a Home Address (HoA) and to have an assigned Home Agent 141 (HA) to the MN. The MN needs to register with the HA in order to 142 enable its reachability and mobility, when away from its home link. 143 The registration process itself may require an establishment of IPSec 144 security associations (SA) and cryptographic material between the MN 145 and HA. Alternatively, the registration process may be secured using 146 a mobility message authentication option, which enables IPv6 mobility 147 in a MN without having to establish an IPSec SA with its HA. 148 Providing the collection of home address, HA address and keying 149 material is generally referred to as the Mobile IPv6 bootstrapping 150 problem [15]. The purpose of this specification is to provide 151 Diameter support for the interaction between the HA and the AAA 152 server. This specification satisfies the requirements defined in 153 [16] for the bootstrapping problem in the split scenario [2] and also 154 specifies Diameter support for the Authentication Protocol for Mobile 155 IPv6 [3]. The Diameter support defined in this specification also 156 applies to Dual Stack Mobile IPv6 [17]. 158 From a mobility service provider (MSP) perspective, it is important 159 to verify that the MN is authenticated and authorized to utilize 160 Mobile IPv6 service, and is accounted for those. Only when the MN is 161 authenticated and authorized, the MSP allows the bootstrapping of 162 Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6 163 registrations, the HA, participates in the authentication of the MN 164 to verify the MN's identity. The HA also participates in the Mobile 165 IPv6 authorization process involving the Diameter infrastructure. 166 The HA, due to its role in traffic forwarding, may also perform 167 accounting for the Mobile IPv6 service provided to the MN. 169 This document enables the following functionality: 171 Authentication: Asserting or helping with assertion of the 172 correctness of the MN identity. As a Diameter client supporting 173 the new Diameter Mobile IPv6 application, the HA may need to 174 support more than one authentication type depending on the 175 environment. Although the authentication is performed by the AAA 176 server there is an impact for the HA as different set of command 177 codes are needed for the respective authentication procedures. 179 Authorization: The HA must verify that the user is authorized to the 180 Mobile IPv6 service using the assistance of the MSP Diameter 181 servers. This is accomplished through the use of new Diameter 182 applications specifically designed for performing Mobile IPv6 183 authorization decisions. This document defines required AAA 184 procedures and requires the HA to support them and to participate 185 in this authorization signaling. 187 Accounting: For accounting purposes and capacity planning, it is 188 required of the HA to provide accounting report to the Diameter 189 infrastructure and thus to support the related Diameter accounting 190 procedures. 192 Session Management: The management of the mobility services may 193 require the AAA to abort or the HA to terminate the Mobile IPv6 194 service before the binding expires. This document defines 195 procedures for the AAA based session management. 197 Figure 1 depicts the reference architecture for this document. 199 +--------+ 200 |Diameter| 201 |Server | 202 +--------+ 203 ^ 204 Back-End | Diameter Mobile IPv6 205 Protocol | HA<->AAA Server 206 Support | Interaction 207 | (this document) 208 v 209 +---------+ +---------------+ 210 | Mobile | Front-End Protocol |Home Agent / | 211 | Node |<-------------------->|Diameter Client| 212 +---------+ IKEv2 or RFC 4285 +---------------+ 214 Figure 1: Architecture Overview 216 Mobile IPv6 signaling between the MN and the HA can be protected 217 using two different mechanisms, namely using IPSec or Authentication 218 Protocol for Mobile IPv6 [3]. For these two approaches several 219 different authentication and key exchange solutions are available. 220 When IPSec is used to protect Mobile IPv6 signaling messages, IKEv2 221 is used [4]. IKEv2 supports EAP-based authentication, certificates 222 and pre-shared secrets. Alternatively, Authentication Protocol for 223 Mobile IPv6 uses a mechanism that is very similar to the one used for 224 protecting Mobile IPv4 signaling messages. 226 The ability to use different credentials has an impact on the 227 interaction between the HA (acting as a Diameter client) and the 228 Diameter Server. For that reason this document illustrates the usage 229 of these authentication mechanisms with different subsections for: 231 o IKEv2 usage with EAP 232 o IKEv2 usage with certificates and pre-shared secrets 233 o Mobile IPv6 Authentication Protocol 235 For accounting of Mobile IPv6 services provided to the MN, this 236 specification uses the Diameter Base Protocol accounting defined in 237 RFC 3588 [5]. 239 2. Terminology 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 243 document are to be interpreted as described in RFC 2119 [6]. 245 The Mobile IPv6 bootstrapping terminology is taken from [15]. 247 3. Application Identifiers 249 This specification defines two new Diameter applications and their 250 respective Application Identifiers: 252 Diameter Mobile IPv6 IKE (MIP6I) TBD by IANA 253 Diameter Mobile IPv6 Auth (MIP6A) TBD by IANA 255 The MIP6I Application Identifier is used when the MN is authenticated 256 and authorized using IKEv2. The MIP6A Application Identifier is used 257 when the MN is authenticated and authorized using Mobile IPv6 258 Authentication Protocol. 260 Mobile IPv6 related accounting generated by the HA uses either MIP6I 261 or MIP6A Application Identifier in the case of coupled accounting 262 model. Diameter Base Accounting Application Identifier (value of 3) 263 is used in the case of split accounting model. Refer Section 4.6 for 264 more information regarding the accounting models. 266 4. Protocol Description 268 4.1. Support for Mobile IPv6 with IKEv2 and EAP 270 The use of IKEv2 with EAP between the MN and the HA allows the AAA to 271 authenticate the MN. When EAP is used with IKEv2, the Diameter EAP 272 application, as defined in [7], is re-used. EAP methods that do not 273 establish a shared key SHOULD NOT be used, as they are subject to a 274 number of man-in-the-middle attacks as stated in Section 2.16 and 275 Section 5 of RFC 4306 [8]. AVPs specific to Mobile IPv6 276 bootstrapping are added to the EAP application commands. 278 Figure 3 shows the message flow involved during the authentication 279 phase when EAP is used. 281 Mobile Home Diameter 282 Node Agent Server 283 | | | 284 | HDR, SAi1, KEi, Ni (1) | | 285 |-------------------------------->| | 286 | | | 287 | HDR, SAr1, KEr, Nr, [CERTREQ](2)| | 288 |<--------------------------------| | 289 | | | 290 | HDR, SK{IDi,[CERTREQ,] [IDr,] | | 291 | [CP(CFG_REQUEST),] | | 292 | SAi2, TSi, TSr} (3) | | 293 |-------------------------------->| DER (EAP-Response) (4) | 294 | |------------------------->| 295 | | | 296 | | DEA (EAP-Request) (5) | 297 | HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------| 298 |<------------------------------- | | 299 | | | 300 | HDR, SK{EAP} | | 301 |-------------------------------->| DER (EAP-Response) | 302 | |------------------------->| 303 | | | 304 | | DEA (EAP-Request) | 305 | HDR, SK{EAP-Request} |<-------------------------| 306 |<--------------------------------| | 307 | | | 308 | HDR, SK{EAP-Response} | | 309 |-------------------------------->| DER (EAP-Response) | 310 | |------------------------->| 311 | ... | ... | 312 | | | 313 | | DEA (EAP-Success) | 314 | |<-------------------------| 315 | HDR, SK{EAP-Success} | | 316 |<--------------------------------| | 317 | | | 318 | HDR, SK{AUTH} | | 319 |-------------------------------->| | 320 | | | 321 | HDR, SK{AUTH, [CP(CFG_REPLY,] | | 322 | SAr2, TSi, TSr} | | 323 |<--------------------------------| | 324 | | | 326 Figure 3: Mobile IPv6 bootstrapping using IKEv2 and EAP 328 The MN and the HA start the interaction with an IKE_SA_INIT exchange. 330 In this phase cryptographic algorithms are negotiated, nonces and 331 Diffie-Hellman parameters are exchanged. Message (3) starts the 332 IKE_AUTH phase. This second phase authenticates the previous 333 messages, exchanges identities and certificates and establishes the 334 first CHILD_SA. It is used to mutually authenticate the MN (acting 335 as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder). 336 The identity of the user/MN is provided in the IDi field. The MN 337 indicates its willingness to be authenticated via EAP by omitting the 338 AUTH field in message (3) (see Section 2.16 of [8]). 340 As part of the authentication process, the MN MAY request a Home- 341 Address, a Home Prefix or suggests one, see [4], using a CFG_REQUEST 342 payload in the message (3). 344 The HA extracts the IDi field from the message (3) and sends a 345 Diameter-EAP-Request (DER) message (4) towards the authenticating 346 Diameter server. The EAP-Payload AVP contains a EAP-Response/ 347 Identity with the identity extracted from the IDi field. 349 This message is routed to the MNs Diameter server/EAP server. The 350 Diameter server selects the EAP method and replies with the DEA 351 Message. Depending on the type of EAP method chosen, a number of DER 352 and DEA messages carry the method specific exchanges between the MN 353 and the Diameter server/EAP server. 355 At the end of the EAP authentication phase, the Diameter server 356 indicates the result of the authentication in the Result-Code AVP and 357 provides the corresponding EAP packet (EAP Success or EAP Failure). 358 The last IKEv2 message sent by the HA contains the Home Address or 359 the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is 360 necessary to setup IPSec SAs for Mobile IPv6 signaling. 362 In some deployment scenarios, the HA may also acts as a IKEv2 363 Responder for IPSec VPN access. A problem in this case is that the 364 IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service 365 or for IPSec VPN access service. A network operator needs to be 366 aware of this limitation. The MN may provide a hint of the intended 367 service, for example, by using different identities in the IKE_AUTH 368 message for the IPSec VPN service and Mobile IPv6 service. However, 369 the use of different identities during the IKEv2 negotiation is 370 deployment specific. Another possibility is to make the distinction 371 on the MN subscription basis. In this case the Diameter server can 372 inform the HA during the IKEv2 negotiation whether the MN is 373 provisioned with an IPSec VPN access service or Mobile IPv6 service. 375 Eventually, when the HA receives a Binding Update (BU), the HA 376 authenticates and authorizes the MN. It is RECOMMENDED that the HA 377 sends an accounting request message every time it receives a BU. 379 4.2. Support for Mobile IPv6 with IKEv2 and Certificates 381 When IKEv2 is used with certificate-based authentication, the 382 Diameter NASREQ application [9] is used to authorize the MN for the 383 Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 384 message MUST correspond to the identity in the MN's certificate. 385 This identity is then used by the HA to populate the User-Name AVP in 386 the succeeding AA-Request message. Further PKI-related procedures 387 such as certificate revocation checking are out of scope of this 388 document. 390 4.3. Support for Mobile IPv6 with IKEv2 and Pre-Shared Secrets 392 When IKEv2 is used with PSK-based initiator authentication, the 393 Diameter NASREQ application [9] is re-used to authorize the MN for 394 the Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH 395 message has to contain an identity that is meaningful for the 396 Diameter infrastructure, such as a Network Access Identifier (NAI), 397 and is then used by the HA to populate the User-Name AVP in the 398 succeeding AA-Request message. 400 4.4. Support for the Mobile IPv6 Authentication Protocol 402 Figure 4 shows the message sequence between the MN, the HA and the 403 Diameter server during the registration when Mobile IPv6 404 Authentication Protocol is used. A BU and a Binding Acknowledgement 405 (BA) messages are used in the binding registration process. 407 Receiving a BU at the HA initiates a MIP6-Request-Message to be sent 408 to the Diameter server. The Diameter server in turn responds with a 409 MIP6-Answer-Message. The HA may assign a Home Address to the MN and 410 provide it to the Diameter server in the MIP-Mobile-Node-Address AVP. 412 According to [3] the MN uses the Mobile Node Identifier Option, 413 specifically the MN-NAI mobility option (as defined in [18]) to 414 identify itself. The HA MUST copy the MN-NAI mobility option value 415 to the User-Name AVP in the subsequent request messages. 417 The procedure described in this specification for the Mobile IPv6 418 Authentication Protocol is only needed for the initial BU received by 419 the HA. When the HA receives subsequent BUs, they are processed 420 locally in the HA. It is RECOMMENDED that the HA sends an accounting 421 request message every time it receives a Binding Update. However, 422 the HA MAY re-authorize the MN with the Diameter server at any time 423 depending on the deployment and the local policy. 425 In some architectures and network deployments the MN-HA security 426 associations may be established as a result of a successful network 427 access authentication. In such deployments, both MN and Diameter 428 server share the keying material required for computation and 429 validation of the MN-HA Authentication Option, and a Security 430 Parameter Index (SPI) for indexing an appropriate security 431 association. Upon receiving a BU with a MN-HA Authentication Option, 432 the HA retrieves the keying material required for the computation and 433 validation of the MN-HA Authentication Option from the Diameter 434 server. The Diameter request message sent by the HA must contain 435 enough information (such as SPI, MN-NAI, etc) so that the Diameter 436 server is able to locate the matching MN-HA security association and 437 return correct keying material back to the HA. 439 Mobile Home Diameter 440 Node Agent Server 441 | | | 442 | | | 443 | Binding Update |MIP6-Request-Message | 444 |------------------------------------>|-------------------->| 445 | (Mobile Node Identifier Option, | | 446 | Mobility Message Replay Protection | | 447 | Option, Authentication Option) | | 448 | | | 449 | | | 450 | Binding Acknowledgement |MIP6-Answer-Message | 451 |<------------------------------------|<--------------------| 452 | (Mobile Node Identifier Option | | 453 | Mobility Message Replay Protection | | 454 | Option, Authentication Option) | | 456 Figure 4: Mobile IPv6 Bootstrapping using the Mobile IPv6 457 Authentication Protocol 459 4.5. Mobile IPv6 Session Management 461 The Diameter server may maintain state or may be stateless. This is 462 indicated in the Auth-Session-State AVP (or its absence). The HA 463 MUST support the Authorization Session State Machine defined in [5]. 464 Moreover, the following four commands may be exchanged between the HA 465 and the Diameter server. 467 4.5.1. Session-Termination-Request 469 The Session-Termination-Request (STR) message [5] is sent by the HA 470 to inform the Diameter server that an authorized session is being 471 terminated. 473 4.5.2. Session-Termination-Answer 475 The Session-Termination-Answer (STA) message [5] is sent by the 476 Diameter server to acknowledge the notification that the session has 477 been terminated. 479 4.5.3. Abort-Session-Request 481 The Abort-Session-Request (ASR) message [5] is sent by the Diameter 482 server to terminate the session. This fulfills one of the 483 requirement described in [16]. 485 4.5.4. Abort-Session-Answer 487 The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent 488 in response to an ASR message. 490 4.6. Accounting for Mobile IPv6 services 492 The HA MUST be able act as a Diameter client collecting accounting 493 records needed for service control and charging. The HA MUST support 494 the accounting procedures (specifically the command codes mentioned 495 below) and the Accounting Session State Machine as defined in [5]. 496 The command codes, exchanged between the HA and Diameter server for 497 accounting purposes, are provided in the following subsections. 499 The Diameter application design guideline [19] defines two separate 500 models for accounting: 502 Split accounting model: 504 According to this model, the accounting messages use the Diameter 505 Base Accounting Application Identifier (value of 3). Since 506 accounting is treated as an independent application, accounting 507 commands may be routed separately from the rest of application 508 messages and thus the accounting messages generally end up in a 509 central accounting server. Since Diameter Mobile IPv6 application 510 does not define its own unique accounting commands, this is the 511 preferred choice, since it permits use of centralized accounting 512 for several applications. 514 Coupled accounting model: 516 In this model, the accounting messages will use either the Mobile 517 IPv6 Split or the Mobile IPv6 Auth Application Identifiers. This 518 means that accounting messages will be routed like any other 519 Mobile IPv6 application messages. This requires the Diameter 520 server in charge of Mobile IPv6 application to handle the 521 accounting records (e.g., sends them to a proper accounting 522 server). 524 As mentioned above, the preferred choice is to use the split 525 accounting model and thus to choose Diameter Base Accounting 526 Application Identifier (value of 3) for accounting messages. 528 4.6.1. Accounting-Request 530 The Accounting-Request command [5] is sent by the HA to the Diameter 531 server to exchange accounting information regarding the MN with the 532 Diameter server. 534 4.6.2. Accounting-Answer 536 The Accounting-Answer command [5] is sent by the Diameter server to 537 the HA to acknowledge receiving an Accounting-Request. 539 5. Command Codes 541 5.1. Command Code for Mobile IPv6 with IKEv2 and EAP 543 For the use of Mobile IPv6 with IKEv2 and EAP this document re-uses 544 the Diameter EAP application [7] commands. The command ABNFs are 545 extended with a number AVPs to support Mobile IPv6 split scenario 546 bootstrapping. Other than new additional AVPs and the corresponding 547 additions to the command ABNFs, the Diameter EAP application command 548 ABNFs remain unchanged. 550 Command-Name Abbrev. Code Reference Application 551 --------------------------------------------------------------------- 552 Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE 553 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE 555 Figure 5: Command Codes 557 5.1.1. Diameter-EAP-Request 559 The Diameter-EAP-Request (DER) message [7], indicated by the Command- 560 Code field set to 268 and the 'R' bit set in the Command Flags field, 561 is sent by the HA to the Diameter server to initiate a Mobile IPv6 562 service authentication and authorization procedure. The DER message 563 format is the same as defined in [7]. The Application-ID field of 564 the Diameter Header MUST be set to the Diameter Mobile IPv6 IKE 565 Application ID (value of TDB). 567 ::= < Diameter Header: 268, REQ, PXY > 568 < Session-Id > 569 { Auth-Application-Id } 570 { Origin-Host } 571 { Origin-Realm } 572 { Destination-Realm } 573 { Auth-Request-Type } 574 [ Destination-Host ] 575 [ NAS-Identifier ] 576 [ NAS-IP-Address ] 577 [ NAS-IPv6-Address ] 578 [ NAS-Port-Type ] 579 [ User-Name ] 580 ... 581 [ Called-Station-Id] 582 ... 583 { EAP-Payload } 584 ... 585 [ MIP6-Feature-Vector ] 586 1*2{ MIP-Home-Agent-Address } 587 1*2{ MIP-Mobile-Node-Address } 588 [ Chargeable-User-Identity ] 590 [ QoS-Capability ] 591 * [ QoS-Resources ] 592 ... 593 * [ AVP ] 595 5.1.2. Diameter-EAP-Answer 597 The Diameter-EAP-Answer (DEA) message defined in [7], indicated by 598 the Command-Code field set to 268 and 'R' bit cleared in the Command 599 Flags field, is sent in response to the Diameter-EAP-Request message 600 (DER). The DEA message format is the same as defined in [7]. The 601 Application-Id field in the Diameter message header MUST be set to 602 the Diameter Mobile IPv6 IKE Application-Id (value of TBD). If the 603 Mobile IPv6 authentication procedure was successful then the response 604 MAY include any set of bootstrapping AVPs. 606 ::= < Diameter Header: 268, PXY > 607 < Session-Id > 608 { Auth-Application-Id } 609 { Auth-Request-Type } 610 { Result-Code } 611 { Origin-Host } 612 { Origin-Realm } 613 [ User-Name ] 614 [ EAP-Payload ] 615 [ EAP-Reissued-Payload ] 616 [ EAP-Master-Session-Key ] 617 [ EAP-Key-Name ] 618 [ Multi-Round-Time 619 ... 620 *2[ MIP-Mobile-Node-Address ] 621 [ MIP6-Feature-Vector ] 622 *2[ MIP-Home-Agent-Address ] 623 * [ QoS-Resources ] 624 [ Chargeable-User-Identity ] 625 ... 626 * [ AVP ] 628 5.2. Command Code for Mobile IPv6 with IKEv2 and Certificate- and PSK- 629 based Authentication 631 This document re-uses the Diameter NASREQ application commands. The 632 following commands are used to carry Mobile IPv6 related 633 bootstrapping AVPs. 635 Command-Name Abbrev. Code Reference Application 636 --------------------------------------------------------------------- 637 AA-Request AAR 265 RFC 4005 Diameter Mobile IPv6 IKE 638 AA-Answer AAA 265 RFC 4005 Diameter Mobile IPv6 IKE 640 Figure 8: Command Codes 642 5.2.1. AA-Request 644 The AA-Request (AAR) message [9], indicated by the Command-Code field 645 set to 265 and the 'R' bit set in the Command Flags field, is sent by 646 the HA to the Diameter server to initiate a Mobile IPv6 service 647 authentication and authorization procedure. The AAR message format 648 is the same as defined in [9]. The Application-ID field of the 649 Diameter Header MUST be set to the Diameter Mobile IPv6 IKE 650 Application ID (value of TBD). 652 ::= < Diameter Header: 265, REQ, PXY > 653 < Session-Id > 654 { Auth-Application-Id } 655 { Origin-Host } 656 { Origin-Realm } 657 { Destination-Realm } 658 { Auth-Request-Type } 659 [ Destination-Host ] 660 [ NAS-Identifier ] 661 [ NAS-IP-Address ] 662 [ NAS-IPv6-Address ] 663 [ NAS-Port-Type ] 664 [ User-Name ] 665 ... 666 [ Called-Station-Id] 667 ... 668 [ MIP6-Feature-Vector ] 669 1*2{ MIP-Home-Agent-Address } 670 1*2{ MIP-Mobile-Node-Address } 671 [ Chargeable-User-Identity ] 672 ... 673 [ QoS-Capability ] 674 * [ QoS-Resources ] 675 ... 676 * [ AVP ] 678 5.2.2. AA-Answer 680 The AA-Answer (AAA) message defined in [9], indicated by the Command- 681 Code field set to 265 and 'R' bit cleared in the Command Flags field, 682 is sent in response to the AA-Request message (AAR). If the Mobile 683 IPv6 authentication procedure was successful then the response MAY 684 include any set of bootstrapping AVPs. 686 The AAA message format is the same as defined in [9]. The 687 Application-Id field in the Diameter header MUST be set to the 688 Diameter Mobile IPv6 IKE Application-Id (value of TBD). 690 ::= < Diameter Header: 265, PXY > 691 < Session-Id > 692 { Auth-Application-Id } 693 { Auth-Request-Type } 694 { Result-Code } 695 { Origin-Host } 696 { Origin-Realm } 697 [ User-Name ] 698 [ Authorization-Lifetime ] 699 ... 701 *2[ MIP-Mobile-Node-Address ] 702 *2[ MIP-Home-Agent-Address ] 703 [ MIP6-Feature-Vector ] 704 [ MIP-MN-HA-MSA ] 705 * [ QoS-Resources ] 706 [ Chargeable-User-Identity ] 707 ... 708 * [ AVP ] 710 When IKEv2 is used with PSK-based initiator authentication, the pre- 711 shared secret is carried inside the MIP-MN-HA-MSA AVP. The pre- 712 shared secret SHOULD NOT be user's long term secret and it is 713 RECOMMENDED that a short-term keying material specifically created 714 for this purpose is used instead. 716 5.3. Command Codes for Mobile IPv6 Authentication Protocol Support 718 This section defines the commands that are used for support with the 719 Mobile IPv6 Authentication Protocol. 721 Command-Name Abbrev. Code Reference Application 722 --------------------------------------------------------------------- 723 MIP6-Request-Message MRM TBD 5.3.1 Diameter Mobile IPv6 Auth 724 MIP6-Answer-Message MAM TBD 5.3.2 Diameter Mobile IPv6 Auth 726 Command Codes 728 5.3.1. MIP6-Request-Message 730 The MIP6-Request-Message (MRM), indicated by the Command-Code field 731 set to TBD and the 'R' bit set in the Command Flags field, is sent by 732 the HA, acting as a Diameter client, in order to request the 733 authentication and authorization of a MN. 735 Although the HA provides the Diameter server with a replay protection 736 related information, the HA is responsible for the replay protection. 738 The message format is shown below. 740 ::= < Diameter Header: XXX, REQ, PXY > 741 < Session-ID > 742 { Auth-Application-Id } 743 { User-Name } 744 { Destination-Realm } 745 { Origin-Host } 746 { Origin-Realm } 747 [ Acct-Multi-Session-Id ] 748 [ Destination-Host ] 749 [ Origin-State-Id ] 750 [ NAS-Identifier ] 751 [ NAS-IP-Address ] 752 [ NAS-IPv6-Address ] 753 [ NAS-Port-Type ] 755 [ Called-Station-Id ] 756 [ MIP6-Feature-Vector ] 757 [ MIP-MN-AAA-SPI ] 758 [ MIP-MN-HA-SPI ] 759 { MIP-Mobile-Node-Address } 760 { MIP-Home-Agent-Address } 761 [ MIP-Careof-Address ] 762 [ MIP-Authenticator ] 763 [ MIP-MAC-Mobility-Data ] 764 [ MIP-Timestamp ] 765 [ QoS-Capability ] 766 * [ QoS-Resources ] 767 [ Chargeable-User-Identity ] 769 [ Authorization-Lifetime ] 770 [ Auth-Session-State ] 771 * [ Proxy-Info ] 772 * [ Route-Record ] 773 * [ AVP ] 775 5.3.2. MIP6-Answer-Message 777 The MIP6-Answer-Message (MAM) message, indicated by the Command-Code 778 field set to TBD and the 'R' bit cleared in the Command Flags field, 779 is sent by the Diameter server in response to the MIP6-Request- 780 Message message. The User-Name MAY be included in the MAM if it is 781 present in the MRM. The Result-Code AVP MAY contain one of the 782 values defined in Section 7, in addition to the values defined in RFC 783 3588 [5]. 785 An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 786 include the MIP-Mobile-Node-Address AVP. 788 The message format is shown below. 790 ::= < Diameter Header: XXX, PXY > 791 < Session-Id > 792 { Auth-Application-Id } 793 { Result-Code } 794 { Origin-Host } 795 { Origin-Realm } 796 [ Acct-Multi-Session-Id ] 797 [ User-Name ] 798 [ Authorization-Lifetime ] 799 [ Auth-Session-State ] 800 [ Error-Message ] 801 [ Error-Reporting-Host ] 802 [ Re-Auth-Request-Type ] 804 [ MIP6-Feature-Vector ] 805 [ MIP-Home-Agent-Address ] 806 [ MIP-Mobile-Node-Address ] 807 [ MIP-MN-HA-MSA ] 808 * [ QoS-Resources ] 809 [ Chargeable-User-Identity ] 811 [ Origin-State-Id ] 812 * [ Proxy-Info ] 813 * [ AVP ] 815 6. AVPs 817 To provide support for RFC 4285 [3] and for RFC 4877 [4] the AVPs in 818 the following subsections are needed. RFC 3588, RFC 4004 and RFC 819 4005 defined AVPs are reused whenever possible without changing the 820 existing semantics of those AVPs. 822 +--------------------------+ 823 | AVP Flag rules | 824 +----+-----+----+-----+----+ 825 AVP Defined | | |SHLD| MUST|MAY | 826 Attribute Name Code in Value Type |MUST| MAY | NOT| NOT|Encr| 827 +-----------------------------------------+----+-----+----+-----+----+ 828 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 829 | Vector | | | | | | 830 +-----------------------------------------+----+-----+----+-----+----+ 831 |MIP-Mobile- | M | P | | V | Y | 832 | Node-Address 334 RFC4004 Address | | | | | | 833 +-----------------------------------------+----+-----+----+-----+----+ 834 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 835 | Agent-Address | | | | | | 836 +-----------------------------------------+----+-----+----+-----+----+ 837 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 838 +-----------------------------------------+----+-----+----+-----+----+ 839 |Called- 30 RFC4005 UTF8String | M | P | | V | Y | 840 | Station-Id | | | | | | 841 +-----------------------------------------+----+-----+----+-----+----+ 842 |QoS-Capability TBD Note 2 Grouped | M | P | | V | Y | 843 +-----------------------------------------+----+-----+----+-----+----+ 844 |QoS-Resources TBD Note 2 Grouped | M | P | | V | Y | 845 +-----------------------------------------+----+-----+----+-----+----+ 846 |MIP-MN-HA-MSA TBD 6.12. Grouped | M | P | | V | Y | 847 +-----------------------------------------+----+-----+----+-----+----+ 848 |Chargeable-User- OctetString| | M,P | | V | Y | 849 | Identity 89 6.19 | | | | | | 850 +-----------------------------------------+----+-----+----+-----+----+ 852 AVPs for Mobile IPv6 IKE Application 854 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 856 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 857 Sections 4.1 and 4.3 of [11]. 859 +--------------------------+ 860 | AVP Flag rules | 861 +----+-----+----+-----+----+ 862 AVP Section | | |SHLD| MUST|MAY | 863 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 864 +-----------------------------------------+----+-----+----+-----+----+ 865 |MIP6-Feature- TBD Note 1 Unsigned64 | M | P | | V | Y | 866 | Vector | | | | | | 867 +-----------------------------------------+----+-----+----+-----+----+ 868 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 869 +-----------------------------------------+----+-----+----+-----+----+ 870 |MIP-MN-AAA-SPI 341 RFC4004 Unsigned32 | | M,P | | V | Y | 871 +-----------------------------------------+----+-----+----+-----+----+ 872 |MIP-MN-HA-SPI TBD 6.4 Unsigned32 | M | P | | V | Y | 873 +-----------------------------------------+----+-----+----+-----+----+ 874 |MIP-Mobile- 333 RFC4004 Address | M | P | | V | Y | 875 | Node-Address | | | | | | 876 +-----------------------------------------+----+-----+----+-----+----+ 877 |MIP-Home- 334 RFC4004 Address | M | P | | V | Y | 878 | Agent-Address | | | | | | 879 +-----------------------------------------+----+-----+----+-----+----+ 880 |MIP-Careof- TBD 6.7 Address | | M,P | | V | Y | 881 | Address | | | | | | 882 +-----------------------------------------+----+-----+----+-----+----+ 883 |MIP- TBD 6.8 OctetString| | M,P | | V | Y | 884 | Authenticator | | | | | | 885 +-----------------------------------------+----+-----+----+-----+----+ 886 |MIP-MAC- TBD 6.9 OctetString| | M,P | | V | Y | 887 | Mobility-Data | | | | | | 888 +-----------------------------------------+----+-----+----+-----+----+ 889 |MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y | 890 +-----------------------------------------+----+-----+----+-----+----+ 891 |MIP-MSA- 367 RFC4004 Unsigned32 | M | P | | V | Y | 892 | Lifetime | | | | | | 893 +-----------------------------------------+----+-----+----+-----+----+ 894 |MIP-MN-HA-MSA TBD 6.12 Grouped | M | P | | V | Y | 895 +-----------------------------------------+----+-----+----+-----+----+ 896 |MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y | 897 | Type | | | | | | 898 +-----------------------------------------+----+-----+----+-----+----+ 899 |MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y | 900 +-----------------------------------------+----+-----+----+-----+----+ 901 |MIP-Timestamp TBD 6.16 Time | | M,P | | V | Y | 902 +-----------------------------------------+----+-----+----+-----+----+ 903 |QoS-Capability TBD Note 2 Grouped | | M,P | | M | Y | 904 +-----------------------------------------+----+-----+----+-----+----+ 905 |QoS-Resources TBD Note 2 Grouped | | M,P | | V | Y | 906 +-----------------------------------------+----+-----+----+-----+----+ 907 |Chargeable-User- OctetString| | M,P | | V | Y | 908 | Identity 89 6.19 | | | | | | 909 +-----------------------------------------+----+-----+----+-----+----+ 911 AVPs for the Mobile IPv6 Auth Application 913 Note 1: The MIP6-Feature-Vector is defined in Section 4.7.4 of [10]. 915 Note 2: The QoS-Capability and QoS-Resource AVPs are defined in 916 Sections 4.1 and 4.3 of [11]. 918 6.1. User-Name AVP 920 The User-Name AVP (AVP Code 1) is of type UTF8String and contains an 921 NAI extracted from the MN-NAI mobility option included in the 922 received BU message. Alternatively, the NAI can be extracted from 923 the IKEv2 IDi payload included in the IKE_AUTH message sent by the 924 IKE initiator. 926 6.2. Called-Station-Id AVP 928 The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and 929 contains the string extracted from the IKEv2 IDr payload, if 930 available in the IKE_AUTH message sent by the IKE initiator. If the 931 Mobile IPv6 Authentication Protocol is used, then the 932 Called-Station-Id AVP contains the string extracted from the Service 933 Selection Mobility Option [20], if available in the received BU. 935 6.3. MIP-MN-AAA-SPI AVP 937 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 938 contains an SPI code extracted from the Mobility Message 939 Authentication Option included in the received BU message. 941 This AVP is re-used from [12]. 943 6.4. MIP-MN-HA-SPI AVP 945 The MIP-MN-HA-SPI AVP (AVP Code TBD) is of type Unsigned32 and 946 contains an SPI code which can be used with other parameters for 947 identifying the security association required for the validation of 948 the Mobile IPv6 MN-HA Authentication Option. 950 When included in the MRM message, the Diameter server needs to return 951 a valid MIP-MN-HA-MSA AVP in the corresponding MAM message. 953 6.5. MIP-Mobile-Node-Address AVP 955 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 956 contains the Home Agent assigned IPv6 or IPv4 Home Address of the 957 Mobile Node. 959 If the MIP-Mobile-Node-Address AVP contains unspecified IPv6 address 960 (0::0) or all zeroes IPv4 address (0.0.0.0) in a request message, 961 then the HA expects the Diameter server to assign the Home Address in 962 a subsequent answer message. If the Diameter server assigns only an 963 IPv6 Home Network Prefix to the Mobile Node the lower 64 bits of the 964 MIP-Mobile-Node-Address AVP provided address MUST be set to zero. 966 This AVP is re-used from [12]. 968 6.6. MIP-Home-Agent-Address AVP 970 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 971 contains the IPv6 or the IPv4 address of the HA. The HA address in a 972 request message is the same as in the received BU message that 973 triggered the authentication and authorization procedure towards the 974 Diameter server. 976 If the MIP-Home-Agent-Address AVP is present in an answer message and 977 the Result-Code AVP is set to DIAMETER_SUCCESS_RELOCATE_HA, then the 978 Diameter server is indicating to the HA that it MUST initiate a HA 979 switch procedure towards the MN (e.g., using the procedure defined in 980 [13]). If the Result-Code AVP is set to any other value, then the HA 981 SHOULD initiate the Home Agent switch procedure towards the MN. The 982 address of the assigned HA is defined in the MIP-Home-Agent-Address 983 AVP. 985 This AVP is re-used from [12]. 987 6.7. MIP-Careof-Address AVP 989 The MIP-Careof-Address AVP (AVP Code TBD) is of type Address and 990 contains the IPv6 Care-of Address of the Mobile Node. The HA 991 extracts this IP address from the received BU message. 993 6.8. MIP-Authenticator AVP 995 The MIP-Authenticator AVP (AVP Code TBD) is of type OctetString and 996 contains the Authenticator Data from the received BU message. The HA 997 extracts this data from the MN-AAA Mobility Message Authentication 998 Option included in the received BU message. 1000 6.9. MIP-MAC-Mobility-Data AVP 1002 The MIP-MAC-Mobility-Data AVP (AVP Code TBD) is of type OctetString 1003 and contains the calculated MAC_Mobility_Data, as defined in [3]. 1005 6.10. MIP-Session-Key AVP 1007 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1008 contains the MN-HA shared secret (i.e., the session key) for the 1009 associated Mobile IPv6 MH-HA authentication option. When the 1010 Diameter server computes the session key it is placed in this AVP. 1012 The MIP-Session-Key AVP may also be used to convey a pre-shared 1013 secret when IKEv2 is used with PSK-based initiator authentication. 1015 This AVP is re-used from [12]. 1017 6.11. MIP-MSA-Lifetime AVP 1019 The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1020 represents the period of time (in seconds) for which the session key 1021 (see Section 6.10) is valid. The associated session key MUST NOT be 1022 used if the lifetime has expired. 1024 This AVP is re-used from [12]. 1026 6.12. MIP-MN-HA-MSA AVP 1028 The MIP-MN-HA-MSA AVP (AVP Code TBD) is of type Grouped and contains 1029 the session related information for use with the Mobile IPv6 1030 Authentication Protocol. 1032 MIP-MN-HA-MSA ::= < AVP Header: TBD > 1033 { MIP-Session-Key } 1034 { MIP-MSA-Lifetime } 1035 [ MIP-MN-HA-SPI ] 1036 [ MIP-Algorithm-Type ] 1037 [ MIP-Replay-Mode ] 1038 * [ AVP ] 1040 6.13. MIP-Algorithm-Type AVP 1042 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and 1043 contains Algorithm identifier for the associated Mobile IPv6 MN-HA 1044 Authentication Option. The Diameter server selects the algorithm 1045 type. Existing algorithm types are defined in RFC 4004 that also 1046 fulfill current RFC 4285 requirements. 1048 This AVP is re-used from [12]. 1050 6.14. MIP-Replay-Mode AVP 1052 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1053 contains the replay mode the HA for authenticating the mobile node. 1054 The replay modes, defined in RFC 4004 [12], are supported. 1056 This AVP is re-used from [12]. 1058 6.15. MIP6-Feature-Vector AVP 1060 This AVP is defined in [10]. This document defines a new capability 1061 bit for signaling the support of Mobile IPv6 route optimization. The 1062 following capability is defined in this document: 1064 RO_SUPPORTED (0x0000000800000000) 1066 Route optimization is supported. When the HA sets this bit, it 1067 indicates support for the route optimization. If this bit is 1068 unset in the returned Mobility-Capability AVP, the AAAH does not 1069 authorize route optimization for the MN. 1071 In a case the HA or the AAAH cannot authorize the use of route 1072 optimization then the HA SHOULD send a Binding Acknowledgement 1073 with a Status Code set to ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION 1074 (status code TBD). This Status Code indicates that the binding 1075 registration succeeded but the HA will fail all possible 1076 subsequent route optimization attempts because of subscription or 1077 operator policy. 1079 USER_TRAFFIC_ENCRYPTION (0x0000000100000000) 1081 User plane traffic encryption is supported. When the HA sets this 1082 bit, it indicates support for the user plane traffic encryption 1083 between the MN and the HA. If this bit is unset in the returned 1084 Mobility-Capability AVP, the AAAH does not authorize user plane 1085 traffic encryption for the MN because of subscription or operator 1086 policy. 1088 In the case the AAAH cannot authorize the use of route 1089 optimization then the HA SHOULD send a Binding Acknowledgement 1090 with a Status Code set to ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION 1091 (status code TBD). This Status Code indicates that the binding 1092 registration succeeded but the HA will silently discard all 1093 encrypted user plane packets sent by the MN to the Home Agent. 1095 VPN_GW_MODE (0x0000000200000000) 1097 The HA is supposed to act as a IPSec VPN gateway for the user. 1098 When the Home Agent sets this bit, it indicates support for acting 1099 as a standalone IPSec VPN gateway. If this bit is unset in the 1100 returned Mobility-Capability AVP, the AAAH does not authorize the 1101 HA to act as a standalone IPSec VPN gateway for the MN because of 1102 subscription or operator policy. 1104 6.16. MIP-Timestamp AVP 1106 The MIP-Timestamp AVP (AVP Code TBD) is of type Time and may contain 1107 the timestamp value from the Mobility message replay protection 1108 option, defined in [3]. The HA extracts this value from the received 1109 BU message, if available. 1111 6.17. QoS-Capability AVP 1113 The QoS-Capability AVP is defined in [11] and contains a list of 1114 supported Quality of Service profiles. 1116 6.18. QoS-Resources AVP 1118 The QoS-Resources AVP is defined in [11] and provides QoS and packet 1119 filtering capabilities. 1121 6.19. Chargeable-User-Identity AVP 1123 The Chargeable-User-Identity AVP (AVP code 89) is of type OctetString 1124 and contains an unique temporary handle of the user. The Chargeable- 1125 User-Identity is defined in RFC 4372 [14]. 1127 6.20. Coupled Accounting Model Accounting AVPs 1129 Diameter Mobile IPv6 application is used in the case of the coupled 1130 account model. Diameter Mobile IPv4 application [12] accounting AVPs 1131 are reused in this document. The following AVPs MUST be included in 1132 the accounting request message: 1134 o Accounting-Input-Octets: Number of octets in IP packets received 1135 from the mobile node. 1136 o Accounting-Output-Octets: Number of octets in IP packets sent by 1137 the mobile node 1138 o Accounting-Input-Packets: Number of IP packets received from the 1139 mobile node. 1140 o Accounting-Output-Packets: Number of IP packets sent by the mobile 1141 node. 1142 o Acct-Multi-Session-Id: Used to link together multiple related 1143 accounting sessions, where each session would have a unique 1144 Session-Id, but the same Acct-Multi-Session-Id AVP. 1145 o Acct-Session-Time: Indicates the length of the current session in 1146 seconds. 1147 o MIP6-Feature-Vector: The supported features for this mobility 1148 service session. 1149 o MIP-Mobile-Node-Address: The Home Address of the mobile node. 1150 o MIP-Home-Agent-Address: The current home agent of the mobile node. 1151 o Chargeable-User-Identity: The unique temporary identity of the 1152 user. This AVP MUST be included if it is available in the home 1153 agent. 1155 Other APVs that SHOULD be included in the accounting request message 1156 include: 1158 o QoS-Resources: Assigned QoS resources for the mobile node. 1159 o QoS-Capability: The QoS capability related to the assigned QoS- 1160 Resources. 1161 o MIP-Careof-Address: The current Care-of Address of the mobile 1162 node. 1164 7. Result-Code AVP Values 1166 This section defines new Result-Code [5] values that MUST be 1167 supported by all Diameter implementations that conform to this 1168 specification. 1170 7.1. Success 1172 Errors that fall within the Success category are used to inform a 1173 peer that a request has been successfully completed. 1175 DIAMETER_SUCCESS_RELOCATE_HA (Status Code TBD) 1177 This result code is used by the Diameter server to inform the HA 1178 that the MN MUST be switched to another HA. 1180 7.2. Permanent Failures 1182 Errors that fall within the permanent failures category are used to 1183 inform the peer that the request failed and SHOULD NOT be attempted 1184 again. 1186 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION (Status Code TBD) 1188 This error is used by the Diameter server to inform the peer that 1189 the requested Mobile IPv6 session keys could not be delivered via 1190 a security association. 1192 8. AVP Occurrence Tables 1194 The following tables present the AVPs defined in this document and 1195 their occurrences in Diameter messages. Note that AVPs that can only 1196 be present within a Grouped AVP are not represented in this table. 1198 The table uses the following symbols: 1200 0: 1202 The AVP MUST NOT be present in the message. 1204 0+: 1206 Zero or more instances of the AVP MAY be present in the message. 1208 0-1: 1210 Zero or one instance of the AVP MAY be present in the message. 1212 1: 1214 One instance of the AVP MUST be present in the message. 1216 8.1. AAR, AAA, DER, DEA, MRM and MAM AVP/Command-Code Table 1218 +-----------------------------------+ 1219 | Command-Code | 1220 |-----+-----+-----+-----+-----+-----+ 1221 AVP Name | AAR | AAA | DER | DEA | MRM | MAM | 1222 -------------------------------|-----+-----|-----+-----+-----+-----+ 1223 MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1224 MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 | 1 | 0-1 | 1225 MIP-MN-AAA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1226 MIP-MN-HA-SPI | 0 | 0 | 0 | 0 | 0-1 | 0 | 1227 MIP-Home-Agent-Address | 1-2 | 0-2 | 1-2 | 0-2 | 1 | 0-1 | 1228 MIP-Careof-Address | 0 | 0 | 0 | 0 | 0-1 | 0 | 1229 MIP-Authenticator | 0 | 0 | 0 | 0 | 0-1 | 0 | 1230 MIP-MAC-Mobility-Data | 0 | 0 | 0 | 0 | 0-1 | 0 | 1231 MIP-MSA-Lifetime | 0 | 0 | 0 | 0 | 0 | 1 | 1232 MIP-MN-HA-MSA | 0 | 0-1 | 0 | 0 | 0 | 0-1 | 1233 MIP-Timestamp | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 1234 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 1 | 0-1 | 1235 Called-Station-Id | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1236 QoS-Resources | *0 | *0 | *0 | *0 | *0 | *0 | 1237 QoS-Capability | 0-1 | 0 | 0-1 | 0 | 0-1 | 0 | 1238 Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1239 +-----+-----+-----+-----+-----+-----+ 1241 8.2. Coupled Accounting Model AVP Table 1243 The table in this section is used to represent which AVPs defined in 1244 this document are to be present in the Accounting messages, as 1245 defined in [5]. 1247 +-------------+ 1248 | Command-Code| 1249 |------+------+ 1250 Attribute Name | ACR | ACA | 1251 -------------------------------------|------+------+ 1252 Accounting-Input-Octets | 1 | 0-1 | 1253 Accounting-Input-Packets | 1 | 0-1 | 1254 Accounting-Output-Octets | 1 | 0-1 | 1255 Accounting-Output-Packets | 1 | 0-1 | 1256 Acct-Multi-Session-Id | 1 | 0-1 | 1257 Acct-Session-Time | 1 | 0-1 | 1258 MIP6-Feature-Vector | 1 | 0-1 | 1259 MIP-Home-Agent-Address | 1 | 0-1 | 1260 MIP-Mobile-Node-Address | 1 | 0-1 | 1261 Event-Timestamp | 0-1 | 0 | 1262 MIP-Careof-Address | 0-1 | 0 | 1263 QoS-Capability | *0 | *0 | 1264 QoS-Resources | *0 | *0 | 1265 Chargeable-User-Identity | 0-1 | 0 | 1266 -------------------------------------|------+------+ 1268 9. IANA Considerations 1270 This section contains the namespaces that have either been created in 1271 this specification or had their values assigned to existing 1272 namespaces managed by IANA. 1274 9.1. Command Codes 1276 IANA is requested to allocate a command code value for the MIP6- 1277 Request-Message (MRM) and for the MIP6-Answer-Message (MAM) from the 1278 Command Code namespace defined in [5]. See Section 5 for the 1279 assignment of the namespace in this specification. 1281 9.2. AVP Codes 1283 This specification requires IANA to register the following new AVPs 1284 from the AVP Code namespace defined in [5]. 1286 o MIP-Careof-Address 1287 o MIP-Authenticator 1288 o MIP-MAC-Mobility-Data 1289 o MIP-Timestamp 1290 o MIP-MN-HA-SPI 1291 o MIP-MN-HA-MSA 1293 The AVPs are defined in Section 6. 1295 9.3. Result-Code AVP Values 1297 This specification requests IANA to allocate new values to the 1298 Result-Code AVP (AVP Code 268) namespace defined in [5]. See 1299 Section 7 for the assignment of the namespace in this specification. 1301 Result-Code | Value 1302 ----------------------------------------------+------ 1303 DIAMETER_SUCCESS_RELOCATE_HA | TBD 1304 DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION | TBD 1306 9.4. Application Identifier 1308 This specification requires IANA to allocate two new values "Diameter 1309 Mobile IPv6 IKE" and "Diameter Mobile IPv6 Auth" from the Application 1310 Identifier namespace defined in [5]. 1312 Application Identifier | Value 1313 -----------------------------------+------ 1314 Diameter Mobile IPv6 IKE (MIP6I) | TBD 1315 Diameter Mobile IPv6 Auth (MIP6A) | TBD 1317 9.5. Namespaces 1319 This specification defines a new value to the Mobility Capability 1320 registry (see [10]) for use with the MIP6-Feature-Vector AVP: 1322 Token | Value | Description 1323 ---------------------------------+----------------------+------------ 1324 RO_SUPPORTED | 0x0000000800000000 | RFC TBD 1325 USER_TRAFFIC_ENCRYPTION | 0x0000000100000000 | RFC TBD 1326 VPN_GW_MODE | 0x0000000200000000 | RFC TBD 1328 9.6. Mobile IPv6 Status Codes 1330 This specification defines a new Mobile IPv6 [1] Status Code value. 1331 The Status Code must be allocated from the range 0-127: 1333 Status Code | Value | Description 1334 ----------------------------------------+---------------+------------ 1335 ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD 1336 ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION | is set to TBD | RFC TBD 1338 10. Security Considerations 1340 The security considerations for the Diameter interaction required to 1341 accomplish the split scenario are described in in [2]. Additionally, 1342 the security considerations of the Diameter Base protocol [5], 1343 Diameter EAP application [7] are applicable to this document. This 1344 document does not introduce new security vulnerabilities. 1346 11. Acknowledgements 1348 The authors would like to thank Jari Arkko, Tolga Asversen, Pasi 1349 Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John 1350 Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay 1351 Devarapalli, Lionel Morand, Domagoj Premec, Semyon Mizikovsky and 1352 Yoshihiro Ohba for all the useful discussions. Ahmad Muhanna 1353 provided a detailed review of the document in August 2007. 1355 We would also like to thank our Area Director, Dan Romascanu, for his 1356 support. 1358 Hannes Tschofenig would like to thank the European Commission support 1359 in the co-funding of the ENABLE project, where this work is partly 1360 being developed. 1362 Julien Bournelle would like to thank GET/INT since he began this work 1363 while he was under their employ. 1365 Madjid Nakhjiri would like to thank Huawei USA as most of his 1366 contributions to this draft were possible while he was under their 1367 employ. 1369 12. References 1371 12.1. Normative References 1373 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1374 IPv6", RFC 3775, June 2004. 1376 [2] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1377 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1379 [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1380 "Authentication Protocol for Mobile IPv6", 1381 draft-ietf-mip6-rfc4285bis-02 (work in progress), 1382 December 2007. 1384 [4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1385 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1386 April 2007. 1388 [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1389 "Diameter Base Protocol", RFC 3588, September 2003. 1391 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1392 Levels", BCP 14, RFC 2119, March 1997. 1394 [7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1395 Authentication Protocol (EAP) Application", RFC 4072, 1396 August 2005. 1398 [8] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1399 RFC 4306, December 2005. 1401 [9] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1402 Network Access Server Application", RFC 4005, August 2005. 1404 [10] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 1405 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 1406 Server to Diameter Server Interaction", 1407 draft-ietf-dime-mip6-integrated-09 (work in progress), 1408 May 2008. 1410 [11] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and 1411 A. Lior, "Quality of Service Attributes for Diameter", 1412 draft-ietf-dime-qos-attributes-06 (work in progress), May 2008. 1414 [12] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 1415 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 1416 August 2005. 1418 [13] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility 1419 Header Home Agent Switch Message", RFC 5142, January 2008. 1421 [14] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 1422 "Chargeable User Identity", RFC 4372, January 2006. 1424 12.2. Informative References 1426 [15] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1427 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1429 [16] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. 1430 Lopez, "AAA Goals for Mobile IPv6", 1431 draft-ietf-mext-aaa-ha-goals-01 (work in progress), May 2008. 1433 [17] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1434 Routers", draft-ietf-mext-nemo-v4traversal-03 (work in 1435 progress), May 2008. 1437 [18] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, 1438 "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1439 RFC 4283, November 2005. 1441 [19] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. 1442 Loughney, "Diameter Applications Design Guidelines", 1443 draft-ietf-dime-app-design-guide-06 (work in progress), 1444 January 2008. 1446 [20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 1447 Selection for Mobile IPv6", RFC 5149, February 2008. 1449 Authors' Addresses 1451 Jouni Korhonen 1452 TeliaSonera 1453 P.O.Box 970 1454 Sonera FIN-00051 1455 Finland 1457 Email: jouni.korhonen@teliasonera.com 1459 Hannes Tschofenig 1460 Nokia Siemens Networks 1461 Linnoitustie 6 1462 Espoo 02600 1463 Finland 1465 Phone: +358 (50) 4871445 1466 Email: Hannes.Tschofenig@gmx.net 1467 URI: http://www.tschofenig.priv.at 1469 Julien Bournelle 1470 Orange Labs 1471 38-4O rue du general Leclerc 1472 Issy-Les-Moulineaux 92794 1473 France 1475 Email: julien.bournelle@orange-ftgroup.com 1476 Gerardo Giaretta 1477 Qualcomm 1478 5775 MoreHouse Dr 1479 San Diego, CA 92121 1480 USA 1482 Email: gerardo.giaretta@gmail.com 1484 Madjid Nakhjiri 1485 Motorola 1486 USA 1488 Email: madjid.nakhjiri@motorola.com 1490 Full Copyright Statement 1492 Copyright (C) The IETF Trust (2008). 1494 This document is subject to the rights, licenses and restrictions 1495 contained in BCP 78, and except as set forth therein, the authors 1496 retain all their rights. 1498 This document and the information contained herein are provided on an 1499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1506 Intellectual Property 1508 The IETF takes no position regarding the validity or scope of any 1509 Intellectual Property Rights or other rights that might be claimed to 1510 pertain to the implementation or use of the technology described in 1511 this document or the extent to which any license under such rights 1512 might or might not be available; nor does it represent that it has 1513 made any independent effort to identify any such rights. Information 1514 on the procedures with respect to rights in RFC documents can be 1515 found in BCP 78 and BCP 79. 1517 Copies of IPR disclosures made to the IETF Secretariat and any 1518 assurances of licenses to be made available, or the result of an 1519 attempt made to obtain a general license or permission for the use of 1520 such proprietary rights by implementers or users of this 1521 specification can be obtained from the IETF on-line IPR repository at 1522 http://www.ietf.org/ipr. 1524 The IETF invites any interested party to bring to its attention any 1525 copyrights, patents or patent applications, or other proprietary 1526 rights that may cover technology that may be required to implement 1527 this standard. Please address the information to the IETF at 1528 ietf-ipr@ietf.org. 1530 Acknowledgment 1532 Funding for the RFC Editor function is provided by the IETF 1533 Administrative Support Activity (IASA).