idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-06.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 (June 30, 2003) is 7596 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 (-08) exists of draft-ietf-ipsec-nat-t-ike-04 == Outdated reference: A later version (-08) exists of draft-vida-mld-v2-06 Summary: 6 errors (**), 0 flaws (~~), 7 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: December 29, 2003 V. Devarapalli 5 Nokia Research Center 6 F. Dupont 7 ENST Bretagne 8 June 30, 2003 10 Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and 11 Home Agents 12 draft-ietf-mobileip-mipv6-ha-ipsec-06.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 December 29, 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 . . . . . . . . . . . . . . . . . . . . . . 46 106 B. Changes from Previous Version . . . . . . . . . . . . . . . 47 107 Intellectual Property and Copyright Statements . . . . . . . 48 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 anti-replay protection. The mobile node and the home agent must have 190 an IPsec security association to protect this traffic. IPsec does 191 not proving correct ordering of messages. Correct ordering of the 192 control traffic is ensured by a sequence number in the Binding Update 193 and Binding Acknowledgement messages. The sequence number in the 194 Binding Updates also provides protection to a certain extent. It 195 fails in some scenarios, for example, if the Home Agent loses the 196 Binding Cache state. Full protection against replay attacks is 197 possible only when IKE is used. 199 Great care is needed when using IKE [5] to establish security 200 associations to Mobile IPv6 home agents. The right kind of addresses 201 must be used for transporting IKE. This is necessary to avoid 202 circular dependencies in which the use of a Binding Update triggers 203 the need for an IKE exchange that cannot complete prior to the 204 Binding Update having been completed. 206 The mobile IPv6 base document defines the main requirements the 207 mobile nodes and home agents must follow when securing the above 208 traffic. This document discusses these requirements in more depth, 209 illustrates the used packet formats, describes suitable configuration 210 procedures, and shows how implementations can process the packets in 211 the right order. 213 We begin our description by showing the required wire formats for the 214 protected packets in Section 3. Section 4 describes rules which 215 associated Mobile IPv6, IPsec, and IKE implementations must observe. 216 Section 5 discusses how to configure either manually keyed IPsec 217 security associations or how to configure IKE to establish them 218 automatically. Section 6 shows examples of how packets are processed 219 within the nodes. 221 All implementations of Mobile IPv6 mobile node and home agent MUST 222 support at least the formats described in Section 3 and obey the 223 rules in Section 4. Note that in addition to the use of ESP as 224 specified here, it may also be possible to use Authentication Header 225 (AH) [3], but for brevity this is not discussed in this 226 specification. 228 The configuration and processing sections are informative, and should 229 only be considered as one possible way of providing the required 230 functionality. 232 Note that where this document indicates a feature MUST be supported 233 and SHOULD be used, this implies that all implementations must be 234 capable of using the specified feature, but there may be cases where, 235 for instance, a configuration option disables to use of the feature 236 in a particular situation. 238 2. Terminology 240 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in RFC 2119 [1]. 244 3. Packet Formats 246 3.1 Binding Updates and Acknowledgements 248 When the mobile node is away from its home, the BUs sent by it to the 249 home agent MUST support at least the following headers in the 250 following order: 252 IPv6 header (source = care-of address, 253 destination = home agent) 254 Destination Options header 255 Home Address option (home address) 256 ESP header in transport mode 257 Mobility header 258 Binding Update 259 Alternate Care-of Address option (care-of address) 261 Note that the Alternate Care-of Address option is used to ensure that 262 the care-of address is protected by ESP. The home agent considers 263 the address within this option as the current care-of address for the 264 mobile node. The home address is not protected by ESP directly, but 265 the use of a specific home address with a specific security 266 association is required by policy. 268 The Binding Acknowledgements sent back to the mobile node when it is 269 away from home MUST support at least the following headers in the 270 following order: 272 IPv6 header (source = home agent, 273 destination = care-of address) 274 Routing header (type 2) 275 home address 276 ESP header in transport mode 277 Mobility header 278 Binding Acknowledgement 280 When the mobile node is at home, the above rules are different as the 281 mobile node can use its home address as a source address. This 282 typically happens for the de-registration Binding Update when the 283 mobile is returning home. In this situation, the Binding Updates 284 MUST support at least the following headers in the following order: 286 IPv6 header (source = home address, 287 destination = home agent) 288 ESP header in transport mode 289 Mobility header 290 Binding Update 292 The Binding Acknowledgement messages sent to the home address MUST 293 support at least the following headers in the following order: 295 IPv6 header (source = home agent, 296 destination = home address) 297 ESP header in transport mode 298 Mobility header 299 Binding Acknowledgement 301 3.2 Return Routability Signaling 303 When the Home Test Init messages tunneled to the home agent are 304 protected by IPsec, they MUST support at least the following headers 305 in the following order: 307 IPv6 header (source = care-of address, 308 destination = home agent) 309 ESP header in tunnel mode 310 IPv6 header (source = home address, 311 destination = correspondent node) 312 Mobility Header 313 Home Test Init 315 This format assumes that the mobile node's current care-of address is 316 used as the outer header destination address in the security 317 association. As discussed in Section 4.3, this requires the home 318 agent to update the destination address when the mobile node moves. 319 Policy entries and security association selectors stay the same, 320 however, as the inner packets do not change upon movements. 322 Note that there are trade-offs in using care-of addresses as the 323 destination addresses versus using the home address and attaching an 324 additional Home Address destination option and/or Routing header to 325 the packets. The basis for requiring support for at least the 326 care-of address case has been discussed in Section 7. 328 Similarly, when the Home Test messages tunneled from the home agent 329 are protected by IPsec, they MUST support at least the following 330 headers in the following order: 332 IPv6 header (source = home agent, 333 destination = care-of address) 334 ESP header in tunnel mode 335 IPv6 header (source = correspondent node, 336 destination = home address) 337 Mobility Header 338 Home Test 340 The format used to protect return routability packets relies on the 341 destination of the tunnel packets to change for the mobile node as it 342 moves. The home agent's address stays the same, but the mobile 343 node's address changes upon movements, as if the security 344 association's outer header destination address had changed. When the 345 mobile node adopts a new care-of address, it adopts also a new source 346 address for outgoing tunnel packets. The home agent accepts packets 347 sent like this, as the outer source address in tunnel packets is not 348 checked according to the rules in RFC 2401. (We note, however, that 349 some implementations are known to make source address checks.) For a 350 discussion of the role of source addresses in outer tunnel headers, 351 see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent 352 requires the packets to be authenticated regardless of the source 353 address change, hence the "new" sender must possess the same keys for 354 the security association as the it had in the previous location. 355 This proves that the sender is the same entity, regardless of the 356 changes in the addresses. 358 The process is more complicated in the home agent side, as the home 359 agent has stored the previous care-of address in its Security 360 Association Database as the outer header destination address. When 361 IKE is being used, the mobile node runs it on top of its current 362 care-of address, and the resulting tunnel-mode security associations 363 will use the same addresses as IKE run over. In order for the home 364 agent to be able to tunnel a Home Test message to the mobile node, it 365 uses the current care-of address as the destination of the tunnel 366 packets, as if the home agent had modified the outer header 367 destination address in the security association used for this 368 protection. This implies that the same security association can be 369 used in multiple locations, and no new configuration or 370 re-establishment of IKE phases is needed per movement. Section 5.2.2 371 discusses the security policy and security association database 372 entries that are needed to accomplish this. 374 3.3 Prefix Discovery 376 If IPsec is used to protect prefix discovery, requests for prefixes 377 from the mobile node to the home agent MUST support at least the 378 following headers in the following order. 380 IPv6 header (source = care-of address, 381 destination = home agent) 382 Destination Options header 383 Home Address option (home address) 384 ESP header in transport mode 385 ICMPv6 386 Mobile Prefix Solicitation 388 Again if IPsec is used, solicited and unsolicited prefix information 389 advertisements from the home agent to the mobile node MUST support at 390 least the following headers in the following order. 392 IPv6 header (source = home agent, 393 destination = care-of address) 394 Routing header (type 2) 395 home address 396 ESP header in transport mode 397 ICMPv6 398 Mobile Prefix Advertisement 400 3.4 Payload Packets 402 If IPsec is used to protect payload packets tunneled to the home 403 agent from the mobile node, a similar format is used as in the case 404 of tunneled Home Test Init messages. However, instead of the 405 Mobility Header these packets may contain any legal IPv6 protocol(s): 407 IPv6 header (source = care-of address, 408 destination = home agent) 409 ESP header in tunnel mode 410 IPv6 header (source = home address, 411 destination = correspondent node) 412 Any protocol 414 Similarly, when the payload packets are tunneled from the home agent 415 to the mobile node with ESP encapsulation, they MUST support at least 416 the following headers in the following order: 418 IPv6 header (source = home agent, 419 destination = care-of address) 420 ESP header in tunnel mode 421 IPv6 header (source = correspondent node, 422 destination = home address) 423 Any protocol 425 4. Requirements 427 This section describes mandatory rules for all Mobile IPv6 mobile 428 nodes and home agents. These rules are necessary in order for it to 429 be possible to enable IPsec communications despite movements, 430 guarantee sufficient security, and to ensure correct processing order 431 of packets. 433 The rules in the following sections apply only to the communications 434 between home agents and mobile nodes. They should not be taken as 435 requirements on how IPsec in general is used by mobile nodes. 437 4.1 Mandatory Support 439 The following requirements apply to both home agents and mobile 440 nodes: 442 o Manual configuration of IPsec security associations MUST be 443 supported. The configuration of the keys is expected to take 444 place out-of-band, for instance at the time the mobile node is 445 configured to use its home agent. 447 o Automatic key management with IKE [5] MAY be supported. Only 448 IKEv1 is discussed in this document. Other automatic key 449 management mechanisms exist and will appear beyond IKEv1, but this 450 document does not address the issues related to them. 452 o ESP encapsulation of Binding Updates and Acknowledgements between 453 the mobile node and home agent MUST be supported and MUST be used. 455 o ESP encapsulation of the Home Test Init and Home Test messages 456 tunneled between the mobile node and home agent MUST be supported 457 and SHOULD be used. 459 o ESP encapsulation of the ICMPv6 messages related to prefix 460 discovery MUST be supported and SHOULD be used. 462 o ESP encapsulation of the payload packets tunneled between the 463 mobile node and home agent MAY be supported and used. 465 o If multicast group membership control protocols or stateful 466 address autoconfiguration protocols are supported, payload data 467 protection MUST be supported for those protocols. 469 4.2 Policy Requirements 471 The following requirements apply to both home agents and mobile 472 nodes: 474 o As required in the base specification [8], when a packet destined 475 to the receiving node is matched against IPsec security policy or 476 selectors of a security association, an address appearing in a 477 Home Address destination option is considered as the source 478 address of the packet. 480 Note that the home address option appears before IPsec headers. 481 Section 11.3.2 of the base specification describes one possible 482 implementation approach for this: The IPsec policy operations can 483 be performed at the time when the packet has not yet been modified 484 per Mobile IPv6 rules, or has been brought back to its normal form 485 after Mobile IPv6 processing. That is, the processing of the Home 486 Address option is seen as a fixed transformation of the packets 487 that does not affect IPsec processing. 489 o Similarly, a home address within a Type 2 Routing header destined 490 to the receiving node is considered as the destination address of 491 the packet, when a packet is matched against IPsec security policy 492 or selectors of a security association. 494 Similar implementation considers apply to the Routing header 495 processing as was described above for the Home Address destination 496 option. 498 o When IPsec is used to protect return routability signaling or 499 payload packets, this protection MUST only be applied to the 500 return routability packets entering the IPv6 encapsulated tunnel 501 interface between the mobile node and the home agent. This can be 502 achieved, for instance, by defining the security policy database 503 entries specifically for the tunnel interface. That is, the 504 policy entries are not generally applied on all traffic on the 505 physical interface(s) of the nodes, but rather only on traffic 506 that enters this tunnel. 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. 622 The following rules apply to mobile nodes: 624 o When ESP is used to protect Binding Updates, there is no 625 protection for the care-of address which appears in the IPv6 626 header outside the area protected by ESP. It is important for the 627 home agent to verify that the care-of address has not been 628 tampered with. As a result, the attacker would have redirected 629 the mobile node's traffic to another address. In order to prevent 630 this, Mobile IPv6 implementations MUST use the Alternate Care-of 631 Address mobility option in Binding Updates sent by mobile nodes 632 while away from home. The exception to this is when the mobile 633 node returns home and sends a Binding Update to the home agent in 634 order to de-register. In this case no Alternate Care-of Address 635 option is needed, as described in Section 3.1. 637 o When IPsec is used to protect return routability signaling or 638 payload packets, the mobile node MUST set the source address it 639 uses for the outgoing tunnel packets to the current primary 640 care-of address. The mobile node starts to use a new primary 641 care-of address immediately after sending a Binding Update to the 642 home agent to register this new address. Similarly, it starts to 643 use the new address as the required destination address of 644 tunneled packets received from the home agent. 646 The following rules apply to home agents: 648 o When IPsec is used to protect return routability signaling or 649 payload packets, IPsec security associations are needed to provide 650 this protection. When the care-of address for the mobile node 651 changes as a result of an accepted Binding Update, special 652 treatment is needed for the next packets sent using these security 653 associations. The home agent MUST set the new care-of address as 654 the destination address of these packets, as if the outer header 655 destination address in the security association had changed. 656 Similarly, the home agent starts to expect the new source address 657 in the tunnel packets received from the mobile node. 659 Such address changes can be implemented, for instance, through an 660 API from the Mobile IPv6 implementation to the IPsec 661 implementation. It should be noted that the use of such an API 662 and the address changes MUST only be done based on the Binding 663 Updates received by the home agent and protected by the use of 664 IPsec. Address modifications based on other sources, such as 665 Binding Updates to the correspondent nodes protected by return 666 routability, or open access to an API from any application may 667 result in security vulnerabilities. 669 4.4 Dynamic Keying 671 The following requirements apply to both home agents and mobile 672 nodes: 674 o If anti-replay protection is required, dynamic keying MUST be 675 used. IPsec can provide anti-replay protection only if dynamic 676 keying is used (which may not always be the case). IPsec also 677 does not guarantee correct ordering of packets, only that they 678 have not been replayed. Because of this, sequence numbers within 679 the Mobile IPv6 messages are used to ensure correct ordering. 680 However, if the 16 bit Mobile IPv6 sequence number space is cycled 681 through, or the home agent reboots and loses its state regarding 682 the sequence numbers, replay and reordering attacks become 683 possible. The use of dynamic keying, IPsec anti-replay 684 protection, and the Mobile IPv6 sequence numbers can together 685 prevent such attacks. 687 o If IKE version 1 is used with preshared secrets in main mode, it 688 determines the shared secret to use from the IP address of the 689 peer. With Mobile IPv6, however, this may be a care-of address 690 and does not indicate which mobile node attempts to contact the 691 home agent. Therefore, if preshared secret authentication is used 692 in IKEv1 between the mobile node and the home agent then 693 aggressive mode MUST be used. Note also that care needs to be 694 taken with phase 1 identity selection. Where the ID_IPV6_ADDR 695 Identity Payloads is used, unambiguous mapping of identities to 696 keys is not possible. (The next version of IKE may not have these 697 limitations.) 699 Note that the difficulties with main mode and preshared secrets in 700 IKE version 1 are well known for dynamic addresses. With static 701 addresses, there has not been a problem. With Mobile IPv6, 702 however, the use of the care-of addresses to run IKE to the home 703 agent presents a problem even when the home address stays stable. 704 Further discussion about the use of care-of addresses in this way 705 appears in Section 7. 707 The following rules apply to mobile nodes: 709 o In addition to the rules above, if dynamic keying is used, the key 710 management protocol MUST use the care-of address as the source 711 address in the protocol exchanges with the mobile node's home 712 agent. 714 o However, the IPsec security associations with the mobile node's 715 home agent use home addresses. That is, the IPsec security 716 associations MUST be requested from the key management protocol 717 using the home address of the mobile node as the client identity. 719 The security associations for protecting Binding Updates and 720 Acknowledgements are requested for the Mobility header protocol in 721 transport mode and for specific IP addresses as endpoints. No 722 other selectors are used. Similarly, the security associations 723 for protecting prefix discovery are requested for the ICMPv6 724 protocol and the specific IP addresses, again without other 725 selectors. Security associations for payload and return 726 routability protection are requested for a specific tunnel 727 interface and either the payload protocol or the Mobility header 728 protocol, in tunnel mode. In this case one requested endpoint is 729 an IP address and the other one is a wildcard, and there are no 730 other selectors. 732 o If the mobile node has used IKE version 1 to establish security 733 associations with its home agent, it should follow the procedures 734 discussed in Section 11.7.1 and 11.7.3 of the base specification 735 [8] to determine whether the IKE endpoints can be moved or if IKE 736 phase 1 has to be re-established. 738 The following rules apply to home agents: 740 o If the home agent has used IKE version 1 to establish security 741 associations with the mobile node, it should follow the procedures 742 discussed in Section 10.3.1 and 10.3.2 of the base specification 743 [8] to determine whether the IKE endpoints can be moved or if IKE 744 phase 1 has to be re-established. 746 5. Example Configurations 748 In the following we describe the Security Policy Database (SPD) and 749 Security Association Database (SAD) entries necessary to protect 750 Binding Updates and Binding Acknowledgements exchanged between the 751 mobile node and the home agent. 753 Section 5.1 introduces the format we use in the description of the 754 SPD and the SAD. Section 5.2 describes how to configure manually 755 keyed IPsec security associations without dynamic keying, and Section 756 5.3 describes how to use dynamic keying. 758 5.1 Format 760 The format used in the examples is as follows. The SPD description 761 has the format 763 "SPD OUT:" 764 "-" 765 "-" 766 ... 767 "-" 769 "SPD IN:" 770 "-" 771 "-" 772 ... 773 "-" 775 Where represents the name of the node, and has the 776 following format: 778 "IF" "THEN USE SA " | 779 "IF" "THEN USE SA " | 781 Where is a boolean expression about the fields of the 782 IPv6 packet, is the name of a specific security association, and 783 is a specification for a security association to be 784 negotiated via IKE [5]. The SAD description has the format 786 "SAD:" 787 "-" 788 "-" 789 ... 790 "-" 792 Where represents the name of the node, and has the 793 following format: 795 "(" "," 796 "," 797 "," 798 "," 799 ")" ":" 800 802 Where is "IN" or "OUT", is the SPI of the security 803 association, is its destination, is in 804 our case "ESP", is either "TUNNEL" or "TRANSPORT", and 805 is an expression which describes the IPsec selectors, i.e., which 806 fields of the IPv6 packet must have which values. 808 We will be using an example mobile node in this section with the home 809 address "home_address_1". The user's identity in this mobile node is 810 "user_1". The home agent's address is "home_agent_1". 812 5.2 Manual Configuration 814 5.2.1 Binding Updates and Acknowledgements 816 Here are the contents of the SPD and SAD for protecting Binding 817 Updates and Acknowledgements: 819 mobile node SPD OUT: 820 - IF source = home_address_1 & destination = home_agent_1 & 821 proto = MH 822 THEN USE SA SA1 824 mobile node SPD IN: 825 - IF source = home_agent_1 & destination = home_address_1 & 826 proto = MH 827 THEN USE SA SA2 829 mobile node SAD: 830 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 831 source = home_address_1 & destination = home_agent_1 & 832 proto = MH 833 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 834 source = home_agent_1 & destination = home_address_1 & 835 proto = MH 837 home agent SPD OUT: 838 - IF source = home_agent_1 & destination = home_address_1 & 839 proto = MH 840 THEN USE SA SA2 842 home agent SPD IN: 843 - IF source = home_address_1 & destination = home_agent_1 & 844 proto = MH 845 THEN USE SA SA1 847 home agent SAD: 848 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 849 source = home_agent_1 & destination = home_address_1 & 850 proto = MH 851 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 852 source = home_address_1 & destination = home_agent_1 & 853 proto = MH 855 In the above, "MH" refers to the protocol number for the Mobility 856 Header [8]. 858 5.2.2 Return Routability Signaling 860 In the following we describe the necessary SPD and SAD entries to 861 protect return routability signaling between the mobile node and the 862 home agent. Note that the rules in the SPD are ordered, and the ones 863 in the previous section must take precedence over these ones. In 864 other words, the higher precedence entries must occur first in the 865 RFC 2401 [2] ordered list of SPD entries. 867 mobile node SPD OUT: 868 - IF interface = IPv6 IPv6 tunnel to home_agent_1 & 869 source = home_address_1 & destination = any & 870 proto = MH 871 THEN USE SA SA3 873 mobile node SPD IN: 874 - IF interface = IPv6 tunnel from home_agent_1 & 875 source = any & destination = home_address_1 & 876 proto = MH 877 THEN USE SA SA4 879 mobile node SAD: 880 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 881 source = home_address_1 & destination = any & proto = MH 882 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 883 source = any & destination = home_address_1 & proto = MH 885 home agent SPD OUT: 886 - IF interface = IPv6 tunnel to home_address_1 & 887 source = any & destination = home_address_1 & 888 proto = MH 889 THEN USE SA SA4 891 home agent SPD IN: 892 - IF interface = IPv6 tunnel from home_address_1 & 893 source = home_address_1 & destination = any & 894 proto = MH 895 THEN USE SA SA3 897 home agent SAD: 898 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 899 source = any & destination = home_address_1 & proto = MH 900 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 901 source = home_address_1 & destination = any & proto = MH 903 The security association from the home agent to the mobile node uses 904 the current care-of address as the destination. As discussed 905 earlier, this address is updated in the SAD as the mobile node moves. 906 It can be initialized to the home address before the mobile node has 907 registered. 909 5.2.3 Prefix Discovery 911 In the following we describe some additional SPD and SAD entries to 912 protect prefix discovery. Note that the SPDs described above protect 913 all ICMPv6 traffic between the mobile node and the home agent, as 914 IPsec may not have the ability to distinguish between different 915 ICMPv6 types. 917 mobile node SPD OUT: 918 - IF source = home_address_1 & destination = home_agent_1 & 919 proto = ICMPv6 920 THEN USE SA SA5. 922 mobile node SPD IN: 923 - IF source = home_agent_1 & destination = home_address_1 & 924 proto = ICMPv6 925 THEN USE SA SA6 927 mobile node SAD: 928 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 929 source = home_address_1 & destination = home_agent_1 & 930 proto = ICMPv6 931 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 932 source = home_agent_1 & destination = home_address_1 & 933 proto = ICMPv6 935 home agent SPD OUT: 936 - IF source = home_agent_1 & destination = home_address_1 & 937 proto = ICMPv6 938 THEN USE SA SA6 940 home agent SPD IN: 941 - IF source = home_address_1 & destination = home_agent_1 & 942 proto = ICMPv6 943 THEN USE SA SA5 945 home agent SAD: 946 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 947 source = home_agent_1 & destination = home_address_1 & 948 proto = ICMPv6 949 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 950 source = home_address_1 & destination = home_agent_1 & 951 proto = ICMPv6 953 5.2.4 Payload Packets 955 It is also possible to perform some additional, optional, protection 956 of tunneled payload packets. This protection takes place in a 957 similar manner to the return routability protection above, but 958 requires a different value for the protocol field. The necessary SPD 959 and SAD entries are shown below. It is assumed that the entries for 960 protecting Binding Updates and Acknowledgements, and the entries to 961 protect Home Test Init and Home Test messages take precedence over 962 these entries. 964 mobile node SPD OUT: 965 - IF interface = IPv6 tunnel to home_agent_1 & 966 source = home_address_1 & destination = any & 967 proto = X 968 THEN USE SA SA7 970 mobile node SPD IN: 971 - IF interface = IPv6 tunnel from home_agent_1 & 972 source = any & destination = home_address_1 & 973 proto = X 974 THEN USE SA SA8 976 mobile node SAD: 977 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 978 source = home_address_1 & destination = any & proto = X 979 - SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL): 980 source = any & destination = home_address_1 & proto = X 982 home agent SPD OUT: 983 - IF interface = IPv6 tunnel to home_address_1 & 984 source = any & destination = home_address_1 & 985 proto = X 986 THEN USE SA SA8 988 home agent SPD IN: 989 - IF interface = IPv6 tunnel from home_address_1 & 990 source = home_address_1 & destination = any & 991 proto = X 992 THEN USE SA SA7 994 home agent SAD: 995 - SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL): 996 source = any & destination = home_address_1 & proto = X 997 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 998 source = home_address_1 & destination = any & proto = X 1000 If multicast group membership control protocols such as MLDv1 [9] or 1001 MLDv2 [12] need to be protected, these packets may use a link-local 1002 address rather than the home address of the mobile node. In this 1003 case the source and destination can be left as a wildcard and the SPD 1004 entries will work solely based on the used interface and the 1005 protocol, which is ICMPv6 for both MLDv1 and MLDv2. 1007 Similar problems are encountered when stateful address 1008 autoconfiguration protocols such as DHCPv6 [10] are used. The same 1009 approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP 1010 protocol. 1012 Support for multiple layers of encapsulation (such as ESP 1013 encapsulated in ESP) is not required by RFC 2401 [2] and is also 1014 otherwise often problematic. It is therefore useful to avoid setting 1015 the protocol X in the above entries to either AH or ESP. 1017 5.3 Dynamic Keying 1019 In this section we show an example configuration that uses IKE to 1020 negotiate security associations. 1022 5.3.1 Binding Updates and Acknowledgements 1024 Here are the contents of the SPD for protecting Binding Updates and 1025 Acknowledgements: 1027 mobile node SPD OUT: 1028 - IF source = home_address_1 & destination = home_agent_1 & 1029 proto = MH 1030 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1032 mobile node SPD IN: 1033 - IF source = home_agent_1 & destination = home_address_1 & 1034 proto = MH 1035 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1037 home agent SPD OUT: 1038 - IF source = home_agent_1 & destination = home_address_1 & 1039 proto = MH 1040 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1042 home agent SPD IN: 1043 - IF source = home_address_1 & destination = home_agent_1 & 1044 proto = MH 1045 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1047 We have omitted details of the proposed transforms in the above, and 1048 all details related to the particular authentication method such as 1049 certificates beyond listing a specific identity that must be used. 1051 We require IKE version 1 to be run using the care-of addresses but 1052 still negotiate IPsec SAs that use home addresses. The extra 1053 conditions set by the home agent SPD for the peer phase 1 identity to 1054 be "user_1" must be verified by the home agent. The purpose of the 1055 condition is to ensure that the IKE phase 2 negotiation for a given 1056 user's home address can't be requested by another user. In the 1057 mobile node, we simply set our local identity to be "user_1". 1059 These checks also imply that the configuration of the home agent is 1060 user-specific: every user or home address requires a specific 1061 configuration entry. It would be possible to alleviate the 1062 configuration tasks by using certificates that have home addresses in 1063 the Subject AltName field. However, it isn't clear if all IKE 1064 implementations allow one address to be used for carrying the IKE 1065 negotiations when another address is mentioned in the used 1066 certificates. In any case, even this approach would have required 1067 user-specific tasks in the certification authority. 1069 5.3.2 Return Routability Signaling 1071 Protection for the return routability signaling can be configured in 1072 a similar manner as above. 1074 mobile node SPD OUT: 1075 - IF interface = IPv6 tunnel to home_agent_1 & 1076 source = home_address_1 & destination = any & 1077 proto = MH 1078 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1079 local phase 1 identity = user_1 1081 mobile node SPD IN: 1082 - IF interface = IPv6 tunnel from home_agent_1 & 1083 source = any & destination = home_address_1 & 1084 proto = MH 1085 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1086 local phase 1 identity = user_1 1088 home agent SPD OUT: 1089 - IF interface = IPv6 tunnel to home_address_1 & 1090 source = any & destination = home_address_1 & 1091 proto = MH 1092 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1093 peer phase 1 identity = user_1 1095 home agent SPD IN: 1096 - IF interface = IPv6 tunnel from home_address_1 & 1097 source = home_address_1 & destination = any & 1098 proto = MH 1099 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1100 peer phase 1 identity = user_1 1102 The security association from the home agent to the mobile node uses 1103 the current care-of address as the destination. As discussed 1104 earlier, this address is updated in the SAD as the mobile node moves. 1105 The SPD entries can be written using the home address (as above), if 1106 the care-of address update in the SAD is also done upon the creation 1107 of security associations. 1109 5.3.3 Prefix Discovery 1111 In the following we describe some additional SPD entries to protect 1112 prefix discovery with IKE. (Note that when actual new prefixes are 1113 discovered, there may be a need to enter new manually configured SPD 1114 entries to specify the authorization policy for the resulting new 1115 home addresses.) 1117 mobile node SPD OUT: 1118 - IF source = home_address_1 & destination = home_agent_1 & 1119 proto = ICMPv6 1120 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1122 mobile node SPD IN: 1123 - IF source = home_agent_1 & destination = home_address_1 & 1124 proto = ICMPv6 1125 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1 1127 home agent SPD OUT: 1128 - IF source = home_agent_1 & destination = home_address_1 & 1129 proto = ICMPv6 1130 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1132 home agent SPD IN: 1133 - IF source = home_address_1 & destination = home_agent_1 & 1134 proto = ICMPv6 1135 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1 1137 5.3.4 Payload Packets 1139 Protection for the payload packets happens similarly to the 1140 protection of return routability signaling. As in the manually keyed 1141 case, these SPD entries have lower priority than the above ones. 1143 mobile node SPD OUT: 1144 - IF interface = IPv6 tunnel to home_agent_1 & 1145 source = home_address_1 & destination = any & 1146 proto = X 1147 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1148 local phase 1 identity = user_1 1150 mobile node SPD IN: 1151 - IF interface = IPv6 tunnel from home_agent_1 & 1152 source = any & destination = home_address_1 & 1153 proto = X 1154 THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & 1155 local phase 1 identity = user_1 1157 home agent SPD OUT: 1158 - IF interface = IPv6 tunnel to home_address_1 & 1159 source = any & destination = home_address_1 & 1160 proto = X 1161 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1162 peer phase 1 identity = user_1 1164 home agent SPD IN: 1165 - IF interface = IPv6 tunnel from home_address_1 & 1166 source = home_address_1 & destination = any & 1167 proto = X 1168 THEN USE SA ESP TUNNEL: outer destination = home_address_1 & 1169 peer phase 1 identity = user_1 1171 6. Processing Steps within a Node 1173 6.1 Binding Update to the Home Agent 1175 Step 1. At the mobile node, Mobile IPv6 module first produces the 1176 following packet: 1178 IPv6 header (source = home address, 1179 destination = home agent) 1180 Mobility header 1181 Binding Update 1183 Step 2. This packet is matched against the IPsec SPD on the mobile 1184 node and we make a note that IPsec must be applied. 1186 Step 3. Then, we add the necessary Mobile IPv6 options but do not 1187 change the addresses yet, as described in Section 11.2.2 of the base 1188 specification [8]. This results in: 1190 IPv6 header (source = home address, 1191 destination = home agent) 1192 Destination Options header 1193 Home Address option (care-of address) 1194 Mobility header 1195 Binding Update 1197 Step 4. Finally, IPsec headers are added and the necessary 1198 authenticator values are calculated: 1200 IPv6 header (source = home address, 1201 destination = home agent) 1202 Destination Options header 1203 Home Address option (care-of address) 1204 ESP header (SPI = spi_a) 1205 Mobility header 1206 Binding Update 1208 Here spi_a is the SPI value that was either configured manually, or 1209 agreed upon in an earlier IKE negotiation. 1211 Step 5. Before sending the packet, the addresses in the IPv6 header 1212 and the Destination Options header are changed: 1214 IPv6 header (source = care-of address, 1215 destination = home agent) 1216 Destination Options header 1217 Home Address option (home address) 1218 ESP header (SPI = spi_a) 1219 Mobility header 1220 Binding Update 1222 6.2 Binding Update from the Mobile Node 1224 Step 1. The following packet is received at the home agent: 1226 IPv6 header (source = care-of address, 1227 destination = home agent) 1228 Destination Options header 1229 Home Address option (home address) 1230 ESP header (SPI = spi_a) 1231 Mobility header 1232 Binding Update 1234 Step 2. The home address option is processed first, which results in 1236 IPv6 header (source = home address, 1237 destination = home agent) 1238 Destination Options header 1239 Home Address option (care-of address) 1240 ESP header (SPI = spi_a) 1241 Mobility header 1242 Binding Update 1244 Step 3. ESP header is processed next, resulting in 1246 IPv6 header (source = home address, 1247 destination = home agent) 1248 Destination Options header 1249 Home Address option (care-of address) 1250 Mobility header 1251 Binding Update 1253 Step 4. This packet matches the policy required for this security 1254 association (source = home address, destination = home agent, proto = 1255 MH). 1257 Step 5. Mobile IPv6 processes the Binding Update. The Binding 1258 Update is delivered to the Mobile IPv6 module. 1260 Step 6. If there are any security associations in the security 1261 association database for the protection of return routability or 1262 payload packets for this mobile node, those security associations are 1263 updated with the new care-of address. 1265 6.3 Binding Acknowledgement to the Mobile Node 1267 Step 1. Mobile IPv6 produces the following packet: 1269 IPv6 header (source = home agent, 1270 destination = home address) 1271 Mobility header 1272 Binding Acknowledgement 1274 Step 2. This packet matches the IPsec policy entries, and we 1275 remember that IPsec has to be applied. 1277 Step 3. Then, we add the necessary Route Headers but do not change 1278 the addresses yet, as described in Section 9.6 of the base 1279 specification [8]. This results in: 1281 IPv6 header (source = home agent, 1282 destination = home address) 1283 Routing header (type 2) 1284 care-of address 1285 Mobility header 1286 Binding Acknowledgement 1288 Step 4. We apply IPsec: 1290 IPv6 header (source = home agent, 1291 destination = home address) 1292 Routing header (type 2) 1293 care-of address 1294 ESP header (SPI = spi_b) 1295 Mobility header 1296 Binding Acknowledgement 1298 Step 5. Finally, before sending the packet out we change the 1299 addresses in the IPv6 header and the Route header: 1301 IPv6 header (source = home agent, 1302 destination = care-of address) 1303 Routing header (type 2) 1304 home address 1305 ESP header (SPI = spi_b) 1306 Mobility header 1307 Binding Acknowledgement 1309 6.4 Binding Acknowledgement from the Home Agent 1311 Step 1. The following packet is received at the mobile node 1313 IPv6 header (source = home agent, 1314 destination = care-of address) 1315 Routing header (type 2) 1316 home address 1317 ESP header (SPI = spi_b) 1318 Mobility header 1319 Binding Acknowledgement 1321 Step 2. After the routing header is processed the packet becomes 1323 IPv6 header (source = home agent, 1324 destination = home address) 1325 Routing header (type 2) 1326 care-of address 1327 ESP header (SPI = spi_b) 1328 Mobility header 1329 Binding Acknowledgement 1331 Step 3. ESP header is processed next, resulting in: 1333 IPv6 header (source = home agent, 1334 destination = home address) 1335 Routing header (type 2) 1336 care-of address 1337 Mobility header 1338 Binding Acknowledgement 1340 Step 4. This packet matches the policy required for this security 1341 association (source = home agent, destination = home address, proto = 1342 MH). 1344 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 1345 module. 1347 6.5 Home Test Init to the Home Agent 1349 Step 1. The mobile node constructs a Home Test Init message: 1351 IPv6 header (source = home address, 1352 destination = correspondent node) 1353 Mobility header 1354 Home Test Init 1356 Step 2. Mobile IPv6 determines that this packet should go to the 1357 tunnel to the home agent. 1359 Step 3. The packet is matched against IPsec policy entries for the 1360 interface, and we find that IPsec needs to be applied. 1362 Step 4. IPsec tunnel mode headers are added. Note that we use a 1363 care-of address as a source address for the tunnel packet. 1365 IPv6 header (source = care-of address, 1366 destination = home agent) 1367 ESP header (SPI = spi_c) 1368 IPv6 header (source = home address, 1369 destination = correspondent node) 1370 Mobility header 1371 Home Test Init 1373 Step 5. The packet is sent directly to the home agent using IPsec 1374 encapsulation. 1376 6.6 Home Test Init from the Mobile Node 1378 Step 1. The home agent receives the following packet: 1380 IPv6 header (source = care-of address, 1381 destination = home agent) 1382 ESP header (SPI = spi_c) 1383 IPv6 header (source = home address, 1384 destination = correspondent node) 1385 Mobility Header 1386 Home Test Init 1388 Step 2. IPsec processing is performed, resulting in: 1390 IPv6 header (source = home address, 1391 destination = correspondent node) 1392 Mobility Header 1393 Home Test Init 1395 Step 3. The resulting packet matches the policy required for this 1396 security association and the packet can be processed further. 1398 Step 4. The packet is then forwarded to the correspondent node. 1400 6.7 Home Test to the Mobile Node 1402 Step 1. The home agent receives a Home Test packet from the 1403 correspondent node: 1405 IPv6 header (source = correspondent node, 1406 destination = home address) 1407 Mobility Header 1408 Home Test Init 1410 Step 2. The home agent determines that this packet is destined to a 1411 mobile node that is away from home, and decides to tunnel it. 1413 Step 3. The packet matches the IPsec policy entries for the tunnel 1414 interface, and we note that IPsec needs to be applied. 1416 Step 4. IPsec is applied, resulting in a new packet. Note that the 1417 home agent must keep track of the location of the mobile node, and 1418 update the tunnel endpoint address in the security association(s) 1419 accordingly. 1421 IPv6 header (source = home agent, 1422 destination = care-of address) 1423 ESP header (SPI = spi_d) 1424 IPv6 header (source = correspondent node, 1425 destination = home address) 1426 Mobility Header 1427 Home Test Init 1429 Step 5. The packet is sent directly to the care-of address using 1430 IPsec encapsulation. 1432 6.8 Home Test from the Home Agent 1434 Step 1. The mobile node receives the following packet: 1436 IPv6 header (source = home agent, 1437 destination = care-of address) 1438 ESP header (SPI = spi_d) 1439 IPv6 header (source = correspondent node, 1440 destination = home address) 1441 Mobility Header 1442 Home Test Init 1444 Step 2. IPsec is processed, resulting in: 1446 IPv6 header (source = correspondent node, 1447 destination = home address) 1448 Mobility Header 1449 Home Test Init 1451 Step 3. This matches the policy required for this security 1452 association (source = any, destination = home address). 1454 Step 4. The packet is given to Mobile IPv6 processing. 1456 6.9 Prefix Solicitation Message to the Home Agent 1458 This procedure is similar to the one presented in Section 6.1. 1460 6.10 Prefix Solicitation Message from the Mobile Node 1462 This procedure is similar to the one presented in Section 6.2. 1464 6.11 Prefix Advertisement Message to the Mobile Node 1466 This procedure is similar to the one presented in Section 6.3. 1468 6.12 Prefix Advertisement Message from the Home Agent 1470 This procedure is similar to the one presented in Section 6.4. 1472 6.13 Payload Packet to the Home Agent 1474 This procedure is similar to the one presented in Section 6.5. 1476 6.14 Payload Packet from the Mobile Node 1478 This procedure is similar to the one presented in Section 6.6. 1480 6.15 Payload Packet to the Mobile Node 1482 This procedure is similar to the one presented in Section 6.7. 1484 6.16 Payload Packet from the Home Agent 1486 This procedure is similar to the one presented in Section 6.8. 1488 6.17 Establishing New Security Associations 1490 Step 1. The mobile node wishes to send a Binding Update to the home 1491 agent. 1493 IPv6 header (source = home address, 1494 destination = home agent) 1495 Mobility header 1496 Binding Update 1498 Step 2. There is no existing security association to protect the 1499 Binding Update, so the mobile node initiates IKE. The IKE packets 1500 are sent as shown in the following examples. The first packet is an 1501 example of an IKE packet sent from the mobile node, and the second 1502 one is from the home agent. The examples shows also that the phase 1 1503 identity used for the mobile node is a FQDN. 1505 IPv6 header (source = care-of address, 1506 destination = home agent) 1507 UDP 1508 IKE 1509 ... IDii = ID_FQDN mn123.ha.net ... 1511 IPv6 header (source = home agent 1512 destination = care-of address) 1513 UDP 1514 IKE 1515 ... IDir = ID_FQDN ha.net ... 1517 Step 3. IKE phase 1 completes, and phase 2 is initiated to request 1518 security associations for protecting traffic between the mobile 1519 node's home address and the home agent. These addresses will be used 1520 as selectors. This involves sending and receiving additional IKE 1521 packets. The below example shows again one packet sent by the mobile 1522 node and another sent by the home agent. The example shows also that 1523 the phase 2 identity used for the mobile node is the mobile node's 1524 home address. 1526 IPv6 header (source = care-of address, 1527 destination = home agent) 1528 UDP 1529 IKE 1530 ... IDci = ID_IPV6_ADDR home address ... 1532 IPv6 header (source = home agent, 1533 destination = care-of address) 1534 UDP 1535 IKE 1536 ... IDcr = ID_IPV6_ADDR home agent ... 1538 Step 4. The remaining steps are as shown in Section 6.1. 1540 6.18 Rekeying Security Associations 1542 Step 1. The mobile node and the home agent have existing security 1543 associations. Either side may decide at any time that the security 1544 associations need to be rekeyed, for instance, because the specified 1545 lifetime is approaching. 1547 Step 2. Mobility header packets sent during rekey may be protected 1548 by the existing security associations. 1550 Step 3. When the rekeying is finished, new security associations are 1551 established. In practice there is a time interval during which an 1552 old, about-to-expire security association and newly established 1553 security association will both exist. The new ones should be used as 1554 soon as they become available. 1556 Step 4. A notification of the deletion of the old security 1557 associations is received. After this, only the new security 1558 associations can be used. 1560 Note that there is no requirement that the existence of the IPsec and 1561 IKE security associations is tied to the existence of bindings. It 1562 is not necessary to delete a security association if a binding is 1563 removed, as a new binding may soon be established after this. 1565 Since cryptographic acceleration hardware may only be able to handle 1566 a limited number of active security associations, security 1567 associations may be deleted via IKE in order to keep the number of 1568 active cryptographic contexts to a minimum. Such deletions should 1569 not be interpreted as a sign of losing a contact to the peer or as a 1570 reason to remove a binding. Rather, if additional traffic needs to 1571 be sent, it is preferable to bring up another security association to 1572 protect it. 1574 6.19 Movements and Dynamic Keying 1576 In this section we describe the sequence of events that relate to 1577 movement with IKE-based security associations. In the initial state, 1578 the mobile node is not registered in any location and has no security 1579 associations with the home agent. Depending on whether the peers 1580 will be able to move IKE endpoints to new care-of addresses, the 1581 actions taken in Step 9 and 10 are different. 1583 Step 1. Mobile node with the home address A moves to care-of address 1584 B. 1586 Step 2. Mobile node runs IKE from care-of address B to the home 1587 agent, establishing a phase 1. The home agent can only act as the 1588 responder before it knows the current location of the mobile node. 1590 Step 3. Protected by this phase 1, mobile node establishes a pair of 1591 security associations for protecting Mobility Header traffic to and 1592 from the home address A. 1594 Step 4. Mobile node sends a Binding Update and receives a Binding 1595 Acknowledgement using the security associations created in Step 3. 1597 Step 5. Mobile node establishes a pair of security associations for 1598 protecting return routability packets. These security associations 1599 are in tunnel mode and their endpoint in the mobile node side is 1600 care-of address B. For the purposes of our example, this step uses 1601 the phase 1 connection established in Step 2. Multiple phase 1 1602 connections are also possible. 1604 Step 6. The mobile node uses the security associations created in 1605 Step 5 to run return routability. 1607 Step 7. The mobile node moves to a new location and adopts a new 1608 care-of address C. 1610 Step 8. Mobile node sends a Binding Update and receives a Binding 1611 Acknowledgement using the security associations created in Step 3. 1612 The home agent ensures that the next packets sent using the security 1613 associations created in Step 5 will have the new care-of address as 1614 their destination address, as if the outer header destination address 1615 in the security association had changed. 1617 Step 9. If the mobile node and the HA have the capability to change 1618 the IKE endpoints, they change the address to C. If they dont have 1619 the capability, both nodes remove their phase 1 connections created 1620 on top of the care-of address B and will establish a new IKE phase 1 1621 on top of the care-of address C. This capability to change the IKE 1622 phase 1 end points is indicated through setting the Key Management 1623 Mobility Capability (K) flag [8] in the Binding Update and Binding 1624 Acknowledgement messages. 1626 Step 10. If a new IKE phase 1 connection was setup after movement, 1627 the MN will not be able to receive any notifications delivered on top 1628 of the old IKE phase 1 security association. Notifications delivered 1629 on top of the new security association are received and processed 1630 normally. If the mobile node and HA were able to update the IKE 1631 endpoints, they can continue using the same IKE phase 1 connection. 1633 7. Implementation Considerations 1635 7.1 IPsec 1637 Note that packet formats and header ordering discussed in Section 3 1638 must be supported, but implementations may also support other 1639 formats. In general, the use of formats not required here may lead 1640 to incorrect processing of the packets by the peer (such as silently 1641 discarding them), unless support for these formats has been verified 1642 off-line. Such verification can take place at the same time the 1643 parameters of the security associations are agreed upon. In some 1644 cases, however, basic IPv6 specifications call for support of options 1645 not discussed here. In these cases such verification step might be 1646 unnecessary as long as the peer fully supports the relevant IPv6 1647 specifications. However, no claims are made in this document about 1648 the validity of these other formats in the context of Mobile IPv6. 1649 It is also likely that systems that support Mobile IPv6 have been 1650 tested more extensively with the required formats. 1652 We have chosen to require an encapsulation format for return 1653 routability and payload packet protection which can only be realized 1654 if the destination of the IPsec packets sent from the home agent can 1655 be changed as the mobile node moves. One of the main reasons for 1656 choosing such a format is that it removes the overhead of twenty four 1657 bytes when a home address option or routing header is added to the 1658 tunneled packet. Such an overhead would not be significant for the 1659 protection of the return routability packets, but would create an 1660 additional overhead if IPsec is used to protect the tunneling of 1661 payload packets to the home agent. This overhead may be significant 1662 for real-time traffic. Given that the use of the shorter packet 1663 formats for any traffic requires the existence of suitable APIs, we 1664 have chosen to require support for the shorter packet formats both 1665 for payload and return routability packets. 1667 In order to support the care-of address as the destination address on 1668 the mobile node side, the home agent must act as if the outer header 1669 destination address in the security association to the mobile node 1670 would have changed upon movements. Implementations are free to 1671 choose any particular method to make this change, such as using an 1672 API to the IPsec implementation to change the parameters of the 1673 security association, removing the security association and 1674 installing a new one, or modification of the packet after it has gone 1675 through IPsec processing. The only requirement is that after 1676 registering a new binding at the home agent, the next IPsec packets 1677 sent on this security association will be addressed to the new 1678 care-of address. 1680 We have chosen to require policy entries that are specific to a 1681 tunnel interface. This means that implementations have to regard the 1682 Home Agent - Mobile Node tunnel as a separate interface on which 1683 IPsec SPDs can be based. A further complication of the IPsec 1684 processing on a tunnel interface is that this requires access to the 1685 BITS implementation before the packet actually goes out. 1687 7.2 IKE 1689 We have chosen to require that a dynamic key management protocol must 1690 be able to make an authorization decision for IPsec security 1691 association creation with different addresses than with what the key 1692 management protocol is run. We expect this to be done typically by 1693 configuring the allowed combinations of phase 1 user identities and 1694 home addresses. 1696 When certificate authentication is used, IKE fragmentation can be 1697 encountered. This can occur when certificate chains are used, or 1698 even with single certificates if they are large. Many firewalls do 1699 not handle fragments properly, and may drop them. Routers in the 1700 path may also discard fragments after the initial one, since they 1701 typically will not contain full IP headers that can be compared 1702 against an access list. Where fragmentation occurs, the endpoints 1703 will not always be able to establish a security association. 1705 Fortunately, typical Mobile IPv6 deployment uses short certificate 1706 chains, as the mobile node is communicating directly with its home 1707 network. Where the problem appears, it may be difficult (at least 1708 away from home) to replace the firewalls or routers with equipment 1709 that can properly support fragments. It may help to store the peer 1710 certificates locally, or to obtain them through other means. 1712 7.3 Bump-in-the-Stack 1714 Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack 1715 (BITS) implementation model of IPsec. As Mobile IPv6 specific 1716 modifications of the packets are required before or after IPsec 1717 processing, the BITS implementation has to perform also some tasks 1718 related to mobility. This may increase the complexity of the 1719 implementation, even if it already performs some tasks of the IP 1720 layer (such as fragmentation). 1722 Specifically, Bump-in-the-Stack implementations may have to deal with 1723 the following issues: 1725 o Processing the Home Address destination option and Routing header 1726 type 2 to a form suitable for IPsec processing to take place. 1727 This is needed, among other things, for the security association 1728 and policy lookups. While relatively straightforward, the 1729 required processing may have a hardware effect in BITS 1730 implementations, if they use hardware support beyond the 1731 cryptographic operations. 1733 o Detecting packets sent between the mobile node and its home agent 1734 using IPv6 encapsulation. 1736 o Offering the necessary APIs for updating the IPsec and IKE 1737 security association endpoints. 1739 8. IANA Considerations 1741 No IANA actions are necessary based on this document. IANA actions 1742 for the Mobile IPv6 protocol itself have been covered in [8]. 1744 9. Security Considerations 1746 The Mobile IPv6 base specification [8] requires strong security 1747 between the mobile node and the home agent. This memo discusses how 1748 that security can be arranged in practice, using IPsec. The security 1749 considerations related to this are documented in the base 1750 specification, including a discussion of the implications of using 1751 either manual or dynamic keying. 1753 Normative References 1755 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1756 Levels", BCP 14, RFC 2119, March 1997. 1758 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1759 Internet Protocol", RFC 2401, November 1998. 1761 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1762 November 1998. 1764 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1765 (ESP)", RFC 2406, November 1998. 1767 [5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1768 RFC 2409, November 1998. 1770 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1771 Specification", RFC 2460, December 1998. 1773 [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1774 Specification", RFC 2473, December 1998. 1776 [8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1777 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 1778 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] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1795 (MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress), 1796 December 2002. 1798 Authors' Addresses 1800 Jari Arkko 1801 Ericsson 1802 Jorvas 02420 1803 Finland 1805 EMail: jari.arkko@ericsson.com 1807 Vijay Devarapalli 1808 Nokia Research Center 1809 313 Fairchild Drive 1810 Mountain View CA 94043 1811 USA 1813 EMail: vijayd@iprg.nokia.com 1815 Francis Dupont 1816 ENST Bretagne 1817 Campus de Rennes 2, rue de la Chataigneraie 1818 BP 78 1819 Cesson-Sevigne Cedex 35512 1820 France 1822 EMail: Francis.Dupont@enst-bretagne.fr 1824 Appendix A. Acknowledgements 1826 The authors would like to thank Greg O'Shea, Michael Thomas, Kevin 1827 Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel 1828 Montenegro, Steven Kent, and Santeri Paavolainen for interesting 1829 discussions in this problem space. 1831 Appendix B. Changes from Previous Version 1833 The following changes have been made to this document from version 1834 05: 1836 o It has been clarified that, as required by the base specification, 1837 the Home Address destination option and type 2 Routing header 1838 affect policy checks only with respect to the nodes that are the 1839 original senders or final receivers of the packet (tracked issue 1840 319). 1842 o Text regarding other protocols than IKEv1 has been aligned with 1843 the text in the base specification, which does not claim treatment 1844 of the issues beyond IKEv1 (tracked issue 319). 1846 o This document no longer references draft-touch-ipsec-vpn (tracked 1847 issue 312). 1849 o The replay protection requirements of this document have been 1850 clarified (tracked issue 311). 1852 Intellectual Property Statement 1854 The IETF takes no position regarding the validity or scope of any 1855 intellectual property or other rights that might be claimed to 1856 pertain to the implementation or use of the technology described in 1857 this document or the extent to which any license under such rights 1858 might or might not be available; neither does it represent that it 1859 has made any effort to identify any such rights. Information on the 1860 IETF's procedures with respect to rights in standards-track and 1861 standards-related documentation can be found in BCP-11. Copies of 1862 claims of rights made available for publication and any assurances of 1863 licenses to be made available, or the result of an attempt made to 1864 obtain a general license or permission for the use of such 1865 proprietary rights by implementors or users of this specification can 1866 be obtained from the IETF Secretariat. 1868 The IETF invites any interested party to bring to its attention any 1869 copyrights, patents or patent applications, or other proprietary 1870 rights which may cover technology that may be required to practice 1871 this standard. Please address the information to the IETF Executive 1872 Director. 1874 Full Copyright Statement 1876 Copyright (C) The Internet Society (2003). All Rights Reserved. 1878 This document and translations of it may be copied and furnished to 1879 others, and derivative works that comment on or otherwise explain it 1880 or assist in its implementation may be prepared, copied, published 1881 and distributed, in whole or in part, without restriction of any 1882 kind, provided that the above copyright notice and this paragraph are 1883 included on all such copies and derivative works. However, this 1884 document itself may not be modified in any way, such as by removing 1885 the copyright notice or references to the Internet Society or other 1886 Internet organizations, except as needed for the purpose of 1887 developing Internet standards in which case the procedures for 1888 copyrights defined in the Internet Standards process must be 1889 followed, or as required to translate it into languages other than 1890 English. 1892 The limited permissions granted above are perpetual and will not be 1893 revoked by the Internet Society or its successors or assignees. 1895 This document and the information contained herein is provided on an 1896 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1897 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1898 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1899 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1900 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1902 Acknowledgement 1904 Funding for the RFC Editor function is currently provided by the 1905 Internet Society.