idnits 2.17.1 draft-ietf-hip-rfc5206-bis-13.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 date (September 9, 2016) is 2784 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 (-12) exists of draft-ietf-hip-multihoming-10 Summary: 0 errors (**), 0 flaws (~~), 2 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 Independent 6 Expires: March 13, 2017 J. Arkko 7 Ericsson 8 September 9, 2016 10 Host Mobility with the Host Identity Protocol 11 draft-ietf-hip-rfc5206-bis-13 13 Abstract 15 This document defines a mobility extension to the Host Identity 16 Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" 17 parameter for HIP messages that allows for a HIP host to notify peers 18 about alternate addresses at which it may be reached. This document 19 also defines how the parameter can be used to preserve communications 20 across a change to the IP address used by one or both peer hosts. 21 The same LOCATOR_SET parameter can also be used to support end-host 22 multihoming, but the procedures are out of scope for this document 23 and are specified elsewhere. 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 March 13, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 Table of Contents 59 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 61 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 63 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 7 65 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 66 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . 8 67 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated 68 Rekey) . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2.3. Mobility messaging through rendezvous server . . . . 10 70 3.2.4. Network Renumbering . . . . . . . . . . . . . . . . . 12 71 3.3. Other Considerations . . . . . . . . . . . . . . . . . . 12 72 3.3.1. Address Verification . . . . . . . . . . . . . . . . 12 73 3.3.2. Credit-Based Authorization . . . . . . . . . . . . . 12 74 3.3.3. Preferred Locator . . . . . . . . . . . . . . . . . . 14 75 4. LOCATOR_SET Parameter Format . . . . . . . . . . . . . . . . 14 76 4.1. Traffic Type and Preferred Locator . . . . . . . . . . . 16 77 4.2. Locator Type and Locator . . . . . . . . . . . . . . . . 16 78 4.3. UPDATE Packet with Included LOCATOR_SET . . . . . . . . . 17 79 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 17 80 5.1. Locator Data Structure and Status . . . . . . . . . . . . 17 81 5.2. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 19 82 5.3. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 19 83 5.4. Verifying Address Reachability . . . . . . . . . . . . . 22 84 5.5. Changing the Preferred Locator . . . . . . . . . . . . . 23 85 5.6. Credit-Based Authorization . . . . . . . . . . . . . . . 23 86 5.6.1. Handling Payload Packets . . . . . . . . . . . . . . 24 87 5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . 25 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 89 6.1. Impersonation Attacks . . . . . . . . . . . . . . . . . . 27 90 6.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 28 91 6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . 28 92 6.2.2. Memory/Computational-Exhaustion DoS Attacks . . . . . 28 93 6.3. Mixed Deployment Environment . . . . . . . . . . . . . . 29 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 95 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 30 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 9.1. Normative references . . . . . . . . . . . . . . . . . . 30 98 9.2. Informative references . . . . . . . . . . . . . . . . . 31 99 Appendix A. Document Revision History . . . . . . . . . . . . . 32 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 102 1. Introduction and Scope 104 The Host Identity Protocol [RFC7401] (HIP) supports an architecture 105 that decouples the transport layer (TCP, UDP, etc.) from the 106 internetworking layer (IPv4 and IPv6) by using public/private key 107 pairs, instead of IP addresses, as host identities. When a host uses 108 HIP, the overlying protocol sublayers (e.g., transport layer sockets 109 and Encapsulating Security Payload (ESP) Security Associations (SAs)) 110 are instead bound to representations of these host identities, and 111 the IP addresses are only used for packet forwarding. However, each 112 host must also know at least one IP address at which its peers are 113 reachable. Initially, these IP addresses are the ones used during 114 the HIP base exchange. 116 One consequence of such a decoupling is that new solutions to 117 network-layer mobility and host multihoming are possible. There are 118 potentially many variations of mobility and multihoming possible. 119 The scope of this document encompasses messaging and elements of 120 procedure for basic network-level host mobility, leaving more 121 complicated mobility scenarios, multihoming, and other variations for 122 further study. More specifically, the following are in scope: 124 This document defines a LOCATOR_SET parameter for use in HIP 125 messages. The LOCATOR_SET parameter allows a HIP host to notify a 126 peer about alternate locators at which it is reachable. The 127 locators may be merely IP addresses, or they may have additional 128 multiplexing and demultiplexing context to aid with the packet 129 handling in the lower layers. For instance, an IP address may 130 need to be paired with an ESP Security Parameter Index (SPI) so 131 that packets are sent on the correct SA for a given address. 133 This document also specifies the messaging and elements of 134 procedure for end-host mobility of a HIP host. In particular, 135 message flows to enable successful host mobility, including 136 address verification methods, are defined herein. 138 The HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] can be used 139 to manage simultaneous mobility of both hosts, initial 140 reacahability of a mobile host, location privacy, and some modes 141 of NAT traversal. Use of the HIP rendezvous server to manage the 142 simultaneous mobility of both hosts is specified herein. 144 The following topics are out of scope: 146 While the same LOCATOR_SET parameter supports host multihoming 147 (simultaneous use of a number of addresses), procedures for host 148 multihoming are out of scope, and are specified in 149 [I-D.ietf-hip-multihoming]. 151 While HIP can potentially be used with transports other than the 152 ESP transport format [RFC7402], this document largely assumes the 153 use of ESP and leaves other transport formats for further study. 155 We do not consider localized mobility management extensions (i.e., 156 mobility management techniques that do not involve directly 157 signaling the correspondent node); this document is concerned with 158 end-to-end mobility. 160 Finally, making underlying IP mobility transparent to the 161 transport layer has implications on the proper response of 162 transport congestion control, path MTU selection, and Quality of 163 Service (QoS). Transport-layer mobility triggers, and the proper 164 transport response to a HIP mobility or multihoming address 165 change, are outside the scope of this document. 167 2. Terminology and Conventions 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 LOCATOR_SET. A HIP parameter containing zero or more Locator fields. 175 Locator. A name that controls how the packet is routed through the 176 network and demultiplexed by the end host. It may include a 177 concatenation of traditional network addresses such as an IPv6 178 address and end-to-end identifiers such as an ESP SPI. It may 179 also include transport port numbers or IPv6 Flow Labels as 180 demultiplexing context, or it may simply be a network address. 182 Address. A name that denotes a point-of-attachment to the network. 183 The two most common examples are an IPv4 address and an IPv6 184 address. The set of possible addresses is a subset of the set of 185 possible locators. 187 Preferred locator. A locator on which a host prefers to receive 188 data. Certain locators are labelled as preferred when a host 189 advertises its locator set to its peer. By default, the locators 190 used in the HIP base exchange are the preferred locators. The use 191 of preferred locators, including the scenario where multiple 192 address scopes and families may be in use, is defined more in 193 [I-D.ietf-hip-multihoming] than in this document. 195 Credit Based Authorization. A mechanism allowing a host to send a 196 certain amount of data to a peer's newly announced locator before 197 the result of mandatory address verification is known. 199 3. Protocol Model 201 This section is an overview; more detailed specification follows this 202 section. 204 3.1. Operating Environment 206 The Host Identity Protocol (HIP) [RFC7401] is a key establishment and 207 parameter negotiation protocol. Its primary applications are for 208 authenticating host messages based on host identities, and 209 establishing security associations (SAs) for the ESP transport format 210 [RFC7402] and possibly other protocols in the future. 212 +--------------------+ +--------------------+ 213 | | | | 214 | +------------+ | | +------------+ | 215 | | Key | | HIP | | Key | | 216 | | Management | <-+-----------------------+-> | Management | | 217 | | Process | | | | Process | | 218 | +------------+ | | +------------+ | 219 | ^ | | ^ | 220 | | | | | | 221 | v | | v | 222 | +------------+ | | +------------+ | 223 | | IPsec | | ESP | | IPsec | | 224 | | Stack | <-+-----------------------+-> | Stack | | 225 | | | | | | | | 226 | +------------+ | | +------------+ | 227 | | | | 228 | | | | 229 | Initiator | | Responder | 230 +--------------------+ +--------------------+ 232 Figure 1: HIP Deployment Model 234 The general deployment model for HIP is shown above, assuming 235 operation in an end-to-end fashion. This document specifies an 236 extension to the HIP protocol to enable end-host mobility. In 237 summary, these extensions to the HIP base protocol enable the 238 signaling of new addressing information to the peer in HIP messages. 239 The messages are authenticated via a signature or keyed hash message 240 authentication code (HMAC) based on its Host Identity. This document 241 specifies the format of this new addressing (LOCATOR_SET) parameter, 242 the procedures for sending and processing this parameter to enable 243 basic host mobility, and procedures for a concurrent address 244 verification mechanism. 246 --------- 247 | TCP | (sockets bound to HITs) 248 --------- 249 | 250 --------- 251 ----> | ESP | {HIT_s, HIT_d} <-> SPI 252 | --------- 253 | | 254 ---- --------- 255 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 256 ---- --------- 257 | 258 --------- 259 | IP | 260 --------- 262 Figure 2: Architecture for HIP Host Mobility (MH) 264 Figure 2 depicts a layered architectural view of a HIP-enabled stack 265 using the ESP transport format. In HIP, upper-layer protocols 266 (including TCP and ESP in this figure) are bound to Host Identity 267 Tags (HITs) and not IP addresses. The HIP sublayer is responsible 268 for maintaining the binding between HITs and IP addresses. The SPI 269 is used to associate an incoming packet with the right HITs. The 270 block labeled "MH" is introduced below. 272 Consider first the case in which there is no mobility or multihoming, 273 as specified in the base protocol specification [RFC7401]. The HIP 274 base exchange establishes the HITs in use between the hosts, the SPIs 275 to use for ESP, and the IP addresses (used in both the HIP signaling 276 packets and ESP data packets). Note that there can only be one such 277 set of bindings in the outbound direction for any given packet, and 278 the only fields used for the binding at the HIP layer are the fields 279 exposed by ESP (the SPI and HITs). For the inbound direction, the 280 SPI is all that is required to find the right host context. ESP 281 rekeying events change the mapping between the HIT pair and SPI, but 282 do not change the IP addresses. 284 Consider next a mobility event, in which a host moves to another IP 285 address. Two things must occur in this case. First, the peer must 286 be notified of the address change using a HIP UPDATE message. 287 Second, each host must change its local bindings at the HIP sublayer 288 (new IP addresses). It may be that both the SPIs and IP addresses 289 are changed simultaneously in a single UPDATE; the protocol described 290 herein supports this. Although internal notification of transport 291 layer protocols regarding the path change (e.g. to reset congestion 292 control variables) may be desired, this specification does not 293 address such internal notification. In addition, elements of 294 procedure for traversing middleboxes, including network address 295 translators, may complicate the above basic scenario and are not 296 covered by this document. 298 3.1.1. Locator 300 This document defines a generalization of an address called a 301 "locator". A locator specifies a point-of-attachment to the network 302 but may also include additional end-to-end tunneling or per-host 303 demultiplexing context that affects how packets are handled below the 304 logical HIP sublayer of the stack. This generalization is useful 305 because IP addresses alone may not be sufficient to describe how 306 packets should be handled below HIP. For example, in a host 307 multihoming context, certain IP addresses may need to be associated 308 with certain ESP SPIs to avoid violating the ESP anti-replay window. 309 Addresses may also be affiliated with transport ports in certain 310 tunneling scenarios. Locators may simply be traditional network 311 addresses. The format of the locator fields in the LOCATOR_SET 312 parameter is defined in Section 4. 314 3.1.2. Mobility Overview 316 When a host moves to another address, it notifies its peer of the new 317 address by sending a HIP UPDATE packet containing a single 318 LOCATOR_SET parameter and a single ESP_INFO parameter. This UPDATE 319 packet is acknowledged by the peer. For reliability in the presence 320 of packet loss, the UPDATE packet is retransmitted as defined in the 321 HIP protocol specification [RFC7401]. The peer can authenticate the 322 contents of the UPDATE packet based on the signature and keyed hash 323 of the packet. 325 When using ESP Transport Format [RFC7402], the host may at the same 326 time decide to rekey its security association and possibly generate a 327 new Diffie-Hellman key; all of these actions are triggered by 328 including additional parameters in the UPDATE packet, as defined in 329 the base protocol specification [RFC7401] and ESP extension 330 [RFC7402]. 332 When using ESP (and possibly other transport modes in the future), 333 the host is able to receive packets that are protected using a HIP 334 created ESP SA from any address. Thus, a host can change its IP 335 address and continue to send packets to its peers without necessarily 336 rekeying. However, the peers are not able to send packets to these 337 new addresses before they can reliably and securely update the set of 338 addresses that they associate with the sending host. Furthermore, 339 mobility may change the path characteristics in such a manner that 340 reordering occurs and packets fall outside the ESP anti-replay window 341 for the SA, thereby requiring rekeying. 343 3.2. Protocol Overview 345 In this section, we briefly introduce a number of usage scenarios for 346 HIP host mobility. These scenarios assume that HIP is being used 347 with the ESP transform [RFC7402], although other scenarios may be 348 defined in the future. To understand these usage scenarios, the 349 reader should be at least minimally familiar with the HIP protocol 350 specification [RFC7401] and with the use of ESP with HIP [RFC7402]. 351 According to these specifications, the data traffic in a HIP session 352 is protected with ESP, and the ESP SPI acts as an index to the right 353 host-to-host context. More specification details are found later in 354 Section 4 and Section 5. 356 The scenarios below assume that the two hosts have completed a single 357 HIP base exchange with each other. Both of the hosts therefore have 358 one incoming and one outgoing SA. Further, each SA uses the same 359 pair of IP addresses, which are the ones used in the base exchange. 361 The readdressing protocol is an asymmetric protocol where a mobile 362 host informs a peer host about changes of IP addresses on affected 363 SPIs. The readdressing exchange is designed to be piggybacked on 364 existing HIP exchanges. In support of mobility, the LOCATOR_SET 365 parameter is carried in UPDATE packets. 367 The scenarios below at times describe addresses as being in either an 368 ACTIVE, UNVERIFIED, or DEPRECATED state. From the perspective of a 369 host, newly-learned addresses of the peer must be verified before put 370 into active service, and addresses removed by the peer are put into a 371 deprecated state. Under limited conditions described below 372 (Section 5.6), an UNVERIFIED address may be used. The addressing 373 states are defined more formally in Section 5.1. 375 Hosts that use link-local addresses as source addresses in their HIP 376 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 377 provide a globally routable address either in the initial handshake 378 or via the LOCATOR_SET parameter. 380 3.2.1. Mobility with a Single SA Pair (No Rekeying) 382 A mobile host must sometimes change an IP address bound to an 383 interface. The change of an IP address might be needed due to a 384 change in the advertised IPv6 prefixes on the link, a reconnected PPP 385 link, a new DHCP lease, or an actual movement to another subnet. In 386 order to maintain its communication context, the host must inform its 387 peers about the new IP address. This first example considers the 388 case in which the mobile host has only one interface, one IP address 389 in use within the HIP session, a single pair of SAs (one inbound, one 390 outbound), and no rekeying occurs on the SAs. We also assume that 391 the new IP addresses are within the same address family (IPv4 or 392 IPv6) as the previous address. This is the simplest scenario, 393 depicted in Figure 3. 395 Mobile Host Peer Host 397 UPDATE(ESP_INFO, LOCATOR_SET, SEQ) 398 -----------------------------------> 399 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 400 <----------------------------------- 401 UPDATE(ACK, ECHO_RESPONSE) 402 -----------------------------------> 404 Figure 3: Readdress without Rekeying, but with Address Check 406 The steps of the packet processing are as follows: 408 1. The mobile host may be disconnected from the peer host for a 409 brief period of time while it switches from one IP address to 410 another; this case is sometimes referred to in the literature as 411 a "break-before-make" case. The host may also obtain its new IP 412 address before loosing the old one ("make-before-break" case). 413 In either case, upon obtaining a new IP address, the mobile host 414 sends a LOCATOR_SET parameter to the peer host in an UPDATE 415 message. The UPDATE message also contains an ESP_INFO parameter 416 containing the values of the old and new SPIs for a security 417 association. In this case, the OLD SPI and NEW SPI parameters 418 both are set to the value of the preexisting incoming SPI; this 419 ESP_INFO does not trigger a rekeying event but is instead 420 included for possible parameter-inspecting middleboxes on the 421 path. The LOCATOR_SET parameter contains the new IP address 422 (Locator Type of "1", defined below) and a locator lifetime. The 423 mobile host waits for this UPDATE to be acknowledged, and 424 retransmits if necessary, as specified in the base specification 425 [RFC7401]. 427 2. The peer host receives the UPDATE, validates it, and updates any 428 local bindings between the HIP association and the mobile host's 429 destination address. The peer host MUST perform an address 430 verification by placing a nonce in the ECHO_REQUEST parameter of 431 the UPDATE message sent back to the mobile host. It also 432 includes an ESP_INFO parameter with the OLD SPI and NEW SPI 433 parameters both set to the value of the preexisting incoming SPI, 434 and sends this UPDATE (with piggybacked acknowledgment) to the 435 mobile host at its new address. The peer MAY use the new address 436 immediately, but it MUST limit the amount of data it sends to the 437 address until address verification completes. 439 3. The mobile host completes the readdress by processing the UPDATE 440 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 441 host receives this ECHO_RESPONSE, it considers the new address to 442 be verified and can put the address into full use. 444 While the peer host is verifying the new address, the new address is 445 marked as UNVERIFIED in the interim, and the old address is 446 DEPRECATED. Once the peer host has received a correct reply to its 447 UPDATE challenge, it marks the new address as ACTIVE and removes the 448 old address. 450 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) 452 The mobile host may decide to rekey the SAs at the same time that it 453 notifies the peer of the new address. In this case, the above 454 procedure described in Figure 3 is slightly modified. The UPDATE 455 message sent from the mobile host includes an ESP_INFO with the OLD 456 SPI set to the previous SPI, the NEW SPI set to the desired new SPI 457 value for the incoming SA, and the KEYMAT Index desired. Optionally, 458 the host may include a DIFFIE_HELLMAN parameter for a new Diffie- 459 Hellman key. The peer completes the request for a rekey as is 460 normally done for HIP rekeying, except that the new address is kept 461 as UNVERIFIED until the UPDATE nonce challenge is received as 462 described above. Figure 4 illustrates this scenario. 464 Mobile Host Peer Host 466 UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) 467 -----------------------------------> 468 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 469 <----------------------------------- 470 UPDATE(ACK, ECHO_RESPONSE) 471 -----------------------------------> 473 Figure 4: Readdress with Mobile-Initiated Rekey 475 3.2.3. Mobility messaging through rendezvous server 477 Section 6.11 of [RFC7401] specifies procedures for sending HIP UPDATE 478 packets. The UPDATE packets are protected by a timer subject to 479 exponential backoff and resent UPDATE_RETRY_MAX times. It may be, 480 however, that the peer is itself in the process of moving when the 481 local host is trying to update the IP address bindings of the HIP 482 association. This is sometimes called the "double-jump" mobility 483 problem; each host's UPDATE packets are simultaneously sent to a 484 stale address of the peer, and the hosts are no longer reachable from 485 one another. 487 The HIP Rendezvous Extension [I-D.ietf-hip-rfc5204-bis] specifies a 488 rendezvous service that permits the I1 packet from the base exchange 489 to be relayed from a stable or well-known public IP address location 490 to the current IP address of the host. It is possible to support 491 double-jump mobility with this rendezvous service if the following 492 extensions to the specifications of [I-D.ietf-hip-rfc5204-bis] and 493 [RFC7401] are followed. 495 1. The mobile host sending an UPDATE to the peer, and not receiving 496 an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the 497 peer, if such a server is known. The host may try the RVS of the 498 peer up to UPDATE_RETRY_MAX times as specified in [RFC7401]. The 499 host may try to use the peer's RVS before it has tried 500 UPDATE_RETRY_MAX times to the last working address (i.e. the RVS 501 may be tried in parallel with retries to the last working 502 address). 504 2. A rendezvous server supporting the UPDATE forwarding extensions 505 specified herein MUST modify the UPDATE in the same manner as it 506 modifies the I1 packet before forwarding. Specifically, it MUST 507 rewrite the IP header source and destination addresses, recompute 508 the IP header checksum, and include the FROM and RVS_HMAC 509 parameters. 511 3. A host receiving an UPDATE packet MUST be prepared to process the 512 FROM and RVS_HMAC parameters, and MUST include a VIA_RVS 513 parameter in the UPDATE reply that contains the ACK of the UPDATE 514 SEQ. 516 4. An initiator receiving a VIA_RVS in the UPDATE reply should 517 initiate address reachability tests (described later in this 518 document) towards the end host's address and not towards the 519 address included in the VIA_RVS. 521 This scenario requires that hosts using rendezvous servers also take 522 steps to update their current address bindings with their rendezvous 523 server upon a mobility event. [I-D.ietf-hip-rfc5204-bis] does not 524 specify how to update the rendezvous server with a client host's new 525 address. [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host 526 may send a REG_REQUEST in either an I2 packet (if there is no active 527 association) or an UPDATE packet (if such association exists). 528 According to procedures described in [I-D.ietf-hip-rfc5203-bis], if a 529 mobile host has an active registration, it may use mobility updates 530 specified herein, within the context of that association, to 531 readdress the association. 533 3.2.4. Network Renumbering 535 It is expected that IPv6 networks will be renumbered much more often 536 than most IPv4 networks. From an end-host point of view, network 537 renumbering is similar to mobility, and procedures described herein 538 also apply to notify a peer of a changed address. 540 3.3. Other Considerations 542 3.3.1. Address Verification 544 When a HIP host receives a set of locators from another HIP host in a 545 LOCATOR_SET, it does not necessarily know whether the other host is 546 actually reachable at the claimed addresses. In fact, a malicious 547 peer host may be intentionally giving bogus addresses in order to 548 cause a packet flood towards the target addresses [RFC4225]. 549 Therefore, the HIP host must first check that the peer is reachable 550 at the new address. 552 Address verification is implemented by the challenger sending some 553 piece of unguessable information to the new address, and waiting for 554 some acknowledgment from the Responder that indicates reception of 555 the information at the new address. This may include the exchange of 556 a nonce, or the generation of a new SPI and observation of data 557 arriving on the new SPI. 559 An additional potential benefit of performing address verification is 560 to allow middleboxes in the network along the new path to obtain the 561 peer host's inbound SPI. 563 3.3.2. Credit-Based Authorization 565 Credit-Based Authorization (CBA) allows a host to securely use a new 566 locator even though the peer's reachability at the address embedded 567 in the locator has not yet been verified. This is accomplished based 568 on the following three hypotheses: 570 1. A flooding attacker typically seeks to somehow multiply the 571 packets it generates for the purpose of its attack because 572 bandwidth is an ample resource for many victims. 574 2. An attacker can often cause unamplified flooding by sending 575 packets to its victim, either by directly addressing the victim 576 in the packets, or by guiding the packets along a specific path 577 by means of an IPv6 Routing header, if Routing headers are not 578 filtered by firewalls. 580 3. Consequently, the additional effort required to set up a 581 redirection-based flooding attack (without CBA and return 582 routability checks) would pay off for the attacker only if 583 amplification could be obtained this way. 585 On this basis, rather than eliminating malicious packet redirection 586 in the first place, Credit-Based Authorization prevents 587 amplifications. This is accomplished by limiting the data a host can 588 send to an unverified address of a peer by the data recently received 589 from that peer. Redirection-based flooding attacks thus become less 590 attractive than, for example, pure direct flooding, where the 591 attacker itself sends bogus packets to the victim. 593 Figure 5 illustrates Credit-Based Authorization: Host B measures the 594 amount of data recently received from peer A and, when A readdresses, 595 sends packets to A's new, unverified address as long as the sum of 596 the packet sizes does not exceed the measured, received data volume. 597 When insufficient credit is left, B stops sending further packets to 598 A until A's address becomes ACTIVE. The address changes may be due 599 to mobility, multihoming, or any other reason. Not shown in Figure 5 600 are the results of credit aging (Section 5.6.2), a mechanism used to 601 dampen possible time-shifting attacks. 603 +-------+ +-------+ 604 | A | | B | 605 +-------+ +-------+ 606 | | 607 address |------------------------------->| credit += size(packet) 608 ACTIVE | | 609 |------------------------------->| credit += size(packet) 610 |<-------------------------------| do not change credit 611 | | 612 + address change | 613 + address verification starts | 614 address |<-------------------------------| credit -= size(packet) 615 UNVERIFIED |------------------------------->| credit += size(packet) 616 |<-------------------------------| credit -= size(packet) 617 | | 618 |<-------------------------------| credit -= size(packet) 619 | X credit < size(packet) 620 | | => do not send packet! 621 + address verification concludes | 622 address | | 623 ACTIVE |<-------------------------------| do not change credit 624 | | 626 Figure 5: Readdressing Scenario 628 3.3.3. Preferred Locator 630 When a host has multiple locators, the peer host must decide which to 631 use for outbound packets. It may be that a host would prefer to 632 receive data on a particular inbound interface. HIP allows a 633 particular locator to be designated as a Preferred locator and 634 communicated to the peer (see Section 4). 636 4. LOCATOR_SET Parameter Format 638 The LOCATOR_SET parameter is a critical parameter as defined by 639 [RFC7401]. It consists of the standard HIP parameter Type and Length 640 fields, plus zero or more Locator sub-parameters. Each Locator sub- 641 parameter contains a Traffic Type, Locator Type, Locator Length, 642 Preferred locator bit, Locator Lifetime, and a Locator encoding. A 643 LOCATOR_SET containing zero Locator fields is permitted but has the 644 effect of deprecating all addresses. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type | Length | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Traffic Type | Locator Type | Locator Length | Reserved |P| 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Locator Lifetime | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Locator | 656 | | 657 | | 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 . . 661 . . 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Traffic Type | Locator Type | Locator Length | Reserved |P| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Locator Lifetime | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Locator | 668 | | 669 | | 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Figure 6: LOCATOR_SET Parameter Format 675 Type: 193 677 Length: Length in octets, excluding Type and Length fields, and 678 excluding padding. 680 Traffic Type: Defines whether the locator pertains to HIP signaling, 681 user data, or both. 683 Locator Type: Defines the semantics of the Locator field. 685 Locator Length: Defines the length of the Locator field, in units of 686 4-byte words (Locators up to a maximum of 4*255 octets are 687 supported). 689 Reserved: Zero when sent, ignored when received. 691 P: Preferred locator. Set to one if the locator is preferred for 692 that Traffic Type; otherwise, set to zero. 694 Locator Lifetime: Locator lifetime, in seconds. 696 Locator: The locator whose semantics and encoding are indicated by 697 the Locator Type field. All Locator sub-fields are integral 698 multiples of four octets in length. 700 The Locator Lifetime indicates how long the following locator is 701 expected to be valid. The lifetime is expressed in seconds. Each 702 locator MUST have a non-zero lifetime. The address is expected to 703 become deprecated when the specified number of seconds has passed 704 since the reception of the message. A deprecated address SHOULD NOT 705 be used as a destination address if an alternate (non-deprecated) is 706 available and has sufficient scope. 708 4.1. Traffic Type and Preferred Locator 710 The following Traffic Type values are defined: 712 0: Both signaling (HIP control packets) and user data. 714 1: Signaling packets only. 716 2: Data packets only. 718 The "P" bit, when set, has scope over the corresponding Traffic Type. 719 That is, when a "P" bit is set for Traffic Type "2", for example, it 720 means that the locator is preferred for data packets. If there is a 721 conflict (for example, if the "P" bit is set for an address of Type 722 "0" and a different address of Type "2"), the more specific Traffic 723 Type rule applies (in this case, "2"). By default, the IP addresses 724 used in the base exchange are Preferred locators for both signaling 725 and user data, unless a new Preferred locator supersedes them. If no 726 locators are indicated as preferred for a given Traffic Type, the 727 implementation may use an arbitrary destination locator from the set 728 of active locators. 730 4.2. Locator Type and Locator 732 The following Locator Type values are defined, along with the 733 associated semantics of the Locator field: 735 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] 736 (128 bits long). This locator type is defined primarily for non- 737 ESP-based usage. 739 1: The concatenation of an ESP SPI (first 32 bits) followed by an 740 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 741 128 bits). This IP address is defined primarily for ESP-based 742 usage. 744 4.3. UPDATE Packet with Included LOCATOR_SET 746 A number of combinations of parameters in an UPDATE packet are 747 possible (e.g., see Section 3.2). In this document, procedures are 748 defined only for the case in which one LOCATOR_SET and one ESP_INFO 749 parameter is used in any HIP packet. Any UPDATE packet that includes 750 a LOCATOR_SET parameter SHOULD include both an HMAC and a 751 HIP_SIGNATURE parameter. 753 The UPDATE MAY also include a HOST_ID parameter (which may be useful 754 for middleboxes inspecting the HIP messages for the first time). If 755 the UPDATE includes the HOST_ID parameter, the receiving host MUST 756 verify that the HOST_ID corresponds to the HOST_ID that was used to 757 establish the HIP association, and the HIP_SIGNATURE must verify with 758 the public key associated with this HOST_ID parameter. 760 The relationship between the announced Locators and any ESP_INFO 761 parameters present in the packet is defined in Section 5.2. This 762 document does not support any elements of procedure for sending more 763 than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. 765 5. Processing Rules 767 This section describes rules for sending and receiving the 768 LOCATOR_SET parameter, testing address reachability, and using 769 Credit-Based Authorization (CBA) on UNVERIFIED locators. 771 5.1. Locator Data Structure and Status 773 In a typical implementation, each locator announced in a LOCATOR_SET 774 parameter is represented by a piece of state that contains the 775 following data: 777 o the actual bit pattern representing the locator, 779 o the lifetime (seconds), 781 o the status (UNVERIFIED, ACTIVE, DEPRECATED), 783 o the Traffic Type scope of the locator, and 785 o whether the locator is preferred for any particular scope. 787 The status is used to track the reachability of the address embedded 788 within the LOCATOR_SET parameter: 790 UNVERIFIED indicates that the reachability of the address has not 791 been verified yet, 793 ACTIVE indicates that the reachability of the address has been 794 verified and the address has not been deprecated, 796 DEPRECATED indicates that the locator lifetime has expired. 798 The following state changes are allowed: 800 UNVERIFIED to ACTIVE The reachability procedure completes 801 successfully. 803 UNVERIFIED to DEPRECATED The locator lifetime expires while the 804 locator is UNVERIFIED. 806 ACTIVE to DEPRECATED The locator lifetime expires while the locator 807 is ACTIVE. 809 ACTIVE to UNVERIFIED There has been no traffic on the address for 810 some time, and the local policy mandates that the address 811 reachability must be verified again before starting to use it 812 again. 814 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 815 locator. 817 A DEPRECATED address MUST NOT be changed to ACTIVE without first 818 verifying its reachability. 820 Note that the state of whether or not a locator is preferred is not 821 necessarily the same as the value of the Preferred bit in the Locator 822 sub-parameter received from the peer. Peers may recommend certain 823 locators to be preferred, but the decision on whether to actually use 824 a locator as a preferred locator is a local decision, possibly 825 influenced by local policy. 827 In addition to state maintained about status and remaining lifetime 828 for each locator learned from the peer, an implementation would 829 typically maintain similar state about its own locators that have 830 been offered to the peer. 832 Finally, the locators used to establish the HIP association are by 833 default assumed to be the initial preferred locators in ACTIVE state, 834 with an unbounded lifetime. 836 5.2. Sending LOCATOR_SETs 838 The decision of when to send LOCATOR_SETs is basically a local policy 839 issue. However, it is RECOMMENDED that a host send a LOCATOR_SET 840 whenever it recognizes a change of its IP addresses in use on an 841 active HIP association, and assumes that the change is going to last 842 at least for a few seconds. Rapidly sending LOCATOR_SETs that force 843 the peer to change the preferred address SHOULD be avoided. 845 We now describe a few cases introduced in Section 3.2. We assume 846 that the Traffic Type for each locator is set to "0" (other values 847 for Traffic Type may be specified in documents that separate the HIP 848 control plane from data plane traffic). Other mobility cases are 849 possible but are left for further study. 851 1. Host mobility with no multihoming and no rekeying. The mobile 852 host creates a single UPDATE containing a single ESP_INFO with a 853 single LOCATOR_SET parameter. The ESP_INFO contains the current 854 value of the SPI in both the OLD SPI and NEW SPI fields. The 855 LOCATOR_SET contains a single Locator with a "Locator Type" of 856 "1"; the SPI must match that of the ESP_INFO. The Preferred bit 857 SHOULD be set and the "Locator Lifetime" is set according to 858 local policy. The UPDATE also contains a SEQ parameter as usual. 859 This packet is retransmitted as defined in the HIP protocol 860 specification [RFC7401]. The UPDATE should be sent to the peer's 861 preferred IP address with an IP source address corresponding to 862 the address in the LOCATOR_SET parameter. 864 2. Host mobility with no multihoming but with rekeying. The mobile 865 host creates a single UPDATE containing a single ESP_INFO with a 866 single LOCATOR_SET parameter (with a single address). The 867 ESP_INFO contains the current value of the SPI in the OLD SPI and 868 the new value of the SPI in the NEW SPI, and a KEYMAT Index as 869 selected by local policy. Optionally, the host may choose to 870 initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN 871 parameter. The LOCATOR_SET contains a single Locator with 872 "Locator Type" of "1"; the SPI must match that of the NEW SPI in 873 the ESP_INFO. Otherwise, the steps are identical to the case in 874 which no rekeying is initiated. 876 5.3. Handling Received LOCATOR_SETs 878 A host SHOULD be prepared to receive a single LOCATOR_SET parameter 879 in a HIP UPDATE packet. Reception of multiple LOCATOR_SET parameters 880 in a single packet, or in HIP packets other than UPDATE, is outside 881 of the scope of this specification. 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 listing 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. A host MAY choose from different message 990 exchanges or different nonce values so long as it establishes that 991 the peer has received and replied to the nonce at the new address. 992 For example, when the host is changing its SPI and sending an 993 ESP_INFO to the peer, the NEW SPI value SHOULD be random and the 994 random value MAY be copied into an ECHO_REQUEST sent in the rekeying 995 UPDATE. However, if the host is not changing its SPI, it MAY still 996 use the ECHO_REQUEST parameter for verification but with some other 997 random value. A host MAY also use other message exchanges as 998 confirmation of the address reachability. 1000 In some cases, it MAY be sufficient to use the arrival of data on a 1001 newly advertised SA as implicit address reachability verification as 1002 depicted in Figure 7, instead of waiting for the confirmation via a 1003 HIP packet. In this case, a host advertising a new SPI as part of 1004 its address reachability check SHOULD be prepared to receive traffic 1005 on the new SA. 1007 Mobile host Peer host 1009 prepare incoming SA 1010 NEW SPI in ESP_INFO (UPDATE) 1011 <----------------------------------- 1012 switch to new outgoing SA 1013 data on new SA 1014 -----------------------------------> 1015 mark address ACTIVE 1017 Figure 7: Address Activation Via Use of a New SA 1019 When address verification is in progress for a new Preferred locator, 1020 the host SHOULD select a different locator listed as ACTIVE, if one 1021 such locator is available, to continue communications until address 1022 verification completes. Alternatively, the host MAY use the new 1023 Preferred locator while in UNVERIFIED status to the extent Credit- 1024 Based Authorization permits. Credit-Based Authorization is explained 1025 in Section 5.6. Once address verification succeeds, the status of 1026 the new Preferred locator changes to ACTIVE. 1028 5.5. Changing the Preferred Locator 1030 A host MAY want to change the Preferred outgoing locator for 1031 different reasons, e.g., because traffic information or ICMP error 1032 messages indicate that the currently used preferred address may have 1033 become unreachable. Another reason may be due to receiving a 1034 LOCATOR_SET parameter that has the "P" bit set. 1036 To change the Preferred locator, the host initiates the following 1037 procedure: 1039 1. If the new Preferred locator has ACTIVE status, the Preferred 1040 locator is changed and the procedure succeeds. 1042 2. If the new Preferred locator has UNVERIFIED status, the host 1043 starts to verify its reachability. The host SHOULD use a 1044 different locator listed as ACTIVE until address verification 1045 completes if one such locator is available. Alternatively, the 1046 host MAY use the new Preferred locator, even though in UNVERIFIED 1047 status, to the extent Credit-Based Authorization permits. Once 1048 address verification succeeds, the status of the new Preferred 1049 locator changes to ACTIVE and its use is no longer governed by 1050 Credit-Based Authorization. 1052 3. If the peer host has not indicated a preference for any address, 1053 then the host picks one of the peer's ACTIVE addresses randomly 1054 or according to local policy. This case may arise if, for 1055 example, ICMP error messages that deprecate the Preferred locator 1056 arrive, but the peer has not yet indicated a new Preferred 1057 locator. 1059 4. If the new Preferred locator has DEPRECATED status and there is 1060 at least one non-deprecated address, the host selects one of the 1061 non-deprecated addresses as a new Preferred locator and 1062 continues. If the selected address is UNVERIFIED, the address 1063 verification procedure described above will apply. 1065 5.6. Credit-Based Authorization 1067 To prevent redirection-based flooding attacks, the use of a Credit- 1068 Based Authorization (CBA) approach MUST be used when a host sends 1069 data to an UNVERIFIED locator. The following algorithm meets the 1070 security considerations for prevention of amplification and time- 1071 shifting attacks. Other forms of credit aging, and other values for 1072 the CreditAgingFactor and CreditAgingInterval parameters in 1073 particular, are for further study, and so are the advanced CBA 1074 techniques specified in [CBA-MIPv6]. 1076 5.6.1. Handling Payload Packets 1078 A host maintains a "credit counter" for each of its peers. Whenever 1079 a packet arrives from a peer, the host SHOULD increase that peer's 1080 credit counter by the size of the received packet. When the host has 1081 a packet to be sent to the peer, and when the peer's Preferred 1082 locator is listed as UNVERIFIED and no alternative locator with 1083 status ACTIVE is available, the host checks whether it can send the 1084 packet to the UNVERIFIED locator. The packet SHOULD be sent if the 1085 value of the credit counter is higher than the size of the outbound 1086 packet. If the credit counter is too low, the packet MUST be 1087 discarded or buffered until address verification succeeds. When a 1088 packet is sent to a peer at an UNVERIFIED locator, the peer's credit 1089 counter MUST be reduced by the size of the packet. The peer's credit 1090 counter is not affected by packets that the host sends to an ACTIVE 1091 locator of that peer. 1093 Figure 8 depicts the actions taken by the host when a packet is 1094 received. Figure 9 shows the decision chain in the event a packet is 1095 sent. 1097 Inbound 1098 packet 1099 | 1100 | +----------------+ +---------------+ 1101 | | Increase | | Deliver | 1102 +-----> | credit counter |-------------> | packet to | 1103 | by packet size | | application | 1104 +----------------+ +---------------+ 1106 Figure 8: Receiving Packets with Credit-Based Authorization 1108 Outbound 1109 packet 1110 | _________________ 1111 | / \ +---------------+ 1112 | / Is the preferred \ No | Send packet | 1113 +-----> | destination address |-------------> | to preferred | 1114 \ UNVERIFIED? / | address | 1115 \_________________/ +---------------+ 1116 | 1117 | Yes 1118 | 1119 v 1120 _________________ 1121 / \ +---------------+ 1122 / Does an ACTIVE \ Yes | Send packet | 1123 | destination address |-------------> | to ACTIVE | 1124 \ exist? / | address | 1125 \_________________/ +---------------+ 1126 | 1127 | No 1128 | 1129 v 1130 _________________ 1131 / \ +---------------+ 1132 / Credit counter \ No | | 1133 | >= |-------------> | Drop or | 1134 \ packet size? / | buffer packet | 1135 \_________________/ +---------------+ 1136 | 1137 | Yes 1138 | 1139 v 1140 +---------------+ +---------------+ 1141 | Reduce credit | | Send packet | 1142 | counter by |----------------> | to preferred | 1143 | packet size | | address | 1144 +---------------+ +---------------+ 1146 Figure 9: Sending Packets with Credit-Based Authorization 1148 5.6.2. Credit Aging 1150 A host ensures that the credit counters it maintains for its peers 1151 gradually decrease over time. Such "credit aging" prevents a 1152 malicious peer from building up credit at a very slow speed and using 1153 this, all at once, for a severe burst of redirected packets. 1155 Credit aging may be implemented by multiplying credit counters with a 1156 factor, CreditAgingFactor (a fractional value less than one), in 1157 fixed time intervals of CreditAgingInterval length. Choosing 1158 appropriate values for CreditAgingFactor and CreditAgingInterval is 1159 important to ensure that a host can send packets to an address in 1160 state UNVERIFIED even when the peer sends at a lower rate than the 1161 host itself. When CreditAgingFactor or CreditAgingInterval are too 1162 small, the peer's credit counter might be too low to continue sending 1163 packets until address verification concludes. 1165 The parameter values proposed in this document are as follows: 1167 CreditAgingFactor 7/8 1168 CreditAgingInterval 5 seconds 1170 These parameter values work well when the host transfers a file to 1171 the peer via a TCP connection and the end-to-end round-trip time does 1172 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1173 use other parameter values or different parameters, which may even be 1174 dynamically established. 1176 6. Security Considerations 1178 The HIP mobility mechanism provides a secure means of updating a 1179 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1180 cryptographically verifies the sender of an UPDATE, so forging or 1181 replaying a HIP UPDATE packet is very difficult (see [RFC7401]). 1182 Therefore, security issues reside in other attack domains. The two 1183 we consider are malicious redirection of legitimate connections as 1184 well as redirection-based flooding attacks using this protocol. This 1185 can be broken down into the following: 1187 Impersonation attacks 1189 - direct conversation with the misled victim 1191 - man-in-the-middle attack 1193 DoS attacks 1195 - flooding attacks (== bandwidth-exhaustion attacks) 1197 * tool 1: direct flooding 1199 * tool 2: flooding by botnets 1201 * tool 3: redirection-based flooding 1203 - memory-exhaustion attacks 1205 - computational-exhaustion attacks 1207 We consider these in more detail in the following sections. 1209 In Section 6.1 and Section 6.2, we assume that all users are using 1210 HIP. In Section 6.3 we consider the security ramifications when we 1211 have both HIP and non-HIP hosts. 1213 6.1. Impersonation Attacks 1215 An attacker wishing to impersonate another host will try to mislead 1216 its victim into directly communicating with them, or carry out a man- 1217 in-the-middle (MitM) attack between the victim and the victim's 1218 desired communication peer. Without mobility support, such attacks 1219 are possible only if the attacker resides on the routing path between 1220 its victim and the victim's desired communication peer, or if the 1221 attacker tricks its victim into initiating the connection over an 1222 incorrect routing path (e.g., by acting as a router or using spoofed 1223 DNS entries). 1225 The HIP extensions defined in this specification change the situation 1226 in that they introduce an ability to redirect a connection, both 1227 before and after establishment. If no precautionary measures are 1228 taken, an attacker could potentially misuse the redirection feature 1229 to impersonate a victim's peer from any arbitrary location. However, 1230 the authentication and authorization mechanisms of the HIP base 1231 exchange [RFC7401] and the signatures in the UPDATE message prevent 1232 this attack. Furthermore, ownership of a HIP association is securely 1233 linked to a HIP HI/HIT. If an attacker somehow uses a bug in the 1234 implementation to redirect a HIP connection, the original owner can 1235 always reclaim their connection (they can always prove ownership of 1236 the private key associated with their public HI). 1238 MitM attacks are possible if an on-path attacker is present during 1239 the initial HIP base exchange and if the hosts do not authenticate 1240 each other's identities. However, once such an opportunistic base 1241 exchange has taken place, a MitM attacker that comes later to the 1242 path cannot steal the HIP connection because it is very difficult for 1243 an attacker to create an UPDATE packet (or any HIP packet) that will 1244 be accepted as a legitimate update. UPDATE packets use HMAC and are 1245 signed. Even when an attacker can snoop packets to obtain the SPI 1246 and HIT/HI, they still cannot forge an UPDATE packet without 1247 knowledge of the secret keys. Also, replay attacks on the UPDATE 1248 packet are prevented as described in [RFC7401]. 1250 6.2. Denial-of-Service Attacks 1252 6.2.1. Flooding Attacks 1254 The purpose of a denial-of-service attack is to exhaust some resource 1255 of the victim such that the victim ceases to operate correctly. A 1256 denial-of-service attack can aim at the victim's network attachment 1257 (flooding attack), its memory, or its processing capacity. In a 1258 flooding attack, the attacker causes an excessive number of bogus or 1259 unwanted packets to be sent to the victim, which fills their 1260 available bandwidth. Note that the victim does not necessarily need 1261 to be a node; it can also be an entire network. The attack basically 1262 functions the same way in either case. 1264 An effective DoS strategy is distributed denial of service (DDoS). 1265 Here, the attacker conventionally distributes some viral software to 1266 as many nodes as possible. Under the control of the attacker, the 1267 infected nodes (e.g. nodes in a botnet), jointly send packets to the 1268 victim. With such an 'army', an attacker can take down even very 1269 high bandwidth networks/victims. 1271 With the ability to redirect connections, an attacker could realize a 1272 DDoS attack without having to distribute viral code. Here, the 1273 attacker initiates a large download from a server, and subsequently 1274 uses the HIP mobility mechanism to redirect this download to its 1275 victim. The attacker can repeat this with multiple servers. This 1276 threat is mitigated through reachability checks and credit-based 1277 authorization. Reachability checks, which when conducted using HIP 1278 can leverage the built-in authentication properties of HIP, can 1279 prevent redirection-based flooding attacks. However, the delay of 1280 such a check can have a noticeable impact on application performance. 1281 To reduce the impact of the delay, credit-based authorization can be 1282 used to send a limited number of packets to the new address while the 1283 validity of the IP address is still in question. Both strategies do 1284 not eliminate flooding attacks per se, but they preclude: (i) their 1285 use from a location off the path towards the flooded victim; and (ii) 1286 any amplification in the number and size of the redirected packets. 1287 As a result, the combination of a reachability check and credit-based 1288 authorization lowers a HIP redirection-based flooding attack to the 1289 level of a direct flooding attack in which the attacker itself sends 1290 the flooding traffic to the victim. 1292 6.2.2. Memory/Computational-Exhaustion DoS Attacks 1294 We now consider whether or not the proposed extensions to HIP add any 1295 new DoS attacks (consideration of DoS attacks using the base HIP 1296 exchange and updates is discussed in [RFC7401]). A simple attack is 1297 to send many UPDATE packets containing many IP addresses that are not 1298 flagged as preferred. The attacker continues to send such packets 1299 until the number of IP addresses associated with the attacker's HI 1300 crashes the system. Therefore, a HIP association SHOULD limit the 1301 number of IP addresses that can be associated with any HI. Other 1302 forms of memory/computationally exhausting attacks via the HIP UPDATE 1303 packet are handled in the base HIP document [RFC7401]. 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 solution 1337 is to prevent the local redirection of sessions that were 1338 previously using an unverified address, but outside of the 1339 existing HIP context, into the HIP SAs until the address change 1340 can be verified. 1342 7. IANA Considerations 1344 RFC5206, obsoleted by this document, specified an allocation for a 1345 LOCATOR parameter in the HIP Parameters registry. This document 1346 requests IANA to rename the parameter to 'LOCATOR_SET' and to update 1347 the reference from RFC5206 to this specification. 1349 RFC5206, obsoleted by this document, specified an allocation a 1350 LOCATOR_TYPE_UNSUPPORTED type in the Notify Message Type registry. 1351 This document requests IANA to update the reference from RFC5206 to 1352 this specification. 1354 8. Authors and Acknowledgments 1356 Pekka Nikander and Jari Arkko originated this document, and Christian 1357 Vogt and Thomas Henderson (editor) later joined as co-authors. Greg 1358 Perkins contributed the initial draft of the security section. Petri 1359 Jokela was a co-author of the initial individual submission. 1361 Credit-Based Authorization was originally introduced in [SIMPLE-CBA], 1362 and portions of this document have been adopted from that earlier 1363 draft. 1365 The authors thank Jeff Ahrenholz, Baris Boyvat, Rene Hummen, Miika 1366 Komu, Mika Kousa, Jan Melen, and Samu Varjonen for improvements to 1367 the document. 1369 9. References 1371 9.1. Normative references 1373 [I-D.ietf-hip-rfc5203-bis] 1374 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1375 Registration Extension", draft-ietf-hip-rfc5203-bis-11 1376 (work in progress), August 2016. 1378 [I-D.ietf-hip-rfc5204-bis] 1379 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1380 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-08 (work 1381 in progress), August 2016. 1383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1384 Requirement Levels", BCP 14, RFC 2119, 1385 DOI 10.17487/RFC2119, March 1997, 1386 . 1388 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1389 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1390 2006, . 1392 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1393 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1394 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1395 . 1397 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 1398 Encapsulating Security Payload (ESP) Transport Format with 1399 the Host Identity Protocol (HIP)", RFC 7402, 1400 DOI 10.17487/RFC7402, April 2015, 1401 . 1403 9.2. Informative references 1405 [CBA-MIPv6] 1406 Vogt, C. and J. Arkko, "Credit-Based Authorization for 1407 Mobile IPv6 Early Binding Updates", February 2005. 1409 [I-D.ietf-hip-multihoming] 1410 Henderson, T., Vogt, C., and J. Arkko, "Host Multihoming 1411 with the Host Identity Protocol", draft-ietf-hip- 1412 multihoming-10 (work in progress), July 2016. 1414 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1415 Nordmark, "Mobile IP Version 6 Route Optimization Security 1416 Design Background", RFC 4225, DOI 10.17487/RFC4225, 1417 December 2005, . 1419 [SIMPLE-CBA] 1420 Vogt, C. and J. Arkko, "Credit-Based Authorization for 1421 Concurrent Reachability Verification", February 2006. 1423 Appendix A. Document Revision History 1425 To be removed upon publication 1427 +----------+--------------------------------------------------------+ 1428 | Revision | Comments | 1429 +----------+--------------------------------------------------------+ 1430 | draft-00 | Initial version from RFC5206 xml (unchanged). | 1431 | | | 1432 | draft-01 | Remove multihoming-specific text; no other changes. | 1433 | | | 1434 | draft-02 | Update references to point to -bis drafts; no other | 1435 | | changes. | 1436 | | | 1437 | draft-03 | issue 4: add make before break use case | 1438 | | | 1439 | | issue 6: peer locator exposure policies | 1440 | | | 1441 | | issue 10: rename LOCATOR to LOCATOR_SET | 1442 | | | 1443 | | issue 14: use of UPDATE packet's IP address | 1444 | | | 1445 | draft-04 | Document refresh; no other changes. | 1446 | | | 1447 | draft-05 | Document refresh; no other changes. | 1448 | | | 1449 | draft-06 | Document refresh; no other changes. | 1450 | | | 1451 | draft-07 | Document refresh; IANA considerations updated. | 1452 | | | 1453 | draft-08 | Remove sending LOCATOR_SET in R1, I2, and NOTIFY | 1454 | | (multihoming) | 1455 | | | 1456 | | State that only one LOCATOR_SET parameter may be sent | 1457 | | in an UPDATE packet (according to this draft) | 1458 | | (multihoming) | 1459 | | | 1460 | | Remove text about cross-family handovers (multihoming) | 1461 | | | 1462 | draft-09 | Add specification text regarding double-jump mobility | 1463 | | procedures. | 1464 | | | 1465 | draft-10 | issue 21: clarified that HI MAY be included in UPDATE | 1466 | | for benefit of middleboxes | 1467 | | | 1468 | | changed one informative reference from RFC 4423-bis to | 1469 | | RFC 7401 | 1470 | | | 1471 | | removed discussion about possible multiple LOCATOR_SET | 1472 | | and ESP_INFO parameters in an UPDATE (per previous | 1473 | | mailing list discussion) | 1474 | | | 1475 | | removed discussion about handling LOCATOR_SET | 1476 | | parameters in packets other than UPDATE (per previous | 1477 | | mailing list discussion) | 1478 | | | 1479 | draft-11 | Editorial improvements from WGLC | 1480 | | | 1481 | draft-12 | Update author affiliations and IPR boilerplate to | 1482 | | trust200902 | 1483 | | | 1484 | draft-13 | Editorial improvements to IANA considerations section. | 1485 | | | 1486 | | Moved citation of [SIMPLE-CBA] to Section 8 and | 1487 | | slightly updated text for redirection-based flooding | 1488 | | attacks in the Security Considerations section. | 1489 | | | 1490 | | Editorial improvements based on last call comments. | 1491 +----------+--------------------------------------------------------+ 1493 Authors' Addresses 1495 Thomas R. Henderson (editor) 1496 University of Washington 1497 Campus Box 352500 1498 Seattle, WA 1499 USA 1501 EMail: tomhend@u.washington.edu 1503 Christian Vogt 1504 Independent 1505 3473 North First Street 1506 San Jose, CA 95134 1507 USA 1509 EMail: mail@christianvogt.net 1510 Jari Arkko 1511 Ericsson 1512 JORVAS FIN-02420 1513 FINLAND 1515 Phone: +358 40 5079256 1516 EMail: jari.arkko@piuha.net