idnits 2.17.1 draft-ietf-hip-mm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1642. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 (July 17, 2005) is 6855 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: '8' is defined on line 1508, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1511, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '3') ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. '5') ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) == Outdated reference: A later version (-03) exists of draft-iab-sec-cons-00 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Henderson (editor) 3 Internet-Draft The Boeing Company 4 Expires: January 18, 2006 July 17, 2005 6 End-Host Mobility and Multihoming with the Host Identity Protocol 7 draft-ietf-hip-mm-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document defines mobility and multihoming extensions to the Host 41 Identity Protocol (HIP). Specifically, this document defines a 42 general "LOCATOR" parameter for HIP messages that allows for a HIP 43 host to notify peers about alternate addresses at which it may be 44 reached. This document also defines elements of procedure for 45 mobility of a HIP host-- the process by which a host dynamically 46 changes the primary locator that it uses to receive packets. While 47 the same LOCATOR parameter can also be used to support end-host 48 multihoming, detailed procedures are left for further study. 50 Table of Contents 52 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 54 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1 Operating Environment . . . . . . . . . . . . . . . . . . 6 56 3.1.1 Locator . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1.3 Multihoming . . . . . . . . . . . . . . . . . . . . . 7 59 3.2 Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 60 3.2.1 Mobility with single SA pair . . . . . . . . . . . . . 8 61 3.2.2 Host multihoming . . . . . . . . . . . . . . . . . . . 10 62 3.2.3 Site multihoming . . . . . . . . . . . . . . . . . . . 12 63 3.2.4 Dual host multihoming . . . . . . . . . . . . . . . . 12 64 3.2.5 Combined mobility and multihoming . . . . . . . . . . 13 65 3.2.6 Using LOCATORs across addressing realms . . . . . . . 13 66 3.2.7 Network renumbering . . . . . . . . . . . . . . . . . 13 67 3.2.8 Initiating the protocol in R1 or I2 . . . . . . . . . 13 68 3.3 Other Considerations . . . . . . . . . . . . . . . . . . . 15 69 3.3.1 Address Verification . . . . . . . . . . . . . . . . . 15 70 3.3.2 Credit-Based Authorization . . . . . . . . . . . . . . 15 71 3.3.3 Preferred locator . . . . . . . . . . . . . . . . . . 16 72 3.3.4 Interaction with Security Associations . . . . . . . . 17 73 4. LOCATOR parameter format . . . . . . . . . . . . . . . . . . . 20 74 4.1 Traffic Type and Preferred Locator . . . . . . . . . . . . 21 75 4.2 Locator Type and Locator . . . . . . . . . . . . . . . . . 22 76 4.3 UPDATE packet with included LOCATOR . . . . . . . . . . . 22 77 5. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 23 78 5.1 Locator data structure and status . . . . . . . . . . . . 23 79 5.2 Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 24 80 5.3 Handling received LOCATORs . . . . . . . . . . . . . . . . 25 81 5.4 Verifying address reachability . . . . . . . . . . . . . . 26 82 5.5 Credit-Based Authorization . . . . . . . . . . . . . . . . 28 83 5.5.1 Handling Payload Packets . . . . . . . . . . . . . . . 28 84 5.5.2 Credit Aging . . . . . . . . . . . . . . . . . . . . . 29 85 5.6 Changing the preferred locator . . . . . . . . . . . . . . 30 86 6. Policy considerations . . . . . . . . . . . . . . . . . . . . 32 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 88 7.1 Impersonation attacks . . . . . . . . . . . . . . . . . . 33 89 7.2 Denial of Service attacks . . . . . . . . . . . . . . . . 34 90 7.2.1 Flooding Attacks . . . . . . . . . . . . . . . . . . . 34 91 7.2.2 Memory/Computational exhaustion DoS attacks . . . . . 35 92 7.3 Mixed deployment environment . . . . . . . . . . . . . . . 35 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 94 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 97 11.1 Normative references . . . . . . . . . . . . . . . . . . . 40 98 11.2 Informative references . . . . . . . . . . . . . . . . . . 40 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41 100 A. Changes from previous versions . . . . . . . . . . . . . . . . 42 101 A.1 From nikander-hip-mm-00 to nikander-hip-mm-01 . . . . . . 42 102 A.2 From nikander-hip-mm-01 to nikander-hip-mm-02 . . . . . . 42 103 A.3 From -02 to draft-ietf-hip-mm-00 . . . . . . . . . . . . . 42 104 A.4 From draft-ietf-hip-mm-00 to -01 . . . . . . . . . . . . . 43 105 A.5 From draft-ietf-hip-mm-01 to -02 . . . . . . . . . . . . . 43 106 Intellectual Property and Copyright Statements . . . . . . . . 44 108 1. Introduction and Scope 110 The Host Identity Protocol [1] (HIP) supports an architecture that 111 decouples the transport layer (TCP, UDP, etc.) from the 112 internetworking layer (IPv4 and IPv6) by using public/private key 113 pairs, instead of IP addresses, as host identities. When a host uses 114 HIP, the overlying protocol sublayers (e.g., transport layer sockets 115 and ESP Security Associations) are instead bound to representations 116 of these host identities, and the IP addresses are only used for 117 packet forwarding. However, each host must also know at least one IP 118 address at which its peers are reachable. Initially, these IP 119 addresses are the ones used during the HIP base exchange [2]. 121 This document defines a generalized LOCATOR parameter for use in HIP 122 messages. The LOCATOR parameter allows a HIP host to notify a peer 123 about alternate addresses at which it is reachable. The LOCATORs may 124 be merely IP addresses, or they may have additional multiplexing and 125 demultiplexing context to aid the packet handling in the lower 126 layers. For instance, an IP address may need to be paired with an 127 ESP SPI so that packets are sent on the correct SA for a given 128 address. 130 This document also specifies the messaging and elements of procedure 131 for end-host mobility of a HIP host-- the sequential change in 132 preferred IP address used to reach a host. In particular, message 133 flows to enable successful host mobility, including address 134 verification methods, are defined herein. However, while the same 135 LOCATOR parameter is intended to support host multihoming (parallel 136 support of a number of addresses), and experimentation is encouraged, 137 detailed elements of procedure for host multihoming are left for 138 further study. 140 There are a number of situations where the simple end-to-end 141 readdressing functionality is not sufficient. These include the 142 initial reachability of a mobile host, location privacy, end-host and 143 site multihoming with legacy hosts, simultaneous mobility of both 144 hosts, and NAT traversal. In these situations there is a need for 145 some helper functionality in the network, such as a HIP Rendezvous 146 server [3]. Such functionality is out of scope of this document. 147 Finally, making underlying IP mobility transparent to the transport 148 layer has implications on the proper response of transport congestion 149 control, path MTU selection, and QoS. Transport-layer mobility 150 triggers, and the proper transport response to a HIP mobility or 151 multihoming address change, are outside the scope of this document. 153 2. Terminology and Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC2119 [6]. 159 Locator. A name that controls how the packet is routed through the 160 network and demultiplexed by the end host. It may include a 161 concatenation of traditional network addresses such as an IPv6 162 address and end-to-end identifiers such as an ESP SPI. It may 163 also include transport port numbers or IPv6 Flow Labels as 164 demultiplexing context, or it may simply be a network address. 166 Address. A name that denotes a point-of-attachment to the network. 167 The two most common examples are an IPv4 address and an IPv6 168 address. The set of possible addresses is a subset of the set of 169 possible locators. 171 Preferred locator. A locator on which a host prefers to receive data. 172 With respect to a given peer, a host always has one active 173 preferred locator, unless there are no active locators. By 174 default, the locators used in the HIP base exchange are the 175 preferred locators. 177 Credit Based Authorization. A host must must verify a mobile or 178 multi-homed peer's reachability at a new locator. Credit-Based 179 Authorization authorizes the peer to receive a certain amount of 180 data at the new locator before the result of such verification is 181 known. 183 3. Protocol Model 185 3.1 Operating Environment 187 The Host Identity Protocol (HIP) [2] is a key establishment and 188 parameter negotiation protocol. Its primary applications are for 189 authenticating host messages based on host identities, and 190 establishing security associations (SAs) for ESP transport format [5] 191 and possibly other protocols in the future. 193 +--------------------+ +--------------------+ 194 | | | | 195 | +------------+ | | +------------+ | 196 | | Key | | HIP | | Key | | 197 | | Management | <-+-----------------------+-> | Management | | 198 | | Process | | | | Process | | 199 | +------------+ | | +------------+ | 200 | ^ | | ^ | 201 | | | | | | 202 | v | | v | 203 | +------------+ | | +------------+ | 204 | | IPsec | | ESP | | IPsec | | 205 | | Stack | <-+-----------------------+-> | Stack | | 206 | | | | | | | | 207 | +------------+ | | +------------+ | 208 | | | | 209 | | | | 210 | Initiator | | Responder | 211 +--------------------+ +--------------------+ 213 Figure 1: HIP deployment model 215 The general deployment model for HIP is shown above, assuming 216 operation in an end-to-end fashion. This document specifies 217 extensions to the HIP protocol to enable end-host mobility and 218 multihoming. In a nutshell, the HIP protocol can carry new 219 addressing information to the peer and can enable direct 220 authentication of the message via a signature based on its host 221 identity. This document specifies the format of this new addressing 222 (LOCATOR) parameter, the procedures for sending and processing this 223 parameter to enable basic host mobility, and procedures for a 224 concurrent address verification mechanism. 226 3.1.1 Locator 228 This document defines a generalization of an address called a 229 "locator". A locator specifies a point-of-attachment to the network 230 but may also include additional end-to-end tunneling or per-host 231 demultiplexing context that affects how packets are handled below the 232 logical HIP sublayer of the stack. This generalization is useful 233 because IP addresses alone may not be sufficient to describe how 234 packets should be handled below HIP. For example, in a host 235 multihoming context, certain IP addresses may need to be associated 236 with certain ESP SPIs, to avoid violation of the ESP anti-replay 237 window [4]. Addresses may also be affiliated with transport ports in 238 certain tunneling scenarios. Or locators may merely be traditional 239 network addresses. 241 3.1.2 Mobility 243 When a host moves to another address, it notifies its peer of the new 244 address by sending a HIP UPDATE packet containing a LOCATOR 245 parameter. This UPDATE packet is acknowledged by the peer, and is 246 protected by retransmission. The peer can authenticate the contents 247 of the UPDATE packet based on the signature and keyed hash of the 248 packet. The host may at the same time decide to rekey its security 249 association and possibly generate a new Diffie-Hellman key; all of 250 these actions are triggered by including additional parameters in the 251 UPDATE packet, as defined in the base protocol specification [2]. 253 When using ESP Transport Format [5], the host is able to receive 254 packets that are protected using a HIP created ESP SA from any 255 address. Thus, a host can change its IP address and continue to send 256 packets to its peers. However, the peers are not able to reply 257 before they can reliably and securely update the set of addresses 258 that they associate with the sending host. Furthermore, mobility may 259 change the path characteristics in such a manner that reordering 260 occurs and packets fall outside the ESP anti-replay window. 262 3.1.3 Multihoming 264 A related operational configuration is host multihoming, in which a 265 host has multiple locators simultaneously rather than sequentially as 266 in the case of mobility. By using the locator parameter defined 267 herein, a host can inform its peers of additional (multiple) locators 268 at which it can be reached, and can declare a particular locator as a 269 "preferred" locator. Although this document defines a mechanism for 270 multihoming, it does not define associated policies and procedure 271 details such as which locators to choose when more than one pair is 272 available, the operation of simultaneous mobility and multihoming, 273 and the implications of multihoming on transport protocols and ESP 274 anti-replay windows. Additional definition of HIP-based multihoming 275 is expected to be part of a future document. 277 3.2 Protocol Overview 279 In this section we briefly introduce a number of usage scenarios 280 where the HIP mobility and multihoming facility is useful. These 281 scenarios assume that HIP is being used with the ESP Transform, 282 although other scenarios may be defined in the future. To understand 283 these usage scenarios, the reader should be at least minimally 284 familiar with the HIP protocol specification [2]. However, for the 285 (relatively) uninitiated reader it is most important to keep in mind 286 that in HIP the actual payload traffic is protected with ESP, and 287 that the ESP SPI acts as an index to the right host-to-host context. 289 Each of the scenarios below assumes that the HIP base exchange has 290 completed, and the hosts each have a single outbound SA to the peer 291 host. Associated with this outbound SA is a single destination 292 address of the peer host-- the source address used by the peer during 293 the base exchange. 295 The readdressing protocol is an asymmetric protocol where one host, 296 called the mobile host, informs another host, called the peer host, 297 about changes of IP addresses on affected SPIs. The readdressing 298 exchange is designed to be piggybacked on existing HIP exchanges. 299 The main packets on which the LOCATOR parameters are expected to be 300 carried are UPDATE packets. However, some implementations may want 301 to experiment with sending LOCATOR parameters also on other packets, 302 such as R1, I2, and NOTIFY. 304 3.2.1 Mobility with single SA pair 306 A mobile host must sometimes change an IP address bound to an 307 interface. The change of an IP address might be needed due to a 308 change in the advertised IPv6 prefixes on the link, a reconnected PPP 309 link, a new DHCP lease, or an actual movement to another subnet. In 310 order to maintain its communication context, the host must inform its 311 peers about the new IP address. This first example considers the 312 case in which the mobile host has only one interface, IP address, and 313 a single pair of SAs (one inbound, one outbound). 315 1. The mobile host is disconnected from the peer host for a brief 316 period of time while it switches from one IP address to another. 317 Upon obtaining a new IP address, the mobile host sends a LOCATOR 318 parameter to the peer host in an UPDATE message. The LOCATOR 319 indicates the new IP address and the SPI associated with the new 320 IP address by using a Locator Type of "1", the locator lifetime, 321 and whether the new locator is a preferred locator. The mobile 322 host may optionally send an ESP_INFO to create a new inbound SA, 323 in which case it transitions to state REKEYING. In this case, 324 the Locator contains the new SPI to use. Otherwise, the existing 325 SPI is identified in the Locator parameter, and the host waits 326 for its UPDATE to be acknowledged. 328 2. Depending on whether the mobile host initiated a rekey, and on 329 whether the peer host itself wants to rekey, a number of 330 responses are possible. Figure 2 illustrates an exchange for 331 which neither side initiates a rekeying, but for which the peer 332 host performs an address check. If the mobile host is rekeying, 333 the peer will also rekey, as shown in Figure 3. If the mobile 334 host did not decide to rekey but the peer desires to do so, then 335 it initiates a rekey as illustrated in Figure 4. The UPDATE 336 messages sent from the peer back to the mobile are sent to the 337 newly advertised address. 339 3. While the peer host is verifying the new address, the address is 340 marked as UNVERIFIED in the interim. Once it has received a 341 correct reply to its UPDATE challenge, or optionally, data on the 342 new SA, it marks the new address as ACTIVE and removes the old 343 address. 345 Mobile Host Peer Host 347 UPDATE(ESP_INFO, LOC, SEQ) 348 -----------------------------------> 349 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 350 <----------------------------------- 351 UPDATE(ACK, ECHO_RESPONSE) 352 -----------------------------------> 354 Figure 2: Readdress without rekeying, but with address check 356 Mobile Host Peer Host 358 UPDATE(ESP_INFO, LOC, SEQ, [DIFFIE_HELLMAN]) 359 -----------------------------------> 360 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 361 <----------------------------------- 362 UPDATE(ACK, ECHO_RESPONSE) 363 -----------------------------------> 365 Figure 3: Readdress with mobile-initiated rekey 367 Mobile Host Peer Host 369 UPDATE(LOC, SEQ) 370 -----------------------------------> 371 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN], ECHO_REQUEST) 372 <----------------------------------- 373 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_RESPONSE) 374 -----------------------------------> 375 UPDATE(ACK) 376 <----------------------------------- 378 Figure 4: Readdress with peer-initiated rekey 380 Hosts that use link-local addresses as source addresses in their HIP 381 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 382 provide a globally routable address either in the initial handshake 383 or via the LOCATOR parameter. 385 3.2.2 Host multihoming 387 A (mobile or stationary) host may sometimes have more than one 388 interface. The host may notify the peer host of the additional 389 interface(s) by using the LOCATOR parameter. To avoid problems with 390 the ESP anti-replay window, a host SHOULD use a different SA for each 391 interface used to receive packets from the peer host. 393 When more than one locator is provided to the peer host, the host 394 SHOULD indicate which locator is preferred. By default, the 395 addresses used in the base exchange are preferred until indicated 396 otherwise. 398 Although the protocol may allow for configurations in which there is 399 an asymmetric number of SAs between the hosts (e.g., one host has two 400 interfaces and two inbound SAs, while the peer has one interface and 401 one inbound SA), it is RECOMMENDED that inbound and outbound SAs be 402 created pairwise between hosts. When an ESP_INFO arrives to rekey a 403 particular outbound SA, the corresponding inbound SA should be also 404 rekeyed at that time. Although asymmetric SA configurations might be 405 experimented with, their usage may constrain interoperability at this 406 time. However, it is recommended that implementations attempt to 407 support peers that prefer to use non-paired SAs. It is expected that 408 this section and behavior will be modified in future revisions of 409 this protocol, once the issue and its implications are better 410 understood. 412 To add both an additional interface and SA, the host sends a LOCATOR 413 with an ESP_INFO. The host uses the same (new) SPI value in the 414 LOCATOR and both the "Old SPI" and "New SPI" values in the ESP_INFO-- 415 this indicates to the peer that the SPI is not replacing an existing 416 SPI. The multihomed host transitions to state REKEYING, waiting for 417 a ESP_INFO from the peer and an ACK of its own UPDATE. As in the 418 mobility case, the peer host must perform an address check while it 419 is rekeying. Figure 5 illustrates the basic packet exchange. 421 Multi-homed Host Peer Host 423 UPDATE(ESP_INFO, LOC, SEQ, [DIFFIE_HELLMAN]) 424 -----------------------------------> 425 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 426 <----------------------------------- 427 UPDATE(ACK, ECHO_RESPONSE) 428 -----------------------------------> 430 Figure 5: Basic multihoming scenario 432 For the case in which multiple locators are advertised in a LOCATOR, 433 the peer does not need to send ACK for the UPDATE(LOCATOR) in every 434 subsequent message used for the address check procedure of the 435 multiple locators. Therefore, a sample packet exchange might look as 436 shown in Figure 6. 438 Multi-homed Host Peer Host 440 UPDATE(LOC(addr_1,addr_2), SEQ) 441 -----------------------------------> 442 UPDATE(ACK) 443 <----------------------------------- 445 sent to addr_1:UPDATE(ESP_INFO, SEQ, ECHO_REQUEST) 446 <----------------------------------- 447 UPDATE(ACK, ECHO_RESPONSE) 448 -----------------------------------> 450 sent to addr_2:UPDATE(ESP_INFO, SEQ, ECHO_REQUEST) 451 <----------------------------------- 452 UPDATE(ACK, ECHO_RESPONSE) 453 -----------------------------------> 455 Figure 6: LOCATOR with multiple addresses 457 When processing inbound LOCATORs that establish new security 458 associations, a host uses the destination address of the UPDATE 459 containing LOCATOR as the local address to which the LOC plus 460 ESP_INFO is targeted. Hosts may send LOCATOR with the same IP 461 address to different peer addresses-- this has the effect of creating 462 multiple inbound SAs implicitly affiliated with different source 463 addresses. 465 When rekeying in a multihoming situation in which there is an 466 asymmetric number of SAs between two hosts, a respondent to the 467 ESP_INFO/UPDATE procedure may have some ambiguity as to which inbound 468 SA it should update in response to the peer's UPDATE. In such a 469 case, the host SHOULD choose an SA corresponding to the inbound 470 interface on which the UPDATE was received. 472 3.2.3 Site multihoming 474 A host may have an interface that has multiple globally reachable IP 475 addresses. Such a situation may be a result of the site having 476 multiple upper Internet Service Providers, or just because the site 477 provides all hosts with both IPv4 and IPv6 addresses. It is 478 desirable that the host can stay reachable with all or any subset of 479 the currently available globally routable addresses, independent on 480 how they are provided. 482 This case is handled the same as if there were different IP 483 addresses, described above in Section 3.2.2. Note that a single 484 interface may experience site multihoming while the host itself may 485 have multiple interfaces. 487 Note that a host may be multi-homed and mobile simultaneously, and 488 that a multi-homed host may want to protect the location of some of 489 its interfaces while revealing the real IP address of some others. 491 This document does not presently specify additional site multihoming 492 extensions to HIP to further align it with the requirements of the 493 multi6 working group. 495 3.2.4 Dual host multihoming 497 Consider the case in which both hosts would like to add an additional 498 address after the base exchange completes. In Figure 7, consider 499 that host1 wants to add address addr1b. It would send a LOCATOR to 500 host2 located at addr2a, and a new set of SPIs would be added between 501 hosts 1 and 2 (call them SPI1b and SPI2b). Next, consider host2 502 deciding to add addr2b to the relationship. host2 now has a choice of 503 which of host1's addresses to initiate LOCATOR to. It may choose to 504 initiate a LOCATOR to addr1a, addr1b, or both. If it chooses to send 505 to both, then a full mesh (four SA pairs) of SAs would exist between 506 the two hosts. This is the most general case; it may be often the 507 case that hosts primarily establish new SAs only with the peer's 508 preferred locator. The readdressing protocol is flexible enough to 509 accommodate this choice. 511 -<- SPI1a -- -- SPI2a ->- 512 host1 < > addr1a <---> addr2a < > host2 513 ->- SPI2a -- -- SPI1a -<- 515 addr1b <---> addr2b 517 Figure 7: Dual multihoming case in which each host uses LOCATOR to 518 add a second address 520 3.2.5 Combined mobility and multihoming 522 It looks likely that in the future many mobile hosts will be 523 simultaneously mobile and multi-homed, i.e., have multiple mobile 524 interfaces. Furthermore, if the interfaces use different access 525 technologies, it is fairly likely that one of the interfaces may 526 appear stable (retain its current IP address) while some other(s) may 527 experience mobility (undergo IP address change). 529 The use of LOCATOR plus ESP_INFO should be flexible enough to handle 530 most such scenarios, although more complicated scenarios have not 531 been studied so far. 533 3.2.6 Using LOCATORs across addressing realms 535 It is possible for HIP associations to migrate to a state in which 536 both parties are only using locators in different addressing realms. 537 For example, the two hosts may initiate the HIP association when both 538 are using IPv6 locators, then one host may loose its IPv6 539 connectivity and obtain an IPv4 address. In such a case, some type 540 of mechanism for interworking between the different realms must be 541 employed; such techniques are outside the scope of the present text. 542 If no mechanism exists, then the UPDATE message carrying the new 543 LOCATOR will likely not be acknowledged anyway, and the HIP state may 544 time out. 546 3.2.7 Network renumbering 548 It is expected that IPv6 networks will be renumbered much more often 549 than most IPv4 networks are. From an end-host point of view, network 550 renumbering is similar to mobility. 552 3.2.8 Initiating the protocol in R1 or I2 554 A Responder host MAY include one or more LOCATOR parameters in the R1 555 packet that it sends to the Initiator. These parameters MUST be 556 protected by the R1 signature. If the R1 packet contains LOCATOR 557 parameters with a new preferred locator, the Initiator SHOULD 558 directly set the new preferred locator to status ACTIVE without 559 performing address verification first, and MUST send the I2 packet to 560 the new preferred locator. The I1 destination address and the new 561 preferred locator may be identical. All new non-preferred locators 562 must still undergo address verification. 564 Initiator Responder 566 R1 with LOCATOR 567 <----------------------------------- 568 record additional addresses 569 change responder address 570 I2 with new SPI in ESP_INFO parameter 571 -----------------------------------> 572 (process normally) 573 R2 574 <----------------------------------- 575 (process normally) 577 Figure 8: LOCATOR inclusion in R1 579 An Initiator MAY include one or more LOCATOR parameters in the I2 580 packet, independent on whether there was LOCATOR parameter(s) in the 581 R1 or not. These parameters MUST be protected by the I2 signature. 582 Even if the I2 packet contains LOCATOR parameters, the Responder MUST 583 still send the R2 packet to the source address of the I2. The new 584 preferred locator SHOULD be identical to the I2 source address. If 585 the I2 packet contains LOCATOR parameters, all new locators must 586 undergo address verification as usual. If any of these locators is a 587 new preferred locator, an efficient method to verify this is to 588 piggyback an ECHO_REQUEST parameter with some unguessable data to the 589 R2 packet. 591 Initiator Responder 593 I2 with LOCATOR 594 -----------------------------------> 595 (process normally) 596 record additional addresses 597 R2 with new SPI in ESP_INFO parameter 598 <----------------------------------- 599 (process normally) 600 data on new SA 601 ------------------------------------> 602 (process normally) 604 Figure 9: LOCATOR inclusion in I2 606 3.3 Other Considerations 608 3.3.1 Address Verification 610 When a HIP host receives a set of locators from another HIP host in a 611 LOCATOR, it does not necessarily know whether the other host is 612 actually reachable at the claimed addresses. In fact, a malicious 613 peer host may be intentionally giving bogus addresses in order to 614 cause a packet flood towards the target addresses [10]. Likewise, 615 viral software may have compromised the peer host, programming it to 616 redirect packets to the target addresses. Thus, the HIP host must 617 first check that the peer is reachable at the new address. 619 An additional potential benefit of performing address verification is 620 to allow middleboxes in the network along the new path to obtain the 621 peer host's inbound SPI. 623 Address verification is implemented by the challenger sending some 624 piece of unguessable information to the new address, and waiting for 625 some acknowledgment from the responder that indicates reception of 626 the information at the new address. This may include exchange of a 627 nonce, or generation of a new SPI and observing data arriving on the 628 new SPI. 630 3.3.2 Credit-Based Authorization 632 Credit-Based Authorization allows a host to securely use a new 633 locator even though the peer's reachability at the address embedded 634 in this locator has not yet been verified. This is accomplished 635 based on the following three hypotheses: 637 1. A flooding attacker typically seeks to somehow multiply the 638 packets it generates itself for the purpose of its attack because 639 bandwidth is an ample resource for many attractive victims. 641 2. An attacker can always cause unamplified flooding by sending 642 packets to its victim directly. 644 3. Consequently, the additional effort required to set up a 645 redirection-based flooding attack would pay off for the attacker 646 only if amplification could be obtained this way. 648 On this basis, rather than eliminating malicious packet redirection 649 in the first place, Credit-Based Authorization prevents any 650 amplification that can be reached through it. This is accomplished 651 by limiting the data a host can send to an unverified address of a 652 peer by the data recently received from that peer. Redirection-based 653 flooding attacks thus become less attractive than, e.g., pure direct 654 flooding, where the attacker itself sends bogus packets to the 655 victim. 657 Figure 10 illustrates Credit-Based Authorization: Host B measures 658 the bytes recently received from peer A and, when A readdresses, 659 sends packets to A's new, unverified address as long as the sum of 660 their sizes does not exceed the measured, received data volume. When 661 insufficient credit is left, B stops sending further packets to A 662 until A's address becomes ACTIVE. The address changes may be due to 663 mobility, due to multihoming, or due to any other reason. 665 +-------+ +-------+ 666 | A | | B | 667 +-------+ +-------+ 668 | | 669 address |------------------------->| credit += size(packet) 670 ACTIVE | | 671 |------------------------->| credit += size(packet) 672 |<-------------------------| don't change credit 673 | | 674 + address change | 675 address |<-------------------------| credit -= size(packet) 676 UNVERIFIED |------------------------->| credit += size(packet) 677 |<-------------------------| credit -= size(packet) 678 | | 679 |<-------------------------| credit -= size(packet) 680 | X credit < size(packet)=> drop! 681 | | 682 + address change | 683 address | | 684 ACTIVE |<-------------------------| don't change credit 685 | | 687 Figure 10: Readdressing Scenario 689 3.3.3 Preferred locator 691 When a host has multiple locators, the peer host must decide upon 692 which to use for outbound packets. It may be that a host would 693 prefer to receive data on a particular inbound interface. HIP allows 694 a particular locator to be designated as a preferred locator, and 695 communicated to the peer (see Section 4). 697 In general, when multiple locators are used for a session, there is 698 the question of using multiple locators for failover only or for 699 load-balancing. Due to the implications of load-balancing on the 700 transport layer that still need to be worked out, this draft assumes 701 that multiple locators are used primarily for failover. An 702 implementation may use ICMP interactions, reachability checks, or 703 other means to detect the failure of a locator. 705 3.3.4 Interaction with Security Associations 707 This document specifies a new HIP protocol parameter, the LOCATOR 708 parameter (see Section 4), that allows the hosts to exchange 709 information about their locator(s), and any changes in their 710 locator(s). The logical structure created with LOCATOR parameters 711 has three levels: hosts, Security Associations (SAs) indexed by 712 Security Parameter Indices (SPIs), and addresses. 714 The relation between these entities for an association negotiated as 715 defined in the base specification [2] and ESP transform [5] is 716 illustrated in Figure 11. 718 -<- SPI1a -- -- SPI2a ->- 719 host1 < > addr1a <---> addr2a < > host2 720 ->- SPI2a -- -- SPI1a -<- 722 Figure 11: Relation between hosts, SPIs, and addresses (base 723 specification) 725 In Figure 11, host1 and host2 negotiate two unidirectional SAs, and 726 each host selects the SPI value for its inbound SA. The addresses 727 addr1a and addr2a are the source addresses that each host uses in the 728 base HIP exchange. These are the "preferred" (and only) addresses 729 conveyed to the peer for each SA; even though packets sent to any of 730 the hosts' interfaces can arrive on an inbound SPI, when a host sends 731 packets to the peer on an outbound SPI, it knows of a single 732 destination address associated with that outbound SPI (for host1, it 733 sends a packet on SPI2a to addr2a to reach host2), unless other 734 mechanisms exist to learn of new addresses. 736 In general, the bindings that exist in an implementation 737 corresponding to this draft can be depicted as shown in Figure 12. 738 In this figure, a host can have multiple inbound SPIs (and, not 739 shown, multiple outbound SPIs) between itself and another host. 740 Furthermore, each SPI may have multiple addresses associated with it. 741 These addresses bound to an SPI are not used as SA selectors. 742 Rather, the addresses are those addresses that are provided to the 743 peer host, as hints for which addresses to use to reach the host on 744 that SPI. The LOCATOR parameter allows for IP addresses and SPIs to 745 be combined to form generalized locators. The LOCATOR parameter is 746 used to change the set of addresses that a peer associates with a 747 particular SPI. 749 address11 750 / 751 SPI1 - address12 752 / 753 / address21 754 host -- SPI2 < 755 \ address22 756 \ 757 SPI3 - address31 758 \ 759 address32 761 Figure 12: Relation between hosts, SPIs, and addresses (general case) 763 A host may establish any number of security associations (or SPIs) 764 with a peer. The main purpose of having multiple SPIs is to group 765 the addresses into collections that are likely to experience fate 766 sharing. For example, if the host needs to change its addresses on 767 SPI2, it is likely that both address21 and address22 will 768 simultaneously become obsolete. In a typical case, such SPIs may 769 correspond with physical interfaces; see below. Note, however, that 770 especially in the case of site multihoming, one of the addresses may 771 become unreachable while the other one still works. In the typical 772 case, however, this does not require the host to inform its peers 773 about the situation, since even the non-working address still 774 logically exists. 776 A basic property of HIP SAs is that the inbound IP address is not 777 used as a selector for the SA. Therefore, in Figure 12, it may seem 778 unnecessary for address31, for example, to be associated only with 779 SPI3-- in practice, a packet may arrive to SPI1 via destination 780 address address31 as well. However, the use of different source and 781 destination addresses typically leads to different paths, with 782 different latencies in the network, and if packets were to arrive via 783 an arbitrary destination IP address (or path) for a given SPI, the 784 reordering due to different latencies may cause some packets to fall 785 outside of the ESP anti-replay window. For this reason, HIP provides 786 a mechanism to affiliate destination addresses with inbound SPIs, if 787 there is a concern that anti-replay windows might be violated 788 otherwise. In this sense, we can say that a given inbound SPI has an 789 "affinity" for certain inbound IP addresses, and this affinity is 790 communicated to the peer host. Each physical interface SHOULD have a 791 separate SA, unless the ESP anti-replay window is loose. 793 Moreover, even if the destination addresses used for a particular SPI 794 are held constant, the use of different source interfaces may also 795 cause packets to fall outside of the ESP anti-replay window, since 796 the path traversed is often affected by the source address or 797 interface used. A host has no way to influence the source interface 798 on which a peer uses to send its packets on a given SPI. Hosts 799 SHOULD consistently use the same source interface when sending to a 800 particular destination IP address and SPI. For this reason, a host 801 may find it useful to change its SPI or at least reset its ESP anti- 802 replay window when the peer host readdresses. 804 An address may appear on more than one SPI. This creates no 805 ambiguity since the receiver will ignore the IP addresses as SA 806 selectors anyway. 808 A single LOCATOR parameter contains data only about one SPI. To 809 simultaneously signal changes on several SPIs, it is necessary to 810 send several LOCATOR parameters. The packet structure supports this. 812 If the LOCATOR parameter is sent in an UPDATE packet, then the 813 receiver will respond with an UPDATE acknowledgment. If the LOCATOR 814 parameter is sent in a NOTIFY, I2, or R2 packet, then the recipient 815 may consider the LOCATOR as informational, and act only when it needs 816 to activate a new address. The use of LOCATOR in a NOTIFY message 817 may not be compatible with middleboxes. 819 4. LOCATOR parameter format 821 The LOCATOR parameter is a critical parameter as defined by [2]. The 822 LOCATOR parameter is also abbreviated as "LOC" in the figures herein. 823 It consists of the standard HIP parameter Type and Length fields, 824 plus one or more Locator sub-parameters. Each Locator sub-parameter 825 contains a Traffic Type, Locator Type, Locator Length, Preferred 826 Locator bit, Locator Lifetime, and a Locator encoding. 828 0 1 2 3 829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Traffic Type | Locator Type | Locator Length | Reserved |P| 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Locator Lifetime | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Locator | 838 | | 839 | | 840 | | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 . . 843 . . 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Traffic Type | Locator Type | Locator Length | Reserved |P| 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Locator Lifetime | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Locator | 850 | | 851 | | 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Type: 193 857 Length: Length in octets, excluding Type and Length fields, and 858 excluding padding. 860 Traffic Type: Defines whether the locator pertains to HIP signaling, 861 user data, or both. 863 Locator Type: Defines the semantics of the Locator field. 865 Locator Length: Defines the length of the Locator field, in units of 866 4-byte words (Locators up to a maximum of 4*255 bytes are 867 supported). 869 Reserved: Zero when sent, ignored when received. 871 P: Preferred locator. Set to one if the locator is preferred for 872 that Traffic Type; otherwise set to zero. 874 Locator Lifetime: Locator lifetime, in seconds. 876 Locator: The locator whose semantics and encoding are indicated by 877 the Locator Type field. All Locator sub-fields are integral 878 multiples of four bytes in length. 880 The Locator Lifetime indicates how long the following locator is 881 expected to be valid. The lifetime is expressed in seconds. Each 882 locator MUST have a non-zero lifetime. The address is expected to 883 become deprecated when the specified number of seconds has passed 884 since the reception of the message. A deprecated address SHOULD NOT 885 be used as an destination address if an alternate (non-deprecated) is 886 available and has sufficient scope. 888 4.1 Traffic Type and Preferred Locator 890 The following Traffic Type values are defined: 892 0: Both signaling (HIP control packets) and user data. 894 1: Signaling packets only. 896 2: Data packets only. 898 The "P" bit, when set, has scope over the corresponding Traffic Type 899 that precedes it. That is, if a "P" bit is set for Traffic Type "2", 900 for example, that means that the locator is preferred for data 901 packets. If there is a conflict (for example, if P bit is set for 902 both "0" and "2"), the more specific Traffic Type rule applies. By 903 default, the IP addresses used in the base exchange are preferred 904 locators for both signaling and user data, unless a new preferred 905 locator supersedes them. If no locators are indicated as preferred 906 for a given Traffic Type, the implementation may use an arbitrary 907 locator from the set of active locators. 909 4.2 Locator Type and Locator 911 The following Locator Type values are defined, along with the 912 associated semantics of the Locator field: 914 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128 915 bits long). 917 1: The concatenation of an ESP SPI (first 32 bits) followed by an 918 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 919 128 bits). 921 4.3 UPDATE packet with included LOCATOR 923 A number of combinations of parameters in an UPDATE packet are 924 possible (e.g., see Section 3.2). Any UPDATE packet that includes a 925 LOCATOR parameter SHOULD include both an HMAC and a HIP_SIGNATURE 926 parameter. 928 5. Processing rules 930 HIP mobility and multihoming is fundamentally based on the HIP 931 architecture [1], where the transport and internetworking layers are 932 decoupled from each other by an interposed host identity protocol 933 layer. In the HIP architecture, the transport layer sockets are 934 bound to the Host Identifiers (through HIT or LSI in the case of 935 legacy APIs), and the Host Identifiers are translated to the actual 936 IP address. 938 The HIP base protocol specification [2] is expected to be commonly 939 used with the ESP Transport Format [5] to establish a pair of 940 Security Associations (SA). The ESP SAs are then used to carry the 941 actual payload data between the two hosts, by wrapping TCP, UDP, and 942 other upper layer packets into transport mode ESP payloads. The IP 943 header uses the actual IP addresses in the network. 945 Although HIP may also be specified in the future to operate with an 946 alternative to ESP providing the per-packet HIP context, the 947 remainder of this document assumes that HIP is being used in 948 conjunction with ESP. Future documents may extend this document to 949 include other behaviors when ESP is not used. 951 The base specification does not contain any mechanisms for changing 952 the IP addresses that were used during the base HIP exchange. Hence, 953 in order to remain connected, any systems that implement only the 954 base specification and nothing else must retain the ability to 955 receive packets at their primary IP address; that is, those systems 956 cannot change the IP address on which they are using to receive 957 packets without causing loss of connectivity until a base exchange is 958 performed from the new address. 960 5.1 Locator data structure and status 962 In a typical implementation, each outgoing locator is represented as 963 a piece of state that contains the following data: 965 o the actual bit pattern representing the locator, 967 o lifetime (seconds), 969 o status (UNVERIFIED, ACTIVE, DEPRECATED). 971 The status is used to track the reachability of the address embedded 972 within the LOCATOR parameter: 974 UNVERIFIED indicates that the reachability of the address has not 975 been verified yet, 977 ACTIVE indicates that the reachability of the address has been 978 verified and the address has not been deprecated, 980 DEPRECATED indicates that the locator lifetime has expired 982 The following state changes are allowed: 984 UNVERIFIED to ACTIVE The reachability procedure completes 985 successfully. 987 UNVERIFIED to DEPRECATED The locator lifetime expires while it is 988 UNVERIFIED. 990 ACTIVE to DEPRECATED The locator lifetime expires while it is ACTIVE. 992 ACTIVE to UNVERIFIED There has been no traffic on the address for 993 some time, and the local policy mandates that the address 994 reachability must be verified again before starting to use it 995 again. 997 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 998 locator. 1000 A DEPRECATED address MUST NOT be changed to ACTIVE without first 1001 verifying its reachability. 1003 5.2 Sending LOCATORs 1005 The decision of when to send LOCATORs is basically a local policy 1006 issue. However, it is RECOMMENDED that a host sends a LOCATOR 1007 whenever it recognizes a change of its IP addresses, and assumes that 1008 the change is going to last at least for a few seconds. Rapidly 1009 sending conflicting LOCATORs SHOULD be avoided. 1011 When a host decides to inform its peers about changes in its IP 1012 addresses, it has to decide how to group the various addresses, and 1013 whether to include any addresses on multiple SPIs. Since each SPI is 1014 associated with a different Security Association, the grouping policy 1015 may be based on ESP anti-replay protection considerations. In the 1016 typical case, simply basing the grouping on actual kernel level 1017 physical and logical interfaces is often the best policy. Virtual 1018 interfaces, such as IPsec tunnel interfaces or Mobile IP home 1019 addresses SHOULD NOT be announced. 1021 Note that the purpose of announcing IP addresses in a LOCATOR is to 1022 provide connectivity between the communicating hosts. In most cases, 1023 tunnels (and therefore virtual interfaces) provide sub-optimal 1024 connectivity. Furthermore, it should be possible to replace most 1025 tunnels with HIP based "non-tunneling", therefore making most virtual 1026 interfaces fairly unnecessary in the future. On the other hand, 1027 there are clearly situations where tunnels are used for diagnostic 1028 and/or testing purposes. In such and other similar cases announcing 1029 the IP addresses of virtual interfaces may be appropriate. 1031 Once the host has decided on the groups and assignment of addresses 1032 to the SPIs, it creates a LOCATOR parameter for each group. If there 1033 are multiple LOCATOR parameters, the parameters MUST be ordered so 1034 that the new preferred locator is in the first LOCATOR parameter. 1035 Only one locator (the first one, if at all) may be indicated as 1036 preferred for each distinct Traffic Type in the LOCATOR parameter. 1038 If addresses are being added to an existing SPI, the LOCATOR 1039 parameter includes the full set of valid addresses for that SPI, each 1040 using a Locator Type of "1" and each with the same value for SPI. 1041 Any locators previously ACTIVE on that SPI that are not included in 1042 the LOCATOR will be set to DEPRECATED by the receiver. 1044 If a mobile host decides to change the SPI upon a readdress, it sends 1045 a LOCATOR with the SPI field within the LOCATOR set to the new SPI, 1046 and also an ESP_INFO parameter with the Old SPI field set to the 1047 previous SPI and the New SPI field set to the new SPI. If multiple 1048 LOCATOR and ESP_INFO parameters are included, the ESP_INFO MUST be 1049 ordered such that they appear in the same order as the set of 1050 corresponding LOCATORs. The decision as to whether to rekey and send 1051 a new Diffie-Hellman parameter while performing readdressing is a 1052 local policy decision. 1054 If new addresses and new SPIs are being created, the LOCATOR 1055 parameter's SPI field contains the new SPI, and the ESP_INFO 1056 parameter's Old SPI field and New SPI fields are both set to the new 1057 SPI, indicating that this is a new and not a replacement SPI. 1059 If there are multiple LOCATOR parameters leading to a packet size 1060 that exceeds the MTU, HIP fragmentation rules as described in [2] 1061 shall apply. 1063 5.3 Handling received LOCATORs 1065 A host SHOULD be prepared to receive LOCATOR parameters in any HIP 1066 packets, excluding I1. 1068 When a host receives a LOCATOR parameter, it first performs the 1069 following operations: 1071 1. For each locator listed in the LOCATOR parameter, check that the 1072 address therein is a legal unicast or anycast address. That is, 1073 the address MUST NOT be a broadcast or multicast address. Note 1074 that some implementations MAY accept addresses that indicate the 1075 local host, since it may be allowed that the host runs HIP with 1076 itself. 1078 2. For each address listed in the LOCATOR parameter, check if the 1079 address is already bound to the SPI. If the address is already 1080 bound, its lifetime is updated. If the status of the address is 1081 DEPRECATED, the status is changed to UNVERIFIED. If the address 1082 is not already bound, the address is added, and its status is set 1083 to UNVERIFIED. Mark all addresses on the SPI that were NOT 1084 listed in the LOCATOR parameter as DEPRECATED. As a result, the 1085 SPI now contains any addresses listed in the LOCATOR parameter 1086 either as UNVERIFIED or ACTIVE, and any old addresses not listed 1087 in the LOCATOR parameter as DEPRECATED. 1089 3. If the LOCATOR is paired with an ESP_INFO parameter, the ESP_INFO 1090 parameter is processed. If the LOCATOR is replacing the address 1091 on an existing SPI, the SPI itself may be changed-- in this case, 1092 the host proceeds according to HIP rekeying procedures. This 1093 case is indicated by the ESP_INFO parameter including an existing 1094 SPI in the Old SPI field and a new SPI in the New SPI field, and 1095 the SPI field in the LOCATOR matching the New SPI in the 1096 ESP_INFO. If instead the LOCATOR corresponds to a new SPI, the 1097 ESP_INFO will include the same SPI in both its Old SPI and New 1098 SPI fields. 1100 4. Mark all locators at the address group that were NOT listed in 1101 the LOCATOR parameter as DEPRECATED. 1103 Once the host has updated the SPI, if the LOCATOR parameter contains 1104 a new preferred locator, the host SHOULD initiate a change of the 1105 preferred locator. This requires that the host first verifies 1106 reachability of the associated address, and only then changes the 1107 preferred locator. See Section 5.6. 1109 5.4 Verifying address reachability 1111 A host MUST verify the reachability of an UNVERIFIED address. The 1112 status of a newly learned address MUST initially be set to UNVERIFIED 1113 unless the new address is advertised in a R1 packet as a new 1114 preferred locator. A host MAY also want to verify the reachability 1115 of an ACTIVE address again after some time, in which case it would 1116 set the status of the address to UNVERIFIED and reinitiate address 1117 verification 1118 A host typically starts the address-verification procedure by sending 1119 a nonce to the new address. For example, if the host is changing its 1120 SPI and is sending an ESP_INFO to the peer, the new SPI value SHOULD 1121 be random and the value MAY be copied into an ECHO_REQUEST sent in 1122 the rekeying UPDATE. If the host is not rekeying, it MAY still use 1123 the ECHO_REQUEST parameter in an UPDATE message sent to the new 1124 address. A host MAY also use other message exchanges as confirmation 1125 of the address reachability. 1127 Note that in the case of receiving a LOCATOR on an R1 and replying 1128 with an I2, receiving the corresponding R2 is sufficient proof of 1129 reachability for the Responder's preferred address. Since further 1130 address verification of such address can impede the HIP base 1131 exchange, a host MUST NOT verify reachability of a new preferred 1132 locator that was received on a R1. 1134 In some cases, it may be sufficient to use the arrival of data on a 1135 newly advertised SA as implicit address reachability verification, 1136 instead of waiting for the confirmation via a HIP packet (e.g., 1137 Figure 14). In this case, a host advertising a new SPI as part of 1138 its address reachability check SHOULD be prepared to receive traffic 1139 on the new SA. Marking the address ACTIVE as a part of receiving 1140 data on the SA is an idempotent operation, and does not cause any 1141 harm. 1143 Mobile host Peer host 1145 prepare incoming SA 1146 new SPI in R2, or UPDATE 1147 <----------------------------------- 1148 switch to new outgoing SA 1149 data on new SA 1150 -----------------------------------> 1151 mark address ACTIVE 1153 Figure 14: Address activation via use of new SA 1155 When address verification is in progress for a new preferred locator, 1156 the host SHOULD select a different locator listed as ACTIVE, if one 1157 such locator is available, to continue communications until address 1158 verification completes. Alternatively, the host MAY use the new 1159 preferred locator while in UNVERIFIED status to the extent Credit- 1160 Based Authorization permits. Credit-Based Authorization is explained 1161 in Section 5.5. Once address verification succeeds, the status of 1162 the new preferred locator changes to ACTIVE. 1164 5.5 Credit-Based Authorization 1166 5.5.1 Handling Payload Packets 1168 A host maintains a "credit counter" for each of its peers. Whenever 1169 a packet arrives from a peer, the host SHOULD increase that peer's 1170 credit counter by the size of the received packet. When the host has 1171 a packet to be sent to the peer, if the peers preferred locator is 1172 listed as UNVERIFIED and no alternative locator with status ACTIVE is 1173 available, the host checks whether it can send the packet to the 1174 UNVERIFIED locator: The packet SHOULD be sent if the value of the 1175 credit counter is higher than the size of the outbound packet. If 1176 the credit counter is too low, the packet MUST be discarded or 1177 buffered until address verification succeeds. When a packet is sent 1178 to a peer at an UNVERIFIED locator, the peer's credit counter MUST be 1179 reduced by the size of the packet. The peer's credit counter is not 1180 affected by packets that the host sends to an ACTIVE locator of that 1181 peer. 1183 Figure 15 depicts the actions taken by the host when a packet is 1184 received. Figure 16 shows the decision chain in the event a packet 1185 is sent. 1187 Inbound 1188 packet 1189 | 1190 | +----------------+ +---------------+ 1191 | | Increase | | Deliver | 1192 +-----> | credit counter |-------------> | packet to | 1193 | by packet size | | application | 1194 +----------------+ +---------------+ 1196 Figure 15: Receiving Packets with Credit-Based Authorization 1198 Outbound 1199 packet 1200 | _________________ 1201 | / \ +---------------+ 1202 | / Is the preferred \ No | Send packet | 1203 +-----> | destination address |-------------> | to preferred | 1204 \ UNVERIFIED? / | address | 1205 \_________________/ +---------------+ 1206 | 1207 | Yes 1208 | 1209 v 1210 _________________ 1211 / \ +---------------+ 1212 / Does an ACTIVE \ Yes | Send packet | 1213 | destination address |-------------> | to ACTIVE | 1214 \ exist? / | address | 1215 \_________________/ +---------------+ 1216 | 1217 | No 1218 | 1219 v 1220 _________________ 1221 / \ +---------------+ 1222 / Credit counter \ No | | 1223 | >= |-------------> | Drop packet | 1224 \ packet size? / | | 1225 \_________________/ +---------------+ 1226 | 1227 | Yes 1228 | 1229 v 1230 +---------------+ +---------------+ 1231 | Reduce credit | | Send packet | 1232 | counter by |----------------> | to preferred | 1233 | packet size | | address | 1234 +---------------+ +---------------+ 1236 Figure 16: Sending Packets with Credit-Based Authorization 1238 5.5.2 Credit Aging 1240 A host ensures that the credit counters it maintains for its peers 1241 gradually decrease over time. Such "credit aging" prevents a 1242 malicious peer from building up credit at a very slow speed and using 1243 this, all at once, for a severe burst of redirected packets. 1245 Credit aging may be implemented by multiplying credit counters with a 1246 factor, CreditAgingFactor, less than one in fixed time intervals of 1247 CreditAgingInterval length. Choosing appropriate values for 1248 CreditAgingFactor and CreditAgingInterval is important to ensure that 1249 a host can send packets to an address in state UNVERIFIED even when 1250 the peer sends at a lower rate than the host itself. When 1251 CreditAgingFactor or CreditAgingInterval are too small, the peer's 1252 credit counter might be too low to continue sending packets until 1253 address verification concludes. 1255 The parameter values proposed in this document are as follows: 1257 CreditAgingFactor 7/8 1258 CreditAgingInterval 5 seconds 1260 These parameter values work well when the host transfers a file to 1261 the peer via a TCP connection and the end-to-end round-trip time does 1262 not exeed 500 milliseconds. Alternative credit-aging algorithms may 1263 use other parameter values or different parameters, which may even be 1264 dynamically established. 1266 5.6 Changing the preferred locator 1268 A host MAY want to change the preferred outgoing locator for 1269 different reasons, e.g., because traffic information or ICMP error 1270 messages indicate that the currently used preferred address may have 1271 become unreachable. Another reason is receiving a LOCATOR parameter 1272 that has the P-bit set. 1274 To change the preferred locator, the host initiates the following 1275 procedure: 1277 1. If the new preferred locator has ACTIVE status, the preferred 1278 locator is changed and the procedure succeeds. 1280 2. If the new preferred locator has UNVERIFIED status, the host 1281 starts to verify its reachability. The host SHOULD use a 1282 different locator listed as ACTIVE until address verification 1283 completes if one such locator is available. Altervatively, the 1284 host MAY use the new preferred locator, even though in UNVERIFIED 1285 status, to the extent Credit-Based Authorization permits. Once 1286 address verification succeeds, the status of the new preferred 1287 locator changes to ACTIVE and its use is no longer governed by 1288 Credit-Based Authorization. 1290 3. If the peer host has not indicated a preference for any address, 1291 then the host picks one of the peer's ACTIVE addresses randomly 1292 or according to policy. This case may arise if, for example, 1293 ICMP error messages arrive that deprecate the preferred locator, 1294 but the peer has not yet indicated a new preferred locator. 1296 4. If the new preferred locator has DEPRECATED status and there is 1297 at least one non-deprecated address, the host selects one of the 1298 non-deprecated addresses as a new preferred locator and 1299 continues. If the selected address is UNVERIFIED, this includes 1300 address verification as described above. 1302 6. Policy considerations 1304 XXX: This section needs to be written. 1306 The host may change the status of unused ACTIVE addresses into 1307 UNVERIFIED after a locally configured period of inactivity. 1309 7. Security Considerations 1311 The HIP mobility mechanism provides a secure means of updating a 1312 host's IP address via HIP REA update packets. Upon receipt, a HIP 1313 host cryptographically verifies the sender of a REA update, so 1314 forging or replaying a HIP update packet is very difficult (see [2]). 1315 Therefore, security issues reside in other attack domains. The two 1316 we consider are malicious redirection of legitimate connections as 1317 well as redirection-based flooding attacks using this protocol. This 1318 can be broken down into the following: 1320 Impersonation attacks 1322 - direct conversation with the misled victim 1324 - man-in-the-middle attack 1326 DoS attacks 1328 - flooding attacks (== bandwidth-exhaustion attacks) 1330 * tool 1: direct flooding 1332 * tool 2: flooding by zombies 1334 * tool 2: redirection-based flooding 1336 - memory-exhaustion attacks 1338 - computational exhaustion attacks 1340 We consider these in more detail in the following sections. 1342 In Section 7.1 and Section 7.2, we assume that all users are using 1343 HIP. In Section 7.3 we consider the security ramifications when we 1344 have both HIP and non-HIP users. 1346 7.1 Impersonation attacks 1348 An attacker wishing to impersonate will try to mislead its victim 1349 into directly communicating with them, or carry out a man in the 1350 middle attack between the victim and the victim's desired 1351 communication peer. Without mobility support, both attack types are 1352 possible only if the attacker resides on the routing path between its 1353 victim and the victim's desired communication peer, or if the 1354 attacker tricks its victim into initiating the connection over an 1355 incorrect routing path (e.g., by acting as a router or using spoofed 1356 DNS entries). 1358 The HIP extensions defined in this specification change the situation 1359 in that they introduce an ability to redirect a connection (like 1360 IPv6), both before and after establishment. If no precautionary 1361 measures are taken, an attacker could misuse this feature to 1362 impersonate a victim's peer from any arbitrary location. The 1363 authentication and authorization mechanisms of the HIP base exchange 1364 [2] and the signatures in the new REA update message prevent this 1365 offense. Furthermore, ownership of a connection is securely linked 1366 to a HIP HI/HIT. If an attacker somehow uses a bug in the 1367 implementation or weakness in some protocol to redirect a HIP 1368 connection, the original owner can always reclaim their connection 1369 (they can always prove ownership of the private key associated with 1370 their public HI). 1372 MitM attacks are always possible if the attacker is present during 1373 the initial HIP base exchange but once the base exchange has taken 1374 place even a MitM cannot steal a HIP connection because it is very 1375 difficult for an attacker to create an REA update packet (or any HIP 1376 packet) that will be accepted as a legitimate update. Update packets 1377 use HMAC and are signed. Even when an attacker can snoop packets to 1378 attain the SPI and HIT/HI, they still cannot forge an update packet 1379 without knowledge of the secret keys. 1381 7.2 Denial of Service attacks 1383 7.2.1 Flooding Attacks 1385 The purpose of a denial-of-service attack is to exhaust some resource 1386 of the victim such that the victim ceases operating correctly. A 1387 denial-of-service attack can aim at the victim's network attachment 1388 (flooding attack), its memory or its processing capacity. In a 1389 flooding attack the attacker causes an excessive number of bogus or 1390 unwanted packets to be sent to the victim, which fills their 1391 available bandwidth. Note that the victim does not necessarily need 1392 to be a node; it can also be an entire network. The attack basically 1393 functions the same way in either case. 1395 An effective DoS strategy is distributed denial of service (DDoS). 1396 Here, the attacker conventionally distributes some viral software to 1397 as many nodes as possible. Under the control of the attacker, the 1398 infected nodes, or "zombies", jointly send packets to the victim. 1399 With such an 'army', an attacker can take down even very high 1400 bandwidth networks/victims. 1402 With the ability to redirect connections, an attacker could realize a 1403 DDoS attack without having to distribute viral code. Here, the 1404 attacker initiates a large download from a server, and subsequently 1405 redirects this download to its victim. The attacker can repeat this 1406 with multiple servers. This threat is mitigated through reachability 1407 checks and credit-based authorization. Both strategies do not 1408 eliminate flooding attacks per se, but they preclude: (i) their use 1409 from a location off the path towards the flooded victim; and (ii) any 1410 amplification in the number and size of the redirected packets. As a 1411 result, the combination of a reachability check and credit-based 1412 authorization makes a HIP redirection-based flooding attack as 1413 effective and applicable as a normal, direct flooding attack in which 1414 the attacker itself sends the flooding traffic to the victim. 1416 This analysis leads to the following two points. First, when a 1417 reachability packet is received this nonce packet MUST be ignored if 1418 the HIT is not one that is currently active. Second, if the attacker 1419 is a MitM and can capture this nonce packet then they can respond to 1420 it, in which case it is possible for an attacker to redirect their 1421 connection. Note, this attack will always be possible when a 1422 reachability packet is not sent. 1424 7.2.2 Memory/Computational exhaustion DoS attacks 1426 We now consider whether or not the proposed extensions to HIP add any 1427 new DoS attacks (consideration of DoS attacks using the base HIP 1428 exchange and updates is discussed in [2]). A simple attack is to 1429 send many REA update packets containing many ip addresses that are 1430 not flagged as preferred. The attacker continues to send such 1431 packets until the number of ip addresses associated with the 1432 attackers HI crashes the system. Therefore, their SHOULD be a limit 1433 to the number of ip addresses that can be associated with any HI. 1434 Other forms of memory/computationally exhausting attacks via the HIP 1435 update packet are handled in the base HIP draft [2]. 1437 7.3 Mixed deployment environment 1439 We now assume that we have both HIP and non-HIP aware hosts. Four 1440 cases exist. 1442 1. A HIP user redirects their connection onto a non-HIP user. The 1443 non-HIP user will drop the reachability packet so this is not a 1444 threat unless the HIP user is a MitM and can respond to the 1445 reachability packet. 1447 2. A non-HIP user attempts to redirect their connection onto a HIP 1448 user. This falls into IPv4 and IPv6 security concerns, which are 1449 outside the scope of this document. 1451 3. A non-HIP user attempts to steal a HIP user's session (assume 1452 that SeND is not active for the following). The non-HIP user 1453 contacts the service that a HIP user has a connection with and 1454 then attempts to use a IPv6 change of address request to steal 1455 the HIP user's connection. What will happen in this case is 1456 implementation dependent but such a request should be ignored/ 1457 dropped. Even if the attack is sucessful, the HIP user can 1458 reclaim their connection via HIP. 1460 4. A HIP user attempts to steal a non-HIP user's session. This 1461 could be problematic since HIP sits 'on top of' layer 3. A HIP 1462 user could spoof the non-HIP user's ip address during the base 1463 exhange or set the non-HIP user's ip address as their preferred 1464 address via an REA update. Other possibilities exist but a 1465 simple solution is to add a check which does not allow any HIP 1466 session to be moved to or created upon an already existing ip 1467 address. 1469 8. IANA Considerations 1470 9. Authors 1472 Pekka Nikander originated this Internet Draft. Tom Henderson, Jari 1473 Arkko, Greg Perkins, and Christian Vogt have each contributed 1474 sections to this draft. 1476 10. Acknowledgments 1478 The authors thank Mika Kousa for many improvements to the draft. 1480 11. References 1482 11.1 Normative references 1484 [1] Moskowitz, R., "Host Identity Protocol Architecture", 1485 draft-ietf-hip-arch-02 (work in progress), January 2005. 1487 [2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 1488 (work in progress), June 2005. 1490 [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1491 Rendezvous Extension", draft-ietf-hip-rvs-03 (work in progress), 1492 July 2005. 1494 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1495 (ESP)", RFC 2406, November 1998. 1497 [5] Jokela, P., "Using ESP transport format with HIP", 1498 draft-ietf-hip-esp-00 (work in progress), July 2005. 1500 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1501 Levels", BCP 14, RFC 2119, March 1997. 1503 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 1504 Architecture", RFC 2373, July 1998. 1506 11.2 Informative references 1508 [8] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, 1509 March 1998. 1511 [9] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1512 Security Considerations", draft-iab-sec-cons-00 (work in 1513 progress), August 2002. 1515 [10] Nikander, P., "Mobile IP version 6 Route Optimization Security 1516 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 1517 in progress), December 2003. 1519 Author's Address 1521 Tom Henderson 1522 The Boeing Company 1523 P.O. Box 3707 1524 Seattle, WA 1525 USA 1527 Email: thomas.r.henderson@boeing.com 1529 Appendix A. Changes from previous versions 1531 A.1 From nikander-hip-mm-00 to nikander-hip-mm-01 1533 The actual protocol has been largely revised, based on the new 1534 symmetric New SPI (NES) design adopted in the base protocol draft 1535 version -08. There are no more separate REA, AC or ACR packets, but 1536 their functionality has been folded into the NES packet. At the same 1537 time, it has become possible to send REA parameters in R1 and I2. 1539 The Forwarding Agent functionality was removed, since it looks like 1540 that it will be moved to the proposed HIP Research Group. Hence, 1541 there will be two other documents related to that, a simple 1542 Rendezvous server document (WG item) and a Forwarding Agent document 1543 (RG item). 1545 A.2 From nikander-hip-mm-01 to nikander-hip-mm-02 1547 Alignment with base-00 draft (use of UPDATE and NOTIFY packets). 1549 The "logical interface" concept was dropped, and the SA/SPI was 1550 identified as the protocol component to which a HIP association binds 1551 addresses to. 1553 The RR was (again) made recommended, not mandatory, able to be 1554 administratively overridden. 1556 A.3 From -02 to draft-ietf-hip-mm-00 1558 REA parameter type value is now "3" (was TBD before). 1560 Recommend that in multihoming situations, that inbound/outbound SAs 1561 are paired to avoid ambiguity when rekeying them. 1563 Clarified that multihoming scenario for now was intended for failover 1564 instead of load-balancing, due to transport layer issues. 1566 Clarified that if HIP negotiates base exchange using link local 1567 addresses, that a host SHOULD provide its peer with a globally 1568 reachable address. 1570 Clarified whether REAs sent for existing SPIs update the full set of 1571 addresses associated with that SPI, or only perform an incremental 1572 (additive) update. REAs for an existing SPI should list all current 1573 addresses for that SPI, and any addresses previously in use on the 1574 SPI but not in the new REA parameter should be DEPRECATED. 1576 Clarified that address verification pertains to *outgoing* addresses. 1578 When discussing inclusion of REA in I2, the draft stated "The 1579 Responder MUST make sure that the puzzle solution is valid BOTH for 1580 the initial IP destination address used for I1 and for the new 1581 preferred address." However, this statement conflicted with Appendix 1582 D of the base specification, so it has been removed for now. 1584 A.4 From draft-ietf-hip-mm-00 to -01 1586 Introduction section reorganized. Some of the scope of the document 1587 relating to multihoming was reduced. 1589 Removed empty appendix "Implementation experiences" 1591 Renamed REA parameter to LOCATOR and aligned to the discussion on 1592 redefining this parameter that occurred on the RG mailing list. 1594 Aligned with decoupling of ESP from base spec. 1596 A.5 From draft-ietf-hip-mm-01 to -02 1598 Aligned with draft-ietf-hip-base-03 and draft-ietf-hip-esp-00 1600 Address verification is a MUST (C. Vogt, list post on 06/12/05) 1602 If UPDATE exceeds MTU because of too many locators, do not split into 1603 multiple UPDATEs, but instead rely on IP fragmentation (C. Vogt, list 1604 post on 06/12/05) 1606 New value for LOCATOR parameter type (193), per 05/31/05 discussion 1607 on the WG list 1609 Various additions related to Credit-Based Authorization due to C. 1610 Vogt 1612 Security section contributed by Greg Perkins, with subsequent editing 1613 from C. Vogt and P. Nikander 1615 Reorganization according to RFC 4101 guidance on writing protocol 1616 models 1618 Open issue: LOCATOR parameter semantics (implicit/explicit removal) 1620 Intellectual Property Statement 1622 The IETF takes no position regarding the validity or scope of any 1623 Intellectual Property Rights or other rights that might be claimed to 1624 pertain to the implementation or use of the technology described in 1625 this document or the extent to which any license under such rights 1626 might or might not be available; nor does it represent that it has 1627 made any independent effort to identify any such rights. Information 1628 on the procedures with respect to rights in RFC documents can be 1629 found in BCP 78 and BCP 79. 1631 Copies of IPR disclosures made to the IETF Secretariat and any 1632 assurances of licenses to be made available, or the result of an 1633 attempt made to obtain a general license or permission for the use of 1634 such proprietary rights by implementers or users of this 1635 specification can be obtained from the IETF on-line IPR repository at 1636 http://www.ietf.org/ipr. 1638 The IETF invites any interested party to bring to its attention any 1639 copyrights, patents or patent applications, or other proprietary 1640 rights that may cover technology that may be required to implement 1641 this standard. Please address the information to the IETF at 1642 ietf-ipr@ietf.org. 1644 Disclaimer of Validity 1646 This document and the information contained herein are provided on an 1647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1651 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1654 Copyright Statement 1656 Copyright (C) The Internet Society (2005). This document is subject 1657 to the rights, licenses and restrictions contained in BCP 78, and 1658 except as set forth therein, the authors retain all their rights. 1660 Acknowledgment 1662 Funding for the RFC Editor function is currently provided by the 1663 Internet Society.