idnits 2.17.1 draft-henderson-hip-rfc5206-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5206, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 3, 2010) is 5224 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 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) ** Obsolete normative reference: RFC 5204 (Obsoleted by RFC 8004) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft Ericsson Research NomadicLab 4 Obsoletes: 5206 (if approved) T. Henderson, Ed. 5 Intended status: Standards Track The Boeing Company 6 Expires: July 7, 2010 C. Vogt 7 J. Arkko 8 Ericsson Research NomadicLab 9 January 3, 2010 11 End-Host Mobility and Multihoming with the Host Identity Protocol 12 draft-henderson-hip-rfc5206-bis-00 14 Abstract 16 This document defines mobility and multihoming extensions to the Host 17 Identity Protocol (HIP). Specifically, this document defines a 18 general "LOCATOR" parameter for HIP messages that allows for a HIP 19 host to notify peers about alternate addresses at which it may be 20 reached. This document also defines elements of procedure for 21 mobility of a HIP host -- the process by which a host dynamically 22 changes the primary locator that it uses to receive packets. While 23 the same LOCATOR parameter can also be used to support end-host 24 multihoming, detailed procedures are left for further study. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on July 7, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 79 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 80 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6 82 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 84 3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 9 85 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 86 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 10 87 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated 88 Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 12 89 3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 12 90 3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 14 91 3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14 92 3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 15 93 3.2.7. Using LOCATORs across Addressing Realms . . . . . . . 15 94 3.2.8. Network Renumbering . . . . . . . . . . . . . . . . . 15 95 3.2.9. Initiating the Protocol in R1 or I2 . . . . . . . . . 16 96 3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 17 97 3.3.1. Address Verification . . . . . . . . . . . . . . . . . 17 98 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 17 99 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 19 100 3.3.4. Interaction with Security Associations . . . . . . . . 19 101 4. LOCATOR Parameter Format . . . . . . . . . . . . . . . . . . . 22 102 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . . 24 103 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 24 104 4.3. UPDATE Packet with Included LOCATOR . . . . . . . . . . . 25 105 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 25 106 5.1. Locator Data Structure and Status . . . . . . . . . . . . 25 107 5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 26 108 5.3. Handling Received LOCATORs . . . . . . . . . . . . . . . . 28 109 5.4. Verifying Address Reachability . . . . . . . . . . . . . . 30 110 5.5. Changing the Preferred Locator . . . . . . . . . . . . . . 32 111 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32 112 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 33 113 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 34 114 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 115 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 36 116 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 37 117 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 37 118 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 37 119 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . . 38 120 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 121 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 39 122 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 123 9.1. Normative references . . . . . . . . . . . . . . . . . . . 39 124 9.2. Informative references . . . . . . . . . . . . . . . . . . 39 125 Appendix A. Document Revision History . . . . . . . . . . . . . . 40 127 1. Introduction and Scope 129 The Host Identity Protocol [RFC4423] (HIP) supports an architecture 130 that decouples the transport layer (TCP, UDP, etc.) from the 131 internetworking layer (IPv4 and IPv6) by using public/private key 132 pairs, instead of IP addresses, as host identities. When a host uses 133 HIP, the overlying protocol sublayers (e.g., transport layer sockets 134 and Encapsulating Security Payload (ESP) Security Associations (SAs)) 135 are instead bound to representations of these host identities, and 136 the IP addresses are only used for packet forwarding. However, each 137 host must also know at least one IP address at which its peers are 138 reachable. Initially, these IP addresses are the ones used during 139 the HIP base exchange [RFC5201]. 141 One consequence of such a decoupling is that new solutions to 142 network-layer mobility and host multihoming are possible. There are 143 potentially many variations of mobility and multihoming possible. 144 The scope of this document encompasses messaging and elements of 145 procedure for basic network-level mobility and simple multihoming, 146 leaving more complicated scenarios and other variations for further 147 study. More specifically: 149 This document defines a generalized LOCATOR parameter for use in 150 HIP messages. The LOCATOR parameter allows a HIP host to notify a 151 peer about alternate addresses at which it is reachable. The 152 LOCATORs may be merely IP addresses, or they may have additional 153 multiplexing and demultiplexing context to aid the packet handling 154 in the lower layers. For instance, an IP address may need to be 155 paired with an ESP Security Parameter Index (SPI) so that packets 156 are sent on the correct SA for a given address. 158 This document also specifies the messaging and elements of 159 procedure for end-host mobility of a HIP host -- the sequential 160 change in the preferred IP address used to reach a host. In 161 particular, message flows to enable successful host mobility, 162 including address verification methods, are defined herein. 164 However, while the same LOCATOR parameter is intended to support 165 host multihoming (parallel support of a number of addresses), and 166 experimentation is encouraged, detailed elements of procedure for 167 host multihoming are left for further study. 169 While HIP can potentially be used with transports other than the ESP 170 transport format [RFC5202], this document largely assumes the use of 171 ESP and leaves other transport formats for further study. 173 There are a number of situations where the simple end-to-end 174 readdressing functionality is not sufficient. These include the 175 initial reachability of a mobile host, location privacy, simultaneous 176 mobility of both hosts, and some modes of NAT traversal. In these 177 situations, there is a need for some helper functionality in the 178 network, such as a HIP rendezvous server [RFC5204]. Such 179 functionality is out of the scope of this document. We also do not 180 consider localized mobility management extensions (i.e., mobility 181 management techniques that do not involve directly signaling the 182 correspondent node); this document is concerned with end-to-end 183 mobility. Finally, making underlying IP mobility transparent to the 184 transport layer has implications on the proper response of transport 185 congestion control, path MTU selection, and Quality of Service (QoS). 186 Transport-layer mobility triggers, and the proper transport response 187 to a HIP mobility or multihoming address change, are outside the 188 scope of this document. 190 2. Terminology and Conventions 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 LOCATOR. The name of a HIP parameter containing zero or more Locator 197 fields. This parameter's name is distinguished from the Locator 198 fields embedded within it by the use of all capital letters. 200 Locator. A name that controls how the packet is routed through the 201 network and demultiplexed by the end host. It may include a 202 concatenation of traditional network addresses such as an IPv6 203 address and end-to-end identifiers such as an ESP SPI. It may 204 also include transport port numbers or IPv6 Flow Labels as 205 demultiplexing context, or it may simply be a network address. 207 Address. A name that denotes a point-of-attachment to the network. 208 The two most common examples are an IPv4 address and an IPv6 209 address. The set of possible addresses is a subset of the set of 210 possible locators. 212 Preferred locator. A locator on which a host prefers to receive 213 data. With respect to a given peer, a host always has one active 214 Preferred locator, unless there are no active locators. By 215 default, the locators used in the HIP base exchange are the 216 Preferred locators. 218 Credit Based Authorization. A host must verify a mobile or 219 multihomed peer's reachability at a new locator. Credit-Based 220 Authorization authorizes the peer to receive a certain amount of 221 data at the new locator before the result of such verification is 222 known. 224 3. Protocol Model 226 This section is an overview; more detailed specification follows this 227 section. 229 3.1. Operating Environment 231 The Host Identity Protocol (HIP) [RFC5201] is a key establishment and 232 parameter negotiation protocol. Its primary applications are for 233 authenticating host messages based on host identities, and 234 establishing security associations (SAs) for the ESP transport format 235 [RFC5202] and possibly other protocols in the future. 237 +--------------------+ +--------------------+ 238 | | | | 239 | +------------+ | | +------------+ | 240 | | Key | | HIP | | Key | | 241 | | Management | <-+-----------------------+-> | Management | | 242 | | Process | | | | Process | | 243 | +------------+ | | +------------+ | 244 | ^ | | ^ | 245 | | | | | | 246 | v | | v | 247 | +------------+ | | +------------+ | 248 | | IPsec | | ESP | | IPsec | | 249 | | Stack | <-+-----------------------+-> | Stack | | 250 | | | | | | | | 251 | +------------+ | | +------------+ | 252 | | | | 253 | | | | 254 | Initiator | | Responder | 255 +--------------------+ +--------------------+ 257 Figure 1: HIP Deployment Model 259 The general deployment model for HIP is shown above, assuming 260 operation in an end-to-end fashion. This document specifies 261 extensions to the HIP protocol to enable end-host mobility and basic 262 multihoming. In summary, these extensions to the HIP base protocol 263 enable the signaling of new addressing information to the peer in HIP 264 messages. The messages are authenticated via a signature or keyed 265 hash message authentication code (HMAC) based on its Host Identity. 266 This document specifies the format of this new addressing (LOCATOR) 267 parameter, the procedures for sending and processing this parameter 268 to enable basic host mobility, and procedures for a concurrent 269 address verification mechanism. 271 --------- 272 | TCP | (sockets bound to HITs) 273 --------- 274 | 275 --------- 276 ----> | ESP | {HIT_s, HIT_d} <-> SPI 277 | --------- 278 | | 279 ---- --------- 280 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 281 ---- --------- 282 | 283 --------- 284 | IP | 285 --------- 287 Figure 2: Architecture for HIP Mobility and Multihoming (MH) 289 Figure 2 depicts a layered architectural view of a HIP-enabled stack 290 using the ESP transport format. In HIP, upper-layer protocols 291 (including TCP and ESP in this figure) are bound to Host Identity 292 Tags (HITs) and not IP addresses. The HIP sublayer is responsible 293 for maintaining the binding between HITs and IP addresses. The SPI 294 is used to associate an incoming packet with the right HITs. The 295 block labeled "MH" is introduced below. 297 Consider first the case in which there is no mobility or multihoming, 298 as specified in the base protocol specification [RFC5201]. The HIP 299 base exchange establishes the HITs in use between the hosts, the SPIs 300 to use for ESP, and the IP addresses (used in both the HIP signaling 301 packets and ESP data packets). Note that there can only be one such 302 set of bindings in the outbound direction for any given packet, and 303 the only fields used for the binding at the HIP layer are the fields 304 exposed by ESP (the SPI and HITs). For the inbound direction, the 305 SPI is all that is required to find the right host context. ESP 306 rekeying events change the mapping between the HIT pair and SPI, but 307 do not change the IP addresses. 309 Consider next a mobility event, in which a host is still single-homed 310 but moves to another IP address. Two things must occur in this case. 311 First, the peer must be notified of the address change using a HIP 312 UPDATE message. Second, each host must change its local bindings at 313 the HIP sublayer (new IP addresses). It may be that both the SPIs 314 and IP addresses are changed simultaneously in a single UPDATE; the 315 protocol described herein supports this. However, simultaneous 316 movement of both hosts, notification of transport layer protocols of 317 the path change, and procedures for possibly traversing middleboxes 318 are not covered by this document. 320 Finally, consider the case when a host is multihomed (has more than 321 one globally routable address) and has multiple addresses available 322 at the HIP layer as alternative locators for fault tolerance. 323 Examples include the use of (possibly multiple) IPv4 and IPv6 324 addresses on the same interface, or the use of multiple interfaces 325 attached to different service providers. Such host multihoming 326 generally necessitates that a separate ESP SA is maintained for each 327 interface in order to prevent packets that arrive over different 328 paths from falling outside of the ESP anti-replay window [RFC4303]. 329 Multihoming thus makes it possible that the bindings shown on the 330 right side of Figure 2 are one to many (in the outbound direction, 331 one HIT pair to multiple SPIs, and possibly then to multiple IP 332 addresses). However, only one SPI and address pair can be used for 333 any given packet, so the job of the "MH" block depicted above is to 334 dynamically manipulate these bindings. Beyond locally managing such 335 multiple bindings, the peer-to-peer HIP signaling protocol needs to 336 be flexible enough to define the desired mappings between HITs, SPIs, 337 and addresses, and needs to ensure that UPDATE messages are sent 338 along the right network paths so that any HIP-aware middleboxes can 339 observe the SPIs. This document does not specify the "MH" block, nor 340 does it specify detailed elements of procedure for how to handle 341 various multihoming (perhaps combined with mobility) scenarios. The 342 "MH" block may apply to more general problems outside of HIP. 343 However, this document does describe a basic multihoming case (one 344 host adds one address to its initial address and notifies the peer) 345 and leave more complicated scenarios for experimentation and future 346 documents. 348 3.1.1. Locator 350 This document defines a generalization of an address called a 351 "locator". A locator specifies a point-of-attachment to the network 352 but may also include additional end-to-end tunneling or per-host 353 demultiplexing context that affects how packets are handled below the 354 logical HIP sublayer of the stack. This generalization is useful 355 because IP addresses alone may not be sufficient to describe how 356 packets should be handled below HIP. For example, in a host 357 multihoming context, certain IP addresses may need to be associated 358 with certain ESP SPIs to avoid violating the ESP anti-replay window. 359 Addresses may also be affiliated with transport ports in certain 360 tunneling scenarios. Locators may simply be traditional network 361 addresses. The format of the locator fields in the LOCATOR parameter 362 is defined in Section 4. 364 3.1.2. Mobility Overview 366 When a host moves to another address, it notifies its peer of the new 367 address by sending a HIP UPDATE packet containing a LOCATOR 368 parameter. This UPDATE packet is acknowledged by the peer. For 369 reliability in the presence of packet loss, the UPDATE packet is 370 retransmitted as defined in the HIP protocol specification [RFC5201]. 371 The peer can authenticate the contents of the UPDATE packet based on 372 the signature and keyed hash of the packet. 374 When using ESP Transport Format [RFC5202], the host may at the same 375 time decide to rekey its security association and possibly generate a 376 new Diffie-Hellman key; all of these actions are triggered by 377 including additional parameters in the UPDATE packet, as defined in 378 the base protocol specification [RFC5201] and ESP extension 379 [RFC5202]. 381 When using ESP (and possibly other transport modes in the future), 382 the host is able to receive packets that are protected using a HIP 383 created ESP SA from any address. Thus, a host can change its IP 384 address and continue to send packets to its peers without necessarily 385 rekeying. However, the peers are not able to send packets to these 386 new addresses before they can reliably and securely update the set of 387 addresses that they associate with the sending host. Furthermore, 388 mobility may change the path characteristics in such a manner that 389 reordering occurs and packets fall outside the ESP anti-replay window 390 for the SA, thereby requiring rekeying. 392 3.1.3. Multihoming Overview 394 A related operational configuration is host multihoming, in which a 395 host has multiple locators simultaneously rather than sequentially, 396 as in the case of mobility. By using the LOCATOR parameter defined 397 herein, a host can inform its peers of additional (multiple) locators 398 at which it can be reached, and can declare a particular locator as a 399 "preferred" locator. Although this document defines a basic 400 mechanism for multihoming, it does not define detailed policies and 401 procedures, such as which locators to choose when more than one pair 402 is available, the operation of simultaneous mobility and multihoming, 403 source address selection policies (beyond those specified in 404 [RFC3484]), and the implications of multihoming on transport 405 protocols and ESP anti-replay windows. Additional definitions of 406 HIP-based multihoming are expected to be part of future documents. 408 3.2. Protocol Overview 410 In this section, we briefly introduce a number of usage scenarios for 411 HIP mobility and multihoming. These scenarios assume that HIP is 412 being used with the ESP transform [RFC5202], although other scenarios 413 may be defined in the future. To understand these usage scenarios, 414 the reader should be at least minimally familiar with the HIP 415 protocol specification [RFC5201]. However, for the (relatively) 416 uninitiated reader, it is most important to keep in mind that in HIP 417 the actual payload traffic is protected with ESP, and that the ESP 418 SPI acts as an index to the right host-to-host context. More 419 specification details are found later in Section 4 and Section 5. 421 The scenarios below assume that the two hosts have completed a single 422 HIP base exchange with each other. Both of the hosts therefore have 423 one incoming and one outgoing SA. Further, each SA uses the same 424 pair of IP addresses, which are the ones used in the base exchange. 426 The readdressing protocol is an asymmetric protocol where a mobile or 427 multihomed host informs a peer host about changes of IP addresses on 428 affected SPIs. The readdressing exchange is designed to be 429 piggybacked on existing HIP exchanges. The majority of the packets 430 on which the LOCATOR parameters are expected to be carried are UPDATE 431 packets. However, some implementations may want to experiment with 432 sending LOCATOR parameters also on other packets, such as R1, I2, and 433 NOTIFY. 435 The scenarios below at times describe addresses as being in either an 436 ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a 437 host, newly-learned addresses of the peer must be verified before put 438 into active service, and addresses removed by the peer are put into a 439 deprecated state. Under limited conditions described below 440 (Section 5.6), an UNVERIFIED address may be used. The addressing 441 states are defined more formally in Section 5.1. 443 Hosts that use link-local addresses as source addresses in their HIP 444 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 445 provide a globally routable address either in the initial handshake 446 or via the LOCATOR parameter. 448 3.2.1. Mobility with a Single SA Pair (No Rekeying) 450 A mobile host must sometimes change an IP address bound to an 451 interface. The change of an IP address might be needed due to a 452 change in the advertised IPv6 prefixes on the link, a reconnected PPP 453 link, a new DHCP lease, or an actual movement to another subnet. In 454 order to maintain its communication context, the host must inform its 455 peers about the new IP address. This first example considers the 456 case in which the mobile host has only one interface, IP address, a 457 single pair of SAs (one inbound, one outbound), and no rekeying 458 occurs on the SAs. We also assume that the new IP addresses are 459 within the same address family (IPv4 or IPv6) as the first address. 460 This is the simplest scenario, depicted in Figure 3. 462 Mobile Host Peer Host 464 UPDATE(ESP_INFO, LOCATOR, SEQ) 465 -----------------------------------> 466 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 467 <----------------------------------- 468 UPDATE(ACK, ECHO_RESPONSE) 469 -----------------------------------> 471 Figure 3: Readdress without Rekeying, but with Address Check 473 The steps of the packet processing are as follows: 475 1. The mobile host is disconnected from the peer host for a brief 476 period of time while it switches from one IP address to another. 477 Upon obtaining a new IP address, the mobile host sends a LOCATOR 478 parameter to the peer host in an UPDATE message. The UPDATE 479 message also contains an ESP_INFO parameter containing the values 480 of the old and new SPIs for a security association. In this 481 case, the OLD SPI and NEW SPI parameters both are set to the 482 value of the preexisting incoming SPI; this ESP_INFO does not 483 trigger a rekeying event but is instead included for possible 484 parameter-inspecting middleboxes on the path. The LOCATOR 485 parameter contains the new IP address (Locator Type of "1", 486 defined below) and a locator lifetime. The mobile host waits for 487 this UPDATE to be acknowledged, and retransmits if necessary, as 488 specified in the base specification [RFC5201]. 490 2. The peer host receives the UPDATE, validates it, and updates any 491 local bindings between the HIP association and the mobile host's 492 destination address. The peer host MUST perform an address 493 verification by placing a nonce in the ECHO_REQUEST parameter of 494 the UPDATE message sent back to the mobile host. It also 495 includes an ESP_INFO parameter with the OLD SPI and NEW SPI 496 parameters both set to the value of the preexisting incoming SPI, 497 and sends this UPDATE (with piggybacked acknowledgment) to the 498 mobile host at its new address. The peer MAY use the new address 499 immediately, but it MUST limit the amount of data it sends to the 500 address until address verification completes. 502 3. The mobile host completes the readdress by processing the UPDATE 503 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 504 host receives this ECHO_RESPONSE, it considers the new address to 505 be verified and can put the address into full use. 507 While the peer host is verifying the new address, the new address is 508 marked as UNVERIFIED in the interim, and the old address is 509 DEPRECATED. Once the peer host has received a correct reply to its 510 UPDATE challenge, it marks the new address as ACTIVE and removes the 511 old address. 513 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) 515 The mobile host may decide to rekey the SAs at the same time that it 516 notifies the peer of the new address. In this case, the above 517 procedure described in Figure 3 is slightly modified. The UPDATE 518 message sent from the mobile host includes an ESP_INFO with the OLD 519 SPI set to the previous SPI, the NEW SPI set to the desired new SPI 520 value for the incoming SA, and the KEYMAT Index desired. Optionally, 521 the host may include a DIFFIE_HELLMAN parameter for a new Diffie- 522 Hellman key. The peer completes the request for a rekey as is 523 normally done for HIP rekeying, except that the new address is kept 524 as UNVERIFIED until the UPDATE nonce challenge is received as 525 described above. Figure 4 illustrates this scenario. 527 Mobile Host Peer Host 529 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 530 -----------------------------------> 531 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 532 <----------------------------------- 533 UPDATE(ACK, ECHO_RESPONSE) 534 -----------------------------------> 536 Figure 4: Readdress with Mobile-Initiated Rekey 538 3.2.3. Host Multihoming 540 A (mobile or stationary) host may sometimes have more than one 541 interface or global address. The host may notify the peer host of 542 the additional interface or address by using the LOCATOR parameter. 543 To avoid problems with the ESP anti-replay window, a host SHOULD use 544 a different SA for each interface or address used to receive packets 545 from the peer host when multiple locator pairs are being used 546 simultaneously rather than sequentially. 548 When more than one locator is provided to the peer host, the host 549 SHOULD indicate which locator is preferred (the locator on which the 550 host prefers to receive traffic). By default, the addresses used in 551 the base exchange are preferred until indicated otherwise. 553 In the multihoming case, the sender may also have multiple valid 554 locators from which to source traffic. In practice, a HIP 555 association in a multihoming configuration may have both a preferred 556 peer locator and a preferred local locator, although rules for source 557 address selection should ultimately govern the selection of the 558 source locator based on the destination locator. 560 Although the protocol may allow for configurations in which there is 561 an asymmetric number of SAs between the hosts (e.g., one host has two 562 interfaces and two inbound SAs, while the peer has one interface and 563 one inbound SA), it is RECOMMENDED that inbound and outbound SAs be 564 created pairwise between hosts. When an ESP_INFO arrives to rekey a 565 particular outbound SA, the corresponding inbound SA should be also 566 rekeyed at that time. Although asymmetric SA configurations might be 567 experimented with, their usage may constrain interoperability at this 568 time. However, it is recommended that implementations attempt to 569 support peers that prefer to use non-paired SAs. It is expected that 570 this section and behavior will be modified in future revisions of 571 this protocol, once the issue and its implications are better 572 understood. 574 Consider the case between two hosts, one single-homed and one 575 multihomed. The multihomed host may decide to inform the single- 576 homed host about its other address. It is RECOMMENDED that the 577 multihomed host set up a new SA pair for use on this new address. To 578 do this, the multihomed host sends a LOCATOR with an ESP_INFO, 579 indicating the request for a new SA by setting the OLD SPI value to 580 zero, and the NEW SPI value to the newly created incoming SPI. A 581 Locator Type of "1" is used to associate the new address with the new 582 SPI. The LOCATOR parameter also contains a second Type "1" locator, 583 that of the original address and SPI. To simplify parameter 584 processing and avoid explicit protocol extensions to remove locators, 585 each LOCATOR parameter MUST list all locators in use on a connection 586 (a complete listing of inbound locators and SPIs for the host). The 587 multihomed host waits for an ESP_INFO (new outbound SA) from the peer 588 and an ACK of its own UPDATE. As in the mobility case, the peer host 589 must perform an address verification before actively using the new 590 address. Figure 5 illustrates this scenario. 592 Multi-homed Host Peer Host 594 UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN]) 595 -----------------------------------> 596 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 597 <----------------------------------- 598 UPDATE(ACK, ECHO_RESPONSE) 599 -----------------------------------> 601 Figure 5: Basic Multihoming Scenario 603 In multihoming scenarios, it is important that hosts receiving 604 UPDATEs associate them correctly with the destination address used in 605 the packet carrying the UPDATE. When processing inbound LOCATORs 606 that establish new security associations on an interface with 607 multiple addresses, a host uses the destination address of the UPDATE 608 containing the LOCATOR as the local address to which the LOCATOR plus 609 ESP_INFO is targeted. This is because hosts may send UPDATEs with 610 the same (locator) IP address to different peer addresses -- this has 611 the effect of creating multiple inbound SAs implicitly affiliated 612 with different peer source addresses. 614 3.2.4. Site Multihoming 616 A host may have an interface that has multiple globally routable IP 617 addresses. Such a situation may be a result of the site having 618 multiple upper Internet Service Providers, or just because the site 619 provides all hosts with both IPv4 and IPv6 addresses. The host 620 should stay reachable at all or any subset of the currently available 621 global routable addresses, independent of how they are provided. 623 This case is handled the same as if there were different IP 624 addresses, described above in Section 3.2.3. Note that a single 625 interface may experience site multihoming while the host itself may 626 have multiple interfaces. 628 Note that a host may be multihomed and mobile simultaneously, and 629 that a multihomed host may want to protect the location of some of 630 its interfaces while revealing the real IP address of some others. 632 This document does not presently specify additional site multihoming 633 extensions to HIP; further alignment with the IETF shim6 working 634 group may be considered in the future. 636 3.2.5. Dual host multihoming 638 Consider the case in which both hosts would like to add an additional 639 address after the base exchange completes. In Figure 6, consider 640 that host1, which used address addr1a in the base exchange to set up 641 SPI1a and SPI2a, wants to add address addr1b. It would send an 642 UPDATE with LOCATOR (containing the address addr1b) to host2, using 643 destination address addr2a, and a new set of SPIs would be added 644 between hosts 1 and 2 (call them SPI1b and SPI2b -- not shown in the 645 figure). Next, consider host2 deciding to add addr2b to the 646 relationship. Host2 must select one of host1's addresses towards 647 which to initiate an UPDATE. It may choose to initiate an UPDATE to 648 addr1a, addr1b, or both. If it chooses to send to both, then a full 649 mesh (four SA pairs) of SAs would exist between the two hosts. This 650 is the most general case; it often may be the case that hosts 651 primarily establish new SAs only with the peer's Preferred locator. 652 The readdressing protocol is flexible enough to accommodate this 653 choice. 655 -<- SPI1a -- -- SPI2a ->- 656 host1 < > addr1a <---> addr2a < > host2 657 ->- SPI2a -- -- SPI1a -<- 659 addr1b <---> addr2a (second SA pair) 660 addr1a <---> addr2b (third SA pair) 661 addr1b <---> addr2b (fourth SA pair) 663 Figure 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to 664 Add a Second Address 666 3.2.6. Combined Mobility and Multihoming 668 It looks likely that in the future, many mobile hosts will be 669 simultaneously mobile and multihomed, i.e., have multiple mobile 670 interfaces. Furthermore, if the interfaces use different access 671 technologies, it is fairly likely that one of the interfaces may 672 appear stable (retain its current IP address) while some other(s) may 673 experience mobility (undergo IP address change). 675 The use of LOCATOR plus ESP_INFO should be flexible enough to handle 676 most such scenarios, although more complicated scenarios have not 677 been studied so far. 679 3.2.7. Using LOCATORs across Addressing Realms 681 It is possible for HIP associations to migrate to a state in which 682 both parties are only using locators in different addressing realms. 683 For example, the two hosts may initiate the HIP association when both 684 are using IPv6 locators, then one host may loose its IPv6 685 connectivity and obtain an IPv4 address. In such a case, some type 686 of mechanism for interworking between the different realms must be 687 employed; such techniques are outside the scope of the present text. 688 The basic problem in this example is that the host readdressing to 689 IPv4 does not know a corresponding IPv4 address of the peer. This 690 may be handled (experimentally) by possibly configuring this address 691 information manually or in the DNS, or the hosts exchange both IPv4 692 and IPv6 addresses in the locator. 694 3.2.8. Network Renumbering 696 It is expected that IPv6 networks will be renumbered much more often 697 than most IPv4 networks. From an end-host point of view, network 698 renumbering is similar to mobility. 700 3.2.9. Initiating the Protocol in R1 or I2 702 A Responder host MAY include a LOCATOR parameter in the R1 packet 703 that it sends to the Initiator. This parameter MUST be protected by 704 the R1 signature. If the R1 packet contains LOCATOR parameters with 705 a new Preferred locator, the Initiator SHOULD directly set the new 706 Preferred locator to status ACTIVE without performing address 707 verification first, and MUST send the I2 packet to the new Preferred 708 locator. The I1 destination address and the new Preferred locator 709 may be identical. All new non-preferred locators must still undergo 710 address verification once the base exchange completes. 712 Initiator Responder 714 R1 with LOCATOR 715 <----------------------------------- 716 record additional addresses 717 change responder address 718 I2 sent to newly indicated preferred address 719 -----------------------------------> 720 (process normally) 721 R2 722 <----------------------------------- 723 (process normally, later verification of non-preferred locators) 725 Figure 7: LOCATOR Inclusion in R1 727 An Initiator MAY include one or more LOCATOR parameters in the I2 728 packet, independent of whether or not there was a LOCATOR parameter 729 in the R1. These parameters MUST be protected by the I2 signature. 730 Even if the I2 packet contains LOCATOR parameters, the Responder MUST 731 still send the R2 packet to the source address of the I2. The new 732 Preferred locator SHOULD be identical to the I2 source address. If 733 the I2 packet contains LOCATOR parameters, all new locators must 734 undergo address verification as usual, and the ESP traffic that 735 subsequently follows should use the Preferred locator. 737 Initiator Responder 739 I2 with LOCATOR 740 -----------------------------------> 741 (process normally) 742 record additional addresses 743 R2 sent to source address of I2 744 <----------------------------------- 745 (process normally) 747 Figure 8: LOCATOR Inclusion in I2 749 The I1 and I2 may be arriving from different source addresses if the 750 LOCATOR parameter is present in R1. In this case, implementations 751 simultaneously using multiple pre-created R1s, indexed by Initiator 752 IP addresses, may inadvertently fail the puzzle solution of I2 753 packets due to a perceived puzzle mismatch. See, for instance, the 754 example in Appendix A of [RFC5201]. As a solution, the Responder's 755 puzzle indexing mechanism must be flexible enough to accommodate the 756 situation when R1 includes a LOCATOR parameter. 758 3.3. Other Considerations 760 3.3.1. Address Verification 762 When a HIP host receives a set of locators from another HIP host in a 763 LOCATOR, it does not necessarily know whether the other host is 764 actually reachable at the claimed addresses. In fact, a malicious 765 peer host may be intentionally giving bogus addresses in order to 766 cause a packet flood towards the target addresses [RFC4225]. 767 Likewise, viral software may have compromised the peer host, 768 programming it to redirect packets to the target addresses. Thus, 769 the HIP host must first check that the peer is reachable at the new 770 address. 772 An additional potential benefit of performing address verification is 773 to allow middleboxes in the network along the new path to obtain the 774 peer host's inbound SPI. 776 Address verification is implemented by the challenger sending some 777 piece of unguessable information to the new address, and waiting for 778 some acknowledgment from the Responder that indicates reception of 779 the information at the new address. This may include the exchange of 780 a nonce, or the generation of a new SPI and observation of data 781 arriving on the new SPI. 783 3.3.2. Credit-Based Authorization 785 Credit-Based Authorization (CBA) allows a host to securely use a new 786 locator even though the peer's reachability at the address embedded 787 in the locator has not yet been verified. This is accomplished based 788 on the following three hypotheses: 790 1. A flooding attacker typically seeks to somehow multiply the 791 packets it generates for the purpose of its attack because 792 bandwidth is an ample resource for many victims. 794 2. An attacker can often cause unamplified flooding by sending 795 packets to its victim, either by directly addressing the victim 796 in the packets, or by guiding the packets along a specific path 797 by means of an IPv6 Routing header, if Routing headers are not 798 filtered by firewalls. 800 3. Consequently, the additional effort required to set up a 801 redirection-based flooding attack (without CBA and return 802 routability checks) would pay off for the attacker only if 803 amplification could be obtained this way. 805 On this basis, rather than eliminating malicious packet redirection 806 in the first place, Credit-Based Authorization prevents 807 amplifications. This is accomplished by limiting the data a host can 808 send to an unverified address of a peer by the data recently received 809 from that peer. Redirection-based flooding attacks thus become less 810 attractive than, for example, pure direct flooding, where the 811 attacker itself sends bogus packets to the victim. 813 Figure 9 illustrates Credit-Based Authorization: Host B measures the 814 amount of data recently received from peer A and, when A readdresses, 815 sends packets to A's new, unverified address as long as the sum of 816 the packet sizes does not exceed the measured, received data volume. 817 When insufficient credit is left, B stops sending further packets to 818 A until A's address becomes ACTIVE. The address changes may be due 819 to mobility, multihoming, or any other reason. Not shown in Figure 9 820 are the results of credit aging (Section 5.6.2), a mechanism used to 821 dampen possible time-shifting attacks. 823 +-------+ +-------+ 824 | A | | B | 825 +-------+ +-------+ 826 | | 827 address |------------------------------->| credit += size(packet) 828 ACTIVE | | 829 |------------------------------->| credit += size(packet) 830 |<-------------------------------| do not change credit 831 | | 832 + address change | 833 + address verification starts | 834 address |<-------------------------------| credit -= size(packet) 835 UNVERIFIED |------------------------------->| credit += size(packet) 836 |<-------------------------------| credit -= size(packet) 837 | | 838 |<-------------------------------| credit -= size(packet) 839 | X credit < size(packet) 840 | | => do not send packet! 841 + address verification concludes | 842 address | | 843 ACTIVE |<-------------------------------| do not change credit 844 | | 846 Figure 9: Readdressing Scenario 848 3.3.3. Preferred Locator 850 When a host has multiple locators, the peer host must decide which to 851 use for outbound packets. It may be that a host would prefer to 852 receive data on a particular inbound interface. HIP allows a 853 particular locator to be designated as a Preferred locator and 854 communicated to the peer (see Section 4). 856 In general, when multiple locators are used for a session, there is 857 the question of using multiple locators for failover only or for 858 load-balancing. Due to the implications of load-balancing on the 859 transport layer that still need to be worked out, this document 860 assumes that multiple locators are used primarily for failover. An 861 implementation may use ICMP interactions, reachability checks, or 862 other means to detect the failure of a locator. 864 3.3.4. Interaction with Security Associations 866 This document specifies a new HIP protocol parameter, the LOCATOR 867 parameter (see Section 4), that allows the hosts to exchange 868 information about their locator(s) and any changes in their 869 locator(s). The logical structure created with LOCATOR parameters 870 has three levels: hosts, Security Associations (SAs) indexed by 871 Security Parameter Indices (SPIs), and addresses. 873 The relation between these levels for an association constructed as 874 defined in the base specification [RFC5201] and ESP transform 875 [RFC5202] is illustrated in Figure 10. 877 -<- SPI1a -- -- SPI2a ->- 878 host1 < > addr1a <---> addr2a < > host2 879 ->- SPI2a -- -- SPI1a -<- 881 Figure 10: Relation between Hosts, SPIs, and Addresses (Base 882 Specification) 884 In Figure 10, host1 and host2 negotiate two unidirectional SAs, and 885 each host selects the SPI value for its inbound SA. The addresses 886 addr1a and addr2a are the source addresses that the hosts use in the 887 base HIP exchange. These are the "preferred" (and only) addresses 888 conveyed to the peer for use on each SA. That is, although packets 889 sent to any of the hosts' interfaces may be accepted on the inbound 890 SA, the peer host in general knows of only the single destination 891 address learned in the base exchange (e.g., for host1, it sends a 892 packet on SPI2a to addr2a to reach host2), unless other mechanisms 893 exist to learn of new addresses. 895 In general, the bindings that exist in an implementation 896 corresponding to this document can be depicted as shown in Figure 11. 897 In this figure, a host can have multiple inbound SPIs (and, not 898 shown, multiple outbound SPIs) associated with another host. 899 Furthermore, each SPI may have multiple addresses associated with it. 900 These addresses that are bound to an SPI are not used to lookup the 901 incoming SA. Rather, the addresses are those that are provided to 902 the peer host, as hints for which addresses to use to reach the host 903 on that SPI. The LOCATOR parameter is used to change the set of 904 addresses that a peer associates with a particular SPI. 906 address11 907 / 908 SPI1 - address12 909 / 910 / address21 911 host -- SPI2 < 912 \ address22 913 \ 914 SPI3 - address31 915 \ 916 address32 918 Figure 11: Relation between Hosts, SPIs, and Addresses (General Case) 920 A host may establish any number of security associations (or SPIs) 921 with a peer. The main purpose of having multiple SPIs with a peer is 922 to group the addresses into collections that are likely to experience 923 fate sharing. For example, if the host needs to change its addresses 924 on SPI2, it is likely that both address21 and address22 will 925 simultaneously become obsolete. In a typical case, such SPIs may 926 correspond with physical interfaces; see below. Note, however, that 927 especially in the case of site multihoming, one of the addresses may 928 become unreachable while the other one still works. In the typical 929 case, however, this does not require the host to inform its peers 930 about the situation, since even the non-working address still 931 logically exists. 933 A basic property of HIP SAs is that the inbound IP address is not 934 used to lookup the incoming SA. Therefore, in Figure 11, it may seem 935 unnecessary for address31, for example, to be associated only with 936 SPI3 -- in practice, a packet may arrive to SPI1 via destination 937 address address31 as well. However, the use of different source and 938 destination addresses typically leads to different paths, with 939 different latencies in the network, and if packets were to arrive via 940 an arbitrary destination IP address (or path) for a given SPI, the 941 reordering due to different latencies may cause some packets to fall 942 outside of the ESP anti-replay window. For this reason, HIP provides 943 a mechanism to affiliate destination addresses with inbound SPIs, 944 when there is a concern that anti-replay windows might be violated. 945 In this sense, we can say that a given inbound SPI has an "affinity" 946 for certain inbound IP addresses, and this affinity is communicated 947 to the peer host. Each physical interface SHOULD have a separate SA, 948 unless the ESP anti-replay window is loose. 950 Moreover, even when the destination addresses used for a particular 951 SPI are held constant, the use of different source interfaces may 952 also cause packets to fall outside of the ESP anti-replay window, 953 since the path traversed is often affected by the source address or 954 interface used. A host has no way to influence the source interface 955 on which a peer sends its packets on a given SPI. A host SHOULD 956 consistently use the same source interface and address when sending 957 to a particular destination IP address and SPI. For this reason, a 958 host may find it useful to change its SPI or at least reset its ESP 959 anti-replay window when the peer host readdresses. 961 An address may appear on more than one SPI. This creates no 962 ambiguity since the receiver will ignore the IP addresses during SA 963 lookup anyway. However, this document does not specify such cases. 965 When the LOCATOR parameter is sent in an UPDATE packet, then the 966 receiver will respond with an UPDATE acknowledgment. When the 967 LOCATOR parameter is sent in an R1 or I2 packet, the base exchange 968 retransmission mechanism will confirm its successful delivery. 969 LOCATORs may experimentally be used in NOTIFY packets; in this case, 970 the recipient MUST consider the LOCATOR as informational and not 971 immediately change the current preferred address, but can test the 972 additional locators when the need arises. The use of the LOCATOR in 973 a NOTIFY message may not be compatible with middleboxes. 975 4. LOCATOR Parameter Format 977 The LOCATOR parameter is a critical parameter as defined by 978 [RFC5201]. It consists of the standard HIP parameter Type and Length 979 fields, plus zero or more Locator sub-parameters. Each Locator sub- 980 parameter contains a Traffic Type, Locator Type, Locator Length, 981 Preferred locator bit, Locator Lifetime, and a Locator encoding. A 982 LOCATOR containing zero Locator fields is permitted but has the 983 effect of deprecating all addresses. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Type | Length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Traffic Type | Locator Type | Locator Length | Reserved |P| 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Locator Lifetime | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Locator | 995 | | 996 | | 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 . . 1000 . . 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Traffic Type | Locator Type | Locator Length | Reserved |P| 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Locator Lifetime | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Locator | 1007 | | 1008 | | 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Figure 12: LOCATOR Parameter Format 1014 Type: 193 1016 Length: Length in octets, excluding Type and Length fields, and 1017 excluding padding. 1019 Traffic Type: Defines whether the locator pertains to HIP signaling, 1020 user data, or both. 1022 Locator Type: Defines the semantics of the Locator field. 1024 Locator Length: Defines the length of the Locator field, in units of 1025 4-byte words (Locators up to a maximum of 4*255 octets are 1026 supported). 1028 Reserved: Zero when sent, ignored when received. 1030 P: Preferred locator. Set to one if the locator is preferred for 1031 that Traffic Type; otherwise, set to zero. 1033 Locator Lifetime: Locator lifetime, in seconds. 1035 Locator: The locator whose semantics and encoding are indicated by 1036 the Locator Type field. All Locator sub-fields are integral 1037 multiples of four octets in length. 1039 The Locator Lifetime indicates how long the following locator is 1040 expected to be valid. The lifetime is expressed in seconds. Each 1041 locator MUST have a non-zero lifetime. The address is expected to 1042 become deprecated when the specified number of seconds has passed 1043 since the reception of the message. A deprecated address SHOULD NOT 1044 be used as a destination address if an alternate (non-deprecated) is 1045 available and has sufficient scope. 1047 4.1. Traffic Type and Preferred Locator 1049 The following Traffic Type values are defined: 1051 0: Both signaling (HIP control packets) and user data. 1053 1: Signaling packets only. 1055 2: Data packets only. 1057 The "P" bit, when set, has scope over the corresponding Traffic Type. 1058 That is, when a "P" bit is set for Traffic Type "2", for example, it 1059 means that the locator is preferred for data packets. If there is a 1060 conflict (for example, if the "P" bit is set for an address of Type 1061 "0" and a different address of Type "2"), the more specific Traffic 1062 Type rule applies (in this case, "2"). By default, the IP addresses 1063 used in the base exchange are Preferred locators for both signaling 1064 and user data, unless a new Preferred locator supersedes them. If no 1065 locators are indicated as preferred for a given Traffic Type, the 1066 implementation may use an arbitrary locator from the set of active 1067 locators. 1069 4.2. Locator Type and Locator 1071 The following Locator Type values are defined, along with the 1072 associated semantics of the Locator field: 1074 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] 1075 (128 bits long). This locator type is defined primarily for non- 1076 ESP-based usage. 1078 1: The concatenation of an ESP SPI (first 32 bits) followed by an 1079 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 1080 128 bits). This IP address is defined primarily for ESP-based 1081 usage. 1083 4.3. UPDATE Packet with Included LOCATOR 1085 A number of combinations of parameters in an UPDATE packet are 1086 possible (e.g., see Section 3.2). In this document, procedures are 1087 defined only for the case in which one LOCATOR and one ESP_INFO 1088 parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD 1089 list all of the locators that are active on the HIP association 1090 (including those on SAs not covered by the ESP_INFO parameter). Any 1091 UPDATE packet that includes a LOCATOR parameter SHOULD include both 1092 an HMAC and a HIP_SIGNATURE parameter. The relationship between the 1093 announced Locators and any ESP_INFO parameters present in the packet 1094 is defined in Section 5.2. The sending of multiple LOCATOR and/or 1095 ESP_INFO parameters is for further study; receivers may wish to 1096 experiment with supporting such a possibility. 1098 5. Processing Rules 1100 This section describes rules for sending and receiving the LOCATOR 1101 parameter, testing address reachability, and using Credit-Based 1102 Authorization (CBA) on UNVERIFIED locators. 1104 5.1. Locator Data Structure and Status 1106 In a typical implementation, each outgoing locator is represented by 1107 a piece of state that contains the following data: 1109 o the actual bit pattern representing the locator, 1111 o the lifetime (seconds), 1113 o the status (UNVERIFIED, ACTIVE, DEPRECATED), 1115 o the Traffic Type scope of the locator, and 1117 o whether the locator is preferred for any particular scope. 1119 The status is used to track the reachability of the address embedded 1120 within the LOCATOR parameter: 1122 UNVERIFIED indicates that the reachability of the address has not 1123 been verified yet, 1125 ACTIVE indicates that the reachability of the address has been 1126 verified and the address has not been deprecated, 1128 DEPRECATED indicates that the locator lifetime has expired. 1130 The following state changes are allowed: 1132 UNVERIFIED to ACTIVE The reachability procedure completes 1133 successfully. 1135 UNVERIFIED to DEPRECATED The locator lifetime expires while the 1136 locator is UNVERIFIED. 1138 ACTIVE to DEPRECATED The locator lifetime expires while the locator 1139 is ACTIVE. 1141 ACTIVE to UNVERIFIED There has been no traffic on the address for 1142 some time, and the local policy mandates that the address 1143 reachability must be verified again before starting to use it 1144 again. 1146 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 1147 locator. 1149 A DEPRECATED address MUST NOT be changed to ACTIVE without first 1150 verifying its reachability. 1152 Note that the state of whether or not a locator is preferred is not 1153 necessarily the same as the value of the Preferred bit in the Locator 1154 sub-parameter received from the peer. Peers may recommend certain 1155 locators to be preferred, but the decision on whether to actually use 1156 a locator as a preferred locator is a local decision, possibly 1157 influenced by local policy. 1159 5.2. Sending LOCATORs 1161 The decision of when to send LOCATORs is basically a local policy 1162 issue. However, it is RECOMMENDED that a host send a LOCATOR 1163 whenever it recognizes a change of its IP addresses in use on an 1164 active HIP association, and assumes that the change is going to last 1165 at least for a few seconds. Rapidly sending LOCATORs that force the 1166 peer to change the preferred address SHOULD be avoided. 1168 When a host decides to inform its peers about changes in its IP 1169 addresses, it has to decide how to group the various addresses with 1170 SPIs. The grouping should consider also whether middlebox 1171 interaction requires sending the same LOCATOR in separate UPDATEs on 1172 different paths. Since each SPI is associated with a different 1173 Security Association, the grouping policy may also be based on ESP 1174 anti-replay protection considerations. In the typical case, simply 1175 basing the grouping on actual kernel level physical and logical 1176 interfaces may be the best policy. Grouping policy is outside of the 1177 scope of this document. 1179 Note that the purpose of announcing IP addresses in a LOCATOR is to 1180 provide connectivity between the communicating hosts. In most cases, 1181 tunnels or virtual interfaces such as IPsec tunnel interfaces or 1182 Mobile IP home addresses provide sub-optimal connectivity. 1183 Furthermore, it should be possible to replace most tunnels with HIP 1184 based "non-tunneling", therefore making most virtual interfaces 1185 fairly unnecessary in the future. Therefore, virtual interfaces 1186 SHOULD NOT be announced in general. On the other hand, there are 1187 clearly situations where tunnels are used for diagnostic and/or 1188 testing purposes. In such and other similar cases announcing the IP 1189 addresses of virtual interfaces may be appropriate. 1191 Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. 1192 Link-local addresses MAY be announced to peers that are known to be 1193 neighbors on the same link, such as when the IP destination address 1194 of a peer is also link-local. The announcement of link-local 1195 addresses in this case is a policy decision; link-local addresses 1196 used as Preferred locators will create reachability problems when the 1197 host moves to another link. In any case, link-local addresses MUST 1198 NOT be announced to a peer unless that peer is known to be on the 1199 same link. 1201 Once the host has decided on the groups and assignment of addresses 1202 to the SPIs, it creates a LOCATOR parameter that serves as a complete 1203 representation of the addresses and affiliated SPIs intended for 1204 active use. We now describe a few cases introduced in Section 3.2. 1205 We assume that the Traffic Type for each locator is set to "0" (other 1206 values for Traffic Type may be specified in documents that separate 1207 the HIP control plane from data plane traffic). Other mobility and 1208 multihoming cases are possible but are left for further 1209 experimentation. 1211 1. Host mobility with no multihoming and no rekeying. The mobile 1212 host creates a single UPDATE containing a single ESP_INFO with a 1213 single LOCATOR parameter. The ESP_INFO contains the current 1214 value of the SPI in both the OLD SPI and NEW SPI fields. The 1215 LOCATOR contains a single Locator with a "Locator Type" of "1"; 1216 the SPI must match that of the ESP_INFO. The Preferred bit 1217 SHOULD be set and the "Locator Lifetime" is set according to 1218 local policy. The UPDATE also contains a SEQ parameter as usual. 1219 This packet is retransmitted as defined in the HIP protocol 1220 specification [RFC5201]. The UPDATE should be sent to the peer's 1221 preferred IP address with an IP source address corresponding to 1222 the address in the LOCATOR parameter. 1224 2. Host mobility with no multihoming but with rekeying. The mobile 1225 host creates a single UPDATE containing a single ESP_INFO with a 1226 single LOCATOR parameter (with a single address). The ESP_INFO 1227 contains the current value of the SPI in the OLD SPI and the new 1228 value of the SPI in the NEW SPI, and a KEYMAT Index as selected 1229 by local policy. Optionally, the host may choose to initiate a 1230 Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. 1231 The LOCATOR contains a single Locator with "Locator Type" of "1"; 1232 the SPI must match that of the NEW SPI in the ESP_INFO. 1233 Otherwise, the steps are identical to the case in which no 1234 rekeying is initiated. 1236 3. Host multihoming (addition of an address). We only describe the 1237 simple case of adding an additional address to a (previously) 1238 single-homed, non-mobile host. The host SHOULD set up a new SA 1239 pair between this new address and the preferred address of the 1240 peer host. To do this, the multihomed host creates a new inbound 1241 SA and creates a new SPI. For the outgoing UPDATE message, it 1242 inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW 1243 SPI field corresponding to the new SPI, and a KEYMAT Index as 1244 selected by local policy. The host adds to the UPDATE message a 1245 LOCATOR with two Type "1" Locators: the original address and SPI 1246 active on the association, and the new address and new SPI being 1247 added (with the SPI matching the NEW SPI contained in the 1248 ESP_INFO). The Preferred bit SHOULD be set depending on the 1249 policy to tell the peer host which of the two locators is 1250 preferred. The UPDATE also contains a SEQ parameter and 1251 optionally a DIFFIE_HELLMAN parameter, and follows rekeying 1252 procedures with respect to this new address. The UPDATE message 1253 SHOULD be sent to the peer's Preferred address with a source 1254 address corresponding to the new locator. 1256 The sending of multiple LOCATORs, locators with Locator Type "0", and 1257 multiple ESP_INFO parameters is for further study. Note that the 1258 inclusion of LOCATOR in an R1 packet requires the use of Type "0" 1259 locators since no SAs are set up at that point. 1261 5.3. Handling Received LOCATORs 1263 A host SHOULD be prepared to receive a LOCATOR parameter in the 1264 following HIP packets: R1, I2, UPDATE, and NOTIFY. 1266 This document describes sending both ESP_INFO and LOCATOR parameters 1267 in an UPDATE. The ESP_INFO parameter is included when there is a 1268 need to rekey or key a new SPI, and is otherwise included for the 1269 possible benefit of HIP-aware middleboxes. The LOCATOR parameter 1270 contains a complete map of the locators that the host wishes to make 1271 or keep active for the HIP association. 1273 In general, the processing of a LOCATOR depends upon the packet type 1274 in which it is included. Here, we describe only the case in which 1275 ESP_INFO is present and a single LOCATOR and ESP_INFO are sent in an 1276 UPDATE message; other cases are for further study. The steps below 1277 cover each of the cases described in Section 5.2. 1279 The processing of ESP_INFO and LOCATOR parameters is intended to be 1280 modular and support future generalization to the inclusion of 1281 multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD 1282 first process the ESP_INFO before the LOCATOR, since the ESP_INFO may 1283 contain a new SPI value mapped to an existing SPI, while a Type "1" 1284 locator will only contain a reference to the new SPI. 1286 When a host receives a validated HIP UPDATE with a LOCATOR and 1287 ESP_INFO parameter, it processes the ESP_INFO as follows. The 1288 ESP_INFO parameter indicates whether an SA is being rekeyed, created, 1289 deprecated, or just identified for the benefit of middleboxes. The 1290 host examines the OLD SPI and NEW SPI values in the ESP_INFO 1291 parameter: 1293 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both 1294 correspond to an existing SPI, the ESP_INFO is gratuitous 1295 (provided for middleboxes) and no rekeying is necessary. 1297 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW 1298 SPI is a different non-zero value, the existing SA is being 1299 rekeyed and the host follows HIP ESP rekeying procedures by 1300 creating a new outbound SA with an SPI corresponding to the NEW 1301 SPI, with no addresses bound to this SPI. Note that locators in 1302 the LOCATOR parameter will reference this new SPI instead of the 1303 old SPI. 1305 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new 1306 non-zero value, then a new SA is being requested by the peer. 1307 This case is also treated like a rekeying event; the receiving 1308 host must create a new SA and respond with an UPDATE ACK. 1310 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and 1311 the NEW SPI is zero, the SA is being deprecated and all locators 1312 uniquely bound to the SPI are put into the DEPRECATED state. 1314 If none of the above cases apply, a protocol error has occurred and 1315 the processing of the UPDATE is stopped. 1317 Next, the locators in the LOCATOR parameter are processed. For each 1318 locator listed in the LOCATOR parameter, check that the address 1319 therein is a legal unicast or anycast address. That is, the address 1320 MUST NOT be a broadcast or multicast address. Note that some 1321 implementations MAY accept addresses that indicate the local host, 1322 since it may be allowed that the host runs HIP with itself. 1324 The below assumes that all locators are of Type "1" with a Traffic 1325 Type of "0"; other cases are for further study. 1327 For each Type "1" address listed in the LOCATOR parameter, the host 1328 checks whether the address is already bound to the SPI indicated. If 1329 the address is already bound, its lifetime is updated. If the status 1330 of the address is DEPRECATED, the status is changed to UNVERIFIED. 1331 If the address is not already bound, the address is added, and its 1332 status is set to UNVERIFIED. Mark all addresses corresponding to the 1333 SPI that were NOT listed in the LOCATOR parameter as DEPRECATED. 1335 As a result, at the end of processing, the addresses listed in the 1336 LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and 1337 any old addresses on the old SA not listed in the LOCATOR parameter 1338 have a state of DEPRECATED. 1340 Once the host has processed the locators, if the LOCATOR parameter 1341 contains a new Preferred locator, the host SHOULD initiate a change 1342 of the Preferred locator. This requires that the host first verifies 1343 reachability of the associated address, and only then changes the 1344 Preferred locator; see Section 5.5. 1346 If a host receives a locator with an unsupported Locator Type, and 1347 when such a locator is also declared to be the Preferred locator for 1348 the peer, the host SHOULD send a NOTIFY error with a Notify Message 1349 Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field 1350 containing the locator(s) that the receiver failed to process. 1351 Otherwise, a host MAY send a NOTIFY error if a (non-preferred) 1352 locator with an unsupported Locator Type is received in a LOCATOR 1353 parameter. 1355 5.4. Verifying Address Reachability 1357 A host MUST verify the reachability of an UNVERIFIED address. The 1358 status of a newly learned address MUST initially be set to UNVERIFIED 1359 unless the new address is advertised in a R1 packet as a new 1360 Preferred locator. A host MAY also want to verify the reachability 1361 of an ACTIVE address again after some time, in which case it would 1362 set the status of the address to UNVERIFIED and reinitiate address 1363 verification. 1365 A host typically starts the address-verification procedure by sending 1366 a nonce to the new address. For example, when the host is changing 1367 its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD 1368 be random and the value MAY be copied into an ECHO_REQUEST sent in 1369 the rekeying UPDATE. However, if the host is not changing its SPI, 1370 it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent 1371 to the new address. A host MAY also use other message exchanges as 1372 confirmation of the address reachability. 1374 Note that in the case of receiving a LOCATOR in an R1 and replying 1375 with an I2 to the new address in the LOCATOR, receiving the 1376 corresponding R2 is sufficient proof of reachability for the 1377 Responder's preferred address. Since further address verification of 1378 such an address can impede the HIP-base exchange, a host MUST NOT 1379 separately verify reachability of a new Preferred locator that was 1380 received on an R1. 1382 In some cases, it MAY be sufficient to use the arrival of data on a 1383 newly advertised SA as implicit address reachability verification as 1384 depicted in Figure 13, instead of waiting for the confirmation via a 1385 HIP packet. In this case, a host advertising a new SPI as part of 1386 its address reachability check SHOULD be prepared to receive traffic 1387 on the new SA. 1389 Mobile host Peer host 1391 prepare incoming SA 1392 NEW SPI in ESP_INFO (UPDATE) 1393 <----------------------------------- 1394 switch to new outgoing SA 1395 data on new SA 1396 -----------------------------------> 1397 mark address ACTIVE 1399 Figure 13: Address Activation Via Use of a New SA 1401 When address verification is in progress for a new Preferred locator, 1402 the host SHOULD select a different locator listed as ACTIVE, if one 1403 such locator is available, to continue communications until address 1404 verification completes. Alternatively, the host MAY use the new 1405 Preferred locator while in UNVERIFIED status to the extent Credit- 1406 Based Authorization permits. Credit-Based Authorization is explained 1407 in Section 5.6. Once address verification succeeds, the status of 1408 the new Preferred locator changes to ACTIVE. 1410 5.5. Changing the Preferred Locator 1412 A host MAY want to change the Preferred outgoing locator for 1413 different reasons, e.g., because traffic information or ICMP error 1414 messages indicate that the currently used preferred address may have 1415 become unreachable. Another reason may be due to receiving a LOCATOR 1416 parameter that has the "P" bit set. 1418 To change the Preferred locator, the host initiates the following 1419 procedure: 1421 1. If the new Preferred locator has ACTIVE status, the Preferred 1422 locator is changed and the procedure succeeds. 1424 2. If the new Preferred locator has UNVERIFIED status, the host 1425 starts to verify its reachability. The host SHOULD use a 1426 different locator listed as ACTIVE until address verification 1427 completes if one such locator is available. Alternatively, the 1428 host MAY use the new Preferred locator, even though in UNVERIFIED 1429 status, to the extent Credit-Based Authorization permits. Once 1430 address verification succeeds, the status of the new Preferred 1431 locator changes to ACTIVE and its use is no longer governed by 1432 Credit-Based Authorization. 1434 3. If the peer host has not indicated a preference for any address, 1435 then the host picks one of the peer's ACTIVE addresses randomly 1436 or according to policy. This case may arise if, for example, 1437 ICMP error messages that deprecate the Preferred locator arrive, 1438 but the peer has not yet indicated a new Preferred locator. 1440 4. If the new Preferred locator has DEPRECATED status and there is 1441 at least one non-deprecated address, the host selects one of the 1442 non-deprecated addresses as a new Preferred locator and 1443 continues. If the selected address is UNVERIFIED, the address 1444 verification procedure described above will apply. 1446 5.6. Credit-Based Authorization 1448 To prevent redirection-based flooding attacks, the use of a Credit- 1449 Based Authorization (CBA) approach is mandatory when a host sends 1450 data to an UNVERIFIED locator. The following algorithm meets the 1451 security considerations for prevention of amplification and time- 1452 shifting attacks. Other forms of credit aging, and other values for 1453 the CreditAgingFactor and CreditAgingInterval parameters in 1454 particular, are for further study, and so are the advanced CBA 1455 techniques specified in [CBA-MIPv6]. 1457 5.6.1. Handling Payload Packets 1459 A host maintains a "credit counter" for each of its peers. Whenever 1460 a packet arrives from a peer, the host SHOULD increase that peer's 1461 credit counter by the size of the received packet. When the host has 1462 a packet to be sent to the peer, and when the peer's Preferred 1463 locator is listed as UNVERIFIED and no alternative locator with 1464 status ACTIVE is available, the host checks whether it can send the 1465 packet to the UNVERIFIED locator. The packet SHOULD be sent if the 1466 value of the credit counter is higher than the size of the outbound 1467 packet. If the credit counter is too low, the packet MUST be 1468 discarded or buffered until address verification succeeds. When a 1469 packet is sent to a peer at an UNVERIFIED locator, the peer's credit 1470 counter MUST be reduced by the size of the packet. The peer's credit 1471 counter is not affected by packets that the host sends to an ACTIVE 1472 locator of that peer. 1474 Figure 14 depicts the actions taken by the host when a packet is 1475 received. Figure 15 shows the decision chain in the event a packet 1476 is sent. 1478 Inbound 1479 packet 1480 | 1481 | +----------------+ +---------------+ 1482 | | Increase | | Deliver | 1483 +-----> | credit counter |-------------> | packet to | 1484 | by packet size | | application | 1485 +----------------+ +---------------+ 1487 Figure 14: Receiving Packets with Credit-Based Authorization 1489 Outbound 1490 packet 1491 | _________________ 1492 | / \ +---------------+ 1493 | / Is the preferred \ No | Send packet | 1494 +-----> | destination address |-------------> | to preferred | 1495 \ UNVERIFIED? / | address | 1496 \_________________/ +---------------+ 1497 | 1498 | Yes 1499 | 1500 v 1501 _________________ 1502 / \ +---------------+ 1503 / Does an ACTIVE \ Yes | Send packet | 1504 | destination address |-------------> | to ACTIVE | 1505 \ exist? / | address | 1506 \_________________/ +---------------+ 1507 | 1508 | No 1509 | 1510 v 1511 _________________ 1512 / \ +---------------+ 1513 / Credit counter \ No | | 1514 | >= |-------------> | Drop packet | 1515 \ packet size? / | | 1516 \_________________/ +---------------+ 1517 | 1518 | Yes 1519 | 1520 v 1521 +---------------+ +---------------+ 1522 | Reduce credit | | Send packet | 1523 | counter by |----------------> | to preferred | 1524 | packet size | | address | 1525 +---------------+ +---------------+ 1527 Figure 15: Sending Packets with Credit-Based Authorization 1529 5.6.2. Credit Aging 1531 A host ensures that the credit counters it maintains for its peers 1532 gradually decrease over time. Such "credit aging" prevents a 1533 malicious peer from building up credit at a very slow speed and using 1534 this, all at once, for a severe burst of redirected packets. 1536 Credit aging may be implemented by multiplying credit counters with a 1537 factor, CreditAgingFactor (a fractional value less than one), in 1538 fixed time intervals of CreditAgingInterval length. Choosing 1539 appropriate values for CreditAgingFactor and CreditAgingInterval is 1540 important to ensure that a host can send packets to an address in 1541 state UNVERIFIED even when the peer sends at a lower rate than the 1542 host itself. When CreditAgingFactor or CreditAgingInterval are too 1543 small, the peer's credit counter might be too low to continue sending 1544 packets until address verification concludes. 1546 The parameter values proposed in this document are as follows: 1548 CreditAgingFactor 7/8 1549 CreditAgingInterval 5 seconds 1551 These parameter values work well when the host transfers a file to 1552 the peer via a TCP connection and the end-to-end round-trip time does 1553 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1554 use other parameter values or different parameters, which may even be 1555 dynamically established. 1557 6. Security Considerations 1559 The HIP mobility mechanism provides a secure means of updating a 1560 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1561 cryptographically verifies the sender of an UPDATE, so forging or 1562 replaying a HIP UPDATE packet is very difficult (see [RFC5201]). 1563 Therefore, security issues reside in other attack domains. The two 1564 we consider are malicious redirection of legitimate connections as 1565 well as redirection-based flooding attacks using this protocol. This 1566 can be broken down into the following: 1568 Impersonation attacks 1570 - direct conversation with the misled victim 1572 - man-in-the-middle attack 1574 DoS attacks 1576 - flooding attacks (== bandwidth-exhaustion attacks) 1578 * tool 1: direct flooding 1579 * tool 2: flooding by zombies 1581 * tool 3: redirection-based flooding 1583 - memory-exhaustion attacks 1585 - computational-exhaustion attacks 1587 We consider these in more detail in the following sections. 1589 In Section 6.1 and Section 6.2, we assume that all users are using 1590 HIP. In Section 6.3 we consider the security ramifications when we 1591 have both HIP and non-HIP users. Security considerations for Credit- 1592 Based Authorization are discussed in [SIMPLE-CBA]. 1594 6.1. Impersonation Attacks 1596 An attacker wishing to impersonate another host will try to mislead 1597 its victim into directly communicating with them, or carry out a man- 1598 in-the-middle (MitM) attack between the victim and the victim's 1599 desired communication peer. Without mobility support, both attack 1600 types are possible only if the attacker resides on the routing path 1601 between its victim and the victim's desired communication peer, or if 1602 the attacker tricks its victim into initiating the connection over an 1603 incorrect routing path (e.g., by acting as a router or using spoofed 1604 DNS entries). 1606 The HIP extensions defined in this specification change the situation 1607 in that they introduce an ability to redirect a connection (like 1608 IPv6), both before and after establishment. If no precautionary 1609 measures are taken, an attacker could misuse the redirection feature 1610 to impersonate a victim's peer from any arbitrary location. The 1611 authentication and authorization mechanisms of the HIP base exchange 1612 [RFC5201] and the signatures in the UPDATE message prevent this 1613 attack. Furthermore, ownership of a HIP association is securely 1614 linked to a HIP HI/HIT. If an attacker somehow uses a bug in the 1615 implementation or weakness in some protocol to redirect a HIP 1616 connection, the original owner can always reclaim their connection 1617 (they can always prove ownership of the private key associated with 1618 their public HI). 1620 MitM attacks are always possible if the attacker is present during 1621 the initial HIP base exchange and if the hosts do not authenticate 1622 each other's identities. However, once the opportunistic base 1623 exchange has taken place, even a MitM cannot steal the HIP connection 1624 anymore because it is very difficult for an attacker to create an 1625 UPDATE packet (or any HIP packet) that will be accepted as a 1626 legitimate update. UPDATE packets use HMAC and are signed. Even 1627 when an attacker can snoop packets to obtain the SPI and HIT/HI, they 1628 still cannot forge an UPDATE packet without knowledge of the secret 1629 keys. 1631 6.2. Denial-of-Service Attacks 1633 6.2.1. Flooding Attacks 1635 The purpose of a denial-of-service attack is to exhaust some resource 1636 of the victim such that the victim ceases to operate correctly. A 1637 denial-of-service attack can aim at the victim's network attachment 1638 (flooding attack), its memory, or its processing capacity. In a 1639 flooding attack, the attacker causes an excessive number of bogus or 1640 unwanted packets to be sent to the victim, which fills their 1641 available bandwidth. Note that the victim does not necessarily need 1642 to be a node; it can also be an entire network. The attack basically 1643 functions the same way in either case. 1645 An effective DoS strategy is distributed denial of service (DDoS). 1646 Here, the attacker conventionally distributes some viral software to 1647 as many nodes as possible. Under the control of the attacker, the 1648 infected nodes, or "zombies", jointly send packets to the victim. 1649 With such an 'army', an attacker can take down even very high 1650 bandwidth networks/victims. 1652 With the ability to redirect connections, an attacker could realize a 1653 DDoS attack without having to distribute viral code. Here, the 1654 attacker initiates a large download from a server, and subsequently 1655 redirects this download to its victim. The attacker can repeat this 1656 with multiple servers. This threat is mitigated through reachability 1657 checks and credit-based authorization. Both strategies do not 1658 eliminate flooding attacks per se, but they preclude: (i) their use 1659 from a location off the path towards the flooded victim; and (ii) any 1660 amplification in the number and size of the redirected packets. As a 1661 result, the combination of a reachability check and credit-based 1662 authorization lowers a HIP redirection-based flooding attack to the 1663 level of a direct flooding attack in which the attacker itself sends 1664 the flooding traffic to the victim. 1666 6.2.2. Memory/Computational-Exhaustion DoS Attacks 1668 We now consider whether or not the proposed extensions to HIP add any 1669 new DoS attacks (consideration of DoS attacks using the base HIP 1670 exchange and updates is discussed in [RFC5201]). A simple attack is 1671 to send many UPDATE packets containing many IP addresses that are not 1672 flagged as preferred. The attacker continues to send such packets 1673 until the number of IP addresses associated with the attacker's HI 1674 crashes the system. Therefore, there SHOULD be a limit to the number 1675 of IP addresses that can be associated with any HI. Other forms of 1676 memory/computationally exhausting attacks via the HIP UPDATE packet 1677 are handled in the base HIP document [RFC5201]. 1679 A central server that has to deal with a large number of mobile 1680 clients may consider increasing the SA lifetimes to try to slow down 1681 the rate of rekeying UPDATEs or increasing the cookie difficulty to 1682 slow down the rate of attack-oriented connections. 1684 6.3. Mixed Deployment Environment 1686 We now assume an environment with both HIP and non-HIP aware hosts. 1687 Four cases exist. 1689 1. A HIP host redirects its connection onto a non-HIP host. The 1690 non-HIP host will drop the reachability packet, so this is not a 1691 threat unless the HIP host is a MitM that could somehow respond 1692 successfully to the reachability check. 1694 2. A non-HIP host attempts to redirect their connection onto a HIP 1695 host. This falls into IPv4 and IPv6 security concerns, which are 1696 outside the scope of this document. 1698 3. A non-HIP host attempts to steal a HIP host's session (assume 1699 that Secure Neighbor Discovery is not active for the following). 1700 The non-HIP host contacts the service that a HIP host has a 1701 connection with and then attempts to change its IP address to 1702 steal the HIP host's connection. What will happen in this case 1703 is implementation dependent but such a request should fail by 1704 being ignored or dropped. Even if the attack were successful, 1705 the HIP host could reclaim its connection via HIP. 1707 4. A HIP host attempts to steal a non-HIP host's session. A HIP 1708 host could spoof the non-HIP host's IP address during the base 1709 exchange or set the non-HIP host's IP address as its preferred 1710 address via an UPDATE. Other possibilities exist, but a simple 1711 solution is to prevent the use of HIP address check information 1712 to influence non-HIP sessions. 1714 7. IANA Considerations 1716 This document defines a LOCATOR parameter for the Host Identity 1717 Protocol [RFC5201]. This parameter is defined in Section 4 with a 1718 Type of 193. 1720 This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message 1721 Type as defined in the Host Identity Protocol specification 1722 [RFC5201]. This parameter is defined in Section 5.3 with a value of 1723 46. 1725 8. Authors and Acknowledgments 1727 Pekka Nikander and Jari Arkko originated this document, and Christian 1728 Vogt and Thomas Henderson (editor) later joined as co-authors. Greg 1729 Perkins contributed the initial draft of the security section. Petri 1730 Jokela was a co-author of the initial individual submission. 1732 The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan 1733 Melen for many improvements to the document. 1735 9. References 1737 9.1. Normative references 1739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1740 Requirement Levels", BCP 14, RFC 2119, March 1997. 1742 [RFC3484] Draves, R., "Default Address Selection for Internet 1743 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1745 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1746 Architecture", RFC 4291, February 2006. 1748 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1749 RFC 4303, December 2005. 1751 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1752 (HIP) Architecture", RFC 4423, May 2006. 1754 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. 1755 Henderson, "Host Identity Protocol", RFC 5201, 1756 April 2008. 1758 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1759 Encapsulating Security Payload (ESP) Transport Format 1760 with the Host Identity Protocol (HIP)", RFC 5202, 1761 April 2008. 1763 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol 1764 (HIP) Rendezvous Extension", RFC 5204, April 2008. 1766 9.2. Informative references 1768 [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based Authorization for 1769 Mobile IPv6 Early Binding Updates", Work in Progress, 1770 February 2005. 1772 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and 1773 E. Nordmark, "Mobile IP Version 6 Route Optimization 1774 Security Design Background", RFC 4225, December 2005. 1776 [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for 1777 Concurrent Reachability Verification", Work 1778 in Progress, February 2006. 1780 Appendix A. Document Revision History 1782 To be removed upon publication 1784 +----------+-------------------------------------------------------+ 1785 | Revision | Comments | 1786 +----------+-------------------------------------------------------+ 1787 | draft-00 | Initial version from RFC5206 xml (unchanged). | 1788 +----------+-------------------------------------------------------+ 1790 Authors' Addresses 1792 Pekka Nikander 1793 Ericsson Research NomadicLab 1794 JORVAS FIN-02420 1795 FINLAND 1797 Phone: +358 9 299 1 1798 EMail: pekka.nikander@nomadiclab.com 1800 Thomas R. Henderson (editor) 1801 The Boeing Company 1802 P.O. Box 3707 1803 Seattle, WA 1804 USA 1806 EMail: thomas.r.henderson@boeing.com 1808 Christian Vogt 1809 Ericsson Research NomadicLab 1810 Hirsalantie 11 1811 JORVAS FIN-02420 1812 FINLAND 1814 Phone: 1815 EMail: christian.vogt@ericsson.com 1816 Jari Arkko 1817 Ericsson Research NomadicLab 1818 JORVAS FIN-02420 1819 FINLAND 1821 Phone: +358 40 5079256 1822 EMail: jari.arkko@ericsson.com