idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 18, 2004) is 7129 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: 'CERTREQ' on line 486 -- Looks like a reference, but probably isn't: 'N' on line 463 -- Looks like a reference, but probably isn't: 'KEi' on line 463 -- Looks like a reference, but probably isn't: 'KEr' on line 466 == Unused Reference: '6' is defined on line 569, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 580, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 585, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 592, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-03 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-09 -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '7') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '8') (Obsoleted by RFC 4306) == Outdated reference: A later version (-01) exists of draft-yegin-mip6-aaa-fwk-00 == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-01 -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '13') (Obsoleted by RFC 2822) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group V. Devarapalli 2 Internet-Draft Nokia 3 Expires: April 18, 2005 October 18, 2004 5 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 6 draft-ietf-mip6-ikev2-ipsec-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This document describes Mobile IPv6 operation with the revised IPsec 42 architecture and IKEv2. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. What is applicavble from RFC 3776? . . . . . . . . . . . . . . 5 49 3.1 Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5 50 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.2.1 Home Agent Requirements . . . . . . . . . . . . . . . 5 52 3.2.2 Mobile Node Requirements . . . . . . . . . . . . . . . 6 53 4. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 7 54 4.1 Binding Update and Acknowledgements . . . . . . . . . . . 7 55 4.2 Return Routabililty Messages . . . . . . . . . . . . . . . 8 56 4.3 Mobile Prefix Discovery Messages . . . . . . . . . . . . . 8 57 4.4 Payload Packets . . . . . . . . . . . . . . . . . . . . . 9 58 5. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 10 59 5.1 Security Policy Database Entries . . . . . . . . . . . . . 10 60 5.1.1 Binding Updates and Acknowledgements . . . . . . . . . 10 61 5.1.2 Return Routability Messages . . . . . . . . . . . . . 11 62 5.1.3 Mobile Prefix Discovery Messages . . . . . . . . . . . 11 63 5.1.4 Payload Packets . . . . . . . . . . . . . . . . . . . 12 64 5.2 Security Association negotiation using IKEv2 . . . . . . . 12 65 6. The use of EAP authentication . . . . . . . . . . . . . . . . 14 66 7. Dynamic Home Address Configuration . . . . . . . . . . . . . . 15 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 72 11.2 Informative References . . . . . . . . . . . . . . . . . . . 19 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 74 Intellectual Property and Copyright Statements . . . . . . . . 21 76 1. Introduction 78 RFC 3776 describes how IPsec [7] is used with Mobile IPv6 [2] to 79 protect the signaling messages. It also illustrates the Security 80 Policy Database and Security Association Database entries required to 81 protect Mobile IPv6 signaling messages. 83 The IPsec architecture has been revised [5]. Among the many changes, 84 the list of selectors has been expanded to included the Mobility 85 Header message type. This has an impact on how security policies and 86 security associations are configured for protecting mobility header 87 messages. It becomes easier to differentiate between the various 88 Mobility Header messages based on the type value instead of checking 89 if a particular mobility header message is being sent on a tunnel 90 interface between the MN and the HA, as it was in RFC 3776. The 91 revised IPsec architecture specification also includes ICMP message 92 type and code as selectors. This makes it possible to protect Mobile 93 Prefix Discovery messages without applying the same security 94 associations to all ICMPv6 messages. 96 This document discusses new requirements for the Home Agent and the 97 Mobile Node to use the revised IPsec architecture and IKEv2. Section 98 3.2 lists the requirements. Section 3 describes the differences with 99 RFC 3776. Section 4 describes the required Security Policy Database 100 (SPD) and Security Association Database (SAD) entries. 102 The Internet Key Exchange (IKE) has also been substantially revised 103 and simplified [4]. This document describes how IKEv2 can be used to 104 setup security associations for Mobile IPv6. 106 The use of EAP within IKEv2 is allowed to authenticate the Mobile 107 Node to the Home Agent. This is described in Section 6. A method 108 for dynamically configuring a Home Address from the Home Agent using 109 the Configuration Payload in IKEv2 is described in Section 7. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [1]. 117 3. What is applicavble from RFC 3776? 119 3.1 Packet Formats 121 The Mobile Node and the Home Agent MUST support the packet formats as 122 defined in Seciton 3 of RFC 3776. 124 3.2 Requirements 126 The Mobile Node and the Home Agent MUST support the requirements 127 listed in Section 4 of RFC 3776 with the following exceptions. 129 o It is not required to configure security policies per interface in 130 order to protect return routability signaling messages. Since the 131 Mobility Header message type is a selector, it is easy to 132 differentiate HoTi and HoT messages from other Mobility Header 133 messages. 135 o It is necessary to avoid a condition where a mobile ndoe could use 136 its security association to send a Binding Update on behalf of 137 another Mobile Node. With manual IPsec configuration, the Home 138 Agent MUST be able to verify that a security association was 139 created for a particular Home Address. With dynamic keying, it 140 should be possible for the Home Agent to verify that the identity 141 presented in the IKE_AUTH exchange is allowed to create security 142 associations for a particular home address. 144 o The Mobile Node should use its Care-of Address as source address 145 in protocol exchanges, when using dynamic keying. However, the 146 security associations MUST be created for the Home Address of the 147 Mobile Node. 149 o The Mobile Node and the Home Agent MUST create security 150 associations based on the Home Address, so that the security 151 associations survive change in Care-of Address. When using IKEv2 152 as the key exchange protocol, the TSi payload during the 153 CREATE_CHILD_SA exchange [4] MUST carry the Home Address of the 154 Mobile Node. 156 3.2.1 Home Agent Requirements 158 This section describes some new and additional requirements on the 159 Home Agent. 161 o The Home Agent MUST support Mobility Header message type as an 162 IPsec selector. 164 o The Home Agent MUST support ICMPv6 message type as an IPsec 165 selector. 167 o The Home Agent MUST be able to distinguish between HoTi messages 168 sent to itself, when it is acting as a Correspondent Node) from 169 those sent to Correspondent Nodes when it is acting as a Home 170 Agent, based on the destination address of the packet. 172 o The Home Agent MUST have an entry for each Mobile Node in its Peer 173 Authorization Database (PAD), [5]. The PAD entry for a Mobile 174 Node contains either a shared key or a trust anchor to verify the 175 Mobile Node's certificate. 177 o The Home Agent MUST support remote configuration of Home Address 178 as descrined in Section 7. When the Home Agent receives a 179 configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDR, it 180 must reply with a valid Home Address for the Mobile Node. The 181 Home Agent could pick a Home Address from a local database or from 182 a DHCPv6 server on the home link. 184 o The Home Agent MAY support authentication using EAP in IKEv2 as 185 described in Section 2.16 of [4]. 187 3.2.2 Mobile Node Requirements 189 This section describes new additional requirements on the Mobile 190 Node. 192 o The Mobile Node MUST support Mobility Header message type as an 193 IPsec selector. 195 o The Mobile Node MUST supprt ICMPv6 message type as an IPsec 196 selector. 198 o The Mobile Node MAY support EAP as an authentication mechanism 199 when using IKEv2 to setup security associations for protecting 200 Mobile IPv6 signaling messages. 202 o The Mobile Node MAY support the mechanism described in Section 7 203 to dynamically configure a Home Address. 205 4. Manual Configuration 207 This section describes the SPD and SAD entries necessary to protect 208 the Mobile IPv6 signaling messages. The format used to describe the 209 SPD and SAD entries is the same as described in RFC 3776. 211 For the examples described in this document, a Mobile Node with home 212 address, "home_address_1", a Home Agent with addres, "home_agent_1" 213 and a user of the Mobile Node with identity "user_1" are assumed. 215 4.1 Binding Update and Acknowledgements 217 mobile node SPD-S: 218 - IF source = home_address_1 & destination = home_agent_1 & 219 proto = MH & mh_type = BU 220 THEN USE SA SA1 222 mobile node SPD-I: 223 - IF source = home_agent_1 & destination = home_address_1 & 224 proto = MH & mh_type = BAck 225 THEN USE SA SA2 227 mobile node SAD: 228 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 229 source = home_address_1 & destination = home_agent_1 & 230 proto = MH & mh_type = BU 231 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 232 source = home_agent_1 & destination = home_address_1 & 233 proto = MH & mh_type = BAck 235 home agent SPD-S: 236 - IF source = home_agent_1 & destination = home_address_1 & 237 proto = MH & mh_type = BAck 238 THEN USE SA SA2 240 home agent SPD-I: 241 - IF source = home_address_1 & destination = home_agent_1 & 242 proto = MH & mh_type = BU 243 THEN USE SA SA1 245 home agent SAD: 246 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 247 source = home_agent_1 & destination = home_address_1 & 248 proto = MH & mh_type = BAck 249 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 250 source = home_address_1 & destination = home_agent_1 & 251 proto = MH & mh_type = BU 253 4.2 Return Routabililty Messages 255 mobile node SPD-S: 256 - IF source = home_address_1 & destination = any & 257 proto = MH & mh_type = HoTi 258 THEN USE SA SA3 260 mobile node SPD-I: 261 - IF destination = home_address_1 & source = any & 262 proto = MH & mh_type = HoT 263 THEN USE SA SA4 265 mobile node SAD: 266 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 267 source = home_address_1 & destination = any & proto = MH & 268 mh_type = HoTi 269 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 270 source = any & destination = home_address_1 & proto = MH & 271 mh_type = HoT 273 home agent SPD-S: 274 - IF destination = home_address_1 & source = any & 275 proto = MH & mh_type = HoT 276 THEN USE SA SA4 278 home agent SPD-I: 279 - IF source = home_address_1 & destination = any & 280 proto = MH & mh_type = HoTi 281 THEN USE SA SA3 283 home agent SAD: 284 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 285 source = any & destination = home_address_1 & proto = MH & 286 mh_type = HoT 287 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 288 source = home_address_1 & destination = any & proto = MH & 289 mh_type = HoTi 291 4.3 Mobile Prefix Discovery Messages 292 mobile node SPD-S: 293 - IF source = home_address_1 & destination = home_agent_1 & 294 proto = ICMPv6 & icmp6_type = MPS 295 THEN USE SA SA5. 297 mobile node SPD-I: 298 - IF source = home_agent_1 & destination = home_address_1 & 299 proto = ICMPv6 & icmp6_type = MPA 300 THEN USE SA SA6 302 mobile node SAD: 303 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 304 source = home_address_1 & destination = home_agent_1 & 305 proto = ICMPv6 & icmp6_type = MPS 306 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 307 source = home_agent_1 & destination = home_address_1 & 308 proto = ICMPv6 & icmp6_type = MPA 310 home agent SPD-S: 311 - IF source = home_agent_1 & destination = home_address_1 & 312 proto = ICMPv6 & icmp6_type = MPA 313 THEN USE SA SA6 315 home agent SPD-I: 316 - IF source = home_address_1 & destination = home_agent_1 & 317 proto = ICMPv6 & icmp6_type = MPS 318 THEN USE SA SA5 320 home agent SAD: 321 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 322 source = home_agent_1 & destination = home_address_1 & 323 proto = ICMPv6 & icmp6_type = MPA 324 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 325 source = home_address_1 & destination = home_agent_1 & 326 proto = ICMPv6 & icmp6_type = MPS 328 4.4 Payload Packets 330 Payload traffic tunneled through the Home Agent can be protected by 331 IPsec, if required. The Mobile Node and the Home Agent use ESP in 332 tunnel mode to protect the tunneled traffic. The SPD and SAD entries 333 shown in Section 5.2.4 of [3] are applicable here. 335 5. Dynamic Configuration 337 This section describes the use of IKEv2 to setup the required 338 security associatiosn. 340 5.1 Security Policy Database Entries 342 5.1.1 Binding Updates and Acknowledgements 344 mobile node SPD-S: 345 - IF destination = home_agent_1 & proto = MH & mh_type = BU 346 THEN USE SA ESP TRANSPORT: local identity = user_1 348 mobile node SPD-I: 349 - IF source = home_agent_1 & proto = MH & mh_type = BAck 350 THEN USE SA ESP TRANSPORT: local identity = user_1 352 home agent SPD-S: 353 - IF source = home_agent_1 & proto = MH & mh_type = BAck 354 THEN USE SA ESP TRANSPORT: peer identity = user_1 356 home agent SPD-I: 357 - IF destination = home_agent_1 & proto = MH & mh_type = BU 358 THEN USE SA ESP TRANSPORT: peer identity = user_1 360 5.1.2 Return Routability Messages 362 mobile node SPD-S: 363 - IF proto = MH & mh_type = HoTi 364 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 365 local identity = user_1 & 366 inner source address =home_address_1 368 mobile node SPD-I: 369 - IF source = any & destination = home_address_1 & 370 proto = MH & mh_type = HoT 371 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 372 local identity = user_1 374 home agent SPD-S: 375 - IF source = any & destination = home_address_1 & 376 proto = MH & mh_type = HoT 377 THEN USE SA ESP TUNNEL: inner destination = home_address_1 378 & peer identity = user_1 380 home agent SPD-I: 381 - IF source = home_address_1 & destination = any & 382 proto = MH & mh_type = HoTi 383 THEN USE SA ESP TUNNEL: inner destination = home_address_1 384 & peer identity = user_1 386 5.1.3 Mobile Prefix Discovery Messages 388 mobile node SPD-S: 389 - IF destination = home_agent_1 & proto = ICMPv6 & 390 icmp6_type = MPS 391 THEN USE SA ESP TRANSPORT: local identity = user_1 393 mobile node SPD-I: 394 - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA 395 THEN USE SA ESP TRANSPORT: local identity = user_1 397 home agent SPD-S: 398 - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA 399 THEN USE SA ESP TRANSPORT: peer identity = user_1 401 home agent SPD-I: 402 - IF destination = home_agent_1 & proto = ICMPv6 & 403 icmp6_type = MPS 404 THEN USE SA ESP TRANSPORT: peer identity = user_1 406 5.1.4 Payload Packets 408 The SPD and SAD entries shown in Section 5.3.4 of [3] are applicable 409 here. This document does not update the SPD and SAD entries 410 described in RFC3776 for protecting payload packets. 412 5.2 Security Association negotiation using IKEv2 414 Mobile IPv6 signaling messages are always first initiated by the 415 Mobile Node. The Mobile Node sends a Binding Update to the Home 416 Agent whenever it moves and acquires a new Care-of Address. 418 The Mobile Node initiates an IKEv2 protocol exchange if the required 419 security associations are not present. For authenticating the Home 420 Agent, public key based mechanisms MUST be used. The Mobile Node 421 includes a Certificate Request payload in the first message sent in 422 the IKE_AUTH exchange. If the Mobile Node is using a shared key for 423 authentication, it uses the shared key to generate the AUTH payload 424 in the IKE_AUTH exchange. If the Mobile Node is using a public key 425 based mechanism, then it uses its private key to generate the AUTH 426 payload in the IKE_AUTH exchange. The Mobile Node MUST always 427 includes its identity in the IDi payload in the IKE_AUTH exchange. 428 The Mobile Node could use a FQDN or RFC 822 [13] identifier as 429 identities. In case the Mobile Node uses FQDN, it sets the IDi type 430 to ID_FQDN. In case, the Mobile Nodes uses a RFC 822 kind of 431 identifier, it sets the IDi type to ID_RFC822_ADDR. 433 Mobile Node Home Agent 434 ----------- ---------- 435 HDR, SAi1, KEi, Ni --> 437 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 439 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 440 AUTH, SAi2, TSi, TSr} 441 --> 443 <-- HDR, SK {IDr, [CERT,] AUTH, 444 SAr2, TSi, TSr} 446 After the IKE_AUTH exchange completes, the Mobile Node and the Home 447 Agent initiate CREATE_CHILD_SA exchanges to negotiate security 448 associations for protecting Binding Update/Binding Ack messages, 449 Return Routability signaling, Mobile Prefix Discovery messages and 450 optionally payload traffic. The CREATE_CHILD_SA exchanges are 451 protected by the security association created during the IKE_AUTH 452 exchange. 454 It is important that the security associations are created based on 455 the Home Address of the Mobile Node, so that the security 456 associations survive Care-of Address change. The Mobile Node MUST 457 set the TSi (Traffic Selector-initiator) payload to its Home Address 458 in the CREATE_CHILD_SA exchange in order to create the security 459 associations for the Home Address. 461 Mobile Node Home Agent 462 ----------- ---------- 463 HDR, SK {[N], SA, Ni, [KEi], 464 [TSi, TSr]} --> 466 <-- HDR, SK {SA, Nr, [KEr], 467 [TSi, TSr]} 469 6. The use of EAP authentication 471 In addition to using public key signatures and shared secrets, EAP 472 [14] can be used with IKEv2 for authenticating the Mobile Node to the 473 Home Agent. 475 The Mobile Node indicates that it wants to use EAP by including the 476 IDi payload but leaving out the AUTH payload in the first message 477 during the IKE_AUTH exchange. The Home Agent includes an EAP payload 478 if it is willing to use an extensible authentication method. 479 Security associations are not created until the subsequent IKE_AUTH 480 exchange after successful EAP authentication. 482 Mobile Node Home Agent 483 ------------ ---------- 484 HDR, SAi1, KEi, Ni --> 486 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 488 HDR, SK {IDi, [CERTREQ,] [IDr,] 489 SAi2, TSi, TSr}--> 491 <-- HDR, SK {IDr, [CERT,] AUTH, 492 EAP } 494 HDR, SK {EAP} --> 496 <-- HDR, SK {EAP (success)} 498 HDR, SK {AUTH} --> 500 <-- HDR, SK {AUTH, SAr2, TSi, 501 TSr} 503 7. Dynamic Home Address Configuration 505 The Mobile Node can dynamically configure a Home Address by including 506 a Configuration Payload with a request for an address from the home 507 link. The Mobile Node MUST include an INTERNAL_IP6_ADDRESS and 508 INTERNAL_IP6_SUBNET attributes in the Configuration Payload. The 509 Mobile Node MAY also include an INTERNAL_IP6_DNS attribute. 511 When the Home Agent receives a configuration payload with a 512 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid Home 513 Address for the Mobile Node. The Home Agent could use a local 514 database or contact a DHCPv6 server on the home link to allocate a 515 Home Address. The Home Agent MUST also include an 516 INTERNAL_ADDRESS_EXPIRY attribute to indicate to the Mobile Node, the 517 duration for which the dynamically allocated Home Address is valid. 519 In case the Home Agent is unable to allocate a Home Address for the 520 Mobile Node during the IKE_AUTH exhcange, it MUST send a Notify 521 Payload with an INTERNAL_ADDRESS_FAILURE message. 523 Mobile Node Home Agent 524 ----------- ---------- 525 HDR, SK {IDi, [CERT,] [CERTREQ,] 526 [IDr,] AUTH, CP(CFG_REQUEST), 527 SAi2, TSi, TSr} 528 --> 530 <-- HDR, SK {IDr, [CERT,] AUTH, 531 CP(CFG_REPLY), SAr2, 532 TSi, TSr} 534 8. Security Considerations 536 This document describes how IPsec can be used to secure Mobile IPv6 537 signaling messages. Please refer to RFC 3775 and RFC 3776 for 538 security considerations related to the use of IPsec with Mobile IPv6. 540 9. IANA Considerations 542 This document requires no action from IANA. 544 10. Acknowledgements 546 TBD 548 11. References 550 11.1 Normative References 552 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 553 Levels", BCP 14, RFC 2119, March 1997. 555 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 556 IPv6", RFC 3775, June 2004. 558 [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 559 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 560 Agents", RFC 3776, June 2004. 562 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 563 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 565 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 566 Protocol", draft-ietf-ipsec-rfc2401bis-03 (work in progress), 567 September 2004. 569 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", 570 draft-ietf-ipsec-esp-v3-09 (work in progress), October 2004. 572 11.2 Informative References 574 [7] Kent, S. and R. Atkinson, "Security Architecture for the 575 Internet Protocol", RFC 2401, November 1998. 577 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 578 RFC 2409, November 1998. 580 [9] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J. and M. 581 Laurent-Maknavicius, "MIPv6 Authorization and Configuration 582 based on EAP", draft-giaretta-mip6-authorization-eap (work in 583 progress), October 2004. 585 [10] Giaretta, G., "Goals for AAA-HA interface", 586 draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), 587 September 2004. 589 [11] Yegin, A., "AAA Mobile IPv6 Application Framework", 590 draft-yegin-mip6-aaa-fwk-00 (work in progress), September 2004. 592 [12] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 593 draft-ietf-mip6-bootstrap-ps-01 (work in progress), October 594 2004. 596 [13] Crocker, D., "Standard for the format of ARPA Internet text 597 messages", STD 11, RFC 822, August 1982. 599 [14] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 600 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 601 3748, June 2004. 603 Author's Address 605 Vijay Devarapalli 606 Nokia Research Center 607 313 Fairchild Drive 608 Mountain View, CA 94043 609 USA 611 EMail: vijay.devarapalli@nokia.com 613 Intellectual Property Statement 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org. 637 Disclaimer of Validity 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Copyright Statement 649 Copyright (C) The Internet Society (2004). This document is subject 650 to the rights, licenses and restrictions contained in BCP 78, and 651 except as set forth therein, the authors retain all their rights. 653 Acknowledgment 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society.