idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1035. ** 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. 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 23, 2005) is 6757 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 809 -- Looks like a reference, but probably isn't: 'N' on line 748 -- Looks like a reference, but probably isn't: 'KEi' on line 748 -- Looks like a reference, but probably isn't: 'KEr' on line 751 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-03 == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-05 -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '10') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-01 == Outdated reference: A later version (-04) exists of draft-sugimoto-mip6-pfkey-migrate-01 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Nokia 4 Expires: April 26, 2006 F. Dupont 5 Point6 6 October 23, 2005 8 Mobile IPv6 Operation with IKEv2 and the revised IPsec 9 draft-ietf-mip6-ikev2-ipsec-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes Mobile IPv6 operation with the revised IPsec 43 architecture and IKEv2. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 4 52 4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5 53 4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 6 54 4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 8 55 5. Selector Granularity Considerations . . . . . . . . . . . . . 8 56 6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 9 57 6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 9 58 6.2. Return Routabililty Messages . . . . . . . . . . . . . . . 10 59 6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 11 60 6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 12 61 7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 12 62 7.1. Security Policy Database Entries . . . . . . . . . . . . . 12 63 7.1.1. Binding Updates and Acknowledgements . . . . . . . . . 13 64 7.1.2. Return Routability Messages . . . . . . . . . . . . . 14 65 7.1.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 14 66 7.1.4. Payload Packets . . . . . . . . . . . . . . . . . . . 15 67 7.2. Security Association negotiation using IKEv2 . . . . . . . 16 68 7.3. Movements and Dynamic Keying . . . . . . . . . . . . . . . 18 69 8. The use of EAP authentication . . . . . . . . . . . . . . . . 19 70 9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 20 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 78 Intellectual Property and Copyright Statements . . . . . . . . . . 25 80 1. Introduction 82 RFC 3776 describes how IPsec [12] is used with Mobile IPv6 [2] to 83 protect the signaling messages. It also illustrates examples of 84 Security Policy Database and Security Association Database entries 85 that can be used to protect Mobile IPv6 signaling messages. 87 The IPsec architecture has been revised [5]. Among the many changes, 88 the list of selectors has been expanded to included the Mobility 89 Header message type. This has an impact on how security policies and 90 security associations are configured for protecting mobility header 91 messages. It becomes easier to differentiate between the various 92 Mobility Header messages based on the type value instead of checking 93 if a particular mobility header message is being sent on a tunnel 94 interface between the mobile node and the home agent, as it was in 95 RFC 3776. The revised IPsec architecture specification also includes 96 ICMP message type and code as selectors. This makes it possible to 97 protect Mobile Prefix Discovery messages without applying the same 98 security associations to all ICMPv6 messages. 100 This document discusses new requirements for the home agent and the 101 mobile node to use the revised IPsec architecture and IKEv2. 102 Section 4 lists the requirements. Section 6 and Section 7 describe 103 the required Security Policy Database (SPD) and Security Association 104 Database (SAD) entries. 106 The Internet Key Exchange (IKE) has also been substantially revised 107 and simplified [4]. Section 7.2 of this document describes how IKEv2 108 can be used to setup security associations for Mobile IPv6. 110 The use of EAP within IKEv2 is allowed to authenticate the mobile 111 node to the home agent. This is described in Section 8. A method 112 for dynamically configuring a home address from the home agent using 113 the Configuration Payload in IKEv2 is described in Section 9. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [1]. 121 3. Packet Formats 123 The mobile node and the home agent MUST support the packet formats as 124 defined in Section 3 of RFC 3776. This document does not update the 125 packet formats described in RFC 3776. 127 4. Requirements 129 This section describes mandatory rules and requirements for all 130 Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as 131 the key negotiation protocol, can be used to protect traffic between 132 the mobile node and the home agent. Many of the requirements are 133 repeated from RFC 3776 to make this document self-contained and 134 complete. 136 4.1. General Requirements 138 o RFC 3775 states that manual configuration of IPsec security 139 associations MUST be supported and automated key management MAY be 140 supported. This document does not make any recommendations 141 regarding the support of manual IPsec configuration and dynamic 142 IPsec configuration. This document just describes the use of 143 manually created IPsec security associations and the use of IKEv2 144 as the automated IPsec key management protocol for protecting 145 Mobile IPv6 signaling messages. 147 o ESP encapsulation for Binding Updates and Binding Acknowledgements 148 MUST be supported and used. 150 o ESP encapsulation in tunnel mode for the Home Test Init and Home 151 Test messages tunneled between the mobile node and the home agent 152 MUST be supported and SHOULD be used. 154 o ESP encapsulation of the ICMPv6 messages related to mobile prefix 155 discovery MUST be supported and SHOULD be used. 157 o ESP encapsulation of the payload packets tunneled between the 158 mobile node and the home agent MAY be supported and used. 160 o If multicast group membership control protocols or stateful 161 address autoconfiguration protocols are supported, payload data 162 protection MUST be supported for those protocols. 164 o The home agent and the mobile node MAY support authentication 165 using EAP in IKEv2 as described in Section 8. 167 o The home agent and the mobile node MAY support remote 168 configuration of home address as described in Section 9. When the 169 home agent receives a configuration payload with a CFG_REQUEST for 170 INTERNAL_IP6_ADDR, it must reply with a valid home address for the 171 mobile node. The home agent can pick a home address from a local 172 database or from a DHCPv6 server on the home link. 174 4.2. Policy Requirements 176 The following requirements are related to the configuration of 177 security policy database on the home agent and the mobile node. 179 o RFC 3776 required configuration of the security policies per 180 interface in order to be able to differentiate between mobility 181 header messages sent to the home agent and tunneled through the 182 home agent to the correspondent node. Since the Mobility Header 183 message type is a selector, it is now easy to differentiate 184 between HoTi and HoT messages from other mobility header messages. 185 Therefore per-interface configuration of security policies is not 186 required. 188 o The home agent MUST be able to prevent a mobile node from using 189 its security association to send a Binding Update on behalf of 190 another mobile node. With manual IPsec configuration, the home 191 agent MUST be able to verify that a security association was 192 created for a particular home address. With dynamic keying, it 193 should be possible for the home agent to verify that the identity 194 presented in the IKE_AUTH exchange is allowed to create security 195 associations for a particular home address. 197 o The home agent MAY use the Peer Authorization Database (PAD) [5] 198 to store per-mobile node state. The PAD entry for a mobile node 199 can contain a shared key, public key or a trust anchor to verify 200 the mobile node's certificate for authenticating the mobile node. 202 o As required in the base specification [7], when a packet destined 203 to the receiving node is matched against IPsec security policy or 204 selectors of a security association, an address appearing in a 205 Home Address destination option is considered as the source 206 address of the packet. 208 Note that the home address option appears before IPsec headers. 209 Section 11.3.2 of the base specification describes one possible 210 implementation approach for this: The IPsec policy operations can 211 be performed at the time when the packet has not yet been modified 212 per Mobile IPv6 rules, or has been brought back to its normal form 213 after Mobile IPv6 processing. That is, the processing of the Home 214 Address option is seen as a fixed transformation of the packets 215 that does not affect IPsec processing. 217 o Similarly, a home address within a Type 2 Routing header destined 218 to the receiving node is considered as the destination address of 219 the packet, when a packet is matched against IPsec security policy 220 or selectors of a security association. 222 Similar implementation considerations apply to the Routing header 223 processing as was described above for the Home Address destination 224 option. 226 o When the mobile node returns home and de-registers with the Home 227 Agent, the tunnel between the home agent and the mobile node's 228 care-of address is torn down. The security policy entries, which 229 were used for protecting tunneled traffic between the mobile node 230 and the home agent MUST be made inactive (for instance, by 231 removing them and installing them back later through an API). The 232 corresponding security associations could be kept as they are or 233 deleted depending on how they were created. If the security 234 associations were created dynamically using IKE, they are 235 automatically deleted when they expire. If the security 236 associations were created through manual configuration, they MUST 237 be retained and used later when the mobile node moves away from 238 home again. The security associations protecting Binding Updates 239 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 240 as they do not depend on care-of addresses and can be used again. 242 o The mobile node MUST use the Home Address destination option in 243 Binding Updates and Mobile Prefix Solicitations, sent to the home 244 agent from a care-of address, so that the home address is visible 245 when the IPsec policy checks are made. 247 o The home agent MUST use the Type 2 Routing header in Binding 248 Acknowledgements and Mobile Prefix Advertisements sent to the 249 mobile node, again due to the need to have the home address 250 visible when the policy checks are made. 252 4.3. IPsec Protocol Processing Requirements 254 The following lists requirements for IPsec processing at the Home 255 Agent and the mobile node. 257 o The home agent and mobile node SHOULD support Mobility Header 258 message type as an IPsec selector. 260 o The home agent and mobile node SHOULD support ICMPv6 message type 261 as an IPsec selector. 263 o The home agent MUST be able to distinguish between HoTi messages 264 sent to itself, when it is acting as a Correspondent Node, from 265 those sent to Correspondent Nodes when it is acting as a home 266 agent, based on the destination address of the packet. 268 o When securing Binding Updates, Binding Acknowledgements, and 269 prefix discovery, both the mobile nodes and the home agents MUST 270 support and SHOULD use the Encapsulating Security Payload (ESP) 271 [6] header in transport mode and MUST use a non-null payload 272 authentication algorithm to provide data origin authentication, 273 connectionless integrity and optional anti-replay protection. 275 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 276 protection of packets belonging to the return routability 277 procedure. A non-null encryption transform and a non-null 278 authentication algorithm MUST be applied. 280 o When ESP is used to protect Binding Updates, there is no 281 protection for the care-of address that appears in the IPv6 header 282 outside the area protected by ESP. It is important for the home 283 agent to verify that the care-of address has not been tampered 284 with. As a result, the attacker would have redirected the mobile 285 node's traffic to another address. In order to prevent this, 286 Mobile IPv6 implementations MUST use the Alternate Care-of Address 287 mobility option in Binding Updates sent by mobile nodes while away 288 from home. The exception to this is when the mobile node returns 289 home and sends a Binding Update to the home agent in order to de- 290 register. 292 When IPsec is used to protect return routability signaling or 293 payload packets, the mobile node MUST set the source address it 294 uses for the outgoing tunnel packets to the current primary care- 295 of address. 297 o When IPsec is used to protect return routability signaling or 298 payload packets, IPsec security associations are needed to provide 299 this protection. When the care-of address for the mobile node 300 changes as a result of an accepted Binding Update, special 301 treatment is needed for the next packets sent using these security 302 associations. The home agent MUST set the new care-of address as 303 the destination address of these packets, as if the outer header 304 destination address in the security association had changed. 305 Similarly, the home agent starts to expect the new source address 306 in the tunnel packets received from the mobile node. 308 Such address changes can be implemented, for instance, through an 309 API from the Mobile IPv6 implementation to the IPsec 310 implementation. One such API is described in [14]. It should be 311 noted that the use of such an API and the address changes MUST 312 only be done based on the Binding Updates received by the home 313 agent and protected by the use of IPsec. Address modifications 314 based on other sources, such as Binding Updates to the 315 correspondent nodes protected by return routability, or open 316 access to an API from any application may result in security 317 vulnerabilities. 319 4.4. Dynamic Keying Requirements 321 The following requirements are related to the use of a dynamic key 322 management protocol by the mobile node and the home agent. 323 Section 7.2 describes the use of IKEv2 as the dynamic key management 324 protocol. 326 o The mobile node MUST use its care-of address as source address in 327 protocol exchanges, when using dynamic keying. 329 o The mobile node and the home agent MUST create security 330 associations based on the home address, so that the security 331 associations survive change in care-of address. When using IKEv2 332 as the key exchange protocol, the home address should be carried 333 as the initiator IP address in the TSi payload during the 334 CREATE_CHILD_SA exchange [4]. 336 o If the mobile node has used IKEv2 to establish security 337 associations with its home agent, it should follow the procedures 338 discussed in Section 11.7.1 and 11.7.3 of the base specification 339 [2] to determine whether the IKE endpoints can be moved or if the 340 IKE SA has to be re-established. 342 o If the home agent has used IKEv2 to establish security 343 associations with the mobile node, it should follow the procedures 344 discussed in Section 10.3.1 and 10.3.2 of the base specification 345 [2] to determine whether the IKE endpoints can be moved or if the 346 IKE SA has to be re-established. 348 5. Selector Granularity Considerations 350 IPsec implementations are compatible with this document even if they 351 do not support fine grain selectors such as the Mobility Header 352 message type and ICMPv6 message type. For various reasons, some 353 implementations may choose to support only coarse grain selectors 354 (i.e., addresses and in some case protocol field) for forwarded 355 traffic. As finer grain selectors give a better control, i.e., the 356 protection is only applied when required, the examples in the 357 document always use the finest granularity. 359 The following describes different ways of setting up IPsec policies 360 for protecting Mobile IPv6 messages: 362 o The IPsec implementations on the mobile node and the home agent 363 support fine grain selectors, including the Mobility Header 364 message type This is the case assumed in the IPsec SPD and SAD 365 examples in this document. 367 o The IPsec implementations only support selectors at a protocol 368 level. The protection of Return Routability Messages uses a setup 369 similar to the regular payload packets to the correspondent node 370 with the protocol selector set to Mobility Header messages. All 371 tunneled Mobility Header messages will be protected. 373 o The last case is where the protocol selector is not available or 374 for privacy considerations all traffic tunneled between the mobile 375 node and the home agent is protected. This uses IPsec tunnel SA 376 with the protocol selector set to 'any'. 378 The last case where all tunneled traffic is protected introduces some 379 additional considerations: 381 o If there is just one IPsec SA providing protection for all 382 traffic, then the SA MUST fulfill the requirements for protecting 383 the Return Routability messages which require confidentiality 384 protection. There can also be separate tunnel mode SPD entries 385 for protecting the Return Routability messages with a higher 386 priority. 388 6. Manual Configuration 390 This section describes the SPD and SAD entries that can be used to 391 protect Mobile IPv6 signaling messages. The SPD and SAD entries are 392 only example configurations. A particular mobile node implementation 393 and a home agent implementation could configure different SPD and SAD 394 entries as long as they provide the required security of the Mobile 395 IPv6 signaling messages. 397 For the examples described in this document, a mobile node with home 398 address, "home_address_1", primary care-of address, 399 "care_of_address_1", a home agent with address, "home_agent_1" and a 400 user of the mobile node with identity "user_1" are assumed. If the 401 home address of the mobile node changes, the SPD and SAD entries need 402 to re-created or updated for the new home address. 404 6.1. Binding Updates and Acknowledgements 406 The following are the SPD and SAD entries on the mobile node and the 407 home agent to protect Binding Updates and Acknowledgements. 409 mobile node SPD-S: 410 - IF source = home_address_1 & destination = home_agent_1 & 411 proto = MH & local_mh_type =BU & remote_mh_type = 412 BAck 413 Then use SA SA1 (OUT) and SA2 (IN) 415 mobile node SAD: 416 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 417 source = home_address_1 & destination = home_agent_1 & 418 proto = MH & mh_type = BU 419 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 420 source = home_agent_1 & destination = home_address_1 & 421 proto = MH & mh_type = BAck 423 home agent SPD-S: 424 - IF source = home_agent_1 & destination = home_address_1 & 425 proto = MH & local_mh_type = BAck & remote_mh_type 426 = BU 427 Then use SA SA2 (OUT) and SA1 (IN) 429 home agent SAD: 430 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 431 source = home_agent_1 & destination = home_address_1 & 432 proto = MH & mh_type = BAck 433 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 434 source = home_address_1 & destination = home_agent_1 & 435 proto = MH & mh_type = BU 437 6.2. Return Routabililty Messages 439 The following are the SPD and SAD entries on the mobile node and the 440 home agent to protect Return Routability messages. 442 mobile node SPD-S: 443 - IF source = home_address_1 & destination = any & 444 proto = MH & local_mh_type = HoTi & remote_mh_type = HoT 445 Then use SA SA3 (OUT) and SA4 (IN) 447 mobile node SAD: 448 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 449 source = home_address_1 & destination = any & proto = MH & 450 mh_type = HoTi 451 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 452 source = any & destination = home_address_1 & proto = MH & 453 mh_type = HoT 455 home agent SPD-S: 456 - IF destination = home_address_1 & source = any & 457 proto = MH & local_mh_type = HoT & remote_mh_type = 458 HoTi 459 Then use SA SA4 (OUT) and SA3 (IN) 461 home agent SAD: 462 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 463 source = any & destination = home_address_1 & proto = MH & 464 mh_type = HoT 465 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 466 source = home_address_1 & destination = any & proto = MH & 467 mh_type = HoTi 469 6.3. Mobile Prefix Discovery Messages 471 The following are the SPD and SAD entries used to protect Mobile 472 Prefix Discovery messages. 474 mobile node SPD-S: 475 - IF source = home_address_1 & destination = home_agent_1 & 476 proto = ICMPv6 & local_icmp6_type = MPS & 477 remote_icmp6_type = MPA 478 Then use SA SA5 (OUT) and SA6 (IN) 480 mobile node SAD: 481 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 482 source = home_address_1 & destination = home_agent_1 & 483 proto = ICMPv6 & icmp6_type = MPS 484 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 485 source = home_agent_1 & destination = home_address_1 & 486 proto = ICMPv6 & icmp6_type = MPA 488 home agent SPD-S: 489 - IF source = home_agent_1 & destination = home_address_1 & 490 proto = ICMPv6 & local_icmp6_type = MPA & 491 remote_icmp6_type = MPS 492 Then use SA SA6 (OUT) and SA5 (IN) 494 home agent SAD: 495 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 496 source = home_agent_1 & destination = home_address_1 & 497 proto = ICMPv6 & icmp6_type = MPA 498 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 499 source = home_address_1 & destination = home_agent_1 & 500 proto = ICMPv6 & icmp6_type = MPS 502 6.4. Payload Packets 504 Regular payload traffic between the mobile node and the correspondent 505 node tunneled through the home agent can be protected by IPsec, if 506 required. The mobile node and the home agent use ESP in tunnel mode 507 to protect the tunneled traffic. The SPD and SAD entries shown in 508 Section 5.2.4 of [3] are applicable here. 510 7. Dynamic Configuration 512 This section describes the use of IKEv2 to setup the required 513 security associations. 515 7.1. Security Policy Database Entries 517 The following sections describe the security policy entries on the 518 mobile node and the home agent. The SPD entries are only example 519 configurations. A particular mobile node implementation and a Home 520 Agent implementation could configure different SPD entries as long as 521 they provide the required security of the Mobile IPv6 signaling 522 messages. 524 In the examples shown below, the identity of the user of the mobile 525 node is assumed to be user_1, the home address of the mobile node is 526 assumed to be home_address_1, he primary care-of address of the 527 mobile node is assumed to be care_of_address_1 and the IPv6 address 528 of the Home Agent is assumed to be home_agent_1. 530 7.1.1. Binding Updates and Acknowledgements 532 The following are the SPD entries on the mobile node and the home 533 agent for protecting Binding Updates and Acknowledgements. 535 mobile node SPD-S: 536 - IF source = home_address_1 & destination = home_agent_1 & 537 proto = MH & local_mh_type = BU & remote_mh_type = BAck 538 Then use SA ESP transport mode 539 IDi = user_1, IDr = home_agent_1, 540 TSi = home_address_1, MH, BU 541 TSr = home_agent_1, MH, BAck 543 home agent SPD-S: 544 - IF source = home_agent_1 & destination = home_address_1 & 545 proto = MH & local_mh_type = BAck & remote_mh_type = BU 546 Then use SA ESP transport mode 547 IDi = home_agent_1, IDr = user_1 548 TSi = home_agent_1, MH, BAck 549 TSr = home_address_1, MH, BU 551 In the examples shown above, the home address of the mobile node 552 might not be available all the time. For instance, the mobile node 553 might have not configured a home address yet. When the mobile node 554 acquires a new home address, it must either add the address to the 555 corresponding SPD entries or create the SPD entries for the home 556 address. 558 The home agent should have named SPD entries per mobile node, based 559 on the identity of the mobile node. The identity of the mobile node 560 is stored in the "Name" selector in the SPD [5]. The home address 561 presented by the mobile node during the IKE negotiation is stored as 562 the remote IP address in the resultant IPsec security associations. 563 The home agent MAY also have generic SPD entries to prevent mobility 564 header traffic that requires IPsec protection from bypassing the 565 IPsec filters. 567 The Mobility Header message type is negotiated by placing it in the 568 most significant eight bits of the 16 bit local "port" selector 569 during IKEv2 exchange. For more details, refer to [5]. The TSi and 570 TSr payloads in the above examples will contain many other selectors 571 apart from home_address_1. For the sake of brevity, we show only 572 those values that relevant for Mobile IPv6. 574 7.1.2. Return Routability Messages 576 The following are the SPD entries on the mobile node and the home 577 agent for protecting the Return Routability messages. 579 mobile node SPD-S: 580 - IF source = home_address_1 & destination = any & 581 proto = MH & local_mh_type = HoTi & 582 remote_mh_type = HoT 583 Then use SA ESP tunnel mode 584 IDi = user_1, IDr = home_agent_1, 585 TSi = home_address_1, MH, HoTi 586 TSr = any, MH, HoT 587 outer src addr = care_of_address_1, 588 outer dst addr = home_agent_1, 589 inner src addr = home_address_1 591 home agent SPD-S: 592 - IF source = any & destination = home_address_1 & 593 proto = MH & local_mh_type = HoT & 594 remote_mh_type = HoTi 595 Then use SA ESP tunnel mode 596 IDi = home_agent_1, IDr = user_1 597 TSi = any, MH, HoT 598 TSr = home_address_1, MH, HoTi 599 outer src addr = home_agent_1, 600 outer dst addr = care_of_address_1, 601 inner dst addr = home_address_1 603 When the mobile node's care-of address changes the SPD entries on 604 both the mobile node and the home agent must be updated. The home 605 agent knows about the change in care-of address of the mobile node 606 when it receives a Binding Update from the mobile node. 608 7.1.3. Mobile Prefix Discovery Messages 610 The following are the SPD entries on the mobile node and the home 611 agent for protecting Mobile Prefix Discovery messages. 613 mobile node SPD-S: 614 - IF source = home_address_1 & destination = home_agent_1 & 615 proto = ICMPv6 & local_mh_type = MPS & 616 remote_mh_type = MPA 617 Then use SA ESP transport mode 618 IDi = user_1, IDr = home_agent_1, 619 TSi = home_address_1, ICMPv6, MPS 620 TSr = home_agent_1, ICMPv6, MPA 622 home agent SPD-S: 623 - IF source = home_agent_1 & destination = home_address_1 & 624 proto = ICMPv6 & local_mh_type = MPA & 625 remote_mh_type = MPS 626 Then use SA ESP transport mode 627 IDi = home_agent_1, IDr = user_1 628 TSi = home_agent_1, ICMPv6, MPA 629 TSr = home_address_1, ICMPv6, MPS 631 In the examples shown above, the home address of the mobile node 632 might not be available all the time. When the mobile node acquires a 633 new home address, it must add the address to the corresponding SPD 634 entries. 636 The TSi and TSr payloads in the above examples will contain many 637 other selectors apart from home_address_1. For brevity, they are not 638 show here. 640 7.1.4. Payload Packets 642 The following are the SPD entries on the mobile node and the home 643 agent if payload traffic exchanged between the mobile node and its 644 Correspondent Node needs to be protected. The SPD entries are 645 similar to the entries for protecting Return Routability messages and 646 have lower priority than the above SPD entries. 648 mobile node SPD-S: 649 - IF interface = IPv6 tunnel to home_agent_1 & proto = X 650 Then use SA ESP tunnel mode 651 IDi = user_1, IDr = home_agent_1, 652 TSi = home_address_1, X, port 653 TSr = any, X, port 654 outer src addr = care_of_address_1 655 outer dst addr = home_agent_1, 656 inner src addr = home_address_1 658 home agent SPD-S: 659 - IF interface = IPv6 tunnel to home_address_1 & proto = X 660 Then use SA ESP tunnel mode 661 IDi = home_agent_1, IDr = user_1, 662 TSi = any, X, port 663 TSr = home_address_1, X, port 664 outer src addr = home_agent_1, 665 outer dst addr = care_of_address_1, 666 inner dst addr = home_address_1 668 7.2. Security Association negotiation using IKEv2 670 Mobile IPv6 signaling messages are typically initiated by the mobile 671 node. The mobile node sends a Binding Update to the home agent 672 whenever it moves and acquires a new care-of address. 674 The mobile node initiates an IKEv2 protocol exchange if the required 675 security associations are not present. A possible mechanism used for 676 mutual authentication is a shared secret between the mobile node and 677 the home agent. The home agent uses the identity of the mobile node 678 to identify the corresponding shared secret. When a public key based 679 mechanism is available, it should be the preferred mechanism for 680 mutual authentication: private keys are used to generate the AUTH 681 payload and identities are verified with certificate information 682 transmitted by CERT payloads. If the mobile node is configured with 683 the home agent information including the public key that corresponds 684 to the home agent, then the mobile node MAY exclude the CERTREQ 685 payload in its IKE_AUTH third message. Similarly, the home agent MAY 686 exclude the CERTREQ payload in its IKE_SA_INIT second message if it 687 is configured with the mobile node information. 689 If a shared secret is being used, the mobile node uses the shared 690 secret to generate the AUTH payload in the IKE_AUTH exchange. If the 691 mobile node is using a public key based mechanism, then it uses its 692 private key to generate the AUTH payload in the IKE_AUTH exchange. 694 Mobile Node Home Agent 695 ----------- ---------- 696 HDR, SAi1, KEi, Ni --> 698 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 700 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 701 AUTH, SAi2, TSi, TSr} 702 --> 704 <-- HDR, SK {IDr, [CERT,] AUTH, 705 SAr2, TSi, TSr} 707 The mobile node should always includes its identity in the IDi 708 payload in the IKE_AUTH exchange. The mobile node could use the 709 following different types of identities to identity itself to the 710 home agent. 712 o Home Address - The mobile node could use its statically configured 713 home address as its identity. In this case the ID Type field is 714 set to ID_IPV6_ADDR. 715 o FQDN - The mobile node can use a Fully Qualified Domain Name as 716 the identifier and set the ID Type field to ID_FQDN. 717 o RFC 822 identifier - If the mobile node uses a RFC 822 identifier 718 [10], it sets the ID Type field to ID_RFC822_ADDR. 720 In the IKE_AUTH exchange, the mobile node includes the home address 721 and the appropriate selectors in the TSi (Traffic Selector-initiator) 722 payload to negotiate IPsec security associations for protecting the 723 Binding Update and Binding Acknowledgement messages. The mobile node 724 MAY use a range of selectors that includes the mobility message types 725 for Binding Update and Binding Acknowledgement to use the same pair 726 of IPsec security association for both messages. 728 After the IKE_AUTH exchange completes, the mobile node initiates 729 CREATE_CHILD_SA exchanges to negotiate additional security 730 associations for protecting Return Routability signaling, Mobile 731 Prefix Discovery messages and optionally payload traffic. The 732 CREATE_CHILD_SA exchanges are protected by the security association 733 created during the IKE_AUTH exchange. If a correspondent node, that 734 is also a mobile node, initiates the return routability exchange, 735 then the home agent initiates the CREATE_CHILD_SA exchange to 736 negotiate security associations for protecting Return Routabilty 737 messages. 739 It is important that the security associations are created based on 740 the home address of the mobile node, so that the security 741 associations survive care-of address change. The mobile node MUST 742 use its home address as the initiator IP address in the TSi payload 743 in the CREATE_CHILD_SA exchange in order to create the security 744 associations for the home address. 746 Mobile Node Home Agent 747 ----------- ---------- 748 HDR, SK {[N], SA, Ni, [KEi], 749 [TSi, TSr]} --> 751 <-- HDR, SK {SA, Nr, [KEr], 752 [TSi, TSr]} 754 When PKI based authentication is used between the mobile node and the 755 Home Agent, the identity presented by the mobile node in the IDi 756 payload must correspond to the identity in the certificate obtained 757 by the Home Agent. The home agent uses the identity presented in the 758 IDi payload to lookup the policy and the certificate that corresponds 759 to the mobile node. If the mobile node presents its home address in 760 the IDi payload, then the home agent MUST verify that the home 761 address matches the address in the iPAddress field in the 762 SubjectAltName extension [9]. 764 When the mobile node uses its home address in the IDi field, 765 implementations are required to match the source address in the outer 766 most IP header with the IP address in the IDi field [9]. This 767 verification step, however, should be configurable [9]. With Mobile 768 IPv6, this verification step will always fail because the source 769 address in the IP header is the care-of address and the IP address in 770 the IDi field is the home address. Therefore, this verification step 771 MUST be disabled. 773 7.3. Movements and Dynamic Keying 775 If the mobile node moves and its care-of address changes, the IKEv2 776 SA might not be valid, unless the mobility extensions defined in [13] 777 are implemented by both the mobile node and the home agent. RFC 3775 778 defines a mechanism based on the successful exchange of Binding 779 Update and Binding Acknowledgement messages. The mobile node 780 establishes the IKE SA with the home agent using its primary care-of 781 address. The IKE SA endpoints are updated on the home agent when it 782 receives the Binding Update from the mobile node's new care-of 783 address and on the mobile node when it sends the Binding Update to 784 the home agent or when it receives the Binding acknowledgement sent 785 by the home agent. This capability to change IKE endpoints is 786 indicated through setting the Key Management Capability (K) flag [2] 787 in the Binding Update and Binding Acknowledgement messages. If the 788 mobile node or the home agent does not support this capability, then 789 an IKEv2 exchange MUST be initiated to re-establish a new IKE SA. 791 8. The use of EAP authentication 793 In addition to using public key signatures and shared secrets, EAP 794 [11] can be used with IKEv2 for authenticating the mobile node to the 795 home agent. 797 The mobile node indicates that it wants to use EAP by including the 798 IDi payload but leaving out the AUTH payload in the first message 799 during the IKE_AUTH exchange. The home agent then includes an EAP 800 payload if it is willing to use an extensible authentication method. 801 Security associations are not created until the subsequent IKE_AUTH 802 exchange after successful EAP authentication. The use of EAP adds at 803 least two round trips to the IKE negotiation. 805 Mobile Node Home Agent 806 ------------ ---------- 807 HDR, SAi1, KEi, Ni --> 809 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 811 HDR, SK {IDi, [CERTREQ,] [IDr,] 812 SAi2, TSi, TSr}--> 814 <-- HDR, SK {IDr, [CERT,] AUTH, 815 EAP } 817 HDR, SK {EAP} --> 819 <-- HDR, SK {EAP (success)} 821 HDR, SK {AUTH} --> 823 <-- HDR, SK {AUTH, SAr2, TSi, 824 TSr} 826 Some EAP methods generate a shared key on the mobile node and the 827 Home Agent once the EAP authentication succeeds. In this case, the 828 shared key is used to generate the AUTH payloads in the subsequent 829 messages. The shared key, if used to generate the AUTH payloads, 830 MUST NOT be used for any other purpose. For more details, refer to 831 [4]. 833 The use of EAP between the mobile node and the home agent might 834 require the home agent to contact an authorization server like the 835 AAA Home server, on the home link, to authenticate the mobile node. 836 Please refer to [7] for more details. 838 The IKEv2 specification [4] requires that public key based mechanism 839 be used to authenticate the home agent to the mobile node, when EAP 840 is used. This should be used by default by the mobile node and the 841 home agent. If the EAP method that is used, supports mutual 842 authentication and key generation, then the mobile node MAY use EAP 843 itself to authenticate the home agent. The mobile node can request 844 this by including the EAP_ONLY_AUTHENTICATION notification payload 845 [8] in message 3. If the home agent supports the 846 EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, 847 it omits the public key based AUTH and CERT payloads in message 4. 848 If the home agent does not support this mechanism, it rejects it by 849 including an AUTH payload in message 4. More details can be found in 850 [8]. 852 9. Dynamic Home Address Configuration 854 The mobile node can dynamically configure a home address by including 855 a Configuration Payload in the IKE_AUTH exchange, with a request for 856 an address from the home link. The mobile node should include an 857 INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The 858 mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it 859 wants to obtain information about the IPv6 prefixes on the home link. 860 If the mobile node wants to configure a DNS server from the home link 861 it can request for the DNS server information by including an 862 INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. 864 When the home agent receives a configuration payload with a 865 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home 866 address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in 867 the CFG_REPLY contains the prefix length of the home prefix in 868 addition to a 128 bit home address. The home agent could use a local 869 database or contact a DHCPv6 server on the home link to allocate a 870 home address. The Home Agent should also include an 871 INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the 872 duration for which the dynamically allocated home address is valid. 874 Mobile Node Home Agent 875 ----------- ---------- 876 HDR, SK {IDi, [CERT,] [CERTREQ,] 877 [IDr,] AUTH, CP(CFG_REQUEST), 878 SAi2, TSi, TSr} 879 --> 881 <-- HDR, SK {IDr, [CERT,] AUTH, 882 CP(CFG_REPLY), SAr2, 883 TSi, TSr} 885 The mobile node could suggest a home address that it wants to use in 886 the CFG_REQUEST. For example, this could be a home address that it 887 was allocated before or could be an address the mobile node auto- 888 configured from the IPv6 prefix on the home link. The Home Agent 889 could let the mobile node use the same home address by setting the 890 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same 891 home address. If the home agent wants the mobile node to use a 892 different home address, it sends a new home address in the 893 INTERNAL_IP_ADDRESS attribute in the CFG_REPLY payload. The Mobile 894 Node MUST stop using its old home address and start using the newly 895 allocated home address. 897 In case the home agent is unable to allocate a home address for the 898 mobile node during the IKE_AUTH exchange, it MUST send a Notify 899 Payload with an INTERNAL_ADDRESS_FAILURE message. 901 10. Security Considerations 903 This document describes how IPsec can be used to secure Mobile IPv6 904 signaling messages. Please refer to RFC 3775 for security 905 considerations related to the use of IPsec with Mobile IPv6. 907 A misbehaving mobile node could create IPsec security associations 908 for a home address that belongs to another mobile node. Therefore, 909 the home agent should check if a particular mobile node is authorized 910 to use a home address before creating IPsec security associations for 911 the home address. If the home address is assigned as described in 912 Section 9, the home agent MUST associate the home address with the 913 identity used in IKE negotiation. The home agent MAY store the 914 assigned home address in the SPD entries created for the mobile node. 916 The use of EAP for authenticating the mobile node to the home agent 917 is described in Section 8. This document recommends that if the EAP 918 method used, supports mutual authentication, then EAP itself be used 919 for authenticating the home agent to the mobile node also. This runs 920 contrary to the recommendation in [4]. The home agent can ignore the 921 recommendation in this document and implement EAP authentication as 922 described in the IKEv2 specification. Security considerations 923 related to the use of EAP with IKEv2 are described in [4] and [8]. 925 11. IANA Considerations 927 This document requires no action from IANA. 929 12. Acknowledgements 930 The author would like to thank Mika Joutsenvirta, Pasi Eronen, 931 Francis Dupont, Jari Arkko, Gerardo Giaretta and Shinta Sugimoto for 932 reviewing the draft. 934 Many of the requirements listed in Section 4 are copied from RFC 935 3776. Therefore, the authors of RFC 3776 are acknowledged. 937 13. References 939 13.1. Normative References 941 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 942 Levels", BCP 14, RFC 2119, March 1997. 944 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 945 IPv6", RFC 3775, June 2004. 947 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 948 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 949 Agents", RFC 3776, June 2004. 951 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 952 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 954 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 955 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 956 April 2005. 958 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", 959 draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 961 13.2. Informative References 963 [7] Giaretta, G., "Goals for AAA-HA interface", 964 draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), 965 September 2004. 967 [8] Eronen, P., "Extension for EAP Authentication in IKEv2", 968 draft-eronen-ipsec-ikev2-eap-auth-03 (work in progress), 969 April 2005. 971 [9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 972 ISAKMP, IKEv2, and PKIX", 973 draft-ietf-pki4ipsec-ikecert-profile-05 (work in progress), 974 August 2005. 976 [10] Crocker, D., "Standard for the format of ARPA Internet text 977 messages", STD 11, RFC 822, August 1982. 979 [11] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 980 Levkowetz, "Extensible Authentication Protocol (EAP)", 981 RFC 3748, June 2004. 983 [12] Kent, S. and R. Atkinson, "Security Architecture for the 984 Internet Protocol", RFC 2401, November 1998. 986 [13] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 987 draft-ietf-mobike-protocol-01 (work in progress), July 2005. 989 [14] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile 990 IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-01 (work 991 in progress), September 2005. 993 Authors' Addresses 995 Vijay Devarapalli 996 Nokia Research Center 997 313 Fairchild Drive 998 Mountain View, CA 94043 999 USA 1001 Email: vijay.devarapalli@nokia.com 1003 Francis Dupont 1004 Point6 1005 c/o GET/ENST Bretagne 1006 2 rue de la Chataigneraie 1007 CS 17607 1008 35576 Cesson-Sevigne Cedex 1009 France 1011 Email: Francis.Dupont@enst-bretagne.fr 1013 Intellectual Property Statement 1015 The IETF takes no position regarding the validity or scope of any 1016 Intellectual Property Rights or other rights that might be claimed to 1017 pertain to the implementation or use of the technology described in 1018 this document or the extent to which any license under such rights 1019 might or might not be available; nor does it represent that it has 1020 made any independent effort to identify any such rights. Information 1021 on the procedures with respect to rights in RFC documents can be 1022 found in BCP 78 and BCP 79. 1024 Copies of IPR disclosures made to the IETF Secretariat and any 1025 assurances of licenses to be made available, or the result of an 1026 attempt made to obtain a general license or permission for the use of 1027 such proprietary rights by implementers or users of this 1028 specification can be obtained from the IETF on-line IPR repository at 1029 http://www.ietf.org/ipr. 1031 The IETF invites any interested party to bring to its attention any 1032 copyrights, patents or patent applications, or other proprietary 1033 rights that may cover technology that may be required to implement 1034 this standard. Please address the information to the IETF at 1035 ietf-ipr@ietf.org. 1037 Disclaimer of Validity 1039 This document and the information contained herein are provided on an 1040 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1041 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1042 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1043 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1044 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1045 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1047 Copyright Statement 1049 Copyright (C) The Internet Society (2005). This document is subject 1050 to the rights, licenses and restrictions contained in BCP 78, and 1051 except as set forth therein, the authors retain all their rights. 1053 Acknowledgment 1055 Funding for the RFC Editor function is currently provided by the 1056 Internet Society.