idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-04.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (March 20, 2003) is 7706 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: '11' is defined on line 1619, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 == 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: 6 errors (**), 0 flaws (~~), 9 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: September 18, 2003 V. Devarapalli 5 Nokia Research Center 6 F. Dupont 7 ENST Bretagne 8 March 20, 2003 10 Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and 11 Home Agents 12 draft-ietf-mobileip-mipv6-ha-ipsec-04.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 September 18, 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 document 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.1 Binding Updates and Acknowledgements . . . . . . . . . 8 56 3.2 Return Routability Signaling . . . . . . . . . . . . . 9 57 3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10 58 3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 10 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12 61 4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12 62 4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 14 63 4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 16 64 5. Example Configurations . . . . . . . . . . . . . . . . . . . 18 65 5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 18 66 5.2 Manual Configuration . . . . . . . . . . . . . . . . . 19 67 5.2.1 Binding Updates and Acknowledgements . . . . . . 19 68 5.2.2 Return Routability Signaling . . . . . . . . . . 20 69 5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 21 70 5.2.4 Payload Packets . . . . . . . . . . . . . . . . 22 71 5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 24 72 5.3.1 Binding Updates and Acknowledgements . . . . . . 24 73 5.3.2 Return Routability Signaling . . . . . . . . . . 25 74 5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 26 75 5.3.4 Payload Packets . . . . . . . . . . . . . . . . 26 76 6. Processing Steps within a Node . . . . . . . . . . . . . . . 28 77 6.1 Binding Update to the Home Agent . . . . . . . . . . . 28 78 6.2 Binding Update from the Mobile Node . . . . . . . . . 29 79 6.3 Binding Acknowledgement to the Mobile Node . . . . . . 29 80 6.4 Binding Acknowledgement from the Home Agent . . . . . 30 81 6.5 Home Test Init to the Home Agent . . . . . . . . . . . 31 82 6.6 Home Test Init from the Mobile Node . . . . . . . . . 32 83 6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 32 84 6.8 Home Test from the Home Agent . . . . . . . . . . . . 33 85 6.9 Prefix Solicitation Message to the Home Agent . . . . 33 86 6.10 Prefix Solicitation Message from the Mobile Node . . . 33 87 6.11 Prefix Advertisement Message to the Mobile Node . . . 33 88 6.12 Prefix Advertisement Message from the Home Agent . . . 34 89 6.13 Payload Packet to the Home Agent . . . . . . . . . . . 34 90 6.14 Payload Packet from the Mobile Node . . . . . . . . . 34 91 6.15 Payload Packet to the Mobile Node . . . . . . . . . . 34 92 6.16 Payload Packet from the Home Agent . . . . . . . . . . 34 93 6.17 Establishing New Security Associations . . . . . . . . 34 94 6.18 Rekeying Security Associations . . . . . . . . . . . . 35 95 6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 36 96 7. Implementation Considerations . . . . . . . . . . . . . . . 38 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 98 9. Security Considerations . . . . . . . . . . . . . . . . . . 41 99 Normative References . . . . . . . . . . . . . . . . . . . . 42 100 Informative References . . . . . . . . . . . . . . . . . . . 43 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 102 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 103 B. Changes from Previous Version . . . . . . . . . . . . . . . 45 104 Intellectual Property and Copyright Statements . . . . . . . 46 106 1. Introduction 108 This document illustrates the use of IPsec in securing control 109 traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node 110 is always expected to be addressable at its home address, whether it 111 is currently attached to its home link or is away from home. The 112 "home address" is an IP address assigned to the mobile node within 113 its home subnet prefix on its home link. While a mobile node is at 114 home, packets addressed to its home address are routed to the mobile 115 node's home link. 117 While a mobile node is attached to some foreign link away from home, 118 it is also addressable at a care-of addresses. A care-of address is 119 an IP address associated with a mobile node that has the subnet 120 prefix of a particular foreign link. The association between a 121 mobile node's home address and care-of address is known as a 122 "binding" for the mobile node. While away from home, a mobile node 123 registers its primary care-of address with a router on its home link, 124 requesting this router to function as the "home agent" for the mobile 125 node. The mobile node performs this binding registration by sending 126 a "Binding Update" message to the home agent. The home agent replies 127 to the mobile node by returning a "Binding Acknowledgement" message. 129 Any other nodes communicating with a mobile node are referred to as 130 "correspondent nodes". Mobile nodes can provide information about 131 their current location to correspondent nodes, again using Binding 132 Updates and Acknowledgements. Additionally, return routability test 133 is performed between the mobile node, home agent, and the 134 correspondent node in order to authorize the establishment of the 135 binding. Packets between the mobile node and the correspondent node 136 are either tunneled via the home agent, or sent directly if a binding 137 exists in the correspondent node for the current location of the 138 mobile node. 140 Mobile IPv6 tunnels payload packets between the mobile node and the 141 home agent in both directions. This tunneling uses IPv6 142 encapsulation [7]. Where these tunnels need to be secured, they are 143 replaced by IPsec tunnels [2]. 145 Mobile IPv6 also provides support for the reconfiguration of the home 146 network. Here the home subnet prefixes may change over time. Mobile 147 nodes can learn new information about home subnet prefixes through 148 the "prefix discovery" mechanism. 150 This document discusses security mechanisms for the control traffic 151 between the mobile node and the home agent. If this traffic is not 152 protected, mobile nodes and correspondent nodes are vulnerable to 153 Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and 154 Denial-of-Service attacks. Any third parties are also vulnerable to 155 Denial-of-Service attacks. These threats are discussed in more 156 detail in Section 15.1 of the Mobile IPv6 base specification [8]. 158 In order to avoid these attacks, the base specification uses IPsec 159 [2] to protect control traffic between the home agent and the mobile 160 node. This control traffic consists of various messages carried by 161 the Mobility Header protocol in IPv6 [6]. The traffic takes the 162 following forms: 164 o Binding Update and Acknowledgement messages exchanged between the 165 mobile node and the home agent, as described in Sections 10.3.1, 166 10.3.2, 11.7.1, and 11.7.3 of the base specification [8]. 168 o Return routability messages Home Test Init and Home Test that pass 169 through the home agent on their way to a correspondent node, as 170 described in Section 10.4.6 of the base specification [8]. 172 o ICMPv6 messages exchanged between the mobile node and the home 173 agent for the purposes of prefix discovery, as described in 174 Sections 10.6 and 11.4 of the base specification [8]. 176 The nodes may also optionally protect payload traffic passing through 177 the home agent, as described in Section 5.3 of the base specification 178 [8]. If multicast group membership control protocols or stateful 179 address autoconfiguration protocols are supported, payload data 180 protection support is required. 182 The control traffic between the mobile node and the home agent 183 requires message authentication, integrity, correct ordering and 184 replay protection. The mobile node and the home agent must have a 185 security association to protect this traffic. Furthermore, great 186 care is needed when using IKE [5] to establish security associations 187 to Mobile IPv6 home agents. The right kind of addresses must be used 188 for transporting IKE. This is necessary to avoid circular 189 dependencies in which the use of a Binding Update triggers the need 190 for an IKE exchange that cannot complete prior to the Binding Update 191 having been completed. 193 The mobile IPv6 base document defines the main requirements the 194 mobile nodes and home agents must follow when securing the above 195 traffic. This document discusses these requirements in more depth, 196 illustrates the used packet formats, describes suitable configuration 197 procedures, and shows how implementations can process the packets in 198 the right order. 200 We begin our description by showing the required wire formats for the 201 protected packets in Section 3. Section 4 describes rules which 202 associated Mobile IPv6, IPsec, and IKE implementations must observe. 203 Section 5 discusses how IPsec can be configured to use either manual 204 or automatically established security associations. Section 6 shows 205 examples of how packets are processed within the nodes. 207 All implementations of Mobile IPv6 mobile node and home agent MUST 208 support at least the formats described in Section 3 and obey the 209 rules in Section 4. The configuration and processing sections are 210 informative, and should only be considered as one possible way of 211 providing the required functionality. 213 2. Terminology 215 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in RFC 2119 [1]. 219 3. Packet Formats 221 3.1 Binding Updates and Acknowledgements 223 When the mobile node is away from its home, the BUs sent by it to the 224 home agent MUST support at least the following headers in the 225 following order: 227 IPv6 header (source = care-of address, 228 destination = home agent) 229 Destination Options header 230 Home Address option (home address) 231 ESP header 232 Mobility header 233 Binding Update 234 Alternate Care-of Address option (care-of address) 236 Note that the Alternate Care-of Address option is used to ensure that 237 the care-of address is protected by ESP. The home agent considers 238 the address within this option as the current care-of address for the 239 mobile node. 241 The Binding Acknowledgements sent back to the mobile node when it is 242 away from home MUST support at least the following headers in the 243 following order: 245 IPv6 header (source = home agent, 246 destination = care-of address) 247 Routing header (type 2) 248 home address 249 ESP header 250 Mobility header 251 Binding Acknowledgement 253 When the mobile node is at home, the above rules are different as the 254 mobile node can use its home address as a source address. This 255 typically happens for the de-registration Binding Update when the 256 mobile is returning home. In this situation, the Binding Updates 257 MUST support at least the following headers in the following order: 259 IPv6 header (source = home address, 260 destination = home agent) 261 ESP header 262 Mobility header 263 Binding Update 265 The Binding Acknowledgement messages sent to the home address MUST 266 support at least the following headers in the following order: 268 IPv6 header (source = home agent, 269 destination = home address) 270 ESP header 271 Mobility header 272 Binding Acknowledgement 274 3.2 Return Routability Signaling 276 When the Home Test Init messages tunneled to the home agent are 277 protected by IPsec, they MUST support at least the following headers 278 in the following order: 280 IPv6 header (source = care-of address, 281 destination = home agent) 282 ESP header 283 IPv6 header (source = home address, 284 destination = correspondent node) 285 Mobility Header 286 Home Test Init 288 This format assumes that the mobile node's current care-of address is 289 used as one of the gateway addresses in the security association. As 290 discussed in Section 4.3, this requires the home agent to update the 291 gateway address when the mobile node moves. Policy entries and 292 security association selectors stay the same, however, as the inner 293 packets do not change upon movements. 295 Similarly, when the Home Test messages tunneled from the home agent 296 are protected by IPsec, they MUST support at least the following 297 headers in the following order: 299 IPv6 header (source = home agent, 300 destination = care-of address) 301 ESP header 302 IPv6 header (source = correspondent node, 303 destination = home address) 304 Mobility Header 305 Home Test 307 The format used to protect return routability packets relies on the 308 destination of the tunnel packets to change for the mobile node as it 309 moves. The home agent's address stays the same, but the mobile 310 node's address changes upon movements, as if the security 311 association's tunnel gateway address had changed. When the mobile 312 node adopts a new care-of address, its source address selection rules 313 will automatically adopt a new source address for outgoing tunnel 314 packets. (The home agent accepts packets sent like this, as the 315 outer source address in tunnel packets is not checked.) 317 The process is more complicated in the home agent side, as the home 318 agent has stored the previous care-of address in its Security 319 Association Database as the gateway address. When IKE is being used, 320 the mobile node runs it on top of its then current care-of address, 321 and the resulting tunnel-mode security associations will use the same 322 addresses as IKE was transported on. In order for the home agent to 323 be able to tunnel a Home Test message to the mobile node, it uses the 324 current care-of address as the destination of the tunnel packets, as 325 if the home agent had modified the gateway address of the security 326 association used for this protection. This implies that the same 327 security association can be used in multiple locations, and no new 328 configuration or IKE rekeying is needed per movement. 330 3.3 Prefix Discovery 332 If IPsec is used to protect prefix discovery, requests for prefixes 333 from the mobile node to the home agent MUST support at least the 334 following headers in the following order. 336 IPv6 header (source = care-of address, 337 destination = home agent) 338 Destination Options header 339 Home Address option (home address) 340 ESP header 341 ICMPv6 342 Mobile Prefix Solicitation 344 Again if IPsec is used, solicited and unsolicited prefix information 345 advertisements from the home agent to the mobile node MUST support at 346 least the following headers in the following order. 348 IPv6 header (source = home agent, 349 destination = care-of address) 350 Routing header (type 2) 351 home address 352 ESP header 353 ICMPv6 354 Mobile Prefix Advertisement 356 3.4 Payload Packets 358 If IPsec is used to protect payload packets tunneled to the home 359 agent from the mobile node, a similar format is used as in the case 360 of tunneled Home Test Init messages. However, instead of the 361 Mobility Header these packets may contain any legal IPv6 protocol(s): 363 IPv6 header (source = care-of address, 364 destination = home agent) 365 ESP header 366 IPv6 header (source = home address, 367 destination = correspondent node) 368 Any protocol 370 Similarly, when the payload packets are tunneled from the home agent 371 to the mobile node with IPsec protection, they MUST support at least 372 the following headers in the following order: 374 IPv6 header (source = home agent, 375 destination = care-of address) 376 ESP header 377 IPv6 header (source = correspondent node, 378 destination = home address) 379 Any protocol 381 4. Requirements 383 This section describes mandatory rules for all Mobile IPv6 mobile 384 nodes and home agents. These rules are necessary in order for it to 385 be possible to enable IPsec communications despite movements, 386 guarantee sufficient security, and to ensure correct processing order 387 of packets. 389 The rules in the following sections apply only to the communications 390 between home agents and mobile nodes. They should not be taken as 391 requirements on how IPsec in general is used by mobile nodes. 393 4.1 Mandatory Support 395 The following requirements apply to both home agents and mobile 396 nodes: 398 o Manual configuration of security associations MUST be supported. 399 The configuration of the keys is expected to take place 400 out-of-band, for instance at the time the mobile node is 401 configured to use its home agent. 403 o Automatic key management with IKE [5] MAY be supported. Only 404 IKEv1 is discussed in this document, even if it is expected that 405 the next version of IKE can also be used and that it offers 406 several improvements in this specific application. 408 o IPsec protection for Binding Updates and Acknowledgements between 409 the mobile node and home agent MUST be supported and MUST be used. 411 o IPsec protection for the Home Test Init and Home Test messages 412 tunneled between the mobile node and home agent MUST be supported 413 and SHOULD be used. 415 o IPsec protection for the ICMPv6 messages related to prefix 416 discovery MUST be supported and SHOULD be used. 418 o IPsec protection of the payload packets tunneled between the 419 mobile node and home agent MAY be supported and used. 421 o If multicast group membership control protocols or stateful 422 address autoconfiguration protocols are supported, payload data 423 protection MUST be supported for those protocols. 425 4.2 Policy Requirements 427 The following requirements apply to both home agents and mobile 428 nodes: 430 o When a packet is matched against IPsec security policy or 431 selectors of a security association, an address appearing in a 432 Home Address destination option MUST be considered as the source 433 address of the packet. 435 o Similarly, a home address within a Type 2 Routing header MUST be 436 considered as the destination address of the packet, when a packet 437 is matched against IPsec security policy or selectors of a 438 security association. 440 o When IPsec is used to protect return routability signaling or 441 payload packets, the security policy database entries SHOULD be 442 defined specifically for the tunnel interface between the mobile 443 node and the home agent. That is, the policy entries are not 444 generally applied on all traffic on the physical interface(s) of 445 the nodes, but rather only on traffic that enters this tunnel. 447 o The authentication of mobile nodes MAY be based either on machine 448 or user credentials. Note that multi-user operating systems 449 typically allow all users of a node to use any of the IP addresses 450 assigned to the node. This limits the capability of the home 451 agent to restrict the use of a home address to a particular user 452 in such environment. Where user credentials are applied in a 453 multi-user environment, the configuration should authorize all 454 users of the node to control all home addresses assigned to the 455 node. 457 o When the mobile node returns home and de-registers with the Home 458 Agent, the tunnel between the home agent and the mobile node's 459 care-of address is torn down. The SPD entries, which were used 460 for protecting tunneled traffic between the mobile node and the 461 home agent become inactive. The corresponding security 462 associations could be stored or deleted depending on how they were 463 created. If the security associations were created dynamically 464 using IKE, they are automatically deleted when they expire. If 465 the security associations were created through manual 466 configuration, they MUST be retained and used later when the 467 mobile node moves aways from home again. The security 468 associations protecting Binding Updates and Acknowledgements, and 469 prefix discovery SHOULD not be deleted as they do not depend on 470 care-of addresses and can be used again. 472 The following rules apply to mobile nodes: 474 o The mobile node MUST use the Home Address destination option in 475 Binding Updates and Mobile Prefix Solicitations, sent to the home 476 agent from a care-of address. 478 o When the mobile node receives a changed set of prefixes from the 479 home agent during prefix discovery, there is a need to configure 480 new security policy entries, and there may be a need to configure 481 new security associations. It is outside the scope of this 482 specification to discuss automatic methods for this. 484 The following rules apply to home agents: 486 o The home agent MUST use the Type 2 Routing header in Binding 487 Acknowledgements and Mobile Prefix Advertisements sent to the 488 mobile node, again due to the need to have the home address 489 visible when the policy checks are made. 491 o It is necessary to avoid the possibility that a mobile node could 492 use its security association to send a Binding Update on behalf of 493 another mobile node using the same home agent. In order to do 494 this, the security policy database entries MUST unequivocally 495 identify a single security association for any given home address 496 and home agent when manual keying is used. When dynamic keying is 497 used, the security policy database entries MUST unequivocally 498 identify the IKE phase 1 credentials which can be used to 499 authorize the creation of security associations for a particular 500 home address. How these mappings are maintained is outside the 501 scope of this specification, but they may be maintained, for 502 instance, as a locally administered table in the home agent. If 503 the phase 1 identity is a FQDN, secure forms of DNS may also be 504 used. 506 o When the set of prefixes advertised by the home agent changes, 507 there is a need to configure new security policy entries, and 508 there may be a need to configure new security associations. It is 509 outside the scope of this specification to discuss automatic 510 methods for this, if new home addresses are required. 512 4.3 IPsec Protocol Processing 514 The following requirements apply to both home agents and mobile 515 nodes: 517 o When securing Binding Updates, Binding Acknowledgements, and 518 prefix discovery, both the mobile nodes and the home agents SHOULD 519 use the Encapsulating Security Payload (ESP) [4] header in 520 transport mode and MUST use a non-null payload authentication 521 algorithm to provide data origin authentication, connectionless 522 integrity and optional anti-replay protection. Note that 523 Authentication Header (AH) [3] is also possible but for brevity is 524 not discussed in this specification. 526 Mandatory support for encryption and integrity protection 527 algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC 528 2406 [4]. Care is needed when selecting suitable encryption 529 algorithms for ESP, however. Currently available integrity 530 protection algorithms are in general considered to be secure. The 531 encryption algorithm, DES, mandated by the current IPsec standards 532 is not, however. This is particularly problematic when security 533 associations are configured manually, as the same key is used for 534 a long time. 536 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 537 protection of packets belonging to the return routability 538 procedure. A non-null encryption transform and authentication 539 algorithm MUST be applied. 541 o IPsec AH [3] authenticator calculation MUST be performed as if a 542 packet with a Type 2 Routing header would have the home address in 543 the IPv6 destination address field and the care-of address in the 544 Routing header. Type 2 Routing header should be treated by IPsec 545 in the same manner as Type 0 Routing header. 547 o Similarly, the authenticator calculation MUST be performed as if a 548 packet with a Home Address destination option would have the home 549 address in the IPv6 source address field and the care-of address 550 in the destination option. 552 The following rules apply to mobile nodes: 554 o When ESP is used to protect Binding Updates, there is no 555 protection for the care-of address which appears in the IPv6 556 header outside the area protected by ESP. It is important for the 557 home agent to verify that the care-of address has not been 558 tampered. As a result, the attacker would have redirected the 559 mobile node's traffic to another address. In order to prevent 560 this, Mobile IPv6 implementations MUST use the Alternate Care-of 561 Address mobility option in registrations sent to the home agent. 562 (Note that AH protects also the IPv6 header, and some 563 implementations might avoid the option if they know AH is being 564 used.) 566 o When IPsec is used to protect return routability signaling or 567 payload packets, the mobile node MUST set the source address it 568 uses for the outgoing tunnel packets to the current primary 569 care-of address. The mobile node starts to use a new primary 570 care-of address immediately after sending a Binding Update to the 571 home agent to register this new address. 573 The following rules apply to home agents: 575 o When IPsec is used to protect return routability signaling or 576 payload packets, IPsec security associations are needed to provide 577 this protection. When the care-of address for the mobile node 578 changes as a result of an accepted Binding Update, special 579 treatment is needed for the next packets sent using these security 580 associations. The home agent MUST set the new care-of address as 581 the destination address of these packets, as if the destination 582 gateway address in the security association had changed. 584 4.4 Dynamic Keying 586 The following requirements apply to both home agents and mobile 587 nodes: 589 o If replay protection is required, dynamic keying MUST be used. 590 IPsec can provide replay protection only if dynamic keying is 591 used. This may not always be possible, and manual keying would be 592 preferred in some cases. IPsec also does not guarantee correct 593 ordering of packets, only that they have not been replayed. 594 Because of this, sequence numbers within the Mobile IPv6 messages 595 ensure correct ordering. However, if a home agent reboots and 596 loses its state regarding the sequence numbers, replay attacks 597 become possible. The use of a key management mechanism together 598 with IPsec can be used to prevent such replay attacks. 600 o If IKE version 1 is used with preshared secrets in main mode, it 601 determines the shared secret to use from the IP address of the 602 peer. With Mobile IPv6, however, this may be a care-of address 603 and does not indicate which mobile node attempts to contact the 604 home agent. Therefore, if preshared secret authentication is used 605 in IKEv1 between the mobile node and the home agent then 606 aggressive mode MUST be used. Note also that care needs to be 607 taken with phase 1 identity selection. Where the ID_IPV6_ADDR 608 Identity Payloads is used, unambiguous mapping of identities to 609 keys is not possible. (The next version of IKE may not have these 610 limitations.) 612 The following rules apply to mobile nodes: 614 o Where dynamic keying is used, the key management protocol MUST use 615 the care-of address as the source address in the protocol 616 exchanges with the mobile node's home agent. 618 o Conversely, the IPsec security associations with the mobile node's 619 home agent MUST be requested from the key management protocol with 620 the home address as the mobile node's address. 622 The security associations for protecting Binding Updates and 623 Acknowledgements are requested for the Mobility header protocol in 624 transport mode and for specific IP addresses as endpoints. 625 Similarly, the security associations for protecting prefix 626 discovery are requested for the ICMPv6 protocol. Security 627 associations for payload and return routability protection are 628 requested for a specific tunnel interface and either the payload 629 protocol or the Mobility header protocol, in tunnel mode. In this 630 case one requested endpoint is an IP address and another one is a 631 wildcard. 633 o If the mobile node has used IKE to establish security associations 634 with its home agent, it should follow the procedures discussed in 635 Section 11.7.1 and 11.7.3 of the base specification to determine 636 whether the IKE endpoints can be moved or if rekeying is needed. 638 The following rules apply to home agents: 640 o If the home agent has used IKE to establish security associations 641 with the mobile node, it should follow the procedures discussed in 642 Section 10.3.1 and 10.3.2 of the base specification to determine 643 whether the IKE endpoints can be moved or if rekeying is needed. 645 5. Example Configurations 647 In the following we describe the Security Policy Database (SPD) and 648 Security Association Database (SAD) entries necessary to protect 649 Binding Updates and Binding Acknowledgements exchanged between the 650 mobile node and the home agent. Our examples assume the use of ESP, 651 but a similar configuration could also be used to protect the 652 messages with AH. 654 Section 5.1 introduces the format we use in the description of the 655 SPD and the SAD. Section 5.2 describes how to configure manually 656 keyed security associations, and Section 5.3 describes how to use 657 dynamic keying. 659 5.1 Format 661 The format used in the examples is as follows. The SPD description 662 has the format 664 "SPD OUT:" 665 "-" 666 "-" 667 ... 668 "-" 670 "SPD IN:" 671 "-" 672 "-" 673 ... 674 "-" 676 Where represents the name of the node, and has the 677 following format: 679 "IF" "THEN USE" | 680 "IF" "THEN CREATE" | 682 Where is an boolean expression about the fields of the 683 IPv6 packet, is the name of a security association, and 684 is a specification for a security association to be 685 negotiated via IKE [5]. The SAD description has the format 687 "SAD:" 688 "-" 689 "-" 690 ... 691 "-" 693 Where represents the name of the node, and has the 694 following format: 696 "(" "," 697 "," 698 "," 699 "," 700 ")" ":" 701 703 Where is "IN" or "OUT", is the SPI of the security 704 association, is its destination, is normally 705 "ESP" in our case but could also be "AH", is either "TUNNEL" 706 or "TRANSPORT", and is a boolean expression about the 707 fields of the IPv6 packet. 709 We will be using an example mobile node in this section with the home 710 address "home_address_1". The user's identity in this mobile node is 711 "user_1". The home agent's address is "home_agent_1". 713 5.2 Manual Configuration 715 5.2.1 Binding Updates and Acknowledgements 717 Here are the contents of the SPD and SAD for protecting Binding 718 Updates and Acknowledgements: 720 mobile node SPD OUT: 721 - IF source = home_address_1 & destination = home_agent_1 & 722 proto = MH 723 THEN USE SA1 725 mobile node SPD IN: 726 - IF source = home_agent_1 & destination = home_address_1 & 727 proto = MH 728 THEN USE SA2 730 mobile node SAD: 731 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 732 source = home_address_1 & destination = home_agent_1 & 733 proto = MH 734 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 735 source = home_agent_1 & destination = home_address_1 & 736 proto = MH 738 home agent SPD OUT: 739 - IF source = home_agent_1 & destination = home_address_1 & 740 proto = MH 741 THEN USE SA2 743 home agent SPD IN: 744 - IF source = home_address_1 & destination = home_agent_1 & 745 proto = MH 746 THEN USE SA1 748 home agent SAD: 749 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 750 source = home_agent_1 & destination = home_address_1 & 751 proto = MH 752 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 753 source = home_address_1 & destination = home_agent_1 & 754 proto = MH 756 In the above, "MH" refers to the protocol number for the Mobility 757 Header [8]. 759 5.2.2 Return Routability Signaling 761 In the following we describe the necessary SPD and SAD entries to 762 protect return routability signaling between the mobile node and the 763 home agent. Note that the rules in the SPD are ordered, and the ones 764 in the previous section must take precedence over these ones: 766 mobile node SPD OUT: 767 - IF interface = tunnel to home_agent_1 & 768 source = home_address_1 & destination = any & 769 proto = MH 770 THEN USE SA3 772 mobile node SPD IN: 773 - IF interface = tunnel from home_agent_1 & 774 source = any & destination = home_address_1 & 775 proto = MH 776 THEN USE SA4 778 mobile node SAD: 779 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 780 source = home_address_1 & destination = any & proto = MH 781 - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): 782 source = any & destination = home_address_1 & proto = MH 784 home agent SPD OUT: 785 - IF interface = tunnel to home_address_1 & 786 source = any & destination = home_address_1 & 787 proto = MH 788 THEN USE SA4 790 home agent SPD IN: 791 - IF interface = tunnel from home_address_1 & 792 source = home_address_1 & destination = any & 793 proto = MH 794 THEN USE SA3 796 home agent SAD: 797 - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): 798 source = any & destination = home_address_1 & proto = MH 799 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 800 source = home_address_1 & destination = any & proto = MH 802 5.2.3 Prefix Discovery 804 In the following we describe some additional SPD and SAD entries to 805 protect prefix discovery. 807 mobile node SPD OUT: 808 - IF source = home_address_1 & destination = home_agent_1 & 809 proto = ICMPv6 810 THEN USE SA5. 812 mobile node SPD IN: 813 - IF source = home_agent_1 & destination = home_address_1 & 814 proto = ICMPv6 815 THEN USE SA6 817 mobile node SAD: 818 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 819 source = home_address_1 & destination = home_agent_1 & 820 proto = ICMPv6 821 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 822 source = home_agent_1 & destination = home_address_1 & 823 proto = ICMPv6 825 home agent SPD OUT: 826 - IF source = home_agent_1 & destination = home_address_1 & 827 proto = ICMPv6 828 THEN USE SA6 830 home agent SPD IN: 831 - IF source = home_address_1 & destination = home_agent_1 & 832 proto = ICMPv6 833 THEN USE SA5 835 home agent SAD: 836 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 837 source = home_agent_1 & destination = home_address_1 & 838 proto = ICMPv6 839 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 840 source = home_address_1 & destination = home_agent_1 & 841 proto = ICMPv6 843 Note that the SPDs described above protect all ICMPv6 traffic between 844 the mobile node and the home agent. 846 5.2.4 Payload Packets 848 It is also possible to perform some additional, optional, protection 849 of tunneled payload packets. This protection takes place in a 850 similar manner to the return routability protection above, but 851 requires a different value for the protocol field. The necessary SPD 852 and SAD entries are shown below. It is assumed that the entries for 853 protecting Binding Updates and Acknowledgements, and the entries to 854 protect Home Test Init and Home Test messages take precedence over 855 these entries. 857 mobile node SPD OUT: 858 - IF interface = tunnel to home_agent_1 & 859 source = home_address_1 & destination = any & 860 proto = X 861 THEN USE SA7 863 mobile node SPD IN: 864 - IF interface = tunnel from home_agent_1 & 865 source = any & destination = home_address_1 & 866 proto = X 867 THEN USE SA8 869 mobile node SAD: 870 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 871 source = home_address_1 & destination = any & proto = X 872 - SA8(IN, spi_h, home_address_1, ESP, TUNNEL): 873 source = any & destination = home_address_1 & proto = X 875 home agent SPD OUT: 876 - IF interface = tunnel to home_address_1 & 877 source = any & destination = home_address_1 & 878 proto = X 879 THEN USE SA8 881 home agent SPD IN: 882 - IF interface = tunnel from home_address_1 & 883 source = home_address_1 & destination = any & 884 proto = X 885 THEN USE SA7 887 home agent SAD: 888 - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): 889 source = any & destination = home_address_1 & proto = X 890 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 891 source = home_address_1 & destination = any & proto = X 893 If multicast group membership control protocols such as MLDv1 [9] or 894 MLDv2 [12] need to be protected, these packets may use a link-local 895 address rather than the home address of the mobile node. In this 896 case the source and destination can be left as a wildcard and the SPD 897 entries will work solely based on the used interface and the 898 protocol, which is ICMPv6 for both MLDv1 and MLDv2. 900 Similar problems are encountered when stateful address 901 autoconfiguration protocols such as DHCPv6 [10] are used. The same 902 approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP 903 protocol. 905 Support for multiple layers of encapsulation (such as ESP 906 encapsulated in ESP) is not required by RFC 2401 [2] and is also 907 otherwise often problematic. It is therefore useful to avoid setting 908 the protocol X in the above entries to either AH or ESP. 910 5.3 Dynamic Keying 912 In this section we show an example configuration that uses IKE to 913 negotiate security associations. 915 5.3.1 Binding Updates and Acknowledgements 917 Here are the contents of the SPD for protecting Binding Updates and 918 Acknowledgements: 920 mobile node SPD OUT: 921 - IF source = home_address_1 & destination = home_agent_1 & 922 proto = MH 923 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 925 mobile node SPD IN: 926 - IF source = home_agent_1 & destination = home_address_1 & 927 proto = MH 928 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 930 home agent SPD OUT: 931 - IF source = home_agent_1 & destination = home_address_1 & 932 proto = MH 933 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 935 home agent SPD IN: 936 - IF source = home_address_1 & destination = home_agent_1 & 937 proto = MH 938 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 940 We have omitted details of the proposed transforms in the above, and 941 all details related to the particular authentication method such as 942 certificates beyond listing a specific identity that must be used. 944 We require IKE to be run using the care-of addresses but still 945 negotiate IPsec SAs that use home addresses. The extra conditions 946 set by the home agent SPD for the peer phase 1 identity to be 947 "user_1" must be verified by the home agent. The purpose of the 948 condition is to ensure that the IKE phase 2 negotiation for a given 949 user's home address can't be requested by another user. In the 950 mobile node, we simply set our local identity to be "user_1". 952 These checks also imply that the configuration of the home agent is 953 user-specific: every user or home address requires a specific 954 configuration entry. It would be possible to alleviate the 955 configuration tasks by using certificates that have home addresses in 956 the Subject AltName field. However, it isn't clear if all IKE 957 implementations allow one address to be used for carrying the IKE 958 negotiations when another address is mentioned in the used 959 certificates. In any case, even this approach would have required 960 user-specific tasks in the certificate authority. 962 5.3.2 Return Routability Signaling 964 Protection for the return routability signaling can be configured in 965 a similar manner as above. 967 mobile node SPD OUT: 968 - IF interface = tunnel to home_agent_1 & 969 source = home_address_1 & destination = any & 970 proto = MH 971 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 972 local phase 1 identity = user_1 974 mobile node SPD IN: 975 - IF interface = tunnel from home_agent_1 & 976 source = any & destination = home_address_1 & 977 proto = MH 978 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 979 local phase 1 identity = user_1 981 home agent SPD OUT: 982 - IF interface = tunnel to home_address_1 & 983 source = any & destination = home_address_1 & 984 proto = MH 985 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 986 peer phase 1 identity = user_1 988 home agent SPD IN: 989 - IF interface = tunnel from home_address_1 & 990 source = home_address_1 & destination = any & 991 proto = MH 992 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 993 peer phase 1 identity = user_1 995 Here we specified the gateway address for the security association as 996 the home address for the mobile node. However, as required by 997 Section 4.3 the packets will actually be sent to the current care-of 998 address. In order to avoid writing dynamically changing information 999 to the SPD entries, the above has been written with the home address 1000 as the gateway. 1002 5.3.3 Prefix Discovery 1004 In the following we describe some additional SPD entries to protect 1005 prefix discovery with IKE. (Note that when actual new prefixes are 1006 discovered, there may be a need to enter new manually configured SPD 1007 entries to specify the authorization policy for the resulting new 1008 home addresses.) 1010 mobile node SPD OUT: 1011 - IF source = home_address_1 & destination = home_agent_1 & 1012 proto = ICMPv6 1013 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 1015 mobile node SPD IN: 1016 - IF source = home_agent_1 & destination = home_address_1 & 1017 proto = ICMPv6 1018 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 1020 home agent SPD OUT: 1021 - IF source = home_agent_1 & destination = home_address_1 & 1022 proto = ICMPv6 1023 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 1025 home agent SPD IN: 1026 - IF source = home_address_1 & destination = home_agent_1 & 1027 proto = ICMPv6 1028 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 1030 5.3.4 Payload Packets 1032 Protection for the payload packets happens similarly to the 1033 protection of return routability signaling. As in the manually keyed 1034 case, these SPD entries have lower priority than the above ones. 1036 mobile node SPD OUT: 1037 - IF interface = tunnel to home_agent_1 & 1038 source = home_address_1 & destination = any & 1039 proto = X 1040 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 1041 local phase 1 identity = user_1 1043 mobile node SPD IN: 1044 - IF interface = tunnel from home_agent_1 & 1045 source = any & destination = home_address_1 & 1046 proto = X 1047 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 1048 local phase 1 identity = user_1 1050 home agent SPD OUT: 1051 - IF interface = tunnel to home_address_1 & 1052 source = any & destination = home_address_1 & 1053 proto = X 1054 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1055 peer phase 1 identity = user_1 1057 home agent SPD IN: 1058 - IF interface = tunnel from home_address_1 & 1059 source = home_address_1 & destination = any & 1060 proto = X 1061 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1062 peer phase 1 identity = user_1 1064 6. Processing Steps within a Node 1066 6.1 Binding Update to the Home Agent 1068 Step 1. At the mobile node, Mobile IPv6 module first produces the 1069 following packet: 1071 IPv6 header (source = home address, 1072 destination = home agent) 1073 Mobility header 1074 Binding Update 1076 Step 2. This packet is matched against the IPsec policy data base on 1077 the mobile node and we make a note that IPsec must be applied. 1079 Step 3. Then, we add the necessary Mobile IPv6 options but do not 1080 change the addresses yet, as described in Section 11.2.2 of the base 1081 specification [8]. This results in: 1083 IPv6 header (source = home address, 1084 destination = home agent) 1085 Destination Options header 1086 Home Address option (care-of address) 1087 Mobility header 1088 Binding Update 1090 Step 4. Finally, IPsec headers are added and the necessary 1091 authenticator values are calculated: 1093 IPv6 header (source = home address, 1094 destination = home agent) 1095 Destination Options header 1096 Home Address option (care-of address) 1097 ESP header (SPI = spi_a) 1098 Mobility header 1099 Binding Update 1101 Step 5. Before sending the packet, the addresses in the IPv6 header 1102 and the Destination Options header are changed: 1104 IPv6 header (source = care-of address, 1105 destination = home agent) 1106 Destination Options header 1107 Home Address option (home address) 1108 ESP header (SPI = spi_a) 1109 Mobility header 1110 Binding Update 1112 6.2 Binding Update from the Mobile Node 1114 Step 1. The following packet is received at the home agent: 1116 IPv6 header (source = care-of address, 1117 destination = home agent) 1118 Destination Options header 1119 Home Address option (home address) 1120 ESP header (SPI = spi_a) 1121 Mobility header 1122 Binding Update 1124 Step 2. The home address option is processed first, which results in 1126 IPv6 header (source = home address, 1127 destination = home agent) 1128 Destination Options header 1129 Home Address option (care-of address) 1130 ESP header (SPI = spi_a) 1131 Mobility header 1132 Binding Update 1134 Step 3. ESP header is processed next, resulting in 1136 IPv6 header (source = home address, 1137 destination = home agent) 1138 Destination Options header 1139 Home Address option (care-of address) 1140 Mobility header 1141 Binding Update 1143 Step 4. This packet matches the security association selectors 1144 (source = home address, destination = home agent, proto = MH). 1146 Step 5. Mobile IPv6 processes the Binding Update. The Binding 1147 Update is delivered to the Mobile IPv6 module. 1149 6.3 Binding Acknowledgement to the Mobile Node 1151 Step 1. Mobile IPv6 produces the following packet: 1153 IPv6 header (source = home agent, 1154 destination = home address) 1155 Mobility header 1156 Binding Acknowledgement 1158 Step 2. This packet matches the IPsec policy entries, and we 1159 remember that IPsec has to be applied. 1161 Step 3. Then, we add the necessary Route Headers but do not change 1162 the addresses yet, as described in Section 9.6 of the base 1163 specification [8]. This results in: 1165 IPv6 header (source = home agent, 1166 destination = home address) 1167 Routing header (type 2) 1168 care-of address 1169 Mobility header 1170 Binding Acknowledgement 1172 Step 4. We apply IPsec: 1174 IPv6 header (source = home agent, 1175 destination = home address) 1176 Routing header (type 2) 1177 care-of address 1178 ESP header (SPI = spi_b) 1179 Mobility header 1180 Binding Acknowledgement 1182 Step 5. Finally, before sending the packet out we change the 1183 addresses in the IPv6 header and the Route header: 1185 IPv6 header (source = home agent, 1186 destination = care-of address) 1187 Routing header (type 2) 1188 home address 1189 ESP header (SPI = spi_b) 1190 Mobility header 1191 Binding Acknowledgement 1193 6.4 Binding Acknowledgement from the Home Agent 1195 Step 1. The following packet is received at the mobile node 1197 IPv6 header (source = home agent, 1198 destination = care-of address) 1199 Routing header (type 2) 1200 home address 1201 ESP header (SPI = spi_b) 1202 Mobility header 1203 Binding Acknowledgement 1205 Step 2. After the routing header is processed the packet becomes 1206 IPv6 header (source = home agent, 1207 destination = home address) 1208 Routing header (type 2) 1209 care-of address 1210 ESP header (SPI = spi_b) 1211 Mobility header 1212 Binding Acknowledgement 1214 Step 3. ESP header is processed next, resulting in: 1216 IPv6 header (source = home agent, 1217 destination = home address) 1218 Routing header (type 2) 1219 care-of address 1220 Mobility header 1221 Binding Acknowledgement 1223 Step 4. This packet matches the security association selectors 1224 (source = home agent, destination = home address, proto = MH). 1226 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 1227 module. 1229 6.5 Home Test Init to the Home Agent 1231 Step 1. The mobile node constructs a Home Test Init message: 1233 IPv6 header (source = home address, 1234 destination = correspondent node) 1235 Mobility header 1236 Home Test Init 1238 Step 2. Mobile IPv6 determines that this packet should go to the 1239 tunnel to the home agent. 1241 Step 3. The packet is matched against IPsec policy entries for the 1242 interface, and we find that IPsec needs to be applied. 1244 Step 4. IPsec tunnel mode headers are added. Note that we use a 1245 care-of address as a source address for the tunnel packet. 1247 IPv6 header (source = care-of address, 1248 destination = home agent) 1249 ESP header (SPI = spi_c) 1250 IPv6 header (source = home address, 1251 destination = correspondent node) 1252 Mobility header 1253 Home Test Init 1255 Step 5. The packet no longer satisfies the criteria that made it 1256 enter the tunnel, and it is sent directly to the home agent. 1258 6.6 Home Test Init from the Mobile Node 1260 Step 1. The home agent receives the following packet: 1262 IPv6 header (source = care-of address, 1263 destination = home agent) 1264 ESP header (SPI = spi_c) 1265 IPv6 header (source = home address, 1266 destination = correspondent node) 1267 Mobility Header 1268 Home Test Init 1270 Step 2. IPsec processing is performed, resulting in: 1272 IPv6 header (source = home address, 1273 destination = correspondent node) 1274 Mobility Header 1275 Home Test Init 1277 Step 3. The resulting packet matches the selectors and the packet 1278 can be processed further. 1280 Step 4. The packet is then forwarded to the correspondent node. 1282 6.7 Home Test to the Mobile Node 1284 Step 1. The home agent receives a Home Test packet from the 1285 correspondent node: 1287 IPv6 header (source = correspondent node, 1288 destination = home address) 1289 Mobility Header 1290 Home Test Init 1292 Step 2. The home agent determines that this packet is destined to a 1293 mobile node that is away from home, and decides to tunnel it. 1295 Step 3. The packet matches the IPsec policy entries for the tunnel 1296 interface, and we note that IPsec needs to be applied. 1298 Step 4. IPsec is applied, resulting in a new packet. Note that the 1299 home agent must keep track of the location of the mobile node, and 1300 update the tunnel gateway address in the security association(s) 1301 accordingly. 1303 IPv6 header (source = home agent, 1304 destination = care-of address) 1305 ESP header (SPI = spi_d) 1306 IPv6 header (source = correspondent node, 1307 destination = home address) 1308 Mobility Header 1309 Home Test Init 1311 Step 5. The packet no longer satisfies the criteria that made it 1312 enter the tunnel, and it is sent directly to the care-of address. 1314 6.8 Home Test from the Home Agent 1316 Step 1. The mobile node receives the following packet: 1318 IPv6 header (source = home agent, 1319 destination = care-of address) 1320 ESP header (SPI = spi_d) 1321 IPv6 header (source = correspondent node, 1322 destination = home address) 1323 Mobility Header 1324 Home Test Init 1326 Step 2. IPsec is processed, resulting in: 1328 IPv6 header (source = correspondent node, 1329 destination = home address) 1330 Mobility Header 1331 Home Test Init 1333 Step 3. This matches the security association selectors (source = 1334 any, destination = home address). 1336 Step 4. The packet is given to Mobile IPv6 processing. 1338 6.9 Prefix Solicitation Message to the Home Agent 1340 This procedure is similar to the one presented in Section 6.1. 1342 6.10 Prefix Solicitation Message from the Mobile Node 1344 This procedure is similar to the one presented in Section 6.2. 1346 6.11 Prefix Advertisement Message to the Mobile Node 1348 This procedure is similar to the one presented in Section 6.3. 1350 6.12 Prefix Advertisement Message from the Home Agent 1352 This procedure is similar to the one presented in Section 6.4. 1354 6.13 Payload Packet to the Home Agent 1356 This procedure is similar to the one presented in Section 6.5. 1358 6.14 Payload Packet from the Mobile Node 1360 This procedure is similar to the one presented in Section 6.6. 1362 6.15 Payload Packet to the Mobile Node 1364 This procedure is similar to the one presented in Section 6.7. 1366 6.16 Payload Packet from the Home Agent 1368 This procedure is similar to the one presented in Section 6.8. 1370 6.17 Establishing New Security Associations 1372 Step 1. The mobile node wishes to send a Binding Update to the home 1373 agent. 1375 IPv6 header (source = home address, 1376 destination = home agent) 1377 Mobility header 1378 Binding Update 1380 Step 2. There is no existing security association to protect the 1381 Binding Update, so IKE is initiated. The IKE packets are sent as 1382 shown in the following examples. The first packet is an example of 1383 an IKE packet sent from the mobile node, and the second one is from 1384 the home agent. The examples shows also that the phase 1 identity 1385 used for the mobile node is a FQDN. 1387 IPv6 header (source = care-of address, 1388 destination = home agent) 1389 UDP 1390 IKE 1391 ... IDii = ID_FQDN mn123.ha.net ... 1393 IPv6 header (source = home agent 1394 destination = care-of address) 1395 UDP 1396 IKE 1397 ... IDir = ID_FQDN ha.net ... 1399 Step 3. IKE phase 1 completes, and phase 2 is initiated to request 1400 security associations for protecting traffic between the mobile 1401 node's home address and the home agent. This involves sending and 1402 receiving additional IKE packets. The below example shows again one 1403 packet sent by the mobile node and another sent by the home agent. 1404 The example shows also that the phase 2 identity used for the mobile 1405 node is the mobile node's home address. 1407 IPv6 header (source = care-of address, 1408 destination = home agent) 1409 UDP 1410 IKE 1411 ... IDci = ID_IPV6_ADDR home address ... 1413 IPv6 header (source = home agent, 1414 destination = care-of address) 1415 UDP 1416 IKE 1417 ... IDcr = ID_IPV6_ADDR home agent ... 1419 Step 4. The remaining steps are as shown in Section 6.1. 1421 6.18 Rekeying Security Associations 1423 Step 1. The mobile node and the home agent have existing security 1424 associations. Either side may decide at any time that the security 1425 associations need to be rekeyed, for instance, because the specified 1426 lifetime is approaching. 1428 Step 2. Mobility header packets sent during rekey may be protected 1429 by the existing security associations. 1431 Step 3. When the rekeying is finished, new security associations are 1432 established. In practice there is a time interval during which an 1433 old, about-to-expire security association and newly established 1434 security association will both exist. The new ones should be used as 1435 soon as they become available. 1437 Step 4. A notification of the deletion of the old security 1438 associations is received. After this, only the new security 1439 associations can be used. 1441 Note that there is no requirement that the existence of the IPsec and 1442 IKE security associations is tied to the existence of bindings. It 1443 is not necessary to delete a security association if a binding is 1444 removed, as a new binding may soon be established after this. 1446 Since cryptographic acceleration hardware may only be able to handle 1447 a limited number of active security associations, security 1448 associations may be deleted via IKE in order to keep the number of 1449 active cryptographic contexts to a minimum. Such deletions should 1450 not be interpreted as a sign of losing a contact to the peer or as a 1451 reason to remove a binding. Rather, if additional traffic needs to 1452 be sent, it is preferable to bring up another security association to 1453 protect it. 1455 6.19 Movements and Dynamic Keying 1457 In this section we describe the sequence of events that relate to 1458 movement with IKE-based security associations. In the initial state, 1459 the mobile node is not registered in any location and has no security 1460 associations with the home agent. Depending on whether the peers 1461 will be able to move IKE endpoints to new care-of addresses, the 1462 actions taken in Step 9 and 10 are different. 1464 Step 1. Mobile node with the home address A moves to care-of address 1465 B. 1467 Step 2. Mobile node runs IKE from care-of address B to the home 1468 agent, establishing a phase 1. 1470 Step 3. Protected by this phase 1, mobile node establishes a pair of 1471 security associations for protecting Mobility Header traffic to and 1472 from the home address A. 1474 Step 4. Mobile node sends a Binding Update and receives a Binding 1475 Acknowledgement using the security associations created in Step 3. 1477 Step 5. Mobile node establishes a pair of security associations for 1478 protecting return routability packets. These security associations 1479 are in tunnel mode and their endpoint in the mobile node side is 1480 care-of address B. For the purposes of our example, this step uses 1481 the phase 1 connection established in Step 2. Multiple phase 1 1482 connections are also possible. 1484 Step 6. The mobile node uses the security associations created in 1485 Step 5 to run return routability. 1487 Step 7. The mobile node moves to a new location and adopts a new 1488 care-of address C. 1490 Step 8. Mobile node sends a Binding Update and receives a Binding 1491 Acknowledgement using the security associations created in Step 3. 1492 The home agent ensures that the next packets sent using the security 1493 associations created in Step 5 will have the new care-of address as 1494 their destination address, as if the destination gateway address in 1495 the security association had changed. 1497 Step 9. If the mobile node and the HA have the capability to change 1498 the IKE endpoints, they change the address to C. If they dont have 1499 the capability, both nodes remove their phase 1 connections created 1500 on top of the care-of address B and establish a new IKE phase 1 on 1501 top of the care-of address C. This capability to change the IKE 1502 phase 1 end points is indicated through setting the Key Management 1503 Mobility Capability (K) flag [8] in the Binding Update and Binding 1504 Acknowledgement messages. 1506 Step 10. If a new IKE phase 1 connection was setup after movement, 1507 the MN will not be able to receive any notifications delivered on top 1508 of the old IKE phase 1 security association. Notifications delivered 1509 on top of the new security association are received and processed 1510 normally. If the mobile node and HA were able to update the IKE 1511 endpoints, they can continue using the same IKE phase 1 connection. 1513 7. Implementation Considerations 1515 We have chosen to require an encapsulation format for return 1516 routability and payload packet protection which can only be realized 1517 if the destination of the IPsec packets sent from the home agent can 1518 be changed as the mobile node moves. One of the main reasons for 1519 choosing such a format is that it removes the overhead of twenty four 1520 bytes when a home address option or routing header is added to the 1521 tunneled packet. What is needed is that the home agent must act as 1522 if the gateway address of a security association to the mobile node 1523 would have changed. Implementations are free to choose any 1524 particular method to make this change, such as using an API to the 1525 IPsec implementation to change the parameters of the security 1526 association, removing the security association and installing a new 1527 one, or modification of the packet after it has gone through IPsec 1528 processing. The only requirement is that after registering a new 1529 binding at the home agent, the next IPsec packets sent on this 1530 security association will be addressed to the new care-of address. 1532 We have also chosen to require that a dynamic key management protocol 1533 must be able to make an authorization decision for IPsec security 1534 association creation with different addresses than with what the key 1535 management protocol is run. We expect this to be done typically by 1536 configuring the allowed combinations of phase 1 user identities and 1537 home addresses. 1539 The base Mobile IPv6 specification sets high requirements for a 1540 so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As 1541 Mobile IPv6 specific modifications of the packets are required after 1542 IPsec processing, the BITS implementation has to perform also some 1543 tasks related to mobility. This may increase the complexity of the 1544 implementation, even if it already performs some tasks of the IP 1545 layer (such as fragmentation). 1547 We have chosen to require policy entries that are specific to a 1548 tunnel interface. This means that implementations have to regard the 1549 Home Agent - Mobile Node tunnel as a separate interface on which 1550 IPsec SPDs can be based. 1552 A further complication of the IPsec processing on a tunnel interface 1553 is that this requires access to the BITS implementation before the 1554 packet actually goes out. 1556 When certificate authentication is used, IKE fragmentation can be 1557 encountered. This can occur when certificate chains are used, or 1558 even with single certificates if they are large. Many firewalls do 1559 not handle fragments properly, and may drop them. Routers in the 1560 path may also discard fragments after the initial one, since they 1561 typically will not contain full IP headers that can be compared 1562 against an access list. Where fragmentation occurs, the endpoints 1563 will not always be able to establish a security association. 1565 Fortunately, typical Mobile IPv6 deployment uses short certificate 1566 chains, as the mobile node is communicating directly with its home 1567 network. Nevertheless, where the problem appears, one solution is to 1568 replace the firewalls or routers with equipment that can properly 1569 support fragments. If this cannot be done, it may help to store the 1570 peer certificates locally, or to obtain them through other means. 1572 8. IANA Considerations 1574 No IANA actions are necessary based on this document. IANA actions 1575 for the Mobile IPv6 protocol itself have been covered in [8]. 1577 9. Security Considerations 1579 The Mobile IPv6 base specification [8] requires strong security 1580 between the mobile node and the home agent. This memo discusses how 1581 that security can be arranged in practice, using IPsec. 1583 Normative References 1585 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1586 Levels", BCP 14, RFC 2119, March 1997. 1588 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1589 Internet Protocol", RFC 2401, November 1998. 1591 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1592 November 1998. 1594 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1595 (ESP)", RFC 2406, November 1998. 1597 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1598 RFC 2409, November 1998. 1600 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1601 Specification", RFC 2460, December 1998. 1603 [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1604 Specification", RFC 2473, December 1998. 1606 [8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1607 IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), February 1608 2003. 1610 Informative References 1612 [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1613 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1615 [10] Droms, R., "Dynamic Host Configuration Protocol for IPv6 1616 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 1617 November 2002. 1619 [11] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, 1620 "Negotiation of NAT-Traversal in the IKE", 1621 draft-ietf-ipsec-nat-t-ike-04 (work in progress), November 1622 2002. 1624 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1625 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 1626 December 2002. 1628 Authors' Addresses 1630 Jari Arkko 1631 Ericsson 1632 Jorvas 02420 1633 Finland 1635 EMail: jari.arkko@ericsson.com 1637 Vijay Devarapalli 1638 Nokia Research Center 1639 313 Fairchild Drive 1640 Mountain View CA 94043 1641 USA 1643 EMail: vijayd@iprg.nokia.com 1645 Francis Dupont 1646 ENST Bretagne 1647 Campus de Rennes 2, rue de la Chataigneraie 1648 BP 78 1649 Cesson-Sevigne Cedex 35512 1650 France 1652 EMail: Francis.Dupont@enst-bretagne.fr 1654 Appendix A. Acknowledgements 1656 The authors would like to thank Greg O'Shea, Michael Thomas, Kevin 1657 Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, and Gabriel 1658 Montenegro for interesting discussions in this problem space. 1660 Appendix B. Changes from Previous Version 1662 The following changes have been made to this document from version 1663 02: 1665 o The wire format for de-registration when returning home has been 1666 updated. The Alternate Care-of Address option is no longer used 1667 in this situation (tracked issue 270). 1669 o An IANA considerations section has been added (tracked issue 265). 1671 o IPsec protocol and mode requirements have now been stated as 1672 minimal requirements and no longer prevent the use of other 1673 protocols (AH) and modes (tracked issue 228). 1675 o Some editorial modifications have been performed. 1677 Intellectual Property Statement 1679 The IETF takes no position regarding the validity or scope of any 1680 intellectual property or other rights that might be claimed to 1681 pertain to the implementation or use of the technology described in 1682 this document or the extent to which any license under such rights 1683 might or might not be available; neither does it represent that it 1684 has made any effort to identify any such rights. Information on the 1685 IETF's procedures with respect to rights in standards-track and 1686 standards-related documentation can be found in BCP-11. Copies of 1687 claims of rights made available for publication and any assurances of 1688 licenses to be made available, or the result of an attempt made to 1689 obtain a general license or permission for the use of such 1690 proprietary rights by implementors or users of this specification can 1691 be obtained from the IETF Secretariat. 1693 The IETF invites any interested party to bring to its attention any 1694 copyrights, patents or patent applications, or other proprietary 1695 rights which may cover technology that may be required to practice 1696 this standard. Please address the information to the IETF Executive 1697 Director. 1699 Full Copyright Statement 1701 Copyright (C) The Internet Society (2003). All Rights Reserved. 1703 This document and translations of it may be copied and furnished to 1704 others, and derivative works that comment on or otherwise explain it 1705 or assist in its implementation may be prepared, copied, published 1706 and distributed, in whole or in part, without restriction of any 1707 kind, provided that the above copyright notice and this paragraph are 1708 included on all such copies and derivative works. However, this 1709 document itself may not be modified in any way, such as by removing 1710 the copyright notice or references to the Internet Society or other 1711 Internet organizations, except as needed for the purpose of 1712 developing Internet standards in which case the procedures for 1713 copyrights defined in the Internet Standards process must be 1714 followed, or as required to translate it into languages other than 1715 English. 1717 The limited permissions granted above are perpetual and will not be 1718 revoked by the Internet Society or its successors or assignees. 1720 This document and the information contained herein is provided on an 1721 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1722 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1723 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1724 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1725 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1727 Acknowledgement 1729 Funding for the RFC Editor function is currently provided by the 1730 Internet Society.