idnits 2.17.1 draft-ietf-hip-rfc5206-bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 12, 2014) is 3453 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) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-14 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-04 == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Henderson, Ed. 3 Internet-Draft University of Washington 4 Obsoletes: 5206 (if approved) C. Vogt 5 Intended status: Standards Track J. Arkko 6 Expires: May 16, 2015 Ericsson Research NomadicLab 7 November 12, 2014 9 Host Mobility with the Host Identity Protocol 10 draft-ietf-hip-rfc5206-bis-07 12 Abstract 14 This document defines mobility extensions to the Host Identity 15 Protocol (HIP). Specifically, this document defines a general 16 "LOCATOR_SET" parameter for HIP messages that allows for a HIP host 17 to notify peers about alternate addresses at which it may be reached. 18 This document also defines elements of procedure for mobility of a 19 HIP host -- the process by which a host dynamically changes the 20 primary locator that it uses to receive packets. While the same 21 LOCATOR_SET parameter can also be used to support end-host 22 multihoming, detailed procedures are out of scope for this document. 23 This document obsoletes RFC 5206. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 16, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 73 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 75 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 77 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 78 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 9 79 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated 80 Rekey) . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.3. Using LOCATOR_SETs across Addressing Realms . . . . . 11 82 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 83 3.3. Other Considerations . . . . . . . . . . . . . . . . . . 12 84 3.3.1. Address Verification . . . . . . . . . . . . . . . . 12 85 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 12 86 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 87 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 14 88 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16 89 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 16 90 4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17 91 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17 92 5.1. Locator Data Structure and Status . . . . . . . . . . . . 17 93 5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 18 94 5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 20 95 5.4. Verifying Address Reachability . . . . . . . . . . . . . 22 96 5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23 97 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 24 98 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24 99 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 26 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 28 102 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 29 103 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 29 104 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 29 105 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 30 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 107 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 31 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 9.1. Normative references . . . . . . . . . . . . . . . . . . 31 110 9.2. Informative references . . . . . . . . . . . . . . . . . 31 111 Appendix A. Document Revision History . . . . . . . . . . . . . 33 113 1. Introduction and Scope 115 The Host Identity Protocol [I-D.ietf-hip-rfc4423-bis] (HIP) supports 116 an architecture that decouples the transport layer (TCP, UDP, etc.) 117 from the internetworking layer (IPv4 and IPv6) by using public/ 118 private key pairs, instead of IP addresses, as host identities. When 119 a host uses HIP, the overlying protocol sublayers (e.g., transport 120 layer sockets and Encapsulating Security Payload (ESP) Security 121 Associations (SAs)) are instead bound to representations of these 122 host identities, and the IP addresses are only used for packet 123 forwarding. However, each host must also know at least one IP 124 address at which its peers are reachable. Initially, these IP 125 addresses are the ones used during the HIP base exchange 126 [I-D.ietf-hip-rfc5201-bis]. 128 One consequence of such a decoupling is that new solutions to 129 network-layer mobility and host multihoming are possible. There are 130 potentially many variations of mobility and multihoming possible. 131 The scope of this document encompasses messaging and elements of 132 procedure for basic network-level host mobility, leaving more 133 complicated scenarios and other variations for further study. More 134 specifically: 136 This document defines a generalized LOCATOR_SET parameter for use 137 in HIP messages. The LOCATOR_SET parameter allows a HIP host to 138 notify a peer about alternate locators at which it is reachable. 139 The locators may be merely IP addresses, or they may have 140 additional multiplexing and demultiplexing context to aid the 141 packet handling in the lower layers. For instance, an IP address 142 may need to be paired with an ESP Security Parameter Index (SPI) 143 so that packets are sent on the correct SA for a given address. 145 This document also specifies the messaging and elements of 146 procedure for end-host mobility of a HIP host -- the sequential 147 change in the preferred IP address used to reach a host. In 148 particular, message flows to enable successful host mobility, 149 including address verification methods, are defined herein. 151 However, while the same LOCATOR_SET parameter is intended to 152 support host multihoming (parallel support of a number of 153 addresses), and experimentation is encouraged, detailed elements 154 of procedure for host multihoming are out of scope. 156 While HIP can potentially be used with transports other than the ESP 157 transport format [I-D.ietf-hip-rfc5202-bis], this document largely 158 assumes the use of ESP and leaves other transport formats for further 159 study. 161 There are a number of situations where the simple end-to-end 162 readdressing functionality is not sufficient. These include the 163 initial reachability of a mobile host, location privacy, simultaneous 164 mobility of both hosts, and some modes of NAT traversal. In these 165 situations, there is a need for some helper functionality in the 166 network, such as a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis]. 167 Such functionality is out of the scope of this document. We also do 168 not consider localized mobility management extensions (i.e., mobility 169 management techniques that do not involve directly signaling the 170 correspondent node); this document is concerned with end-to-end 171 mobility. Making underlying IP mobility transparent to the transport 172 layer has implications on the proper response of transport congestion 173 control, path MTU selection, and Quality of Service (QoS). 174 Transport-layer mobility triggers, and the proper transport response 175 to a HIP mobility or multihoming address change, are outside the 176 scope of this document. 178 2. Terminology and Conventions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 LOCATOR_SET. The name of a HIP parameter containing zero or more 185 Locator fields. 187 Locator. A name that controls how the packet is routed through the 188 network and demultiplexed by the end host. It may include a 189 concatenation of traditional network addresses such as an IPv6 190 address and end-to-end identifiers such as an ESP SPI. It may 191 also include transport port numbers or IPv6 Flow Labels as 192 demultiplexing context, or it may simply be a network address. 194 Address. A name that denotes a point-of-attachment to the network. 195 The two most common examples are an IPv4 address and an IPv6 196 address. The set of possible addresses is a subset of the set of 197 possible locators. 199 Preferred locator. A locator on which a host prefers to receive 200 data. With respect to a given peer, a host always has one active 201 Preferred locator, unless there are no active locators. By 202 default, the locators used in the HIP base exchange are the 203 Preferred locators. 205 Credit Based Authorization. A host must verify a peer host's 206 reachability at a new locator. Credit-Based Authorization 207 authorizes the peer to receive a certain amount of data at the new 208 locator before the result of such verification is known. 210 3. Protocol Model 212 This section is an overview; more detailed specification follows this 213 section. 215 3.1. Operating Environment 217 The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key 218 establishment and parameter negotiation protocol. Its primary 219 applications are for authenticating host messages based on host 220 identities, and establishing security associations (SAs) for the ESP 221 transport format [I-D.ietf-hip-rfc5202-bis] and possibly other 222 protocols in the future. 224 +--------------------+ +--------------------+ 225 | | | | 226 | +------------+ | | +------------+ | 227 | | Key | | HIP | | Key | | 228 | | Management | <-+-----------------------+-> | Management | | 229 | | Process | | | | Process | | 230 | +------------+ | | +------------+ | 231 | ^ | | ^ | 232 | | | | | | 233 | v | | v | 234 | +------------+ | | +------------+ | 235 | | IPsec | | ESP | | IPsec | | 236 | | Stack | <-+-----------------------+-> | Stack | | 237 | | | | | | | | 238 | +------------+ | | +------------+ | 239 | | | | 240 | | | | 241 | Initiator | | Responder | 242 +--------------------+ +--------------------+ 244 Figure 1: HIP Deployment Model 246 The general deployment model for HIP is shown above, assuming 247 operation in an end-to-end fashion. This document specifies 248 extensions to the HIP protocol to enable end-host mobility and basic 249 multihoming. In summary, these extensions to the HIP base protocol 250 enable the signaling of new addressing information to the peer in HIP 251 messages. The messages are authenticated via a signature or keyed 252 hash message authentication code (HMAC) based on its Host Identity. 253 This document specifies the format of this new addressing 254 (LOCATOR_SET) parameter, the procedures for sending and processing 255 this parameter to enable basic host mobility, and procedures for a 256 concurrent address verification mechanism. 258 --------- 259 | TCP | (sockets bound to HITs) 260 --------- 261 | 262 --------- 263 ----> | ESP | {HIT_s, HIT_d} <-> SPI 264 | --------- 265 | | 266 ---- --------- 267 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 268 ---- --------- 269 | 270 --------- 271 | IP | 272 --------- 274 Figure 2: Architecture for HIP Host Mobility (MH) 276 Figure 2 depicts a layered architectural view of a HIP-enabled stack 277 using the ESP transport format. In HIP, upper-layer protocols 278 (including TCP and ESP in this figure) are bound to Host Identity 279 Tags (HITs) and not IP addresses. The HIP sublayer is responsible 280 for maintaining the binding between HITs and IP addresses. The SPI 281 is used to associate an incoming packet with the right HITs. The 282 block labeled "MH" is introduced below. 284 Consider first the case in which there is no mobility or multihoming, 285 as specified in the base protocol specification 286 [I-D.ietf-hip-rfc5201-bis]. The HIP base exchange establishes the 287 HITs in use between the hosts, the SPIs to use for ESP, and the IP 288 addresses (used in both the HIP signaling packets and ESP data 289 packets). Note that there can only be one such set of bindings in 290 the outbound direction for any given packet, and the only fields used 291 for the binding at the HIP layer are the fields exposed by ESP (the 292 SPI and HITs). For the inbound direction, the SPI is all that is 293 required to find the right host context. ESP rekeying events change 294 the mapping between the HIT pair and SPI, but do not change the IP 295 addresses. 297 Consider next a mobility event, in which a host moves to another IP 298 address. Two things must occur in this case. First, the peer must 299 be notified of the address change using a HIP UPDATE message. 300 Second, each host must change its local bindings at the HIP sublayer 301 (new IP addresses). It may be that both the SPIs and IP addresses 302 are changed simultaneously in a single UPDATE; the protocol described 303 herein supports this. However, simultaneous movement of both hosts, 304 notification of transport layer protocols of the path change, and 305 procedures for possibly traversing middleboxes are not covered by 306 this document. 308 3.1.1. Locator 310 This document defines a generalization of an address called a 311 "locator". A locator specifies a point-of-attachment to the network 312 but may also include additional end-to-end tunneling or per-host 313 demultiplexing context that affects how packets are handled below the 314 logical HIP sublayer of the stack. This generalization is useful 315 because IP addresses alone may not be sufficient to describe how 316 packets should be handled below HIP. For example, in a host 317 multihoming context, certain IP addresses may need to be associated 318 with certain ESP SPIs to avoid violating the ESP anti-replay window. 319 Addresses may also be affiliated with transport ports in certain 320 tunneling scenarios. Locators may simply be traditional network 321 addresses. The format of the locator fields in the LOCATOR_SET 322 parameter is defined in Section 4. 324 3.1.2. Mobility Overview 326 When a host moves to another address, it notifies its peer of the new 327 address by sending a HIP UPDATE packet containing a LOCATOR_SET 328 parameter. This UPDATE packet is acknowledged by the peer. For 329 reliability in the presence of packet loss, the UPDATE packet is 330 retransmitted as defined in the HIP protocol specification 331 [I-D.ietf-hip-rfc5201-bis]. The peer can authenticate the contents 332 of the UPDATE packet based on the signature and keyed hash of the 333 packet. 335 When using ESP Transport Format [I-D.ietf-hip-rfc5202-bis], the host 336 may at the same time decide to rekey its security association and 337 possibly generate a new Diffie-Hellman key; all of these actions are 338 triggered by including additional parameters in the UPDATE packet, as 339 defined in the base protocol specification [I-D.ietf-hip-rfc5201-bis] 340 and ESP extension [I-D.ietf-hip-rfc5202-bis]. 342 When using ESP (and possibly other transport modes in the future), 343 the host is able to receive packets that are protected using a HIP 344 created ESP SA from any address. Thus, a host can change its IP 345 address and continue to send packets to its peers without necessarily 346 rekeying. However, the peers are not able to send packets to these 347 new addresses before they can reliably and securely update the set of 348 addresses that they associate with the sending host. Furthermore, 349 mobility may change the path characteristics in such a manner that 350 reordering occurs and packets fall outside the ESP anti-replay window 351 for the SA, thereby requiring rekeying. 353 3.2. Protocol Overview 355 In this section, we briefly introduce a number of usage scenarios for 356 HIP host mobility. These scenarios assume that HIP is being used 357 with the ESP transform [I-D.ietf-hip-rfc5202-bis], although other 358 scenarios may be defined in the future. To understand these usage 359 scenarios, the reader should be at least minimally familiar with the 360 HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for 361 the (relatively) uninitiated reader, it is most important to keep in 362 mind that in HIP the actual payload traffic is protected with ESP, 363 and that the ESP SPI acts as an index to the right host-to-host 364 context. More specification details are found later in Section 4 and 365 Section 5. 367 The scenarios below assume that the two hosts have completed a single 368 HIP base exchange with each other. Both of the hosts therefore have 369 one incoming and one outgoing SA. Further, each SA uses the same 370 pair of IP addresses, which are the ones used in the base exchange. 372 The readdressing protocol is an asymmetric protocol where a mobile 373 host informs a peer host about changes of IP addresses on affected 374 SPIs. The readdressing exchange is designed to be piggybacked on 375 existing HIP exchanges. The majority of the packets on which the 376 LOCATOR_SET parameters are expected to be carried are UPDATE packets. 377 However, some implementations may want to experiment with sending 378 LOCATOR_SET parameters also on other packets, such as R1, I2, and 379 NOTIFY. 381 The scenarios below at times describe addresses as being in either an 382 ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a 383 host, newly-learned addresses of the peer must be verified before put 384 into active service, and addresses removed by the peer are put into a 385 deprecated state. Under limited conditions described below 386 (Section 5.6), an UNVERIFIED address may be used. The addressing 387 states are defined more formally in Section 5.1. 389 Hosts that use link-local addresses as source addresses in their HIP 390 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 391 provide a globally routable address either in the initial handshake 392 or via the LOCATOR_SET parameter. 394 3.2.1. Mobility with a Single SA Pair (No Rekeying) 396 A mobile host must sometimes change an IP address bound to an 397 interface. The change of an IP address might be needed due to a 398 change in the advertised IPv6 prefixes on the link, a reconnected PPP 399 link, a new DHCP lease, or an actual movement to another subnet. In 400 order to maintain its communication context, the host must inform its 401 peers about the new IP address. This first example considers the 402 case in which the mobile host has only one interface, IP address, a 403 single pair of SAs (one inbound, one outbound), and no rekeying 404 occurs on the SAs. We also assume that the new IP addresses are 405 within the same address family (IPv4 or IPv6) as the first address. 406 This is the simplest scenario, depicted in Figure 3. 408 Mobile Host Peer Host 410 UPDATE(ESP_INFO, LOCATOR_SET, SEQ) 411 -----------------------------------> 412 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 413 <----------------------------------- 414 UPDATE(ACK, ECHO_RESPONSE) 415 -----------------------------------> 417 Figure 3: Readdress without Rekeying, but with Address Check 419 The steps of the packet processing are as follows: 421 1. The mobile host may be disconnected from the peer host for a 422 brief period of time while it switches from one IP address to 423 another; this case is sometimes referred to in the literature as 424 a "break-before-make" case. The host may also obtain its new IP 425 address before loosing the old one ("make-before-break" case). 426 In either case, upon obtaining a new IP address, the mobile host 427 sends a LOCATOR_SET parameter to the peer host in an UPDATE 428 message. The UPDATE message also contains an ESP_INFO parameter 429 containing the values of the old and new SPIs for a security 430 association. In this case, the OLD SPI and NEW SPI parameters 431 both are set to the value of the preexisting incoming SPI; this 432 ESP_INFO does not trigger a rekeying event but is instead 433 included for possible parameter-inspecting middleboxes on the 434 path. The LOCATOR_SET parameter contains the new IP address 435 (Locator Type of "1", defined below) and a locator lifetime. The 436 mobile host waits for this UPDATE to be acknowledged, and 437 retransmits if necessary, as specified in the base specification 438 [I-D.ietf-hip-rfc5201-bis]. 440 2. The peer host receives the UPDATE, validates it, and updates any 441 local bindings between the HIP association and the mobile host's 442 destination address. The peer host MUST perform an address 443 verification by placing a nonce in the ECHO_REQUEST parameter of 444 the UPDATE message sent back to the mobile host. It also 445 includes an ESP_INFO parameter with the OLD SPI and NEW SPI 446 parameters both set to the value of the preexisting incoming SPI, 447 and sends this UPDATE (with piggybacked acknowledgment) to the 448 mobile host at its new address. The peer MAY use the new address 449 immediately, but it MUST limit the amount of data it sends to the 450 address until address verification completes. 452 3. The mobile host completes the readdress by processing the UPDATE 453 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 454 host receives this ECHO_RESPONSE, it considers the new address to 455 be verified and can put the address into full use. 457 While the peer host is verifying the new address, the new address is 458 marked as UNVERIFIED in the interim, and the old address is 459 DEPRECATED. Once the peer host has received a correct reply to its 460 UPDATE challenge, it marks the new address as ACTIVE and removes the 461 old address. 463 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) 465 The mobile host may decide to rekey the SAs at the same time that it 466 notifies the peer of the new address. In this case, the above 467 procedure described in Figure 3 is slightly modified. The UPDATE 468 message sent from the mobile host includes an ESP_INFO with the OLD 469 SPI set to the previous SPI, the NEW SPI set to the desired new SPI 470 value for the incoming SA, and the KEYMAT Index desired. Optionally, 471 the host may include a DIFFIE_HELLMAN parameter for a new Diffie- 472 Hellman key. The peer completes the request for a rekey as is 473 normally done for HIP rekeying, except that the new address is kept 474 as UNVERIFIED until the UPDATE nonce challenge is received as 475 described above. Figure 4 illustrates this scenario. 477 Mobile Host Peer Host 479 UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) 480 -----------------------------------> 481 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 482 <----------------------------------- 483 UPDATE(ACK, ECHO_RESPONSE) 484 -----------------------------------> 486 Figure 4: Readdress with Mobile-Initiated Rekey 488 3.2.3. Using LOCATOR_SETs across Addressing Realms 490 It is possible for HIP associations to migrate to a state in which 491 both parties are only using locators in different addressing realms. 492 For example, the two hosts may initiate the HIP association when both 493 are using IPv6 locators, then one host may loose its IPv6 494 connectivity and obtain an IPv4 address. In such a case, some type 495 of mechanism for interworking between the different realms must be 496 employed; such techniques are outside the scope of the present text. 498 The basic problem in this example is that the host readdressing to 499 IPv4 does not know a corresponding IPv4 address of the peer. This 500 may be handled (experimentally) by possibly configuring this address 501 information manually or in the DNS, or the hosts exchange both IPv4 502 and IPv6 addresses in the locator. 504 3.2.4. Network Renumbering 506 It is expected that IPv6 networks will be renumbered much more often 507 than most IPv4 networks. From an end-host point of view, network 508 renumbering is similar to mobility. 510 3.3. Other Considerations 512 3.3.1. Address Verification 514 When a HIP host receives a set of locators from another HIP host in a 515 LOCATOR_SET, it does not necessarily know whether the other host is 516 actually reachable at the claimed addresses. In fact, a malicious 517 peer host may be intentionally giving bogus addresses in order to 518 cause a packet flood towards the target addresses [RFC4225]. 519 Likewise, viral software may have compromised the peer host, 520 programming it to redirect packets to the target addresses. Thus, 521 the HIP host must first check that the peer is reachable at the new 522 address. 524 An additional potential benefit of performing address verification is 525 to allow middleboxes in the network along the new path to obtain the 526 peer host's inbound SPI. 528 Address verification is implemented by the challenger sending some 529 piece of unguessable information to the new address, and waiting for 530 some acknowledgment from the Responder that indicates reception of 531 the information at the new address. This may include the exchange of 532 a nonce, or the generation of a new SPI and observation of data 533 arriving on the new SPI. 535 3.3.2. Credit-Based Authorization 537 Credit-Based Authorization (CBA) allows a host to securely use a new 538 locator even though the peer's reachability at the address embedded 539 in the locator has not yet been verified. This is accomplished based 540 on the following three hypotheses: 542 1. A flooding attacker typically seeks to somehow multiply the 543 packets it generates for the purpose of its attack because 544 bandwidth is an ample resource for many victims. 546 2. An attacker can often cause unamplified flooding by sending 547 packets to its victim, either by directly addressing the victim 548 in the packets, or by guiding the packets along a specific path 549 by means of an IPv6 Routing header, if Routing headers are not 550 filtered by firewalls. 552 3. Consequently, the additional effort required to set up a 553 redirection-based flooding attack (without CBA and return 554 routability checks) would pay off for the attacker only if 555 amplification could be obtained this way. 557 On this basis, rather than eliminating malicious packet redirection 558 in the first place, Credit-Based Authorization prevents 559 amplifications. This is accomplished by limiting the data a host can 560 send to an unverified address of a peer by the data recently received 561 from that peer. Redirection-based flooding attacks thus become less 562 attractive than, for example, pure direct flooding, where the 563 attacker itself sends bogus packets to the victim. 565 Figure 5 illustrates Credit-Based Authorization: Host B measures the 566 amount of data recently received from peer A and, when A readdresses, 567 sends packets to A's new, unverified address as long as the sum of 568 the packet sizes does not exceed the measured, received data volume. 569 When insufficient credit is left, B stops sending further packets to 570 A until A's address becomes ACTIVE. The address changes may be due 571 to mobility, multihoming, or any other reason. Not shown in Figure 5 572 are the results of credit aging (Section 5.6.2), a mechanism used to 573 dampen possible time-shifting attacks. 575 +-------+ +-------+ 576 | A | | B | 577 +-------+ +-------+ 578 | | 579 address |------------------------------->| credit += size(packet) 580 ACTIVE | | 581 |------------------------------->| credit += size(packet) 582 |<-------------------------------| do not change credit 583 | | 584 + address change | 585 + address verification starts | 586 address |<-------------------------------| credit -= size(packet) 587 UNVERIFIED |------------------------------->| credit += size(packet) 588 |<-------------------------------| credit -= size(packet) 589 | | 590 |<-------------------------------| credit -= size(packet) 591 | X credit < size(packet) 592 | | => do not send packet! 593 + address verification concludes | 594 address | | 595 ACTIVE |<-------------------------------| do not change credit 596 | | 598 Figure 5: Readdressing Scenario 600 3.3.3. Preferred Locator 602 When a host has multiple locators, the peer host must decide which to 603 use for outbound packets. It may be that a host would prefer to 604 receive data on a particular inbound interface. HIP allows a 605 particular locator to be designated as a Preferred locator and 606 communicated to the peer (see Section 4). 608 4. LOCATOR_SET Parameter Format 610 The LOCATOR_SET parameter is a critical parameter as defined by 611 [I-D.ietf-hip-rfc5201-bis]. It consists of the standard HIP 612 parameter Type and Length fields, plus zero or more Locator sub- 613 parameters. Each Locator sub-parameter contains a Traffic Type, 614 Locator Type, Locator Length, Preferred locator bit, Locator 615 Lifetime, and a Locator encoding. A LOCATOR_SET containing zero 616 Locator fields is permitted but has the effect of deprecating all 617 addresses. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Traffic Type | Locator Type | Locator Length | Reserved |P| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Locator Lifetime | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Locator | 629 | | 630 | | 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 . . 634 . . 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Traffic Type | Locator Type | Locator Length | Reserved |P| 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Locator Lifetime | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Locator | 641 | | 642 | | 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 6: LOCATOR_SET Parameter Format 648 Type: 193 650 Length: Length in octets, excluding Type and Length fields, and 651 excluding padding. 653 Traffic Type: Defines whether the locator pertains to HIP signaling, 654 user data, or both. 656 Locator Type: Defines the semantics of the Locator field. 658 Locator Length: Defines the length of the Locator field, in units of 659 4-byte words (Locators up to a maximum of 4*255 octets are 660 supported). 662 Reserved: Zero when sent, ignored when received. 664 P: Preferred locator. Set to one if the locator is preferred for 665 that Traffic Type; otherwise, set to zero. 667 Locator Lifetime: Locator lifetime, in seconds. 669 Locator: The locator whose semantics and encoding are indicated by 670 the Locator Type field. All Locator sub-fields are integral 671 multiples of four octets in length. 673 The Locator Lifetime indicates how long the following locator is 674 expected to be valid. The lifetime is expressed in seconds. Each 675 locator MUST have a non-zero lifetime. The address is expected to 676 become deprecated when the specified number of seconds has passed 677 since the reception of the message. A deprecated address SHOULD NOT 678 be used as a destination address if an alternate (non-deprecated) is 679 available and has sufficient scope. 681 4.1. Traffic Type and Preferred Locator 683 The following Traffic Type values are defined: 685 0: Both signaling (HIP control packets) and user data. 687 1: Signaling packets only. 689 2: Data packets only. 691 The "P" bit, when set, has scope over the corresponding Traffic Type. 692 That is, when a "P" bit is set for Traffic Type "2", for example, it 693 means that the locator is preferred for data packets. If there is a 694 conflict (for example, if the "P" bit is set for an address of Type 695 "0" and a different address of Type "2"), the more specific Traffic 696 Type rule applies (in this case, "2"). By default, the IP addresses 697 used in the base exchange are Preferred locators for both signaling 698 and user data, unless a new Preferred locator supersedes them. If no 699 locators are indicated as preferred for a given Traffic Type, the 700 implementation may use an arbitrary locator from the set of active 701 locators. 703 4.2. Locator Type and Locator 705 The following Locator Type values are defined, along with the 706 associated semantics of the Locator field: 708 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] 709 (128 bits long). This locator type is defined primarily for non- 710 ESP-based usage. 712 1: The concatenation of an ESP SPI (first 32 bits) followed by an 713 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 714 128 bits). This IP address is defined primarily for ESP-based 715 usage. 717 4.3. UPDATE Packet with Included LOCATOR_SET 719 A number of combinations of parameters in an UPDATE packet are 720 possible (e.g., see Section 3.2). In this document, procedures are 721 defined only for the case in which one LOCATOR_SET and one ESP_INFO 722 parameter is used in any HIP packet. Furthermore, the LOCATOR_SET 723 SHOULD list all of the locators that are active on the HIP 724 association (including those on SAs not covered by the ESP_INFO 725 parameter). Any UPDATE packet that includes a LOCATOR_SET parameter 726 SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The 727 relationship between the announced Locators and any ESP_INFO 728 parameters present in the packet is defined in Section 5.2. The 729 sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for 730 further study; receivers may wish to experiment with supporting such 731 a possibility. 733 5. Processing Rules 735 This section describes rules for sending and receiving the 736 LOCATOR_SET parameter, testing address reachability, and using 737 Credit-Based Authorization (CBA) on UNVERIFIED locators. 739 5.1. Locator Data Structure and Status 741 In a typical implementation, each outgoing locator is represented by 742 a piece of state that contains the following data: 744 o the actual bit pattern representing the locator, 746 o the lifetime (seconds), 748 o the status (UNVERIFIED, ACTIVE, DEPRECATED), 750 o the Traffic Type scope of the locator, and 752 o whether the locator is preferred for any particular scope. 754 The status is used to track the reachability of the address embedded 755 within the LOCATOR_SET parameter: 757 UNVERIFIED indicates that the reachability of the address has not 758 been verified yet, 760 ACTIVE indicates that the reachability of the address has been 761 verified and the address has not been deprecated, 763 DEPRECATED indicates that the locator lifetime has expired. 765 The following state changes are allowed: 767 UNVERIFIED to ACTIVE The reachability procedure completes 768 successfully. 770 UNVERIFIED to DEPRECATED The locator lifetime expires while the 771 locator is UNVERIFIED. 773 ACTIVE to DEPRECATED The locator lifetime expires while the locator 774 is ACTIVE. 776 ACTIVE to UNVERIFIED There has been no traffic on the address for 777 some time, and the local policy mandates that the address 778 reachability must be verified again before starting to use it 779 again. 781 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 782 locator. 784 A DEPRECATED address MUST NOT be changed to ACTIVE without first 785 verifying its reachability. 787 Note that the state of whether or not a locator is preferred is not 788 necessarily the same as the value of the Preferred bit in the Locator 789 sub-parameter received from the peer. Peers may recommend certain 790 locators to be preferred, but the decision on whether to actually use 791 a locator as a preferred locator is a local decision, possibly 792 influenced by local policy. 794 5.2. Sending LOCATOR_SETs 796 The decision of when to send LOCATOR_SETs is basically a local policy 797 issue. However, it is RECOMMENDED that a host send a LOCATOR_SET 798 whenever it recognizes a change of its IP addresses in use on an 799 active HIP association, and assumes that the change is going to last 800 at least for a few seconds. It is possible to delay the exposure of 801 additional locators to the peer, and to send data from previously 802 unannounced locators, as might arise in certain mobility situations. 803 Rapidly sending LOCATOR_SETs that force the peer to change the 804 preferred address SHOULD be avoided. 806 When a host decides to inform its peers about changes in its IP 807 addresses, it has to decide how to group the various addresses with 808 SPIs. The grouping should consider also whether middlebox 809 interaction requires sending the same LOCATOR_SET in separate UPDATEs 810 on different paths. Since each SPI is associated with a different 811 Security Association, the grouping policy may also be based on ESP 812 anti-replay protection considerations. In the typical case, simply 813 basing the grouping on actual kernel level physical and logical 814 interfaces may be the best policy. Grouping policy is outside of the 815 scope of this document. 817 Note that the purpose of announcing IP addresses in a LOCATOR_SET is 818 to provide connectivity between the communicating hosts. In most 819 cases, tunnels or virtual interfaces such as IPsec tunnel interfaces 820 or Mobile IP home addresses provide sub-optimal connectivity. 821 Furthermore, it should be possible to replace most tunnels with HIP 822 based "non-tunneling", therefore making most virtual interfaces 823 fairly unnecessary in the future. Therefore, virtual interfaces 824 SHOULD NOT be announced in general. On the other hand, there are 825 clearly situations where tunnels are used for diagnostic and/or 826 testing purposes. In such and other similar cases announcing the IP 827 addresses of virtual interfaces may be appropriate. 829 Hosts MUST NOT announce broadcast or multicast addresses in 830 LOCATOR_SETs. Link-local addresses MAY be announced to peers that 831 are known to be neighbors on the same link, such as when the IP 832 destination address of a peer is also link-local. The announcement 833 of link-local addresses in this case is a policy decision; link-local 834 addresses used as Preferred locators will create reachability 835 problems when the host moves to another link. In any case, link- 836 local addresses MUST NOT be announced to a peer unless that peer is 837 known to be on the same link. 839 Once the host has decided on the groups and assignment of addresses 840 to the SPIs, it creates a LOCATOR_SET parameter that serves as a 841 complete representation of the addresses and affiliated SPIs intended 842 for active use. We now describe a few cases introduced in 843 Section 3.2. We assume that the Traffic Type for each locator is set 844 to "0" (other values for Traffic Type may be specified in documents 845 that separate the HIP control plane from data plane traffic). Other 846 mobility cases are possible but are left for further experimentation. 848 1. Host mobility with no multihoming and no rekeying. The mobile 849 host creates a single UPDATE containing a single ESP_INFO with a 850 single LOCATOR_SET parameter. The ESP_INFO contains the current 851 value of the SPI in both the OLD SPI and NEW SPI fields. The 852 LOCATOR_SET contains a single Locator with a "Locator Type" of 853 "1"; the SPI must match that of the ESP_INFO. The Preferred bit 854 SHOULD be set and the "Locator Lifetime" is set according to 855 local policy. The UPDATE also contains a SEQ parameter as usual. 856 This packet is retransmitted as defined in the HIP protocol 857 specification [I-D.ietf-hip-rfc5201-bis]. The UPDATE should be 858 sent to the peer's preferred IP address with an IP source address 859 corresponding to the address in the LOCATOR_SET parameter. 861 2. Host mobility with no multihoming but with rekeying. The mobile 862 host creates a single UPDATE containing a single ESP_INFO with a 863 single LOCATOR_SET parameter (with a single address). The 864 ESP_INFO contains the current value of the SPI in the OLD SPI and 865 the new value of the SPI in the NEW SPI, and a KEYMAT Index as 866 selected by local policy. Optionally, the host may choose to 867 initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN 868 parameter. The LOCATOR_SET contains a single Locator with 869 "Locator Type" of "1"; the SPI must match that of the NEW SPI in 870 the ESP_INFO. Otherwise, the steps are identical to the case in 871 which no rekeying is initiated. 873 The sending of multiple LOCATOR_SETs, locators with Locator Type "0", 874 and multiple ESP_INFO parameters is for further study. Note that the 875 inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" 876 locators since no SAs are set up at that point. 878 5.3. Handling Received LOCATOR_SETs 880 A host SHOULD be prepared to receive a LOCATOR_SET parameter in the 881 following HIP packets: R1, I2, UPDATE, and NOTIFY. 883 This document describes sending both ESP_INFO and LOCATOR_SET 884 parameters in an UPDATE. The ESP_INFO parameter is included when 885 there is a need to rekey or key a new SPI, and is otherwise included 886 for the possible benefit of HIP-aware middleboxes. The LOCATOR_SET 887 parameter contains a complete map of the locators that the host 888 wishes to make or keep active for the HIP association. 890 In general, the processing of a LOCATOR_SET depends upon the packet 891 type in which it is included. Here, we describe only the case in 892 which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are 893 sent in an UPDATE message; other cases are for further study. The 894 steps below cover each of the cases described in Section 5.2. 896 The processing of ESP_INFO and LOCATOR_SET parameters is intended to 897 be modular and support future generalization to the inclusion of 898 multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host 899 SHOULD first process the ESP_INFO before the LOCATOR_SET, since the 900 ESP_INFO may contain a new SPI value mapped to an existing SPI, while 901 a Type "1" locator will only contain a reference to the new SPI. 903 When a host receives a validated HIP UPDATE with a LOCATOR_SET and 904 ESP_INFO parameter, it processes the ESP_INFO as follows. The 905 ESP_INFO parameter indicates whether an SA is being rekeyed, created, 906 deprecated, or just identified for the benefit of middleboxes. The 907 host examines the OLD SPI and NEW SPI values in the ESP_INFO 908 parameter: 910 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both 911 correspond to an existing SPI, the ESP_INFO is gratuitous 912 (provided for middleboxes) and no rekeying is necessary. 914 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW 915 SPI is a different non-zero value, the existing SA is being 916 rekeyed and the host follows HIP ESP rekeying procedures by 917 creating a new outbound SA with an SPI corresponding to the NEW 918 SPI, with no addresses bound to this SPI. Note that locators in 919 the LOCATOR_SET parameter will reference this new SPI instead of 920 the old SPI. 922 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new 923 non-zero value, then a new SA is being requested by the peer. 924 This case is also treated like a rekeying event; the receiving 925 host must create a new SA and respond with an UPDATE ACK. 927 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and 928 the NEW SPI is zero, the SA is being deprecated and all locators 929 uniquely bound to the SPI are put into the DEPRECATED state. 931 If none of the above cases apply, a protocol error has occurred and 932 the processing of the UPDATE is stopped. 934 Next, the locators in the LOCATOR_SET parameter are processed. For 935 each locator listed in the LOCATOR_SET parameter, check that the 936 address therein is a legal unicast or anycast address. That is, the 937 address MUST NOT be a broadcast or multicast address. Note that some 938 implementations MAY accept addresses that indicate the local host, 939 since it may be allowed that the host runs HIP with itself. 941 The below assumes that all locators are of Type "1" with a Traffic 942 Type of "0"; other cases are for further study. 944 For each Type "1" address listed in the LOCATOR_SET parameter, the 945 host checks whether the address is already bound to the SPI 946 indicated. If the address is already bound, its lifetime is updated. 947 If the status of the address is DEPRECATED, the status is changed to 948 UNVERIFIED. If the address is not already bound, the address is 949 added, and its status is set to UNVERIFIED. Mark all addresses 950 corresponding to the SPI that were NOT listed in the LOCATOR_SET 951 parameter as DEPRECATED. 953 As a result, at the end of processing, the addresses listed in the 954 LOCATOR_SET parameter have either a state of UNVERIFIED or ACTIVE, 955 and any old addresses on the old SA not listed in the LOCATOR_SET 956 parameter have a state of DEPRECATED. 958 Once the host has processed the locators, if the LOCATOR_SET 959 parameter contains a new Preferred locator, the host SHOULD initiate 960 a change of the Preferred locator. This requires that the host first 961 verifies reachability of the associated address, and only then 962 changes the Preferred locator; see Section 5.5. 964 If a host receives a locator with an unsupported Locator Type, and 965 when such a locator is also declared to be the Preferred locator for 966 the peer, the host SHOULD send a NOTIFY error with a Notify Message 967 Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field 968 containing the locator(s) that the receiver failed to process. 969 Otherwise, a host MAY send a NOTIFY error if a (non-preferred) 970 locator with an unsupported Locator Type is received in a LOCATOR_SET 971 parameter. 973 A host MAY add the source IP address of a received HIP packet as a 974 candidate locator for the peer even if it is not listed in the peer's 975 LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the 976 LOCATOR_SET. 978 5.4. Verifying Address Reachability 980 A host MUST verify the reachability of an UNVERIFIED address. The 981 status of a newly learned address MUST initially be set to UNVERIFIED 982 unless the new address is advertised in a R1 packet as a new 983 Preferred locator. A host MAY also want to verify the reachability 984 of an ACTIVE address again after some time, in which case it would 985 set the status of the address to UNVERIFIED and reinitiate address 986 verification. 988 A host typically starts the address-verification procedure by sending 989 a nonce to the new address. For example, when the host is changing 990 its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD 991 be random and the value MAY be copied into an ECHO_REQUEST sent in 992 the rekeying UPDATE. However, if the host is not changing its SPI, 993 it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent 994 to the new address. A host MAY also use other message exchanges as 995 confirmation of the address reachability. 997 Note that in the case of receiving a LOCATOR_SET in an R1 and 998 replying with an I2 to the new address in the LOCATOR_SET, receiving 999 the corresponding R2 is sufficient proof of reachability for the 1000 Responder's preferred address. Since further address verification of 1001 such an address can impede the HIP-base exchange, a host MUST NOT 1002 separately verify reachability of a new Preferred locator that was 1003 received on an R1. 1005 In some cases, it MAY be sufficient to use the arrival of data on a 1006 newly advertised SA as implicit address reachability verification as 1007 depicted in Figure 7, instead of waiting for the confirmation via a 1008 HIP packet. In this case, a host advertising a new SPI as part of 1009 its address reachability check SHOULD be prepared to receive traffic 1010 on the new SA. 1012 Mobile host Peer host 1014 prepare incoming SA 1015 NEW SPI in ESP_INFO (UPDATE) 1016 <----------------------------------- 1017 switch to new outgoing SA 1018 data on new SA 1019 -----------------------------------> 1020 mark address ACTIVE 1022 Figure 7: Address Activation Via Use of a New SA 1024 When address verification is in progress for a new Preferred locator, 1025 the host SHOULD select a different locator listed as ACTIVE, if one 1026 such locator is available, to continue communications until address 1027 verification completes. Alternatively, the host MAY use the new 1028 Preferred locator while in UNVERIFIED status to the extent Credit- 1029 Based Authorization permits. Credit-Based Authorization is explained 1030 in Section 5.6. Once address verification succeeds, the status of 1031 the new Preferred locator changes to ACTIVE. 1033 5.5. Changing the Preferred Locator 1035 A host MAY want to change the Preferred outgoing locator for 1036 different reasons, e.g., because traffic information or ICMP error 1037 messages indicate that the currently used preferred address may have 1038 become unreachable. Another reason may be due to receiving a 1039 LOCATOR_SET parameter that has the "P" bit set. 1041 To change the Preferred locator, the host initiates the following 1042 procedure: 1044 1. If the new Preferred locator has ACTIVE status, the Preferred 1045 locator is changed and the procedure succeeds. 1047 2. If the new Preferred locator has UNVERIFIED status, the host 1048 starts to verify its reachability. The host SHOULD use a 1049 different locator listed as ACTIVE until address verification 1050 completes if one such locator is available. Alternatively, the 1051 host MAY use the new Preferred locator, even though in UNVERIFIED 1052 status, to the extent Credit-Based Authorization permits. Once 1053 address verification succeeds, the status of the new Preferred 1054 locator changes to ACTIVE and its use is no longer governed by 1055 Credit-Based Authorization. 1057 3. If the peer host has not indicated a preference for any address, 1058 then the host picks one of the peer's ACTIVE addresses randomly 1059 or according to policy. This case may arise if, for example, 1060 ICMP error messages that deprecate the Preferred locator arrive, 1061 but the peer has not yet indicated a new Preferred locator. 1063 4. If the new Preferred locator has DEPRECATED status and there is 1064 at least one non-deprecated address, the host selects one of the 1065 non-deprecated addresses as a new Preferred locator and 1066 continues. If the selected address is UNVERIFIED, the address 1067 verification procedure described above will apply. 1069 5.6. Credit-Based Authorization 1071 To prevent redirection-based flooding attacks, the use of a Credit- 1072 Based Authorization (CBA) approach is mandatory when a host sends 1073 data to an UNVERIFIED locator. The following algorithm meets the 1074 security considerations for prevention of amplification and time- 1075 shifting attacks. Other forms of credit aging, and other values for 1076 the CreditAgingFactor and CreditAgingInterval parameters in 1077 particular, are for further study, and so are the advanced CBA 1078 techniques specified in [CBA-MIPv6]. 1080 5.6.1. Handling Payload Packets 1082 A host maintains a "credit counter" for each of its peers. Whenever 1083 a packet arrives from a peer, the host SHOULD increase that peer's 1084 credit counter by the size of the received packet. When the host has 1085 a packet to be sent to the peer, and when the peer's Preferred 1086 locator is listed as UNVERIFIED and no alternative locator with 1087 status ACTIVE is available, the host checks whether it can send the 1088 packet to the UNVERIFIED locator. The packet SHOULD be sent if the 1089 value of the credit counter is higher than the size of the outbound 1090 packet. If the credit counter is too low, the packet MUST be 1091 discarded or buffered until address verification succeeds. When a 1092 packet is sent to a peer at an UNVERIFIED locator, the peer's credit 1093 counter MUST be reduced by the size of the packet. The peer's credit 1094 counter is not affected by packets that the host sends to an ACTIVE 1095 locator of that peer. 1097 Figure 8 depicts the actions taken by the host when a packet is 1098 received. Figure 9 shows the decision chain in the event a packet is 1099 sent. 1101 Inbound 1102 packet 1103 | 1104 | +----------------+ +---------------+ 1105 | | Increase | | Deliver | 1106 +-----> | credit counter |-------------> | packet to | 1107 | by packet size | | application | 1108 +----------------+ +---------------+ 1110 Figure 8: Receiving Packets with Credit-Based Authorization 1112 Outbound 1113 packet 1114 | _________________ 1115 | / \ +---------------+ 1116 | / Is the preferred \ No | Send packet | 1117 +-----> | destination address |-------------> | to preferred | 1118 \ UNVERIFIED? / | address | 1119 \_________________/ +---------------+ 1120 | 1121 | Yes 1122 | 1123 v 1124 _________________ 1125 / \ +---------------+ 1126 / Does an ACTIVE \ Yes | Send packet | 1127 | destination address |-------------> | to ACTIVE | 1128 \ exist? / | address | 1129 \_________________/ +---------------+ 1130 | 1131 | No 1132 | 1133 v 1134 _________________ 1135 / \ +---------------+ 1136 / Credit counter \ No | | 1137 | >= |-------------> | Drop packet | 1138 \ packet size? / | | 1139 \_________________/ +---------------+ 1140 | 1141 | Yes 1142 | 1143 v 1144 +---------------+ +---------------+ 1145 | Reduce credit | | Send packet | 1146 | counter by |----------------> | to preferred | 1147 | packet size | | address | 1148 +---------------+ +---------------+ 1150 Figure 9: Sending Packets with Credit-Based Authorization 1152 5.6.2. Credit Aging 1154 A host ensures that the credit counters it maintains for its peers 1155 gradually decrease over time. Such "credit aging" prevents a 1156 malicious peer from building up credit at a very slow speed and using 1157 this, all at once, for a severe burst of redirected packets. 1159 Credit aging may be implemented by multiplying credit counters with a 1160 factor, CreditAgingFactor (a fractional value less than one), in 1161 fixed time intervals of CreditAgingInterval length. Choosing 1162 appropriate values for CreditAgingFactor and CreditAgingInterval is 1163 important to ensure that a host can send packets to an address in 1164 state UNVERIFIED even when the peer sends at a lower rate than the 1165 host itself. When CreditAgingFactor or CreditAgingInterval are too 1166 small, the peer's credit counter might be too low to continue sending 1167 packets until address verification concludes. 1169 The parameter values proposed in this document are as follows: 1171 CreditAgingFactor 7/8 1172 CreditAgingInterval 5 seconds 1174 These parameter values work well when the host transfers a file to 1175 the peer via a TCP connection and the end-to-end round-trip time does 1176 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1177 use other parameter values or different parameters, which may even be 1178 dynamically established. 1180 6. Security Considerations 1182 The HIP mobility mechanism provides a secure means of updating a 1183 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1184 cryptographically verifies the sender of an UPDATE, so forging or 1185 replaying a HIP UPDATE packet is very difficult (see 1186 [I-D.ietf-hip-rfc5201-bis]). Therefore, security issues reside in 1187 other attack domains. The two we consider are malicious redirection 1188 of legitimate connections as well as redirection-based flooding 1189 attacks using this protocol. This can be broken down into the 1190 following: 1192 Impersonation attacks 1194 - direct conversation with the misled victim 1196 - man-in-the-middle attack 1198 DoS attacks 1200 - flooding attacks (== bandwidth-exhaustion attacks) 1202 * tool 1: direct flooding 1204 * tool 2: flooding by zombies 1206 * tool 3: redirection-based flooding 1208 - memory-exhaustion attacks 1210 - computational-exhaustion attacks 1212 We consider these in more detail in the following sections. 1214 In Section 6.1 and Section 6.2, we assume that all users are using 1215 HIP. In Section 6.3 we consider the security ramifications when we 1216 have both HIP and non-HIP users. Security considerations for Credit- 1217 Based Authorization are discussed in [SIMPLE-CBA]. 1219 6.1. Impersonation Attacks 1221 An attacker wishing to impersonate another host will try to mislead 1222 its victim into directly communicating with them, or carry out a man- 1223 in-the-middle (MitM) attack between the victim and the victim's 1224 desired communication peer. Without mobility support, both attack 1225 types are possible only if the attacker resides on the routing path 1226 between its victim and the victim's desired communication peer, or if 1227 the attacker tricks its victim into initiating the connection over an 1228 incorrect routing path (e.g., by acting as a router or using spoofed 1229 DNS entries). 1231 The HIP extensions defined in this specification change the situation 1232 in that they introduce an ability to redirect a connection (like 1233 IPv6), both before and after establishment. If no precautionary 1234 measures are taken, an attacker could misuse the redirection feature 1235 to impersonate a victim's peer from any arbitrary location. The 1236 authentication and authorization mechanisms of the HIP base exchange 1237 [I-D.ietf-hip-rfc5201-bis] and the signatures in the UPDATE message 1238 prevent this attack. Furthermore, ownership of a HIP association is 1239 securely linked to a HIP HI/HIT. If an attacker somehow uses a bug 1240 in the implementation or weakness in some protocol to redirect a HIP 1241 connection, the original owner can always reclaim their connection 1242 (they can always prove ownership of the private key associated with 1243 their public HI). 1245 MitM attacks are always possible if the attacker is present during 1246 the initial HIP base exchange and if the hosts do not authenticate 1247 each other's identities. However, once the opportunistic base 1248 exchange has taken place, even a MitM cannot steal the HIP connection 1249 anymore because it is very difficult for an attacker to create an 1250 UPDATE packet (or any HIP packet) that will be accepted as a 1251 legitimate update. UPDATE packets use HMAC and are signed. Even 1252 when an attacker can snoop packets to obtain the SPI and HIT/HI, they 1253 still cannot forge an UPDATE packet without knowledge of the secret 1254 keys. 1256 6.2. Denial-of-Service Attacks 1258 6.2.1. Flooding Attacks 1260 The purpose of a denial-of-service attack is to exhaust some resource 1261 of the victim such that the victim ceases to operate correctly. A 1262 denial-of-service attack can aim at the victim's network attachment 1263 (flooding attack), its memory, or its processing capacity. In a 1264 flooding attack, the attacker causes an excessive number of bogus or 1265 unwanted packets to be sent to the victim, which fills their 1266 available bandwidth. Note that the victim does not necessarily need 1267 to be a node; it can also be an entire network. The attack basically 1268 functions the same way in either case. 1270 An effective DoS strategy is distributed denial of service (DDoS). 1271 Here, the attacker conventionally distributes some viral software to 1272 as many nodes as possible. Under the control of the attacker, the 1273 infected nodes, or "zombies", jointly send packets to the victim. 1274 With such an 'army', an attacker can take down even very high 1275 bandwidth networks/victims. 1277 With the ability to redirect connections, an attacker could realize a 1278 DDoS attack without having to distribute viral code. Here, the 1279 attacker initiates a large download from a server, and subsequently 1280 redirects this download to its victim. The attacker can repeat this 1281 with multiple servers. This threat is mitigated through reachability 1282 checks and credit-based authorization. Both strategies do not 1283 eliminate flooding attacks per se, but they preclude: (i) their use 1284 from a location off the path towards the flooded victim; and (ii) any 1285 amplification in the number and size of the redirected packets. As a 1286 result, the combination of a reachability check and credit-based 1287 authorization lowers a HIP redirection-based flooding attack to the 1288 level of a direct flooding attack in which the attacker itself sends 1289 the flooding traffic to the victim. 1291 6.2.2. Memory/Computational-Exhaustion DoS Attacks 1293 We now consider whether or not the proposed extensions to HIP add any 1294 new DoS attacks (consideration of DoS attacks using the base HIP 1295 exchange and updates is discussed in [I-D.ietf-hip-rfc5201-bis]). A 1296 simple attack is to send many UPDATE packets containing many IP 1297 addresses that are not flagged as preferred. The attacker continues 1298 to send such packets until the number of IP addresses associated with 1299 the attacker's HI crashes the system. Therefore, there SHOULD be a 1300 limit to the number of IP addresses that can be associated with any 1301 HI. Other forms of memory/computationally exhausting attacks via the 1302 HIP UPDATE packet are handled in the base HIP document 1303 [I-D.ietf-hip-rfc5201-bis]. 1305 A central server that has to deal with a large number of mobile 1306 clients may consider increasing the SA lifetimes to try to slow down 1307 the rate of rekeying UPDATEs or increasing the cookie difficulty to 1308 slow down the rate of attack-oriented connections. 1310 6.3. Mixed Deployment Environment 1312 We now assume an environment with both HIP and non-HIP aware hosts. 1313 Four cases exist. 1315 1. A HIP host redirects its connection onto a non-HIP host. The 1316 non-HIP host will drop the reachability packet, so this is not a 1317 threat unless the HIP host is a MitM that could somehow respond 1318 successfully to the reachability check. 1320 2. A non-HIP host attempts to redirect their connection onto a HIP 1321 host. This falls into IPv4 and IPv6 security concerns, which are 1322 outside the scope of this document. 1324 3. A non-HIP host attempts to steal a HIP host's session (assume 1325 that Secure Neighbor Discovery is not active for the following). 1326 The non-HIP host contacts the service that a HIP host has a 1327 connection with and then attempts to change its IP address to 1328 steal the HIP host's connection. What will happen in this case 1329 is implementation dependent but such a request should fail by 1330 being ignored or dropped. Even if the attack were successful, 1331 the HIP host could reclaim its connection via HIP. 1333 4. A HIP host attempts to steal a non-HIP host's session. A HIP 1334 host could spoof the non-HIP host's IP address during the base 1335 exchange or set the non-HIP host's IP address as its preferred 1336 address via an UPDATE. Other possibilities exist, but a simple 1337 solution is to prevent the use of HIP address check information 1338 to influence non-HIP sessions. 1340 7. IANA Considerations 1342 The following changes to the "Host Identity Protocol (HIP) 1343 Parameters" registries are requested. 1345 The existing Parameter Type of 'LOCATOR' (value 193) should be 1346 renamed to 'LOCATOR_SET' and the reference should be updated from 1347 RFC5206 to this specification. 1349 The existing Notify Message Type of 'LOCATOR_TYPE_UNSUPPORTED' (value 1350 46) should have its reference updated from RFC5206 to this 1351 specification. 1353 8. Authors and Acknowledgments 1355 Pekka Nikander and Jari Arkko originated this document, and Christian 1356 Vogt and Thomas Henderson (editor) later joined as co-authors. Greg 1357 Perkins contributed the initial draft of the security section. Petri 1358 Jokela was a co-author of the initial individual submission. 1360 The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, Jan Melen, 1361 Baris Boyvat, and Samu Varjonen for many improvements to the 1362 document. 1364 9. References 1366 9.1. Normative references 1368 [I-D.ietf-hip-rfc5201-bis] 1369 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 1370 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 1371 hip-rfc5201-bis-14 (work in progress), October 2013. 1373 [I-D.ietf-hip-rfc5202-bis] 1374 Jokela, P., Moskowitz, R., and J. Melen, "Using the 1375 Encapsulating Security Payload (ESP) Transport Format with 1376 the Host Identity Protocol (HIP)", draft-ietf-hip- 1377 rfc5202-bis-05 (work in progress), November 2013. 1379 [I-D.ietf-hip-rfc5204-bis] 1380 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1381 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-04 (work 1382 in progress), June 2014. 1384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1385 Requirement Levels", BCP 14, RFC 2119, March 1997. 1387 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1388 Architecture", RFC 4291, February 2006. 1390 9.2. Informative references 1392 [CBA-MIPv6] 1393 Vogt, C. and J. Arkko, "Credit-Based Authorization for 1394 Mobile IPv6 Early Binding Updates", February 2005. 1396 [I-D.ietf-hip-rfc4423-bis] 1397 Moskowitz, R. and M. Komu, "Host Identity Protocol 1398 Architecture", draft-ietf-hip-rfc4423-bis-08 (work in 1399 progress), April 2014. 1401 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1402 Nordmark, "Mobile IP Version 6 Route Optimization Security 1403 Design Background", RFC 4225, December 2005. 1405 [SIMPLE-CBA] 1406 Vogt, C. and J. Arkko, "Credit-Based Authorization for 1407 Concurrent Reachability Verification", February 2006. 1409 Appendix A. Document Revision History 1411 To be removed upon publication 1413 +----------+--------------------------------------------------------+ 1414 | Revision | Comments | 1415 +----------+--------------------------------------------------------+ 1416 | draft-00 | Initial version from RFC5206 xml (unchanged). | 1417 | | | 1418 | draft-01 | Remove multihoming-specific text; no other changes. | 1419 | | | 1420 | draft-02 | Update references to point to -bis drafts; no other | 1421 | | changes. | 1422 | | | 1423 | draft-03 | issue 4: add make before break use case | 1424 | | | 1425 | | issue 6: peer locator exposure policies | 1426 | | | 1427 | | issue 10: rename LOCATOR to LOCATOR_SET | 1428 | | | 1429 | | issue 14: use of UPDATE packet's IP address | 1430 | | | 1431 | draft-04 | Document refresh; no other changes. | 1432 | | | 1433 | draft-05 | Document refresh; no other changes. | 1434 | | | 1435 | draft-06 | Document refresh; no other changes. | 1436 | | | 1437 | draft-07 | Document refresh; IANA considerations updated. | 1438 +----------+--------------------------------------------------------+ 1440 Authors' Addresses 1442 Thomas R. Henderson (editor) 1443 University of Washington 1444 Campus Box 352500 1445 Seattle, WA 1446 USA 1448 EMail: tomhend@u.washington.edu 1449 Christian Vogt 1450 Ericsson Research NomadicLab 1451 Hirsalantie 11 1452 JORVAS FIN-02420 1453 FINLAND 1455 EMail: christian.vogt@ericsson.com 1457 Jari Arkko 1458 Ericsson Research NomadicLab 1459 JORVAS FIN-02420 1460 FINLAND 1462 Phone: +358 40 5079256 1463 EMail: jari.arkko@ericsson.com