idnits 2.17.1 draft-ietf-hip-mm-03.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 1822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1812. ** 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 (February 24, 2006) is 6637 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) ** 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-04 ** 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-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. '5') ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) Summary: 8 errors (**), 0 flaws (~~), 5 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: August 28, 2006 February 24, 2006 6 End-Host Mobility and Multihoming with the Host Identity Protocol 7 draft-ietf-hip-mm-03 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 August 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . 6 54 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 7 56 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.1.2. Mobility overview . . . . . . . . . . . . . . . . . . 10 58 3.1.3. Multihoming overview . . . . . . . . . . . . . . . . . 10 59 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 60 3.2.1. Mobility with single SA pair (no rekeying) . . . . . . 11 61 3.2.2. Host multihoming . . . . . . . . . . . . . . . . . . . 13 62 3.2.3. Site multihoming . . . . . . . . . . . . . . . . . . . 15 63 3.2.4. Dual host multihoming . . . . . . . . . . . . . . . . 15 64 3.2.5. Combined mobility and multihoming . . . . . . . . . . 16 65 3.2.6. Using LOCATORs across addressing realms . . . . . . . 16 66 3.2.7. Network renumbering . . . . . . . . . . . . . . . . . 16 67 3.2.8. Initiating the protocol in R1 or I2 . . . . . . . . . 16 68 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 17 69 3.3.1. Address Verification . . . . . . . . . . . . . . . . . 17 70 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 18 71 3.3.3. Preferred locator . . . . . . . . . . . . . . . . . . 19 72 3.3.4. Interaction with Security Associations . . . . . . . . 20 73 4. LOCATOR parameter format . . . . . . . . . . . . . . . . . . . 23 74 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 24 75 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 25 76 4.3. UPDATE packet with included LOCATOR . . . . . . . . . . . 25 77 5. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 26 78 5.1. Locator data structure and status . . . . . . . . . . . . 26 79 5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 26 80 5.3. Handling received LOCATORs . . . . . . . . . . . . . . . . 28 81 5.4. Verifying address reachability . . . . . . . . . . . . . . 30 82 5.5. Credit-Based Authorization . . . . . . . . . . . . . . . . 31 83 5.5.1. Handling Payload Packets . . . . . . . . . . . . . . . 31 84 5.5.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 33 85 5.6. Changing the preferred locator . . . . . . . . . . . . . . 34 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 87 6.1. Impersonation attacks . . . . . . . . . . . . . . . . . . 36 88 6.2. Denial of Service attacks . . . . . . . . . . . . . . . . 37 89 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 37 90 6.2.2. Memory/Computational exhaustion DoS attacks . . . . . 38 91 6.3. Mixed deployment environment . . . . . . . . . . . . . . . 38 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 93 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 94 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 10.1. Normative references . . . . . . . . . . . . . . . . . . . 43 97 10.2. Informative references . . . . . . . . . . . . . . . . . . 43 99 Appendix A. Changes from previous versions . . . . . . . . . . . 44 100 A.1. From nikander-hip-mm-00 to nikander-hip-mm-01 . . . . . . 44 101 A.2. From nikander-hip-mm-01 to nikander-hip-mm-02 . . . . . . 44 102 A.3. From -02 to draft-ietf-hip-mm-00 . . . . . . . . . . . . . 44 103 A.4. From draft-ietf-hip-mm-00 to -01 . . . . . . . . . . . . . 45 104 A.5. From draft-ietf-hip-mm-01 to -02 . . . . . . . . . . . . . 45 105 A.6. From draft-ietf-hip-mm-02 to -03 . . . . . . . . . . . . . 45 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 107 Intellectual Property and Copyright Statements . . . . . . . . . . 48 109 1. Introduction and Scope 111 The Host Identity Protocol [1] (HIP) supports an architecture that 112 decouples the transport layer (TCP, UDP, etc.) from the 113 internetworking layer (IPv4 and IPv6) by using public/private key 114 pairs, instead of IP addresses, as host identities. When a host uses 115 HIP, the overlying protocol sublayers (e.g., transport layer sockets 116 and ESP Security Associations) are instead bound to representations 117 of these host identities, and the IP addresses are only used for 118 packet forwarding. However, each host must also know at least one IP 119 address at which its peers are reachable. Initially, these IP 120 addresses are the ones used during the HIP base exchange [2]. 122 One consequence of such a decoupling is that new solutions to 123 network-layer mobility and host multihoming are possible. There are 124 potentially many variations of mobility and multihoming possible. 125 The scope of this document encompasses messaging and elements of 126 procedure for basic network-level mobility and simple multihoming, 127 leaving more complicated scenarios and other variations for further 128 study. Specifically, 130 This document defines a generalized LOCATOR parameter for use in 131 HIP messages. The LOCATOR parameter allows a HIP host to notify a 132 peer about alternate addresses at which it is reachable. The 133 LOCATORs may be merely IP addresses, or they may have additional 134 multiplexing and demultiplexing context to aid the packet handling 135 in the lower layers. For instance, an IP address may need to be 136 paired with an ESP SPI so that packets are sent on the correct SA 137 for a given address. 139 This document also specifies the messaging and elements of 140 procedure for end-host mobility of a HIP host-- the sequential 141 change in preferred IP address used to reach a host. In 142 particular, message flows to enable successful host mobility, 143 including address verification methods, are defined herein. 145 However, while the same LOCATOR parameter is intended to support 146 host multihoming (parallel support of a number of addresses), and 147 experimentation is encouraged, detailed elements of procedure for 148 host multihoming are left for further study. 150 While HIP can potentially be used with transports other than the ESP 151 transport format [5], this document largely assumes the use of ESP 152 and leaves other transport for further study. 154 There are a number of situations where the simple end-to-end 155 readdressing functionality is not sufficient. These include the 156 initial reachability of a mobile host, location privacy, simultaneous 157 mobility of both hosts, and some modes of NAT traversal. In these 158 situations there is a need for some helper functionality in the 159 network, such as a HIP Rendezvous server [3]. Such functionality is 160 out of scope of this document. We also do not consider localized 161 mobility management extensions; this document is concerned with end- 162 to-end mobility. Finally, making underlying IP mobility transparent 163 to the transport layer has implications on the proper response of 164 transport congestion control, path MTU selection, and QoS. 165 Transport-layer mobility triggers, and the proper transport response 166 to a HIP mobility or multihoming address change, are outside the 167 scope of this document. 169 2. Terminology and Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC2119 [6]. 175 Locator. A name that controls how the packet is routed through the 176 network and demultiplexed by the end host. It may include a 177 concatenation of traditional network addresses such as an IPv6 178 address and end-to-end identifiers such as an ESP SPI. It may 179 also include transport port numbers or IPv6 Flow Labels as 180 demultiplexing context, or it may simply be a network address. 182 Address. A name that denotes a point-of-attachment to the network. 183 The two most common examples are an IPv4 address and an IPv6 184 address. The set of possible addresses is a subset of the set of 185 possible locators. 187 Preferred locator. A locator on which a host prefers to receive data. 188 With respect to a given peer, a host always has one active 189 preferred locator, unless there are no active locators. By 190 default, the locators used in the HIP base exchange are the 191 preferred locators. 193 Credit Based Authorization. A host must verify a mobile or multi- 194 homed peer's reachability at a new locator. Credit-Based 195 Authorization authorizes the peer to receive a certain amount of 196 data at the new locator before the result of such verification is 197 known. 199 3. Protocol Model 201 3.1. Operating Environment 203 The Host Identity Protocol (HIP) [2] is a key establishment and 204 parameter negotiation protocol. Its primary applications are for 205 authenticating host messages based on host identities, and 206 establishing security associations (SAs) for ESP transport format [5] 207 and possibly other protocols in the future. 209 +--------------------+ +--------------------+ 210 | | | | 211 | +------------+ | | +------------+ | 212 | | Key | | HIP | | Key | | 213 | | Management | <-+-----------------------+-> | Management | | 214 | | Process | | | | Process | | 215 | +------------+ | | +------------+ | 216 | ^ | | ^ | 217 | | | | | | 218 | v | | v | 219 | +------------+ | | +------------+ | 220 | | IPsec | | ESP | | IPsec | | 221 | | Stack | <-+-----------------------+-> | Stack | | 222 | | | | | | | | 223 | +------------+ | | +------------+ | 224 | | | | 225 | | | | 226 | Initiator | | Responder | 227 +--------------------+ +--------------------+ 229 Figure 1: HIP deployment model 231 The general deployment model for HIP is shown above, assuming 232 operation in an end-to-end fashion. This document specifies 233 extensions to the HIP protocol to enable end-host mobility and 234 multihoming. In summary, these extensions to the HIP protocol can 235 carry new addressing information to the peer and can enable direct 236 authentication of the message via a signature or keyed hash message 237 authentication code (HMAC) based on its host identity. This document 238 specifies the format of this new addressing (LOCATOR) parameter, the 239 procedures for sending and processing this parameter to enable basic 240 host mobility, and procedures for a concurrent address verification 241 mechanism. 243 --------- 244 | TCP | (sockets bound to HITs) 245 --------- 246 | 247 --------- 248 ----> | ESP | {HIT_s, HIT_d} <-> SPI 249 | --------- 250 | | 251 ---- --------- 252 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 253 ---- --------- 254 | 255 --------- 256 | IP | 257 --------- 259 Figure 2: Architecture for HIP mobility and multihoming 261 Figure 2 depicts a layered architectural view of a HIP-enabled stack 262 using ESP transport format. In HIP, upper-layer protocols (including 263 TCP and ESP in this figure) are bound to HITs and not IP addresses. 264 The HIP sublayer is responsible for maintaining the binding between 265 HITs and IP addresses. The SPI (or other context tag if ESP is not 266 used with HIP), and not necessarily the IP addresses, is used to 267 associate an incoming packet with the right HITs. The block labeled 268 "MH" is introduced below. 270 Consider first the case in which there is no mobility or multihoming, 271 as specified in the base protocol specification [2]. The HIP base 272 exchange establishes the HITs in use between the hosts, the SPIs to 273 use for ESP, and the IP addresses (used in the HIP signaling 274 packets). Note that there can only be one such binding in the 275 outbound direction for any given packet, and the only selectors for 276 the binding at the HIP layer are the fields exposed by ESP (the SPI 277 and HITs). For the inbound direction, the SPI is all that is 278 required to find the right host context. ESP rekeying events change 279 the mapping between the HIT pair and SPI, but do not change the IP 280 addresses. 282 Consider next a mobility event, in which a host is still single-homed 283 but moves to another IP address. Two things must occur in this case. 284 First, the peer must be notified of the address change using a HIP 285 UPDATE message. Second, each host must change its local bindings at 286 the HIP sublayer (new IP addresses). It may be that both the SPIs 287 and IP addresses are changed simultaneously in a single UPDATE; the 288 protocol described herein supports this. This document specifies the 289 messaging and elements of procedure for such a mobility event. 290 However, simultaneous movement of both hosts, notification of 291 transport layer protocols of the path change, and procedures for 292 possibly traversing middleboxes are not covered by this document. 294 Finally, consider the case when a host is multihomed (has more than 295 one globally routable address) and wants to make these multiple 296 addresses available for use by the upper layer protocols, for fault 297 tolerance. Examples include the use of (possibly multiple) IPv4 and 298 IPv6 addresses on the same interface, or the use of multiple 299 interfaces attached to different service providers. Such host 300 multihoming generally necessitates that a separate ESP SA is 301 maintained for each interface in order to prevent packets that arrive 302 over different paths from falling outside of the ESP replay 303 protection window. Multihoming thus makes possible that the bindings 304 shown on the right side of Figure 2 are one to many (in the outbound 305 direction, one HIT pair to multiple SPIs, and possibly then to 306 multiple IP addresses). However, only one SPI and address can be 307 used for any given packet, so the job of the "MH" block depicted 308 above is to dynamically manipulate these bindings. Beyond locally 309 managing such multiple bindings, the peer-to-peer HIP signaling 310 protocol needs to be flexible enough to define the desired mappings 311 between HITs, SPIs, and addresses, and needs to ensure that UPDATE 312 messages are sent along the right network paths so that any HIP-aware 313 middleboxes can observe the SPIs. This document does not specify the 314 "MH" block, nor does it specify detailed elements of procedure for 315 how to handle various multihoming (perhaps combined with mobility) 316 scenarios. However, this document does describe a basic multihoming 317 case (one host adds one address to its initial address and notifies 318 the peer) and leave more complicated scenarios for experimentation 319 and future documents. 321 3.1.1. Locator 323 This document defines a generalization of an address called a 324 "locator". A locator specifies a point-of-attachment to the network 325 but may also include additional end-to-end tunneling or per-host 326 demultiplexing context that affects how packets are handled below the 327 logical HIP sublayer of the stack. This generalization is useful 328 because IP addresses alone may not be sufficient to describe how 329 packets should be handled below HIP. For example, in a host 330 multihoming context, certain IP addresses may need to be associated 331 with certain ESP SPIs, to avoid violation of the ESP anti-replay 332 window [4]. Addresses may also be affiliated with transport ports in 333 certain tunneling scenarios. Or locators may merely be traditional 334 network addresses. In Section 4, a generalized HIP LOCATOR parameter 335 is defined that can contain one or more locators (addresses). 337 3.1.2. Mobility overview 339 When a host moves to another address, it notifies its peer of the new 340 address by sending a HIP UPDATE packet containing a LOCATOR 341 parameter. This UPDATE packet is acknowledged by the peer, and is 342 protected by retransmission. The peer can authenticate the contents 343 of the UPDATE packet based on the signature and keyed hash of the 344 packet. 346 When using ESP Transport Format [5], the host may at the same time 347 decide to rekey its security association and possibly generate a new 348 Diffie-Hellman key; all of these actions are triggered by including 349 additional parameters in the UPDATE packet, as defined in the base 350 protocol specification [2] and ESP extension [5]. 352 When using ESP (and possibly other transport modes in the future), 353 the host is able to receive packets that are protected using a HIP 354 created ESP SA from any address. Thus, a host can change its IP 355 address and continue to send packets to its peers without necessarily 356 rekeying. However, the peers are not able to reply before they can 357 reliably and securely update the set of addresses that they associate 358 with the sending host. Furthermore, mobility may change the path 359 characteristics in such a manner that reordering occurs and packets 360 fall outside the ESP anti-replay window for the SA, thereby requiring 361 rekeying. 363 3.1.3. Multihoming overview 365 A related operational configuration is host multihoming, in which a 366 host has multiple locators simultaneously rather than sequentially as 367 in the case of mobility. By using the LOCATOR parameter defined 368 herein, a host can inform its peers of additional (multiple) locators 369 at which it can be reached, and can declare a particular locator as a 370 "preferred" locator. Although this document defines a mechanism for 371 multihoming, it does not define detailed policies and procedures such 372 as which locators to choose when more than one pair is available, the 373 operation of simultaneous mobility and multihoming, and the 374 implications of multihoming on transport protocols and ESP anti- 375 replay windows. Additional definition of HIP-based multihoming is 376 expected to be part of future documents. 378 3.2. Protocol Overview 380 In this section we briefly introduce a number of usage scenarios for 381 HIP mobility and multihoming. These scenarios assume that HIP is 382 being used with the ESP transform [5], although other scenarios may 383 be defined in the future. To understand these usage scenarios, the 384 reader should be at least minimally familiar with the HIP protocol 385 specification [2]. However, for the (relatively) uninitiated reader 386 it is most important to keep in mind that in HIP the actual payload 387 traffic is protected with ESP, and that the ESP SPI acts as an index 388 to the right host-to-host context. 390 Each of the scenarios below assumes that the HIP base exchange has 391 completed, and the hosts each have a single outbound SA to the peer 392 host. Associated with this outbound SA is a single destination 393 address of the peer host-- the source address used by the peer during 394 the base exchange. 396 The readdressing protocol is an asymmetric protocol where a mobile or 397 multihomed host informs a peer host about changes of IP addresses on 398 affected SPIs. The readdressing exchange is designed to be 399 piggybacked on existing HIP exchanges. The main packets on which the 400 LOCATOR parameters are expected to be carried are UPDATE packets. 401 However, some implementations may want to experiment with sending 402 LOCATOR parameters also on other packets, such as R1, I2, and NOTIFY. 404 Hosts that use link-local addresses as source addresses in their HIP 405 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 406 provide a globally routable address either in the initial handshake 407 or via the LOCATOR parameter. 409 3.2.1. Mobility with single SA pair (no rekeying) 411 A mobile host must sometimes change an IP address bound to an 412 interface. The change of an IP address might be needed due to a 413 change in the advertised IPv6 prefixes on the link, a reconnected PPP 414 link, a new DHCP lease, or an actual movement to another subnet. In 415 order to maintain its communication context, the host must inform its 416 peers about the new IP address. This first example considers the 417 case in which the mobile host has only one interface, IP address, a 418 single pair of SAs (one inbound, one outbound), and no rekeying 419 occurs on the SAs. We also assume that the new IP addresses are 420 within the same address family (IPv4 or IPv6) as the first address. 421 This is the simplest scenario, depicted in Figure 3. 423 Mobile Host Peer Host 425 UPDATE(ESP_INFO, LOCATOR, SEQ) 426 -----------------------------------> 427 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 428 <----------------------------------- 429 UPDATE(ACK, ECHO_RESPONSE) 430 -----------------------------------> 432 Figure 3: Readdress without rekeying, but with address check 433 1. The mobile host is disconnected from the peer host for a brief 434 period of time while it switches from one IP address to another. 435 Upon obtaining a new IP address, the mobile host sends a LOCATOR 436 parameter to the peer host in an UPDATE message. The UPDATE 437 message also contains an ESP_INFO parameter with the "Old SPI" 438 and "New SPI" parameters both set to the value of the pre- 439 existing incoming SPI; this ESP_INFO does not trigger a rekeying 440 event but is instead included for possible parameter-inspecting 441 middleboxes on the path. The LOCATOR parameter contains the new 442 IP address (Locator Type of "1", defined below) and a locator 443 lifetime. The mobile host waits for this UPDATE to be 444 acknowledged, and retransmits if necessary, as specified in the 445 base specification [2]. 447 2. The peer host receives the UPDATE, validates it, and updates any 448 local bindings between the HIP association and the mobile host's 449 destination address. The peer host MUST perform an address 450 verification by placing a nonce in the ECHO_REQUEST parameter of 451 hte UPDATE message sent back to the mobile host. It also 452 includes an ESP_INFO parameter with the "Old SPI" and "New SPI" 453 parameters both set to the value of the pre-existing incoming 454 SPI, and sends this UPDATE (with piggybacked acknowledgment) to 455 the mobile host at its new address. The peer MAY use the new 456 address immediately, but it MUST limit the amount of data it 457 sends to the address until address verification completes. 459 3. The mobile host completes the readdress by processing the UPDATE 460 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 461 host receives this ECHO_RESPONSE, it considers the new address to 462 be verified and can put it into full use. 464 While the peer host is verifying the new address, the new address is 465 marked as UNVERIFIED in the interim, and the old address is 466 DEPRECATED. Once the peer host has received a correct reply to its 467 UPDATE challenge, it marks the new address as ACTIVE and removes the 468 old address. 470 3.2.1.1. Mobility with single SA pair (mobile-initiated rekey) 472 The mobile host may decide to rekey the SAs at the same time that it 473 is notifying the peer of the new address. In this case, the above 474 procedure described in Figure 3 is slightly modified. The UPDATE 475 message sent from the mobile host includes an ESP_INFO with the "Old 476 SPI" set to the previous SPI, the "New SPI" set to the desired new 477 SPI value for the incoming SA, and the Keymat Index desired. 478 Optionally, the host may include a DIFFIE_HELLMAN parameter for a new 479 Diffie-Hellman key. The peer completes the request for rekey as is 480 normally done for HIP rekeying, except that the new address is kept 481 as UNVERIFIED until the UPDATE nonce challenge is received as 482 described above. Figure 4 illustrates this scenario. 484 Mobile Host Peer Host 486 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 487 -----------------------------------> 488 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 489 <----------------------------------- 490 UPDATE(ACK, ECHO_RESPONSE) 491 -----------------------------------> 493 Figure 4: Readdress with mobile-initiated rekey 495 3.2.1.2. Mobility with single SA pair (peer-initiated rekey) 497 A second variation of this basic mobility scenario covers the case in 498 which the mobile host does not attempt to rekey the existing SAs, but 499 the peer host decides to do so. This typically results in a four 500 packet exchange, as shown in Figure 5. The initial UPDATE packet 501 from the mobile host is the same as in the scenario for which there 502 is no rekey (Figure 3). The peer may decide to rekey, however, in 503 which case the subsequent three packets follow the normal rekeying 504 procedure described in the ESP specification [5], with the addition 505 of the ECHO_REQUEST and ECHO_RESPONSE nonce for verification of the 506 new address. 508 Mobile Host Peer Host 510 UPDATE(ESP_INFO, LOCATOR, SEQ) 511 -----------------------------------> 512 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN], ECHO_REQUEST) 513 <----------------------------------- 514 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_RESPONSE) 515 -----------------------------------> 516 UPDATE(ACK) 517 <----------------------------------- 519 Figure 5: Readdress with peer-initiated rekey 521 3.2.2. Host multihoming 523 A (mobile or stationary) host may sometimes have more than one 524 interface or global address. The host may notify the peer host of 525 the additional interface or address by using the LOCATOR parameter. 526 To avoid problems with the ESP anti-replay window, a host SHOULD use 527 a different SA for each interface or address used to receive packets 528 from the peer host. 530 When more than one locator is provided to the peer host, the host 531 SHOULD indicate which locator is preferred. By default, the 532 addresses used in the base exchange are preferred until indicated 533 otherwise. 535 Although the protocol may allow for configurations in which there is 536 an asymmetric number of SAs between the hosts (e.g., one host has two 537 interfaces and two inbound SAs, while the peer has one interface and 538 one inbound SA), it is RECOMMENDED that inbound and outbound SAs be 539 created pairwise between hosts. When an ESP_INFO arrives to rekey a 540 particular outbound SA, the corresponding inbound SA should be also 541 rekeyed at that time. Although asymmetric SA configurations might be 542 experimented with, their usage may constrain interoperability at this 543 time. However, it is recommended that implementations attempt to 544 support peers that prefer to use non-paired SAs. It is expected that 545 this section and behavior will be modified in future revisions of 546 this protocol, once the issue and its implications are better 547 understood. 549 Consider the case between two single-homed hosts, in which one of the 550 host notifies the peer of an additional address. It is RECOMMENDED 551 that the host set up a new SA pair for use on this new address. To 552 do this, the multihomed host sends a LOCATOR with an ESP_INFO, 553 indicating the request for a new SA by setting the "Old SPI" value to 554 zero, and the "New SPI" value to the newly created incoming SPI. A 555 Locator Type of "1" is used to associate the new address with the new 556 SPI. The LOCATOR parameter also contains a second Type 1 locator: 557 that of the original address and SPI. To simplify parameter 558 processing and avoid explicit protocol extensions to remove locators, 559 each LOCATOR parameter must list all locators in use on a connection 560 (a complete listing of inbound locators and SPIs for the host). The 561 multihomed host transitions to state REKEYING, waiting for a ESP_INFO 562 (new outbound SA) from the peer and an ACK of its own UPDATE. As in 563 the mobility case, the peer host must perform an address verification 564 before putting the new address into active use. Figure 6 illustrates 565 the basic packet exchange. 567 Multi-homed Host Peer Host 569 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 570 -----------------------------------> 571 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 572 <----------------------------------- 573 UPDATE(ACK, ECHO_RESPONSE) 574 -----------------------------------> 576 Figure 6: Basic multihoming scenario 577 When processing inbound LOCATORs that establish new security 578 associations on an interface with multiple addresses, a host uses the 579 destination address of the UPDATE containing LOCATOR as the local 580 address to which the LOCATOR plus ESP_INFO is targeted. Hosts may 581 send UPDATEs with the same IP address in the LOCATOR to different 582 peer addresses-- this has the effect of creating multiple inbound SAs 583 implicitly affiliated with different peer source addresses. 585 3.2.3. Site multihoming 587 A host may have an interface that has multiple globally reachable IP 588 addresses. Such a situation may be a result of the site having 589 multiple upper Internet Service Providers, or just because the site 590 provides all hosts with both IPv4 and IPv6 addresses. It is 591 desirable that the host can stay reachable with all or any subset of 592 the currently available globally routable addresses, independent on 593 how they are provided. 595 This case is handled the same as if there were different IP 596 addresses, described above in Section 3.2.2. Note that a single 597 interface may experience site multihoming while the host itself may 598 have multiple interfaces. 600 Note that a host may be multi-homed and mobile simultaneously, and 601 that a multi-homed host may want to protect the location of some of 602 its interfaces while revealing the real IP address of some others. 604 This document does not presently specify additional site multihoming 605 extensions to HIP; further alignment with the IETF shim6 working 606 group may be considered in the future. 608 3.2.4. Dual host multihoming 610 Consider the case in which both hosts would like to add an additional 611 address after the base exchange completes. In Figure 7, consider 612 that host1 wants to add address addr1b. It would send an UPDATE with 613 LOCATOR to host2 located at addr2a, and a new set of SPIs would be 614 added between hosts 1 and 2 (call them SPI1b and SPI2b). Next, 615 consider host2 deciding to add addr2b to the relationship. host2 now 616 has a choice to which of host1's addresses to initiate an UPDATE. It 617 may choose to initiate an UPDATE to addr1a, addr1b, or both. If it 618 chooses to send to both, then a full mesh (four SA pairs) of SAs 619 would exist between the two hosts. This is the most general case; it 620 often may be the case that hosts primarily establish new SAs only 621 with the peer's preferred locator. The readdressing protocol is 622 flexible enough to accommodate this choice. 624 -<- SPI1a -- -- SPI2a ->- 625 host1 < > addr1a <---> addr2a < > host2 626 ->- SPI2a -- -- SPI1a -<- 628 addr1b <---> addr2a (second SA pair) 629 addr1a <---> addr2b (third SA pair) 630 addr1b <---> addr2b (fourth SA pair) 632 Figure 7: Dual multihoming case in which each host uses LOCATOR to 633 add a second address 635 3.2.5. Combined mobility and multihoming 637 It looks likely that in the future many mobile hosts will be 638 simultaneously mobile and multi-homed, i.e., have multiple mobile 639 interfaces. Furthermore, if the interfaces use different access 640 technologies, it is fairly likely that one of the interfaces may 641 appear stable (retain its current IP address) while some other(s) may 642 experience mobility (undergo IP address change). 644 The use of LOCATOR plus ESP_INFO should be flexible enough to handle 645 most such scenarios, although more complicated scenarios have not 646 been studied so far. 648 3.2.6. Using LOCATORs across addressing realms 650 It is possible for HIP associations to migrate to a state in which 651 both parties are only using locators in different addressing realms. 652 For example, the two hosts may initiate the HIP association when both 653 are using IPv6 locators, then one host may loose its IPv6 654 connectivity and obtain an IPv4 address. In such a case, some type 655 of mechanism for interworking between the different realms must be 656 employed; such techniques are outside the scope of the present text. 657 If no mechanism exists, then the UPDATE message carrying the new 658 LOCATOR will likely not reach the destination anyway, and the HIP 659 state may time out. 661 3.2.7. Network renumbering 663 It is expected that IPv6 networks will be renumbered much more often 664 than most IPv4 networks are. From an end-host point of view, network 665 renumbering is similar to mobility. 667 3.2.8. Initiating the protocol in R1 or I2 669 A Responder host MAY include one or more LOCATOR parameters in the R1 670 packet that it sends to the Initiator. These parameters MUST be 671 protected by the R1 signature. If the R1 packet contains LOCATOR 672 parameters with a new preferred locator, the Initiator SHOULD 673 directly set the new preferred locator to status ACTIVE without 674 performing address verification first, and MUST send the I2 packet to 675 the new preferred locator. The I1 destination address and the new 676 preferred locator may be identical. All new non-preferred locators 677 must still undergo address verification. 679 Initiator Responder 681 R1 with LOCATOR 682 <----------------------------------- 683 record additional addresses 684 change responder address 685 I2 sent to newly indicated preferred address 686 -----------------------------------> 687 (process normally) 688 R2 689 <----------------------------------- 690 (process normally, later verification of non-preferred locators) 692 Figure 8: LOCATOR inclusion in R1 694 An Initiator MAY include one or more LOCATOR parameters in the I2 695 packet, independent of whether there was a LOCATOR parameter in the 696 R1 or not. These parameters MUST be protected by the I2 signature. 697 Even if the I2 packet contains LOCATOR parameters, the Responder MUST 698 still send the R2 packet to the source address of the I2. The new 699 preferred locator SHOULD be identical to the I2 source address. If 700 the I2 packet contains LOCATOR parameters, all new locators must 701 undergo address verification as usual. 703 Initiator Responder 705 I2 with LOCATOR 706 -----------------------------------> 707 (process normally) 708 record additional addresses 709 R2 sent to source address of I2 710 <----------------------------------- 711 (process normally) 713 Figure 9: LOCATOR inclusion in I2 715 3.3. Other Considerations 717 3.3.1. Address Verification 719 When a HIP host receives a set of locators from another HIP host in a 720 LOCATOR, it does not necessarily know whether the other host is 721 actually reachable at the claimed addresses. In fact, a malicious 722 peer host may be intentionally giving bogus addresses in order to 723 cause a packet flood towards the target addresses [8]. Likewise, 724 viral software may have compromised the peer host, programming it to 725 redirect packets to the target addresses. Thus, the HIP host must 726 first check that the peer is reachable at the new address. 728 An additional potential benefit of performing address verification is 729 to allow middleboxes in the network along the new path to obtain the 730 peer host's inbound SPI. 732 Address verification is implemented by the challenger sending some 733 piece of unguessable information to the new address, and waiting for 734 some acknowledgment from the responder that indicates reception of 735 the information at the new address. This may include exchange of a 736 nonce, or generation of a new SPI and observing data arriving on the 737 new SPI. 739 3.3.2. Credit-Based Authorization 741 Credit-Based Authorization allows a host to securely use a new 742 locator even though the peer's reachability at the address embedded 743 in this locator has not yet been verified. This is accomplished 744 based on the following three hypotheses: 746 1. A flooding attacker typically seeks to somehow multiply the 747 packets it generates itself for the purpose of its attack because 748 bandwidth is an ample resource for many attractive victims. 750 2. An attacker can always cause unamplified flooding by sending 751 packets to its victim directly. 753 3. Consequently, the additional effort required to set up a 754 redirection-based flooding attack would pay off for the attacker 755 only if amplification could be obtained this way. 757 On this basis, rather than eliminating malicious packet redirection 758 in the first place, Credit-Based Authorization prevents any 759 amplification that can be reached through it. This is accomplished 760 by limiting the data a host can send to an unverified address of a 761 peer by the data recently received from that peer. Redirection-based 762 flooding attacks thus become less attractive than, e.g., pure direct 763 flooding, where the attacker itself sends bogus packets to the 764 victim. 766 Figure 10 illustrates Credit-Based Authorization: Host B measures the 767 bytes recently received from peer A and, when A readdresses, sends 768 packets to A's new, unverified address as long as the sum of their 769 sizes does not exceed the measured, received data volume. When 770 insufficient credit is left, B stops sending further packets to A 771 until A's address becomes ACTIVE. The address changes may be due to 772 mobility, due to multihoming, or due to any other reason. 774 +-------+ +-------+ 775 | A | | B | 776 +-------+ +-------+ 777 | | 778 address |------------------------->| credit += size(packet) 779 ACTIVE | | 780 |------------------------->| credit += size(packet) 781 |<-------------------------| don't change credit 782 | | 783 + address change | 784 address |<-------------------------| credit -= size(packet) 785 UNVERIFIED |------------------------->| credit += size(packet) 786 |<-------------------------| credit -= size(packet) 787 | | 788 |<-------------------------| credit -= size(packet) 789 | X credit < size(packet)=> drop! 790 | | 791 + address change | 792 address | | 793 ACTIVE |<-------------------------| don't change credit 794 | | 796 Figure 10: Readdressing Scenario 798 3.3.3. Preferred locator 800 When a host has multiple locators, the peer host must decide upon 801 which to use for outbound packets. It may be that a host would 802 prefer to receive data on a particular inbound interface. HIP allows 803 a particular locator to be designated as a preferred locator, and 804 communicated to the peer (see Section 4). 806 In general, when multiple locators are used for a session, there is 807 the question of using multiple locators for failover only or for 808 load-balancing. Due to the implications of load-balancing on the 809 transport layer that still need to be worked out, this draft assumes 810 that multiple locators are used primarily for failover. An 811 implementation may use ICMP interactions, reachability checks, or 812 other means to detect the failure of a locator. 814 3.3.4. Interaction with Security Associations 816 This document specifies a new HIP protocol parameter, the LOCATOR 817 parameter (see Section 4), that allows the hosts to exchange 818 information about their locator(s), and any changes in their 819 locator(s). The logical structure created with LOCATOR parameters 820 has three levels: hosts, Security Associations (SAs) indexed by 821 Security Parameter Indices (SPIs), and addresses. 823 The relation between these entities for an association negotiated as 824 defined in the base specification [2] and ESP transform [5] is 825 illustrated in Figure 11. 827 -<- SPI1a -- -- SPI2a ->- 828 host1 < > addr1a <---> addr2a < > host2 829 ->- SPI2a -- -- SPI1a -<- 831 Figure 11: Relation between hosts, SPIs, and addresses (base 832 specification) 834 In Figure 11, host1 and host2 negotiate two unidirectional SAs, and 835 each host selects the SPI value for its inbound SA. The addresses 836 addr1a and addr2a are the source addresses that each host uses in the 837 base HIP exchange. These are the "preferred" (and only) addresses 838 conveyed to the peer for each SA; even though packets sent to any of 839 the hosts' interfaces can arrive on an inbound SPI, when a host sends 840 packets to the peer on an outbound SPI, it knows of a single 841 destination address associated with that outbound SPI (for host1, it 842 sends a packet on SPI2a to addr2a to reach host2), unless other 843 mechanisms exist to learn of new addresses. 845 In general, the bindings that exist in an implementation 846 corresponding to this draft can be depicted as shown in Figure 12. 847 In this figure, a host can have multiple inbound SPIs (and, not 848 shown, multiple outbound SPIs) between itself and another host. 849 Furthermore, each SPI may have multiple addresses associated with it. 850 These addresses bound to an SPI are not used as SA selectors. 851 Rather, the addresses are those addresses that are provided to the 852 peer host, as hints for which addresses to use to reach the host on 853 that SPI. The LOCATOR parameter allows for IP addresses and SPIs to 854 be combined to form generalized locators. The LOCATOR parameter is 855 used to change the set of addresses that a peer associates with a 856 particular SPI. 858 address11 859 / 860 SPI1 - address12 861 / 862 / address21 863 host -- SPI2 < 864 \ address22 865 \ 866 SPI3 - address31 867 \ 868 address32 870 Figure 12: Relation between hosts, SPIs, and addresses (general case) 872 A host may establish any number of security associations (or SPIs) 873 with a peer. The main purpose of having multiple SPIs is to group 874 the addresses into collections that are likely to experience fate 875 sharing. For example, if the host needs to change its addresses on 876 SPI2, it is likely that both address21 and address22 will 877 simultaneously become obsolete. In a typical case, such SPIs may 878 correspond with physical interfaces; see below. Note, however, that 879 especially in the case of site multihoming, one of the addresses may 880 become unreachable while the other one still works. In the typical 881 case, however, this does not require the host to inform its peers 882 about the situation, since even the non-working address still 883 logically exists. 885 A basic property of HIP SAs is that the inbound IP address is not 886 used as a selector for the SA. Therefore, in Figure 12, it may seem 887 unnecessary for address31, for example, to be associated only with 888 SPI3-- in practice, a packet may arrive to SPI1 via destination 889 address address31 as well. However, the use of different source and 890 destination addresses typically leads to different paths, with 891 different latencies in the network, and if packets were to arrive via 892 an arbitrary destination IP address (or path) for a given SPI, the 893 reordering due to different latencies may cause some packets to fall 894 outside of the ESP anti-replay window. For this reason, HIP provides 895 a mechanism to affiliate destination addresses with inbound SPIs, if 896 there is a concern that anti-replay windows might be violated 897 otherwise. In this sense, we can say that a given inbound SPI has an 898 "affinity" for certain inbound IP addresses, and this affinity is 899 communicated to the peer host. Each physical interface SHOULD have a 900 separate SA, unless the ESP anti-replay window is loose. 902 Moreover, even if the destination addresses used for a particular SPI 903 are held constant, the use of different source interfaces may also 904 cause packets to fall outside of the ESP anti-replay window, since 905 the path traversed is often affected by the source address or 906 interface used. A host has no way to influence the source interface 907 on which a peer uses to send its packets on a given SPI. Hosts 908 SHOULD consistently use the same source interface and address when 909 sending to a particular destination IP address and SPI. For this 910 reason, a host may find it useful to change its SPI or at least reset 911 its ESP anti-replay window when the peer host readdresses. 913 An address may appear on more than one SPI. This creates no 914 ambiguity since the receiver will ignore the IP addresses as SA 915 selectors anyway. However, this document does not specify such 916 cases. 918 If the LOCATOR parameter is sent in an UPDATE packet, then the 919 receiver will respond with an UPDATE acknowledgment. If the LOCATOR 920 parameter is sent in a NOTIFY, I2, or R2 packet, then the recipient 921 may consider the LOCATOR as informational, and act only when it needs 922 to activate a new address. The use of LOCATOR in a NOTIFY message 923 may not be compatible with middleboxes. 925 4. LOCATOR parameter format 927 The LOCATOR parameter is a critical parameter as defined by [2]. It 928 consists of the standard HIP parameter Type and Length fields, plus 929 one or more Locator sub-parameters. Each Locator sub-parameter 930 contains a Traffic Type, Locator Type, Locator Length, Preferred 931 Locator bit, Locator Lifetime, and a Locator encoding. 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Type | Length | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Traffic Type | Locator Type | Locator Length | Reserved |P| 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Locator Lifetime | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Locator | 943 | | 944 | | 945 | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 . . 948 . . 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Traffic Type | Locator Type | Locator Length | Reserved |P| 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Locator Lifetime | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Locator | 955 | | 956 | | 957 | | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 Type: 193 962 Length: Length in octets, excluding Type and Length fields, and 963 excluding padding. 965 Traffic Type: Defines whether the locator pertains to HIP signaling, 966 user data, or both. 968 Locator Type: Defines the semantics of the Locator field. 970 Locator Length: Defines the length of the Locator field, in units of 971 4-byte words (Locators up to a maximum of 4*255 bytes are 972 supported). 974 Reserved: Zero when sent, ignored when received. 976 P: Preferred locator. Set to one if the locator is preferred for 977 that Traffic Type; otherwise set to zero. 979 Locator Lifetime: Locator lifetime, in seconds. 981 Locator: The locator whose semantics and encoding are indicated by 982 the Locator Type field. All Locator sub-fields are integral 983 multiples of four bytes in length. 985 The Locator Lifetime indicates how long the following locator is 986 expected to be valid. The lifetime is expressed in seconds. Each 987 locator MUST have a non-zero lifetime. The address is expected to 988 become deprecated when the specified number of seconds has passed 989 since the reception of the message. A deprecated address SHOULD NOT 990 be used as an destination address if an alternate (non-deprecated) is 991 available and has sufficient scope. 993 4.1. Traffic Type and Preferred Locator 995 The following Traffic Type values are defined: 997 0: Both signaling (HIP control packets) and user data. 999 1: Signaling packets only. 1001 2: Data packets only. 1003 The "P" bit, when set, has scope over the corresponding Traffic Type 1004 that precedes it. That is, if a "P" bit is set for Traffic Type "2", 1005 for example, that means that the locator is preferred for data 1006 packets. If there is a conflict (for example, if P bit is set for an 1007 address of Type "0" and a different address of Type "2"), the more 1008 specific Traffic Type rule applies. By default, the IP addresses 1009 used in the base exchange are preferred locators for both signaling 1010 and user data, unless a new preferred locator supersedes them. If no 1011 locators are indicated as preferred for a given Traffic Type, the 1012 implementation may use an arbitrary locator from the set of active 1013 locators. 1015 4.2. Locator Type and Locator 1017 The following Locator Type values are defined, along with the 1018 associated semantics of the Locator field: 1020 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128 1021 bits long). 1023 1: The concatenation of an ESP SPI (first 32 bits) followed by an 1024 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 1025 128 bits). 1027 4.3. UPDATE packet with included LOCATOR 1029 A number of combinations of parameters in an UPDATE packet are 1030 possible (e.g., see Section 3.2). Only one LOCATOR parameter is used 1031 in any HIP packet, and this LOCATOR SHOULD list all of the locators 1032 that the host wishes to make available for the HIP association. Any 1033 UPDATE packet that includes a LOCATOR parameter SHOULD include both 1034 an HMAC and a HIP_SIGNATURE parameter. 1036 5. Processing rules 1038 5.1. Locator data structure and status 1040 In a typical implementation, each outgoing locator is represented by 1041 a piece of state that contains the following data: 1043 o the actual bit pattern representing the locator, 1045 o lifetime (seconds), 1047 o status (UNVERIFIED, ACTIVE, DEPRECATED). 1049 The status is used to track the reachability of the address embedded 1050 within the LOCATOR parameter: 1052 UNVERIFIED indicates that the reachability of the address has not 1053 been verified yet, 1055 ACTIVE indicates that the reachability of the address has been 1056 verified and the address has not been deprecated, 1058 DEPRECATED indicates that the locator lifetime has expired 1060 The following state changes are allowed: 1062 UNVERIFIED to ACTIVE The reachability procedure completes 1063 successfully. 1065 UNVERIFIED to DEPRECATED The locator lifetime expires while it is 1066 UNVERIFIED. 1068 ACTIVE to DEPRECATED The locator lifetime expires while it is ACTIVE. 1070 ACTIVE to UNVERIFIED There has been no traffic on the address for 1071 some time, and the local policy mandates that the address 1072 reachability must be verified again before starting to use it 1073 again. 1075 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 1076 locator. 1078 A DEPRECATED address MUST NOT be changed to ACTIVE without first 1079 verifying its reachability. 1081 5.2. Sending LOCATORs 1083 The decision of when to send LOCATORs is basically a local policy 1084 issue. However, it is RECOMMENDED that a host sends a LOCATOR 1085 whenever it recognizes a change of its IP addresses in use on an 1086 active HIP association, and assumes that the change is going to last 1087 at least for a few seconds. Rapidly sending conflicting LOCATORs 1088 SHOULD be avoided. 1090 When a host decides to inform its peers about changes in its IP 1091 addresses, it has to decide how to group the various addresses with 1092 SPIs. The grouping should consider also whether middlebox 1093 interaction requires sending (the same) LOCATOR in separate UPDATEs 1094 on different paths. Since each SPI is associated with a different 1095 Security Association, the grouping policy may also be based on ESP 1096 anti-replay protection considerations. In the typical case, simply 1097 basing the grouping on actual kernel level physical and logical 1098 interfaces may be the best policy. Grouping policy is outside of the 1099 scope of this document. 1101 Note that the purpose of announcing IP addresses in a LOCATOR is to 1102 provide connectivity between the communicating hosts. In most cases, 1103 tunnels or virtual interfaces such as IPsec tunnel interfaces or 1104 Mobile IP home addresses provide sub-optimal connectivity. 1105 Furthermore, it should be possible to replace most tunnels with HIP 1106 based "non-tunneling", therefore making most virtual interfaces 1107 fairly unnecessary in the future. Therefore, virtual interfaces 1108 SHOULD NOT be announced in general. On the other hand, there are 1109 clearly situations where tunnels are used for diagnostic and/or 1110 testing purposes. In such and other similar cases announcing the IP 1111 addresses of virtual interfaces may be appropriate. 1113 Once the host has decided on the groups and assignment of addresses 1114 to the SPIs, it creates a LOCATOR parameter that serves as a complete 1115 representation of the addresses and affiliated SPIs intended for 1116 active use. We now describe a few cases introduced in Section 3.2. 1117 We assume that the Traffic Type for each locator is set to "0" (other 1118 values for Traffic Type may be specified in documents that separate 1119 HIP control plane from data plane traffic). Other mobility and 1120 multihoming cases are possible but are left for further 1121 experimentation. 1123 1. Host mobility with no multihoming and no rekeying. The mobile 1124 host creates a single UPDATE containing a single ESP_INFO with a 1125 single LOCATOR parameter. The ESP_INFO contains the current 1126 value of the SPI in both the "Old SPI" and "New SPI" fields. The 1127 LOCATOR contains a single Locator with a "Locator Type" of "1"; 1128 the SPI must match that of the ESP_INFO. The Preferred bit 1129 SHOULD be set and the "Locator Lifetime" is set according to 1130 local policy. The UPDATE also contains a SEQ parameter as usual 1131 and is protected by retransmission. The UPDATE should be sent to 1132 the peer's preferred IP address with an IP source address 1133 corresponding to the address in the LOCATOR parameter. 1135 2. Host mobility with no multihoming but with rekeying. The mobile 1136 host creates a single UPDATE containing a single ESP_INFO with a 1137 single LOCATOR parameter (with a single address). The ESP_INFO 1138 contains the current value of the SPI in the "Old SPI" and the 1139 new value of the SPI in the "New SPI", and a "Keymat Index" as 1140 selected by local policy. Optionally, the host may choose to 1141 initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN 1142 parameter. The LOCATOR contains a single Locator with "Locator 1143 Type" of "1"; the SPI must match that of the "New SPI" in the 1144 ESP_INFO. Otherwise, the steps are identical to the case when no 1145 rekeying is initiated. 1147 3. Host multihoming (addition of an address). We only describe the 1148 simple case of adding an additional address to a single-homed, 1149 non-mobile host. The host SHOULD set up a new SA pair between 1150 this new address and the preferred address of the peer host. To 1151 do this, the multihomed host creates a new inbound SA and creates 1152 a new ESP_INFO parameter with an "Old SPI" parameter of "0", a 1153 "New SPI" parameter corresponding to the new SPI, and a "Keymat 1154 Index" as selected by local policy. The host adds to the UPDATE 1155 message a LOCATOR with two Type "1" Locators: the original 1156 address and SPI active on the association, and the new address 1157 and new SPI being added (with the SPI matching the "New SPI" 1158 contained in the ESP_INFO). The Preferred bit SHOULD be set 1159 depending on the policy to tell the peer host which of the two 1160 locators is preferred. The UPDATE also contains a SEQ parameter 1161 and optionally a DIFFIE_HELLMAN parameter, and follows rekeying 1162 procedures with respect to this new address. The UPDATE message 1163 SHOULD be sent to the peer's preferred address with a source 1164 address corresponding to the new locator. 1166 The sending of multiple LOCATORs, locators with Locator Type "0", and 1167 multiple ESP_INFO parameters is for further study. 1169 5.3. Handling received LOCATORs 1171 A host SHOULD be prepared to receive a LOCATOR parameter in any HIP 1172 packet, excluding I1. 1174 This document describes sending both ESP_INFO and LOCATOR parameters 1175 in an UPDATE. The ESP_INFO parameter is included if there is a need 1176 to rekey or key a new SPI, and is otherwise included for the possible 1177 benefit of HIP-aware middleboxes. The LOCATOR parameter contains a 1178 complete map of the locators that the host wishes to make or keep 1179 active for the HIP association. 1181 In general, the processing of a LOCATOR depends upon the packet type 1182 in which it is included and upon whether ESP_INFO parameter is 1183 included. Here, we describe only the case in which ESP_INFO is 1184 present and a single LOCATOR and ESP_INFO are sent in an UPDATE 1185 message; other cases are for further study. The steps below cover 1186 each of the cases described in Section 5.2. 1188 When a host receives a LOCATOR parameter in a validated HIP packet, 1189 it first performs the following operations: 1191 1. The host checks if the New SPI listed in the ESP_INFO is a new 1192 one. If it is a new one, it creates a new inbound SA with that 1193 SPI that contains no addresses. If it is an existing one, it 1194 prepares to change the address set on the existing SPI. 1196 2. For each locator listed in the LOCATOR parameter, check that the 1197 address therein is a legal unicast or anycast address. That is, 1198 the address MUST NOT be a broadcast or multicast address. Note 1199 that some implementations MAY accept addresses that indicate the 1200 local host, since it may be allowed that the host runs HIP with 1201 itself. 1203 3. For each Type 1 address listed in the LOCATOR parameter, check if 1204 the address is already bound to the SPI indicated. If the 1205 address is already bound, its lifetime is updated. If the status 1206 of the address is DEPRECATED, the status is changed to 1207 UNVERIFIED. If the address is not already bound, the address is 1208 added, and its status is set to UNVERIFIED. Mark all addresses 1209 on the SPI that were NOT listed in the LOCATOR parameter as 1210 DEPRECATED. As a result, the SPI now contains any addresses 1211 listed in the LOCATOR parameter either as UNVERIFIED or ACTIVE, 1212 and any old addresses not listed in the LOCATOR parameter as 1213 DEPRECATED. 1215 4. If the LOCATOR is paired with an ESP_INFO parameter, the ESP_INFO 1216 parameter is processed as follows: 1218 1. If the Old SPI indicates an existing SPI and the New SPI is a 1219 different non-zero value, the existing SA is being rekeyed 1220 and the host follows HIP ESP rekeying procedures. Note that 1221 the Locators in the LOCATOR parameter will use this New SPI 1222 instead of the Old SPI. 1224 2. If the Old SPI value is zero and the New SPI is a new non- 1225 zero value, then a new SA is being requested by the peer. 1226 This case is also treated like a rekeying event; the 1227 receiving host must create a new inbound SA and respond with 1228 an UPDATE ACK. 1230 3. If the Old SPI indicates an existing SPI and the New SPI is 1231 zero, the SPI is being deprecated and all locators uniquely 1232 bound to the SPI are put into DEPRECATED state. 1234 4. If the Old SPI equals the New SPI and both correspond to an 1235 existing SPI, the ESP_INFO is gratuitous (provided for 1236 middleboxes) and no rekeying is necessary. 1238 5. Mark all locators on each SPI that were NOT listed in the LOCATOR 1239 parameter as DEPRECATED. 1241 As a result, each SPI now contains any addresses listed in the 1242 LOCATOR parameter either as UNVERIFIED or ACTIVE, and any old 1243 addresses not listed in the LOCATOR parameter as DEPRECATED. 1245 Once the host has updated the SPI, if the LOCATOR parameter contains 1246 a new preferred locator, the host SHOULD initiate a change of the 1247 preferred locator. This requires that the host first verifies 1248 reachability of the associated address, and only then changes the 1249 preferred locator. See Section 5.6. 1251 5.4. Verifying address reachability 1253 A host MUST verify the reachability of an UNVERIFIED address. The 1254 status of a newly learned address MUST initially be set to UNVERIFIED 1255 unless the new address is advertised in a R1 packet as a new 1256 preferred locator. A host MAY also want to verify the reachability 1257 of an ACTIVE address again after some time, in which case it would 1258 set the status of the address to UNVERIFIED and reinitiate address 1259 verification 1261 A host typically starts the address-verification procedure by sending 1262 a nonce to the new address. For example, if the host is changing its 1263 SPI and is sending an ESP_INFO to the peer, the new SPI value SHOULD 1264 be random and the value MAY be copied into an ECHO_REQUEST sent in 1265 the rekeying UPDATE. If the host is not rekeying, it MAY still use 1266 the ECHO_REQUEST parameter in an UPDATE message sent to the new 1267 address. A host MAY also use other message exchanges as confirmation 1268 of the address reachability. 1270 Note that in the case of receiving a LOCATOR on an R1 and replying 1271 with an I2, receiving the corresponding R2 is sufficient proof of 1272 reachability for the Responder's preferred address. Since further 1273 address verification of such address can impede the HIP base 1274 exchange, a host MUST NOT verify reachability of a new preferred 1275 locator that was received on a R1. 1277 In some cases, it may be sufficient to use the arrival of data on a 1278 newly advertised SA as implicit address reachability verification, 1279 instead of waiting for the confirmation via a HIP packet (e.g., 1280 Figure 14). In this case, a host advertising a new SPI as part of 1281 its address reachability check SHOULD be prepared to receive traffic 1282 on the new SA. Marking the address ACTIVE as a part of receiving 1283 data on the SA is an idempotent operation, and does not cause any 1284 harm. 1286 Mobile host Peer host 1288 prepare incoming SA 1289 new SPI in R2, or UPDATE 1290 <----------------------------------- 1291 switch to new outgoing SA 1292 data on new SA 1293 -----------------------------------> 1294 mark address ACTIVE 1296 Figure 14: Address activation via use of new SA 1298 When address verification is in progress for a new preferred locator, 1299 the host SHOULD select a different locator listed as ACTIVE, if one 1300 such locator is available, to continue communications until address 1301 verification completes. Alternatively, the host MAY use the new 1302 preferred locator while in UNVERIFIED status to the extent Credit- 1303 Based Authorization permits. Credit-Based Authorization is explained 1304 in Section 5.5. Once address verification succeeds, the status of 1305 the new preferred locator changes to ACTIVE. 1307 5.5. Credit-Based Authorization 1309 5.5.1. Handling Payload Packets 1311 A host maintains a "credit counter" for each of its peers. Whenever 1312 a packet arrives from a peer, the host SHOULD increase that peer's 1313 credit counter by the size of the received packet. When the host has 1314 a packet to be sent to the peer, if the peers preferred locator is 1315 listed as UNVERIFIED and no alternative locator with status ACTIVE is 1316 available, the host checks whether it can send the packet to the 1317 UNVERIFIED locator: The packet SHOULD be sent if the value of the 1318 credit counter is higher than the size of the outbound packet. If 1319 the credit counter is too low, the packet MUST be discarded or 1320 buffered until address verification succeeds. When a packet is sent 1321 to a peer at an UNVERIFIED locator, the peer's credit counter MUST be 1322 reduced by the size of the packet. The peer's credit counter is not 1323 affected by packets that the host sends to an ACTIVE locator of that 1324 peer. 1326 Figure 15 depicts the actions taken by the host when a packet is 1327 received. Figure 16 shows the decision chain in the event a packet 1328 is sent. 1330 Inbound 1331 packet 1332 | 1333 | +----------------+ +---------------+ 1334 | | Increase | | Deliver | 1335 +-----> | credit counter |-------------> | packet to | 1336 | by packet size | | application | 1337 +----------------+ +---------------+ 1339 Figure 15: Receiving Packets with Credit-Based Authorization 1340 Outbound 1341 packet 1342 | _________________ 1343 | / \ +---------------+ 1344 | / Is the preferred \ No | Send packet | 1345 +-----> | destination address |-------------> | to preferred | 1346 \ UNVERIFIED? / | address | 1347 \_________________/ +---------------+ 1348 | 1349 | Yes 1350 | 1351 v 1352 _________________ 1353 / \ +---------------+ 1354 / Does an ACTIVE \ Yes | Send packet | 1355 | destination address |-------------> | to ACTIVE | 1356 \ exist? / | address | 1357 \_________________/ +---------------+ 1358 | 1359 | No 1360 | 1361 v 1362 _________________ 1363 / \ +---------------+ 1364 / Credit counter \ No | | 1365 | >= |-------------> | Drop packet | 1366 \ packet size? / | | 1367 \_________________/ +---------------+ 1368 | 1369 | Yes 1370 | 1371 v 1372 +---------------+ +---------------+ 1373 | Reduce credit | | Send packet | 1374 | counter by |----------------> | to preferred | 1375 | packet size | | address | 1376 +---------------+ +---------------+ 1378 Figure 16: Sending Packets with Credit-Based Authorization 1380 5.5.2. Credit Aging 1382 A host ensures that the credit counters it maintains for its peers 1383 gradually decrease over time. Such "credit aging" prevents a 1384 malicious peer from building up credit at a very slow speed and using 1385 this, all at once, for a severe burst of redirected packets. 1387 Credit aging may be implemented by multiplying credit counters with a 1388 factor, CreditAgingFactor, less than one in fixed time intervals of 1389 CreditAgingInterval length. Choosing appropriate values for 1390 CreditAgingFactor and CreditAgingInterval is important to ensure that 1391 a host can send packets to an address in state UNVERIFIED even when 1392 the peer sends at a lower rate than the host itself. When 1393 CreditAgingFactor or CreditAgingInterval are too small, the peer's 1394 credit counter might be too low to continue sending packets until 1395 address verification concludes. 1397 The parameter values proposed in this document are as follows: 1399 CreditAgingFactor 7/8 1400 CreditAgingInterval 5 seconds 1402 These parameter values work well when the host transfers a file to 1403 the peer via a TCP connection and the end-to-end round-trip time does 1404 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1405 use other parameter values or different parameters, which may even be 1406 dynamically established. 1408 5.6. Changing the preferred locator 1410 A host MAY want to change the preferred outgoing locator for 1411 different reasons, e.g., because traffic information or ICMP error 1412 messages indicate that the currently used preferred address may have 1413 become unreachable. Another reason may be due to receiving a LOCATOR 1414 parameter that has the P-bit set. 1416 To change the preferred locator, the host initiates the following 1417 procedure: 1419 1. If the new preferred locator has ACTIVE status, the preferred 1420 locator is changed and the procedure succeeds. 1422 2. If the new preferred locator has UNVERIFIED status, the host 1423 starts to verify its reachability. The host SHOULD use a 1424 different locator listed as ACTIVE until address verification 1425 completes if one such locator is available. Alternatively, the 1426 host MAY use the new preferred locator, even though in UNVERIFIED 1427 status, to the extent Credit-Based Authorization permits. Once 1428 address verification succeeds, the status of the new preferred 1429 locator changes to ACTIVE and its use is no longer governed by 1430 Credit-Based Authorization. 1432 3. If the peer host has not indicated a preference for any address, 1433 then the host picks one of the peer's ACTIVE addresses randomly 1434 or according to policy. This case may arise if, for example, 1435 ICMP error messages arrive that deprecate the preferred locator, 1436 but the peer has not yet indicated a new preferred locator. 1438 4. If the new preferred locator has DEPRECATED status and there is 1439 at least one non-deprecated address, the host selects one of the 1440 non-deprecated addresses as a new preferred locator and 1441 continues. If the selected address is UNVERIFIED, this includes 1442 address verification as described above. 1444 6. Security Considerations 1446 The HIP mobility mechanism provides a secure means of updating a 1447 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1448 cryptographically verifies the sender of an UPDATE, so forging or 1449 replaying a HIP UPDATE packet is very difficult (see [2]). 1450 Therefore, security issues reside in other attack domains. The two 1451 we consider are malicious redirection of legitimate connections as 1452 well as redirection-based flooding attacks using this protocol. This 1453 can be broken down into the following: 1455 Impersonation attacks 1457 - direct conversation with the misled victim 1459 - man-in-the-middle attack 1461 DoS attacks 1463 - flooding attacks (== bandwidth-exhaustion attacks) 1465 * tool 1: direct flooding 1467 * tool 2: flooding by zombies 1469 * tool 2: redirection-based flooding 1471 - memory-exhaustion attacks 1473 - computational exhaustion attacks 1475 We consider these in more detail in the following sections. 1477 In Section 6.1 and Section 6.2, we assume that all users are using 1478 HIP. In Section 6.3 we consider the security ramifications when we 1479 have both HIP and non-HIP users. 1481 6.1. Impersonation attacks 1483 An attacker wishing to impersonate will try to mislead its victim 1484 into directly communicating with them, or carry out a man in the 1485 middle attack between the victim and the victim's desired 1486 communication peer. Without mobility support, both attack types are 1487 possible only if the attacker resides on the routing path between its 1488 victim and the victim's desired communication peer, or if the 1489 attacker tricks its victim into initiating the connection over an 1490 incorrect routing path (e.g., by acting as a router or using spoofed 1491 DNS entries). 1493 The HIP extensions defined in this specification change the situation 1494 in that they introduce an ability to redirect a connection (like 1495 IPv6), both before and after establishment. If no precautionary 1496 measures are taken, an attacker could misuse this feature to 1497 impersonate a victim's peer from any arbitrary location. The 1498 authentication and authorization mechanisms of the HIP base exchange 1499 [2] and the signatures in the UPDATE message prevent this attack. 1500 Furthermore, ownership of a HIP association is securely linked to a 1501 HIP HI/HIT. If an attacker somehow uses a bug in the implementation 1502 or weakness in some protocol to redirect a HIP connection, the 1503 original owner can always reclaim their connection (they can always 1504 prove ownership of the private key associated with their public HI). 1506 MitM attacks are always possible if the attacker is present during 1507 the initial HIP base exchange and if the hosts do not authenticate 1508 each other's identities, but once the base exchange has taken place 1509 even a MitM cannot steal an opportunistic HIP connection because it 1510 is very difficult for an attacker to create an UPDATE packet (or any 1511 HIP packet) that will be accepted as a legitimate update. UPDATE 1512 packets use HMAC and are signed. Even when an attacker can snoop 1513 packets to obtain the SPI and HIT/HI, they still cannot forge an 1514 UPDATE packet without knowledge of the secret keys. 1516 6.2. Denial of Service attacks 1518 6.2.1. Flooding Attacks 1520 The purpose of a denial-of-service attack is to exhaust some resource 1521 of the victim such that the victim ceases to operate correctly. A 1522 denial-of-service attack can aim at the victim's network attachment 1523 (flooding attack), its memory, or its processing capacity. In a 1524 flooding attack the attacker causes an excessive number of bogus or 1525 unwanted packets to be sent to the victim, which fills their 1526 available bandwidth. Note that the victim does not necessarily need 1527 to be a node; it can also be an entire network. The attack basically 1528 functions the same way in either case. 1530 An effective DoS strategy is distributed denial of service (DDoS). 1531 Here, the attacker conventionally distributes some viral software to 1532 as many nodes as possible. Under the control of the attacker, the 1533 infected nodes, or "zombies", jointly send packets to the victim. 1534 With such an 'army', an attacker can take down even very high 1535 bandwidth networks/victims. 1537 With the ability to redirect connections, an attacker could realize a 1538 DDoS attack without having to distribute viral code. Here, the 1539 attacker initiates a large download from a server, and subsequently 1540 redirects this download to its victim. The attacker can repeat this 1541 with multiple servers. This threat is mitigated through reachability 1542 checks and credit-based authorization. Both strategies do not 1543 eliminate flooding attacks per se, but they preclude: (i) their use 1544 from a location off the path towards the flooded victim; and (ii) any 1545 amplification in the number and size of the redirected packets. As a 1546 result, the combination of a reachability check and credit-based 1547 authorization makes a HIP redirection-based flooding attack as 1548 effective and applicable as a normal, direct flooding attack in which 1549 the attacker itself sends the flooding traffic to the victim. 1551 This analysis leads to the following two points. First, when a 1552 reachability packet is received, this nonce packet MUST be ignored if 1553 the HIT is not one that is currently active. Second, if the attacker 1554 is a MitM and can capture this nonce packet then it can respond to 1555 it, in which case it is possible for an attacker to redirect the 1556 connection. Note, this attack will always be possible when a 1557 reachability packet is not sent. 1559 6.2.2. Memory/Computational exhaustion DoS attacks 1561 We now consider whether or not the proposed extensions to HIP add any 1562 new DoS attacks (consideration of DoS attacks using the base HIP 1563 exchange and updates is discussed in [2]). A simple attack is to 1564 send many UPDATE packets containing many IP addresses that are not 1565 flagged as preferred. The attacker continues to send such packets 1566 until the number of IP addresses associated with the attacker's HI 1567 crashes the system. Therefore, there SHOULD be a limit to the number 1568 of IP addresses that can be associated with any HI. Other forms of 1569 memory/computationally exhausting attacks via the HIP UPDATE packet 1570 are handled in the base HIP draft [2]. 1572 6.3. Mixed deployment environment 1574 We now assume an environment with both HIP and non-HIP aware hosts. 1575 Four cases exist. 1577 1. A HIP user redirects their connection onto a non-HIP user. The 1578 non-HIP user will drop the reachability packet so this is not a 1579 threat unless the HIP user is a MitM and can respond to the 1580 reachability packet. 1582 2. A non-HIP user attempts to redirect their connection onto a HIP 1583 user. This falls into IPv4 and IPv6 security concerns, which are 1584 outside the scope of this document. 1586 3. A non-HIP user attempts to steal a HIP user's session (assume 1587 that Secure Neighbor Discovery is not active for the following). 1588 The non-HIP user contacts the service that a HIP user has a 1589 connection with and then attempts to use a IPv6 change of address 1590 request to steal the HIP user's connection. What will happen in 1591 this case is implementation dependent but such a request should 1592 be ignored/dropped. Even if the attack is successful, the HIP 1593 user can reclaim its connection via HIP. 1595 4. A HIP user attempts to steal a non-HIP user's session. This 1596 could be problematic since HIP sits 'on top of' layer 3. A HIP 1597 user could spoof the non-HIP user's IP address during the base 1598 exchange or set the non-HIP user's IP address as their preferred 1599 address via an UPDATE. Other possibilities exist but a simple 1600 solution is to add a check which does not allow any HIP session 1601 to be moved to or created upon an already existing IP address. 1603 7. IANA Considerations 1605 This document defines a LOCATOR parameter for the Host Identity 1606 Protocol [2]. This parameter is defined in Section 4 with a Type of 1607 193. 1609 8. Authors 1611 Pekka Nikander originated this Internet Draft. Tom Henderson, Jari 1612 Arkko, Greg Perkins, and Christian Vogt have each contributed 1613 sections to this draft. 1615 9. Acknowledgments 1617 The authors thank Mika Kousa, Jeff Ahrenholz, and Jan Melen for many 1618 improvements to the draft. 1620 10. References 1622 10.1. Normative references 1624 [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1625 Architecture", draft-ietf-hip-arch-03 (work in progress), 1626 August 2005. 1628 [2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 1629 (work in progress), October 2005. 1631 [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1632 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in progress), 1633 October 2005. 1635 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1636 December 2005. 1638 [5] Jokela, P., "Using ESP transport format with HIP", 1639 draft-ietf-hip-esp-01 (work in progress), October 2005. 1641 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1642 Levels", BCP 14, RFC 2119, March 1997. 1644 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 1645 Architecture", RFC 2373, July 1998. 1647 10.2. Informative references 1649 [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1650 Nordmark, "Mobile IP Version 6 Route Optimization Security 1651 Design Background", RFC 4225, December 2005. 1653 Appendix A. Changes from previous versions 1655 A.1. From nikander-hip-mm-00 to nikander-hip-mm-01 1657 The actual protocol has been largely revised, based on the new 1658 symmetric New SPI (NES) design adopted in the base protocol draft 1659 version -08. There are no more separate REA, AC or ACR packets, but 1660 their functionality has been folded into the NES packet. At the same 1661 time, it has become possible to send REA parameters in R1 and I2. 1663 The Forwarding Agent functionality was removed, since it looks like 1664 that it will be moved to the proposed HIP Research Group. Hence, 1665 there will be two other documents related to that, a simple 1666 Rendezvous server document (WG item) and a Forwarding Agent document 1667 (RG item). 1669 A.2. From nikander-hip-mm-01 to nikander-hip-mm-02 1671 Alignment with base-00 draft (use of UPDATE and NOTIFY packets). 1673 The "logical interface" concept was dropped, and the SA/SPI was 1674 identified as the protocol component to which a HIP association binds 1675 addresses to. 1677 The RR was (again) made recommended, not mandatory, able to be 1678 administratively overridden. 1680 A.3. From -02 to draft-ietf-hip-mm-00 1682 REA parameter type value is now "3" (was TBD before). 1684 Recommend that in multihoming situations, that inbound/outbound SAs 1685 are paired to avoid ambiguity when rekeying them. 1687 Clarified that multihoming scenario for now was intended for failover 1688 instead of load-balancing, due to transport layer issues. 1690 Clarified that if HIP negotiates base exchange using link local 1691 addresses, that a host SHOULD provide its peer with a globally 1692 reachable address. 1694 Clarified whether REAs sent for existing SPIs update the full set of 1695 addresses associated with that SPI, or only perform an incremental 1696 (additive) update. REAs for an existing SPI should list all current 1697 addresses for that SPI, and any addresses previously in use on the 1698 SPI but not in the new REA parameter should be DEPRECATED. 1700 Clarified that address verification pertains to *outgoing* addresses. 1702 When discussing inclusion of REA in I2, the draft stated "The 1703 Responder MUST make sure that the puzzle solution is valid BOTH for 1704 the initial IP destination address used for I1 and for the new 1705 preferred address." However, this statement conflicted with Appendix 1706 D of the base specification, so it has been removed for now. 1708 A.4. From draft-ietf-hip-mm-00 to -01 1710 Introduction section reorganized. Some of the scope of the document 1711 relating to multihoming was reduced. 1713 Removed empty appendix "Implementation experiences" 1715 Renamed REA parameter to LOCATOR and aligned to the discussion on 1716 redefining this parameter that occurred on the RG mailing list. 1718 Aligned with decoupling of ESP from base spec. 1720 A.5. From draft-ietf-hip-mm-01 to -02 1722 Aligned with draft-ietf-hip-base-03 and draft-ietf-hip-esp-00 1724 Address verification is a MUST (C. Vogt, list post on 06/12/05) 1726 If UPDATE exceeds MTU because of too many locators, do not split into 1727 multiple UPDATEs, but instead rely on IP fragmentation (C. Vogt, list 1728 post on 06/12/05) 1730 New value for LOCATOR parameter type (193), per 05/31/05 discussion 1731 on the WG list 1733 Various additions related to Credit-Based Authorization due to C. 1734 Vogt 1736 Security section contributed by Greg Perkins, with subsequent editing 1737 from C. Vogt and P. Nikander 1739 Reorganization according to RFC 4101 guidance on writing protocol 1740 models 1742 Open issue: LOCATOR parameter semantics (implicit/explicit removal) 1744 A.6. From draft-ietf-hip-mm-02 to -03 1746 Aligned with draft-ietf-hip-base-05 and draft-ietf-hip-esp-02 1748 Further clarification that the scope of this draft is primarily 1749 limited to the case in which ESP is used 1750 New layered architectural overview in Section 3 1752 Limited the scope of multihoming description to just a single host 1753 adding a single new address; other cases left for further study 1755 Require that ESP_INFO be included on all UPDATE packets relating to 1756 mobility and multihoming (for middleboxes) 1758 New convention for use of "Old SPI" and "New SPI" values to signal 1759 new SPIs (Old SPI == 0, New SPI != 0) and gratuitous ESP_INFOs with 1760 no rekeying (Old SPI == New SPI != 0). 1762 Only specify the use of Locator Type of 1 when using ESP, for 1763 simplicity of receiver processing. 1765 Removed multiple addresses in LOCATOR example of section 3.2.2, 1766 because it is not clear that the example is correct (requires further 1767 study) 1769 Corrected mention of sending ECHO_REQUEST nonce in R2 (should be sent 1770 in separate UPDATE because R2 is not an acknowledged packet) 1772 Removed first four paragraphs of Section 5, which were redundant with 1773 previous introductory material. 1775 Rewrote Sections 5.2 and 5.3 on sending and receiving LOCATOR, to 1776 more explicitly cover the scenario scope of this document. 1778 Removed unwritten "Policy Considerations" section 1780 Author's Address 1782 Tom Henderson 1783 The Boeing Company 1784 P.O. Box 3707 1785 Seattle, WA 1786 USA 1788 Email: thomas.r.henderson@boeing.com 1790 Intellectual Property Statement 1792 The IETF takes no position regarding the validity or scope of any 1793 Intellectual Property Rights or other rights that might be claimed to 1794 pertain to the implementation or use of the technology described in 1795 this document or the extent to which any license under such rights 1796 might or might not be available; nor does it represent that it has 1797 made any independent effort to identify any such rights. Information 1798 on the procedures with respect to rights in RFC documents can be 1799 found in BCP 78 and BCP 79. 1801 Copies of IPR disclosures made to the IETF Secretariat and any 1802 assurances of licenses to be made available, or the result of an 1803 attempt made to obtain a general license or permission for the use of 1804 such proprietary rights by implementers or users of this 1805 specification can be obtained from the IETF on-line IPR repository at 1806 http://www.ietf.org/ipr. 1808 The IETF invites any interested party to bring to its attention any 1809 copyrights, patents or patent applications, or other proprietary 1810 rights that may cover technology that may be required to implement 1811 this standard. Please address the information to the IETF at 1812 ietf-ipr@ietf.org. 1814 Disclaimer of Validity 1816 This document and the information contained herein are provided on an 1817 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1818 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1819 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1820 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1821 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1822 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1824 Copyright Statement 1826 Copyright (C) The Internet Society (2006). This document is subject 1827 to the rights, licenses and restrictions contained in BCP 78, and 1828 except as set forth therein, the authors retain all their rights. 1830 Acknowledgment 1832 Funding for the RFC Editor function is currently provided by the 1833 Internet Society.