idnits 2.17.1 draft-ietf-hip-rfc5206-bis-03.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 (September 13, 2011) is 4580 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) == Unused Reference: 'RFC3484' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1403, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-03 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-rfc4423-bis (ref. 'I-D.ietf-hip-rfc4423-bis') == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-06 == Outdated reference: A later version (-07) exists of draft-ietf-hip-rfc5202-bis-00 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-01 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 8 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 The Boeing Company 4 Obsoletes: 5206 (if approved) C. Vogt 5 Intended status: Standards Track J. Arkko 6 Expires: March 16, 2012 Ericsson Research NomadicLab 7 September 13, 2011 9 Host Mobility with the Host Identity Protocol 10 draft-ietf-hip-rfc5206-bis-03 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 March 16, 2012. 42 Copyright Notice 44 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 73 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 6 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) . . . . . 10 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 . . . . . 12 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 . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 32 111 Appendix A. Document Revision History . . . . . . . . . . . . . . 32 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. This parameter's name is distinguished from the 186 Locator fields embedded within it by the use of all capital 187 letters. 189 Locator. A name that controls how the packet is routed through the 190 network and demultiplexed by the end host. It may include a 191 concatenation of traditional network addresses such as an IPv6 192 address and end-to-end identifiers such as an ESP SPI. It may 193 also include transport port numbers or IPv6 Flow Labels as 194 demultiplexing context, or it may simply be a network address. 196 Address. A name that denotes a point-of-attachment to the network. 197 The two most common examples are an IPv4 address and an IPv6 198 address. The set of possible addresses is a subset of the set of 199 possible locators. 201 Preferred locator. A locator on which a host prefers to receive 202 data. With respect to a given peer, a host always has one active 203 Preferred locator, unless there are no active locators. By 204 default, the locators used in the HIP base exchange are the 205 Preferred locators. 207 Credit Based Authorization. A host must verify a peer host's 208 reachability at a new locator. Credit-Based Authorization 209 authorizes the peer to receive a certain amount of data at the new 210 locator before the result of such verification is known. 212 3. Protocol Model 214 This section is an overview; more detailed specification follows this 215 section. 217 3.1. Operating Environment 219 The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is a key 220 establishment and parameter negotiation protocol. Its primary 221 applications are for authenticating host messages based on host 222 identities, and establishing security associations (SAs) for the ESP 223 transport format [I-D.ietf-hip-rfc5202-bis] and possibly other 224 protocols in the future. 226 +--------------------+ +--------------------+ 227 | | | | 228 | +------------+ | | +------------+ | 229 | | Key | | HIP | | Key | | 230 | | Management | <-+-----------------------+-> | Management | | 231 | | Process | | | | Process | | 232 | +------------+ | | +------------+ | 233 | ^ | | ^ | 234 | | | | | | 235 | v | | v | 236 | +------------+ | | +------------+ | 237 | | IPsec | | ESP | | IPsec | | 238 | | Stack | <-+-----------------------+-> | Stack | | 239 | | | | | | | | 240 | +------------+ | | +------------+ | 241 | | | | 242 | | | | 243 | Initiator | | Responder | 244 +--------------------+ +--------------------+ 246 Figure 1: HIP Deployment Model 248 The general deployment model for HIP is shown above, assuming 249 operation in an end-to-end fashion. This document specifies 250 extensions to the HIP protocol to enable end-host mobility and basic 251 multihoming. In summary, these extensions to the HIP base protocol 252 enable the signaling of new addressing information to the peer in HIP 253 messages. The messages are authenticated via a signature or keyed 254 hash message authentication code (HMAC) based on its Host Identity. 256 This document specifies the format of this new addressing 257 (LOCATOR_SET) parameter, the procedures for sending and processing 258 this parameter to enable basic host mobility, and procedures for a 259 concurrent address verification mechanism. 261 --------- 262 | TCP | (sockets bound to HITs) 263 --------- 264 | 265 --------- 266 ----> | ESP | {HIT_s, HIT_d} <-> SPI 267 | --------- 268 | | 269 ---- --------- 270 | MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 271 ---- --------- 272 | 273 --------- 274 | IP | 275 --------- 277 Figure 2: Architecture for HIP Host Mobility (MH) 279 Figure 2 depicts a layered architectural view of a HIP-enabled stack 280 using the ESP transport format. In HIP, upper-layer protocols 281 (including TCP and ESP in this figure) are bound to Host Identity 282 Tags (HITs) and not IP addresses. The HIP sublayer is responsible 283 for maintaining the binding between HITs and IP addresses. The SPI 284 is used to associate an incoming packet with the right HITs. The 285 block labeled "MH" is introduced below. 287 Consider first the case in which there is no mobility or multihoming, 288 as specified in the base protocol specification 289 [I-D.ietf-hip-rfc5201-bis]. The HIP base exchange establishes the 290 HITs in use between the hosts, the SPIs to use for ESP, and the IP 291 addresses (used in both the HIP signaling packets and ESP data 292 packets). Note that there can only be one such set of bindings in 293 the outbound direction for any given packet, and the only fields used 294 for the binding at the HIP layer are the fields exposed by ESP (the 295 SPI and HITs). For the inbound direction, the SPI is all that is 296 required to find the right host context. ESP rekeying events change 297 the mapping between the HIT pair and SPI, but do not change the IP 298 addresses. 300 Consider next a mobility event, in which a host moves to another IP 301 address. Two things must occur in this case. First, the peer must 302 be notified of the address change using a HIP UPDATE message. 303 Second, each host must change its local bindings at the HIP sublayer 304 (new IP addresses). It may be that both the SPIs and IP addresses 305 are changed simultaneously in a single UPDATE; the protocol described 306 herein supports this. However, simultaneous movement of both hosts, 307 notification of transport layer protocols of the path change, and 308 procedures for possibly traversing middleboxes are not covered by 309 this document. 311 3.1.1. Locator 313 This document defines a generalization of an address called a 314 "locator". A locator specifies a point-of-attachment to the network 315 but may also include additional end-to-end tunneling or per-host 316 demultiplexing context that affects how packets are handled below the 317 logical HIP sublayer of the stack. This generalization is useful 318 because IP addresses alone may not be sufficient to describe how 319 packets should be handled below HIP. For example, in a host 320 multihoming context, certain IP addresses may need to be associated 321 with certain ESP SPIs to avoid violating the ESP anti-replay window. 322 Addresses may also be affiliated with transport ports in certain 323 tunneling scenarios. Locators may simply be traditional network 324 addresses. The format of the locator fields in the LOCATOR_SET 325 parameter is defined in Section 4. 327 3.1.2. Mobility Overview 329 When a host moves to another address, it notifies its peer of the new 330 address by sending a HIP UPDATE packet containing a LOCATOR_SET 331 parameter. This UPDATE packet is acknowledged by the peer. For 332 reliability in the presence of packet loss, the UPDATE packet is 333 retransmitted as defined in the HIP protocol specification 334 [I-D.ietf-hip-rfc5201-bis]. The peer can authenticate the contents 335 of the UPDATE packet based on the signature and keyed hash of the 336 packet. 338 When using ESP Transport Format [I-D.ietf-hip-rfc5202-bis], the host 339 may at the same time decide to rekey its security association and 340 possibly generate a new Diffie-Hellman key; all of these actions are 341 triggered by including additional parameters in the UPDATE packet, as 342 defined in the base protocol specification [I-D.ietf-hip-rfc5201-bis] 343 and ESP extension [I-D.ietf-hip-rfc5202-bis]. 345 When using ESP (and possibly other transport modes in the future), 346 the host is able to receive packets that are protected using a HIP 347 created ESP SA from any address. Thus, a host can change its IP 348 address and continue to send packets to its peers without necessarily 349 rekeying. However, the peers are not able to send packets to these 350 new addresses before they can reliably and securely update the set of 351 addresses that they associate with the sending host. Furthermore, 352 mobility may change the path characteristics in such a manner that 353 reordering occurs and packets fall outside the ESP anti-replay window 354 for the SA, thereby requiring rekeying. 356 3.2. Protocol Overview 358 In this section, we briefly introduce a number of usage scenarios for 359 HIP host mobility. These scenarios assume that HIP is being used 360 with the ESP transform [I-D.ietf-hip-rfc5202-bis], although other 361 scenarios may be defined in the future. To understand these usage 362 scenarios, the reader should be at least minimally familiar with the 363 HIP protocol specification [I-D.ietf-hip-rfc5201-bis]. However, for 364 the (relatively) uninitiated reader, it is most important to keep in 365 mind that in HIP the actual payload traffic is protected with ESP, 366 and that the ESP SPI acts as an index to the right host-to-host 367 context. More specification details are found later in Section 4 and 368 Section 5. 370 The scenarios below assume that the two hosts have completed a single 371 HIP base exchange with each other. Both of the hosts therefore have 372 one incoming and one outgoing SA. Further, each SA uses the same 373 pair of IP addresses, which are the ones used in the base exchange. 375 The readdressing protocol is an asymmetric protocol where a mobile 376 host informs a peer host about changes of IP addresses on affected 377 SPIs. The readdressing exchange is designed to be piggybacked on 378 existing HIP exchanges. The majority of the packets on which the 379 LOCATOR_SET parameters are expected to be carried are UPDATE packets. 380 However, some implementations may want to experiment with sending 381 LOCATOR_SET parameters also on other packets, such as R1, I2, and 382 NOTIFY. 384 The scenarios below at times describe addresses as being in either an 385 ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a 386 host, newly-learned addresses of the peer must be verified before put 387 into active service, and addresses removed by the peer are put into a 388 deprecated state. Under limited conditions described below 389 (Section 5.6), an UNVERIFIED address may be used. The addressing 390 states are defined more formally in Section 5.1. 392 Hosts that use link-local addresses as source addresses in their HIP 393 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 394 provide a globally routable address either in the initial handshake 395 or via the LOCATOR_SET parameter. 397 3.2.1. Mobility with a Single SA Pair (No Rekeying) 399 A mobile host must sometimes change an IP address bound to an 400 interface. The change of an IP address might be needed due to a 401 change in the advertised IPv6 prefixes on the link, a reconnected PPP 402 link, a new DHCP lease, or an actual movement to another subnet. In 403 order to maintain its communication context, the host must inform its 404 peers about the new IP address. This first example considers the 405 case in which the mobile host has only one interface, IP address, a 406 single pair of SAs (one inbound, one outbound), and no rekeying 407 occurs on the SAs. We also assume that the new IP addresses are 408 within the same address family (IPv4 or IPv6) as the first address. 409 This is the simplest scenario, depicted in Figure 3. 411 Mobile Host Peer Host 413 UPDATE(ESP_INFO, LOCATOR_SET, SEQ) 414 -----------------------------------> 415 UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST) 416 <----------------------------------- 417 UPDATE(ACK, ECHO_RESPONSE) 418 -----------------------------------> 420 Figure 3: Readdress without Rekeying, but with Address Check 422 The steps of the packet processing are as follows: 424 1. The mobile host may be disconnected from the peer host for a 425 brief period of time while it switches from one IP address to 426 another; this case is sometimes referred to in the literature as 427 a "break-before-make" case. The host may also obtain its new IP 428 address before loosing the old one ("make-before-break" case). 429 In either case, upon obtaining a new IP address, the mobile host 430 sends a LOCATOR_SET parameter to the peer host in an UPDATE 431 message. The UPDATE message also contains an ESP_INFO parameter 432 containing the values of the old and new SPIs for a security 433 association. In this case, the OLD SPI and NEW SPI parameters 434 both are set to the value of the preexisting incoming SPI; this 435 ESP_INFO does not trigger a rekeying event but is instead 436 included for possible parameter-inspecting middleboxes on the 437 path. The LOCATOR_SET parameter contains the new IP address 438 (Locator Type of "1", defined below) and a locator lifetime. The 439 mobile host waits for this UPDATE to be acknowledged, and 440 retransmits if necessary, as specified in the base specification 441 [I-D.ietf-hip-rfc5201-bis]. 443 2. The peer host receives the UPDATE, validates it, and updates any 444 local bindings between the HIP association and the mobile host's 445 destination address. The peer host MUST perform an address 446 verification by placing a nonce in the ECHO_REQUEST parameter of 447 the UPDATE message sent back to the mobile host. It also 448 includes an ESP_INFO parameter with the OLD SPI and NEW SPI 449 parameters both set to the value of the preexisting incoming SPI, 450 and sends this UPDATE (with piggybacked acknowledgment) to the 451 mobile host at its new address. The peer MAY use the new address 452 immediately, but it MUST limit the amount of data it sends to the 453 address until address verification completes. 455 3. The mobile host completes the readdress by processing the UPDATE 456 ACK and echoing the nonce in an ECHO_RESPONSE. Once the peer 457 host receives this ECHO_RESPONSE, it considers the new address to 458 be verified and can put the address into full use. 460 While the peer host is verifying the new address, the new address is 461 marked as UNVERIFIED in the interim, and the old address is 462 DEPRECATED. Once the peer host has received a correct reply to its 463 UPDATE challenge, it marks the new address as ACTIVE and removes the 464 old address. 466 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) 468 The mobile host may decide to rekey the SAs at the same time that it 469 notifies the peer of the new address. In this case, the above 470 procedure described in Figure 3 is slightly modified. The UPDATE 471 message sent from the mobile host includes an ESP_INFO with the OLD 472 SPI set to the previous SPI, the NEW SPI set to the desired new SPI 473 value for the incoming SA, and the KEYMAT Index desired. Optionally, 474 the host may include a DIFFIE_HELLMAN parameter for a new Diffie- 475 Hellman key. The peer completes the request for a rekey as is 476 normally done for HIP rekeying, except that the new address is kept 477 as UNVERIFIED until the UPDATE nonce challenge is received as 478 described above. Figure 4 illustrates this scenario. 480 Mobile Host Peer Host 482 UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) 483 -----------------------------------> 484 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 485 <----------------------------------- 486 UPDATE(ACK, ECHO_RESPONSE) 487 -----------------------------------> 489 Figure 4: Readdress with Mobile-Initiated Rekey 491 3.2.3. Using LOCATOR_SETs across Addressing Realms 493 It is possible for HIP associations to migrate to a state in which 494 both parties are only using locators in different addressing realms. 495 For example, the two hosts may initiate the HIP association when both 496 are using IPv6 locators, then one host may loose its IPv6 497 connectivity and obtain an IPv4 address. In such a case, some type 498 of mechanism for interworking between the different realms must be 499 employed; such techniques are outside the scope of the present text. 500 The basic problem in this example is that the host readdressing to 501 IPv4 does not know a corresponding IPv4 address of the peer. This 502 may be handled (experimentally) by possibly configuring this address 503 information manually or in the DNS, or the hosts exchange both IPv4 504 and IPv6 addresses in the locator. 506 3.2.4. Network Renumbering 508 It is expected that IPv6 networks will be renumbered much more often 509 than most IPv4 networks. From an end-host point of view, network 510 renumbering is similar to mobility. 512 3.3. Other Considerations 514 3.3.1. Address Verification 516 When a HIP host receives a set of locators from another HIP host in a 517 LOCATOR_SET, it does not necessarily know whether the other host is 518 actually reachable at the claimed addresses. In fact, a malicious 519 peer host may be intentionally giving bogus addresses in order to 520 cause a packet flood towards the target addresses [RFC4225]. 521 Likewise, viral software may have compromised the peer host, 522 programming it to redirect packets to the target addresses. Thus, 523 the HIP host must first check that the peer is reachable at the new 524 address. 526 An additional potential benefit of performing address verification is 527 to allow middleboxes in the network along the new path to obtain the 528 peer host's inbound SPI. 530 Address verification is implemented by the challenger sending some 531 piece of unguessable information to the new address, and waiting for 532 some acknowledgment from the Responder that indicates reception of 533 the information at the new address. This may include the exchange of 534 a nonce, or the generation of a new SPI and observation of data 535 arriving on the new SPI. 537 3.3.2. Credit-Based Authorization 539 Credit-Based Authorization (CBA) allows a host to securely use a new 540 locator even though the peer's reachability at the address embedded 541 in the locator has not yet been verified. This is accomplished based 542 on the following three hypotheses: 544 1. A flooding attacker typically seeks to somehow multiply the 545 packets it generates for the purpose of its attack because 546 bandwidth is an ample resource for many victims. 548 2. An attacker can often cause unamplified flooding by sending 549 packets to its victim, either by directly addressing the victim 550 in the packets, or by guiding the packets along a specific path 551 by means of an IPv6 Routing header, if Routing headers are not 552 filtered by firewalls. 554 3. Consequently, the additional effort required to set up a 555 redirection-based flooding attack (without CBA and return 556 routability checks) would pay off for the attacker only if 557 amplification could be obtained this way. 559 On this basis, rather than eliminating malicious packet redirection 560 in the first place, Credit-Based Authorization prevents 561 amplifications. This is accomplished by limiting the data a host can 562 send to an unverified address of a peer by the data recently received 563 from that peer. Redirection-based flooding attacks thus become less 564 attractive than, for example, pure direct flooding, where the 565 attacker itself sends bogus packets to the victim. 567 Figure 5 illustrates Credit-Based Authorization: Host B measures the 568 amount of data recently received from peer A and, when A readdresses, 569 sends packets to A's new, unverified address as long as the sum of 570 the packet sizes does not exceed the measured, received data volume. 571 When insufficient credit is left, B stops sending further packets to 572 A until A's address becomes ACTIVE. The address changes may be due 573 to mobility, multihoming, or any other reason. Not shown in Figure 5 574 are the results of credit aging (Section 5.6.2), a mechanism used to 575 dampen possible time-shifting attacks. 577 +-------+ +-------+ 578 | A | | B | 579 +-------+ +-------+ 580 | | 581 address |------------------------------->| credit += size(packet) 582 ACTIVE | | 583 |------------------------------->| credit += size(packet) 584 |<-------------------------------| do not change credit 585 | | 586 + address change | 587 + address verification starts | 588 address |<-------------------------------| credit -= size(packet) 589 UNVERIFIED |------------------------------->| credit += size(packet) 590 |<-------------------------------| credit -= size(packet) 591 | | 592 |<-------------------------------| credit -= size(packet) 593 | X credit < size(packet) 594 | | => do not send packet! 595 + address verification concludes | 596 address | | 597 ACTIVE |<-------------------------------| do not change credit 598 | | 600 Figure 5: Readdressing Scenario 602 3.3.3. Preferred Locator 604 When a host has multiple locators, the peer host must decide which to 605 use for outbound packets. It may be that a host would prefer to 606 receive data on a particular inbound interface. HIP allows a 607 particular locator to be designated as a Preferred locator and 608 communicated to the peer (see Section 4). 610 4. LOCATOR_SET Parameter Format 612 The LOCATOR_SET parameter is a critical parameter as defined by 613 [I-D.ietf-hip-rfc5201-bis]. It consists of the standard HIP 614 parameter Type and Length fields, plus zero or more Locator sub- 615 parameters. Each Locator sub-parameter contains a Traffic Type, 616 Locator Type, Locator Length, Preferred locator bit, Locator 617 Lifetime, and a Locator encoding. A LOCATOR_SET containing zero 618 Locator fields is permitted but has the effect of deprecating all 619 addresses. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Traffic Type | Locator Type | Locator Length | Reserved |P| 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Locator Lifetime | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Locator | 631 | | 632 | | 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 . . 636 . . 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Traffic Type | Locator Type | Locator Length | Reserved |P| 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Locator Lifetime | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Locator | 643 | | 644 | | 645 | | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 6: LOCATOR_SET Parameter Format 650 Type: 193 652 Length: Length in octets, excluding Type and Length fields, and 653 excluding padding. 655 Traffic Type: Defines whether the locator pertains to HIP signaling, 656 user data, or both. 658 Locator Type: Defines the semantics of the Locator field. 660 Locator Length: Defines the length of the Locator field, in units of 661 4-byte words (Locators up to a maximum of 4*255 octets are 662 supported). 664 Reserved: Zero when sent, ignored when received. 666 P: Preferred locator. Set to one if the locator is preferred for 667 that Traffic Type; otherwise, set to zero. 669 Locator Lifetime: Locator lifetime, in seconds. 671 Locator: The locator whose semantics and encoding are indicated by 672 the Locator Type field. All Locator sub-fields are integral 673 multiples of four octets in length. 675 The Locator Lifetime indicates how long the following locator is 676 expected to be valid. The lifetime is expressed in seconds. Each 677 locator MUST have a non-zero lifetime. The address is expected to 678 become deprecated when the specified number of seconds has passed 679 since the reception of the message. A deprecated address SHOULD NOT 680 be used as a destination address if an alternate (non-deprecated) is 681 available and has sufficient scope. 683 4.1. Traffic Type and Preferred Locator 685 The following Traffic Type values are defined: 687 0: Both signaling (HIP control packets) and user data. 689 1: Signaling packets only. 691 2: Data packets only. 693 The "P" bit, when set, has scope over the corresponding Traffic Type. 694 That is, when a "P" bit is set for Traffic Type "2", for example, it 695 means that the locator is preferred for data packets. If there is a 696 conflict (for example, if the "P" bit is set for an address of Type 697 "0" and a different address of Type "2"), the more specific Traffic 698 Type rule applies (in this case, "2"). By default, the IP addresses 699 used in the base exchange are Preferred locators for both signaling 700 and user data, unless a new Preferred locator supersedes them. If no 701 locators are indicated as preferred for a given Traffic Type, the 702 implementation may use an arbitrary locator from the set of active 703 locators. 705 4.2. Locator Type and Locator 707 The following Locator Type values are defined, along with the 708 associated semantics of the Locator field: 710 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [RFC4291] 711 (128 bits long). This locator type is defined primarily for non- 712 ESP-based usage. 714 1: The concatenation of an ESP SPI (first 32 bits) followed by an 715 IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 716 128 bits). This IP address is defined primarily for ESP-based 717 usage. 719 4.3. UPDATE Packet with Included LOCATOR_SET 721 A number of combinations of parameters in an UPDATE packet are 722 possible (e.g., see Section 3.2). In this document, procedures are 723 defined only for the case in which one LOCATOR_SET and one ESP_INFO 724 parameter is used in any HIP packet. Furthermore, the LOCATOR_SET 725 SHOULD list all of the locators that are active on the HIP 726 association (including those on SAs not covered by the ESP_INFO 727 parameter). Any UPDATE packet that includes a LOCATOR_SET parameter 728 SHOULD include both an HMAC and a HIP_SIGNATURE parameter. The 729 relationship between the announced Locators and any ESP_INFO 730 parameters present in the packet is defined in Section 5.2. The 731 sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for 732 further study; receivers may wish to experiment with supporting such 733 a possibility. 735 5. Processing Rules 737 This section describes rules for sending and receiving the 738 LOCATOR_SET parameter, testing address reachability, and using 739 Credit-Based Authorization (CBA) on UNVERIFIED locators. 741 5.1. Locator Data Structure and Status 743 In a typical implementation, each outgoing locator is represented by 744 a piece of state that contains the following data: 746 o the actual bit pattern representing the locator, 748 o the lifetime (seconds), 750 o the status (UNVERIFIED, ACTIVE, DEPRECATED), 752 o the Traffic Type scope of the locator, and 754 o whether the locator is preferred for any particular scope. 756 The status is used to track the reachability of the address embedded 757 within the LOCATOR_SET parameter: 759 UNVERIFIED indicates that the reachability of the address has not 760 been verified yet, 762 ACTIVE indicates that the reachability of the address has been 763 verified and the address has not been deprecated, 765 DEPRECATED indicates that the locator lifetime has expired. 767 The following state changes are allowed: 769 UNVERIFIED to ACTIVE The reachability procedure completes 770 successfully. 772 UNVERIFIED to DEPRECATED The locator lifetime expires while the 773 locator is UNVERIFIED. 775 ACTIVE to DEPRECATED The locator lifetime expires while the locator 776 is ACTIVE. 778 ACTIVE to UNVERIFIED There has been no traffic on the address for 779 some time, and the local policy mandates that the address 780 reachability must be verified again before starting to use it 781 again. 783 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 784 locator. 786 A DEPRECATED address MUST NOT be changed to ACTIVE without first 787 verifying its reachability. 789 Note that the state of whether or not a locator is preferred is not 790 necessarily the same as the value of the Preferred bit in the Locator 791 sub-parameter received from the peer. Peers may recommend certain 792 locators to be preferred, but the decision on whether to actually use 793 a locator as a preferred locator is a local decision, possibly 794 influenced by local policy. 796 5.2. Sending LOCATOR_SETs 798 The decision of when to send LOCATOR_SETs is basically a local policy 799 issue. However, it is RECOMMENDED that a host send a LOCATOR_SET 800 whenever it recognizes a change of its IP addresses in use on an 801 active HIP association, and assumes that the change is going to last 802 at least for a few seconds. It is possible to delay the exposure of 803 additional locators to the peer, and to send data from previously 804 unannounced locators, as might arise in certain mobility situations. 805 Rapidly sending LOCATOR_SETs that force the peer to change the 806 preferred address SHOULD be avoided. 808 When a host decides to inform its peers about changes in its IP 809 addresses, it has to decide how to group the various addresses with 810 SPIs. The grouping should consider also whether middlebox 811 interaction requires sending the same LOCATOR_SET in separate UPDATEs 812 on different paths. Since each SPI is associated with a different 813 Security Association, the grouping policy may also be based on ESP 814 anti-replay protection considerations. In the typical case, simply 815 basing the grouping on actual kernel level physical and logical 816 interfaces may be the best policy. Grouping policy is outside of the 817 scope of this document. 819 Note that the purpose of announcing IP addresses in a LOCATOR_SET is 820 to provide connectivity between the communicating hosts. In most 821 cases, tunnels or virtual interfaces such as IPsec tunnel interfaces 822 or Mobile IP home addresses provide sub-optimal connectivity. 823 Furthermore, it should be possible to replace most tunnels with HIP 824 based "non-tunneling", therefore making most virtual interfaces 825 fairly unnecessary in the future. Therefore, virtual interfaces 826 SHOULD NOT be announced in general. On the other hand, there are 827 clearly situations where tunnels are used for diagnostic and/or 828 testing purposes. In such and other similar cases announcing the IP 829 addresses of virtual interfaces may be appropriate. 831 Hosts MUST NOT announce broadcast or multicast addresses in 832 LOCATOR_SETs. Link-local addresses MAY be announced to peers that 833 are known to be neighbors on the same link, such as when the IP 834 destination address of a peer is also link-local. The announcement 835 of link-local addresses in this case is a policy decision; link-local 836 addresses used as Preferred locators will create reachability 837 problems when the host moves to another link. In any case, link- 838 local addresses MUST NOT be announced to a peer unless that peer is 839 known to be on the same link. 841 Once the host has decided on the groups and assignment of addresses 842 to the SPIs, it creates a LOCATOR_SET parameter that serves as a 843 complete representation of the addresses and affiliated SPIs intended 844 for active use. We now describe a few cases introduced in 845 Section 3.2. We assume that the Traffic Type for each locator is set 846 to "0" (other values for Traffic Type may be specified in documents 847 that separate the HIP control plane from data plane traffic). Other 848 mobility cases are possible but are left for further experimentation. 850 1. Host mobility with no multihoming and no rekeying. The mobile 851 host creates a single UPDATE containing a single ESP_INFO with a 852 single LOCATOR_SET parameter. The ESP_INFO contains the current 853 value of the SPI in both the OLD SPI and NEW SPI fields. The 854 LOCATOR_SET contains a single Locator with a "Locator Type" of 855 "1"; the SPI must match that of the ESP_INFO. The Preferred bit 856 SHOULD be set and the "Locator Lifetime" is set according to 857 local policy. The UPDATE also contains a SEQ parameter as usual. 858 This packet is retransmitted as defined in the HIP protocol 859 specification [I-D.ietf-hip-rfc5201-bis]. The UPDATE should be 860 sent to the peer's preferred IP address with an IP source address 861 corresponding to the address in the LOCATOR_SET parameter. 863 2. Host mobility with no multihoming but with rekeying. The mobile 864 host creates a single UPDATE containing a single ESP_INFO with a 865 single LOCATOR_SET parameter (with a single address). The 866 ESP_INFO contains the current value of the SPI in the OLD SPI and 867 the new value of the SPI in the NEW SPI, and a KEYMAT Index as 868 selected by local policy. Optionally, the host may choose to 869 initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN 870 parameter. The LOCATOR_SET contains a single Locator with 871 "Locator Type" of "1"; the SPI must match that of the NEW SPI in 872 the ESP_INFO. Otherwise, the steps are identical to the case in 873 which no rekeying is initiated. 875 The sending of multiple LOCATOR_SETs, locators with Locator Type "0", 876 and multiple ESP_INFO parameters is for further study. Note that the 877 inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" 878 locators since no SAs are set up at that point. 880 5.3. Handling Received LOCATOR_SETs 882 A host SHOULD be prepared to receive a LOCATOR_SET parameter in the 883 following HIP packets: R1, I2, UPDATE, and NOTIFY. 885 This document describes sending both ESP_INFO and LOCATOR_SET 886 parameters in an UPDATE. The ESP_INFO parameter is included when 887 there is a need to rekey or key a new SPI, and is otherwise included 888 for the possible benefit of HIP-aware middleboxes. The LOCATOR_SET 889 parameter contains a complete map of the locators that the host 890 wishes to make or keep active for the HIP association. 892 In general, the processing of a LOCATOR_SET depends upon the packet 893 type in which it is included. Here, we describe only the case in 894 which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are 895 sent in an UPDATE message; other cases are for further study. The 896 steps below cover each of the cases described in Section 5.2. 898 The processing of ESP_INFO and LOCATOR_SET parameters is intended to 899 be modular and support future generalization to the inclusion of 900 multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host 901 SHOULD first process the ESP_INFO before the LOCATOR_SET, since the 902 ESP_INFO may contain a new SPI value mapped to an existing SPI, while 903 a Type "1" locator will only contain a reference to the new SPI. 905 When a host receives a validated HIP UPDATE with a LOCATOR_SET and 906 ESP_INFO parameter, it processes the ESP_INFO as follows. The 907 ESP_INFO parameter indicates whether an SA is being rekeyed, created, 908 deprecated, or just identified for the benefit of middleboxes. The 909 host examines the OLD SPI and NEW SPI values in the ESP_INFO 910 parameter: 912 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both 913 correspond to an existing SPI, the ESP_INFO is gratuitous 914 (provided for middleboxes) and no rekeying is necessary. 916 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW 917 SPI is a different non-zero value, the existing SA is being 918 rekeyed and the host follows HIP ESP rekeying procedures by 919 creating a new outbound SA with an SPI corresponding to the NEW 920 SPI, with no addresses bound to this SPI. Note that locators in 921 the LOCATOR_SET parameter will reference this new SPI instead of 922 the old SPI. 924 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new 925 non-zero value, then a new SA is being requested by the peer. 926 This case is also treated like a rekeying event; the receiving 927 host must create a new SA and respond with an UPDATE ACK. 929 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and 930 the NEW SPI is zero, the SA is being deprecated and all locators 931 uniquely bound to the SPI are put into the DEPRECATED state. 933 If none of the above cases apply, a protocol error has occurred and 934 the processing of the UPDATE is stopped. 936 Next, the locators in the LOCATOR_SET parameter are processed. For 937 each locator listed in the LOCATOR_SET parameter, check that the 938 address therein is a legal unicast or anycast address. That is, the 939 address MUST NOT be a broadcast or multicast address. Note that some 940 implementations MAY accept addresses that indicate the local host, 941 since it may be allowed that the host runs HIP with itself. 943 The below assumes that all locators are of Type "1" with a Traffic 944 Type of "0"; other cases are for further study. 946 For each Type "1" address listed in the LOCATOR_SET parameter, the 947 host checks whether the address is already bound to the SPI 948 indicated. If the address is already bound, its lifetime is updated. 949 If the status of the address is DEPRECATED, the status is changed to 950 UNVERIFIED. If the address is not already bound, the address is 951 added, and its status is set to UNVERIFIED. Mark all addresses 952 corresponding to the SPI that were NOT listed in the LOCATOR_SET 953 parameter as DEPRECATED. 955 As a result, at the end of processing, the addresses listed in the 956 LOCATOR_SET parameter have either a state of UNVERIFIED or ACTIVE, 957 and any old addresses on the old SA not listed in the LOCATOR_SET 958 parameter have a state of DEPRECATED. 960 Once the host has processed the locators, if the LOCATOR_SET 961 parameter contains a new Preferred locator, the host SHOULD initiate 962 a change of the Preferred locator. This requires that the host first 963 verifies reachability of the associated address, and only then 964 changes the Preferred locator; see Section 5.5. 966 If a host receives a locator with an unsupported Locator Type, and 967 when such a locator is also declared to be the Preferred locator for 968 the peer, the host SHOULD send a NOTIFY error with a Notify Message 969 Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field 970 containing the locator(s) that the receiver failed to process. 971 Otherwise, a host MAY send a NOTIFY error if a (non-preferred) 972 locator with an unsupported Locator Type is received in a LOCATOR_SET 973 parameter. 975 A host MAY add the source IP address of a received HIP packet as a 976 candidate locator for the peer even if it is not listed in the peer's 977 LOCATOR_SET, but it SHOULD prefer locators explicitly listed in the 978 LOCATOR_SET. 980 5.4. Verifying Address Reachability 982 A host MUST verify the reachability of an UNVERIFIED address. The 983 status of a newly learned address MUST initially be set to UNVERIFIED 984 unless the new address is advertised in a R1 packet as a new 985 Preferred locator. A host MAY also want to verify the reachability 986 of an ACTIVE address again after some time, in which case it would 987 set the status of the address to UNVERIFIED and reinitiate address 988 verification. 990 A host typically starts the address-verification procedure by sending 991 a nonce to the new address. For example, when the host is changing 992 its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD 993 be random and the value MAY be copied into an ECHO_REQUEST sent in 994 the rekeying UPDATE. However, if the host is not changing its SPI, 995 it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent 996 to the new address. A host MAY also use other message exchanges as 997 confirmation of the address reachability. 999 Note that in the case of receiving a LOCATOR_SET in an R1 and 1000 replying with an I2 to the new address in the LOCATOR_SET, receiving 1001 the corresponding R2 is sufficient proof of reachability for the 1002 Responder's preferred address. Since further address verification of 1003 such an address can impede the HIP-base exchange, a host MUST NOT 1004 separately verify reachability of a new Preferred locator that was 1005 received on an R1. 1007 In some cases, it MAY be sufficient to use the arrival of data on a 1008 newly advertised SA as implicit address reachability verification as 1009 depicted in Figure 7, instead of waiting for the confirmation via a 1010 HIP packet. In this case, a host advertising a new SPI as part of 1011 its address reachability check SHOULD be prepared to receive traffic 1012 on the new SA. 1014 Mobile host Peer host 1016 prepare incoming SA 1017 NEW SPI in ESP_INFO (UPDATE) 1018 <----------------------------------- 1019 switch to new outgoing SA 1020 data on new SA 1021 -----------------------------------> 1022 mark address ACTIVE 1024 Figure 7: Address Activation Via Use of a New SA 1026 When address verification is in progress for a new Preferred locator, 1027 the host SHOULD select a different locator listed as ACTIVE, if one 1028 such locator is available, to continue communications until address 1029 verification completes. Alternatively, the host MAY use the new 1030 Preferred locator while in UNVERIFIED status to the extent Credit- 1031 Based Authorization permits. Credit-Based Authorization is explained 1032 in Section 5.6. Once address verification succeeds, the status of 1033 the new Preferred locator changes to ACTIVE. 1035 5.5. Changing the Preferred Locator 1037 A host MAY want to change the Preferred outgoing locator for 1038 different reasons, e.g., because traffic information or ICMP error 1039 messages indicate that the currently used preferred address may have 1040 become unreachable. Another reason may be due to receiving a 1041 LOCATOR_SET parameter that has the "P" bit set. 1043 To change the Preferred locator, the host initiates the following 1044 procedure: 1046 1. If the new Preferred locator has ACTIVE status, the Preferred 1047 locator is changed and the procedure succeeds. 1049 2. If the new Preferred locator has UNVERIFIED status, the host 1050 starts to verify its reachability. The host SHOULD use a 1051 different locator listed as ACTIVE until address verification 1052 completes if one such locator is available. Alternatively, the 1053 host MAY use the new Preferred locator, even though in UNVERIFIED 1054 status, to the extent Credit-Based Authorization permits. Once 1055 address verification succeeds, the status of the new Preferred 1056 locator changes to ACTIVE and its use is no longer governed by 1057 Credit-Based Authorization. 1059 3. If the peer host has not indicated a preference for any address, 1060 then the host picks one of the peer's ACTIVE addresses randomly 1061 or according to policy. This case may arise if, for example, 1062 ICMP error messages that deprecate the Preferred locator arrive, 1063 but the peer has not yet indicated a new Preferred locator. 1065 4. If the new Preferred locator has DEPRECATED status and there is 1066 at least one non-deprecated address, the host selects one of the 1067 non-deprecated addresses as a new Preferred locator and 1068 continues. If the selected address is UNVERIFIED, the address 1069 verification procedure described above will apply. 1071 5.6. Credit-Based Authorization 1073 To prevent redirection-based flooding attacks, the use of a Credit- 1074 Based Authorization (CBA) approach is mandatory when a host sends 1075 data to an UNVERIFIED locator. The following algorithm meets the 1076 security considerations for prevention of amplification and time- 1077 shifting attacks. Other forms of credit aging, and other values for 1078 the CreditAgingFactor and CreditAgingInterval parameters in 1079 particular, are for further study, and so are the advanced CBA 1080 techniques specified in [CBA-MIPv6]. 1082 5.6.1. Handling Payload Packets 1084 A host maintains a "credit counter" for each of its peers. Whenever 1085 a packet arrives from a peer, the host SHOULD increase that peer's 1086 credit counter by the size of the received packet. When the host has 1087 a packet to be sent to the peer, and when the peer's Preferred 1088 locator is listed as UNVERIFIED and no alternative locator with 1089 status ACTIVE is available, the host checks whether it can send the 1090 packet to the UNVERIFIED locator. The packet SHOULD be sent if the 1091 value of the credit counter is higher than the size of the outbound 1092 packet. If the credit counter is too low, the packet MUST be 1093 discarded or buffered until address verification succeeds. When a 1094 packet is sent to a peer at an UNVERIFIED locator, the peer's credit 1095 counter MUST be reduced by the size of the packet. The peer's credit 1096 counter is not affected by packets that the host sends to an ACTIVE 1097 locator of that peer. 1099 Figure 8 depicts the actions taken by the host when a packet is 1100 received. Figure 9 shows the decision chain in the event a packet is 1101 sent. 1103 Inbound 1104 packet 1105 | 1106 | +----------------+ +---------------+ 1107 | | Increase | | Deliver | 1108 +-----> | credit counter |-------------> | packet to | 1109 | by packet size | | application | 1110 +----------------+ +---------------+ 1112 Figure 8: Receiving Packets with Credit-Based Authorization 1114 Outbound 1115 packet 1116 | _________________ 1117 | / \ +---------------+ 1118 | / Is the preferred \ No | Send packet | 1119 +-----> | destination address |-------------> | to preferred | 1120 \ UNVERIFIED? / | address | 1121 \_________________/ +---------------+ 1122 | 1123 | Yes 1124 | 1125 v 1126 _________________ 1127 / \ +---------------+ 1128 / Does an ACTIVE \ Yes | Send packet | 1129 | destination address |-------------> | to ACTIVE | 1130 \ exist? / | address | 1131 \_________________/ +---------------+ 1132 | 1133 | No 1134 | 1135 v 1136 _________________ 1137 / \ +---------------+ 1138 / Credit counter \ No | | 1139 | >= |-------------> | Drop packet | 1140 \ packet size? / | | 1141 \_________________/ +---------------+ 1142 | 1143 | Yes 1144 | 1145 v 1146 +---------------+ +---------------+ 1147 | Reduce credit | | Send packet | 1148 | counter by |----------------> | to preferred | 1149 | packet size | | address | 1150 +---------------+ +---------------+ 1152 Figure 9: Sending Packets with Credit-Based Authorization 1154 5.6.2. Credit Aging 1156 A host ensures that the credit counters it maintains for its peers 1157 gradually decrease over time. Such "credit aging" prevents a 1158 malicious peer from building up credit at a very slow speed and using 1159 this, all at once, for a severe burst of redirected packets. 1161 Credit aging may be implemented by multiplying credit counters with a 1162 factor, CreditAgingFactor (a fractional value less than one), in 1163 fixed time intervals of CreditAgingInterval length. Choosing 1164 appropriate values for CreditAgingFactor and CreditAgingInterval is 1165 important to ensure that a host can send packets to an address in 1166 state UNVERIFIED even when the peer sends at a lower rate than the 1167 host itself. When CreditAgingFactor or CreditAgingInterval are too 1168 small, the peer's credit counter might be too low to continue sending 1169 packets until address verification concludes. 1171 The parameter values proposed in this document are as follows: 1173 CreditAgingFactor 7/8 1174 CreditAgingInterval 5 seconds 1176 These parameter values work well when the host transfers a file to 1177 the peer via a TCP connection and the end-to-end round-trip time does 1178 not exceed 500 milliseconds. Alternative credit-aging algorithms may 1179 use other parameter values or different parameters, which may even be 1180 dynamically established. 1182 6. Security Considerations 1184 The HIP mobility mechanism provides a secure means of updating a 1185 host's IP address via HIP UPDATE packets. Upon receipt, a HIP host 1186 cryptographically verifies the sender of an UPDATE, so forging or 1187 replaying a HIP UPDATE packet is very difficult (see 1188 [I-D.ietf-hip-rfc5201-bis]). Therefore, security issues reside in 1189 other attack domains. The two we consider are malicious redirection 1190 of legitimate connections as well as redirection-based flooding 1191 attacks using this protocol. This can be broken down into the 1192 following: 1194 Impersonation attacks 1196 - direct conversation with the misled victim 1198 - man-in-the-middle attack 1200 DoS attacks 1202 - flooding attacks (== bandwidth-exhaustion attacks) 1204 * tool 1: direct flooding 1205 * tool 2: flooding by zombies 1207 * tool 3: redirection-based flooding 1209 - memory-exhaustion attacks 1211 - computational-exhaustion attacks 1213 We consider these in more detail in the following sections. 1215 In Section 6.1 and Section 6.2, we assume that all users are using 1216 HIP. In Section 6.3 we consider the security ramifications when we 1217 have both HIP and non-HIP users. Security considerations for Credit- 1218 Based Authorization are discussed in [SIMPLE-CBA]. 1220 6.1. Impersonation Attacks 1222 An attacker wishing to impersonate another host will try to mislead 1223 its victim into directly communicating with them, or carry out a man- 1224 in-the-middle (MitM) attack between the victim and the victim's 1225 desired communication peer. Without mobility support, both attack 1226 types are possible only if the attacker resides on the routing path 1227 between its victim and the victim's desired communication peer, or if 1228 the attacker tricks its victim into initiating the connection over an 1229 incorrect routing path (e.g., by acting as a router or using spoofed 1230 DNS entries). 1232 The HIP extensions defined in this specification change the situation 1233 in that they introduce an ability to redirect a connection (like 1234 IPv6), both before and after establishment. If no precautionary 1235 measures are taken, an attacker could misuse the redirection feature 1236 to impersonate a victim's peer from any arbitrary location. The 1237 authentication and authorization mechanisms of the HIP base exchange 1238 [I-D.ietf-hip-rfc5201-bis] and the signatures in the UPDATE message 1239 prevent this attack. Furthermore, ownership of a HIP association is 1240 securely linked to a HIP HI/HIT. If an attacker somehow uses a bug 1241 in the implementation or weakness in some protocol to redirect a HIP 1242 connection, the original owner can always reclaim their connection 1243 (they can always prove ownership of the private key associated with 1244 their public HI). 1246 MitM attacks are always possible if the attacker is present during 1247 the initial HIP base exchange and if the hosts do not authenticate 1248 each other's identities. However, once the opportunistic base 1249 exchange has taken place, even a MitM cannot steal the HIP connection 1250 anymore because it is very difficult for an attacker to create an 1251 UPDATE packet (or any HIP packet) that will be accepted as a 1252 legitimate update. UPDATE packets use HMAC and are signed. Even 1253 when an attacker can snoop packets to obtain the SPI and HIT/HI, they 1254 still cannot forge an UPDATE packet without knowledge of the secret 1255 keys. 1257 6.2. Denial-of-Service Attacks 1259 6.2.1. Flooding Attacks 1261 The purpose of a denial-of-service attack is to exhaust some resource 1262 of the victim such that the victim ceases to operate correctly. A 1263 denial-of-service attack can aim at the victim's network attachment 1264 (flooding attack), its memory, or its processing capacity. In a 1265 flooding attack, the attacker causes an excessive number of bogus or 1266 unwanted packets to be sent to the victim, which fills their 1267 available bandwidth. Note that the victim does not necessarily need 1268 to be a node; it can also be an entire network. The attack basically 1269 functions the same way in either case. 1271 An effective DoS strategy is distributed denial of service (DDoS). 1272 Here, the attacker conventionally distributes some viral software to 1273 as many nodes as possible. Under the control of the attacker, the 1274 infected nodes, or "zombies", jointly send packets to the victim. 1275 With such an 'army', an attacker can take down even very high 1276 bandwidth networks/victims. 1278 With the ability to redirect connections, an attacker could realize a 1279 DDoS attack without having to distribute viral code. Here, the 1280 attacker initiates a large download from a server, and subsequently 1281 redirects this download to its victim. The attacker can repeat this 1282 with multiple servers. This threat is mitigated through reachability 1283 checks and credit-based authorization. Both strategies do not 1284 eliminate flooding attacks per se, but they preclude: (i) their use 1285 from a location off the path towards the flooded victim; and (ii) any 1286 amplification in the number and size of the redirected packets. As a 1287 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 [I-D.ietf-hip-rfc5201-bis]). A 1297 simple attack is to send many UPDATE packets containing many IP 1298 addresses that are not flagged as preferred. The attacker continues 1299 to send such packets until the number of IP addresses associated with 1300 the attacker's HI crashes the system. Therefore, there SHOULD be a 1301 limit to the number of IP addresses that can be associated with any 1302 HI. Other forms of memory/computationally exhausting attacks via the 1303 HIP UPDATE packet are handled in the base HIP document 1304 [I-D.ietf-hip-rfc5201-bis]. 1306 A central server that has to deal with a large number of mobile 1307 clients may consider increasing the SA lifetimes to try to slow down 1308 the rate of rekeying UPDATEs or increasing the cookie difficulty to 1309 slow down the rate of attack-oriented connections. 1311 6.3. Mixed Deployment Environment 1313 We now assume an environment with both HIP and non-HIP aware hosts. 1314 Four cases exist. 1316 1. A HIP host redirects its connection onto a non-HIP host. The 1317 non-HIP host will drop the reachability packet, so this is not a 1318 threat unless the HIP host is a MitM that could somehow respond 1319 successfully to the reachability check. 1321 2. A non-HIP host attempts to redirect their connection onto a HIP 1322 host. This falls into IPv4 and IPv6 security concerns, which are 1323 outside the scope of this document. 1325 3. A non-HIP host attempts to steal a HIP host's session (assume 1326 that Secure Neighbor Discovery is not active for the following). 1327 The non-HIP host contacts the service that a HIP host has a 1328 connection with and then attempts to change its IP address to 1329 steal the HIP host's connection. What will happen in this case 1330 is implementation dependent but such a request should fail by 1331 being ignored or dropped. Even if the attack were successful, 1332 the HIP host could reclaim its connection via HIP. 1334 4. A HIP host attempts to steal a non-HIP host's session. A HIP 1335 host could spoof the non-HIP host's IP address during the base 1336 exchange or set the non-HIP host's IP address as its preferred 1337 address via an UPDATE. Other possibilities exist, but a simple 1338 solution is to prevent the use of HIP address check information 1339 to influence non-HIP sessions. 1341 7. IANA Considerations 1343 This document defines a LOCATOR_SET parameter for the Host Identity 1344 Protocol [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in 1345 Section 4 with a Type of 193. 1347 This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message 1348 Type as defined in the Host Identity Protocol specification 1350 [I-D.ietf-hip-rfc5201-bis]. This parameter is defined in Section 5.3 1351 with a value of 46. 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-rfc4423-bis] Moskowitz, R., "Host Identity Protocol 1369 Architecture", 1370 draft-ietf-hip-rfc4423-bis-03 (work in 1371 progress), September 2011. 1373 [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and 1374 T. Henderson, "Host Identity Protocol 1375 Version 2 (HIPv2)", 1376 draft-ietf-hip-rfc5201-bis-06 (work in 1377 progress), July 2011. 1379 [I-D.ietf-hip-rfc5202-bis] Jokela, P., Moskowitz, R., Nikander, P., 1380 and J. Melen, "Using the Encapsulating 1381 Security Payload (ESP) Transport Format 1382 with the Host Identity Protocol (HIP)", 1383 draft-ietf-hip-rfc5202-bis-00 (work in 1384 progress), September 2010. 1386 [I-D.ietf-hip-rfc5204-bis] Laganier, J. and L. Eggert, "Host 1387 Identity Protocol (HIP) Rendezvous 1388 Extension", draft-ietf-hip-rfc5204-bis-01 1389 (work in progress), March 2011. 1391 [RFC2119] Bradner, S., "Key words for use in RFCs 1392 to Indicate Requirement Levels", BCP 14, 1393 RFC 2119, March 1997. 1395 [RFC3484] Draves, R., "Default Address Selection 1396 for Internet Protocol version 6 (IPv6)", 1397 RFC 3484, February 2003. 1399 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 1400 Addressing Architecture", RFC 4291, 1401 February 2006. 1403 [RFC4303] Kent, S., "IP Encapsulating Security 1404 Payload (ESP)", RFC 4303, December 2005. 1406 9.2. Informative references 1408 [CBA-MIPv6] Vogt, C. and J. Arkko, "Credit-Based 1409 Authorization for Mobile IPv6 Early 1410 Binding Updates", Work in Progress, 1411 February 2005. 1413 [RFC4225] Nikander, P., Arkko, J., Aura, T., 1414 Montenegro, G., and E. Nordmark, "Mobile 1415 IP Version 6 Route Optimization Security 1416 Design Background", RFC 4225, 1417 December 2005. 1419 [SIMPLE-CBA] Vogt, C. and J. Arkko, "Credit-Based 1420 Authorization for Concurrent Reachability 1421 Verification", Work in Progress, 1422 February 2006. 1424 Appendix A. Document Revision History 1426 To be removed upon publication 1428 +----------+--------------------------------------------------------+ 1429 | Revision | Comments | 1430 +----------+--------------------------------------------------------+ 1431 | draft-00 | Initial version from RFC5206 xml (unchanged). | 1432 | draft-01 | Remove multihoming-specific text; no other changes. | 1433 | draft-02 | Update references to point to -bis drafts; no other | 1434 | | changes. | 1435 | draft-03 | issue 4: add make before break use case | 1436 | | issue 6: peer locator exposure policies | 1437 | | issue 10: rename LOCATOR to LOCATOR_SET | 1438 | | issue 14: use of UPDATE packet's IP address | 1439 +----------+--------------------------------------------------------+ 1441 Authors' Addresses 1443 Thomas R. Henderson (editor) 1444 The Boeing Company 1445 P.O. Box 3707 1446 Seattle, WA 1447 USA 1449 EMail: thomas.r.henderson@boeing.com 1451 Christian Vogt 1452 Ericsson Research NomadicLab 1453 Hirsalantie 11 1454 JORVAS FIN-02420 1455 FINLAND 1457 Phone: 1458 EMail: christian.vogt@ericsson.com 1460 Jari Arkko 1461 Ericsson Research NomadicLab 1462 JORVAS FIN-02420 1463 FINLAND 1465 Phone: +358 40 5079256 1466 EMail: jari.arkko@ericsson.com