idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-05.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). -- 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 (May 26, 2003) is 7640 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 1789, 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-22 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-04 == Outdated reference: A later version (-07) exists of draft-touch-ipsec-vpn-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: November 24, 2003 V. Devarapalli 5 Nokia Research Center 6 F. Dupont 7 ENST Bretagne 8 May 26, 2003 10 Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and 11 Home Agents 12 draft-ietf-mobileip-mipv6-ha-ipsec-05.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 November 24, 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 . . . . . . . . . . . . . . . . . . . 11 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12 61 4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12 62 4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 15 63 4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 17 64 5. Example Configurations . . . . . . . . . . . . . . . . . . . 19 65 5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 19 66 5.2 Manual Configuration . . . . . . . . . . . . . . . . . 20 67 5.2.1 Binding Updates and Acknowledgements . . . . . . 20 68 5.2.2 Return Routability Signaling . . . . . . . . . . 21 69 5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 22 70 5.2.4 Payload Packets . . . . . . . . . . . . . . . . 23 71 5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 25 72 5.3.1 Binding Updates and Acknowledgements . . . . . . 25 73 5.3.2 Return Routability Signaling . . . . . . . . . . 26 74 5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 27 75 5.3.4 Payload Packets . . . . . . . . . . . . . . . . 27 76 6. Processing Steps within a Node . . . . . . . . . . . . . . . 29 77 6.1 Binding Update to the Home Agent . . . . . . . . . . . 29 78 6.2 Binding Update from the Mobile Node . . . . . . . . . 30 79 6.3 Binding Acknowledgement to the Mobile Node . . . . . . 31 80 6.4 Binding Acknowledgement from the Home Agent . . . . . 32 81 6.5 Home Test Init to the Home Agent . . . . . . . . . . . 32 82 6.6 Home Test Init from the Mobile Node . . . . . . . . . 33 83 6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 33 84 6.8 Home Test from the Home Agent . . . . . . . . . . . . 34 85 6.9 Prefix Solicitation Message to the Home Agent . . . . 35 86 6.10 Prefix Solicitation Message from the Mobile Node . . . 35 87 6.11 Prefix Advertisement Message to the Mobile Node . . . 35 88 6.12 Prefix Advertisement Message from the Home Agent . . . 35 89 6.13 Payload Packet to the Home Agent . . . . . . . . . . . 35 90 6.14 Payload Packet from the Mobile Node . . . . . . . . . 35 91 6.15 Payload Packet to the Mobile Node . . . . . . . . . . 35 92 6.16 Payload Packet from the Home Agent . . . . . . . . . . 35 93 6.17 Establishing New Security Associations . . . . . . . . 35 94 6.18 Rekeying Security Associations . . . . . . . . . . . . 36 95 6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37 96 7. Implementation Considerations . . . . . . . . . . . . . . . 39 97 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 39 98 7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 40 99 7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 40 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 101 9. Security Considerations . . . . . . . . . . . . . . . . . . 43 102 Normative References . . . . . . . . . . . . . . . . . . . . 44 103 Informative References . . . . . . . . . . . . . . . . . . . 45 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 105 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 106 B. Changes from Previous Version . . . . . . . . . . . . . . . 48 107 Intellectual Property and Copyright Statements . . . . . . . 50 109 1. Introduction 111 This document illustrates the use of IPsec in securing Mobile IPv6 112 [8] traffic between mobile nodes and home agents. In Mobile IPv6, a 113 mobile node is always expected to be addressable at its home address, 114 whether it is currently attached to its home link or is away from 115 home. The "home address" is an IP address assigned to the mobile 116 node within its home subnet prefix on its home link. While a mobile 117 node is at home, packets addressed to its home address are routed to 118 the mobile node's home link. 120 While a mobile node is attached to some foreign link away from home, 121 it is also addressable at a care-of addresses. A care-of address is 122 an IP address associated with a mobile node that has a subnet prefix 123 from a particular foreign link. The association between a mobile 124 node's home address and care-of address is known as a "binding" for 125 the mobile node. While away from home, a mobile node registers its 126 primary care-of address with a router on its home link, requesting 127 this router to function as the "home agent" for the mobile node. The 128 mobile node performs this binding registration by sending a "Binding 129 Update" message to the home agent. The home agent replies to the 130 mobile node by returning a "Binding Acknowledgement" message. 132 Any other nodes communicating with a mobile node are referred to as 133 "correspondent nodes". Mobile nodes can provide information about 134 their current location to correspondent nodes, again using Binding 135 Updates and Acknowledgements. Additionally, return routability test 136 is performed between the mobile node, home agent, and the 137 correspondent node in order to authorize the establishment of the 138 binding. Packets between the mobile node and the correspondent node 139 are either tunneled via the home agent, or sent directly if a binding 140 exists in the correspondent node for the current location of the 141 mobile node. 143 Mobile IPv6 tunnels payload packets between the mobile node and the 144 home agent in both directions. This tunneling uses IPv6 145 encapsulation [7]. Where these tunnels need to be secured, they are 146 replaced by IPsec tunnels [2]. 148 Mobile IPv6 also provides support for the reconfiguration of the home 149 network. Here the home subnet prefixes may change over time. Mobile 150 nodes can learn new information about home subnet prefixes through 151 the "prefix discovery" mechanism. 153 This document discusses security mechanisms for the control traffic 154 between the mobile node and the home agent. If this traffic is not 155 protected, mobile nodes and correspondent nodes are vulnerable to 156 man-in-the-middle, hijacking, passive wiretapping, impersonation, and 157 denial-of-service attacks. Any third parties are also vulnerable to 158 denial-of-service attacks, for instance if an attacker could direct 159 the traffic flowing through the home agent to a innocent third party. 160 These attacks are discussed in more detail in Section 15.1 of the 161 Mobile IPv6 base specification [8]. 163 In order to avoid these attacks, the base specification uses IPsec 164 Encapsulating Security Payload (ESP) [4] to protect control traffic 165 between the home agent and the mobile node. This control traffic 166 consists of various messages carried by the Mobility Header protocol 167 in IPv6 [6]. The traffic takes the following forms: 169 o Binding Update and Acknowledgement messages exchanged between the 170 mobile node and the home agent, as described in Sections 10.3.1, 171 10.3.2, 11.7.1, and 11.7.3 of the base specification [8]. 173 o Return routability messages Home Test Init and Home Test that pass 174 through the home agent on their way to a correspondent node, as 175 described in Section 10.4.6 of the base specification [8]. 177 o ICMPv6 messages exchanged between the mobile node and the home 178 agent for the purposes of prefix discovery, as described in 179 Sections 10.6 and 11.4 of the base specification [8]. 181 The nodes may also optionally protect payload traffic passing through 182 the home agent, as described in Section 5.3 of the base specification 183 [8]. If multicast group membership control protocols or stateful 184 address autoconfiguration protocols are supported, payload data 185 protection support is required. 187 The control traffic between the mobile node and the home agent 188 requires message authentication, integrity, correct ordering and 189 optional anti-replay protection. The mobile node and the home agent 190 must have a security association to protect this traffic. In 191 addition, Mobile IPv6 messages assist in ensuring correct ordering, 192 as IPsec can only provide protection against replayed messages. Full 193 protection against replay and ordering attacks is possible only when 194 IKE is used, however. 196 Great care is needed when using IKE [5] to establish security 197 associations to Mobile IPv6 home agents. The right kind of addresses 198 must be used for transporting IKE. This is necessary to avoid 199 circular dependencies in which the use of a Binding Update triggers 200 the need for an IKE exchange that cannot complete prior to the 201 Binding Update having been completed. 203 The mobile IPv6 base document defines the main requirements the 204 mobile nodes and home agents must follow when securing the above 205 traffic. This document discusses these requirements in more depth, 206 illustrates the used packet formats, describes suitable configuration 207 procedures, and shows how implementations can process the packets in 208 the right order. 210 We begin our description by showing the required wire formats for the 211 protected packets in Section 3. Section 4 describes rules which 212 associated Mobile IPv6, IPsec, and IKE implementations must observe. 213 Section 5 discusses how to configure either manually keyed IPsec 214 security associations or how to configure IKE to establish them 215 automatically. Section 6 shows examples of how packets are processed 216 within the nodes. 218 All implementations of Mobile IPv6 mobile node and home agent MUST 219 support at least the formats described in Section 3 and obey the 220 rules in Section 4. Note that in addition to the use of ESP as 221 specified here, it may also be possible to use Authentication Header 222 (AH) [3], but for brevity this is not discussed in this 223 specification. 225 The configuration and processing sections are informative, and should 226 only be considered as one possible way of providing the required 227 functionality. 229 Note that where this document indicates a feature MUST be supported 230 and SHOULD be used, this implies that all implementations must be 231 capable of using the specified feature, but there may be cases where, 232 for instance, a configuration option disables to use of the feature 233 in a particular situation. 235 2. Terminology 237 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 239 document are to be interpreted as described in RFC 2119 [1]. 241 3. Packet Formats 243 3.1 Binding Updates and Acknowledgements 245 When the mobile node is away from its home, the BUs sent by it to the 246 home agent MUST support at least the following headers in the 247 following order: 249 IPv6 header (source = care-of address, 250 destination = home agent) 251 Destination Options header 252 Home Address option (home address) 253 ESP header in transport mode 254 Mobility header 255 Binding Update 256 Alternate Care-of Address option (care-of address) 258 Note that the Alternate Care-of Address option is used to ensure that 259 the care-of address is protected by ESP. The home agent considers 260 the address within this option as the current care-of address for the 261 mobile node. The home address is not protected by ESP directly, but 262 the use of a specific home address with a specific security 263 association is required by policy. 265 The Binding Acknowledgements sent back to the mobile node when it is 266 away from home MUST support at least the following headers in the 267 following order: 269 IPv6 header (source = home agent, 270 destination = care-of address) 271 Routing header (type 2) 272 home address 273 ESP header in transport mode 274 Mobility header 275 Binding Acknowledgement 277 When the mobile node is at home, the above rules are different as the 278 mobile node can use its home address as a source address. This 279 typically happens for the de-registration Binding Update when the 280 mobile is returning home. In this situation, the Binding Updates 281 MUST support at least the following headers in the following order: 283 IPv6 header (source = home address, 284 destination = home agent) 285 ESP header in transport mode 286 Mobility header 287 Binding Update 289 The Binding Acknowledgement messages sent to the home address MUST 290 support at least the following headers in the following order: 292 IPv6 header (source = home agent, 293 destination = home address) 294 ESP header in transport mode 295 Mobility header 296 Binding Acknowledgement 298 3.2 Return Routability Signaling 300 When the Home Test Init messages tunneled to the home agent are 301 protected by IPsec, they MUST support at least the following headers 302 in the following order: 304 IPv6 header (source = care-of address, 305 destination = home agent) 306 ESP header in tunnel mode 307 IPv6 header (source = home address, 308 destination = correspondent node) 309 Mobility Header 310 Home Test Init 312 This format assumes that the mobile node's current care-of address is 313 used as the outer header destination address in the security 314 association. As discussed in Section 4.3, this requires the home 315 agent to update the destination address when the mobile node moves. 316 Policy entries and security association selectors stay the same, 317 however, as the inner packets do not change upon movements. 319 Note that there are trade-offs in using care-of addresses as the 320 destination addresses versus using the home address and attaching an 321 additional Home Address destination option and/or Routing header to 322 the packets. The basis for requiring support for at least the 323 care-of address case has been discussed in Section 7. 325 Similarly, when the Home Test messages tunneled from the home agent 326 are protected by IPsec, they MUST support at least the following 327 headers in the following order: 329 IPv6 header (source = home agent, 330 destination = care-of address) 331 ESP header in tunnel mode 332 IPv6 header (source = correspondent node, 333 destination = home address) 334 Mobility Header 335 Home Test 337 The format used to protect return routability packets relies on the 338 destination of the tunnel packets to change for the mobile node as it 339 moves. The home agent's address stays the same, but the mobile 340 node's address changes upon movements, as if the security 341 association's outer header destination address had changed. When the 342 mobile node adopts a new care-of address, it adopts also a new source 343 address for outgoing tunnel packets. The home agent accepts packets 344 sent like this, as the outer source address in tunnel packets is not 345 checked according to the rules in RFC 2401. (We note, however, that 346 some implementations are known to make source address checks.) For a 347 discussion of the role of source addresses in outer tunnel headers, 348 see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent 349 requires the packets to be authenticated regardless of the source 350 address change, hence the "new" sender must possess the same keys for 351 the security association as the it had in the previous location. 352 This proves that the sender is the same entity, regardless of the 353 changes in the addresses. 355 The process is more complicated in the home agent side, as the home 356 agent has stored the previous care-of address in its Security 357 Association Database as the outer header destination address. When 358 IKE is being used, the mobile node runs it on top of its current 359 care-of address, and the resulting tunnel-mode security associations 360 will use the same addresses as IKE run over. In order for the home 361 agent to be able to tunnel a Home Test message to the mobile node, it 362 uses the current care-of address as the destination of the tunnel 363 packets, as if the home agent had modified the outer header 364 destination address in the security association used for this 365 protection. This implies that the same security association can be 366 used in multiple locations, and no new configuration or 367 re-establishment of IKE phases is needed per movement. Section 5.2.2 368 discusses the security policy and security association database 369 entries that are needed to accomplish this. 371 3.3 Prefix Discovery 373 If IPsec is used to protect prefix discovery, requests for prefixes 374 from the mobile node to the home agent MUST support at least the 375 following headers in the following order. 377 IPv6 header (source = care-of address, 378 destination = home agent) 379 Destination Options header 380 Home Address option (home address) 381 ESP header in transport mode 382 ICMPv6 383 Mobile Prefix Solicitation 385 Again if IPsec is used, solicited and unsolicited prefix information 386 advertisements from the home agent to the mobile node MUST support at 387 least the following headers in the following order. 389 IPv6 header (source = home agent, 390 destination = care-of address) 391 Routing header (type 2) 392 home address 393 ESP header in transport mode 394 ICMPv6 395 Mobile Prefix Advertisement 397 3.4 Payload Packets 399 If IPsec is used to protect payload packets tunneled to the home 400 agent from the mobile node, a similar format is used as in the case 401 of tunneled Home Test Init messages. However, instead of the 402 Mobility Header these packets may contain any legal IPv6 protocol(s): 404 IPv6 header (source = care-of address, 405 destination = home agent) 406 ESP header in tunnel mode 407 IPv6 header (source = home address, 408 destination = correspondent node) 409 Any protocol 411 Similarly, when the payload packets are tunneled from the home agent 412 to the mobile node with ESP encapsulation, they MUST support at least 413 the following headers in the following order: 415 IPv6 header (source = home agent, 416 destination = care-of address) 417 ESP header in tunnel mode 418 IPv6 header (source = correspondent node, 419 destination = home address) 420 Any protocol 422 4. Requirements 424 This section describes mandatory rules for all Mobile IPv6 mobile 425 nodes and home agents. These rules are necessary in order for it to 426 be possible to enable IPsec communications despite movements, 427 guarantee sufficient security, and to ensure correct processing order 428 of packets. 430 The rules in the following sections apply only to the communications 431 between home agents and mobile nodes. They should not be taken as 432 requirements on how IPsec in general is used by mobile nodes. 434 4.1 Mandatory Support 436 The following requirements apply to both home agents and mobile 437 nodes: 439 o Manual configuration of IPsec security associations MUST be 440 supported. The configuration of the keys is expected to take 441 place out-of-band, for instance at the time the mobile node is 442 configured to use its home agent. 444 o Automatic key management with IKE [5] MAY be supported. Only 445 IKEv1 is discussed in this document, even if it is expected that 446 the next version of IKE can also be used and that it offers 447 several improvements in this specific application. 449 o ESP encapsulation of Binding Updates and Acknowledgements between 450 the mobile node and home agent MUST be supported and MUST be used. 452 o ESP encapsulation of the Home Test Init and Home Test messages 453 tunneled between the mobile node and home agent MUST be supported 454 and SHOULD be used. 456 o ESP encapsulation of the ICMPv6 messages related to prefix 457 discovery MUST be supported and SHOULD be used. 459 o ESP encapsulation of the payload packets tunneled between the 460 mobile node and home agent MAY be supported and used. 462 o If multicast group membership control protocols or stateful 463 address autoconfiguration protocols are supported, payload data 464 protection MUST be supported for those protocols. 466 4.2 Policy Requirements 468 The following requirements apply to both home agents and mobile 469 nodes: 471 o When a packet is matched against IPsec security policy or 472 selectors of a security association, an address appearing in a 473 Home Address destination option MUST be considered as the source 474 address of the packet. 476 Note that the home address option appears before IPsec headers. 477 Section 11.3.2 of the base specification [8] describes one 478 possible implementation approach for this: The IPsec policy 479 operations can be performed at the time when the packet has not 480 yet been modified per Mobile IPv6 rules, or has been brought back 481 to its normal form after Mobile IPv6 processing. That is, the 482 processing of the Home Address option is seen as a fixed 483 transformation of the packets that does not affect IPsec 484 processing. 486 o Similarly, a home address within a Type 2 Routing header MUST be 487 considered as the destination address of the packet, when a packet 488 is matched against IPsec security policy or selectors of a 489 security association. 491 Similar implementation considers apply to the Routing header 492 processing as was described above for the Home Address destination 493 option. 495 o When IPsec is used to protect return routability signaling or 496 payload packets, this protection MUST only be applied to the 497 return routability packets entering the IPv6 encapsulated tunnel 498 interface between the mobile node and the home agent. This can be 499 achieved, for instance, by defining the security policy database 500 entries specifically for the tunnel interface. That is, the 501 policy entries are not generally applied on all traffic on the 502 physical interface(s) of the nodes, but rather only on traffic 503 that enters this tunnel. 505 Note that this requirement is similar to the approach taken in 506 dynamically routed VPNs [12]. 508 o The authentication of mobile nodes MAY be based either on machine 509 or user credentials. Note that multi-user operating systems 510 typically allow all users of a node to use any of the IP addresses 511 assigned to the node. This limits the capability of the home 512 agent to restrict the use of a home address to a particular user 513 in such environment. Where user credentials are applied in a 514 multi-user environment, the configuration should authorize all 515 users of the node to control all home addresses assigned to the 516 node. 518 o When the mobile node returns home and de-registers with the Home 519 Agent, the tunnel between the home agent and the mobile node's 520 care-of address is torn down. The security policy entries, which 521 were used for protecting tunneled traffic between the mobile node 522 and the home agent MUST be made inactive (for instance, by 523 removing them and installing them back later through an API). The 524 corresponding security associations could be kept as they are or 525 deleted depending on how they were created. If the security 526 associations were created dynamically using IKE, they are 527 automatically deleted when they expire. If the security 528 associations were created through manual configuration, they MUST 529 be retained and used later when the mobile node moves aways from 530 home again. The security associations protecting Binding Updates 531 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 532 as they do not depend on care-of addresses and can be used again. 534 The following rules apply to mobile nodes: 536 o The mobile node MUST use the Home Address destination option in 537 Binding Updates and Mobile Prefix Solicitations, sent to the home 538 agent from a care-of address. 540 o When the mobile node receives a changed set of prefixes from the 541 home agent during prefix discovery, there is a need to configure 542 new security policy entries, and there may be a need to configure 543 new security associations. It is outside the scope of this 544 specification to discuss automatic methods for this. 546 The following rules apply to home agents: 548 o The home agent MUST use the Type 2 Routing header in Binding 549 Acknowledgements and Mobile Prefix Advertisements sent to the 550 mobile node, again due to the need to have the home address 551 visible when the policy checks are made. 553 o It is necessary to avoid the possibility that a mobile node could 554 use its security association to send a Binding Update on behalf of 555 another mobile node using the same home agent. In order to do 556 this, the security policy database entries MUST unequivocally 557 identify a single security association for protecting Binding 558 Updates between any given home address and home agent when 559 manually keyed IPsec security associations are used. When dynamic 560 keying is used, the security policy database entries MUST 561 unequivocally identify the IKE phase 1 credentials which can be 562 used to authorize the creation of security associations for 563 protecting Binding Updates for a particular home address. How 564 these mappings are maintained is outside the scope of this 565 specification, but they may be maintained, for instance, as a 566 locally administered table in the home agent. If the phase 1 567 identity is a Fully Qualified Domain Name (FQDN), secure forms of 568 DNS may also be used. 570 o When the set of prefixes advertised by the home agent changes, 571 there is a need to configure new security policy entries, and 572 there may be a need to configure new security associations. It is 573 outside the scope of this specification to discuss automatic 574 methods for this, if new home addresses are required. 576 4.3 IPsec Protocol Processing 578 The following requirements apply to both home agents and mobile 579 nodes: 581 o When securing Binding Updates, Binding Acknowledgements, and 582 prefix discovery, both the mobile nodes and the home agents MUST 583 support and SHOULD use the Encapsulating Security Payload (ESP) 584 [4] header in transport mode and MUST use a non-null payload 585 authentication algorithm to provide data origin authentication, 586 connectionless integrity and optional anti-replay protection. 588 Mandatory support for encryption and integrity protection 589 algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC 590 2406 [4]. Care is needed when selecting suitable encryption 591 algorithms for ESP, however. Currently available integrity 592 protection algorithms are in general considered to be secure. The 593 encryption algorithm, DES, mandated by the current IPsec standards 594 is not, however. This is particularly problematic when IPsec 595 security associations are configured manually, as the same key is 596 used for a long time. 598 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 599 protection of packets belonging to the return routability 600 procedure. A non-null encryption transform and a non-null 601 authentication algorithm MUST be applied. 603 Note that the return routability procedure involves two message 604 exchanges from the mobile node to the correspondent node. The 605 purpose of these exchanges is to assure that the mobile node is 606 live at the claimed home and care-of addresses. One of the 607 exchanges is sent directly to and from the correspondent node, 608 while another one is tunneled through the home agent. If an 609 attacker is on the mobile node's link and the mobile node's 610 current link is an unprotected wireless link, the attacker would 611 able to see both sets of messages, and launch attacks based on it 612 (these attacks are discussed further in Section 15.4 of the base 613 specification [8]. One can prevent the attack by making sure that 614 the packets tunneled through the home agent are encrypted. 616 Note that this specification concerns itself only with on-the-wire 617 formats, and does not dictate specific implementations mechanisms. 618 In the case of IPsec tunnel mode, the use of IP-in-IP 619 encapsulation followed by IPsec transport mode encapsulation may 620 also be possible. The trade-offs related to the use of tunnel 621 mode and IP-in-IP encapsulation have been discussed in [12]. 623 The following rules apply to mobile nodes: 625 o When ESP is used to protect Binding Updates, there is no 626 protection for the care-of address which appears in the IPv6 627 header outside the area protected by ESP. It is important for the 628 home agent to verify that the care-of address has not been 629 tampered with. As a result, the attacker would have redirected 630 the mobile node's traffic to another address. In order to prevent 631 this, Mobile IPv6 implementations MUST use the Alternate Care-of 632 Address mobility option in Binding Updates sent by mobile nodes 633 while away from home. The exception to this is when the mobile 634 node returns home and sends a Binding Update to the home agent in 635 order to de-register. In this case no Alternate Care-of Address 636 option is needed, as described in Section 3.1. 638 o When IPsec is used to protect return routability signaling or 639 payload packets, the mobile node MUST set the source address it 640 uses for the outgoing tunnel packets to the current primary 641 care-of address. The mobile node starts to use a new primary 642 care-of address immediately after sending a Binding Update to the 643 home agent to register this new address. Similarly, it starts to 644 use the new address as the required destination address of 645 tunneled packets received from the home agent. 647 The following rules apply to home agents: 649 o When IPsec is used to protect return routability signaling or 650 payload packets, IPsec security associations are needed to provide 651 this protection. When the care-of address for the mobile node 652 changes as a result of an accepted Binding Update, special 653 treatment is needed for the next packets sent using these security 654 associations. The home agent MUST set the new care-of address as 655 the destination address of these packets, as if the outer header 656 destination address in the security association had changed. 657 Similarly, the home agent starts to expect the new source address 658 in the tunnel packets received from the mobile node. 660 Such address changes can be implemented, for instance, through an 661 API from the Mobile IPv6 implementation to the IPsec 662 implementation. It should be noted that the use of such an API 663 and the address changes MUST only be done based on the Binding 664 Updates received by the home agent and protected by the use of 665 IPsec. Address modifications based on other sources, such as 666 Binding Updates to the correspondent nodes protected by return 667 routability, or open access to an API from any application may 668 result in security vulnerabilities. 670 4.4 Dynamic Keying 672 The following requirements apply to both home agents and mobile 673 nodes: 675 o If anti-replay protection is required, dynamic keying MUST be 676 used. IPsec can provide anti-replay protection only if dynamic 677 keying is used (which may not always be the case). IPsec also 678 does not guarantee correct ordering of packets, only that they 679 have not been replayed. Because of this, sequence numbers within 680 the Mobile IPv6 messages are used to ensure correct ordering. 681 However, if the 16 bit Mobile IPv6 sequence number space is cycled 682 through, or the home agent reboots and loses its state regarding 683 the sequence numbers, replay and reordering attacks become 684 possible. The use of dynamic keying, IPsec anti-replay 685 protection, and the Mobile IPv6 sequence numbers can together 686 prevent such attacks. 688 o If IKE version 1 is used with preshared secrets in main mode, it 689 determines the shared secret to use from the IP address of the 690 peer. With Mobile IPv6, however, this may be a care-of address 691 and does not indicate which mobile node attempts to contact the 692 home agent. Therefore, if preshared secret authentication is used 693 in IKEv1 between the mobile node and the home agent then 694 aggressive mode MUST be used. Note also that care needs to be 695 taken with phase 1 identity selection. Where the ID_IPV6_ADDR 696 Identity Payloads is used, unambiguous mapping of identities to 697 keys is not possible. (The next version of IKE may not have these 698 limitations.) 700 Note that the difficulties with main mode and preshared secrets in 701 IKE version 1 are well known for dynamic addresses. With static 702 addresses, there has not been a problem. With Mobile IPv6, 703 however, the use of the care-of addresses to run IKE to the home 704 agent presents a problem even when the home address stays stable. 705 Further discussion about the use of care-of addresses in this way 706 appears in Section 7. 708 The following rules apply to mobile nodes: 710 o In addition to the rules above, if dynamic keying is used, the key 711 management protocol MUST use the care-of address as the source 712 address in the protocol exchanges with the mobile node's home 713 agent. 715 o However, the IPsec security associations with the mobile node's 716 home agent use home addresses. That is, the IPsec security 717 associations MUST be requested from the key management protocol 718 using the home address of the mobile node as the client identity. 720 The security associations for protecting Binding Updates and 721 Acknowledgements are requested for the Mobility header protocol in 722 transport mode and for specific IP addresses as endpoints. No 723 other selectors are used. Similarly, the security associations 724 for protecting prefix discovery are requested for the ICMPv6 725 protocol and the specific IP addresses, again without other 726 selectors. Security associations for payload and return 727 routability protection are requested for a specific tunnel 728 interface and either the payload protocol or the Mobility header 729 protocol, in tunnel mode. In this case one requested endpoint is 730 an IP address and the other one is a wildcard, and there are no 731 other selectors. 733 o If the mobile node has used IKE version 1 to establish security 734 associations with its home agent, it should follow the procedures 735 discussed in Section 11.7.1 and 11.7.3 of the base specification 736 [8] to determine whether the IKE endpoints can be moved or if IKE 737 phase 1 has to be re-established. 739 The following rules apply to home agents: 741 o If the home agent has used IKE version 1 to establish security 742 associations with the mobile node, it should follow the procedures 743 discussed in Section 10.3.1 and 10.3.2 of the base specification 744 [8] to determine whether the IKE endpoints can be moved or if IKE 745 phase 1 has to be re-established. 747 5. Example Configurations 749 In the following we describe the Security Policy Database (SPD) and 750 Security Association Database (SAD) entries necessary to protect 751 Binding Updates and Binding Acknowledgements exchanged between the 752 mobile node and the home agent. 754 Section 5.1 introduces the format we use in the description of the 755 SPD and the SAD. Section 5.2 describes how to configure manually 756 keyed IPsec security associations without dynamic keying, and Section 757 5.3 describes how to use dynamic keying. 759 5.1 Format 761 The format used in the examples is as follows. The SPD description 762 has the format 764 "SPD OUT:" 765 "-" 766 "-" 767 ... 768 "-" 770 "SPD IN:" 771 "-" 772 "-" 773 ... 774 "-" 776 Where represents the name of the node, and has the 777 following format: 779 "IF" "THEN USE SA " | 780 "IF" "THEN USE SA " | 782 Where is a boolean expression about the fields of the 783 IPv6 packet, is the name of a specific security association, and 784 is a specification for a security association to be 785 negotiated via IKE [5]. The SAD description has the format 787 "SAD:" 788 "-" 789 "-" 790 ... 791 "-" 793 Where represents the name of the node, and has the 794 following format: 796 "(" "," 797 "," 798 "," 799 "," 800 ")" ":" 801 803 Where is "IN" or "OUT", is the SPI of the security 804 association, is its destination, is in 805 our case "ESP", is either "TUNNEL" or "TRANSPORT", and 806 is an expression which describes the IPsec selectors, i.e., which 807 fields of the IPv6 packet must have which values. 809 We will be using an example mobile node in this section with the home 810 address "home_address_1". The user's identity in this mobile node is 811 "user_1". The home agent's address is "home_agent_1". 813 5.2 Manual Configuration 815 5.2.1 Binding Updates and Acknowledgements 817 Here are the contents of the SPD and SAD for protecting Binding 818 Updates and Acknowledgements: 820 mobile node SPD OUT: 821 - IF source = home_address_1 & destination = home_agent_1 & 822 proto = MH 823 THEN USE SA SA1 825 mobile node SPD IN: 826 - IF source = home_agent_1 & destination = home_address_1 & 827 proto = MH 828 THEN USE SA SA2 830 mobile node SAD: 831 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 832 source = home_address_1 & destination = home_agent_1 & 833 proto = MH 834 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 835 source = home_agent_1 & destination = home_address_1 & 836 proto = MH 838 home agent SPD OUT: 839 - IF source = home_agent_1 & destination = home_address_1 & 840 proto = MH 841 THEN USE SA SA2 843 home agent SPD IN: 844 - IF source = home_address_1 & destination = home_agent_1 & 845 proto = MH 846 THEN USE SA SA1 848 home agent SAD: 849 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 850 source = home_agent_1 & destination = home_address_1 & 851 proto = MH 852 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 853 source = home_address_1 & destination = home_agent_1 & 854 proto = MH 856 In the above, "MH" refers to the protocol number for the Mobility 857 Header [8]. 859 5.2.2 Return Routability Signaling 861 In the following we describe the necessary SPD and SAD entries to 862 protect return routability signaling between the mobile node and the 863 home agent. Note that the rules in the SPD are ordered, and the ones 864 in the previous section must take precedence over these ones. In 865 other words, the higher precedence entries must occur first in the 866 RFC 2401 [2] ordered list of SPD entries. 868 mobile node SPD OUT: 869 - IF interface = IPv6 IPv6 tunnel to home_agent_1 & 870 source = home_address_1 & destination = any & 871 proto = MH 872 THEN USE SA SA3 874 mobile node SPD IN: 875 - IF interface = IPv6 tunnel from home_agent_1 & 876 source = any & destination = home_address_1 & 877 proto = MH 878 THEN USE SA SA4 880 mobile node SAD: 881 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 882 source = home_address_1 & destination = any & proto = MH 883 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 884 source = any & destination = home_address_1 & proto = MH 886 home agent SPD OUT: 887 - IF interface = IPv6 tunnel to home_address_1 & 888 source = any & destination = home_address_1 & 889 proto = MH 890 THEN USE SA SA4 892 home agent SPD IN: 893 - IF interface = IPv6 tunnel from home_address_1 & 894 source = home_address_1 & destination = any & 895 proto = MH 896 THEN USE SA SA3 898 home agent SAD: 899 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 900 source = any & destination = home_address_1 & proto = MH 901 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 902 source = home_address_1 & destination = any & proto = MH 904 The security association from the home agent to the mobile node uses 905 the current care-of address as the destination. As discussed 906 earlier, this address is updated in the SAD as the mobile node moves. 907 It can be initialized to the home address before the mobile node has 908 registered. 910 5.2.3 Prefix Discovery 912 In the following we describe some additional SPD and SAD entries to 913 protect prefix discovery. Note that the SPDs described above protect 914 all ICMPv6 traffic between the mobile node and the home agent, as 915 IPsec may not have the ability to distinguish between different 916 ICMPv6 types. 918 mobile node SPD OUT: 919 - IF source = home_address_1 & destination = home_agent_1 & 920 proto = ICMPv6 921 THEN USE SA SA5. 923 mobile node SPD IN: 924 - IF source = home_agent_1 & destination = home_address_1 & 925 proto = ICMPv6 926 THEN USE SA SA6 928 mobile node SAD: 929 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 930 source = home_address_1 & destination = home_agent_1 & 931 proto = ICMPv6 932 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 933 source = home_agent_1 & destination = home_address_1 & 934 proto = ICMPv6 936 home agent SPD OUT: 937 - IF source = home_agent_1 & destination = home_address_1 & 938 proto = ICMPv6 939 THEN USE SA SA6 941 home agent SPD IN: 942 - IF source = home_address_1 & destination = home_agent_1 & 943 proto = ICMPv6 944 THEN USE SA SA5 946 home agent SAD: 947 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 948 source = home_agent_1 & destination = home_address_1 & 949 proto = ICMPv6 950 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 951 source = home_address_1 & destination = home_agent_1 & 952 proto = ICMPv6 954 5.2.4 Payload Packets 956 It is also possible to perform some additional, optional, protection 957 of tunneled payload packets. This protection takes place in a 958 similar manner to the return routability protection above, but 959 requires a different value for the protocol field. The necessary SPD 960 and SAD entries are shown below. It is assumed that the entries for 961 protecting Binding Updates and Acknowledgements, and the entries to 962 protect Home Test Init and Home Test messages take precedence over 963 these entries. 965 mobile node SPD OUT: 966 - IF interface = IPv6 tunnel to home_agent_1 & 967 source = home_address_1 & destination = any & 968 proto = X 969 THEN USE SA SA7 971 mobile node SPD IN: 972 - IF interface = IPv6 tunnel from home_agent_1 & 973 source = any & destination = home_address_1 & 974 proto = X 975 THEN USE SA SA8 977 mobile node SAD: 978 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 979 source = home_address_1 & destination = any & proto = X 980 - SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL): 981 source = any & destination = home_address_1 & proto = X 983 home agent SPD OUT: 984 - IF interface = IPv6 tunnel to home_address_1 & 985 source = any & destination = home_address_1 & 986 proto = X 987 THEN USE SA SA8 989 home agent SPD IN: 990 - IF interface = IPv6 tunnel from home_address_1 & 991 source = home_address_1 & destination = any & 992 proto = X 993 THEN USE SA SA7 995 home agent SAD: 996 - SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL): 997 source = any & destination = home_address_1 & proto = X 998 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 999 source = home_address_1 & destination = any & proto = X 1001 If multicast group membership control protocols such as MLDv1 [9] or 1002 MLDv2 [13] need to be protected, these packets may use a link-local 1003 address rather than the home address of the mobile node. In this 1004 case the source and destination can be left as a wildcard and the SPD 1005 entries will work solely based on the used interface and the 1006 protocol, which is ICMPv6 for both MLDv1 and MLDv2. 1008 Similar problems are encountered when stateful address 1009 autoconfiguration protocols such as DHCPv6 [10] are used. The same 1010 approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP 1011 protocol. 1013 Support for multiple layers of encapsulation (such as ESP 1014 encapsulated in ESP) is not required by RFC 2401 [2] and is also 1015 otherwise often problematic. It is therefore useful to avoid setting 1016 the protocol X in the above entries to either AH or ESP. 1018 5.3 Dynamic Keying 1020 In this section we show an example configuration that uses IKE to 1021 negotiate security associations. 1023 5.3.1 Binding Updates and Acknowledgements 1025 Here are the contents of the SPD for protecting Binding Updates and 1026 Acknowledgements: 1028 mobile node SPD OUT: 1029 - IF source = home_address_1 & destination = home_agent_1 & 1030 proto = MH 1031 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1033 mobile node SPD IN: 1034 - IF source = home_agent_1 & destination = home_address_1 & 1035 proto = MH 1036 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1038 home agent SPD OUT: 1039 - IF source = home_agent_1 & destination = home_address_1 & 1040 proto = MH 1041 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1043 home agent SPD IN: 1044 - IF source = home_address_1 & destination = home_agent_1 & 1045 proto = MH 1046 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1048 We have omitted details of the proposed transforms in the above, and 1049 all details related to the particular authentication method such as 1050 certificates beyond listing a specific identity that must be used. 1052 We require IKE version 1 to be run using the care-of addresses but 1053 still negotiate IPsec SAs that use home addresses. The extra 1054 conditions set by the home agent SPD for the peer phase 1 identity to 1055 be "user_1" must be verified by the home agent. The purpose of the 1056 condition is to ensure that the IKE phase 2 negotiation for a given 1057 user's home address can't be requested by another user. In the 1058 mobile node, we simply set our local identity to be "user_1". 1060 These checks also imply that the configuration of the home agent is 1061 user-specific: every user or home address requires a specific 1062 configuration entry. It would be possible to alleviate the 1063 configuration tasks by using certificates that have home addresses in 1064 the Subject AltName field. However, it isn't clear if all IKE 1065 implementations allow one address to be used for carrying the IKE 1066 negotiations when another address is mentioned in the used 1067 certificates. In any case, even this approach would have required 1068 user-specific tasks in the certification authority. 1070 5.3.2 Return Routability Signaling 1072 Protection for the return routability signaling can be configured in 1073 a similar manner as above. 1075 mobile node SPD OUT: 1076 - IF interface = IPv6 tunnel to home_agent_1 & 1077 source = home_address_1 & destination = any & 1078 proto = MH 1079 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1080 local phase 1 identity = user_1 1082 mobile node SPD IN: 1083 - IF interface = IPv6 tunnel from home_agent_1 & 1084 source = any & destination = home_address_1 & 1085 proto = MH 1086 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1087 local phase 1 identity = user_1 1089 home agent SPD OUT: 1090 - IF interface = IPv6 tunnel to home_address_1 & 1091 source = any & destination = home_address_1 & 1092 proto = MH 1093 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1094 peer phase 1 identity = user_1 1096 home agent SPD IN: 1097 - IF interface = IPv6 tunnel from home_address_1 & 1098 source = home_address_1 & destination = any & 1099 proto = MH 1100 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1101 peer phase 1 identity = user_1 1103 The security association from the home agent to the mobile node uses 1104 the current care-of address as the destination. As discussed 1105 earlier, this address is updated in the SAD as the mobile node moves. 1106 The SPD entries can be written using the home address (as above), if 1107 the care-of address update in the SAD is also done upon the creation 1108 of security associations. 1110 5.3.3 Prefix Discovery 1112 In the following we describe some additional SPD entries to protect 1113 prefix discovery with IKE. (Note that when actual new prefixes are 1114 discovered, there may be a need to enter new manually configured SPD 1115 entries to specify the authorization policy for the resulting new 1116 home addresses.) 1118 mobile node SPD OUT: 1119 - IF source = home_address_1 & destination = home_agent_1 & 1120 proto = ICMPv6 1121 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1123 mobile node SPD IN: 1124 - IF source = home_agent_1 & destination = home_address_1 & 1125 proto = ICMPv6 1126 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1128 home agent SPD OUT: 1129 - IF source = home_agent_1 & destination = home_address_1 & 1130 proto = ICMPv6 1131 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1133 home agent SPD IN: 1134 - IF source = home_address_1 & destination = home_agent_1 & 1135 proto = ICMPv6 1136 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1138 5.3.4 Payload Packets 1140 Protection for the payload packets happens similarly to the 1141 protection of return routability signaling. As in the manually keyed 1142 case, these SPD entries have lower priority than the above ones. 1144 mobile node SPD OUT: 1145 - IF interface = IPv6 tunnel to home_agent_1 & 1146 source = home_address_1 & destination = any & 1147 proto = X 1148 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1149 local phase 1 identity = user_1 1151 mobile node SPD IN: 1152 - IF interface = IPv6 tunnel from home_agent_1 & 1153 source = any & destination = home_address_1 & 1154 proto = X 1155 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1156 local phase 1 identity = user_1 1158 home agent SPD OUT: 1159 - IF interface = IPv6 tunnel to home_address_1 & 1160 source = any & destination = home_address_1 & 1161 proto = X 1162 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1163 peer phase 1 identity = user_1 1165 home agent SPD IN: 1166 - IF interface = IPv6 tunnel from home_address_1 & 1167 source = home_address_1 & destination = any & 1168 proto = X 1169 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1170 peer phase 1 identity = user_1 1172 6. Processing Steps within a Node 1174 6.1 Binding Update to the Home Agent 1176 Step 1. At the mobile node, Mobile IPv6 module first produces the 1177 following packet: 1179 IPv6 header (source = home address, 1180 destination = home agent) 1181 Mobility header 1182 Binding Update 1184 Step 2. This packet is matched against the IPsec SPD on the mobile 1185 node and we make a note that IPsec must be applied. 1187 Step 3. Then, we add the necessary Mobile IPv6 options but do not 1188 change the addresses yet, as described in Section 11.2.2 of the base 1189 specification [8]. This results in: 1191 IPv6 header (source = home address, 1192 destination = home agent) 1193 Destination Options header 1194 Home Address option (care-of address) 1195 Mobility header 1196 Binding Update 1198 Step 4. Finally, IPsec headers are added and the necessary 1199 authenticator values are calculated: 1201 IPv6 header (source = home address, 1202 destination = home agent) 1203 Destination Options header 1204 Home Address option (care-of address) 1205 ESP header (SPI = spi_a) 1206 Mobility header 1207 Binding Update 1209 Here spi_a is the SPI value that was either configured manually, or 1210 agreed upon in an earlier IKE negotiation. 1212 Step 5. Before sending the packet, the addresses in the IPv6 header 1213 and the Destination Options header are changed: 1215 IPv6 header (source = care-of address, 1216 destination = home agent) 1217 Destination Options header 1218 Home Address option (home address) 1219 ESP header (SPI = spi_a) 1220 Mobility header 1221 Binding Update 1223 6.2 Binding Update from the Mobile Node 1225 Step 1. The following packet is received at the home agent: 1227 IPv6 header (source = care-of address, 1228 destination = home agent) 1229 Destination Options header 1230 Home Address option (home address) 1231 ESP header (SPI = spi_a) 1232 Mobility header 1233 Binding Update 1235 Step 2. The home address option is processed first, which results in 1237 IPv6 header (source = home address, 1238 destination = home agent) 1239 Destination Options header 1240 Home Address option (care-of address) 1241 ESP header (SPI = spi_a) 1242 Mobility header 1243 Binding Update 1245 Step 3. ESP header is processed next, resulting in 1247 IPv6 header (source = home address, 1248 destination = home agent) 1249 Destination Options header 1250 Home Address option (care-of address) 1251 Mobility header 1252 Binding Update 1254 Step 4. This packet matches the policy required for this security 1255 association (source = home address, destination = home agent, proto = 1256 MH). 1258 Step 5. Mobile IPv6 processes the Binding Update. The Binding 1259 Update is delivered to the Mobile IPv6 module. 1261 Step 6. If there are any security associations in the security 1262 association database for the protection of return routability or 1263 payload packets for this mobile node, those security associations are 1264 updated with the new care-of address. 1266 6.3 Binding Acknowledgement to the Mobile Node 1268 Step 1. Mobile IPv6 produces the following packet: 1270 IPv6 header (source = home agent, 1271 destination = home address) 1272 Mobility header 1273 Binding Acknowledgement 1275 Step 2. This packet matches the IPsec policy entries, and we 1276 remember that IPsec has to be applied. 1278 Step 3. Then, we add the necessary Route Headers but do not change 1279 the addresses yet, as described in Section 9.6 of the base 1280 specification [8]. This results in: 1282 IPv6 header (source = home agent, 1283 destination = home address) 1284 Routing header (type 2) 1285 care-of address 1286 Mobility header 1287 Binding Acknowledgement 1289 Step 4. We apply IPsec: 1291 IPv6 header (source = home agent, 1292 destination = home address) 1293 Routing header (type 2) 1294 care-of address 1295 ESP header (SPI = spi_b) 1296 Mobility header 1297 Binding Acknowledgement 1299 Step 5. Finally, before sending the packet out we change the 1300 addresses in the IPv6 header and the Route header: 1302 IPv6 header (source = home agent, 1303 destination = care-of address) 1304 Routing header (type 2) 1305 home address 1306 ESP header (SPI = spi_b) 1307 Mobility header 1308 Binding Acknowledgement 1310 6.4 Binding Acknowledgement from the Home Agent 1312 Step 1. The following packet is received at the mobile node 1314 IPv6 header (source = home agent, 1315 destination = care-of address) 1316 Routing header (type 2) 1317 home address 1318 ESP header (SPI = spi_b) 1319 Mobility header 1320 Binding Acknowledgement 1322 Step 2. After the routing header is processed the packet becomes 1324 IPv6 header (source = home agent, 1325 destination = home address) 1326 Routing header (type 2) 1327 care-of address 1328 ESP header (SPI = spi_b) 1329 Mobility header 1330 Binding Acknowledgement 1332 Step 3. ESP header is processed next, resulting in: 1334 IPv6 header (source = home agent, 1335 destination = home address) 1336 Routing header (type 2) 1337 care-of address 1338 Mobility header 1339 Binding Acknowledgement 1341 Step 4. This packet matches the policy required for this security 1342 association (source = home agent, destination = home address, proto = 1343 MH). 1345 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 1346 module. 1348 6.5 Home Test Init to the Home Agent 1350 Step 1. The mobile node constructs a Home Test Init message: 1352 IPv6 header (source = home address, 1353 destination = correspondent node) 1354 Mobility header 1355 Home Test Init 1357 Step 2. Mobile IPv6 determines that this packet should go to the 1358 tunnel to the home agent. 1360 Step 3. The packet is matched against IPsec policy entries for the 1361 interface, and we find that IPsec needs to be applied. 1363 Step 4. IPsec tunnel mode headers are added. Note that we use a 1364 care-of address as a source address for the tunnel packet. 1366 IPv6 header (source = care-of address, 1367 destination = home agent) 1368 ESP header (SPI = spi_c) 1369 IPv6 header (source = home address, 1370 destination = correspondent node) 1371 Mobility header 1372 Home Test Init 1374 Step 5. The packet is sent directly to the home agent using IPsec 1375 encapsulation. 1377 6.6 Home Test Init from the Mobile Node 1379 Step 1. The home agent receives the following packet: 1381 IPv6 header (source = care-of address, 1382 destination = home agent) 1383 ESP header (SPI = spi_c) 1384 IPv6 header (source = home address, 1385 destination = correspondent node) 1386 Mobility Header 1387 Home Test Init 1389 Step 2. IPsec processing is performed, resulting in: 1391 IPv6 header (source = home address, 1392 destination = correspondent node) 1393 Mobility Header 1394 Home Test Init 1396 Step 3. The resulting packet matches the policy required for this 1397 security association and the packet can be processed further. 1399 Step 4. The packet is then forwarded to the correspondent node. 1401 6.7 Home Test to the Mobile Node 1403 Step 1. The home agent receives a Home Test packet from the 1404 correspondent node: 1406 IPv6 header (source = correspondent node, 1407 destination = home address) 1408 Mobility Header 1409 Home Test Init 1411 Step 2. The home agent determines that this packet is destined to a 1412 mobile node that is away from home, and decides to tunnel it. 1414 Step 3. The packet matches the IPsec policy entries for the tunnel 1415 interface, and we note that IPsec needs to be applied. 1417 Step 4. IPsec is applied, resulting in a new packet. Note that the 1418 home agent must keep track of the location of the mobile node, and 1419 update the tunnel endpoint address in the security association(s) 1420 accordingly. 1422 IPv6 header (source = home agent, 1423 destination = care-of address) 1424 ESP header (SPI = spi_d) 1425 IPv6 header (source = correspondent node, 1426 destination = home address) 1427 Mobility Header 1428 Home Test Init 1430 Step 5. The packet is sent directly to the care-of address using 1431 IPsec encapsulation. 1433 6.8 Home Test from the Home Agent 1435 Step 1. The mobile node receives the following packet: 1437 IPv6 header (source = home agent, 1438 destination = care-of address) 1439 ESP header (SPI = spi_d) 1440 IPv6 header (source = correspondent node, 1441 destination = home address) 1442 Mobility Header 1443 Home Test Init 1445 Step 2. IPsec is processed, resulting in: 1447 IPv6 header (source = correspondent node, 1448 destination = home address) 1449 Mobility Header 1450 Home Test Init 1452 Step 3. This matches the policy required for this security 1453 association (source = any, destination = home address). 1455 Step 4. The packet is given to Mobile IPv6 processing. 1457 6.9 Prefix Solicitation Message to the Home Agent 1459 This procedure is similar to the one presented in Section 6.1. 1461 6.10 Prefix Solicitation Message from the Mobile Node 1463 This procedure is similar to the one presented in Section 6.2. 1465 6.11 Prefix Advertisement Message to the Mobile Node 1467 This procedure is similar to the one presented in Section 6.3. 1469 6.12 Prefix Advertisement Message from the Home Agent 1471 This procedure is similar to the one presented in Section 6.4. 1473 6.13 Payload Packet to the Home Agent 1475 This procedure is similar to the one presented in Section 6.5. 1477 6.14 Payload Packet from the Mobile Node 1479 This procedure is similar to the one presented in Section 6.6. 1481 6.15 Payload Packet to the Mobile Node 1483 This procedure is similar to the one presented in Section 6.7. 1485 6.16 Payload Packet from the Home Agent 1487 This procedure is similar to the one presented in Section 6.8. 1489 6.17 Establishing New Security Associations 1491 Step 1. The mobile node wishes to send a Binding Update to the home 1492 agent. 1494 IPv6 header (source = home address, 1495 destination = home agent) 1496 Mobility header 1497 Binding Update 1499 Step 2. There is no existing security association to protect the 1500 Binding Update, so the mobile node initiates IKE. The IKE packets 1501 are sent as shown in the following examples. The first packet is an 1502 example of an IKE packet sent from the mobile node, and the second 1503 one is from the home agent. The examples shows also that the phase 1 1504 identity used for the mobile node is a FQDN. 1506 IPv6 header (source = care-of address, 1507 destination = home agent) 1508 UDP 1509 IKE 1510 ... IDii = ID_FQDN mn123.ha.net ... 1512 IPv6 header (source = home agent 1513 destination = care-of address) 1514 UDP 1515 IKE 1516 ... IDir = ID_FQDN ha.net ... 1518 Step 3. IKE phase 1 completes, and phase 2 is initiated to request 1519 security associations for protecting traffic between the mobile 1520 node's home address and the home agent. These addresses will be used 1521 as selectors. This involves sending and receiving additional IKE 1522 packets. The below example shows again one packet sent by the mobile 1523 node and another sent by the home agent. The example shows also that 1524 the phase 2 identity used for the mobile node is the mobile node's 1525 home address. 1527 IPv6 header (source = care-of address, 1528 destination = home agent) 1529 UDP 1530 IKE 1531 ... IDci = ID_IPV6_ADDR home address ... 1533 IPv6 header (source = home agent, 1534 destination = care-of address) 1535 UDP 1536 IKE 1537 ... IDcr = ID_IPV6_ADDR home agent ... 1539 Step 4. The remaining steps are as shown in Section 6.1. 1541 6.18 Rekeying Security Associations 1543 Step 1. The mobile node and the home agent have existing security 1544 associations. Either side may decide at any time that the security 1545 associations need to be rekeyed, for instance, because the specified 1546 lifetime is approaching. 1548 Step 2. Mobility header packets sent during rekey may be protected 1549 by the existing security associations. 1551 Step 3. When the rekeying is finished, new security associations are 1552 established. In practice there is a time interval during which an 1553 old, about-to-expire security association and newly established 1554 security association will both exist. The new ones should be used as 1555 soon as they become available. 1557 Step 4. A notification of the deletion of the old security 1558 associations is received. After this, only the new security 1559 associations can be used. 1561 Note that there is no requirement that the existence of the IPsec and 1562 IKE security associations is tied to the existence of bindings. It 1563 is not necessary to delete a security association if a binding is 1564 removed, as a new binding may soon be established after this. 1566 Since cryptographic acceleration hardware may only be able to handle 1567 a limited number of active security associations, security 1568 associations may be deleted via IKE in order to keep the number of 1569 active cryptographic contexts to a minimum. Such deletions should 1570 not be interpreted as a sign of losing a contact to the peer or as a 1571 reason to remove a binding. Rather, if additional traffic needs to 1572 be sent, it is preferable to bring up another security association to 1573 protect it. 1575 6.19 Movements and Dynamic Keying 1577 In this section we describe the sequence of events that relate to 1578 movement with IKE-based security associations. In the initial state, 1579 the mobile node is not registered in any location and has no security 1580 associations with the home agent. Depending on whether the peers 1581 will be able to move IKE endpoints to new care-of addresses, the 1582 actions taken in Step 9 and 10 are different. 1584 Step 1. Mobile node with the home address A moves to care-of address 1585 B. 1587 Step 2. Mobile node runs IKE from care-of address B to the home 1588 agent, establishing a phase 1. The home agent can only act as the 1589 responder before it knows the current location of the mobile node. 1591 Step 3. Protected by this phase 1, mobile node establishes a pair of 1592 security associations for protecting Mobility Header traffic to and 1593 from the home address A. 1595 Step 4. Mobile node sends a Binding Update and receives a Binding 1596 Acknowledgement using the security associations created in Step 3. 1598 Step 5. Mobile node establishes a pair of security associations for 1599 protecting return routability packets. These security associations 1600 are in tunnel mode and their endpoint in the mobile node side is 1601 care-of address B. For the purposes of our example, this step uses 1602 the phase 1 connection established in Step 2. Multiple phase 1 1603 connections are also possible. 1605 Step 6. The mobile node uses the security associations created in 1606 Step 5 to run return routability. 1608 Step 7. The mobile node moves to a new location and adopts a new 1609 care-of address C. 1611 Step 8. Mobile node sends a Binding Update and receives a Binding 1612 Acknowledgement using the security associations created in Step 3. 1613 The home agent ensures that the next packets sent using the security 1614 associations created in Step 5 will have the new care-of address as 1615 their destination address, as if the outer header destination address 1616 in the security association had changed. 1618 Step 9. If the mobile node and the HA have the capability to change 1619 the IKE endpoints, they change the address to C. If they dont have 1620 the capability, both nodes remove their phase 1 connections created 1621 on top of the care-of address B and will establish a new IKE phase 1 1622 on top of the care-of address C. This capability to change the IKE 1623 phase 1 end points is indicated through setting the Key Management 1624 Mobility Capability (K) flag [8] in the Binding Update and Binding 1625 Acknowledgement messages. 1627 Step 10. If a new IKE phase 1 connection was setup after movement, 1628 the MN will not be able to receive any notifications delivered on top 1629 of the old IKE phase 1 security association. Notifications delivered 1630 on top of the new security association are received and processed 1631 normally. If the mobile node and HA were able to update the IKE 1632 endpoints, they can continue using the same IKE phase 1 connection. 1634 7. Implementation Considerations 1636 7.1 IPsec 1638 Note that packet formats and header ordering discussed in Section 3 1639 must be supported, but implementations may also support other 1640 formats. In general, the use of formats not required here may lead 1641 to incorrect processing of the packets by the peer (such as silently 1642 discarding them), unless support for these formats has been verified 1643 off-line. Such verification can take place at the same time the 1644 parameters of the security associations are agreed upon. In some 1645 cases, however, basic IPv6 specifications call for support of options 1646 not discussed here. In these cases such verification step might be 1647 unnecessary as long as the peer fully supports the relevant IPv6 1648 specifications. However, no claims are made in this document about 1649 the validity of these other formats in the context of Mobile IPv6. 1650 It is also likely that systems that support Mobile IPv6 have been 1651 tested more extensively with the required formats. 1653 We have chosen to require an encapsulation format for return 1654 routability and payload packet protection which can only be realized 1655 if the destination of the IPsec packets sent from the home agent can 1656 be changed as the mobile node moves. One of the main reasons for 1657 choosing such a format is that it removes the overhead of twenty four 1658 bytes when a home address option or routing header is added to the 1659 tunneled packet. Such an overhead would not be significant for the 1660 protection of the return routability packets, but would create an 1661 additional overhead if IPsec is used to protect the tunneling of 1662 payload packets to the home agent. This overhead may be significant 1663 for real-time traffic. Given that the use of the shorter packet 1664 formats for any traffic requires the existence of suitable APIs, we 1665 have chosen to require support for the shorter packet formats both 1666 for payload and return routability packets. 1668 In order to support the care-of address as the destination address on 1669 the mobile node side, the home agent must act as if the outer header 1670 destination address in the security association to the mobile node 1671 would have changed upon movements. Implementations are free to 1672 choose any particular method to make this change, such as using an 1673 API to the IPsec implementation to change the parameters of the 1674 security association, removing the security association and 1675 installing a new one, or modification of the packet after it has gone 1676 through IPsec processing. The only requirement is that after 1677 registering a new binding at the home agent, the next IPsec packets 1678 sent on this security association will be addressed to the new 1679 care-of address. 1681 We have chosen to require policy entries that are specific to a 1682 tunnel interface. This means that implementations have to regard the 1683 Home Agent - Mobile Node tunnel as a separate interface on which 1684 IPsec SPDs can be based. A further complication of the IPsec 1685 processing on a tunnel interface is that this requires access to the 1686 BITS implementation before the packet actually goes out. 1688 7.2 IKE 1690 We have chosen to require that a dynamic key management protocol must 1691 be able to make an authorization decision for IPsec security 1692 association creation with different addresses than with what the key 1693 management protocol is run. We expect this to be done typically by 1694 configuring the allowed combinations of phase 1 user identities and 1695 home addresses. 1697 When certificate authentication is used, IKE fragmentation can be 1698 encountered. This can occur when certificate chains are used, or 1699 even with single certificates if they are large. Many firewalls do 1700 not handle fragments properly, and may drop them. Routers in the 1701 path may also discard fragments after the initial one, since they 1702 typically will not contain full IP headers that can be compared 1703 against an access list. Where fragmentation occurs, the endpoints 1704 will not always be able to establish a security association. 1706 Fortunately, typical Mobile IPv6 deployment uses short certificate 1707 chains, as the mobile node is communicating directly with its home 1708 network. Where the problem appears, it may be difficult (at least 1709 away from home) to replace the firewalls or routers with equipment 1710 that can properly support fragments. It may help to store the peer 1711 certificates locally, or to obtain them through other means. 1713 7.3 Bump-in-the-Stack 1715 Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack 1716 (BITS) implementation model of IPsec. As Mobile IPv6 specific 1717 modifications of the packets are required before or after IPsec 1718 processing, the BITS implementation has to perform also some tasks 1719 related to mobility. This may increase the complexity of the 1720 implementation, even if it already performs some tasks of the IP 1721 layer (such as fragmentation). 1723 Specifically, Bump-in-the-Stack implementations may have to deal with 1724 the following issues: 1726 o Processing the Home Address destination option and Routing header 1727 type 2 to a form suitable for IPsec processing to take place. 1728 This is needed, among other things, for the security association 1729 and policy lookups. While relatively straightforward, the 1730 required processing may have a hardware effect in BITS 1731 implementations, if they use hardware support beyond the 1732 cryptographic operations. 1734 o Detecting packets sent between the mobile node and its home agent 1735 using IPv6 encapsulation. 1737 o Offering the necessary APIs for updating the IPsec and IKE 1738 security association endpoints. 1740 8. IANA Considerations 1742 No IANA actions are necessary based on this document. IANA actions 1743 for the Mobile IPv6 protocol itself have been covered in [8]. 1745 9. Security Considerations 1747 The Mobile IPv6 base specification [8] requires strong security 1748 between the mobile node and the home agent. This memo discusses how 1749 that security can be arranged in practice, using IPsec. The security 1750 considerations related to this are documented in the base 1751 specification, including a discussion of the implications of using 1752 either manual or dynamic keying. 1754 Normative References 1756 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1757 Levels", BCP 14, RFC 2119, March 1997. 1759 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1760 Internet Protocol", RFC 2401, November 1998. 1762 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1763 November 1998. 1765 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1766 (ESP)", RFC 2406, November 1998. 1768 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1769 RFC 2409, November 1998. 1771 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1772 Specification", RFC 2460, December 1998. 1774 [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1775 Specification", RFC 2473, December 1998. 1777 [8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1778 IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2003. 1780 Informative References 1782 [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1783 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1785 [10] Droms, R., "Dynamic Host Configuration Protocol for IPv6 1786 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 1787 November 2002. 1789 [11] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe, 1790 "Negotiation of NAT-Traversal in the IKE", 1791 draft-ietf-ipsec-nat-t-ike-04 (work in progress), November 1792 2002. 1794 [12] Touch, J. and L. Eggert, "Use of IPsec Transport Mode for 1795 Dynamic Routing", draft-touch-ipsec-vpn-04 (work in progress), 1796 June 2002. 1798 [13] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1799 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 1800 December 2002. 1802 Authors' Addresses 1804 Jari Arkko 1805 Ericsson 1806 Jorvas 02420 1807 Finland 1809 EMail: jari.arkko@ericsson.com 1811 Vijay Devarapalli 1812 Nokia Research Center 1813 313 Fairchild Drive 1814 Mountain View CA 94043 1815 USA 1817 EMail: vijayd@iprg.nokia.com 1818 Francis Dupont 1819 ENST Bretagne 1820 Campus de Rennes 2, rue de la Chataigneraie 1821 BP 78 1822 Cesson-Sevigne Cedex 35512 1823 France 1825 EMail: Francis.Dupont@enst-bretagne.fr 1827 Appendix A. Acknowledgements 1829 The authors would like to thank Greg O'Shea, Michael Thomas, Kevin 1830 Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel 1831 Montenegro, Steven Kent, and Santeri Paavolainen for interesting 1832 discussions in this problem space. 1834 Appendix B. Changes from Previous Version 1836 The following changes have been made to this document from version 1837 04: 1839 o Implications for Bumb-in-the-Stack implementations have been more 1840 extensively discussed (tracked issue 307). 1842 o The required policy checks for protecting return routability 1843 packets have been clarified; the language now allows different 1844 implementations as long as the end result is the same (tracked 1845 issue 306). 1847 o The required IPsec SPD checks have been clarified. While it is 1848 required that policy checks be based on the home address (from the 1849 Home Address destination option), this does not imply a change in 1850 the IPsec SPD entries. Instead, this is a mere processing order 1851 issue (tracked issue 292). 1853 o Justifications have been added to explain why return routability 1854 packets require protection (tracked issue 292). 1856 o The precise meaning of "inactive" SPD entries and SAs has been 1857 clarified (tracked issue 292). 1859 o The IKE text has been made more precise with respect to the IKE 1860 version the text applies to (tracked issue 292). 1862 o "Manual keying" has been clarified to mean manually created IPsec 1863 security associations, not the configuration of preshared secret 1864 in IKE (tracked issue 296). 1866 o Most of AH discussion has been left out from the document, and 1867 replaced with a note in the introduction (tracked issue 296). 1869 o Section 7 no longer recommends replacing routers in the face of 1870 certificate fragmentation problems (tracked issue 287). 1872 o The draft now explains the background for the decision to use 1873 care-of addresses as the source address for IKE and in the tunnel 1874 packets from the mobile node (tracked issue 284). 1876 o The draft now explains that the decision to use care-of addresses 1877 in IKE implies that shared secrets cannot be used with Main Mode 1878 even where a static (home) address is available (tracked issue 1879 284). 1881 o The draft now explains where the API between the IPsec and the 1882 Mobile IPv6 should and should not be used (tracked issue 284). 1884 o The draft clarifies now the requirements with respect to the use 1885 of IPsec tunnel mode versus the use of IP-in-IP encapsulation 1886 (tracked issue 284). 1888 o The draft clarifies the implications of either using or not using 1889 IKE (tracked issue 282). 1891 o Some editorial modifications have been performed (tracked issues 1892 287 and 292). 1894 Intellectual Property Statement 1896 The IETF takes no position regarding the validity or scope of any 1897 intellectual property or other rights that might be claimed to 1898 pertain to the implementation or use of the technology described in 1899 this document or the extent to which any license under such rights 1900 might or might not be available; neither does it represent that it 1901 has made any effort to identify any such rights. Information on the 1902 IETF's procedures with respect to rights in standards-track and 1903 standards-related documentation can be found in BCP-11. Copies of 1904 claims of rights made available for publication and any assurances of 1905 licenses to be made available, or the result of an attempt made to 1906 obtain a general license or permission for the use of such 1907 proprietary rights by implementors or users of this specification can 1908 be obtained from the IETF Secretariat. 1910 The IETF invites any interested party to bring to its attention any 1911 copyrights, patents or patent applications, or other proprietary 1912 rights which may cover technology that may be required to practice 1913 this standard. Please address the information to the IETF Executive 1914 Director. 1916 Full Copyright Statement 1918 Copyright (C) The Internet Society (2003). All Rights Reserved. 1920 This document and translations of it may be copied and furnished to 1921 others, and derivative works that comment on or otherwise explain it 1922 or assist in its implementation may be prepared, copied, published 1923 and distributed, in whole or in part, without restriction of any 1924 kind, provided that the above copyright notice and this paragraph are 1925 included on all such copies and derivative works. However, this 1926 document itself may not be modified in any way, such as by removing 1927 the copyright notice or references to the Internet Society or other 1928 Internet organizations, except as needed for the purpose of 1929 developing Internet standards in which case the procedures for 1930 copyrights defined in the Internet Standards process must be 1931 followed, or as required to translate it into languages other than 1932 English. 1934 The limited permissions granted above are perpetual and will not be 1935 revoked by the Internet Society or its successors or assignees. 1937 This document and the information contained herein is provided on an 1938 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1939 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1940 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1941 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1942 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1944 Acknowledgement 1946 Funding for the RFC Editor function is currently provided by the 1947 Internet Society.