idnits 2.17.1 draft-ietf-hip-mm-05.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, updated by RFC 4748 on line 1917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1941. 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 IETF Trust 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 (March 2, 2007) is 6237 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) ** Obsolete normative reference: RFC 4423 (ref. '1') (Obsoleted by RFC 9063) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '2') ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '3') ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-esp (ref. '6') ** Obsolete normative reference: RFC 2373 (ref. '8') (Obsoleted by RFC 3513) Summary: 7 errors (**), 0 flaws (~~), 4 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: September 3, 2007 March 2, 2007 6 End-Host Mobility and Multihoming with the Host Identity Protocol 7 draft-ietf-hip-mm-05 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 September 3, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . 9 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. Mobility with single SA pair (mobile-initiated 62 rekey) . . . . . . . . . . . . . . . . . . . . . . . . 12 63 3.2.3. Host multihoming . . . . . . . . . . . . . . . . . . . 13 64 3.2.4. Site multihoming . . . . . . . . . . . . . . . . . . . 14 65 3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 15 66 3.2.6. Combined mobility and multihoming . . . . . . . . . . 16 67 3.2.7. Using LOCATORs across addressing realms . . . . . . . 16 68 3.2.8. Network renumbering . . . . . . . . . . . . . . . . . 16 69 3.2.9. Initiating the protocol in R1 or I2 . . . . . . . . . 16 70 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 18 71 3.3.1. Address Verification . . . . . . . . . . . . . . . . . 18 72 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 18 73 3.3.3. Preferred locator . . . . . . . . . . . . . . . . . . 19 74 3.3.4. Interaction with Security Associations . . . . . . . . 20 75 4. LOCATOR parameter format . . . . . . . . . . . . . . . . . . . 23 76 4.1. Traffic Type and Preferred locator . . . . . . . . . . . . 24 77 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 25 78 4.3. UPDATE packet with included LOCATOR . . . . . . . . . . . 25 79 5. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 26 80 5.1. Locator data structure and status . . . . . . . . . . . . 26 81 5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 27 82 5.3. Handling received LOCATORs . . . . . . . . . . . . . . . . 29 83 5.4. Verifying address reachability . . . . . . . . . . . . . . 31 84 5.5. Changing the Preferred locator . . . . . . . . . . . . . . 32 85 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 33 86 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 33 87 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 35 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 89 6.1. Impersonation attacks . . . . . . . . . . . . . . . . . . 37 90 6.2. Denial of Service attacks . . . . . . . . . . . . . . . . 38 91 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 38 92 6.2.2. Memory/Computational exhaustion DoS attacks . . . . . 39 93 6.3. Mixed deployment environment . . . . . . . . . . . . . . . 39 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 95 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 42 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 9.1. Normative references . . . . . . . . . . . . . . . . . . . 43 98 9.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 A.7. From draft-ietf-hip-mm-03 to -04 . . . . . . . . . . . . . 46 107 A.8. From draft-ietf-hip-mm-04 to -05 . . . . . . . . . . . . . 46 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 109 Intellectual Property and Copyright Statements . . . . . . . . . . 48 111 1. Introduction and Scope 113 The Host Identity Protocol [1] (HIP) supports an architecture that 114 decouples the transport layer (TCP, UDP, etc.) from the 115 internetworking layer (IPv4 and IPv6) by using public/private key 116 pairs, instead of IP addresses, as host identities. When a host uses 117 HIP, the overlying protocol sublayers (e.g., transport layer sockets 118 and ESP Security Associations) are instead bound to representations 119 of these host identities, and the IP addresses are only used for 120 packet forwarding. However, each host must also know at least one IP 121 address at which its peers are reachable. Initially, these IP 122 addresses are the ones used during the HIP base exchange [2]. 124 One consequence of such a decoupling is that new solutions to 125 network-layer mobility and host multihoming are possible. There are 126 potentially many variations of mobility and multihoming possible. 127 The scope of this document encompasses messaging and elements of 128 procedure for basic network-level mobility and simple multihoming, 129 leaving more complicated scenarios and other variations for further 130 study. Specifically, 132 This document defines a generalized LOCATOR parameter for use in 133 HIP messages. The LOCATOR parameter allows a HIP host to notify a 134 peer about alternate addresses at which it is reachable. The 135 LOCATORs may be merely IP addresses, or they may have additional 136 multiplexing and demultiplexing context to aid the packet handling 137 in the lower layers. For instance, an IP address may need to be 138 paired with an ESP SPI so that packets are sent on the correct SA 139 for a given address. 141 This document also specifies the messaging and elements of 142 procedure for end-host mobility of a HIP host-- the sequential 143 change in preferred IP address used to reach a host. In 144 particular, message flows to enable successful host mobility, 145 including address verification methods, are defined herein. 147 However, while the same LOCATOR parameter is intended to support 148 host multihoming (parallel support of a number of addresses), and 149 experimentation is encouraged, detailed elements of procedure for 150 host multihoming are left for further study. 152 While HIP can potentially be used with transports other than the ESP 153 transport format [6], this document largely assumes the use of ESP 154 and leaves other transport for further study. 156 There are a number of situations where the simple end-to-end 157 readdressing functionality is not sufficient. These include the 158 initial reachability of a mobile host, location privacy, simultaneous 159 mobility of both hosts, and some modes of NAT traversal. In these 160 situations there is a need for some helper functionality in the 161 network, such as a HIP Rendezvous server [3]. Such functionality is 162 out of scope of this document. We also do not consider localized 163 mobility management extensions (i.e., mobility management techniques 164 that do not involve directly signaling the correspondent node); this 165 document is concerned with end-to-end mobility. Finally, making 166 underlying IP mobility transparent to the transport layer has 167 implications on the proper response of transport congestion control, 168 path MTU selection, and QoS. Transport-layer mobility triggers, and 169 the proper transport response to a HIP mobility or multihoming 170 address change, are outside the scope of this document. 172 2. Terminology and Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC2119 [7]. 178 LOCATOR. The name of a HIP parameter containing zero or more Locator 179 fields. This parameter's name is distinguished from the Locator 180 fields embedded within it by the use of all capital letters. 182 Locator. A name that controls how the packet is routed through the 183 network and demultiplexed by the end host. It may include a 184 concatenation of traditional network addresses such as an IPv6 185 address and end-to-end identifiers such as an ESP SPI. It may 186 also include transport port numbers or IPv6 Flow Labels as 187 demultiplexing context, or it may simply be a network address. 189 Address. A name that denotes a point-of-attachment to the network. 190 The two most common examples are an IPv4 address and an IPv6 191 address. The set of possible addresses is a subset of the set of 192 possible locators. 194 Preferred locator. A locator on which a host prefers to receive 195 data. With respect to a given peer, a host always has one active 196 Preferred locator, unless there are no active locators. By 197 default, the locators used in the HIP base exchange are the 198 Preferred locators. 200 Credit Based Authorization. A host must verify a mobile or multi- 201 homed peer's reachability at a new locator. Credit-Based 202 Authorization authorizes the peer to receive a certain amount of 203 data at the new locator before the result of such verification is 204 known. 206 3. Protocol Model 208 This section is an overview; more detailed specification follows this 209 section. 211 3.1. Operating Environment 213 The Host Identity Protocol (HIP) [2] is a key establishment and 214 parameter negotiation protocol. Its primary applications are for 215 authenticating host messages based on host identities, and 216 establishing security associations (SAs) for ESP transport format [6] 217 and possibly other protocols in the future. 219 +--------------------+ +--------------------+ 220 | | | | 221 | +------------+ | | +------------+ | 222 | | Key | | HIP | | Key | | 223 | | Management | <-+-----------------------+-> | Management | | 224 | | Process | | | | Process | | 225 | +------------+ | | +------------+ | 226 | ^ | | ^ | 227 | | | | | | 228 | v | | v | 229 | +------------+ | | +------------+ | 230 | | IPsec | | ESP | | IPsec | | 231 | | Stack | <-+-----------------------+-> | Stack | | 232 | | | | | | | | 233 | +------------+ | | +------------+ | 234 | | | | 235 | | | | 236 | Initiator | | Responder | 237 +--------------------+ +--------------------+ 239 Figure 1: HIP deployment model 241 The general deployment model for HIP is shown above, assuming 242 operation in an end-to-end fashion. This document specifies 243 extensions to the HIP protocol to enable end-host mobility and basic 244 multihoming. In summary, these extensions to the HIP base protocol 245 enable the signaling of new addressing information to the peer in HIP 246 messages. The messages are authenticated via a signature or keyed 247 hash message authentication code (HMAC) based on its host identity. 248 This document specifies the format of this new addressing (LOCATOR) 249 parameter, the procedures for sending and processing this parameter 250 to enable basic host mobility, and procedures for a concurrent 251 address verification mechanism. 253 --------- 254 | TCP | (sockets bound to HITs) 255 --------- 256 | 257 --------- 258 ----> | ESP | {HIT_s, HIT_d} <-> SPI 259 | --------- 260 | | 261 ---- --------- 262 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 263 ---- --------- 264 | 265 --------- 266 | IP | 267 --------- 269 Figure 2: Architecture for HIP mobility and multihoming (MH) 271 Figure 2 depicts a layered architectural view of a HIP-enabled stack 272 using ESP transport format. In HIP, upper-layer protocols (including 273 TCP and ESP in this figure) are bound to HITs and not IP addresses. 274 The HIP sublayer is responsible for maintaining the binding between 275 HITs and IP addresses. The SPI is used to associate an incoming 276 packet with the right HITs. The block labeled "MH" is introduced 277 below. 279 Consider first the case in which there is no mobility or multihoming, 280 as specified in the base protocol specification [2]. The HIP base 281 exchange establishes the HITs in use between the hosts, the SPIs to 282 use for ESP, and the IP addresses (used in both the HIP signaling 283 packets and ESP data packets). Note that there can only be one such 284 set of bindings in the outbound direction for any given packet, and 285 the only fields used for the binding at the HIP layer are the fields 286 exposed by ESP (the SPI and HITs). For the inbound direction, the 287 SPI is all that is required to find the right host context. ESP 288 rekeying events change the mapping between the HIT pair and SPI, but 289 do not change the IP addresses. 291 Consider next a mobility event, in which a host is still single-homed 292 but moves to another IP address. Two things must occur in this case. 293 First, the peer must be notified of the address change using a HIP 294 UPDATE message. Second, each host must change its local bindings at 295 the HIP sublayer (new IP addresses). It may be that both the SPIs 296 and IP addresses are changed simultaneously in a single UPDATE; the 297 protocol described herein supports this. However, simultaneous 298 movement of both hosts, notification of transport layer protocols of 299 the path change, and procedures for possibly traversing middleboxes 300 are not covered by this document. 302 Finally, consider the case when a host is multihomed (has more than 303 one globally routable address) and has multiple addresses available 304 at the HIP layer as alternative locators, for fault tolerance. 305 Examples include the use of (possibly multiple) IPv4 and IPv6 306 addresses on the same interface, or the use of multiple interfaces 307 attached to different service providers. Such host multihoming 308 generally necessitates that a separate ESP SA is maintained for each 309 interface in order to prevent packets that arrive over different 310 paths from falling outside of the ESP anti-replay window [4]. 311 Multihoming thus makes possible that the bindings shown on the right 312 side of Figure 2 are one to many (in the outbound direction, one HIT 313 pair to multiple SPIs, and possibly then to multiple IP addresses). 314 However, only one SPI and address pair can be used for any given 315 packet, so the job of the "MH" block depicted above is to dynamically 316 manipulate these bindings. Beyond locally managing such multiple 317 bindings, the peer-to-peer HIP signaling protocol needs to be 318 flexible enough to define the desired mappings between HITs, SPIs, 319 and addresses, and needs to ensure that UPDATE messages are sent 320 along the right network paths so that any HIP-aware middleboxes can 321 observe the SPIs. This document does not specify the "MH" block, nor 322 does it specify detailed elements of procedure for how to handle 323 various multihoming (perhaps combined with mobility) scenarios. The 324 "MH" block may apply to more general problems outside of HIP. 325 However, this document does describe a basic multihoming case (one 326 host adds one address to its initial address and notifies the peer) 327 and leave more complicated scenarios for experimentation and future 328 documents. 330 3.1.1. Locator 332 This document defines a generalization of an address called a 333 "locator". A locator specifies a point-of-attachment to the network 334 but may also include additional end-to-end tunneling or per-host 335 demultiplexing context that affects how packets are handled below the 336 logical HIP sublayer of the stack. This generalization is useful 337 because IP addresses alone may not be sufficient to describe how 338 packets should be handled below HIP. For example, in a host 339 multihoming context, certain IP addresses may need to be associated 340 with certain ESP SPIs, to avoid violation ESP anti-replay window. 341 Addresses may also be affiliated with transport ports in certain 342 tunneling scenarios. Locators may simply be traditional network 343 addresses. The format of the locators is defined in Section 4. 345 3.1.2. Mobility overview 347 When a host moves to another address, it notifies its peer of the new 348 address by sending a HIP UPDATE packet containing a LOCATOR 349 parameter. This UPDATE packet is acknowledged by the peer. For 350 reliability in the presence of packet loss, the UPDATE packet is 351 retransmitted as defined in the HIP protocol specification [2]. The 352 peer can authenticate the contents of the UPDATE packet based on the 353 signature and keyed hash of the packet. 355 When using ESP Transport Format [6], the host may at the same time 356 decide to rekey its security association and possibly generate a new 357 Diffie-Hellman key; all of these actions are triggered by including 358 additional parameters in the UPDATE packet, as defined in the base 359 protocol specification [2] and ESP extension [6]. 361 When using ESP (and possibly other transport modes in the future), 362 the host is able to receive packets that are protected using a HIP 363 created ESP SA from any address. Thus, a host can change its IP 364 address and continue to send packets to its peers without necessarily 365 rekeying. However, the peers are not able to send packets to these 366 new addresses before they can reliably and securely update the set of 367 addresses that they associate with the sending host. Furthermore, 368 mobility may change the path characteristics in such a manner that 369 reordering occurs and packets fall outside the ESP anti-replay window 370 for the SA, thereby requiring rekeying. 372 3.1.3. Multihoming overview 374 A related operational configuration is host multihoming, in which a 375 host has multiple locators simultaneously rather than sequentially as 376 in the case of mobility. By using the LOCATOR parameter defined 377 herein, a host can inform its peers of additional (multiple) locators 378 at which it can be reached, and can declare a particular locator as a 379 "preferred" locator. Although this document defines a basic 380 mechanism for multihoming, it does not define detailed policies and 381 procedures such as which locators to choose when more than one pair 382 is available, the operation of simultaneous mobility and multihoming, 383 source address selection policies (beyond those specified in [5]), 384 and the implications of multihoming on transport protocols and ESP 385 anti-replay windows. Additional definition of HIP-based multihoming 386 is expected to be part of future documents. 388 3.2. Protocol Overview 390 In this section we briefly introduce a number of usage scenarios for 391 HIP mobility and multihoming. These scenarios assume that HIP is 392 being used with the ESP transform [6], although other scenarios may 393 be defined in the future. To understand these usage scenarios, the 394 reader should be at least minimally familiar with the HIP protocol 395 specification [2]. However, for the (relatively) uninitiated reader 396 it is most important to keep in mind that in HIP the actual payload 397 traffic is protected with ESP, and that the ESP SPI acts as an index 398 to the right host-to-host context. More specification detail on is 399 later found in Section 4 and Section 5. 401 The scenarios below assume that the two hosts have completed a single 402 HIP base exchange with each other. Both of the hosts therefore have 403 one incoming and one outgoing SA. Further, each SA uses the same 404 pair of IP addresses; the ones used in the base exchange. 406 The readdressing protocol is an asymmetric protocol where a mobile or 407 multihomed host informs a peer host about changes of IP addresses on 408 affected SPIs. The readdressing exchange is designed to be 409 piggybacked on existing HIP exchanges. The majority of the packets 410 on which the LOCATOR parameters are expected to be carried are UPDATE 411 packets. However, some implementations may want to experiment with 412 sending LOCATOR parameters also on other packets, such as R1, I2, and 413 NOTIFY. 415 Hosts that use link-local addresses as source addresses in their HIP 416 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 417 provide a globally routable address either in the initial handshake 418 or via the LOCATOR parameter. 420 3.2.1. Mobility with single SA pair (no rekeying) 422 A mobile host must sometimes change an IP address bound to an 423 interface. The change of an IP address might be needed due to a 424 change in the advertised IPv6 prefixes on the link, a reconnected PPP 425 link, a new DHCP lease, or an actual movement to another subnet. In 426 order to maintain its communication context, the host must inform its 427 peers about the new IP address. This first example considers the 428 case in which the mobile host has only one interface, IP address, a 429 single pair of SAs (one inbound, one outbound), and no rekeying 430 occurs on the SAs. We also assume that the new IP addresses are 431 within the same address family (IPv4 or IPv6) as the first address. 432 This is the simplest scenario, depicted in Figure 3. 434 Mobile Host Peer Host 436 UPDATE(ESP_INFO, LOCATOR, SEQ) 437 -----------------------------------> 438 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 439 <----------------------------------- 440 UPDATE(ACK, ECHO_RESPONSE) 441 -----------------------------------> 443 Figure 3: Readdress without rekeying, but with address check 445 The steps of the packet processing are as follows: 447 1. The mobile host is disconnected from the peer host for a brief 448 period of time while it switches from one IP address to another. 449 Upon obtaining a new IP address, the mobile host sends a LOCATOR 450 parameter to the peer host in an UPDATE message. The UPDATE 451 message also contains an ESP_INFO parameter containing the values 452 of the old and new SPIs for a security association. In this 453 case, the "Old SPI" and "New SPI" parameters both are set to the 454 value of the pre-existing incoming SPI; this ESP_INFO does not 455 trigger a rekeying event but is instead included for possible 456 parameter-inspecting middleboxes on the path. The LOCATOR 457 parameter contains the new IP address (Locator Type of "1", 458 defined below) and a locator lifetime. The mobile host waits for 459 this UPDATE to be acknowledged, and retransmits if necessary, as 460 specified in the base specification [2]. 462 2. The peer host receives the UPDATE, validates it, and updates any 463 local bindings between the HIP association and the mobile host's 464 destination address. The peer host MUST perform an address 465 verification by placing a nonce in the ECHO_REQUEST parameter of 466 the UPDATE message sent back to the mobile host. It also 467 includes an ESP_INFO parameter with the "Old SPI" and "New SPI" 468 parameters both set to the value of the pre-existing incoming 469 SPI, and sends this UPDATE (with piggybacked acknowledgment) to 470 the mobile host at its new address. The peer MAY use the new 471 address immediately, but it MUST limit the amount of data it 472 sends to the address until address verification completes. 474 3. The mobile host completes the readdress by processing the UPDATE 475 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 476 host receives this ECHO_RESPONSE, it considers the new address to 477 be verified and can put it into full use. 479 While the peer host is verifying the new address, the new address is 480 marked as UNVERIFIED in the interim, and the old address is 481 DEPRECATED. Once the peer host has received a correct reply to its 482 UPDATE challenge, it marks the new address as ACTIVE and removes the 483 old address. 485 3.2.2. Mobility with single SA pair (mobile-initiated rekey) 487 The mobile host may decide to rekey the SAs at the same time that it 488 is notifying the peer of the new address. In this case, the above 489 procedure described in Figure 3 is slightly modified. The UPDATE 490 message sent from the mobile host includes an ESP_INFO with the "Old 491 SPI" set to the previous SPI, the "New SPI" set to the desired new 492 SPI value for the incoming SA, and the Keymat Index desired. 493 Optionally, the host may include a DIFFIE_HELLMAN parameter for a new 494 Diffie-Hellman key. The peer completes the request for rekey as is 495 normally done for HIP rekeying, except that the new address is kept 496 as UNVERIFIED until the UPDATE nonce challenge is received as 497 described above. Figure 4 illustrates this scenario. 499 Mobile Host Peer Host 501 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 502 -----------------------------------> 503 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 504 <----------------------------------- 505 UPDATE(ACK, ECHO_RESPONSE) 506 -----------------------------------> 508 Figure 4: Readdress with mobile-initiated rekey 510 3.2.3. Host multihoming 512 A (mobile or stationary) host may sometimes have more than one 513 interface or global address. The host may notify the peer host of 514 the additional interface or address by using the LOCATOR parameter. 515 To avoid problems with the ESP anti-replay window, a host SHOULD use 516 a different SA for each interface or address used to receive packets 517 from the peer host, when multiple locator pairs are being used 518 simultaneously rather than sequentially. 520 When more than one locator is provided to the peer host, the host 521 SHOULD indicate which locator is preferred (the locator on which the 522 host prefers to receive traffic). By default, the addresses used in 523 the base exchange are preferred until indicated otherwise. 525 In the multihoming case, the sender may also have multiple valid 526 locators from which to source traffic. In practice, a HIP 527 association in a multihoming configuration may have both a preferred 528 peer locator and a preferred local locator, although rules for source 529 address selection should ultimately govern the selection of source 530 locator based on the destination locator. 532 Although the protocol may allow for configurations in which there is 533 an asymmetric number of SAs between the hosts (e.g., one host has two 534 interfaces and two inbound SAs, while the peer has one interface and 535 one inbound SA), it is RECOMMENDED that inbound and outbound SAs be 536 created pairwise between hosts. When an ESP_INFO arrives to rekey a 537 particular outbound SA, the corresponding inbound SA should be also 538 rekeyed at that time. Although asymmetric SA configurations might be 539 experimented with, their usage may constrain interoperability at this 540 time. However, it is recommended that implementations attempt to 541 support peers that prefer to use non-paired SAs. It is expected that 542 this section and behavior will be modified in future revisions of 543 this protocol, once the issue and its implications are better 544 understood. 546 Consider the case between two hosts, one single-homed and one 547 multihomed. The multihomed host may decide to inform the single- 548 homed host about its other address. It is RECOMMENDED that the 549 multihomed host set up a new SA pair for use on this new address. To 550 do this, the multihomed host sends a LOCATOR with an ESP_INFO, 551 indicating the request for a new SA by setting the "Old SPI" value to 552 zero, and the "New SPI" value to the newly created incoming SPI. A 553 Locator Type of "1" is used to associate the new address with the new 554 SPI. The LOCATOR parameter also contains a second Type 1 locator: 555 that of the original address and SPI. To simplify parameter 556 processing and avoid explicit protocol extensions to remove locators, 557 each LOCATOR parameter MUST list all locators in use on a connection 558 (a complete listing of inbound locators and SPIs for the host). The 559 multihomed host waits for a ESP_INFO (new outbound SA) from the peer 560 and an ACK of its own UPDATE. As in the mobility case, the peer host 561 must perform an address verification before actively using the new 562 address. Figure 5 illustrates this scenario. 564 Multi-homed Host Peer Host 566 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 567 -----------------------------------> 568 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 569 <----------------------------------- 570 UPDATE(ACK, ECHO_RESPONSE) 571 -----------------------------------> 573 Figure 5: Basic multihoming scenario 575 In multihoming scenarios, it is important that hosts receiving 576 UPDATEs associate them correctly with the destination address used in 577 the packet carrying the UPDATE. When processing inbound LOCATORs 578 that establish new security associations on an interface with 579 multiple addresses, a host uses the destination address of the UPDATE 580 containing LOCATOR as the local address to which the LOCATOR plus 581 ESP_INFO is targeted. This is because hosts may send UPDATEs with 582 the same (locator) IP address to different peer addresses-- this has 583 the effect of creating multiple inbound SAs implicitly affiliated 584 with different peer source addresses. 586 3.2.4. Site multihoming 588 A host may have an interface that has multiple globally reachable IP 589 addresses. Such a situation may be a result of the site having 590 multiple upper Internet Service Providers, or just because the site 591 provides all hosts with both IPv4 and IPv6 addresses. It is 592 desirable that the host can stay reachable with all or any subset of 593 the currently available globally routable addresses, independent on 594 how they are provided. 596 This case is handled the same as if there were different IP 597 addresses, described above in Section 3.2.3. Note that a single 598 interface may experience site multihoming while the host itself may 599 have multiple interfaces. 601 Note that a host may be multi-homed and mobile simultaneously, and 602 that a multi-homed host may want to protect the location of some of 603 its interfaces while revealing the real IP address of some others. 605 This document does not presently specify additional site multihoming 606 extensions to HIP; further alignment with the IETF shim6 working 607 group may be considered in the future. 609 3.2.5. Dual host multihoming 611 Consider the case in which both hosts would like to add an additional 612 address after the base exchange completes. In Figure 6, consider 613 that host1, which used address addr1a in the base exchange to set up 614 SPI1a and SPI2a, wants to add address addr1b. It would send an 615 UPDATE with LOCATOR (containing the address addr1b) to host2, using 616 destination address addr2a, and a new set of SPIs would be added 617 between hosts 1 and 2 (call them SPI1b and SPI2b-- not shown in the 618 figure). Next, consider host2 deciding to add addr2b to the 619 relationship. Host2 must select one of host1's addresses towards 620 which to initiate an UPDATE. It may choose to initiate an UPDATE to 621 addr1a, addr1b, or both. If it chooses to send to both, then a full 622 mesh (four SA pairs) of SAs would exist between the two hosts. This 623 is the most general case; it often may be the case that hosts 624 primarily establish new SAs only with the peer's Preferred locator. 625 The readdressing protocol is flexible enough to accommodate this 626 choice. 628 -<- SPI1a -- -- SPI2a ->- 629 host1 < > addr1a <---> addr2a < > host2 630 ->- SPI2a -- -- SPI1a -<- 632 addr1b <---> addr2a (second SA pair) 633 addr1a <---> addr2b (third SA pair) 634 addr1b <---> addr2b (fourth SA pair) 636 Figure 6: Dual multihoming case in which each host uses LOCATOR to 637 add a second address 639 3.2.6. Combined mobility and multihoming 641 It looks likely that in the future many mobile hosts will be 642 simultaneously mobile and multi-homed, i.e., have multiple mobile 643 interfaces. Furthermore, if the interfaces use different access 644 technologies, it is fairly likely that one of the interfaces may 645 appear stable (retain its current IP address) while some other(s) may 646 experience mobility (undergo IP address change). 648 The use of LOCATOR plus ESP_INFO should be flexible enough to handle 649 most such scenarios, although more complicated scenarios have not 650 been studied so far. 652 3.2.7. Using LOCATORs across addressing realms 654 It is possible for HIP associations to migrate to a state in which 655 both parties are only using locators in different addressing realms. 656 For example, the two hosts may initiate the HIP association when both 657 are using IPv6 locators, then one host may loose its IPv6 658 connectivity and obtain an IPv4 address. In such a case, some type 659 of mechanism for interworking between the different realms must be 660 employed; such techniques are outside the scope of the present text. 661 The basic problem in this example is that the host readdressing to 662 IPv4 does not know a corresponding IPv4 address of the peer. This 663 may be handled (experimentally) by possibly configuring this address 664 information manually or in the DNS, or the hosts exchange both IPv4 665 and IPv6 addresses in the locator. 667 3.2.8. Network renumbering 669 It is expected that IPv6 networks will be renumbered much more often 670 than most IPv4 networks are. From an end-host point of view, network 671 renumbering is similar to mobility. 673 3.2.9. Initiating the protocol in R1 or I2 675 A Responder host MAY include a LOCATOR parameter in the R1 packet 676 that it sends to the Initiator. This parameter MUST be protected by 677 the R1 signature. If the R1 packet contains LOCATOR parameters with 678 a new Preferred locator, the Initiator SHOULD directly set the new 679 Preferred locator to status ACTIVE without performing address 680 verification first, and MUST send the I2 packet to the new Preferred 681 locator. The I1 destination address and the new Preferred locator 682 may be identical. All new non-preferred locators must still undergo 683 address verification once the base exchange completes. 685 Initiator Responder 687 R1 with LOCATOR 688 <----------------------------------- 689 record additional addresses 690 change responder address 691 I2 sent to newly indicated preferred address 692 -----------------------------------> 693 (process normally) 694 R2 695 <----------------------------------- 696 (process normally, later verification of non-preferred locators) 698 Figure 7: LOCATOR inclusion in R1 700 An Initiator MAY include one or more LOCATOR parameters in the I2 701 packet, independent of whether there was a LOCATOR parameter in the 702 R1 or not. These parameters MUST be protected by the I2 signature. 703 Even if the I2 packet contains LOCATOR parameters, the Responder MUST 704 still send the R2 packet to the source address of the I2. The new 705 Preferred locator SHOULD be identical to the I2 source address. If 706 the I2 packet contains LOCATOR parameters, all new locators must 707 undergo address verification as usual, and the ESP traffic that 708 subsequently follows should use the Preferred locator. 710 Initiator Responder 712 I2 with LOCATOR 713 -----------------------------------> 714 (process normally) 715 record additional addresses 716 R2 sent to source address of I2 717 <----------------------------------- 718 (process normally) 720 Figure 8: LOCATOR inclusion in I2 722 The I1 and I2 may be arriving from different source addresses if the 723 LOCATOR parameter is present in R1. In this case, implementations 724 using pre-created R1 indexed with IP addresses fail the puzzle 725 solution of I2 packets inadvertently. See, for example, the example 726 in Appendix A of [2]. As a solution, the responder's puzzle indexing 727 mechanism must be flexible enough to accomodate the situation when R1 728 includes a LOCATOR parameter. 730 3.3. Other Considerations 732 3.3.1. Address Verification 734 When a HIP host receives a set of locators from another HIP host in a 735 LOCATOR, it does not necessarily know whether the other host is 736 actually reachable at the claimed addresses. In fact, a malicious 737 peer host may be intentionally giving bogus addresses in order to 738 cause a packet flood towards the target addresses [9]. Likewise, 739 viral software may have compromised the peer host, programming it to 740 redirect packets to the target addresses. Thus, the HIP host must 741 first check that the peer is reachable at the new address. 743 An additional potential benefit of performing address verification is 744 to allow middleboxes in the network along the new path to obtain the 745 peer host's inbound SPI. 747 Address verification is implemented by the challenger sending some 748 piece of unguessable information to the new address, and waiting for 749 some acknowledgment from the responder that indicates reception of 750 the information at the new address. This may include exchange of a 751 nonce, or generation of a new SPI and observing data arriving on the 752 new SPI. 754 3.3.2. Credit-Based Authorization 756 Credit-Based Authorization (CBA) allows a host to securely use a new 757 locator even though the peer's reachability at the address embedded 758 in the locator has not yet been verified. This is accomplished based 759 on the following three hypotheses: 761 1. A flooding attacker typically seeks to somehow multiply the 762 packets it generates for the purpose of its attack because 763 bandwidth is an ample resource for many victims. 765 2. An attacker can often cause unamplified flooding by sending 766 packets to its victim, either by directly addressing the victim 767 in the packets, or by guiding the packets along a specific path 768 by means of an IPv6 Routing header, if Routing headers are not 769 filtered by firewalls. 771 3. Consequently, the additional effort required to set up a 772 redirection-based flooding attack (without CBA and return 773 routability checks) would pay off for the attacker only if 774 amplification could be obtained this way. 776 On this basis, rather than eliminating malicious packet redirection 777 in the first place, Credit-Based Authorization prevents 778 amplifications. This is accomplished by limiting the data a host can 779 send to an unverified address of a peer by the data recently received 780 from that peer. Redirection-based flooding attacks thus become less 781 attractive than, e.g., pure direct flooding, where the attacker 782 itself sends bogus packets to the victim. 784 Figure 9 illustrates Credit-Based Authorization: Host B measures the 785 amount of data recently received from peer A and, when A readdresses, 786 sends packets to A's new, unverified address as long as the sum of 787 the packet sizes does not exceed the measured, received data volume. 788 When insufficient credit is left, B stops sending further packets to 789 A until A's address becomes ACTIVE. The address changes may be due 790 to mobility, due to multihoming, or due to any other reason. Not 791 shown in Figure 9 are the results of credit aging (Section 5.6.2), a 792 mechanism used to dampen possible time-shifting attacks. 794 +-------+ +-------+ 795 | A | | B | 796 +-------+ +-------+ 797 | | 798 address |------------------------------->| credit += size(packet) 799 ACTIVE | | 800 |------------------------------->| credit += size(packet) 801 |<-------------------------------| do not change credit 802 | | 803 + address change | 804 + address verification starts | 805 address |<-------------------------------| credit -= size(packet) 806 UNVERIFIED |------------------------------->| credit += size(packet) 807 |<-------------------------------| credit -= size(packet) 808 | | 809 |<-------------------------------| credit -= size(packet) 810 | X credit < size(packet) 811 | | => do not send packet! 812 + address verification concludes | 813 address | | 814 ACTIVE |<-------------------------------| do not change credit 815 | | 817 Figure 9: Readdressing Scenario 819 3.3.3. Preferred locator 821 When a host has multiple locators, the peer host must decide upon 822 which to use for outbound packets. It may be that a host would 823 prefer to receive data on a particular inbound interface. HIP allows 824 a particular locator to be designated as a Preferred locator, and 825 communicated to the peer (see Section 4). 827 In general, when multiple locators are used for a session, there is 828 the question of using multiple locators for failover only or for 829 load-balancing. Due to the implications of load-balancing on the 830 transport layer that still need to be worked out, this draft assumes 831 that multiple locators are used primarily for failover. An 832 implementation may use ICMP interactions, reachability checks, or 833 other means to detect the failure of a locator. 835 3.3.4. Interaction with Security Associations 837 This document specifies a new HIP protocol parameter, the LOCATOR 838 parameter (see Section 4), that allows the hosts to exchange 839 information about their locator(s), and any changes in their 840 locator(s). The logical structure created with LOCATOR parameters 841 has three levels: hosts, Security Associations (SAs) indexed by 842 Security Parameter Indices (SPIs), and addresses. 844 The relation between these levels for an association constructed as 845 defined in the base specification [2] and ESP transform [6] is 846 illustrated in Figure 10. 848 -<- SPI1a -- -- SPI2a ->- 849 host1 < > addr1a <---> addr2a < > host2 850 ->- SPI2a -- -- SPI1a -<- 852 Figure 10: Relation between hosts, SPIs, and addresses (base 853 specification) 855 In Figure 10, host1 and host2 negotiate two unidirectional SAs, and 856 each host selects the SPI value for its inbound SA. The addresses 857 addr1a and addr2a are the source addresses that the hosts use in the 858 base HIP exchange. These are the "preferred" (and only) addresses 859 conveyed to the peer for use on each SA. That is, although packets 860 sent to any of the hosts' interfaces may be accepted on the inbound 861 SA, the peer host in general knows of only the single destination 862 address learned in the base exchange (e.g., for host1, it sends a 863 packet on SPI2a to addr2a to reach host2), unless other mechanisms 864 exist to learn of new addresses. 866 In general, the bindings that exist in an implementation 867 corresponding to this draft can be depicted as shown in Figure 11. 868 In this figure, a host can have multiple inbound SPIs (and, not 869 shown, multiple outbound SPIs) associated with another host. 870 Furthermore, each SPI may have multiple addresses associated with it. 871 These addresses bound to an SPI are not used to lookup the incoming 872 SA. Rather, the addresses are those addresses that are provided to 873 the peer host, as hints for which addresses to use to reach the host 874 on that SPI. The LOCATOR parameter is used to change the set of 875 addresses that a peer associates with a particular SPI. 877 address11 878 / 879 SPI1 - address12 880 / 881 / address21 882 host -- SPI2 < 883 \ address22 884 \ 885 SPI3 - address31 886 \ 887 address32 889 Figure 11: Relation between hosts, SPIs, and addresses (general case) 891 A host may establish any number of security associations (or SPIs) 892 with a peer. The main purpose of having multiple SPIs with a peer is 893 to group the addresses into collections that are likely to experience 894 fate sharing. For example, if the host needs to change its addresses 895 on SPI2, it is likely that both address21 and address22 will 896 simultaneously become obsolete. In a typical case, such SPIs may 897 correspond with physical interfaces; see below. Note, however, that 898 especially in the case of site multihoming, one of the addresses may 899 become unreachable while the other one still works. In the typical 900 case, however, this does not require the host to inform its peers 901 about the situation, since even the non-working address still 902 logically exists. 904 A basic property of HIP SAs is that the inbound IP address is not 905 used to lookup the incoming SA. Therefore, in Figure 11, it may seem 906 unnecessary for address31, for example, to be associated only with 907 SPI3-- in practice, a packet may arrive to SPI1 via destination 908 address address31 as well. However, the use of different source and 909 destination addresses typically leads to different paths, with 910 different latencies in the network, and if packets were to arrive via 911 an arbitrary destination IP address (or path) for a given SPI, the 912 reordering due to different latencies may cause some packets to fall 913 outside of the ESP anti-replay window. For this reason, HIP provides 914 a mechanism to affiliate destination addresses with inbound SPIs, 915 when there is a concern that anti-replay windows might be violated. 916 In this sense, we can say that a given inbound SPI has an "affinity" 917 for certain inbound IP addresses, and this affinity is communicated 918 to the peer host. Each physical interface SHOULD have a separate SA, 919 unless the ESP anti-replay window is loose. 921 Moreover, even when the destination addresses used for a particular 922 SPI are held constant, the use of different source interfaces may 923 also cause packets to fall outside of the ESP anti-replay window, 924 since the path traversed is often affected by the source address or 925 interface used. A host has no way to influence the source interface 926 on which a peer sends its packets on a given SPI. A host SHOULD 927 consistently use the same source interface and address when sending 928 to a particular destination IP address and SPI. For this reason, a 929 host may find it useful to change its SPI or at least reset its ESP 930 anti-replay window when the peer host readdresses. 932 An address may appear on more than one SPI. This creates no 933 ambiguity since the receiver will ignore the IP addresses during SA 934 lookup anyway. However, this document does not specify such cases. 936 When the LOCATOR parameter is sent in an UPDATE packet, then the 937 receiver will respond with an UPDATE acknowledgment. When the 938 LOCATOR parameter is sent in an R1 or I2 packet, the base exchange 939 retransmission mechanism will confirm its successful delivery. 940 LOCATORs may experimentally be used in NOTIFY packets; in this case, 941 the recipient MUST consider the LOCATOR as informational and not 942 immediately change the current preferred address, but can test the 943 additional locators when the need arises. The use of LOCATOR in a 944 NOTIFY message may not be compatible with middleboxes. 946 4. LOCATOR parameter format 948 The LOCATOR parameter is a critical parameter as defined by [2]. It 949 consists of the standard HIP parameter Type and Length fields, plus 950 zero or more Locator sub-parameters. Each Locator sub-parameter 951 contains a Traffic Type, Locator Type, Locator Length, Preferred 952 locator bit, Locator Lifetime, and a Locator encoding. A LOCATOR 953 contaning zero Locator fields is permitted but has the effect of 954 DEPRECATING all addresses. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Length | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Traffic Type | Locator Type | Locator Length | Reserved |P| 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Locator Lifetime | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Locator | 966 | | 967 | | 968 | | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 . . 971 . . 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Traffic Type | Locator Type | Locator Length | Reserved |P| 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Locator Lifetime | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Locator | 978 | | 979 | | 980 | | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 Type: 193 985 Length: Length in octets, excluding Type and Length fields, and 986 excluding padding. 988 Traffic Type: Defines whether the locator pertains to HIP signaling, 989 user data, or both. 991 Locator Type: Defines the semantics of the Locator field. 993 Locator Length: Defines the length of the Locator field, in units of 994 4-byte words (Locators up to a maximum of 4*255 octets are 995 supported). 997 Reserved: Zero when sent, ignored when received. 999 P: Preferred locator. Set to one if the locator is preferred for 1000 that Traffic Type; otherwise set to zero. 1002 Locator Lifetime: Locator lifetime, in seconds. 1004 Locator: The locator whose semantics and encoding are indicated by 1005 the Locator Type field. All Locator sub-fields are integral 1006 multiples of four octets in length. 1008 The Locator Lifetime indicates how long the following locator is 1009 expected to be valid. The lifetime is expressed in seconds. Each 1010 locator MUST have a non-zero lifetime. The address is expected to 1011 become deprecated when the specified number of seconds has passed 1012 since the reception of the message. A deprecated address SHOULD NOT 1013 be used as an destination address if an alternate (non-deprecated) is 1014 available and has sufficient scope. 1016 4.1. Traffic Type and Preferred locator 1018 The following Traffic Type values are defined: 1020 0: Both signaling (HIP control packets) and user data. 1022 1: Signaling packets only. 1024 2: Data packets only. 1026 The "P" bit, when set, has scope over the corresponding Traffic Type. 1027 That is, when a "P" bit is set for Traffic Type "2", for example, it 1028 means that the locator is preferred for data packets. If there is a 1029 conflict (for example, if P bit is set for an address of Type "0" and 1030 a different address of Type "2"), the more specific Traffic Type rule 1031 applies (in this case, "2"). By default, the IP addresses used in 1032 the base exchange are Preferred locators for both signaling and user 1033 data, unless a new Preferred locator supersedes them. If no locators 1034 are indicated as preferred for a given Traffic Type, the 1035 implementation may use an arbitrary locator from the set of active 1036 locators. 1038 4.2. Locator Type and Locator 1040 The following Locator Type values are defined, along with the 1041 associated semantics of the Locator field: 1043 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] (128 1044 bits long). This locator type is defined primarily for non-ESP- 1045 based usage. 1047 1: The concatenation of an ESP SPI (first 32 bits) followed by an 1048 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 1049 128 bits). This IP address is defined primarily for ESP-based 1050 usage. 1052 4.3. UPDATE packet with included LOCATOR 1054 A number of combinations of parameters in an UPDATE packet are 1055 possible (e.g., see Section 3.2). In this document, procedures are 1056 defined only for the case in which one LOCATOR and one ESP_INFO 1057 parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD 1058 list all of the locators that are active on the HIP association 1059 (including those on SAs not covered by the ESP_INFO parameter). Any 1060 UPDATE packet that includes a LOCATOR parameter SHOULD include both 1061 an HMAC and a HIP_SIGNATURE parameter. The relationship between the 1062 announced Locators and any ESP_INFO parameters present in the packet 1063 is defined in Section 5.2. The sending of multiple LOCATOR and/or 1064 ESP_INFO parameters is for further study; receivers may wish to 1065 experiment with supporting such a possibility. 1067 5. Processing rules 1069 This section describes rules for sending and receiving the LOCATOR 1070 parameter, testing address reachability, and using Credit-Based 1071 Authorization (CBA) on UNVERIFIED locators. 1073 5.1. Locator data structure and status 1075 In a typical implementation, each outgoing locator is represented by 1076 a piece of state that contains the following data: 1078 o the actual bit pattern representing the locator, 1080 o lifetime (seconds), 1082 o status (UNVERIFIED, ACTIVE, DEPRECATED), 1084 o the Traffic Type scope of the locator, and 1086 o whether the locator is preferred for any particular scope. 1088 The status is used to track the reachability of the address embedded 1089 within the LOCATOR parameter: 1091 UNVERIFIED indicates that the reachability of the address has not 1092 been verified yet, 1094 ACTIVE indicates that the reachability of the address has been 1095 verified and the address has not been deprecated, 1097 DEPRECATED indicates that the locator lifetime has expired 1099 The following state changes are allowed: 1101 UNVERIFIED to ACTIVE The reachability procedure completes 1102 successfully. 1104 UNVERIFIED to DEPRECATED The locator lifetime expires while the 1105 locator is UNVERIFIED. 1107 ACTIVE to DEPRECATED The locator lifetime expires while the locator 1108 is ACTIVE. 1110 ACTIVE to UNVERIFIED There has been no traffic on the address for 1111 some time, and the local policy mandates that the address 1112 reachability must be verified again before starting to use it 1113 again. 1115 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 1116 locator. 1118 A DEPRECATED address MUST NOT be changed to ACTIVE without first 1119 verifying its reachability. 1121 Note that the state of whether a locator is preferred or not is not 1122 necessarily the same as the value of the Preferred bit in the Locator 1123 sub-parameter received from the peer. Peers may recommend certain 1124 locators to be preferred, but the decision on whether to actually use 1125 a locator as a preferred locator is a local decision possibly 1126 influenced by local policy. 1128 5.2. Sending LOCATORs 1130 The decision of when to send LOCATORs is basically a local policy 1131 issue. However, it is RECOMMENDED that a host sends a LOCATOR 1132 whenever it recognizes a change of its IP addresses in use on an 1133 active HIP association, and assumes that the change is going to last 1134 at least for a few seconds. Rapidly sending LOCATORs that force the 1135 peer to change the preferred address SHOULD be avoided. 1137 When a host decides to inform its peers about changes in its IP 1138 addresses, it has to decide how to group the various addresses with 1139 SPIs. The grouping should consider also whether middlebox 1140 interaction requires sending the same LOCATOR in separate UPDATEs on 1141 different paths. Since each SPI is associated with a different 1142 Security Association, the grouping policy may also be based on ESP 1143 anti-replay protection considerations. In the typical case, simply 1144 basing the grouping on actual kernel level physical and logical 1145 interfaces may be the best policy. Grouping policy is outside of the 1146 scope of this document. 1148 Note that the purpose of announcing IP addresses in a LOCATOR is to 1149 provide connectivity between the communicating hosts. In most cases, 1150 tunnels or virtual interfaces such as IPsec tunnel interfaces or 1151 Mobile IP home addresses provide sub-optimal connectivity. 1152 Furthermore, it should be possible to replace most tunnels with HIP 1153 based "non-tunneling", therefore making most virtual interfaces 1154 fairly unnecessary in the future. Therefore, virtual interfaces 1155 SHOULD NOT be announced in general. On the other hand, there are 1156 clearly situations where tunnels are used for diagnostic and/or 1157 testing purposes. In such and other similar cases announcing the IP 1158 addresses of virtual interfaces may be appropriate. 1160 Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. 1161 Link-local addresses MAY be announced to peers that are known to be 1162 neighbors on the same link, such as when the IP destination address 1163 of a peer is also link-local. The announcement of link-local 1164 addresses in this case is a policy decision; link-local addresses 1165 used as Preferred locators will create reachability problems when the 1166 host moves to another link. In any case, link-local addresses MUST 1167 NOT be announced to a peer unless that peer is known to be on the 1168 same link. 1170 Once the host has decided on the groups and assignment of addresses 1171 to the SPIs, it creates a LOCATOR parameter that serves as a complete 1172 representation of the addresses and affiliated SPIs intended for 1173 active use. We now describe a few cases introduced in Section 3.2. 1174 We assume that the Traffic Type for each locator is set to "0" (other 1175 values for Traffic Type may be specified in documents that separate 1176 HIP control plane from data plane traffic). Other mobility and 1177 multihoming cases are possible but are left for further 1178 experimentation. 1180 1. Host mobility with no multihoming and no rekeying. The mobile 1181 host creates a single UPDATE containing a single ESP_INFO with a 1182 single LOCATOR parameter. The ESP_INFO contains the current 1183 value of the SPI in both the "Old SPI" and "New SPI" fields. The 1184 LOCATOR contains a single Locator with a "Locator Type" of "1"; 1185 the SPI must match that of the ESP_INFO. The Preferred bit 1186 SHOULD be set and the "Locator Lifetime" is set according to 1187 local policy. The UPDATE also contains a SEQ parameter as usual. 1188 This packet is retransmitted as defined in the HIP protocol 1189 specification [2]. The UPDATE should be sent to the peer's 1190 preferred IP address with an IP source address corresponding to 1191 the address in the LOCATOR parameter. 1193 2. Host mobility with no multihoming but with rekeying. The mobile 1194 host creates a single UPDATE containing a single ESP_INFO with a 1195 single LOCATOR parameter (with a single address). The ESP_INFO 1196 contains the current value of the SPI in the "Old SPI" and the 1197 new value of the SPI in the "New SPI", and a "Keymat Index" as 1198 selected by local policy. Optionally, the host may choose to 1199 initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN 1200 parameter. The LOCATOR contains a single Locator with "Locator 1201 Type" of "1"; the SPI must match that of the "New SPI" in the 1202 ESP_INFO. Otherwise, the steps are identical to the case when no 1203 rekeying is initiated. 1205 3. Host multihoming (addition of an address). We only describe the 1206 simple case of adding an additional address to a (previously) 1207 single-homed, non-mobile host. The host SHOULD set up a new SA 1208 pair between this new address and the preferred address of the 1209 peer host. To do this, the multihomed host creates a new inbound 1210 SA and creates a new SPI. For the outgoing UPDATE message, it 1211 inserts an ESP_INFO parameter with an "Old SPI" field of "0", a 1212 "New SPI" field corresponding to the new SPI, and a "Keymat 1213 Index" as selected by local policy. The host adds to the UPDATE 1214 message a LOCATOR with two Type "1" Locators: the original 1215 address and SPI active on the association, and the new address 1216 and new SPI being added (with the SPI matching the "New SPI" 1217 contained in the ESP_INFO). The Preferred bit SHOULD be set 1218 depending on the policy to tell the peer host which of the two 1219 locators is preferred. The UPDATE also contains a SEQ parameter 1220 and optionally a DIFFIE_HELLMAN parameter, and follows rekeying 1221 procedures with respect to this new address. The UPDATE message 1222 SHOULD be sent to the peer's Preferred address with a source 1223 address corresponding to the new locator. 1225 The sending of multiple LOCATORs, locators with Locator Type "0", and 1226 multiple ESP_INFO parameters is for further study. Note that the 1227 inclusion of LOCATOR in an R1 packet requires the use of Type "0" 1228 locators since no SAs are set up at that point. 1230 5.3. Handling received LOCATORs 1232 A host SHOULD be prepared to receive a LOCATOR parameter in the 1233 following HIP packets: R1, I2, UPDATE, and NOTIFY. 1235 This document describes sending both ESP_INFO and LOCATOR parameters 1236 in an UPDATE. The ESP_INFO parameter is included when there is a 1237 need to rekey or key a new SPI, and is otherwise included for the 1238 possible benefit of HIP-aware middleboxes. The LOCATOR parameter 1239 contains a complete map of the locators that the host wishes to make 1240 or keep active for the HIP association. 1242 In general, the processing of a LOCATOR depends upon the packet type 1243 in which it is included. Here, we describe only the case in which 1244 ESP_INFO is present and a single LOCATOR and ESP_INFO are sent in an 1245 UPDATE message; other cases are for further study. The steps below 1246 cover each of the cases described in Section 5.2. 1248 The processing of ESP_INFO and LOCATOR parameters is intended to be 1249 modular and support future generalization to the inclusion of 1250 multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD 1251 first process the ESP_INFO before the LOCATOR, since the ESP_INFO may 1252 contain a new SPI value mapped to an existing SPI, while a Type 1 1253 locator will only contain reference to the new SPI. 1255 When a host receives a validated HIP UPDATE with a LOCATOR and 1256 ESP_INFO parameter, it processes the ESP_INFO as follows. The 1257 ESP_INFO parameter indicates whether a SA is being rekeyed, created, 1258 deprecated, or just identified for the benefit of middleboxes. The 1259 host examines the Old SPI and New SPI values in the ESP_INFO 1260 parameter: 1262 1. (no rekeying) If the Old SPI is equal to the New SPI and both 1263 correspond to an existing SPI, the ESP_INFO is gratuitous 1264 (provided for middleboxes) and no rekeying is necessary. 1266 2. (rekeying) If the Old SPI indicates an existing SPI and the New 1267 SPI is a different non-zero value, the existing SA is being 1268 rekeyed and the host follows HIP ESP rekeying procedures by 1269 creating a new outbound SA with an SPI corresponding to the New 1270 SPI, with no addresses bound to this SPI. Note that locators in 1271 the LOCATOR parameter will reference this new SPI instead of the 1272 old SPI. 1274 3. (new SA) If the Old SPI value is zero and the New SPI is a new 1275 non-zero value, then a new SA is being requested by the peer. 1276 This case is also treated like a rekeying event; the receiving 1277 host must create a new SA and respond with an UPDATE ACK. 1279 4. (deprecating of SA) If the Old SPI indicates an existing SPI and 1280 the New SPI is zero, the SA is being deprecated and all locators 1281 uniquely bound to the SPI are put into DEPRECATED state. 1283 If none of the above cases apply, a protocol error has occurred and 1284 the processing of the UPDATE is stopped. 1286 Next, the locators in the LOCATOR parameter are processed. For each 1287 locator listed in the LOCATOR parameter, check that the address 1288 therein is a legal unicast or anycast address. That is, the address 1289 MUST NOT be a broadcast or multicast address. Note that some 1290 implementations MAY accept addresses that indicate the local host, 1291 since it may be allowed that the host runs HIP with itself. 1293 The below assumes that all locators are of Type 1 with a Traffic Type 1294 of 0; other cases are for further study. 1296 For each Type 1 address listed in the LOCATOR parameter, the host 1297 checks whether the address is already bound to the SPI indicated. If 1298 the address is already bound, its lifetime is updated. If the status 1299 of the address is DEPRECATED, the status is changed to UNVERIFIED. 1300 If the address is not already bound, the address is added, and its 1301 status is set to UNVERIFIED. Mark all addresses corresponding to the 1302 SPI that were NOT listed in the LOCATOR parameter as DEPRECATED. 1304 As a result, at the end of processing, the addresses listed in the 1305 LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and 1306 any old addresses on the old SA not listed in the LOCATOR parameter 1307 have a state of DEPRECATED. 1309 Once the host has processed the locators, if the LOCATOR parameter 1310 contains a new Preferred locator, the host SHOULD initiate a change 1311 of the Preferred locator. This requires that the host first verifies 1312 reachability of the associated address, and only then changes the 1313 Preferred locator. See Section 5.5. 1315 If a host receives a locator with an unsupported Locator Type, when 1316 such locator is also declared to be the Preferred locator for the 1317 peer, the host SHOULD send a NOTIFY error with a Notify Message Type 1318 of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field 1319 containing the locator(s) that the receiver failed to process. 1320 Otherwise, a host MAY send a NOTIFY error if a (non-preferred) 1321 locator with an unsupported Locator Type is received in a LOCATOR 1322 parameter. 1324 5.4. Verifying address reachability 1326 A host MUST verify the reachability of an UNVERIFIED address. The 1327 status of a newly learned address MUST initially be set to UNVERIFIED 1328 unless the new address is advertised in a R1 packet as a new 1329 Preferred locator. A host MAY also want to verify the reachability 1330 of an ACTIVE address again after some time, in which case it would 1331 set the status of the address to UNVERIFIED and reinitiate address 1332 verification 1334 A host typically starts the address-verification procedure by sending 1335 a nonce to the new address. For example, when the host is changing 1336 its SPI and is sending an ESP_INFO to the peer, the new SPI value 1337 SHOULD be random and the value MAY be copied into an ECHO_REQUEST 1338 sent in the rekeying UPDATE. However, if the host is not changing 1339 its SPI, it MAY still use the ECHO_REQUEST parameter in an UPDATE 1340 message sent to the new address. A host MAY also use other message 1341 exchanges as confirmation of the address reachability. 1343 Note that in the case of receiving a LOCATOR in an R1 and replying 1344 with an I2 to the new address in the LOCATOR, receiving the 1345 corresponding R2 is sufficient proof of reachability for the 1346 Responder's preferred address. Since further address verification of 1347 such address can impede the HIP base exchange, a host MUST NOT 1348 separately verify reachability of a new Preferred locator that was 1349 received on a R1. 1351 In some cases, it MAY be sufficient to use the arrival of data on a 1352 newly advertised SA as implicit address reachability verification as 1353 depicted in Figure 13, instead of waiting for the confirmation via a 1354 HIP packet. In this case, a host advertising a new SPI as part of 1355 its address reachability check SHOULD be prepared to receive traffic 1356 on the new SA. 1358 Mobile host Peer host 1360 prepare incoming SA 1361 new SPI in ESP_INFO (UPDATE) 1362 <----------------------------------- 1363 switch to new outgoing SA 1364 data on new SA 1365 -----------------------------------> 1366 mark address ACTIVE 1368 Figure 13: Address activation via use of new SA 1370 When address verification is in progress for a new Preferred locator, 1371 the host SHOULD select a different locator listed as ACTIVE, if one 1372 such locator is available, to continue communications until address 1373 verification completes. Alternatively, the host MAY use the new 1374 Preferred locator while in UNVERIFIED status to the extent Credit- 1375 Based Authorization permits. Credit-Based Authorization is explained 1376 in Section 5.6. Once address verification succeeds, the status of 1377 the new Preferred locator changes to ACTIVE. 1379 5.5. Changing the Preferred locator 1381 A host MAY want to change the Preferred outgoing locator for 1382 different reasons, e.g., because traffic information or ICMP error 1383 messages indicate that the currently used preferred address may have 1384 become unreachable. Another reason may be due to receiving a LOCATOR 1385 parameter that has the P-bit set. 1387 To change the Preferred locator, the host initiates the following 1388 procedure: 1390 1. If the new Preferred locator has ACTIVE status, the Preferred 1391 locator is changed and the procedure succeeds. 1393 2. If the new Preferred locator has UNVERIFIED status, the host 1394 starts to verify its reachability. The host SHOULD use a 1395 different locator listed as ACTIVE until address verification 1396 completes if one such locator is available. Alternatively, the 1397 host MAY use the new Preferred locator, even though in UNVERIFIED 1398 status, to the extent Credit-Based Authorization permits. Once 1399 address verification succeeds, the status of the new Preferred 1400 locator changes to ACTIVE and its use is no longer governed by 1401 Credit-Based Authorization. 1403 3. If the peer host has not indicated a preference for any address, 1404 then the host picks one of the peer's ACTIVE addresses randomly 1405 or according to policy. This case may arise if, for example, 1406 ICMP error messages arrive that deprecate the Preferred locator, 1407 but the peer has not yet indicated a new Preferred locator. 1409 4. If the new Preferred locator has DEPRECATED status and there is 1410 at least one non-deprecated address, the host selects one of the 1411 non-deprecated addresses as a new Preferred locator and 1412 continues. If the selected address is UNVERIFIED, this includes 1413 address verification as described above. 1415 5.6. Credit-Based Authorization 1417 To prevent redirection-based flooding attacks, the use of a Credit- 1418 Based Authorization (CBA) approach is mandatory when a host sends 1419 data to an UNVERIFIED locator. The following algorithm meets the 1420 security considerations for prevention of amplification and time- 1421 shifting attacks. Other forms of credit aging, and other values for 1422 the CreditAgingFactor and CreditAgingInterval parameters in 1423 particular, are for further study, and so are the advanced CBA 1424 techniques specified in [10]. 1426 5.6.1. Handling Payload Packets 1428 A host maintains a "credit counter" for each of its peers. Whenever 1429 a packet arrives from a peer, the host SHOULD increase that peer's 1430 credit counter by the size of the received packet. When the host has 1431 a packet to be sent to the peer, and when the peer's Preferred 1432 locator is listed as UNVERIFIED and no alternative locator with 1433 status ACTIVE is available, the host checks whether it can send the 1434 packet to the UNVERIFIED locator. The packet SHOULD be sent if the 1435 value of the credit counter is higher than the size of the outbound 1436 packet. If the credit counter is too low, the packet MUST be 1437 discarded or buffered until address verification succeeds. When a 1438 packet is sent to a peer at an UNVERIFIED locator, the peer's credit 1439 counter MUST be reduced by the size of the packet. The peer's credit 1440 counter is not affected by packets that the host sends to an ACTIVE 1441 locator of that peer. 1443 Figure 14 depicts the actions taken by the host when a packet is 1444 received. Figure 15 shows the decision chain in the event a packet 1445 is sent. 1447 Inbound 1448 packet 1449 | 1450 | +----------------+ +---------------+ 1451 | | Increase | | Deliver | 1452 +-----> | credit counter |-------------> | packet to | 1453 | by packet size | | application | 1454 +----------------+ +---------------+ 1456 Figure 14: Receiving Packets with Credit-Based Authorization 1458 Outbound 1459 packet 1460 | _________________ 1461 | / \ +---------------+ 1462 | / Is the preferred \ No | Send packet | 1463 +-----> | destination address |-------------> | to preferred | 1464 \ UNVERIFIED? / | address | 1465 \_________________/ +---------------+ 1466 | 1467 | Yes 1468 | 1469 v 1470 _________________ 1471 / \ +---------------+ 1472 / Does an ACTIVE \ Yes | Send packet | 1473 | destination address |-------------> | to ACTIVE | 1474 \ exist? / | address | 1475 \_________________/ +---------------+ 1476 | 1477 | No 1478 | 1479 v 1480 _________________ 1481 / \ +---------------+ 1482 / Credit counter \ No | | 1483 | >= |-------------> | Drop packet | 1484 \ packet size? / | | 1485 \_________________/ +---------------+ 1486 | 1487 | Yes 1488 | 1489 v 1490 +---------------+ +---------------+ 1491 | Reduce credit | | Send packet | 1492 | counter by |----------------> | to preferred | 1493 | packet size | | address | 1494 +---------------+ +---------------+ 1496 Figure 15: Sending Packets with Credit-Based Authorization 1498 5.6.2. Credit Aging 1500 A host ensures that the credit counters it maintains for its peers 1501 gradually decrease over time. Such "credit aging" prevents a 1502 malicious peer from building up credit at a very slow speed and using 1503 this, all at once, for a severe burst of redirected packets. 1505 Credit aging may be implemented by multiplying credit counters with a 1506 factor, CreditAgingFactor (a fractional value less than one), in 1507 fixed time intervals of CreditAgingInterval length. Choosing 1508 appropriate values for CreditAgingFactor and CreditAgingInterval is 1509 important to ensure that a host can send packets to an address in 1510 state UNVERIFIED even when the peer sends at a lower rate than the 1511 host itself. When CreditAgingFactor or CreditAgingInterval are too 1512 small, the peer's credit counter might be too low to continue sending 1513 packets until address verification concludes. 1515 The parameter values proposed in this document are as follows: 1517 CreditAgingFactor 7/8 1518 CreditAgingInterval 5 seconds 1520 These parameter values work well when the host transfers a file to 1521 the peer via a TCP connection and the end-to-end round-trip time does 1522 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1523 use other parameter values or different parameters, which may even be 1524 dynamically established. 1526 6. Security Considerations 1528 The HIP mobility mechanism provides a secure means of updating a 1529 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1530 cryptographically verifies the sender of an UPDATE, so forging or 1531 replaying a HIP UPDATE packet is very difficult (see [2]). 1532 Therefore, security issues reside in other attack domains. The two 1533 we consider are malicious redirection of legitimate connections as 1534 well as redirection-based flooding attacks using this protocol. This 1535 can be broken down into the following: 1537 Impersonation attacks 1539 - direct conversation with the misled victim 1541 - man-in-the-middle attack 1543 DoS attacks 1545 - flooding attacks (== bandwidth-exhaustion attacks) 1547 * tool 1: direct flooding 1549 * tool 2: flooding by zombies 1551 * tool 2: redirection-based flooding 1553 - memory-exhaustion attacks 1555 - computational exhaustion attacks 1557 We consider these in more detail in the following sections. 1559 In Section 6.1 and Section 6.2, we assume that all users are using 1560 HIP. In Section 6.3 we consider the security ramifications when we 1561 have both HIP and non-HIP users. Security considerations for Credit- 1562 Based Authorization are discussed in [11]. 1564 6.1. Impersonation attacks 1566 An attacker wishing to impersonate will try to mislead its victim 1567 into directly communicating with them, or carry out a man in the 1568 middle attack between the victim and the victim's desired 1569 communication peer. Without mobility support, both attack types are 1570 possible only if the attacker resides on the routing path between its 1571 victim and the victim's desired communication peer, or if the 1572 attacker tricks its victim into initiating the connection over an 1573 incorrect routing path (e.g., by acting as a router or using spoofed 1574 DNS entries). 1576 The HIP extensions defined in this specification change the situation 1577 in that they introduce an ability to redirect a connection (like 1578 IPv6), both before and after establishment. If no precautionary 1579 measures are taken, an attacker could misuse the redirection feature 1580 to impersonate a victim's peer from any arbitrary location. The 1581 authentication and authorization mechanisms of the HIP base exchange 1582 [2] and the signatures in the UPDATE message prevent this attack. 1583 Furthermore, ownership of a HIP association is securely linked to a 1584 HIP HI/HIT. If an attacker somehow uses a bug in the implementation 1585 or weakness in some protocol to redirect a HIP connection, the 1586 original owner can always reclaim their connection (they can always 1587 prove ownership of the private key associated with their public HI). 1589 MitM attacks are always possible if the attacker is present during 1590 the initial HIP base exchange and if the hosts do not authenticate 1591 each other's identities. However, once the opportunistic base 1592 exchange has taken place, even a MitM cannot steal the HIP connection 1593 anymore because it is very difficult for an attacker to create an 1594 UPDATE packet (or any HIP packet) that will be accepted as a 1595 legitimate update. UPDATE packets use HMAC and are signed. Even 1596 when an attacker can snoop packets to obtain the SPI and HIT/HI, they 1597 still cannot forge an UPDATE packet without knowledge of the secret 1598 keys. 1600 6.2. Denial of Service attacks 1602 6.2.1. Flooding Attacks 1604 The purpose of a denial-of-service attack is to exhaust some resource 1605 of the victim such that the victim ceases to operate correctly. A 1606 denial-of-service attack can aim at the victim's network attachment 1607 (flooding attack), its memory, or its processing capacity. In a 1608 flooding attack the attacker causes an excessive number of bogus or 1609 unwanted packets to be sent to the victim, which fills their 1610 available bandwidth. Note that the victim does not necessarily need 1611 to be a node; it can also be an entire network. The attack basically 1612 functions the same way in either case. 1614 An effective DoS strategy is distributed denial of service (DDoS). 1615 Here, the attacker conventionally distributes some viral software to 1616 as many nodes as possible. Under the control of the attacker, the 1617 infected nodes, or "zombies", jointly send packets to the victim. 1618 With such an 'army', an attacker can take down even very high 1619 bandwidth networks/victims. 1621 With the ability to redirect connections, an attacker could realize a 1622 DDoS attack without having to distribute viral code. Here, the 1623 attacker initiates a large download from a server, and subsequently 1624 redirects this download to its victim. The attacker can repeat this 1625 with multiple servers. This threat is mitigated through reachability 1626 checks and credit-based authorization. Both strategies do not 1627 eliminate flooding attacks per se, but they preclude: (i) their use 1628 from a location off the path towards the flooded victim; and (ii) any 1629 amplification in the number and size of the redirected packets. As a 1630 result, the combination of a reachability check and credit-based 1631 authorization lowers a HIP redirection-based flooding attack to the 1632 level of a direct flooding attack in which the attacker itself sends 1633 the flooding traffic to the victim. 1635 6.2.2. Memory/Computational exhaustion DoS attacks 1637 We now consider whether or not the proposed extensions to HIP add any 1638 new DoS attacks (consideration of DoS attacks using the base HIP 1639 exchange and updates is discussed in [2]). A simple attack is to 1640 send many UPDATE packets containing many IP addresses that are not 1641 flagged as preferred. The attacker continues to send such packets 1642 until the number of IP addresses associated with the attacker's HI 1643 crashes the system. Therefore, there SHOULD be a limit to the number 1644 of IP addresses that can be associated with any HI. Other forms of 1645 memory/computationally exhausting attacks via the HIP UPDATE packet 1646 are handled in the base HIP draft [2]. 1648 A central server that has to deal with a large number of mobile 1649 clients may consider increasing the SA lifetimes to try to slow down 1650 the rate of rekeying UPDATEs or increasing the cookie difficulty to 1651 slow down the rate of attack-oriented connections. 1653 6.3. Mixed deployment environment 1655 We now assume an environment with both HIP and non-HIP aware hosts. 1656 Four cases exist. 1658 1. A HIP host redirects its connection onto a non-HIP host. The 1659 non-HIP host will drop the reachability packet, so this is not a 1660 threat unless the HIP host is a MitM that could somehow respond 1661 successfully to the reachability check. 1663 2. A non-HIP host attempts to redirect their connection onto a HIP 1664 host. This falls into IPv4 and IPv6 security concerns, which are 1665 outside the scope of this document. 1667 3. A non-HIP host attempts to steal a HIP host's session (assume 1668 that Secure Neighbor Discovery is not active for the following). 1669 The non-HIP host contacts the service that a HIP host has a 1670 connection with and then attempts to change its IP address to 1671 steal the HIP host's connection. What will happen in this case 1672 is implementation dependent but such a request should fail by 1673 being ignored or dropped. Even if the attack were successful, 1674 the HIP host could reclaim its connection via HIP. 1676 4. A HIP host attempts to steal a non-HIP host's session. A HIP 1677 host could spoof the non-HIP host's IP address during the base 1678 exchange or set the non-HIP host's IP address as its preferred 1679 address via an UPDATE. Other possibilities exist but a simple 1680 solution is to prevent use of HIP address check information to 1681 influence non-HIP sessions. 1683 7. IANA Considerations 1685 This document defines a LOCATOR parameter for the Host Identity 1686 Protocol [2]. This parameter is defined in Section 4 with a Type of 1687 193. 1689 This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message 1690 Type as defined in the Host Identity Protocol specification [2]. 1691 This parameter is defined in Section 5.3 with a Value of 46. 1693 8. Authors and Acknowledgments 1695 Pekka Nikander originated this Internet Draft. Tom Henderson, Jari 1696 Arkko, Greg Perkins, and Christian Vogt have each contributed 1697 sections to this draft. 1699 The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan 1700 Melen for many improvements to the draft. 1702 9. References 1704 9.1. Normative references 1706 [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1707 Architecture", RFC 4423, August 2005. 1709 [2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 1710 (work in progress), February 2007. 1712 [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1713 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 1714 progress), June 2006. 1716 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1717 December 2005. 1719 [5] Draves, R., "Default Address Selection for Internet Protocol 1720 version 6 (IPv6)", RFC 3484, February 2003. 1722 [6] Jokela, P., "Using ESP transport format with HIP", 1723 draft-ietf-hip-esp-05 (work in progress), February 2007. 1725 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1726 Levels", BCP 14, RFC 2119, March 1997. 1728 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 1729 Architecture", RFC 2373, July 1998. 1731 9.2. Informative references 1733 [9] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1734 Nordmark, "Mobile IP Version 6 Route Optimization Security 1735 Design Background", RFC 4225, December 2005. 1737 [10] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile 1738 IPv6 Early Binding Updates", 1739 draft-vogt-mobopts-credit-based-authorization-00 (work in 1740 progress), February 2005. 1742 [11] Vogt, C. and J. Arkko, "Credit-Based Authorization for 1743 Concurrent Reachability Verification", 1744 draft-vogt-mobopts-simple-cba-00 (work in progress), 1745 February 2006. 1747 Appendix A. Changes from previous versions 1749 A.1. From nikander-hip-mm-00 to nikander-hip-mm-01 1751 The actual protocol has been largely revised, based on the new 1752 symmetric New SPI (NES) design adopted in the base protocol draft 1753 version -08. There are no more separate REA, AC or ACR packets, but 1754 their functionality has been folded into the NES packet. At the same 1755 time, it has become possible to send REA parameters in R1 and I2. 1757 The Forwarding Agent functionality was removed, since it looks like 1758 that it will be moved to the proposed HIP Research Group. Hence, 1759 there will be two other documents related to that, a simple 1760 Rendezvous server document (WG item) and a Forwarding Agent document 1761 (RG item). 1763 A.2. From nikander-hip-mm-01 to nikander-hip-mm-02 1765 Alignment with base-00 draft (use of UPDATE and NOTIFY packets). 1767 The "logical interface" concept was dropped, and the SA/SPI was 1768 identified as the protocol component to which a HIP association binds 1769 addresses to. 1771 The RR was (again) made recommended, not mandatory, able to be 1772 administratively overridden. 1774 A.3. From -02 to draft-ietf-hip-mm-00 1776 REA parameter type value is now "3" (was TBD before). 1778 Recommend that in multihoming situations, that inbound/outbound SAs 1779 are paired to avoid ambiguity when rekeying them. 1781 Clarified that multihoming scenario for now was intended for failover 1782 instead of load-balancing, due to transport layer issues. 1784 Clarified that if HIP negotiates base exchange using link local 1785 addresses, that a host SHOULD provide its peer with a globally 1786 reachable address. 1788 Clarified whether REAs sent for existing SPIs update the full set of 1789 addresses associated with that SPI, or only perform an incremental 1790 (additive) update. REAs for an existing SPI should list all current 1791 addresses for that SPI, and any addresses previously in use on the 1792 SPI but not in the new REA parameter should be DEPRECATED. 1794 Clarified that address verification pertains to *outgoing* addresses. 1796 When discussing inclusion of REA in I2, the draft stated "The 1797 Responder MUST make sure that the puzzle solution is valid BOTH for 1798 the initial IP destination address used for I1 and for the new 1799 preferred address." However, this statement conflicted with Appendix 1800 D of the base specification, so it has been removed for now. 1802 A.4. From draft-ietf-hip-mm-00 to -01 1804 Introduction section reorganized. Some of the scope of the document 1805 relating to multihoming was reduced. 1807 Removed empty appendix "Implementation experiences" 1809 Renamed REA parameter to LOCATOR and aligned to the discussion on 1810 redefining this parameter that occurred on the RG mailing list. 1812 Aligned with decoupling of ESP from base spec. 1814 A.5. From draft-ietf-hip-mm-01 to -02 1816 Aligned with draft-ietf-hip-base-03 and draft-ietf-hip-esp-00 1818 Address verification is a MUST (C. Vogt, list post on 06/12/05) 1820 If UPDATE exceeds MTU because of too many locators, do not split into 1821 multiple UPDATEs, but instead rely on IP fragmentation (C. Vogt, list 1822 post on 06/12/05) 1824 New value for LOCATOR parameter type (193), per 05/31/05 discussion 1825 on the WG list 1827 Various additions related to Credit-Based Authorization due to C. 1828 Vogt 1830 Security section contributed by Greg Perkins, with subsequent editing 1831 from C. Vogt and P. Nikander 1833 Reorganization according to RFC 4101 guidance on writing protocol 1834 models 1836 Open issue: LOCATOR parameter semantics (implicit/explicit removal) 1838 A.6. From draft-ietf-hip-mm-02 to -03 1840 Aligned with draft-ietf-hip-base-05 and draft-ietf-hip-esp-02 1842 Further clarification that the scope of this draft is primarily 1843 limited to the case in which ESP is used 1844 New layered architectural overview in Section 3 1846 Limited the scope of multihoming description to just a single host 1847 adding a single new address; other cases left for further study 1849 Require that ESP_INFO be included on all UPDATE packets relating to 1850 mobility and multihoming (for middleboxes) 1852 New convention for use of "Old SPI" and "New SPI" values to signal 1853 new SPIs (Old SPI == 0, New SPI != 0) and gratuitous ESP_INFOs with 1854 no rekeying (Old SPI == New SPI != 0). 1856 Only specify the use of Locator Type of 1 when using ESP, for 1857 simplicity of receiver processing. 1859 Removed multiple addresses in LOCATOR example of section 3.2.2, 1860 because it is not clear that the example is correct (requires further 1861 study) 1863 Corrected mention of sending ECHO_REQUEST nonce in R2 (should be sent 1864 in separate UPDATE because R2 is not an acknowledged packet) 1866 Removed first four paragraphs of Section 5, which were redundant with 1867 previous introductory material. 1869 Rewrote Sections 5.2 and 5.3 on sending and receiving LOCATOR, to 1870 more explicitly cover the scenario scope of this document. 1872 Removed unwritten "Policy Considerations" section 1874 A.7. From draft-ietf-hip-mm-03 to -04 1876 Responded to numerous WGLC comments and corrections from Miika Komu 1877 (responses on the HIP mailing list) 1879 A.8. From draft-ietf-hip-mm-04 to -05 1881 Responded to Jeffrey Hutzelman comments as part of IETF secdir 1882 review, and discussion with Christian Vogt. This includes clarifying 1883 how UPDATE retransmissions are handled, a clarification on Credit- 1884 Based Authorization flooding attacks, how to handle unsupported 1885 Locator Type values, and the announcement of link-local addresses. 1887 Handled several editorial comments from Marcelo Bagnulo Braun 1888 regarding the host multihoming procedures. 1890 New use-case section by Marcelo Bagnulo Braun to clarify the 1891 multihoming case of sequential address usage (to be provided) 1893 Author's Address 1895 Tom Henderson 1896 The Boeing Company 1897 P.O. Box 3707 1898 Seattle, WA 1899 USA 1901 Email: thomas.r.henderson@boeing.com 1903 Full Copyright Statement 1905 Copyright (C) The IETF Trust (2007). 1907 This document is subject to the rights, licenses and restrictions 1908 contained in BCP 78, and except as set forth therein, the authors 1909 retain all their rights. 1911 This document and the information contained herein are provided on an 1912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1914 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1915 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1916 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1919 Intellectual Property 1921 The IETF takes no position regarding the validity or scope of any 1922 Intellectual Property Rights or other rights that might be claimed to 1923 pertain to the implementation or use of the technology described in 1924 this document or the extent to which any license under such rights 1925 might or might not be available; nor does it represent that it has 1926 made any independent effort to identify any such rights. Information 1927 on the procedures with respect to rights in RFC documents can be 1928 found in BCP 78 and BCP 79. 1930 Copies of IPR disclosures made to the IETF Secretariat and any 1931 assurances of licenses to be made available, or the result of an 1932 attempt made to obtain a general license or permission for the use of 1933 such proprietary rights by implementers or users of this 1934 specification can be obtained from the IETF on-line IPR repository at 1935 http://www.ietf.org/ipr. 1937 The IETF invites any interested party to bring to its attention any 1938 copyrights, patents or patent applications, or other proprietary 1939 rights that may cover technology that may be required to implement 1940 this standard. Please address the information to the IETF at 1941 ietf-ipr@ietf.org. 1943 Acknowledgment 1945 Funding for the RFC Editor function is provided by the IETF 1946 Administrative Support Activity (IASA).