idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...e IPv6 mobile node and home agent MUST...' RFC 2119 keyword, line 216: '... home agent MUST have at least the f...' RFC 2119 keyword, line 234: '... away from home MUST have at least th...' RFC 2119 keyword, line 249: '... MUST have at least the following he...' RFC 2119 keyword, line 258: '...messages sent to the home address MUST...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The SPD entries, which were used for protecting tunneled traffic between the mobile node and the home agent become inactive. The corresponding security associations could be stored or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves aways from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD not be deleted as they do not depend on care-of addresses and can be used again. -- 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 (January 20, 2003) is 7767 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) == Unused Reference: '10' is defined on line 1569, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '1') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '2') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '4') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-20 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-04 == Outdated reference: A later version (-08) exists of draft-vida-mld-v2-06 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Expires: July 21, 2003 V. Devarapalli 5 Nokia Research Center 6 F. Dupont 7 ENST Bretagne 8 January 20, 2003 10 Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and 11 Home Agents 12 draft-ietf-mobileip-mipv6-ha-ipsec-02.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 21, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 Mobile IPv6 uses IPsec to protect signaling between the home agent 44 and the mobile node. Mobile IPv6 base document defines the main 45 requirements these nodes must follow. This draft discusses these 46 requirements in more depth, illustrates the used packet formats, 47 describes suitable configuration procedures, and shows how 48 implementations can process the packets in the right order. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 54 2.1 Binding Updates and Acknowledgements . . . . . . . . . 7 55 2.2 Return Routability Signaling . . . . . . . . . . . . . 8 56 2.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 9 57 2.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 59 3.1 Mandatory Support . . . . . . . . . . . . . . . . . . 11 60 3.2 Policy Requirements . . . . . . . . . . . . . . . . . 11 61 3.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13 62 3.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15 63 4. Example Configurations . . . . . . . . . . . . . . . . . . . 17 64 4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17 65 4.2 Manual Configuration . . . . . . . . . . . . . . . . . 18 66 4.2.1 Binding Updates and Acknowledgements . . . . . . 18 67 4.2.2 Return Routability Signaling . . . . . . . . . . 19 68 4.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20 69 4.2.4 Payload Packets . . . . . . . . . . . . . . . . 21 70 4.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 23 71 4.3.1 Binding Updates and Acknowledgements . . . . . . 23 72 4.3.2 Return Routability Signaling . . . . . . . . . . 24 73 4.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24 74 4.3.4 Payload Packets . . . . . . . . . . . . . . . . 25 75 5. Processing Steps within a Node . . . . . . . . . . . . . . . 27 76 5.1 Binding Update to the Home Agent . . . . . . . . . . . 27 77 5.2 Binding Update from the Mobile Node . . . . . . . . . 28 78 5.3 Binding Acknowledgement to the Mobile Node . . . . . . 28 79 5.4 Binding Acknowledgement from the Home Agent . . . . . 29 80 5.5 Home Test Init to the Home Agent . . . . . . . . . . . 30 81 5.6 Home Test Init from the Mobile Node . . . . . . . . . 31 82 5.7 Home Test to the Mobile Node . . . . . . . . . . . . . 31 83 5.8 Home Test from the Home Agent . . . . . . . . . . . . 32 84 5.9 Prefix Solicitation Message to the Home Agent . . . . 32 85 5.10 Prefix Solicitation Message from the Mobile Node . . . 32 86 5.11 Prefix Advertisement Message to the Mobile Node . . . 32 87 5.12 Prefix Advertisement Message from the Home Agent . . . 33 88 5.13 Payload Packet to the Home Agent . . . . . . . . . . . 33 89 5.14 Payload Packet from the Mobile Node . . . . . . . . . 33 90 5.15 Payload Packet to the Mobile Node . . . . . . . . . . 33 91 5.16 Payload Packet from the Home Agent . . . . . . . . . . 33 92 5.17 Establishing New Security Associations . . . . . . . . 33 93 5.18 Rekeying Security Associations . . . . . . . . . . . . 34 94 5.19 Movements and Dynamic Keying . . . . . . . . . . . . . 35 95 6. Implementation Considerations . . . . . . . . . . . . . . . 37 96 7. Security Considerations . . . . . . . . . . . . . . . . . . 39 97 Normative References . . . . . . . . . . . . . . . . . . . . 40 98 Informative References . . . . . . . . . . . . . . . . . . . 41 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 100 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 101 B. Changes from Previous Version . . . . . . . . . . . . . . . 43 102 Intellectual Property and Copyright Statements . . . . . . . 44 104 1. Introduction 106 This draft illustrates the use of IPsec in securing control traffic 107 relating Mobile IPv6 [7]. In Mobile IPv6, a mobile node is always 108 expected to be addressable at its home address, whether it is 109 currently attached to its home link or is away from home. The "home 110 address" is an IP address assigned to the mobile node within its home 111 subnet prefix on its home link. While a mobile node is at home, 112 packets addressed to its home address are routed to the mobile node's 113 home link. 115 While a mobile node is attached to some foreign link away from home, 116 it is also addressable at a care-of addresses. A care-of address is 117 an IP address associated with a mobile node that has the subnet 118 prefix of a particular foreign link. The association between a 119 mobile node's home address and care-of address is known as a 120 "binding" for the mobile node. While away from home, a mobile node 121 registers its primary care-of address with a router on its home link, 122 requesting this router to function as the "home agent" for the mobile 123 node. The mobile node performs this binding registration by sending 124 a "Binding Update" message to the home agent. The home agent replies 125 to the mobile node by returning a "Binding Acknowledgement" message. 127 Any other nodes communicating with a mobile node are referred to as 128 "correspondent nodes". Mobile nodes can provide information about 129 their current location to correspondent nodes, again using Binding 130 Updates and Acknowledgements. Additionally, return routability test 131 is performed between the mobile node, home agent, and the 132 correspondent node in order to authorize the establishment of the 133 binding. Packets between the mobile node and the correspondent node 134 are either tunneled via the home agent, or sent directly if a binding 135 exists in the correspondent node for the current location of the 136 mobile node. 138 Mobile IPv6 tunnels payload packets between the mobile node and the 139 home agent in both directions. This tunneling uses IPv6 140 encapsulation [6]. Where these tunnels need to be secured, they are 141 replaced by IPsec tunnels [1]. 143 Mobile IPv6 also provides support for the reconfiguration of the home 144 network. Here the home subnet prefixes may change over time. Mobile 145 nodes can learn new information about home subnet prefixes through 146 the "prefix discovery" mechanism. 148 This draft discusses security mechanisms for the control traffic 149 between the mobile node and the home agent. If this traffic is not 150 protected, mobile nodes and correspondent nodes are vulnerable to 151 Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and 152 Denial-of-Service attacks. Any third parties are also vulnerable to 153 Denial-of-Service attacks. These threats are discussed in more 154 detail in Section 15.1 of the Mobile IPv6 base specification [7]. 156 In order to avoid these attacks, the base specification uses IPsec 157 [1] to protect control traffic between the home agent and the mobile 158 node. This control traffic consists of various messages carried by 159 the Mobility Header protocol in IPv6 [5]. The traffic takes the 160 following forms: 162 o Binding Update and Acknowledgement messages exchanged between the 163 mobile node and the home agent, as described in Sections 10.3.1, 164 10.3.2, 11.7.1, and 11.7.3 of the base specification [7]. 166 o Return routability messages Home Test Init and Home Test that pass 167 through the home agent on their way to a correspondent node, as 168 described in Section 10.4.6 of the base specification [7]. 170 o ICMPv6 messages exchanged between the mobile node and the home 171 agent for the purposes of prefix discovery, as described in 172 Sections 10.6 and 11.4 of the base specification [7]. 174 The nodes may also optionally protect payload traffic passing through 175 the home agent, as described in Section 5.3 of the base specification 176 [7]. If multicast group membership control protocols or stateful 177 address autoconfiguration protocols are supported, payload data 178 protection support is required. 180 The control traffic between the mobile node and the home agent 181 requires message authentication, integrity, correct ordering and 182 replay protection. The mobile node and the home agent must have an 183 security association to protect this traffic. Furthermore, the great 184 care is needed when using IKE [4] to establish security associations 185 to Mobile IPv6 home agents. The right kind of addresses must used 186 for transporting IKE. This is necessary to ensure that a Binding 187 Update is not needed before the IKE exchange which is needed for 188 securing the Binding Update. 190 Mobile IPv6 base document defines the main requirements the mobile 191 nodes and home agents must follow when securing the above traffic. 192 This draft discusses these requirements in more depth, illustrates 193 the used packet formats, describes suitable configuration procedures, 194 and shows how implementations can process the packets in the right 195 order. 197 We begin our description by showing the required wire formats for the 198 protected packets in Section 2. Section 3 describes rules which 199 associated Mobile IPv6, IPsec, and IKE implementations must observe. 201 Section 4 discusses how IPsec can be configured to use either manual 202 or automatically established security associations. Section 5 shows 203 examples of how packets are processed within the nodes. 205 All implementations of Mobile IPv6 mobile node and home agent MUST 206 support at least the formats described in Section 2 and obey the 207 rules in Section 3. The configuration and processing sections are 208 informative, and should only be considered as one possible way of 209 providing the required functionality. 211 2. Packet Formats 213 2.1 Binding Updates and Acknowledgements 215 When the mobile node is away from its home, the BUs sent by it to the 216 home agent MUST have at least the following headers in the following 217 order: 219 IPv6 header (source = care-of address, 220 destination = home agent) 221 Destination Options header 222 Home Address option (home address) 223 ESP header 224 Mobility header 225 Binding Update 226 Alternative Care-of Address option (care-of address) 228 Note that the Alternative Care-of Address option is used to ensure 229 that the care-of address is protected by ESP. The home agent 230 considers the address within this option as the current care-of 231 address for the mobile node. 233 The Binding Acknowledgements sent back to the mobile node when it is 234 away from home MUST have at least the following headers in the 235 following order: 237 IPv6 header (source = home agent, 238 destination = care-of address) 239 Routing header (type 2) 240 home address 241 ESP header 242 Mobility header 243 Binding Acknowledgement 245 When the mobile node is at home, the above rules are different as the 246 mobile node can use its home address as a source address. This 247 typically happens for the de-registration Binding Update when the 248 mobile is returning home. In this situation, the Binding Updates 249 MUST have at least the following headers in the following order: 251 IPv6 header (source = home address, 252 destination = home agent) 253 ESP header 254 Mobility header 255 Binding Update 256 Alternative Care-of Address option (care-of address) 258 The Binding Acknowledgement messages sent to the home address MUST 259 have at least the following headers in the following order: 261 IPv6 header (source = home agent, 262 destination = home address) 263 ESP header 264 Mobility header 265 Binding Acknowledgement 267 2.2 Return Routability Signaling 269 When the Home Test Init messages tunneled to the home agent are 270 protected by IPsec, they MUST have at least the following headers in 271 the following order: 273 IPv6 header (source = care-of address, 274 destination = home agent) 275 ESP header 276 IPv6 header (source = home address, 277 destination = correspondent node) 278 Mobility Header 279 Home Test Init 281 Similarly, when the Home Test messages tunneled from the home agent 282 are protected by IPsec, they MUST have at least the following headers 283 in the following order: 285 IPv6 header (source = home agent, 286 destination = care-of address) 287 ESP header 288 IPv6 header (source = correspondent node, 289 destination = home address) 290 Mobility Header 291 Home Test 293 The format used to protect return routability packets relies on the 294 destination of the tunnel packets to change for the mobile node as it 295 moves. The home agent's address stays the same, but the mobile 296 node's address changes upon movements, as if the security 297 association's tunnel gateway address had changed. When the mobile 298 node adopts a new care-of address, its source address selection rules 299 will automatically adopt a new source address for outgoing tunnel 300 packets. 302 The process is more complicated in the home agent side, as the home 303 agent has stored the previous care-of address in its Security 304 Association Database as the gateway address. When IKE is being used, 305 the mobile node runs it on top of its then current care-of address, 306 and the resulting tunnel-mode security associations will use the same 307 addresses as IKE was transported on. In order for the home agent to 308 be able to tunnel a Home Test message to the mobile node, it uses the 309 current care-of address as the destination of the tunnel packets, as 310 if the home agent had modified the gateway address of the security 311 association used for this protection. This implies that the same 312 security association can be used in multiple locations, and no new 313 configuration or IKE rekeying is needed per movement. 315 2.3 Prefix Discovery 317 If IPsec is used to protect prefix discovery, requests for prefix 318 from the mobile node to the home agent MUST have at least the 319 following headers in the following order. 321 IPv6 header (source = care-of address, 322 destination = home agent) 323 Destination Options header 324 Home Address option (home address) 325 ESP header 326 ICMPv6 327 Mobile Prefix Solicitation 329 Again if IPsec is used, solicited and unsolicited prefix information 330 advertisements from the home agent to the mobile node MUST have at 331 least the following headers in the following order. 333 IPv6 header (source = home agent, 334 destination = care-of address) 335 Routing header (type 2) 336 home address 337 ESP header 338 ICMPv6 339 Mobile Prefix Advertisement 341 2.4 Payload Packets 343 If IPsec is used to protect payload packets tunneled to the home 344 agent from the mobile node, a similar format is used as in the case 345 of tunneled Home Test Init messages. However, instead of the 346 Mobility Header these packets may contain any legal IPv6 protocol(s): 348 IPv6 header (source = care-of address, 349 destination = home agent) 350 ESP header 351 IPv6 header (source = home address, 352 destination = correspondent node) 354 Any protocol 356 Similarly, when the payload packets are tunneled from the home agent 357 to the mobile node with IPsec protection, they MUST have at least the 358 following headers in the following order: 360 IPv6 header (source = home agent, 361 destination = care-of address) 362 ESP header 363 IPv6 header (source = correspondent node, 364 destination = home address) 365 Any protocol 367 3. Requirements 369 This section describes mandatory rules for all Mobile IPv6 mobile 370 nodes and home agents. These rules are necessary in order for it to 371 be possible to enable IPsec communications despite movements, 372 guarantee sufficient security, and to ensure correct processing order 373 of packets. 375 The rules in the following sections apply only to the communications 376 between home agents and mobile nodes, and should not be taken as 377 requirements on IPsec in generally is used by mobile nodes. 379 3.1 Mandatory Support 381 The following requirements apply to both home agents and mobile 382 nodes: 384 o Manual configuration of security associations MUST be supported. 385 The configuration of the keys is expected to take place 386 out-of-band, for instance at the time the mobile node is 387 configured to use its home agent. 389 o Automatic key management with IKE [4] MAY be supported. Only 390 IKEv1 is discussed in this document, even if it is expected that 391 the next version of IKE can also be used and that it offers 392 several improvements in this specific application. 394 o IPsec protection for Binding Updates and Acknowledgements between 395 the mobile node and home agent MUST be supported and MUST be used. 397 o IPsec protection for the Home Test Init and Home Test messages 398 tunneled between the mobile node and home agent MUST be supported 399 and SHOULD be used. 401 o IPsec protection for the ICMPv6 messages related to prefix 402 discovery SHOULD be supported and used. 404 o IPsec protection of the payload packets tunneled between the 405 mobile node and home agent MAY be supported and used. 407 o If multicast group membership control protocols or stateful 408 address autoconfiguration protocols are supported, payload data 409 protection MUST be supported. 411 3.2 Policy Requirements 413 The following requirements apply to both home agents and mobile 414 nodes: 416 o When a packet is matched against IPsec security policy or 417 selectors of a security association, an address appearing in a 418 Home Address destination option MUST be considered as the source 419 address of the packet. 421 o Similarly, a home address within a Type 2 Routing header MUST be 422 considered as the destination address of the packet, when a packet 423 is matched against IPsec security policy or selectors of a 424 security association. 426 o When IPsec is used to protect return routability signaling or 427 payload packets, the security policy database entries SHOULD be 428 defined specifically for the tunnel interface between the mobile 429 node and the home agent. That is, the policy entries are not 430 generally applied on all traffic on the physical interface(s) of 431 the nodes, but rather only on traffic that enters this tunnel. 433 o IP layer implementations are, in general, unable to ensure that a 434 particular address of the machine is only used by the user 435 authorized to use that address. Therefore, this specification 436 requires that mobile nodes and home agents SHOULD use credentials 437 that are authorized to control all addresses given to the node. 439 o When the mobile node returns home and de-registers with the Home 440 Agent, the tunnel between the home agent and the mobile node's 441 care-of address is torn down. The SPD entries, which were used 442 for protecting tunneled traffic between the mobile node and the 443 home agent become inactive. The corresponding security 444 associations could be stored or deleted depending on how they were 445 created. If the security associations were created dynamically 446 using IKE, they are automatically deleted when they expire. If 447 the security associations were created through manual 448 configuration, they MUST be retained and used later when the 449 mobile node moves aways from home again. The security 450 associations protecting Binding Updates and Acknowledgements, and 451 prefix discovery SHOULD not be deleted as they do not depend on 452 care-of addresses and can be used again. 454 The following rules apply to mobile nodes: 456 o The mobile node MUST use the Home Address destination option in 457 Binding Updates and Mobile Prefix Solicitations, sent to the home 458 agent from a care-of address. 460 o When the mobile node receives changed set of prefixes from the 461 home agent during prefix discovery, there is a need to configure 462 new security policy entries, and there may be a need to configure 463 new security associations. It is outside the scope of this 464 specification to discuss automatic methods for this. 466 The following rules apply to home agents: 468 o The home agent MUST use the Type 2 Routing header in Binding 469 Acknowledgements and Mobile Prefix Advertisements sent to the 470 mobile node, again due to the need to have the home address 471 visible when the policy checks are made. 473 o It is necessary to avoid the possibility that a mobile node could 474 use its security association to send a Binding Update on behalf of 475 another mobile node using the same home agent. In order to do 476 this, the security policy database entries MUST unequivocally 477 identify a single security association for any given home address 478 and home agent when manual keying is used. When dynamic keying is 479 used, the security policy database entries MUST unequivocally 480 identify the IKE phase 1 credentials which can be used to 481 authorize the creation of security associations for a particular 482 home address. How these mappings are maintained is outside the 483 scope of this specification, but they may be maintained, for 484 instance, as a locally administered table in the home agent. If 485 the phase 1 identity is a FQDN, secure forms of DNS may also be 486 used. 488 o When the set of prefixes advertised by the home agent changes, 489 there is a need to configure new security policy entries, and 490 there may be a need to configure new security associations. It is 491 outside the scope of this specification to discuss automatic 492 methods for this. 494 3.3 IPsec Protocol Processing 496 The following requirements apply to both home agents and mobile 497 nodes: 499 o When securing Binding Updates, Binding Acknowledgements, and 500 prefix discovery, both the mobile nodes and the home agents SHOULD 501 use the Encapsulating Security Payload (ESP) [3] header in 502 transport mode and MUST use a non-null payload authentication 503 algorithm to provide data origin authentication, connectionless 504 integrity and optional anti-replay protection. Note that 505 Authentication Header (AH) [2] is also possible but for brevity 506 not discussed in this specification. 508 Care is needed when selecting suitable encryption algorithms for 509 ESP. Currently available integrity protection algorithms are in 510 general considered to be secure. The encryption algorithm, DES, 511 mandated by the current IPsec standards is not, however. This is 512 particularly problematic when security associations are configured 513 manually, as the same key is used for a long time. 515 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 516 protection of packets belonging to the return routability 517 procedure. A non-null encryption transform and authentication 518 algorithm MUST be applied. 520 o IPsec AH [2] authenticator calculation MUST be performed as if a 521 packet with a Type 2 Routing header would have the home address in 522 the IPv6 destination address field and the care-of address in the 523 Routing header. Type 2 Routing header should be treated by IPsec 524 in the same manner as Type 0 Routing header. 526 o Similarly, the authenticator calculation MUST be performed as if a 527 packet with a Home Address destination option would have the home 528 address in the IPv6 source address field and the care-of address 529 in the destination option. 531 The following rules apply to mobile nodes: 533 o When ESP is used to protect Binding Updates, there is no 534 protection for the care-of address which appears in the IPv6 535 header outside the area protected by ESP. It is important for the 536 home agent to verify that the care-of address has not been 537 tampered. As a result, the attacker would have redirected the 538 mobile node's traffic to another address. In order to prevent 539 this, Mobile IPv6 implementations SHOULD use the Alternate Care-of 540 Address mobility option in all Binding Updates sent to the home 541 agent. (Note that AH protects also the IPv6 header, and some 542 implementations might avoid the option if they know AH is being 543 used.) 545 o When IPsec is used to protect return routability signaling or 546 payload packets, the mobile node MUST set the source address it 547 uses for the outgoing tunnel packets to the current primary 548 care-of address. The mobile node starts to use a new primary 549 care-of address immediately after sending a Binding Update to the 550 home agent to register this new address. 552 The following rules apply to home agents: 554 o When IPsec is used to protect return routability signaling or 555 payload packets, IPsec security associations are needed to provide 556 this protection When the care-of address for the mobile node 557 changes, special treatment is needed for the next packets sent 558 using these security associations. The home agent MUST set the 559 new care-of address as the destination address of these packets, 560 as if the destination gateway address in the security association 561 had changed. 563 3.4 Dynamic Keying 565 The following requirements apply to both home agents and mobile 566 nodes: 568 o If replay protection is required, dynamic keying MUST be used. 569 IPsec can provide replay protection only if dynamic keying is 570 used. This may not always be possible, and manual keying would be 571 preferred in some cases. IPsec also does not guarantee correct 572 ordering of packets, only that they have not been replayed. 573 Because of this, sequence numbers within the Mobile IPv6 messages 574 ensure correct ordering. However, if a home agent reboots and 575 loses its state regarding the sequence numbers, replay attacks 576 become possible. The use of a key management mechanism together 577 with IPsec can be used to prevent such replay attacks. 579 o If IKE version 1 is used with preshared secrets in main mode, it 580 determine the shared secret to use from the IP address of the 581 peer. With Mobile IPv6, however, this may be a care-of address 582 and does not indicate which mobile node attempts to contact the 583 home agent. Therefore, if preshared secret authentication is used 584 in IKEv1 between the mobile node and the home agent then 585 aggressive mode MUST be used. Note also that care needs to be 586 taken with phase 1 identity selection. Where the ID_IPV6_ADDR 587 Identity Payloads is used, unambiguous mapping of identities to 588 keys is not possible. (The next version of IKE may not have these 589 limitations.) 591 The following rules apply to mobile nodes: 593 o Where dynamic keying is used, the key management protocol MUST use 594 the care-of address as the source address in the protocol 595 exchanges with the mobile node's home agent. 597 o Conversely, the IPsec security associations with the mobile node's 598 home agent MUST be requested from the key management protocol with 599 the home address as the mobile node's address. 601 o If the mobile node has used IKE to establish security associations 602 with its home agent, it should follow the procedures discussed in 603 Section 11.7.1 and 11.7.3 of the base specification to determine 604 whether the IKE endpoints can be moved or if rekeying is needed. 606 The following rules apply to home agents: 608 o If the home agent has used IKE to establish security associations 609 with the mobile node, it should follow the procedures discussed in 610 Section 10.3.1 and 10.3.2 of the base specification to determine 611 whether the IKE endpoints can be moved or if rekeying is needed. 613 4. Example Configurations 615 In the following we describe the Security Policy Database (SPD) and 616 Security Association Database (SAD) entries necessary to protect 617 Binding Updates and Binding Acknowledgements exchanged between the 618 mobile node and the home agent. Our examples assume the use of ESP, 619 but a similar configuration could also be used to protect the 620 messages with AH. 622 Section 4.1 introduces the format we use in the description of the 623 SPD and the SAD. Section 4.2 describes how to configure manually 624 keyed security associations, and Section 4.3 describes how to use 625 dynamic keying. 627 4.1 Format 629 The format used in the examples is as follows. The SPD description 630 has the format 632 "SPD OUT:" 633 "-" 634 "-" 635 ... 636 "-" 638 "SPD IN:" 639 "-" 640 "-" 641 ... 642 "-" 644 Where represents the name of the node, and has the 645 following format: 647 "IF" "THEN USE" | 648 "IF" "THEN CREATE" | 650 Where is an boolean expression about the fields of the 651 IPv6 packet, is the name of a security association, and 652 is a specification for an SA to be negotiated via IKE [4]. 653 The SAD description has the format 655 "SAD:" 656 "-" 657 "-" 658 ... 659 "-" 661 Where represents the name of the node, and has the 662 following format: 664 "(" "," 665 "," 666 "," 667 "," 668 ")" ":" 669 671 Where is "IN" or "OUT", is the SPI of the security 672 association, is its destination, is normally 673 "ESP" in our case but could also be "AH", is either "TUNNEL" 674 or "TRANSPORT", and is a boolean expression about the 675 fields of the IPv6 packet. 677 We will be using an example mobile node in this section with the home 678 address "home_address_1". The user's identity in this mobile node is 679 "user_1". The home agent's address is "home_agent_1". 681 4.2 Manual Configuration 683 4.2.1 Binding Updates and Acknowledgements 685 Here are the contents of the SPD and SAD for protecting Binding 686 Updates and Acknowledgements in the mobile node mobile node and home 687 agent home agent: 689 mobile node SPD OUT: 690 - IF source = home_address_1 & destination = home_agent_1 & 691 proto = MH 692 THEN USE SA1 694 mobile node SPD IN: 695 - IF source = home_agent_1 & destination = home_address_1 & 696 proto = MH 697 THEN USE SA2 699 mobile node SAD: 700 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 701 source = home_address_1 & destination = home_agent_1 & 702 proto = MH 703 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 704 source = home_agent_1 & destination = home_address_1 & 705 proto = MH 707 home agent SPD OUT: 708 - IF source = home_agent_1 & destination = home_address_1 & 709 proto = MH 710 THEN USE SA2 712 home agent SPD IN: 713 - IF source = home_address_1 & destination = home_agent_1 & 714 proto = MH 715 THEN USE SA1 717 home agent SAD: 718 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 719 source = home_agent_1 & destination = home_address_1 & 720 proto = MH 721 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 722 source = home_address_1 & destination = home_agent_1 & 723 proto = MH 725 4.2.2 Return Routability Signaling 727 In the following we describe the necessary SPD and SAD entries to 728 protect return routability signaling between the mobile node and the 729 home agent. Note that the rules in the SPD are ordered, and the ones 730 in the previous section must take precedence over these ones: 732 mobile node SPD OUT: 733 - IF interface = tunnel to home_agent_1 & 734 source = home_address_1 & destination = any & 735 proto = MH 736 THEN USE SA3 738 mobile node SPD IN: 739 - IF interface = tunnel from home_agent_1 & 740 source = any & destination = home_address_1 & 741 proto = MH 742 THEN USE SA4 744 mobile node SAD: 745 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 746 source = home_address_1 & destination = any & proto = MH 747 - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): 748 source = any & destination = home_address_1 & proto = MH 750 home agent SPD OUT: 751 - IF interface = tunnel to home_address_1 & 752 source = any & destination = home_address_1 & 753 proto = MH 754 THEN USE SA4 756 home agent SPD IN: 757 - IF interface = tunnel from home_address_1 & 758 source = home_address_1 & destination = any & 759 proto = MH 760 THEN USE SA3 762 home agent SAD: 763 - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): 764 source = any & destination = home_address_1 & proto = MH 765 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 766 source = home_address_1 & destination = any & proto = MH 768 4.2.3 Prefix Discovery 770 In the following we describe some additional SPD and SAD entries to 771 protect prefix discovery. 773 mobile node SPD OUT: 774 - IF source = home_address_1 & destination = home_agent_1 & 775 proto = ICMPv6 776 THEN USE SA5. 778 mobile node SPD IN: 779 - IF source = home_agent_1 & destination = home_address_1 & 780 proto = ICMPv6 781 THEN USE SA6 783 mobile node SAD: 784 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 785 source = home_address_1 & destination = home_agent_1 & 786 proto = ICMPv6 787 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 788 source = home_agent_1 & destination = home_address_1 & 789 proto = ICMPv6 791 home agent SPD OUT: 792 - IF source = home_agent_1 & destination = home_address_1 & 793 proto = ICMPv6 794 THEN USE SA6 796 home agent SPD IN: 797 - IF source = home_address_1 & destination = home_agent_1 & 798 proto = ICMPv6 799 THEN USE SA5 801 home agent SAD: 802 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 803 source = home_agent_1 & destination = home_address_1 & 804 proto = ICMPv6 805 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 806 source = home_address_1 & destination = home_agent_1 & 807 proto = ICMPv6 809 Note that the SPDs described above protect all ICMPv6 traffic between 810 the mobile node and the home agent. 812 4.2.4 Payload Packets 814 It is also possible to perform some additional, optional, protection 815 of tunneled payload packets. This protection takes place in a 816 similar manner to the return routability protection above, but 817 requires a different value for the protocol field. The necessary SPD 818 and SAD entries are shown below. It is assumed that the entries for 819 protecting Binding Updates and Acknowledgements, and the entries to 820 protect Home Test Init and Home Test messages take precedence over 821 these entries. 823 mobile node SPD OUT: 824 - IF interface = tunnel to home_agent_1 & 825 source = home_address_1 & destination = any & 826 proto = X 827 THEN USE SA7 829 mobile node SPD IN: 830 - IF interface = tunnel from home_agent_1 & 831 source = any & destination = home_address_1 & 832 proto = X 833 THEN USE SA8 835 mobile node SAD: 836 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 837 source = home_address_1 & destination = any & proto = X 838 - SA8(IN, spi_h, home_address_1, ESP, TUNNEL): 839 source = any & destination = home_address_1 & proto = X 841 home agent SPD OUT: 842 - IF interface = tunnel to home_address_1 & 843 source = any & destination = home_address_1 & 844 proto = X 845 THEN USE SA8 847 home agent SPD IN: 848 - IF interface = tunnel from home_address_1 & 849 source = home_address_1 & destination = any & 850 proto = X 851 THEN USE SA7 853 home agent SAD: 854 - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): 855 source = any & destination = home_address_1 & proto = X 856 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 857 source = home_address_1 & destination = any & proto = X 859 If multicast group membership control protocols such as MLDv1 [8] or 860 MLDv2 [11] need to be protected, these packets may use a link-local 861 address rather than the home address of the mobile node. In this 862 case the source and destination can be left as a wildcard and the SPD 863 entries will work solely based on the used interface and the 864 protocol, which is ICMPv6 for both MLDv1 and MLDv2. 866 Similar problems are encountered when stateful address 867 autoconfiguration protocols such as DHCPv6 [9] are used. The same 868 approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP 869 protocol. 871 4.3 Dynamic Keying 873 In this section we show an example configuration that uses IKE to 874 negotiate security associations. 876 4.3.1 Binding Updates and Acknowledgements 878 Here are the contents of the SPD for protecting Binding Updates and 879 Acknowledgements: 881 mobile node SPD OUT: 882 - IF source = home_address_1 & destination = home_agent_1 & 883 proto = MH 884 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 886 mobile node SPD IN: 887 - IF source = home_agent_1 & destination = home_address_1 & 888 proto = MH 889 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 891 home agent SPD OUT: 892 - IF source = home_agent_1 & destination = home_address_1 & 893 proto = MH 894 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 896 home agent SPD IN: 897 - IF source = home_address_1 & destination = home_agent_1 & 898 proto = MH 899 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 901 We have omitted details of the proposed transforms in the above, and 902 all details related to the particular authentication method such as 903 certificates beyond listing a specific identity that must be used. 905 We require IKE to be run using the care-of addresses but still 906 negotiate IPsec SAs that use home addresses. The extra conditions 907 set by the home agent SPD for the peer phase 1 identity to be 908 "user_1" must be verified by the home agent. The purpose of the 909 condition is to ensure that the IKE phase 2 negotiation for a given 910 user's home address can't be requested by another user. In the 911 mobile node, we simply set our local identity to be "user_1". 913 These checks also imply that the configuration of the home agent is 914 user-specific: every user or home address requires a specific 915 configuration entry. It would be possible to alleviate the 916 configuration tasks by using certificates that have home addresses in 917 the Subject AltName field. However, it isn't clear if all IKE 918 implementations allow one address to be used for carrying the IKE 919 negotiations when another address is mentioned in the used 920 certificates. In any case, even this approach would have required 921 user-specific tasks in the certificate authority. 923 4.3.2 Return Routability Signaling 925 Protection for the return routability signaling can be configured in 926 a similar manner as above. 928 mobile node SPD OUT: 929 - IF interface = tunnel to home_agent_1 & 930 source = home_address_1 & destination = any & 931 proto = MH 932 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 933 local phase 1 identity = user_1 935 mobile node SPD IN: 936 - IF interface = tunnel from home_agent_1 & 937 source = any & destination = home_address_1 & 938 proto = MH 939 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 940 local phase 1 identity = user_1 942 home agent SPD OUT: 943 - IF interface = tunnel to home_address_1 & 944 source = any & destination = home_address_1 & 945 proto = MH 946 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 947 peer phase 1 identity = user_1 949 home agent SPD IN: 950 - IF interface = tunnel from home_address_1 & 951 source = home_address_1 & destination = any & 952 proto = MH 953 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 954 peer phase 1 identity = user_1 956 One difference to the above is that we specified the tunnel gateway 957 address, as we need to use a different address for that than those 958 appearing in the packets. 960 4.3.3 Prefix Discovery 962 In the following we describe some additional SPD entries to protect 963 prefix discovery with IKE. (Note that when actual new prefixes are 964 discovered, there may be a need to enter new manually configured SPD 965 entries to specify the authorization policy for the resulting new 966 home addresses.) 968 mobile node SPD OUT: 969 - IF source = home_address_1 & destination = home_agent_1 & 970 proto = ICMPv6 971 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 973 mobile node SPD IN: 974 - IF source = home_agent_1 & destination = home_address_1 & 975 proto = ICMPv6 976 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 978 home agent SPD OUT: 979 - IF source = home_agent_1 & destination = home_address_1 & 980 proto = ICMPv6 981 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 983 home agent SPD IN: 984 - IF source = home_address_1 & destination = home_agent_1 & 985 proto = ICMPv6 986 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 988 4.3.4 Payload Packets 990 Protection for the payload packets happens similarly to the 991 protection of return routability signaling. As in the manually keyed 992 case, these SPD entries have lower priority than the above ones. 994 mobile node SPD OUT: 995 - IF interface = tunnel to home_agent_1 & 996 source = home_address_1 & destination = any & 997 proto = X 998 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 999 local phase 1 identity = user_1 1001 mobile node SPD IN: 1002 - IF interface = tunnel from home_agent_1 & 1003 source = any & destination = home_address_1 & 1004 proto = X 1005 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 1006 local phase 1 identity = user_1 1008 home agent SPD OUT: 1009 - IF interface = tunnel to home_address_1 & 1010 source = any & destination = home_address_1 & 1011 proto = X 1012 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1013 peer phase 1 identity = user_1 1015 home agent SPD IN: 1016 - IF interface = tunnel from home_address_1 & 1017 source = home_address_1 & destination = any & 1018 proto = X 1019 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1020 peer phase 1 identity = user_1 1022 5. Processing Steps within a Node 1024 5.1 Binding Update to the Home Agent 1026 Step 1. At the mobile node, Mobile IPv6 module first produces the 1027 following packet: 1029 IPv6 header (source = home address, 1030 destination = home agent) 1031 Mobility header 1032 Binding Update 1034 Step 2. This packet is matched against the IPsec policy data base on 1035 the mobile node and we make a note that IPsec must be applied. 1037 Step 3. Then, we add the necessary Mobile IPv6 options but do not 1038 change the addresses yet, as described in Section 11.2.2 of the base 1039 specification [7]. This results in: 1041 IPv6 header (source = home address, 1042 destination = home agent) 1043 Destination Options header 1044 Home Address option (care-of address) 1045 Mobility header 1046 Binding Update 1048 Step 4. Finally, IPsec headers are added and the necessary 1049 authenticator values are calculated: 1051 IPv6 header (source = home address, 1052 destination = home agent) 1053 Destination Options header 1054 Home Address option (care-of address) 1055 ESP header (SPI = spi_a) 1056 Mobility header 1057 Binding Update 1059 Step 5. Before sending the packet, the addresses in the IPv6 header 1060 and the Destination Options header are changed: 1062 IPv6 header (source = care-of address, 1063 destination = home agent) 1064 Destination Options header 1065 Home Address option (home address) 1066 ESP header (SPI = spi_a) 1067 Mobility header 1068 Binding Update 1070 5.2 Binding Update from the Mobile Node 1072 Step 1. The following packet is received at the home agent: 1074 IPv6 header (source = care-of address, 1075 destination = home agent) 1076 Destination Options header 1077 Home Address option (home address) 1078 ESP header (SPI = spi_a) 1079 Mobility header 1080 Binding Update 1082 Step 2. The home address option is processed first, which results in 1084 IPv6 header (source = home address, 1085 destination = home agent) 1086 Destination Options header 1087 Home Address option (care-of address) 1088 ESP header (SPI = spi_a) 1089 Mobility header 1090 Binding Update 1092 Step 3. ESP header is processed next, resulting in 1094 IPv6 header (source = home address, 1095 destination = home agent) 1096 Destination Options header 1097 Home Address option (care-of address) 1098 Mobility header 1099 Binding Update 1101 Step 4. This packet matches the security association selectors 1102 (source = home address, destination = home agent, proto = MH). 1104 Step 5. Mobile IPv6 processes the Binding Update. The Binding 1105 Update is delivered to the Mobile IPv6 module. 1107 5.3 Binding Acknowledgement to the Mobile Node 1109 Step 1. Mobile IPv6 produces the following packet: 1111 IPv6 header (source = home agent, 1112 destination = home address) 1113 Mobility header 1114 Binding Acknowledgement 1116 Step 2. This packet matches the IPsec policy entries, and we 1117 remember that IPsec has to be applied. 1119 Step 3. Then, we add the necessary Route Headers but do not change 1120 the addresses yet, as described in Section 9.6 of the base 1121 specification [7]. This results in: 1123 IPv6 header (source = home agent, 1124 destination = home address) 1125 Routing header (type 2) 1126 care-of address 1127 Mobility header 1128 Binding Acknowledgement 1130 Step 4. We apply IPsec: 1132 IPv6 header (source = home agent, 1133 destination = home address) 1134 Routing header (type 2) 1135 care-of address 1136 ESP header (SPI = spi_b) 1137 Mobility header 1138 Binding Acknowledgement 1140 Step 5. Finally, before sending the packet out we change the 1141 addresses in the IPv6 header and the Route header: 1143 IPv6 header (source = home agent, 1144 destination = care-of address) 1145 Routing header (type 2) 1146 home address 1147 ESP header (SPI = spi_b) 1148 Mobility header 1149 Binding Acknowledgement 1151 5.4 Binding Acknowledgement from the Home Agent 1153 Step 1. The following packet is received at the mobile node 1155 IPv6 header (source = home agent, 1156 destination = care-of address) 1157 Routing header (type 2) 1158 home address 1159 ESP header (SPI = spi_b) 1160 Mobility header 1161 Binding Acknowledgement 1163 Step 2. After the routing header is processed the packet becomes 1164 IPv6 header (source = home agent, 1165 destination = home address) 1166 Routing header (type 2) 1167 care-of address 1168 ESP header (SPI = spi_b) 1169 Mobility header 1170 Binding Acknowledgement 1172 Step 3. ESP header is processed next, resulting in: 1174 IPv6 header (source = home agent, 1175 destination = home address) 1176 Routing header (type 2) 1177 care-of address 1178 Mobility header 1179 Binding Acknowledgement 1181 Step 4. This packet matches the security association selectors 1182 (source = home agent, destination = home address, proto = MH). 1184 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 1185 module. 1187 5.5 Home Test Init to the Home Agent 1189 Step 1. The mobile node constructs a Home Test Init message: 1191 IPv6 header (source = home address, 1192 destination = correspondent node) 1193 Mobility header 1194 Home Test Init 1196 Step 2. Mobile IPv6 determines that this packet should go to the 1197 tunnel to the home agent. 1199 Step 3. The packet is matched against IPsec policy entries for the 1200 interface, and we find that IPsec needs to be applied. 1202 Step 4. IPsec tunnel mode headers are added. Note that we use a 1203 care-of address as a source address for the tunnel packet. 1205 IPv6 header (source = care-of address, 1206 destination = home agent) 1207 ESP header (SPI = spi_c) 1208 IPv6 header (source = home address, 1209 destination = correspondent node) 1210 Mobility header 1211 Home Test Init 1213 Step 5. The packet no longer satisfies the criteria that made it 1214 enter the tunnel, and it is sent directly to the home agent. 1216 5.6 Home Test Init from the Mobile Node 1218 Step 1. The home agent receives the following packet: 1220 IPv6 header (source = care-of address, 1221 destination = home agent) 1222 ESP header (SPI = spi_c) 1223 IPv6 header (source = home address, 1224 destination = correspondent node) 1225 Mobility Header 1226 Home Test Init 1228 Step 2. IPsec processing is performed, resulting in: 1230 IPv6 header (source = home address, 1231 destination = correspondent node) 1232 Mobility Header 1233 Home Test Init 1235 Step 3. The resulting packet matches the selectors and the packet 1236 can be processed further. 1238 Step 4. The packet is then forwarded to the correspondent node. 1240 5.7 Home Test to the Mobile Node 1242 Step 1. The home agent receives a Home Test packet from the 1243 correspondent node: 1245 IPv6 header (source = correspondent node, 1246 destination = home address) 1247 Mobility Header 1248 Home Test Init 1250 Step 2. The home agent determines that this packet is destined to a 1251 mobile node that is away from home, and decides to tunnel it. 1253 Step 3. The packet matches the IPsec policy entries for the tunnel 1254 interface, and we note that IPsec needs to be applied. 1256 Step 4. IPsec is applied, resulting in a new packet. Note that the 1257 home agent must keep track of the location of the mobile node, and 1258 update the tunnel gateway address in the security association(s) 1259 accordingly. 1261 IPv6 header (source = home agent, 1262 destination = care-of address) 1263 ESP header (SPI = spi_d) 1264 IPv6 header (source = correspondent node, 1265 destination = home address) 1266 Mobility Header 1267 Home Test Init 1269 Step 5. The packet no longer satisfies the criteria that made it 1270 enter the tunnel, and it is sent directly to the care-of address. 1272 5.8 Home Test from the Home Agent 1274 Step 1. The mobile node receives the following packet: 1276 IPv6 header (source = home agent, 1277 destination = care-of address) 1278 ESP header (SPI = spi_d) 1279 IPv6 header (source = correspondent node, 1280 destination = home address) 1281 Mobility Header 1282 Home Test Init 1284 Step 2. IPsec is processed, resulting in: 1286 IPv6 header (source = correspondent node, 1287 destination = home address) 1288 Mobility Header 1289 Home Test Init 1291 Step 3. This matches the security association selectors (source = 1292 any, destination = home address). 1294 Step 4. The packet is given to Mobile IPv6 processing. 1296 5.9 Prefix Solicitation Message to the Home Agent 1298 This procedure is similar to the one presented in Section 5.1. 1300 5.10 Prefix Solicitation Message from the Mobile Node 1302 This procedure is similar to the one presented in Section 5.2. 1304 5.11 Prefix Advertisement Message to the Mobile Node 1306 This procedure is similar to the one presented in Section 5.3. 1308 5.12 Prefix Advertisement Message from the Home Agent 1310 This procedure is similar to the one presented in Section 5.4. 1312 5.13 Payload Packet to the Home Agent 1314 This procedure is similar to the one presented in Section 5.5. 1316 5.14 Payload Packet from the Mobile Node 1318 This procedure is similar to the one presented in Section 5.6. 1320 5.15 Payload Packet to the Mobile Node 1322 This procedure is similar to the one presented in Section 5.7. 1324 5.16 Payload Packet from the Home Agent 1326 This procedure is similar to the one presented in Section 5.8. 1328 5.17 Establishing New Security Associations 1330 Step 1. The mobile node wishes to send a Binding Update to the home 1331 agent. 1333 IPv6 header (source = home address, 1334 destination = home agent) 1335 Mobility header 1336 Binding Update 1338 Step 2. There is no existing security association to protect the 1339 Binding Update, so IKE is initiated. The IKE packets are sent as 1340 shown in the following examples. The first packet is an example of 1341 an IKE packet sent from the mobile node, and the second one is frokm 1342 the home agent. The examples shows also that the phase 1 identity 1343 used for the mobile node is a FQDN. 1345 IPv6 header (source = care-of address, 1346 destination = home agent) 1347 UDP 1348 IKE 1349 ... IDii = ID_FQDN mn123.ha.net ... 1351 IPv6 header (source = home agent 1352 destination = care-of address) 1353 UDP 1354 IKE 1355 ... IDir = ID_FQDN ha.net ... 1357 Step 3. IKE phase 1 completes, and phase 2 is initiated to request 1358 security associations for protecting traffic between the mobile 1359 node's home address and the home agent. This involves sending and 1360 receiving additional IKE packets. The below example shows again one 1361 packet sent by the mobile node and another sent by the home agent. 1362 The example shows also that the phase 2 identity used for the mobile 1363 node is the mobile node's home address. 1365 IPv6 header (source = care-of address, 1366 destination = home agent) 1367 UDP 1368 IKE 1369 ... IDci = ID_IPV6_ADDR home address ... 1371 IPv6 header (source = home agent, 1372 destination = care-of address) 1373 UDP 1374 IKE 1375 ... IDcr = ID_IPV6_ADDR home agent ... 1377 Step 4. The remaining steps are as shown in Section 5.1. 1379 5.18 Rekeying Security Associations 1381 Step 1. The mobile node and the home agent have existing security 1382 associations. Either side may decide at any time that the security 1383 associations need to be rekeyed, for instance, because the specified 1384 lifetime is approaching. 1386 Step 2. Mobility header packets sent during rekey may be protected 1387 by the existing security associations. 1389 Step 3. When the rekeying is finished, new security associations are 1390 established. In practice there is a time interval during which an 1391 old, about-to-expire security association and newly established 1392 security association will both exist. The new ones should be used as 1393 soon as they become available. 1395 Step 4. A notification of the deletion of the old security 1396 associations is received. After this, only the new security 1397 associations can be used. 1399 Note that there is no requirement that the existence of the IPsec and 1400 IKE security associations is tied to the existence of bindings. It 1401 is not necessary to delete a security association if a binding is 1402 removed, as a new binding may soon be established after this. 1404 Since cryptographic acceleration hardware may only be able to handle 1405 a limited number of active security associations, security 1406 associations may be deleted via IKE in order to keep the number of 1407 active cryptographic contexts to a minimum. Such deletions should 1408 not be interpreted as a sign of losing a contact to the peer or as a 1409 reason to remove a binding. Rather, if additional traffic needs to 1410 be sent, it is preferable to bring up another security association to 1411 protect it. 1413 5.19 Movements and Dynamic Keying 1415 In this section we describe the sequence of events that relate to 1416 movement with IKE-based security associations. In the initial state, 1417 the mobile node is not registered in any location and has no security 1418 associations with the home agent. Depending on whether the peers 1419 will be able to move IKE endpoints to new care-of addresses, the 1420 actions taken in Step 9 and 10 are different. 1422 Step 1. Mobile node with the home address A moves to care-of address 1423 B. 1425 Step 2. Mobile node runs IKE from care-of address B to the home 1426 agent, establishing a phase 1. 1428 Step 3. Protected by this phase 1, mobile node establishes a pair of 1429 security associations for protecting MH traffic to and from the home 1430 address A. 1432 Step 4. Mobile node sends a Binding Update and receives a Binding 1433 Acknowledgement using the security associations created in Step 3. 1435 Step 5. Mobile node establishes a pair of security associations for 1436 protecting return routability packets. These security associations 1437 are in tunnel mode and their endpoint in the mobile node side is 1438 care-of address B. For the purposes of our example, this step uses 1439 the phase 1 connection established in Step 2. Multiple phase 1 1440 connections are also possible. 1442 Step 6. The mobile node uses the security associations created in 1443 Step 5 to run return routability. 1445 Step 7. The mobile node moves to a new location and adopts a new 1446 care-of address C. 1448 Step 8. Mobile node sends a Binding Update and receives a Binding 1449 Acknowledgement using the security associations created in Step 3. 1450 The home agent ensures that the next packets sent using the security 1451 associations created in Step 5 will have the new care-of address as 1452 their destination address, as if the destination gateway address in 1453 the security association had changed. 1455 Step 9. If the mobile node and the HA have the capability to change 1456 the IKE endpoints, they change the address to C. If they dont have 1457 the capability, both nodes remove their phase 1 connections created 1458 on top of the care-of address B and establish a new IKE phase 1 on 1459 top of the care-of address C. This capability to change the IKE 1460 phase 1 end points is indicated through setting the Key Management 1461 Mobility Capability (K) flag [7] in the Binding Update and Binding 1462 Acknowledgement messages. 1464 Step 11. If a new IKE phase 1 connection was setup after movement, 1465 the MN will not be able to receive any notifications delivered on top 1466 of the old IKE phase 1 security association. Notifications delivered 1467 on top of the new security association are received and processed 1468 normally. If the mobile node and HA were able to update the IKE 1469 endpoints, they can continue using the same IKE phase 1 connection. 1471 6. Implementation Considerations 1473 We have chosen to require an encapsulation format for return 1474 routability and payload packet protection which can only be realized 1475 if the destination of the IPsec packets sent from the home agent can 1476 be changed as the mobile node moves. One of the main reasons for 1477 choosing such a format is that it removes the overhead of twenty four 1478 bytes when a home address option or routing header is added to the 1479 tunneled packet. What is needed is that the home agent must act as 1480 if the gateway address of a security association to the mobile node 1481 would have changed. Implementations are free to choose any 1482 particular method to make this change, such as using an API to the 1483 IPsec implementation to change the parameters of the security 1484 association, removing the security association and installing a new 1485 one, or modification of the packet after it has gone through IPsec 1486 processing. The only requirement is that after registering a new 1487 binding at the home agent, the next IPsec packets sent on this 1488 security association will be addressed to the new care-of address. 1490 We have also chosen to require that a dynamic key management protocol 1491 must be able to make an authorization decision for IPsec security 1492 association creation with different addresses than with what the key 1493 management protocol is run. We expect this to be done typically by 1494 configuring the allowed combinations of phase 1 user identities and 1495 home addresses. 1497 The base Mobile IPv6 specification sets high requirements for a 1498 so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As 1499 Mobile IPv6 specific modifications of the packets are required after 1500 IPsec processing, the BITS implementation has to perform also some 1501 tasks related to mobility. This may increase the complexity of the 1502 implementation, even if it already performs some tasks of the IP 1503 layer (such as fragmentation). 1505 We have chosen to require policy entries that are specific to a 1506 tunnel interface. This means that implementations have to regard the 1507 Home Agent - Mobile Node tunnel as a separate interface on which 1508 IPsec SPDs can be based. 1510 A further complication of the IPsec processing on a tunnel interface 1511 is that this requires access to the BITS implementation before the 1512 packet actually goes out. 1514 When certificate authentication is used, IKE fragmentation can be 1515 encountered. This can occur when certificate chains are used, or 1516 even with single certificates if they are large. Many firewalls do 1517 not handle fragments properly, and may drop them. Routers in the 1518 path may also discard fragments after the initial one, since they 1519 typically will not contain full IP headers that can be compared 1520 against an access list. Where fragmentation occurs, the endpoints 1521 will not always be able to establish a security association. 1523 Fortunately, typical Mobile IPv6 deployment uses short certificate 1524 chains, as the mobile node is communicating directly with its home 1525 network. Nevertheless, where the problem appears, one solution is to 1526 replace the firewalls or routers with equipment that can properly 1527 support fragments. If this cannot be done, it may help to store the 1528 peer certificates locally, or to obtain them through other means. 1530 7. Security Considerations 1532 The Mobile IPv6 base specification [7] requires strong security 1533 between the mobile node and the home agent. This memo discusses how 1534 that security can be arranged in practice, using IPsec. 1536 Normative References 1538 [1] Kent, S. and R. Atkinson, "Security Architecture for the 1539 Internet Protocol", RFC 2401, November 1998. 1541 [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1542 November 1998. 1544 [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1545 (ESP)", RFC 2406, November 1998. 1547 [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1548 RFC 2409, November 1998. 1550 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1551 Specification", RFC 2460, December 1998. 1553 [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1554 Specification", RFC 2473, December 1998. 1556 [7] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1557 IPv6", draft-ietf-mobileip-ipv6-20 (work in progress), January 1558 2003. 1560 Informative References 1562 [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1563 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1565 [9] Droms, R., "Dynamic Host Configuration Protocol for IPv6 1566 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 1567 November 2002. 1569 [10] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, 1570 "Negotiation of NAT-Traversal in the IKE", 1571 draft-ietf-ipsec-nat-t-ike-04 (work in progress), November 1572 2002. 1574 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1575 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 1576 December 2002. 1578 Authors' Addresses 1580 Jari Arkko 1581 Ericsson 1582 Jorvas 02420 1583 Finland 1585 EMail: jari.arkko@ericsson.com 1587 Vijay Devarapalli 1588 Nokia Research Center 1589 313 Fairchild Drive 1590 Mountain View CA 94043 1591 USA 1593 EMail: vijayd@iprg.nokia.com 1595 Francis Dupont 1596 ENST Bretagne 1597 Campus de Rennes 2, rue de la Chataigneraie 1598 BP 78 1599 Cesson-Sevigne Cedex 35512 1600 France 1602 EMail: Francis.Dupont@enst-bretagne.fr 1604 Appendix A. Acknowledgements 1606 The authors would like to thank Michael Thomas, Kevin Miles, Cheryl 1607 Madson, Bernard Aboba, Erik Nordmark, and Gabriel Montenegro for 1608 interesting discussions in this problem space. 1610 Appendix B. Changes from Previous Version 1612 The following changes have been made to this draft from version 1: 1614 o The validation of a Home Address destination option in the 1615 presense of a Binding Update and IPsec encapsulation has been 1616 specified (tracked issue 216). 1618 o The requirements for the IKE phase 2 authorization check have been 1619 made explicit (tracked issue 216). 1621 o More details have been provided on how IKE processing takes place 1622 (tracked issue 195). 1624 o Requirements for treating necessary policy and security 1625 association modifications upon new prefixes have been explained 1626 better (tracked issue 195). 1628 o The Key Management Movement Capability (K) bit has been added to 1629 the Binding Update and Acknowledgement messages (tracked issue 1630 194). 1632 o More details have been provided on how IKE end-points change 1633 during movements (tracked issue 194). 1635 o The results of the security review have been adopted (tracked 1636 issue 189). The modifications include specifying only the use of 1637 ESP for protecting signaling. 1639 o Many editorial modifications. 1641 Intellectual Property Statement 1643 The IETF takes no position regarding the validity or scope of any 1644 intellectual property or other rights that might be claimed to 1645 pertain to the implementation or use of the technology described in 1646 this document or the extent to which any license under such rights 1647 might or might not be available; neither does it represent that it 1648 has made any effort to identify any such rights. Information on the 1649 IETF's procedures with respect to rights in standards-track and 1650 standards-related documentation can be found in BCP-11. Copies of 1651 claims of rights made available for publication and any assurances of 1652 licenses to be made available, or the result of an attempt made to 1653 obtain a general license or permission for the use of such 1654 proprietary rights by implementors or users of this specification can 1655 be obtained from the IETF Secretariat. 1657 The IETF invites any interested party to bring to its attention any 1658 copyrights, patents or patent applications, or other proprietary 1659 rights which may cover technology that may be required to practice 1660 this standard. Please address the information to the IETF Executive 1661 Director. 1663 Full Copyright Statement 1665 Copyright (C) The Internet Society (2003). All Rights Reserved. 1667 This document and translations of it may be copied and furnished to 1668 others, and derivative works that comment on or otherwise explain it 1669 or assist in its implementation may be prepared, copied, published 1670 and distributed, in whole or in part, without restriction of any 1671 kind, provided that the above copyright notice and this paragraph are 1672 included on all such copies and derivative works. However, this 1673 document itself may not be modified in any way, such as by removing 1674 the copyright notice or references to the Internet Society or other 1675 Internet organizations, except as needed for the purpose of 1676 developing Internet standards in which case the procedures for 1677 copyrights defined in the Internet Standards process must be 1678 followed, or as required to translate it into languages other than 1679 English. 1681 The limited permissions granted above are perpetual and will not be 1682 revoked by the Internet Society or its successors or assignees. 1684 This document and the information contained herein is provided on an 1685 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1686 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1687 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1688 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1689 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1691 Acknowledgement 1693 Funding for the RFC Editor function is currently provided by the 1694 Internet Society.