idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-03.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. 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 (February 18, 2003) is 7739 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 1613, 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: 7 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: August 19, 2003 V. Devarapalli 5 Nokia Research Center 6 F. Dupont 7 ENST Bretagne 8 February 18, 2003 10 Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and 11 Home Agents 12 draft-ietf-mobileip-mipv6-ha-ipsec-03.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 August 19, 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. Security Considerations . . . . . . . . . . . . . . . . . . 40 98 Normative References . . . . . . . . . . . . . . . . . . . . 41 99 Informative References . . . . . . . . . . . . . . . . . . . 42 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 101 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 102 B. Changes from Previous Version . . . . . . . . . . . . . . . 44 103 Intellectual Property and Copyright Statements . . . . . . . 45 105 1. Introduction 107 This document illustrates the use of IPsec in securing control 108 traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node 109 is always expected to be addressable at its home address, whether it 110 is currently attached to its home link or is away from home. The 111 "home address" is an IP address assigned to the mobile node within 112 its home subnet prefix on its home link. While a mobile node is at 113 home, packets addressed to its home address are routed to the mobile 114 node's home link. 116 While a mobile node is attached to some foreign link away from home, 117 it is also addressable at a care-of addresses. A care-of address is 118 an IP address associated with a mobile node that has the subnet 119 prefix of a particular foreign link. The association between a 120 mobile node's home address and care-of address is known as a 121 "binding" for the mobile node. While away from home, a mobile node 122 registers its primary care-of address with a router on its home link, 123 requesting this router to function as the "home agent" for the mobile 124 node. The mobile node performs this binding registration by sending 125 a "Binding Update" message to the home agent. The home agent replies 126 to the mobile node by returning a "Binding Acknowledgement" message. 128 Any other nodes communicating with a mobile node are referred to as 129 "correspondent nodes". Mobile nodes can provide information about 130 their current location to correspondent nodes, again using Binding 131 Updates and Acknowledgements. Additionally, return routability test 132 is performed between the mobile node, home agent, and the 133 correspondent node in order to authorize the establishment of the 134 binding. Packets between the mobile node and the correspondent node 135 are either tunneled via the home agent, or sent directly if a binding 136 exists in the correspondent node for the current location of the 137 mobile node. 139 Mobile IPv6 tunnels payload packets between the mobile node and the 140 home agent in both directions. This tunneling uses IPv6 141 encapsulation [7]. Where these tunnels need to be secured, they are 142 replaced by IPsec tunnels [2]. 144 Mobile IPv6 also provides support for the reconfiguration of the home 145 network. Here the home subnet prefixes may change over time. Mobile 146 nodes can learn new information about home subnet prefixes through 147 the "prefix discovery" mechanism. 149 This document discusses security mechanisms for the control traffic 150 between the mobile node and the home agent. If this traffic is not 151 protected, mobile nodes and correspondent nodes are vulnerable to 152 Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and 153 Denial-of-Service attacks. Any third parties are also vulnerable to 154 Denial-of-Service attacks. These threats are discussed in more 155 detail in Section 15.1 of the Mobile IPv6 base specification [8]. 157 In order to avoid these attacks, the base specification uses IPsec 158 [2] to protect control traffic between the home agent and the mobile 159 node. This control traffic consists of various messages carried by 160 the Mobility Header protocol in IPv6 [6]. The traffic takes the 161 following forms: 163 o Binding Update and Acknowledgement messages exchanged between the 164 mobile node and the home agent, as described in Sections 10.3.1, 165 10.3.2, 11.7.1, and 11.7.3 of the base specification [8]. 167 o Return routability messages Home Test Init and Home Test that pass 168 through the home agent on their way to a correspondent node, as 169 described in Section 10.4.6 of the base specification [8]. 171 o ICMPv6 messages exchanged between the mobile node and the home 172 agent for the purposes of prefix discovery, as described in 173 Sections 10.6 and 11.4 of the base specification [8]. 175 The nodes may also optionally protect payload traffic passing through 176 the home agent, as described in Section 5.3 of the base specification 177 [8]. If multicast group membership control protocols or stateful 178 address autoconfiguration protocols are supported, payload data 179 protection support is required. 181 The control traffic between the mobile node and the home agent 182 requires message authentication, integrity, correct ordering and 183 replay protection. The mobile node and the home agent must have a 184 security association to protect this traffic. Furthermore, great 185 care is needed when using IKE [5] to establish security associations 186 to Mobile IPv6 home agents. The right kind of addresses must be used 187 for transporting IKE. This is necessary to avoid circular 188 dependencies in which the use of a Binding Update triggers the need 189 for an IKE exchange that cannot complete prior to the Binding Update 190 having been completed. 192 The mobile IPv6 base document defines the main requirements the 193 mobile nodes and home agents must follow when securing the above 194 traffic. This document discusses these requirements in more depth, 195 illustrates the used packet formats, describes suitable configuration 196 procedures, and shows how implementations can process the packets in 197 the right order. 199 We begin our description by showing the required wire formats for the 200 protected packets in Section 3. Section 4 describes rules which 201 associated Mobile IPv6, IPsec, and IKE implementations must observe. 202 Section 5 discusses how IPsec can be configured to use either manual 203 or automatically established security associations. Section 6 shows 204 examples of how packets are processed within the nodes. 206 All implementations of Mobile IPv6 mobile node and home agent MUST 207 support at least the formats described in Section 3 and obey the 208 rules in Section 4. The configuration and processing sections are 209 informative, and should only be considered as one possible way of 210 providing the required functionality. 212 2. Terminology 214 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in RFC 2119 [1]. 218 3. Packet Formats 220 3.1 Binding Updates and Acknowledgements 222 When the mobile node is away from its home, the BUs sent by it to the 223 home agent MUST support at least the following headers in the 224 following order: 226 IPv6 header (source = care-of address, 227 destination = home agent) 228 Destination Options header 229 Home Address option (home address) 230 ESP header 231 Mobility header 232 Binding Update 233 Alternative Care-of Address option (care-of address) 235 Note that the Alternative Care-of Address option is used to ensure 236 that the care-of address is protected by ESP. The home agent 237 considers the address within this option as the current care-of 238 address for the mobile node. 240 The Binding Acknowledgements sent back to the mobile node when it is 241 away from home MUST have at least the following headers in the 242 following order: 244 IPv6 header (source = home agent, 245 destination = care-of address) 246 Routing header (type 2) 247 home address 248 ESP header 249 Mobility header 250 Binding Acknowledgement 252 When the mobile node is at home, the above rules are different as the 253 mobile node can use its home address as a source address. This 254 typically happens for the de-registration Binding Update when the 255 mobile is returning home. In this situation, the Binding Updates 256 MUST support at least the following headers in the following order: 258 IPv6 header (source = home address, 259 destination = home agent) 260 ESP header 261 Mobility header 262 Binding Update 263 Alternative Care-of Address option (care-of address) 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 all Binding Updates sent to the home 562 agent. (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. Payload and 627 return routability protection requests security associations for a 628 specific tunnel interface and either the payload protocol or the 629 Mobility header protocol, in tunnel mode. In this case one 630 requested endpoint is an IP address and another one is a wildcard. 632 o If the mobile node has used IKE to establish security associations 633 with its home agent, it should follow the procedures discussed in 634 Section 11.7.1 and 11.7.3 of the base specification to determine 635 whether the IKE endpoints can be moved or if rekeying is needed. 637 The following rules apply to home agents: 639 o If the home agent has used IKE to establish security associations 640 with the mobile node, it should follow the procedures discussed in 641 Section 10.3.1 and 10.3.2 of the base specification to determine 642 whether the IKE endpoints can be moved or if rekeying is needed. 644 5. Example Configurations 646 In the following we describe the Security Policy Database (SPD) and 647 Security Association Database (SAD) entries necessary to protect 648 Binding Updates and Binding Acknowledgements exchanged between the 649 mobile node and the home agent. Our examples assume the use of ESP, 650 but a similar configuration could also be used to protect the 651 messages with AH. 653 Section 5.1 introduces the format we use in the description of the 654 SPD and the SAD. Section 5.2 describes how to configure manually 655 keyed security associations, and Section 5.3 describes how to use 656 dynamic keying. 658 5.1 Format 660 The format used in the examples is as follows. The SPD description 661 has the format 663 "SPD OUT:" 664 "-" 665 "-" 666 ... 667 "-" 669 "SPD IN:" 670 "-" 671 "-" 672 ... 673 "-" 675 Where represents the name of the node, and has the 676 following format: 678 "IF" "THEN USE" | 679 "IF" "THEN CREATE" | 681 Where is an boolean expression about the fields of the 682 IPv6 packet, is the name of a security association, and 683 is a specification for a security association to be 684 negotiated via IKE [5]. The SAD description has the format 686 "SAD:" 687 "-" 688 "-" 689 ... 690 "-" 692 Where represents the name of the node, and has the 693 following format: 695 "(" "," 696 "," 697 "," 698 "," 699 ")" ":" 700 702 Where is "IN" or "OUT", is the SPI of the security 703 association, is its destination, is normally 704 "ESP" in our case but could also be "AH", is either "TUNNEL" 705 or "TRANSPORT", and is a boolean expression about the 706 fields of the IPv6 packet. 708 We will be using an example mobile node in this section with the home 709 address "home_address_1". The user's identity in this mobile node is 710 "user_1". The home agent's address is "home_agent_1". 712 5.2 Manual Configuration 714 5.2.1 Binding Updates and Acknowledgements 716 Here are the contents of the SPD and SAD for protecting Binding 717 Updates and Acknowledgements: 719 mobile node SPD OUT: 720 - IF source = home_address_1 & destination = home_agent_1 & 721 proto = MH 722 THEN USE SA1 724 mobile node SPD IN: 725 - IF source = home_agent_1 & destination = home_address_1 & 726 proto = MH 727 THEN USE SA2 729 mobile node SAD: 730 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 731 source = home_address_1 & destination = home_agent_1 & 732 proto = MH 733 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 734 source = home_agent_1 & destination = home_address_1 & 735 proto = MH 737 home agent SPD OUT: 738 - IF source = home_agent_1 & destination = home_address_1 & 739 proto = MH 740 THEN USE SA2 742 home agent SPD IN: 743 - IF source = home_address_1 & destination = home_agent_1 & 744 proto = MH 745 THEN USE SA1 747 home agent SAD: 748 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 749 source = home_agent_1 & destination = home_address_1 & 750 proto = MH 751 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 752 source = home_address_1 & destination = home_agent_1 & 753 proto = MH 755 In the above, "MH" refers to the protocol number for the Mobility 756 Header [8]. 758 5.2.2 Return Routability Signaling 760 In the following we describe the necessary SPD and SAD entries to 761 protect return routability signaling between the mobile node and the 762 home agent. Note that the rules in the SPD are ordered, and the ones 763 in the previous section must take precedence over these ones: 765 mobile node SPD OUT: 766 - IF interface = tunnel to home_agent_1 & 767 source = home_address_1 & destination = any & 768 proto = MH 769 THEN USE SA3 771 mobile node SPD IN: 772 - IF interface = tunnel from home_agent_1 & 773 source = any & destination = home_address_1 & 774 proto = MH 775 THEN USE SA4 777 mobile node SAD: 778 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 779 source = home_address_1 & destination = any & proto = MH 780 - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): 781 source = any & destination = home_address_1 & proto = MH 783 home agent SPD OUT: 784 - IF interface = tunnel to home_address_1 & 785 source = any & destination = home_address_1 & 786 proto = MH 787 THEN USE SA4 789 home agent SPD IN: 790 - IF interface = tunnel from home_address_1 & 791 source = home_address_1 & destination = any & 792 proto = MH 793 THEN USE SA3 795 home agent SAD: 796 - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): 797 source = any & destination = home_address_1 & proto = MH 798 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 799 source = home_address_1 & destination = any & proto = MH 801 5.2.3 Prefix Discovery 803 In the following we describe some additional SPD and SAD entries to 804 protect prefix discovery. 806 mobile node SPD OUT: 807 - IF source = home_address_1 & destination = home_agent_1 & 808 proto = ICMPv6 809 THEN USE SA5. 811 mobile node SPD IN: 812 - IF source = home_agent_1 & destination = home_address_1 & 813 proto = ICMPv6 814 THEN USE SA6 816 mobile node SAD: 817 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 818 source = home_address_1 & destination = home_agent_1 & 819 proto = ICMPv6 820 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 821 source = home_agent_1 & destination = home_address_1 & 822 proto = ICMPv6 824 home agent SPD OUT: 825 - IF source = home_agent_1 & destination = home_address_1 & 826 proto = ICMPv6 827 THEN USE SA6 829 home agent SPD IN: 830 - IF source = home_address_1 & destination = home_agent_1 & 831 proto = ICMPv6 832 THEN USE SA5 834 home agent SAD: 835 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 836 source = home_agent_1 & destination = home_address_1 & 837 proto = ICMPv6 838 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 839 source = home_address_1 & destination = home_agent_1 & 840 proto = ICMPv6 842 Note that the SPDs described above protect all ICMPv6 traffic between 843 the mobile node and the home agent. 845 5.2.4 Payload Packets 847 It is also possible to perform some additional, optional, protection 848 of tunneled payload packets. This protection takes place in a 849 similar manner to the return routability protection above, but 850 requires a different value for the protocol field. The necessary SPD 851 and SAD entries are shown below. It is assumed that the entries for 852 protecting Binding Updates and Acknowledgements, and the entries to 853 protect Home Test Init and Home Test messages take precedence over 854 these entries. 856 mobile node SPD OUT: 857 - IF interface = tunnel to home_agent_1 & 858 source = home_address_1 & destination = any & 859 proto = X 860 THEN USE SA7 862 mobile node SPD IN: 863 - IF interface = tunnel from home_agent_1 & 864 source = any & destination = home_address_1 & 865 proto = X 866 THEN USE SA8 868 mobile node SAD: 869 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 870 source = home_address_1 & destination = any & proto = X 871 - SA8(IN, spi_h, home_address_1, ESP, TUNNEL): 872 source = any & destination = home_address_1 & proto = X 874 home agent SPD OUT: 875 - IF interface = tunnel to home_address_1 & 876 source = any & destination = home_address_1 & 877 proto = X 878 THEN USE SA8 880 home agent SPD IN: 881 - IF interface = tunnel from home_address_1 & 882 source = home_address_1 & destination = any & 883 proto = X 884 THEN USE SA7 886 home agent SAD: 887 - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): 888 source = any & destination = home_address_1 & proto = X 889 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 890 source = home_address_1 & destination = any & proto = X 892 If multicast group membership control protocols such as MLDv1 [9] or 893 MLDv2 [12] need to be protected, these packets may use a link-local 894 address rather than the home address of the mobile node. In this 895 case the source and destination can be left as a wildcard and the SPD 896 entries will work solely based on the used interface and the 897 protocol, which is ICMPv6 for both MLDv1 and MLDv2. 899 Similar problems are encountered when stateful address 900 autoconfiguration protocols such as DHCPv6 [10] are used. The same 901 approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP 902 protocol. 904 Support for multiple layers of encapsulation (such as ESP 905 encapsulated in ESP) is not required by RFC 2401 [2] and is also 906 otherwise often problematic. It is therefore useful to avoid setting 907 the protocol X in the above entries to either AH or ESP. 909 5.3 Dynamic Keying 911 In this section we show an example configuration that uses IKE to 912 negotiate security associations. 914 5.3.1 Binding Updates and Acknowledgements 916 Here are the contents of the SPD for protecting Binding Updates and 917 Acknowledgements: 919 mobile node SPD OUT: 920 - IF source = home_address_1 & destination = home_agent_1 & 921 proto = MH 922 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 924 mobile node SPD IN: 925 - IF source = home_agent_1 & destination = home_address_1 & 926 proto = MH 927 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 929 home agent SPD OUT: 930 - IF source = home_agent_1 & destination = home_address_1 & 931 proto = MH 932 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 934 home agent SPD IN: 935 - IF source = home_address_1 & destination = home_agent_1 & 936 proto = MH 937 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 939 We have omitted details of the proposed transforms in the above, and 940 all details related to the particular authentication method such as 941 certificates beyond listing a specific identity that must be used. 943 We require IKE to be run using the care-of addresses but still 944 negotiate IPsec SAs that use home addresses. The extra conditions 945 set by the home agent SPD for the peer phase 1 identity to be 946 "user_1" must be verified by the home agent. The purpose of the 947 condition is to ensure that the IKE phase 2 negotiation for a given 948 user's home address can't be requested by another user. In the 949 mobile node, we simply set our local identity to be "user_1". 951 These checks also imply that the configuration of the home agent is 952 user-specific: every user or home address requires a specific 953 configuration entry. It would be possible to alleviate the 954 configuration tasks by using certificates that have home addresses in 955 the Subject AltName field. However, it isn't clear if all IKE 956 implementations allow one address to be used for carrying the IKE 957 negotiations when another address is mentioned in the used 958 certificates. In any case, even this approach would have required 959 user-specific tasks in the certificate authority. 961 5.3.2 Return Routability Signaling 963 Protection for the return routability signaling can be configured in 964 a similar manner as above. 966 mobile node SPD OUT: 967 - IF interface = tunnel to home_agent_1 & 968 source = home_address_1 & destination = any & 969 proto = MH 970 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 971 local phase 1 identity = user_1 973 mobile node SPD IN: 974 - IF interface = tunnel from home_agent_1 & 975 source = any & destination = home_address_1 & 976 proto = MH 977 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 978 local phase 1 identity = user_1 980 home agent SPD OUT: 981 - IF interface = tunnel to home_address_1 & 982 source = any & destination = home_address_1 & 983 proto = MH 984 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 985 peer phase 1 identity = user_1 987 home agent SPD IN: 988 - IF interface = tunnel from home_address_1 & 989 source = home_address_1 & destination = any & 990 proto = MH 991 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 992 peer phase 1 identity = user_1 994 Here we specified the gateway address for the security association as 995 the home address for the mobile node. However, as required by 996 Section 4.3 the packets will actually be sent to the current care-of 997 address. In order to avoid writing dynamically changing information 998 to the SPD entries, the above has been written with the home address 999 as the gateway. 1001 5.3.3 Prefix Discovery 1003 In the following we describe some additional SPD entries to protect 1004 prefix discovery with IKE. (Note that when actual new prefixes are 1005 discovered, there may be a need to enter new manually configured SPD 1006 entries to specify the authorization policy for the resulting new 1007 home addresses.) 1009 mobile node SPD OUT: 1010 - IF source = home_address_1 & destination = home_agent_1 & 1011 proto = ICMPv6 1012 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 1014 mobile node SPD IN: 1015 - IF source = home_agent_1 & destination = home_address_1 & 1016 proto = ICMPv6 1017 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 1019 home agent SPD OUT: 1020 - IF source = home_agent_1 & destination = home_address_1 & 1021 proto = ICMPv6 1022 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 1024 home agent SPD IN: 1025 - IF source = home_address_1 & destination = home_agent_1 & 1026 proto = ICMPv6 1027 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 1029 5.3.4 Payload Packets 1031 Protection for the payload packets happens similarly to the 1032 protection of return routability signaling. As in the manually keyed 1033 case, these SPD entries have lower priority than the above ones. 1035 mobile node SPD OUT: 1036 - IF interface = tunnel to home_agent_1 & 1037 source = home_address_1 & destination = any & 1038 proto = X 1039 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 1040 local phase 1 identity = user_1 1042 mobile node SPD IN: 1043 - IF interface = tunnel from home_agent_1 & 1044 source = any & destination = home_address_1 & 1045 proto = X 1046 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 1047 local phase 1 identity = user_1 1049 home agent SPD OUT: 1050 - IF interface = tunnel to home_address_1 & 1051 source = any & destination = home_address_1 & 1052 proto = X 1053 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1054 peer phase 1 identity = user_1 1056 home agent SPD IN: 1057 - IF interface = tunnel from home_address_1 & 1058 source = home_address_1 & destination = any & 1059 proto = X 1060 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 1061 peer phase 1 identity = user_1 1063 6. Processing Steps within a Node 1065 6.1 Binding Update to the Home Agent 1067 Step 1. At the mobile node, Mobile IPv6 module first produces the 1068 following packet: 1070 IPv6 header (source = home address, 1071 destination = home agent) 1072 Mobility header 1073 Binding Update 1075 Step 2. This packet is matched against the IPsec policy data base on 1076 the mobile node and we make a note that IPsec must be applied. 1078 Step 3. Then, we add the necessary Mobile IPv6 options but do not 1079 change the addresses yet, as described in Section 11.2.2 of the base 1080 specification [8]. This results in: 1082 IPv6 header (source = home address, 1083 destination = home agent) 1084 Destination Options header 1085 Home Address option (care-of address) 1086 Mobility header 1087 Binding Update 1089 Step 4. Finally, IPsec headers are added and the necessary 1090 authenticator values are calculated: 1092 IPv6 header (source = home address, 1093 destination = home agent) 1094 Destination Options header 1095 Home Address option (care-of address) 1096 ESP header (SPI = spi_a) 1097 Mobility header 1098 Binding Update 1100 Step 5. Before sending the packet, the addresses in the IPv6 header 1101 and the Destination Options header are changed: 1103 IPv6 header (source = care-of address, 1104 destination = home agent) 1105 Destination Options header 1106 Home Address option (home address) 1107 ESP header (SPI = spi_a) 1108 Mobility header 1109 Binding Update 1111 6.2 Binding Update from the Mobile Node 1113 Step 1. The following packet is received at the home agent: 1115 IPv6 header (source = care-of address, 1116 destination = home agent) 1117 Destination Options header 1118 Home Address option (home address) 1119 ESP header (SPI = spi_a) 1120 Mobility header 1121 Binding Update 1123 Step 2. The home address option is processed first, which results in 1125 IPv6 header (source = home address, 1126 destination = home agent) 1127 Destination Options header 1128 Home Address option (care-of address) 1129 ESP header (SPI = spi_a) 1130 Mobility header 1131 Binding Update 1133 Step 3. ESP header is processed next, resulting in 1135 IPv6 header (source = home address, 1136 destination = home agent) 1137 Destination Options header 1138 Home Address option (care-of address) 1139 Mobility header 1140 Binding Update 1142 Step 4. This packet matches the security association selectors 1143 (source = home address, destination = home agent, proto = MH). 1145 Step 5. Mobile IPv6 processes the Binding Update. The Binding 1146 Update is delivered to the Mobile IPv6 module. 1148 6.3 Binding Acknowledgement to the Mobile Node 1150 Step 1. Mobile IPv6 produces the following packet: 1152 IPv6 header (source = home agent, 1153 destination = home address) 1154 Mobility header 1155 Binding Acknowledgement 1157 Step 2. This packet matches the IPsec policy entries, and we 1158 remember that IPsec has to be applied. 1160 Step 3. Then, we add the necessary Route Headers but do not change 1161 the addresses yet, as described in Section 9.6 of the base 1162 specification [8]. This results in: 1164 IPv6 header (source = home agent, 1165 destination = home address) 1166 Routing header (type 2) 1167 care-of address 1168 Mobility header 1169 Binding Acknowledgement 1171 Step 4. We apply IPsec: 1173 IPv6 header (source = home agent, 1174 destination = home address) 1175 Routing header (type 2) 1176 care-of address 1177 ESP header (SPI = spi_b) 1178 Mobility header 1179 Binding Acknowledgement 1181 Step 5. Finally, before sending the packet out we change the 1182 addresses in the IPv6 header and the Route header: 1184 IPv6 header (source = home agent, 1185 destination = care-of address) 1186 Routing header (type 2) 1187 home address 1188 ESP header (SPI = spi_b) 1189 Mobility header 1190 Binding Acknowledgement 1192 6.4 Binding Acknowledgement from the Home Agent 1194 Step 1. The following packet is received at the mobile node 1196 IPv6 header (source = home agent, 1197 destination = care-of address) 1198 Routing header (type 2) 1199 home address 1200 ESP header (SPI = spi_b) 1201 Mobility header 1202 Binding Acknowledgement 1204 Step 2. After the routing header is processed the packet becomes 1205 IPv6 header (source = home agent, 1206 destination = home address) 1207 Routing header (type 2) 1208 care-of address 1209 ESP header (SPI = spi_b) 1210 Mobility header 1211 Binding Acknowledgement 1213 Step 3. ESP header is processed next, resulting in: 1215 IPv6 header (source = home agent, 1216 destination = home address) 1217 Routing header (type 2) 1218 care-of address 1219 Mobility header 1220 Binding Acknowledgement 1222 Step 4. This packet matches the security association selectors 1223 (source = home agent, destination = home address, proto = MH). 1225 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 1226 module. 1228 6.5 Home Test Init to the Home Agent 1230 Step 1. The mobile node constructs a Home Test Init message: 1232 IPv6 header (source = home address, 1233 destination = correspondent node) 1234 Mobility header 1235 Home Test Init 1237 Step 2. Mobile IPv6 determines that this packet should go to the 1238 tunnel to the home agent. 1240 Step 3. The packet is matched against IPsec policy entries for the 1241 interface, and we find that IPsec needs to be applied. 1243 Step 4. IPsec tunnel mode headers are added. Note that we use a 1244 care-of address as a source address for the tunnel packet. 1246 IPv6 header (source = care-of address, 1247 destination = home agent) 1248 ESP header (SPI = spi_c) 1249 IPv6 header (source = home address, 1250 destination = correspondent node) 1251 Mobility header 1252 Home Test Init 1254 Step 5. The packet no longer satisfies the criteria that made it 1255 enter the tunnel, and it is sent directly to the home agent. 1257 6.6 Home Test Init from the Mobile Node 1259 Step 1. The home agent receives the following packet: 1261 IPv6 header (source = care-of address, 1262 destination = home agent) 1263 ESP header (SPI = spi_c) 1264 IPv6 header (source = home address, 1265 destination = correspondent node) 1266 Mobility Header 1267 Home Test Init 1269 Step 2. IPsec processing is performed, resulting in: 1271 IPv6 header (source = home address, 1272 destination = correspondent node) 1273 Mobility Header 1274 Home Test Init 1276 Step 3. The resulting packet matches the selectors and the packet 1277 can be processed further. 1279 Step 4. The packet is then forwarded to the correspondent node. 1281 6.7 Home Test to the Mobile Node 1283 Step 1. The home agent receives a Home Test packet from the 1284 correspondent node: 1286 IPv6 header (source = correspondent node, 1287 destination = home address) 1288 Mobility Header 1289 Home Test Init 1291 Step 2. The home agent determines that this packet is destined to a 1292 mobile node that is away from home, and decides to tunnel it. 1294 Step 3. The packet matches the IPsec policy entries for the tunnel 1295 interface, and we note that IPsec needs to be applied. 1297 Step 4. IPsec is applied, resulting in a new packet. Note that the 1298 home agent must keep track of the location of the mobile node, and 1299 update the tunnel gateway address in the security association(s) 1300 accordingly. 1302 IPv6 header (source = home agent, 1303 destination = care-of address) 1304 ESP header (SPI = spi_d) 1305 IPv6 header (source = correspondent node, 1306 destination = home address) 1307 Mobility Header 1308 Home Test Init 1310 Step 5. The packet no longer satisfies the criteria that made it 1311 enter the tunnel, and it is sent directly to the care-of address. 1313 6.8 Home Test from the Home Agent 1315 Step 1. The mobile node receives the following packet: 1317 IPv6 header (source = home agent, 1318 destination = care-of address) 1319 ESP header (SPI = spi_d) 1320 IPv6 header (source = correspondent node, 1321 destination = home address) 1322 Mobility Header 1323 Home Test Init 1325 Step 2. IPsec is processed, resulting in: 1327 IPv6 header (source = correspondent node, 1328 destination = home address) 1329 Mobility Header 1330 Home Test Init 1332 Step 3. This matches the security association selectors (source = 1333 any, destination = home address). 1335 Step 4. The packet is given to Mobile IPv6 processing. 1337 6.9 Prefix Solicitation Message to the Home Agent 1339 This procedure is similar to the one presented in Section 6.1. 1341 6.10 Prefix Solicitation Message from the Mobile Node 1343 This procedure is similar to the one presented in Section 6.2. 1345 6.11 Prefix Advertisement Message to the Mobile Node 1347 This procedure is similar to the one presented in Section 6.3. 1349 6.12 Prefix Advertisement Message from the Home Agent 1351 This procedure is similar to the one presented in Section 6.4. 1353 6.13 Payload Packet to the Home Agent 1355 This procedure is similar to the one presented in Section 6.5. 1357 6.14 Payload Packet from the Mobile Node 1359 This procedure is similar to the one presented in Section 6.6. 1361 6.15 Payload Packet to the Mobile Node 1363 This procedure is similar to the one presented in Section 6.7. 1365 6.16 Payload Packet from the Home Agent 1367 This procedure is similar to the one presented in Section 6.8. 1369 6.17 Establishing New Security Associations 1371 Step 1. The mobile node wishes to send a Binding Update to the home 1372 agent. 1374 IPv6 header (source = home address, 1375 destination = home agent) 1376 Mobility header 1377 Binding Update 1379 Step 2. There is no existing security association to protect the 1380 Binding Update, so IKE is initiated. The IKE packets are sent as 1381 shown in the following examples. The first packet is an example of 1382 an IKE packet sent from the mobile node, and the second one is from 1383 the home agent. The examples shows also that the phase 1 identity 1384 used for the mobile node is a FQDN. 1386 IPv6 header (source = care-of address, 1387 destination = home agent) 1388 UDP 1389 IKE 1390 ... IDii = ID_FQDN mn123.ha.net ... 1392 IPv6 header (source = home agent 1393 destination = care-of address) 1394 UDP 1395 IKE 1396 ... IDir = ID_FQDN ha.net ... 1398 Step 3. IKE phase 1 completes, and phase 2 is initiated to request 1399 security associations for protecting traffic between the mobile 1400 node's home address and the home agent. This involves sending and 1401 receiving additional IKE packets. The below example shows again one 1402 packet sent by the mobile node and another sent by the home agent. 1403 The example shows also that the phase 2 identity used for the mobile 1404 node is the mobile node's home address. 1406 IPv6 header (source = care-of address, 1407 destination = home agent) 1408 UDP 1409 IKE 1410 ... IDci = ID_IPV6_ADDR home address ... 1412 IPv6 header (source = home agent, 1413 destination = care-of address) 1414 UDP 1415 IKE 1416 ... IDcr = ID_IPV6_ADDR home agent ... 1418 Step 4. The remaining steps are as shown in Section 6.1. 1420 6.18 Rekeying Security Associations 1422 Step 1. The mobile node and the home agent have existing security 1423 associations. Either side may decide at any time that the security 1424 associations need to be rekeyed, for instance, because the specified 1425 lifetime is approaching. 1427 Step 2. Mobility header packets sent during rekey may be protected 1428 by the existing security associations. 1430 Step 3. When the rekeying is finished, new security associations are 1431 established. In practice there is a time interval during which an 1432 old, about-to-expire security association and newly established 1433 security association will both exist. The new ones should be used as 1434 soon as they become available. 1436 Step 4. A notification of the deletion of the old security 1437 associations is received. After this, only the new security 1438 associations can be used. 1440 Note that there is no requirement that the existence of the IPsec and 1441 IKE security associations is tied to the existence of bindings. It 1442 is not necessary to delete a security association if a binding is 1443 removed, as a new binding may soon be established after this. 1445 Since cryptographic acceleration hardware may only be able to handle 1446 a limited number of active security associations, security 1447 associations may be deleted via IKE in order to keep the number of 1448 active cryptographic contexts to a minimum. Such deletions should 1449 not be interpreted as a sign of losing a contact to the peer or as a 1450 reason to remove a binding. Rather, if additional traffic needs to 1451 be sent, it is preferable to bring up another security association to 1452 protect it. 1454 6.19 Movements and Dynamic Keying 1456 In this section we describe the sequence of events that relate to 1457 movement with IKE-based security associations. In the initial state, 1458 the mobile node is not registered in any location and has no security 1459 associations with the home agent. Depending on whether the peers 1460 will be able to move IKE endpoints to new care-of addresses, the 1461 actions taken in Step 9 and 10 are different. 1463 Step 1. Mobile node with the home address A moves to care-of address 1464 B. 1466 Step 2. Mobile node runs IKE from care-of address B to the home 1467 agent, establishing a phase 1. 1469 Step 3. Protected by this phase 1, mobile node establishes a pair of 1470 security associations for protecting Mobility Header traffic to and 1471 from the home address A. 1473 Step 4. Mobile node sends a Binding Update and receives a Binding 1474 Acknowledgement using the security associations created in Step 3. 1476 Step 5. Mobile node establishes a pair of security associations for 1477 protecting return routability packets. These security associations 1478 are in tunnel mode and their endpoint in the mobile node side is 1479 care-of address B. For the purposes of our example, this step uses 1480 the phase 1 connection established in Step 2. Multiple phase 1 1481 connections are also possible. 1483 Step 6. The mobile node uses the security associations created in 1484 Step 5 to run return routability. 1486 Step 7. The mobile node moves to a new location and adopts a new 1487 care-of address C. 1489 Step 8. Mobile node sends a Binding Update and receives a Binding 1490 Acknowledgement using the security associations created in Step 3. 1491 The home agent ensures that the next packets sent using the security 1492 associations created in Step 5 will have the new care-of address as 1493 their destination address, as if the destination gateway address in 1494 the security association had changed. 1496 Step 9. If the mobile node and the HA have the capability to change 1497 the IKE endpoints, they change the address to C. If they dont have 1498 the capability, both nodes remove their phase 1 connections created 1499 on top of the care-of address B and establish a new IKE phase 1 on 1500 top of the care-of address C. This capability to change the IKE 1501 phase 1 end points is indicated through setting the Key Management 1502 Mobility Capability (K) flag [8] in the Binding Update and Binding 1503 Acknowledgement messages. 1505 Step 10. If a new IKE phase 1 connection was setup after movement, 1506 the MN will not be able to receive any notifications delivered on top 1507 of the old IKE phase 1 security association. Notifications delivered 1508 on top of the new security association are received and processed 1509 normally. If the mobile node and HA were able to update the IKE 1510 endpoints, they can continue using the same IKE phase 1 connection. 1512 7. Implementation Considerations 1514 We have chosen to require an encapsulation format for return 1515 routability and payload packet protection which can only be realized 1516 if the destination of the IPsec packets sent from the home agent can 1517 be changed as the mobile node moves. One of the main reasons for 1518 choosing such a format is that it removes the overhead of twenty four 1519 bytes when a home address option or routing header is added to the 1520 tunneled packet. What is needed is that the home agent must act as 1521 if the gateway address of a security association to the mobile node 1522 would have changed. Implementations are free to choose any 1523 particular method to make this change, such as using an API to the 1524 IPsec implementation to change the parameters of the security 1525 association, removing the security association and installing a new 1526 one, or modification of the packet after it has gone through IPsec 1527 processing. The only requirement is that after registering a new 1528 binding at the home agent, the next IPsec packets sent on this 1529 security association will be addressed to the new care-of address. 1531 We have also chosen to require that a dynamic key management protocol 1532 must be able to make an authorization decision for IPsec security 1533 association creation with different addresses than with what the key 1534 management protocol is run. We expect this to be done typically by 1535 configuring the allowed combinations of phase 1 user identities and 1536 home addresses. 1538 The base Mobile IPv6 specification sets high requirements for a 1539 so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As 1540 Mobile IPv6 specific modifications of the packets are required after 1541 IPsec processing, the BITS implementation has to perform also some 1542 tasks related to mobility. This may increase the complexity of the 1543 implementation, even if it already performs some tasks of the IP 1544 layer (such as fragmentation). 1546 We have chosen to require policy entries that are specific to a 1547 tunnel interface. This means that implementations have to regard the 1548 Home Agent - Mobile Node tunnel as a separate interface on which 1549 IPsec SPDs can be based. 1551 A further complication of the IPsec processing on a tunnel interface 1552 is that this requires access to the BITS implementation before the 1553 packet actually goes out. 1555 When certificate authentication is used, IKE fragmentation can be 1556 encountered. This can occur when certificate chains are used, or 1557 even with single certificates if they are large. Many firewalls do 1558 not handle fragments properly, and may drop them. Routers in the 1559 path may also discard fragments after the initial one, since they 1560 typically will not contain full IP headers that can be compared 1561 against an access list. Where fragmentation occurs, the endpoints 1562 will not always be able to establish a security association. 1564 Fortunately, typical Mobile IPv6 deployment uses short certificate 1565 chains, as the mobile node is communicating directly with its home 1566 network. Nevertheless, where the problem appears, one solution is to 1567 replace the firewalls or routers with equipment that can properly 1568 support fragments. If this cannot be done, it may help to store the 1569 peer certificates locally, or to obtain them through other means. 1571 8. Security Considerations 1573 The Mobile IPv6 base specification [8] requires strong security 1574 between the mobile node and the home agent. This memo discusses how 1575 that security can be arranged in practice, using IPsec. 1577 Normative References 1579 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1580 Levels", BCP 14, RFC 2119, March 1997. 1582 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1583 Internet Protocol", RFC 2401, November 1998. 1585 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1586 November 1998. 1588 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1589 (ESP)", RFC 2406, November 1998. 1591 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1592 RFC 2409, November 1998. 1594 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1595 Specification", RFC 2460, December 1998. 1597 [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1598 Specification", RFC 2473, December 1998. 1600 [8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1601 IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), February 1602 2003. 1604 Informative References 1606 [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1607 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1609 [10] Droms, R., "Dynamic Host Configuration Protocol for IPv6 1610 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 1611 November 2002. 1613 [11] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, 1614 "Negotiation of NAT-Traversal in the IKE", 1615 draft-ietf-ipsec-nat-t-ike-04 (work in progress), November 1616 2002. 1618 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1619 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 1620 December 2002. 1622 Authors' Addresses 1624 Jari Arkko 1625 Ericsson 1626 Jorvas 02420 1627 Finland 1629 EMail: jari.arkko@ericsson.com 1631 Vijay Devarapalli 1632 Nokia Research Center 1633 313 Fairchild Drive 1634 Mountain View CA 94043 1635 USA 1637 EMail: vijayd@iprg.nokia.com 1639 Francis Dupont 1640 ENST Bretagne 1641 Campus de Rennes 2, rue de la Chataigneraie 1642 BP 78 1643 Cesson-Sevigne Cedex 35512 1644 France 1646 EMail: Francis.Dupont@enst-bretagne.fr 1648 Appendix A. Acknowledgements 1650 The authors would like to thank Greg O'Shea, Michael Thomas, Kevin 1651 Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, and Gabriel 1652 Montenegro for interesting discussions in this problem space. 1654 Appendix B. Changes from Previous Version 1656 The following changes have been made to this document from version 1657 02: 1659 o It is now better explained why the mobile node can change its 1660 source address in security associations before such a change is 1661 told to the home agent (tracked issue 249). 1663 o The support for protecting prefix discovery with IPsec has been 1664 made mandatory, but use is still a SHOULD (tracked issue 249). 1666 o Requirements for security association and policy configuration for 1667 new home addresses received through prefix discovery have been 1668 specified (tracked issue 243). 1670 o IPsec protocol and mode requirements have now been stated as 1671 minimal requirements and no longer prevent the use of other 1672 protocols (AH) and modes (tracked issue 228). 1674 o The specification explicitly discourages the use of nested IPsec 1675 encapsulation (tracked issue 219). 1677 o The different types of requests for phase 2 security associations 1678 have been explained in the requirements section. This relates to 1679 using IKE for creating security associations for Binding Update 1680 protection or other tasks (tracked issue 219). 1682 o Many editorial modifications have been performed. 1684 Intellectual Property Statement 1686 The IETF takes no position regarding the validity or scope of any 1687 intellectual property or other rights that might be claimed to 1688 pertain to the implementation or use of the technology described in 1689 this document or the extent to which any license under such rights 1690 might or might not be available; neither does it represent that it 1691 has made any effort to identify any such rights. Information on the 1692 IETF's procedures with respect to rights in standards-track and 1693 standards-related documentation can be found in BCP-11. Copies of 1694 claims of rights made available for publication and any assurances of 1695 licenses to be made available, or the result of an attempt made to 1696 obtain a general license or permission for the use of such 1697 proprietary rights by implementors or users of this specification can 1698 be obtained from the IETF Secretariat. 1700 The IETF invites any interested party to bring to its attention any 1701 copyrights, patents or patent applications, or other proprietary 1702 rights which may cover technology that may be required to practice 1703 this standard. Please address the information to the IETF Executive 1704 Director. 1706 Full Copyright Statement 1708 Copyright (C) The Internet Society (2003). All Rights Reserved. 1710 This document and translations of it may be copied and furnished to 1711 others, and derivative works that comment on or otherwise explain it 1712 or assist in its implementation may be prepared, copied, published 1713 and distributed, in whole or in part, without restriction of any 1714 kind, provided that the above copyright notice and this paragraph are 1715 included on all such copies and derivative works. However, this 1716 document itself may not be modified in any way, such as by removing 1717 the copyright notice or references to the Internet Society or other 1718 Internet organizations, except as needed for the purpose of 1719 developing Internet standards in which case the procedures for 1720 copyrights defined in the Internet Standards process must be 1721 followed, or as required to translate it into languages other than 1722 English. 1724 The limited permissions granted above are perpetual and will not be 1725 revoked by the Internet Society or its successors or assignees. 1727 This document and the information contained herein is provided on an 1728 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1729 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1730 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1731 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1732 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1734 Acknowledgement 1736 Funding for the RFC Editor function is currently provided by the 1737 Internet Society.