idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-06.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 1063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1053. ** 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 : ---------------------------------------------------------------------------- -- 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 (April 12, 2006) is 6587 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 859 -- Looks like a reference, but probably isn't: 'N' on line 799 -- Looks like a reference, but probably isn't: 'KEi' on line 799 -- Looks like a reference, but probably isn't: 'KEr' on line 802 ** 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-08 -- 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-02 Summary: 5 errors (**), 0 flaws (~~), 4 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 Expires: October 14, 2006 CELAR 6 April 12, 2006 8 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 9 draft-ietf-mip6-ikev2-ipsec-06.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 October 14, 2006. 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 . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 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 4. Requirements 159 This section describes mandatory rules and requirements for all 160 Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as 161 the key negotiation protocol, can be used to protect traffic between 162 the mobile node and the home agent. Many of the requirements are 163 repeated from RFC 3776 to make this document self-contained and 164 complete. 166 4.1. General Requirements 168 o RFC 3775 states that manual configuration of IPsec security 169 associations MUST be supported and automated key management MAY be 170 supported. This document does not make any recommendations 171 regarding the support of manual IPsec configuration and dynamic 172 IPsec configuration. This document just describes the use of 173 manually created IPsec security associations and the use of IKEv2 174 as the automated IPsec key management protocol for protecting 175 Mobile IPv6 signaling messages. 177 o ESP encapsulation for Binding Updates and Binding Acknowledgements 178 MUST be supported and used. 180 o ESP encapsulation in tunnel mode for the Home Test Init and Home 181 Test messages tunneled between the mobile node and the home agent 182 MUST be supported and SHOULD be used. 184 o ESP encapsulation of the ICMPv6 messages related to mobile prefix 185 discovery MUST be supported and SHOULD be used. 187 o ESP encapsulation of the payload packets tunneled between the 188 mobile node and the home agent MAY be supported and used. 190 o If multicast group membership control protocols or stateful 191 address autoconfiguration protocols are supported, payload data 192 protection MUST be supported for those protocols. 194 o The home agent and the mobile node MAY support authentication 195 using EAP in IKEv2 as described in Section 8. 197 o The home agent and the mobile node MAY support remote 198 configuration of home address as described in Section 9. When the 199 home agent receives a configuration payload with a CFG_REQUEST for 200 INTERNAL_IP6_ADDR, it must reply with a valid home address for the 201 mobile node. The home agent can pick a home address from a local 202 database or from a DHCPv6 server on the home link. 204 4.2. Policy Requirements 206 The following requirements are related to the configuration of 207 security policy database on the home agent and the mobile node. 209 o RFC 3776 required configuration of the security policies per 210 interface in order to be able to differentiate between mobility 211 header messages sent to the home agent and tunneled through the 212 home agent to the correspondent node. Since the Mobility Header 213 message type is a selector, it is now easy to differentiate 214 between HoTi and HoT messages from other mobility header messages. 215 Therefore per-interface configuration of security policies is not 216 required. 218 o The home agent MUST be able to prevent a mobile node from using 219 its security association to send a Binding Update on behalf of 220 another mobile node. With manual IPsec configuration, the home 221 agent MUST be able to verify that a security association was 222 created for a particular home address. With dynamic keying, it 223 should be possible for the home agent to verify that the identity 224 presented in the IKE_AUTH exchange is allowed to create security 225 associations for a particular home address. 227 o The home agent MAY use the Peer Authorization Database (PAD) [5] 228 to store per-mobile node state. The PAD entry for a mobile node 229 can contain a shared key, public key or a trust anchor to verify 230 the mobile node's certificate for authenticating the mobile node. 232 o As required in the base specification [2], when a packet destined 233 to the receiving node is matched against IPsec security policy or 234 selectors of a security association, an address appearing in a 235 Home Address destination option is considered as the source 236 address of the packet. 238 Note that the home address option appears before IPsec headers. 239 Section 11.3.2 of the base specification describes one possible 240 implementation approach for this: The IPsec policy operations can 241 be performed at the time when the packet has not yet been modified 242 per Mobile IPv6 rules, or has been brought back to its normal form 243 after Mobile IPv6 processing. That is, the processing of the Home 244 Address option is seen as a fixed transformation of the packets 245 that does not affect IPsec processing. 247 o Similarly, a home address within a Type 2 Routing header destined 248 to the receiving node is considered as the destination address of 249 the packet, when a packet is matched against IPsec security policy 250 or selectors of a security association. 252 Similar implementation considerations apply to the Routing header 253 processing as was described above for the Home Address destination 254 option. 256 o When the mobile node returns home and de-registers with the Home 257 Agent, the tunnel between the home agent and the mobile node's 258 care-of address is torn down. The security policy entries, which 259 were used for protecting tunneled traffic between the mobile node 260 and the home agent MUST be made inactive (for instance, by 261 removing them and installing them back later through an API). The 262 corresponding security associations could be kept as they are or 263 deleted depending on how they were created. If the security 264 associations were created dynamically using IKE, they are 265 automatically deleted when they expire. If the security 266 associations were created through manual configuration, they MUST 267 be retained and used later when the mobile node moves away from 268 home again. The security associations protecting Binding Updates 269 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 270 as they do not depend on care-of addresses and can be used again. 272 o The mobile node MUST use the Home Address destination option in 273 Binding Updates and Mobile Prefix Solicitations, sent to the home 274 agent from a care-of address, so that the home address is visible 275 when the IPsec policy checks are made. 277 o The home agent MUST use the Type 2 Routing header in Binding 278 Acknowledgements and Mobile Prefix Advertisements sent to the 279 mobile node, again due to the need to have the home address 280 visible when the policy checks are made. 282 4.3. IPsec Protocol Processing Requirements 284 The following lists requirements for IPsec processing at the Home 285 Agent and the mobile node. 287 o The home agent and mobile node SHOULD support Mobility Header 288 message type as an IPsec selector. 290 o The home agent and mobile node SHOULD support ICMPv6 message type 291 as an IPsec selector. 293 o The home agent MUST be able to distinguish between HoTi messages 294 sent to itself, when it is acting as a Correspondent Node, from 295 those sent to Correspondent Nodes when it is acting as a home 296 agent, based on the destination address of the packet. 298 o When securing Binding Updates, Binding Acknowledgements, and 299 prefix discovery, both the mobile nodes and the home agents MUST 300 support and SHOULD use the Encapsulating Security Payload (ESP) 301 [6] header in transport mode and MUST use a non-null payload 302 authentication algorithm to provide data origin authentication, 303 connectionless integrity and optional anti-replay protection. 305 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 306 protection of packets belonging to the return routability 307 procedure. A non-null encryption transform and a non-null 308 authentication algorithm MUST be applied. 310 o When ESP is used to protect Binding Updates, there is no 311 protection for the care-of address that appears in the IPv6 header 312 outside the area protected by ESP. It is important for the home 313 agent to verify that the care-of address has not been tampered 314 with. As a result, the attacker would have redirected the mobile 315 node's traffic to another address. In order to prevent this, 316 Mobile IPv6 implementations MUST use the Alternate Care-of Address 317 mobility option in Binding Updates sent by mobile nodes while away 318 from home. The exception to this is when the mobile node returns 319 home and sends a Binding Update to the home agent in order to de- 320 register. 322 When IPsec is used to protect return routability signaling or 323 payload packets, the mobile node MUST set the source address it 324 uses for the outgoing tunnel packets to the current primary care- 325 of address. 327 o When IPsec is used to protect return routability signaling or 328 payload packets, IPsec security associations are needed to provide 329 this protection. When the care-of address for the mobile node 330 changes as a result of an accepted Binding Update, special 331 treatment is needed for the next packets sent using these security 332 associations. The home agent MUST set the new care-of address as 333 the destination address of these packets, as if the outer header 334 destination address in the security association had changed. 335 Similarly, the home agent starts to expect the new source address 336 in the tunnel packets received from the mobile node. 338 Such address changes can be implemented, for instance, through an 339 API from the Mobile IPv6 implementation to the IPsec 340 implementation. One such API is described in [12]. It should be 341 noted that the use of such an API and the address changes MUST 342 only be done based on the Binding Updates received by the home 343 agent and protected by the use of IPsec. Address modifications 344 based on other sources, such as Binding Updates to the 345 correspondent nodes protected by return routability, or open 346 access to an API from any application may result in security 347 vulnerabilities. 349 4.4. Dynamic Keying Requirements 351 The following requirements are related to the use of a dynamic key 352 management protocol by the mobile node and the home agent. 353 Section 7.2 describes the use of IKEv2 as the dynamic key management 354 protocol. 356 o The mobile node MUST use its care-of address as source address in 357 protocol exchanges, when using dynamic keying. 359 o The mobile node and the home agent MUST create security 360 associations based on the home address, so that the security 361 associations survive change in care-of address. When using IKEv2 362 as the key exchange protocol, the home address should be carried 363 as the initiator IP address in the TSi payload during the 364 CREATE_CHILD_SA exchange [4]. 366 o If the mobile node has used IKEv2 to establish security 367 associations with its home agent, it should follow the procedures 368 discussed in Section 11.7.1 and 11.7.3 of the base specification 369 [2] to determine whether the IKE endpoints can be moved or if the 370 IKE SA has to be re-established. 372 o If the home agent has used IKEv2 to establish security 373 associations with the mobile node, it should follow the procedures 374 discussed in Section 10.3.1 and 10.3.2 of the base specification 375 [2] to determine whether the IKE endpoints can be moved or if the 376 IKE SA has to be re-established. 378 5. Selector Granularity Considerations 380 IPsec implementations are compatible with this document even if they 381 do not support fine grain selectors such as the Mobility Header 382 message type and ICMPv6 message type. For various reasons, some 383 implementations may choose to support only coarse grain selectors 384 (i.e., addresses and in some cases the protocol field) for forwarded 385 traffic. As finer grain selectors give better control, i.e., the 386 protection is only applied when required, the examples in the 387 document always use the finest granularity. 389 The following describes different ways of setting up IPsec policies 390 for protecting Mobile IPv6 messages: 392 o The IPsec implementations on the mobile node and the home agent 393 support fine grain selectors, including the Mobility Header 394 message type. This is the case assumed in the IPsec SPD and SAD 395 examples in this document. 397 o The IPsec implementations only support selectors at a protocol 398 level. In such implementations, the IPsec implementation can only 399 identify mobility header traffic and cannot identify the 400 individual mobility header messages. In this case, the protection 401 of Return Routability Messages uses a setup similar to the regular 402 payload packets to the correspondent node with the protocol 403 selector set to Mobility Header messages. All tunneled Mobility 404 Header messages will be protected. 406 o The third case is where the protocol selector is not available in 407 the IPsec implementation. In this case all traffic sent by the 408 mobile node reverse tunneled through the home agent is protected 409 using ESP in tunnel mode. This case is also applicable when the 410 mobile node, due to privacy considerations tunnels all traffic to 411 the home agent. This includes Mobile IPv6 signaling messages 412 exchanged between the mobile node and the home agent and all 413 traffic exchanged between the mobile node and the correspondent 414 node. This case uses IPsec tunnel mode SA with the protocol 415 selector set to 'any'. 417 The third case where all tunneled traffic is protected introduces 418 some additional considerations: 420 o If there is just one IPsec SA providing protection for all 421 traffic, then the SA MUST fulfill the requirements for protecting 422 the Return Routability messages which require confidentiality 423 protection. If the third case is being used for privacy 424 considerations, then there can also be separate tunnel mode SPD 425 entries for protecting the Return Routability messages with a 426 higher priority. 428 o The receipt of a Binding Update from the new care-of address 429 updates the tunnel end point of the IPsec SA as described in 430 Section 4.3. Since the Binding Update that updates the tunnel end 431 point is received through the same tunnel interface that needs to 432 be updated, special care should be taken on the home agent to 433 ensure that the Binding Update is not dropped. This can be 434 achieved by either performing the source address check on the 435 outer IPv6 header after the binding update is processed or have 436 exception handling to check the inner packet for a Binding Update 437 when the source address match on the outer source address fails. 438 Typical IPsec processing does not check the outer source address. 440 6. Manual Configuration 442 This section describes the SPD and SAD entries that can be used to 443 protect Mobile IPv6 signaling messages. The SPD and SAD entries are 444 only example configurations. A particular mobile node implementation 445 and a home agent implementation could configure different SPD and SAD 446 entries as long as they provide the required security of the Mobile 447 IPv6 signaling messages. 449 For the examples described in this document, a mobile node with home 450 address, "home_address_1", primary care-of address, 451 "care_of_address_1", a home agent with address, "home_agent_1" and a 452 user of the mobile node with identity "user_1" are assumed. If the 453 home address of the mobile node changes, the SPD and SAD entries need 454 to be re-created or updated for the new home address. 456 6.1. Binding Updates and Acknowledgements 458 The following are the SPD and SAD entries on the mobile node and the 459 home agent to protect Binding Updates and Acknowledgements. 461 mobile node SPD-S: 462 - IF source = home_address_1 & destination = home_agent_1 & 463 proto = MH & local_mh_type =BU & remote_mh_type = 464 BAck 465 Then use SA SA1 (OUT) and SA2 (IN) 467 mobile node SAD: 468 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 469 source = home_address_1 & destination = home_agent_1 & 470 proto = MH & mh_type = BU 471 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 472 source = home_agent_1 & destination = home_address_1 & 473 proto = MH & mh_type = BAck 475 home agent SPD-S: 476 - IF source = home_agent_1 & destination = home_address_1 & 477 proto = MH & local_mh_type = BAck & remote_mh_type 478 = BU 479 Then use SA SA2 (OUT) and SA1 (IN) 481 home agent SAD: 482 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 483 source = home_agent_1 & destination = home_address_1 & 484 proto = MH & mh_type = BAck 485 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 486 source = home_address_1 & destination = home_agent_1 & 487 proto = MH & mh_type = BU 489 6.2. Return Routabililty Messages 491 The following are the SPD and SAD entries on the mobile node and the 492 home agent to protect Return Routability messages. 494 mobile node SPD-S: 495 - IF source = home_address_1 & destination = any & 496 proto = MH & local_mh_type = HoTi & remote_mh_type = HoT 497 Then use SA SA3 (OUT) and SA4 (IN) 499 mobile node SAD: 500 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 501 source = home_address_1 & destination = any & proto = MH & 502 mh_type = HoTi 503 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 504 source = any & destination = home_address_1 & proto = MH & 505 mh_type = HoT 507 home agent SPD-S: 508 - IF destination = home_address_1 & source = any & 509 proto = MH & local_mh_type = HoT & remote_mh_type = 510 HoTi 511 Then use SA SA4 (OUT) and SA3 (IN) 513 home agent SAD: 514 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 515 source = any & destination = home_address_1 & proto = MH & 516 mh_type = HoT 517 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 518 source = home_address_1 & destination = any & proto = MH & 519 mh_type = HoTi 521 6.3. Mobile Prefix Discovery Messages 523 The following are the SPD and SAD entries used to protect Mobile 524 Prefix Discovery messages. 526 mobile node SPD-S: 527 - IF source = home_address_1 & destination = home_agent_1 & 528 proto = ICMPv6 & local_icmp6_type = MPS & 529 remote_icmp6_type = MPA 530 Then use SA SA5 (OUT) and SA6 (IN) 532 mobile node SAD: 533 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 534 source = home_address_1 & destination = home_agent_1 & 535 proto = ICMPv6 & icmp6_type = MPS 536 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 537 source = home_agent_1 & destination = home_address_1 & 538 proto = ICMPv6 & icmp6_type = MPA 540 home agent SPD-S: 541 - IF source = home_agent_1 & destination = home_address_1 & 542 proto = ICMPv6 & local_icmp6_type = MPA & 543 remote_icmp6_type = MPS 544 Then use SA SA6 (OUT) and SA5 (IN) 546 home agent SAD: 547 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 548 source = home_agent_1 & destination = home_address_1 & 549 proto = ICMPv6 & icmp6_type = MPA 550 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 551 source = home_address_1 & destination = home_agent_1 & 552 proto = ICMPv6 & icmp6_type = MPS 554 6.4. Payload Packets 556 Regular payload traffic between the mobile node and the correspondent 557 node tunneled through the home agent can be protected by IPsec, if 558 required. The mobile node and the home agent use ESP in tunnel mode 559 to protect the tunneled traffic. The SPD and SAD entries shown in 560 Section 5.2.4 of [3] are applicable here. 562 7. Dynamic Configuration 564 This section describes the use of IKEv2 to setup the required 565 security associations. 567 7.1. Security Policy Database Entries 569 The following sections describe the security policy entries on the 570 mobile node and the home agent. The SPD entries are only example 571 configurations. A particular mobile node implementation and a Home 572 Agent implementation could configure different SPD entries as long as 573 they provide the required security of the Mobile IPv6 signaling 574 messages. 576 In the examples shown below, the identity of the user of the mobile 577 node is assumed to be user_1, the home address of the mobile node is 578 assumed to be home_address_1, he primary care-of address of the 579 mobile node is assumed to be care_of_address_1 and the IPv6 address 580 of the Home Agent is assumed to be home_agent_1. 582 7.1.1. Binding Updates and Acknowledgements 584 The following are the SPD entries on the mobile node and the home 585 agent for protecting Binding Updates and Acknowledgements. 587 mobile node SPD-S: 588 - IF source = home_address_1 & destination = home_agent_1 & 589 proto = MH & local_mh_type = BU & remote_mh_type = BAck 590 Then use SA ESP transport mode 591 IDi = user_1, IDr = home_agent_1, 592 TSi = home_address_1, MH, BU 593 TSr = home_agent_1, MH, BAck 595 home agent SPD-S: 596 - IF source = home_agent_1 & destination = home_address_1 & 597 proto = MH & local_mh_type = BAck & remote_mh_type = BU 598 Then use SA ESP transport mode 599 IDi = home_agent_1, IDr = user_1 600 TSi = home_agent_1, MH, BAck 601 TSr = home_address_1, MH, BU 603 In the examples shown above, the home address of the mobile node 604 might not be available all the time. For instance, the mobile node 605 might have not configured a home address yet. When the mobile node 606 acquires a new home address, it must either add the address to the 607 corresponding SPD entries or create the SPD entries for the home 608 address. 610 The home agent should have named SPD entries per mobile node, based 611 on the identity of the mobile node. The identity of the mobile node 612 is stored in the "Name" selector in the SPD [5]. The home address 613 presented by the mobile node during the IKE negotiation is stored as 614 the remote IP address in the resultant IPsec security associations. 615 The home agent MAY also have generic SPD entries to prevent mobility 616 header traffic that requires IPsec protection from bypassing the 617 IPsec filters. 619 The Mobility Header message type is negotiated by placing it in the 620 most significant eight bits of the 16 bit local "port" selector 621 during IKEv2 exchange. For more details, refer to [5]. The TSi and 622 TSr payloads in the above examples will contain many other selectors 623 apart from home_address_1. For the sake of brevity, we show only 624 those values that are relevant for Mobile IPv6. 626 7.1.2. Return Routability Messages 628 The following are the SPD entries on the mobile node and the home 629 agent for protecting the Return Routability messages. 631 mobile node SPD-S: 632 - IF source = home_address_1 & destination = any & 633 proto = MH & local_mh_type = HoTi & 634 remote_mh_type = HoT 635 Then use SA ESP tunnel mode 636 IDi = user_1, IDr = home_agent_1, 637 TSi = home_address_1, MH, HoTi 638 TSr = any, MH, HoT 639 outer src addr = care_of_address_1, 640 outer dst addr = home_agent_1, 641 inner src addr = home_address_1 643 home agent SPD-S: 644 - IF source = any & destination = home_address_1 & 645 proto = MH & local_mh_type = HoT & 646 remote_mh_type = HoTi 647 Then use SA ESP tunnel mode 648 IDi = home_agent_1, IDr = user_1 649 TSi = any, MH, HoT 650 TSr = home_address_1, MH, HoTi 651 outer src addr = home_agent_1, 652 outer dst addr = care_of_address_1, 653 inner dst addr = home_address_1 655 When the mobile node's care-of address changes the SPD entries on 656 both the mobile node and the home agent must be updated. The home 657 agent knows about the change in care-of address of the mobile node 658 when it receives a Binding Update from the mobile node. 660 7.1.3. Mobile Prefix Discovery Messages 662 The following are the SPD entries on the mobile node and the home 663 agent for protecting Mobile Prefix Discovery messages. 665 mobile node SPD-S: 666 - IF source = home_address_1 & destination = home_agent_1 & 667 proto = ICMPv6 & local_mh_type = MPS & 668 remote_mh_type = MPA 669 Then use SA ESP transport mode 670 IDi = user_1, IDr = home_agent_1, 671 TSi = home_address_1, ICMPv6, MPS 672 TSr = home_agent_1, ICMPv6, MPA 674 home agent SPD-S: 675 - IF source = home_agent_1 & destination = home_address_1 & 676 proto = ICMPv6 & local_mh_type = MPA & 677 remote_mh_type = MPS 678 Then use SA ESP transport mode 679 IDi = home_agent_1, IDr = user_1 680 TSi = home_agent_1, ICMPv6, MPA 681 TSr = home_address_1, ICMPv6, MPS 683 In the examples shown above, the home address of the mobile node 684 might not be available all the time. When the mobile node acquires a 685 new home address, it must add the address to the corresponding SPD 686 entries. 688 The TSi and TSr payloads in the above examples will contain many 689 other selectors apart from home_address_1. For brevity, they are not 690 show here. 692 7.1.4. Payload Packets 694 The following are the SPD entries on the mobile node and the home 695 agent if payload traffic exchanged between the mobile node and its 696 Correspondent Node needs to be protected. The SPD entries are 697 similar to the entries for protecting Return Routability messages and 698 have lower priority than the above SPD entries. 700 mobile node SPD-S: 701 - IF interface = IPv6 tunnel to home_agent_1 & proto = X 702 Then use SA ESP tunnel mode 703 IDi = user_1, IDr = home_agent_1, 704 TSi = home_address_1, X, port 705 TSr = any, X, port 706 outer src addr = care_of_address_1 707 outer dst addr = home_agent_1, 708 inner src addr = home_address_1 710 home agent SPD-S: 711 - IF interface = IPv6 tunnel to home_address_1 & proto = X 712 Then use SA ESP tunnel mode 713 IDi = home_agent_1, IDr = user_1, 714 TSi = any, X, port 715 TSr = home_address_1, X, port 716 outer src addr = home_agent_1, 717 outer dst addr = care_of_address_1, 718 inner dst addr = home_address_1 720 7.2. Security Association negotiation using IKEv2 722 Mobile IPv6 signaling messages are typically initiated by the mobile 723 node. The mobile node sends a Binding Update to the home agent 724 whenever it moves and acquires a new care-of address. 726 The mobile node initiates an IKEv2 protocol exchange if the required 727 security associations are not present. A possible mechanism used for 728 mutual authentication is a shared secret between the mobile node and 729 the home agent. The home agent uses the identity of the mobile node 730 to identify the corresponding shared secret. When a public key based 731 mechanism is available, it should be the preferred mechanism for 732 mutual authentication: private keys are used to generate the AUTH 733 payload and identities are verified with certificate information 734 transmitted by CERT payloads. If the mobile node is configured with 735 the home agent information including the public key that corresponds 736 to the home agent, then the mobile node MAY exclude the CERTREQ 737 payload in its IKE_AUTH third message. Similarly, the home agent MAY 738 exclude the CERTREQ payload in its IKE_SA_INIT second message if it 739 is configured with the mobile node information. 741 If a shared secret is being used, the mobile node uses the shared 742 secret to generate the AUTH payload in the IKE_AUTH exchange. If the 743 mobile node is using a public key based mechanism, then it uses its 744 private key to generate the AUTH payload in the IKE_AUTH exchange. 746 Mobile Node Home Agent 747 ----------- ---------- 748 HDR, SAi1, KEi, Ni --> 750 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 752 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 753 AUTH, SAi2, TSi, TSr} 754 --> 756 <-- HDR, SK {IDr, [CERT,] AUTH, 757 SAr2, TSi, TSr} 759 The mobile node should always include its identity in the IDi payload 760 in the IKE_AUTH exchange. The mobile node could use the following 761 different types of identities to identity itself to the home agent. 763 o Home Address - The mobile node could use its statically configured 764 home address as its identity. In this case the ID Type field is 765 set to ID_IPV6_ADDR. 766 o FQDN - The mobile node can use a Fully Qualified Domain Name as 767 the identifier and set the ID Type field to ID_FQDN. 768 o RFC 822 identifier - If the mobile node uses a RFC 822 identifier 769 [9], it sets the ID Type field to ID_RFC822_ADDR. 771 In the IKE_AUTH exchange, the mobile node includes the home address 772 and the appropriate selectors in the TSi (Traffic Selector-initiator) 773 payload to negotiate IPsec security associations for protecting the 774 Binding Update and Binding Acknowledgement messages. The mobile node 775 MAY use a range of selectors that includes the mobility message types 776 for Binding Update and Binding Acknowledgement to use the same pair 777 of IPsec security association for both messages. 779 After the IKE_AUTH exchange completes, the mobile node initiates 780 CREATE_CHILD_SA exchanges to negotiate additional security 781 associations for protecting Return Routability signaling, Mobile 782 Prefix Discovery messages and optionally payload traffic. The 783 CREATE_CHILD_SA exchanges are protected by the security association 784 created during the IKE_AUTH exchange. If a correspondent node, that 785 is also a mobile node, initiates the return routability exchange, 786 then the home agent initiates the CREATE_CHILD_SA exchange to 787 negotiate security associations for protecting Return Routabilty 788 messages. 790 It is important that the security associations are created based on 791 the home address of the mobile node, so that the security 792 associations survive care-of address change. The mobile node MUST 793 use its home address as the initiator IP address in the TSi payload 794 in the CREATE_CHILD_SA exchange in order to create the security 795 associations for the home address. 797 Mobile Node Home Agent 798 ----------- ---------- 799 HDR, SK {[N], SA, Ni, [KEi], 800 [TSi, TSr]} --> 802 <-- HDR, SK {SA, Nr, [KEr], 803 [TSi, TSr]} 805 When PKI based authentication is used between the mobile node and the 806 Home Agent, the identity presented by the mobile node in the IDi 807 payload must correspond to the identity in the certificate obtained 808 by the Home Agent. The home agent uses the identity presented in the 809 IDi payload to lookup the policy and the certificate that corresponds 810 to the mobile node. If the mobile node presents its home address in 811 the IDi payload, then the home agent MUST verify that the home 812 address matches the address in the iPAddress field in the 813 SubjectAltName extension [8]. 815 When the mobile node uses its home address in the IDi field, 816 implementations are required to match the source address in the outer 817 most IP header with the IP address in the IDi field [8]. This 818 verification step, however, should be configurable [8]. With Mobile 819 IPv6, this verification step will always fail because the source 820 address in the IP header is the care-of address and the IP address in 821 the IDi field is the home address. Therefore, this verification step 822 MUST be disabled. 824 7.3. Movements and Dynamic Keying 826 If the mobile node moves and its care-of address changes, the IKEv2 827 SA might not be valid. RFC 3775 defines a mechanism based on the 828 successful exchange of Binding Update and Binding Acknowledgement 829 messages. The mobile node establishes the IKE SA with the home agent 830 using its primary care-of address. The IKE SA endpoints are updated 831 on the home agent when it receives the Binding Update from the mobile 832 node's new care-of address and on the mobile node when it sends the 833 Binding Update to the home agent or when it receives the Binding 834 acknowledgement sent by the home agent. This capability to change 835 IKE endpoints is indicated through setting the Key Management 836 Capability (K) flag [2] in the Binding Update and Binding 837 Acknowledgement messages. If the mobile node or the home agent does 838 not support this capability, then an IKEv2 exchange MUST be initiated 839 to re-establish a new IKE SA. 841 8. The use of EAP authentication 843 In addition to using public key signatures and shared secrets, EAP 844 [10] can be used with IKEv2 for authenticating the mobile node to the 845 home agent. 847 The mobile node indicates that it wants to use EAP by including the 848 IDi payload but leaving out the AUTH payload in the first message 849 during the IKE_AUTH exchange. The home agent then includes an EAP 850 payload if it is willing to use an extensible authentication method. 851 Security associations are not created until the subsequent IKE_AUTH 852 exchange after successful EAP authentication. The use of EAP adds at 853 least two round trips to the IKE negotiation. 855 Mobile Node Home Agent 856 ------------ ---------- 857 HDR, SAi1, KEi, Ni --> 859 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 861 HDR, SK {IDi, [CERTREQ,] [IDr,] 862 SAi2, TSi, TSr}--> 864 <-- HDR, SK {IDr, [CERT,] AUTH, 865 EAP } 867 HDR, SK {EAP} --> 869 <-- HDR, SK {EAP (success)} 871 HDR, SK {AUTH} --> 873 <-- HDR, SK {AUTH, SAr2, TSi, 874 TSr} 876 Some EAP methods generate a shared key on the mobile node and the 877 Home Agent once the EAP authentication succeeds. In this case, the 878 shared key is used to generate the AUTH payloads in the subsequent 879 messages. The shared key, if used to generate the AUTH payloads, 880 MUST NOT be used for any other purpose. For more details, refer to 881 [4]. 883 The use of EAP between the mobile node and the home agent might 884 require the home agent to contact an authorization server like the 885 AAA Home server, on the home link, to authenticate the mobile node. 886 Please refer to [7] for more details. 888 9. Dynamic Home Address Configuration 890 The mobile node can dynamically configure a home address by including 891 a Configuration Payload in the IKE_AUTH exchange, with a request for 892 an address from the home link. The mobile node should include an 893 INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The 894 mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it 895 wants to obtain information about the IPv6 prefixes on the home link. 896 If the mobile node wants to configure a DNS server from the home link 897 it can request for the DNS server information by including an 898 INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. 900 When the home agent receives a configuration payload with a 901 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home 902 address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in 903 the CFG_REPLY contains the prefix length of the home prefix in 904 addition to a 128 bit home address. The home agent could use a local 905 database or contact a DHCPv6 server on the home link to allocate a 906 home address. The Home Agent should also include an 907 INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the 908 duration for which the dynamically allocated home address is valid. 910 Mobile Node Home Agent 911 ----------- ---------- 912 HDR, SK {IDi, [CERT,] [CERTREQ,] 913 [IDr,] AUTH, CP(CFG_REQUEST), 914 SAi2, TSi, TSr} 915 --> 917 <-- HDR, SK {IDr, [CERT,] AUTH, 918 CP(CFG_REPLY), SAr2, 919 TSi, TSr} 921 The mobile node could suggest a home address that it wants to use in 922 the CFG_REQUEST. For example, this could be a home address that it 923 was allocated before or could be an address the mobile node auto- 924 configured from the IPv6 prefix on the home link. The Home Agent 925 could let the mobile node use the same home address by setting the 926 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same 927 home address. If the home agent wants the mobile node to use a 928 different home address, it sends a new home address in the 929 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile 930 Node MUST stop using its old home address and start using the newly 931 allocated home address. 933 In case the home agent is unable to allocate a home address for the 934 mobile node during the IKE_AUTH exchange, it MUST send a Notify 935 Payload with an INTERNAL_ADDRESS_FAILURE message. 937 10. Security Considerations 939 This document describes how IPsec can be used to secure Mobile IPv6 940 signaling messages. Please refer to RFC 3775 for security 941 considerations related to the use of IPsec with Mobile IPv6. 943 A misbehaving mobile node could create IPsec security associations 944 for a home address that belongs to another mobile node. Therefore, 945 the home agent should check if a particular mobile node is authorized 946 to use a home address before creating IPsec security associations for 947 the home address. If the home address is assigned as described in 948 Section 9, the home agent MUST associate the home address with the 949 identity used in IKE negotiation. The home agent MAY store the 950 assigned home address in the SPD entries created for the mobile node. 952 The use of EAP for authenticating the mobile node to the home agent 953 is described in Section 8. Security considerations related to the 954 use of EAP with IKEv2 are described in [4]. 956 11. IANA Considerations 958 This document requires no action from IANA. 960 12. Acknowledgements 962 The author would like to thank Mika Joutsenvirta, Pasi Eronen, Jari 963 Arkko, Gerardo Giaretta and Shinta Sugimoto for reviewing the draft. 965 Many of the requirements listed in Section 4 are copied from RFC 966 3776. Therefore, the authors of RFC 3776 are acknowledged. 968 13. References 970 13.1. Normative References 972 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 973 Levels", BCP 14, RFC 2119, March 1997. 975 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 976 IPv6", RFC 3775, June 2004. 978 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 979 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 980 Agents", RFC 3776, June 2004. 982 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 983 December 2005. 985 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 986 Protocol", RFC 4301, December 2005. 988 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 989 December 2005. 991 13.2. Informative References 993 [7] Giaretta, G., "Goals for AAA-HA interface", 994 draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), 995 September 2004. 997 [8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 998 ISAKMP, IKEv2, and PKIX", 999 draft-ietf-pki4ipsec-ikecert-profile-08 (work in progress), 1000 March 2006. 1002 [9] Crocker, D., "Standard for the format of ARPA Internet text 1003 messages", STD 11, RFC 822, August 1982. 1005 [10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1006 Levkowetz, "Extensible Authentication Protocol (EAP)", 1007 RFC 3748, June 2004. 1009 [11] Kent, S. and R. Atkinson, "Security Architecture for the 1010 Internet Protocol", RFC 2401, November 1998. 1012 [12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile 1013 IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-02 (work 1014 in progress), March 2006. 1016 Authors' Addresses 1018 Vijay Devarapalli 1019 Azaire Networks 1020 4800 Great America Pkwy 1021 Santa Clara, CA 95054 1022 USA 1024 Email: vijay.devarapalli@azairenet.com 1026 Francis Dupont 1027 CELAR 1029 Email: Francis.Dupont@point6.net 1031 Intellectual Property Statement 1033 The IETF takes no position regarding the validity or scope of any 1034 Intellectual Property Rights or other rights that might be claimed to 1035 pertain to the implementation or use of the technology described in 1036 this document or the extent to which any license under such rights 1037 might or might not be available; nor does it represent that it has 1038 made any independent effort to identify any such rights. Information 1039 on the procedures with respect to rights in RFC documents can be 1040 found in BCP 78 and BCP 79. 1042 Copies of IPR disclosures made to the IETF Secretariat and any 1043 assurances of licenses to be made available, or the result of an 1044 attempt made to obtain a general license or permission for the use of 1045 such proprietary rights by implementers or users of this 1046 specification can be obtained from the IETF on-line IPR repository at 1047 http://www.ietf.org/ipr. 1049 The IETF invites any interested party to bring to its attention any 1050 copyrights, patents or patent applications, or other proprietary 1051 rights that may cover technology that may be required to implement 1052 this standard. Please address the information to the IETF at 1053 ietf-ipr@ietf.org. 1055 Disclaimer of Validity 1057 This document and the information contained herein are provided on an 1058 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1059 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1060 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1061 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1062 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1063 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1065 Copyright Statement 1067 Copyright (C) The Internet Society (2006). This document is subject 1068 to the rights, licenses and restrictions contained in BCP 78, and 1069 except as set forth therein, the authors retain all their rights. 1071 Acknowledgment 1073 Funding for the RFC Editor function is currently provided by the 1074 Internet Society.