idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-07.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 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1090. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3776, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3776, updated by this document, for RFC5378 checks: 2002-09-20) -- 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 22, 2006) is 6396 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 865 -- Looks like a reference, but probably isn't: 'N' on line 804 -- Looks like a reference, but probably isn't: 'KEi' on line 804 -- Looks like a reference, but probably isn't: 'KEr' on line 807 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-11 -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '9') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-04) exists of draft-sugimoto-mip6-pfkey-migrate-03 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Updates: 3776 (if approved) F. Dupont 5 Intended status: Standards Track CELAR 6 Expires: April 25, 2007 October 22, 2006 8 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 9 draft-ietf-mip6-ikev2-ipsec-07.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 25, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . 7 54 4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 8 55 5. Selector Granularity Considerations . . . . . . . . . . . . . 9 56 6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 10 57 6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 11 58 6.2. Return Routabililty Messages . . . . . . . . . . . . . . . 11 59 6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 12 60 6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 13 61 7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 13 62 7.1. Security Policy Database Entries . . . . . . . . . . . . . 13 63 7.1.1. Binding Updates and Acknowledgements . . . . . . . . . 14 64 7.1.2. Return Routability Messages . . . . . . . . . . . . . 15 65 7.1.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 15 66 7.1.4. Payload Packets . . . . . . . . . . . . . . . . . . . 16 67 7.2. Security Association negotiation using IKEv2 . . . . . . . 17 68 7.3. Movements and Dynamic Keying . . . . . . . . . . . . . . . 19 69 8. The use of EAP authentication . . . . . . . . . . . . . . . . 20 70 9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 21 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 78 Intellectual Property and Copyright Statements . . . . . . . . . . 25 80 1. Introduction 82 RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used 83 with Mobile IPv6 [2] to protect the signaling messages. It also 84 illustrates examples of Security Policy Database and Security 85 Association Database entries that can be used to protect Mobile IPv6 86 signaling messages. 88 The IPsec architecture has been revised in RFC 4301 [5]. Among the 89 many changes, the list of selectors has been expanded to include the 90 Mobility Header message type. This has an impact on how security 91 policies and security associations are configured for protecting 92 mobility header messages. It becomes easier to differentiate between 93 the various Mobility Header messages based on the type value instead 94 of checking if a particular mobility header message is being sent on 95 a tunnel interface between the mobile node and the home agent, as it 96 was in RFC 3776. The revised IPsec architecture specification also 97 includes ICMP message type and code as selectors. This makes it 98 possible to protect Mobile Prefix Discovery messages without applying 99 the same security associations to all ICMPv6 messages. 101 This document discusses new requirements for the home agent and the 102 mobile node to use the revised IPsec architecture and IKEv2. 103 Section 4 lists the requirements. Section 6 and Section 7 describe 104 the required Security Policy Database (SPD) and Security Association 105 Database (SAD) entries. 107 The Internet Key Exchange (IKE) has also been substantially revised 108 and simplified [4]. Section 7.2 of this document describes how IKEv2 109 can be used to setup security associations for Mobile IPv6. 111 The use of EAP within IKEv2 is allowed to authenticate the mobile 112 node to the home agent. This is described in Section 8. A method 113 for dynamically configuring a home address from the home agent using 114 the Configuration Payload in IKEv2 is described in Section 9. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [1]. 122 3. Packet Formats 124 The mobile node and the home agent MUST support the packet formats as 125 defined in Section 3 of RFC 3776. 127 In case the mobile node reverse tunnels all traffic including Mobile 128 IPv6 signaling messages exchanged between the mobile node and the 129 home agent, then the Home Address Option is not required to be 130 present in the messages sent to the home agent. The packet format 131 for the binding update when sent in the tunnel mode looks as follows. 133 IPv6 hdr (source = care-of address, 134 destination = home agent) 135 ESP header in tunnel mode 136 IPv6 hdr (source = home address, 137 destination = home agent) 138 Mobility Header 139 Binding Update 140 Alternate Care-of Address option (care-of address) 142 The binding acknowledgement sent to the mobile node when it is away 143 from the home link looks as follows. 145 IPv6 hdr (source = home agent, 146 destination = care-of address) 147 ESP header in tunnel mode 148 IPv6 hdr (source = home agent, 149 destination = home address) 150 Mobility Header 151 Binding Acknowledgement 153 The packet formats for tunneled mobile prefix discovery messages is 154 very similar with the home address as the source address in the inner 155 IP header. 157 The support for the above tunneled packet format is optional on the 158 mobile node and the home agent. 160 4. Requirements 162 This section describes mandatory rules and requirements for all 163 Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as 164 the key negotiation protocol, can be used to protect traffic between 165 the mobile node and the home agent. Many of the requirements are 166 repeated from RFC 3776 to make this document self-contained and 167 complete. 169 4.1. General Requirements 171 o RFC 3775 states that manual configuration of IPsec security 172 associations MUST be supported and automated key management MAY be 173 supported. This document does not make any recommendations 174 regarding the support of manual IPsec configuration and dynamic 175 IPsec configuration. This document just describes the use of 176 manually created IPsec security associations and the use of IKEv2 177 as the automated IPsec key management protocol for protecting 178 Mobile IPv6 signaling messages. 180 o ESP encapsulation for Binding Updates and Binding Acknowledgements 181 MUST be supported and used. 183 o ESP encapsulation in tunnel mode for the Home Test Init and Home 184 Test messages tunneled between the mobile node and the home agent 185 MUST be supported and SHOULD be used. 187 o ESP encapsulation of the ICMPv6 messages related to mobile prefix 188 discovery MUST be supported and SHOULD be used. 190 o ESP encapsulation of the payload packets tunneled between the 191 mobile node and the home agent MAY be supported and used. 193 o If multicast group membership control protocols or stateful 194 address autoconfiguration protocols are supported, payload data 195 protection MUST be supported for those protocols. 197 o The home agent and the mobile node MAY support authentication 198 using EAP in IKEv2 as described in Section 8. 200 o The home agent and the mobile node MAY support remote 201 configuration of home address as described in Section 9. When the 202 home agent receives a configuration payload with a CFG_REQUEST for 203 INTERNAL_IP6_ADDRESS, it must reply with a valid home address for 204 the mobile node. The home agent can pick a home address from a 205 local database or from a DHCPv6 server on the home link. 207 4.2. Policy Requirements 209 The following requirements are related to the configuration of 210 security policy database on the home agent and the mobile node. 212 o RFC 3776 required configuration of the security policies per 213 interface in order to be able to differentiate between mobility 214 header messages sent to the home agent and tunneled through the 215 home agent to the correspondent node. Since the Mobility Header 216 message type is a selector, it is now easy to differentiate 217 between HoTi and HoT messages from other mobility header messages. 218 Therefore per-interface configuration of security policies is not 219 required. 221 o The home agent MUST be able to prevent a mobile node from using 222 its security association to send a Binding Update on behalf of 223 another mobile node. With manual IPsec configuration, the home 224 agent MUST be able to verify that a security association was 225 created for a particular home address. With dynamic keying, the 226 home agent MUST be able to verify that the identity presented in 227 the IKE_AUTH exchange is allowed to create security associations 228 for a particular home address. 230 o The home agent MAY use the Peer Authorization Database (PAD) [5] 231 to store per-mobile node state. The PAD entry for a mobile node 232 MAY contain a shared key, public key or a trust anchor to verify 233 the mobile node's certificate for authenticating the mobile node. 235 o As required in the base specification [2], when a packet destined 236 to the receiving node is matched against IPsec security policy or 237 selectors of a security association, an address appearing in a 238 Home Address destination option is considered as the source 239 address of the packet. 241 Note that the home address option appears before IPsec headers. 242 Section 11.3.2 of the base specification describes one possible 243 implementation approach for this: The IPsec policy operations can 244 be performed at the time when the packet has not yet been modified 245 per Mobile IPv6 rules, or has been brought back to its normal form 246 after Mobile IPv6 processing. That is, the processing of the Home 247 Address option is seen as a fixed transformation of the packets 248 that does not affect IPsec processing. 250 o Similarly, a home address within a Type 2 Routing header destined 251 to the receiving node is considered as the destination address of 252 the packet, when a packet is matched against IPsec security policy 253 or selectors of a security association. 255 Similar implementation considerations apply to the Routing header 256 processing as was described above for the Home Address destination 257 option. 259 o When the mobile node returns home and de-registers with the Home 260 Agent, the tunnel between the home agent and the mobile node's 261 care-of address is torn down. The security policy entries, which 262 were used for protecting tunneled traffic between the mobile node 263 and the home agent MUST be made inactive (for instance, by 264 removing them and installing them back later through an API). The 265 corresponding security associations could be kept as they are or 266 deleted depending on how they were created. If the security 267 associations were created dynamically using IKE, they are 268 automatically deleted when they expire. If the security 269 associations were created through manual configuration, they MUST 270 be retained and used later when the mobile node moves away from 271 home again. The security associations protecting Binding Updates 272 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 273 as they do not depend on care-of addresses and can be used again. 275 o The mobile node MUST use the Home Address destination option in 276 Binding Updates and Mobile Prefix Solicitations, sent to the home 277 agent from a care-of address, so that the home address is visible 278 when the IPsec policy checks are made. 280 o The home agent MUST use the Type 2 Routing header in Binding 281 Acknowledgements and Mobile Prefix Advertisements sent to the 282 mobile node, again due to the need to have the home address 283 visible when the policy checks are made. 285 4.3. IPsec Protocol Processing Requirements 287 The following lists requirements for IPsec processing at the Home 288 Agent and the mobile node. 290 o The home agent and mobile node SHOULD support Mobility Header 291 message type as an IPsec selector. 293 o The home agent and mobile node SHOULD support ICMPv6 message type 294 as an IPsec selector. 296 o The home agent MUST be able to distinguish between HoTi messages 297 sent to itself, when it is acting as a Correspondent Node, from 298 those sent to Correspondent Nodes when it is acting as a home 299 agent, based on the destination address of the packet. 301 o When securing Binding Updates, Binding Acknowledgements, and 302 Mobile Prefix Discovery messages, both the mobile node and the 303 home agent MUST support the use of Encapsulating Security Payload 304 (ESP) [6] header in transport mode and MUST use a non-null payload 305 authentication algorithm to provide data origin authentication, 306 connectionless integrity and optional anti-replay protection. 307 Support for protecting these messages using ESP in tunnel mode is 308 optional. 310 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 311 protection of packets belonging to the return routability 312 procedure. A non-null encryption transform and a non-null 313 authentication algorithm MUST be applied. 315 o When ESP is used to protect Binding Updates, there is no 316 protection for the care-of address that appears in the IPv6 header 317 outside the area protected by ESP. It is important for the home 318 agent to verify that the care-of address has not been tampered 319 with. As a result, the attacker would have redirected the mobile 320 node's traffic to another address. In order to prevent this, 321 Mobile IPv6 implementations MUST use the Alternate Care-of Address 322 mobility option in Binding Updates sent by mobile nodes while away 323 from home. The exception to this is when the mobile node returns 324 home and sends a Binding Update to the home agent in order to de- 325 register. 327 When IPsec is used to protect return routability signaling or 328 payload packets, the mobile node MUST set the source address it 329 uses for the outgoing tunnel packets to the current primary care- 330 of address. 332 o When IPsec is used to protect return routability signaling or 333 payload packets, IPsec security associations are needed to provide 334 this protection. When the care-of address for the mobile node 335 changes as a result of an accepted Binding Update, special 336 treatment is needed for the next packets sent using these security 337 associations. The home agent MUST set the new care-of address as 338 the destination address of these packets, as if the outer header 339 destination address in the security association had changed. 340 Similarly, the home agent starts to expect the new source address 341 in the tunnel packets received from the mobile node. 343 Such address changes can be implemented, for instance, through an 344 API from the Mobile IPv6 implementation to the IPsec 345 implementation. One such API is described in [12]. It should be 346 noted that the use of such an API and the address changes MUST 347 only be done based on the Binding Updates received by the home 348 agent and protected by the use of IPsec. Address modifications 349 based on other sources, such as Binding Updates to the 350 correspondent nodes protected by return routability, or open 351 access to an API from any application may result in security 352 vulnerabilities. 354 4.4. Dynamic Keying Requirements 356 The following requirements are related to the use of a dynamic key 357 management protocol by the mobile node and the home agent. 358 Section 7.2 describes the use of IKEv2 as the dynamic key management 359 protocol. 361 o The mobile node MUST use its care-of address as source address in 362 protocol exchanges, when using dynamic keying. 364 o The mobile node and the home agent MUST create security 365 associations based on the home address, so that the security 366 associations survive change in care-of address. When using IKEv2 367 as the key exchange protocol, the home address should be carried 368 as the initiator IP address in the TSi payload during the 369 CREATE_CHILD_SA exchange [4]. 371 o If the mobile node has used IKEv2 to establish security 372 associations with its home agent, it should follow the procedures 373 discussed in Section 11.7.1 and 11.7.3 of the base specification 374 [2] to determine whether the IKE endpoints can be moved or if the 375 IKE SA has to be re-established. 377 o If the home agent has used IKEv2 to establish security 378 associations with the mobile node, it should follow the procedures 379 discussed in Section 10.3.1 and 10.3.2 of the base specification 380 [2] to determine whether the IKE endpoints can be moved or if the 381 IKE SA has to be re-established. 383 5. Selector Granularity Considerations 385 IPsec implementations are compatible with this document even if they 386 do not support fine grain selectors such as the Mobility Header 387 message type and ICMPv6 message type. For various reasons, some 388 implementations may choose to support only coarse grain selectors 389 (i.e., addresses and in some cases the protocol field) for forwarded 390 traffic. As finer grain selectors give better control, i.e., the 391 protection is only applied when required, the examples in the 392 document always use the finest granularity. 394 The following describes different ways of setting up IPsec policies 395 for protecting Mobile IPv6 messages: 397 o The IPsec implementations on the mobile node and the home agent 398 support fine grain selectors, including the Mobility Header 399 message type. This is the case assumed in the IPsec SPD and SAD 400 examples in this document. 402 o The IPsec implementations only support selectors at a protocol 403 level. In such implementations, the IPsec implementation can only 404 identify mobility header traffic and cannot identify the 405 individual mobility header messages. In this case, the protection 406 of Return Routability Messages uses a setup similar to the regular 407 payload packets to the correspondent node with the protocol 408 selector set to Mobility Header messages. All tunneled Mobility 409 Header messages will be protected. 411 o The third case is where the protocol selector is not available in 412 the IPsec implementation. In this case all traffic sent by the 413 mobile node reverse tunneled through the home agent is protected 414 using ESP in tunnel mode. This case is also applicable when the 415 mobile node, due to privacy considerations tunnels all traffic to 416 the home agent. This includes Mobile IPv6 signaling messages 417 exchanged between the mobile node and the home agent and all 418 traffic exchanged between the mobile node and the correspondent 419 node. This case uses IPsec tunnel mode SA with the protocol 420 selector set to 'any'. 422 The third case where all tunneled traffic is protected introduces 423 some additional considerations: 425 o If there is just one IPsec SA providing protection for all 426 traffic, then the SA MUST fulfill the requirements for protecting 427 the Return Routability messages which require confidentiality 428 protection. If the third case is being used for privacy 429 considerations, then there can also be separate tunnel mode SPD 430 entries for protecting the Return Routability messages with a 431 higher priority. 433 o The receipt of a Binding Update from the new care-of address 434 updates the tunnel end point of the IPsec SA as described in 435 Section 4.3. Since the Binding Update that updates the tunnel end 436 point is received through the same tunnel interface that needs to 437 be updated, special care should be taken on the home agent to 438 ensure that the Binding Update is not dropped. This can be 439 achieved by either performing the source address check on the 440 outer IPv6 header after the binding update is processed or have 441 exception handling to check the inner packet for a Binding Update 442 when the source address match on the outer source address fails. 443 Typical IPsec processing does not check the outer source address. 445 6. Manual Configuration 447 This section describes the SPD and SAD entries that can be used to 448 protect Mobile IPv6 signaling messages. The SPD and SAD entries are 449 only example configurations. A particular mobile node implementation 450 and a home agent implementation could configure different SPD and SAD 451 entries as long as they provide the required security of the Mobile 452 IPv6 signaling messages. 454 For the examples described in this document, a mobile node with home 455 address, "home_address_1", primary care-of address, 456 "care_of_address_1", a home agent with address, "home_agent_1" and a 457 user of the mobile node with identity "user_1" are assumed. If the 458 home address of the mobile node changes, the SPD and SAD entries need 459 to be re-created or updated for the new home address. 461 6.1. Binding Updates and Acknowledgements 463 The following are the SPD and SAD entries on the mobile node and the 464 home agent to protect Binding Updates and Acknowledgements. 466 mobile node SPD-S: 467 - IF source = home_address_1 & destination = home_agent_1 & 468 proto = MH & local_mh_type =BU & remote_mh_type = 469 BAck 470 Then use SA SA1 (OUT) and SA2 (IN) 472 mobile node SAD: 473 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 474 source = home_address_1 & destination = home_agent_1 & 475 proto = MH & mh_type = BU 476 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 477 source = home_agent_1 & destination = home_address_1 & 478 proto = MH & mh_type = BAck 480 home agent SPD-S: 481 - IF source = home_agent_1 & destination = home_address_1 & 482 proto = MH & local_mh_type = BAck & remote_mh_type 483 = BU 484 Then use SA SA2 (OUT) and SA1 (IN) 486 home agent SAD: 487 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 488 source = home_agent_1 & destination = home_address_1 & 489 proto = MH & mh_type = BAck 490 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 491 source = home_address_1 & destination = home_agent_1 & 492 proto = MH & mh_type = BU 494 6.2. Return Routabililty Messages 496 The following are the SPD and SAD entries on the mobile node and the 497 home agent to protect Return Routability messages. 499 mobile node SPD-S: 500 - IF source = home_address_1 & destination = any & 501 proto = MH & local_mh_type = HoTi & remote_mh_type = HoT 502 Then use SA SA3 (OUT) and SA4 (IN) 504 mobile node SAD: 505 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 506 source = home_address_1 & destination = any & proto = MH & 507 mh_type = HoTi 508 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 509 source = any & destination = home_address_1 & proto = MH & 510 mh_type = HoT 512 home agent SPD-S: 513 - IF destination = home_address_1 & source = any & 514 proto = MH & local_mh_type = HoT & remote_mh_type = 515 HoTi 516 Then use SA SA4 (OUT) and SA3 (IN) 518 home agent SAD: 519 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 520 source = any & destination = home_address_1 & proto = MH & 521 mh_type = HoT 522 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 523 source = home_address_1 & destination = any & proto = MH & 524 mh_type = HoTi 526 6.3. Mobile Prefix Discovery Messages 528 The following are the SPD and SAD entries used to protect Mobile 529 Prefix Discovery messages. 531 mobile node SPD-S: 532 - IF source = home_address_1 & destination = home_agent_1 & 533 proto = ICMPv6 & local_icmp6_type = MPS & 534 remote_icmp6_type = MPA 535 Then use SA SA5 (OUT) and SA6 (IN) 537 mobile node SAD: 538 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 539 source = home_address_1 & destination = home_agent_1 & 540 proto = ICMPv6 & icmp6_type = MPS 541 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 542 source = home_agent_1 & destination = home_address_1 & 543 proto = ICMPv6 & icmp6_type = MPA 545 home agent SPD-S: 546 - IF source = home_agent_1 & destination = home_address_1 & 547 proto = ICMPv6 & local_icmp6_type = MPA & 548 remote_icmp6_type = MPS 549 Then use SA SA6 (OUT) and SA5 (IN) 551 home agent SAD: 552 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 553 source = home_agent_1 & destination = home_address_1 & 554 proto = ICMPv6 & icmp6_type = MPA 555 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 556 source = home_address_1 & destination = home_agent_1 & 557 proto = ICMPv6 & icmp6_type = MPS 559 6.4. Payload Packets 561 Regular payload traffic between the mobile node and the correspondent 562 node tunneled through the home agent can be protected by IPsec, if 563 required. The mobile node and the home agent use ESP in tunnel mode 564 to protect the tunneled traffic. The SPD and SAD entries shown in 565 Section 5.2.4 of [3] are applicable here. 567 7. Dynamic Configuration 569 This section describes the use of IKEv2 to setup the required 570 security associations. 572 7.1. Security Policy Database Entries 574 The following sections describe the security policy entries on the 575 mobile node and the home agent. The SPD entries are only example 576 configurations. A particular mobile node implementation and a Home 577 Agent implementation could configure different SPD entries as long as 578 they provide the required security of the Mobile IPv6 signaling 579 messages. 581 In the examples shown below, the identity of the user of the mobile 582 node is assumed to be user_1, the home address of the mobile node is 583 assumed to be home_address_1, he primary care-of address of the 584 mobile node is assumed to be care_of_address_1 and the IPv6 address 585 of the Home Agent is assumed to be home_agent_1. 587 7.1.1. Binding Updates and Acknowledgements 589 The following are the SPD entries on the mobile node and the home 590 agent for protecting Binding Updates and Acknowledgements. 592 mobile node SPD-S: 593 - IF source = home_address_1 & destination = home_agent_1 & 594 proto = MH & local_mh_type = BU & remote_mh_type = BAck 595 Then use SA ESP transport mode 596 IDi = user_1, IDr = home_agent_1, 597 TSi = home_address_1, MH, BU 598 TSr = home_agent_1, MH, BAck 600 home agent SPD-S: 601 - IF source = home_agent_1 & destination = home_address_1 & 602 proto = MH & local_mh_type = BAck & remote_mh_type = BU 603 Then use SA ESP transport mode 604 IDi = home_agent_1, IDr = user_1 605 TSi = home_agent_1, MH, BAck 606 TSr = home_address_1, MH, BU 608 In the examples shown above, the home address of the mobile node 609 might not be available all the time. For instance, the mobile node 610 might have not configured a home address yet. When the mobile node 611 acquires a new home address, it must either add the address to the 612 corresponding SPD entries or create the SPD entries for the home 613 address. 615 The home agent should have named SPD entries per mobile node, based 616 on the identity of the mobile node. The identity of the mobile node 617 is stored in the "Name" selector in the SPD [5]. The home address 618 presented by the mobile node during the IKE negotiation is stored as 619 the remote IP address in the resultant IPsec security associations. 620 If the mobile node dynamically configures a home agent and the home 621 address, the home agent may not know which mobile nodes it is 622 supposed to be serving. Therefore the home agent cannot have SPD 623 entries configured per mobile node. Instead the home agent should 624 have have generic SPD entries to prevent mobility header traffic that 625 requires IPsec protection from bypassing the IPsec filters. Once a 626 mobile node authenticates to the home agent and configures a home 627 address, appropriate SPD entries are created for the mobile node. 629 The Mobility Header message type is negotiated by placing it in the 630 most significant eight bits of the 16 bit local "port" selector 631 during IKEv2 exchange. For more details, refer to [5]. The TSi and 632 TSr payloads in the above examples will contain many other selectors 633 apart from home_address_1. For the sake of brevity, we show only 634 those values that are relevant for Mobile IPv6. 636 7.1.2. Return Routability Messages 638 The following are the SPD entries on the mobile node and the home 639 agent for protecting the Return Routability messages. 641 mobile node SPD-S: 642 - IF source = home_address_1 & destination = any & 643 proto = MH & local_mh_type = HoTi & 644 remote_mh_type = HoT 645 Then use SA ESP tunnel mode 646 IDi = user_1, IDr = home_agent_1, 647 TSi = home_address_1, MH, HoTi 648 TSr = any, MH, HoT 649 outer src addr = care_of_address_1, 650 outer dst addr = home_agent_1, 651 inner src addr = home_address_1 653 home agent SPD-S: 654 - IF source = any & destination = home_address_1 & 655 proto = MH & local_mh_type = HoT & 656 remote_mh_type = HoTi 657 Then use SA ESP tunnel mode 658 IDi = home_agent_1, IDr = user_1 659 TSi = any, MH, HoT 660 TSr = home_address_1, MH, HoTi 661 outer src addr = home_agent_1, 662 outer dst addr = care_of_address_1, 663 inner dst addr = home_address_1 665 When the mobile node's care-of address changes the SPD entries on 666 both the mobile node and the home agent must be updated. The home 667 agent knows about the change in care-of address of the mobile node 668 when it receives a Binding Update from the mobile node. 670 7.1.3. Mobile Prefix Discovery Messages 672 The following are the SPD entries on the mobile node and the home 673 agent for protecting Mobile Prefix Discovery messages. 675 mobile node SPD-S: 676 - IF source = home_address_1 & destination = home_agent_1 & 677 proto = ICMPv6 & local_mh_type = MPS & 678 remote_mh_type = MPA 679 Then use SA ESP transport mode 680 IDi = user_1, IDr = home_agent_1, 681 TSi = home_address_1, ICMPv6, MPS 682 TSr = home_agent_1, ICMPv6, MPA 684 home agent SPD-S: 685 - IF source = home_agent_1 & destination = home_address_1 & 686 proto = ICMPv6 & local_mh_type = MPA & 687 remote_mh_type = MPS 688 Then use SA ESP transport mode 689 IDi = home_agent_1, IDr = user_1 690 TSi = home_agent_1, ICMPv6, MPA 691 TSr = home_address_1, ICMPv6, MPS 693 In the examples shown above, the home address of the mobile node 694 might not be available all the time. When the mobile node acquires a 695 new home address, it must add the address to the corresponding SPD 696 entries. 698 The TSi and TSr payloads in the above examples will contain many 699 other selectors apart from home_address_1. For brevity, they are not 700 show here. 702 7.1.4. Payload Packets 704 The following are the SPD entries on the mobile node and the home 705 agent if payload traffic exchanged between the mobile node and its 706 Correspondent Node needs to be protected. The SPD entries are 707 similar to the entries for protecting Return Routability messages and 708 have lower priority than the above SPD entries. 710 mobile node SPD-S: 711 - IF interface = IPv6 tunnel to home_agent_1 & proto = X 712 Then use SA ESP tunnel mode 713 IDi = user_1, IDr = home_agent_1, 714 TSi = home_address_1, X, port 715 TSr = any, X, port 716 outer src addr = care_of_address_1 717 outer dst addr = home_agent_1, 718 inner src addr = home_address_1 720 home agent SPD-S: 721 - IF interface = IPv6 tunnel to home_address_1 & proto = X 722 Then use SA ESP tunnel mode 723 IDi = home_agent_1, IDr = user_1, 724 TSi = any, X, port 725 TSr = home_address_1, X, port 726 outer src addr = home_agent_1, 727 outer dst addr = care_of_address_1, 728 inner dst addr = home_address_1 730 7.2. Security Association negotiation using IKEv2 732 Mobile IPv6 signaling messages are typically initiated by the mobile 733 node. The mobile node sends a Binding Update to the home agent 734 whenever it moves and acquires a new care-of address. 736 The mobile node initiates an IKEv2 protocol exchange if the required 737 security associations are not present. A possible mechanism used for 738 mutual authentication is a shared secret between the mobile node and 739 the home agent. The home agent uses the identity of the mobile node 740 to identify the corresponding shared secret. When a public key based 741 mechanism is available, it should be the preferred mechanism for 742 mutual authentication. 744 If a shared secret is being used, the mobile node uses the shared 745 secret to generate the AUTH payload in the IKE_AUTH exchange. If the 746 mobile node is using a public key based mechanism, then it uses its 747 private key to generate the AUTH payload in the IKE_AUTH exchange. 749 Mobile Node Home Agent 750 ----------- ---------- 751 HDR, SAi1, KEi, Ni --> 753 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 755 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 756 AUTH, SAi2, TSi, TSr} 757 --> 759 <-- HDR, SK {IDr, [CERT,] AUTH, 760 SAr2, TSi, TSr} 762 The mobile node always includes its identity in the IDi payload in 763 the IKE_AUTH exchange. The mobile node could use the following 764 different types of identities to identity itself to the home agent. 766 o Home Address - The mobile node could use its statically configured 767 home address as its identity. In this case the ID Type field is 768 set to ID_IPV6_ADDR. 769 o FQDN - The mobile node can use a Fully Qualified Domain Name as 770 the identifier and set the ID Type field to ID_FQDN. 771 o RFC 822 identifier - If the mobile node uses a RFC 822 identifier 772 [9], it sets the ID Type field to ID_RFC822_ADDR. 774 The above list of identities is not exhaustive. 776 In the IKE_AUTH exchange, the mobile node includes the home address 777 and the appropriate selectors in the TSi (Traffic Selector-initiator) 778 payload to negotiate IPsec security associations for protecting the 779 Binding Update and Binding Acknowledgement messages. The mobile node 780 MAY use a range of selectors that includes the mobility message types 781 for Binding Update and Binding Acknowledgement to use the same pair 782 of IPsec security association for both messages. 784 After the IKE_AUTH exchange completes, the mobile node initiates 785 CREATE_CHILD_SA exchanges to negotiate additional security 786 associations for protecting Return Routability signaling, Mobile 787 Prefix Discovery messages and optionally payload traffic. The 788 CREATE_CHILD_SA exchanges are protected by the security association 789 created during the IKE_AUTH exchange. If a correspondent node, that 790 is also a mobile node, initiates the return routability exchange, 791 then the home agent initiates the CREATE_CHILD_SA exchange to 792 negotiate security associations for protecting Return Routabilty 793 messages. 795 It is important that the security associations are created based on 796 the home address of the mobile node, so that the security 797 associations survive care-of address change. The mobile node MUST 798 use its home address as the initiator IP address in the TSi payload 799 in the CREATE_CHILD_SA exchange in order to create the security 800 associations for the home address. 802 Mobile Node Home Agent 803 ----------- ---------- 804 HDR, SK {[N], SA, Ni, [KEi], 805 [TSi, TSr]} --> 807 <-- HDR, SK {SA, Nr, [KEr], 808 [TSi, TSr]} 810 When PKI based authentication is used between the mobile node and the 811 Home Agent, the identity presented by the mobile node in the IDi 812 payload must correspond to the identity in the certificate obtained 813 by the Home Agent. The home agent uses the identity presented in the 814 IDi payload to lookup the policy and the certificate that corresponds 815 to the mobile node. If the mobile node presents its home address in 816 the IDi payload, then the home agent MUST verify that the home 817 address matches the address in the iPAddress field in the 818 SubjectAltName extension [8]. 820 When the mobile node uses its home address in the IDi field, 821 implementations are required to match the source address in the 822 outermost IP header with the IP address in the IDi field [8]. This 823 verification step, however, should be configurable [8]. With Mobile 824 IPv6, this verification step will always fail because the source 825 address in the IP header is the care-of address and the IP address in 826 the IDi field is the home address. Therefore, this verification step 827 MUST be disabled. 829 7.3. Movements and Dynamic Keying 831 If the mobile node moves and its care-of address changes, the IKEv2 832 SA might not be valid. RFC 3775 defines a mechanism based on the 833 successful exchange of Binding Update and Binding Acknowledgement 834 messages. The mobile node establishes the IKE SA with the home agent 835 using its primary care-of address. The IKE SA endpoints are updated 836 on the home agent when it receives the Binding Update from the mobile 837 node's new care-of address and on the mobile node when it sends the 838 Binding Update to the home agent or when it receives the Binding 839 acknowledgement sent by the home agent. This capability to change 840 IKE endpoints is indicated through setting the Key Management 841 Capability (K) flag [2] in the Binding Update and Binding 842 Acknowledgement messages. If the mobile node or the home agent does 843 not support this capability, and has no other means to update the 844 addresses, then an IKEv2 exchange MUST be initiated to re-establish a 845 new IKE SA. 847 8. The use of EAP authentication 849 In addition to using public key signatures and shared secrets, EAP 850 [10] can be used with IKEv2 for authenticating the mobile node to the 851 home agent. 853 The mobile node indicates that it wants to use EAP by including the 854 IDi payload but leaving out the AUTH payload in the first message 855 during the IKE_AUTH exchange. The home agent then includes an EAP 856 payload if it is willing to use an extensible authentication method. 857 Security associations are not created until the subsequent IKE_AUTH 858 exchange after successful EAP authentication. The use of EAP adds at 859 least two round trips to the IKE negotiation. 861 Mobile Node Home Agent 862 ------------ ---------- 863 HDR, SAi1, KEi, Ni --> 865 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 867 HDR, SK {IDi, [CERTREQ,] [IDr,] 868 SAi2, TSi, TSr}--> 870 <-- HDR, SK {IDr, [CERT,] AUTH, 871 EAP } 873 HDR, SK {EAP} --> 875 <-- HDR, SK {EAP (success)} 877 HDR, SK {AUTH} --> 879 <-- HDR, SK {AUTH, SAr2, TSi, 880 TSr} 882 When EAP is used, the identity presented by the mobile node in the 883 IDi field may not be the actual identity of the mobile node. It 884 could be set to an identity that is used only for AAA routing 885 purposes and selecting the right EAP method. The actual identity is 886 carried inside EAP payloads that is not visible to the home agent. 887 The home agent MUST acquire the mobile node's identity from the 888 corresponding AAA server. More details can be found in [13]. 890 Some EAP methods generate a shared key on the mobile node and the 891 Home Agent once the EAP authentication succeeds. In this case, the 892 shared key is used to generate the AUTH payloads in the subsequent 893 messages. The shared key, if used to generate the AUTH payloads, 894 MUST NOT be used for any other purpose. For more details, refer to 895 [4]. 897 The use of EAP between the mobile node and the home agent might 898 require the home agent to contact an authorization server like the 899 AAA Home server, on the home link, to authenticate the mobile node. 900 Please refer to [7] for more details. 902 9. Dynamic Home Address Configuration 904 The mobile node can dynamically configure a home address by including 905 a Configuration Payload in the IKE_AUTH exchange, with a request for 906 an address from the home link. The mobile node should include a 907 zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST 908 Payload. The mobile node MAY include multiple instances of the 909 INTERNAL_IP6_ADDRESS to request multiple home address to the assigned 910 by the home agent. 912 When the home agent receives a configuration payload with a 913 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home 914 address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in 915 the CFG_REPLY contains the prefix length of the home prefix in 916 addition to a 128 bit home address. The home agent could use a local 917 database or contact a DHCPv6 server on the home link to allocate a 918 home address. The Home Agent should also include an 919 INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the 920 duration for which the dynamically allocated home address is valid. 922 Mobile Node Home Agent 923 ----------- ---------- 924 HDR, SK {IDi, [CERT,] [CERTREQ,] 925 [IDr,] AUTH, CP(CFG_REQUEST), 926 SAi2, TSi, TSr} 927 --> 929 <-- HDR, SK {IDr, [CERT,] AUTH, 930 CP(CFG_REPLY), SAr2, 931 TSi, TSr} 933 The mobile node could suggest a home address that it wants to use in 934 the CFG_REQUEST. For example, this could be a home address that it 935 was allocated before or could be an address the mobile node auto- 936 configured from the IPv6 prefix on the home link. The Home Agent 937 could let the mobile node use the same home address by setting the 938 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same 939 home address. If the home agent wants the mobile node to use a 940 different home address, it sends a new home address in the 941 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile 942 Node MUST stop using its old home address and start using the newly 943 allocated home address. 945 In case the home agent is unable to allocate a home address for the 946 mobile node during the IKE_AUTH exchange, it MUST send a Notify 947 Payload with an INTERNAL_ADDRESS_FAILURE message. 949 If the mobile node wants to configure a DNS server from the home link 950 it can request for the DNS server information by including an 951 INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. 953 10. Security Considerations 955 This document describes how IPsec can be used to secure Mobile IPv6 956 signaling messages. Please refer to RFC 3775 for security 957 considerations related to the use of IPsec with Mobile IPv6. 959 A misbehaving mobile node could create IPsec security associations 960 for a home address that belongs to another mobile node. Therefore, 961 the home agent should check if a particular mobile node is authorized 962 to use a home address before creating IPsec security associations for 963 the home address. If the home address is assigned as described in 964 Section 9, the home agent MUST associate the home address with the 965 identity used in IKE negotiation. The home agent MAY store the 966 assigned home address in the SPD entries created for the mobile node. 968 The use of EAP for authenticating the mobile node to the home agent 969 is described in Section 8. Security considerations related to the 970 use of EAP with IKEv2 are described in [4]. 972 11. IANA Considerations 974 This document requires no action from IANA. 976 12. Acknowledgements 978 The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari 979 Arkko, Gerardo Giaretta and Shinta Sugimoto for reviewing the draft. 981 Many of the requirements listed in Section 4 are copied from RFC 982 3776. Therefore, the authors of RFC 3776 are acknowledged. 984 13. References 986 13.1. Normative References 988 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 989 Levels", BCP 14, RFC 2119, March 1997. 991 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 992 IPv6", RFC 3775, June 2004. 994 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 995 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 996 Agents", RFC 3776, June 2004. 998 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 999 December 2005. 1001 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 1002 Protocol", RFC 4301, December 2005. 1004 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1005 December 2005. 1007 13.2. Informative References 1009 [7] Giaretta, G., "AAA Goals for Mobile IPv6", 1010 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1011 September 2006. 1013 [8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 1014 ISAKMP, IKEv2, and PKIX", 1015 draft-ietf-pki4ipsec-ikecert-profile-11 (work in progress), 1016 September 2006. 1018 [9] Crocker, D., "Standard for the format of ARPA Internet text 1019 messages", STD 11, RFC 822, August 1982. 1021 [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1022 Levkowetz, "Extensible Authentication Protocol (EAP)", 1023 RFC 3748, June 2004. 1025 [11] Kent, S. and R. Atkinson, "Security Architecture for the 1026 Internet Protocol", RFC 2401, November 1998. 1028 [12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile 1029 IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-03 (work 1030 in progress), September 2006. 1032 [13] Hoffman, P. and P. Eronen, "IKEv2 Clarifications and 1033 Implementation Guidelines", 1034 draft-eronen-ipsec-ikev2-clarifications-09 (work in progress), 1035 May 2006. 1037 Authors' Addresses 1039 Vijay Devarapalli 1040 Azaire Networks 1041 4800 Great America Pkwy 1042 Santa Clara, CA 95054 1043 USA 1045 Email: vijay.devarapalli@azairenet.com 1047 Francis Dupont 1048 CELAR 1050 Email: Francis.Dupont@point6.net 1052 Full Copyright Statement 1054 Copyright (C) The Internet Society (2006). 1056 This document is subject to the rights, licenses and restrictions 1057 contained in BCP 78, and except as set forth therein, the authors 1058 retain all their rights. 1060 This document and the information contained herein are provided on an 1061 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1062 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1063 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1064 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1065 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1066 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1068 Intellectual Property 1070 The IETF takes no position regarding the validity or scope of any 1071 Intellectual Property Rights or other rights that might be claimed to 1072 pertain to the implementation or use of the technology described in 1073 this document or the extent to which any license under such rights 1074 might or might not be available; nor does it represent that it has 1075 made any independent effort to identify any such rights. Information 1076 on the procedures with respect to rights in RFC documents can be 1077 found in BCP 78 and BCP 79. 1079 Copies of IPR disclosures made to the IETF Secretariat and any 1080 assurances of licenses to be made available, or the result of an 1081 attempt made to obtain a general license or permission for the use of 1082 such proprietary rights by implementers or users of this 1083 specification can be obtained from the IETF on-line IPR repository at 1084 http://www.ietf.org/ipr. 1086 The IETF invites any interested party to bring to its attention any 1087 copyrights, patents or patent applications, or other proprietary 1088 rights that may cover technology that may be required to implement 1089 this standard. Please address the information to the IETF at 1090 ietf-ipr@ietf.org. 1092 Acknowledgment 1094 Funding for the RFC Editor function is provided by the IETF 1095 Administrative Support Activity (IASA).