idnits 2.17.1 draft-ietf-hip-multihoming-12.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 (October 10, 2016) is 2752 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 (-14) exists of draft-ietf-hip-rfc5206-bis-13 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 Intended status: Standards Track C. Vogt 5 Expires: April 13, 2017 Independent 6 J. Arkko 7 Ericsson 8 October 10, 2016 10 Host Multihoming with the Host Identity Protocol 11 draft-ietf-hip-multihoming-12 13 Abstract 15 This document defines host multihoming extensions to the Host 16 Identity Protocol (HIP), by leveraging protocol components defined 17 for host mobility. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 13, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 55 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 59 4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6 60 4.2.2. Multiple Security Associations . . . . . . . . . . . 6 61 4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7 62 4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9 63 4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10 64 4.2.6. Dual Host Multihoming . . . . . . . . . . . . . . . . 10 65 4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11 66 4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11 67 4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13 68 4.3. Interaction with Security Associations . . . . . . . . . 13 69 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14 71 5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16 72 5.3. Verifying Address Reachability . . . . . . . . . . . . . 18 73 5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 9.1. Normative references . . . . . . . . . . . . . . . . . . 21 79 9.2. Informative references . . . . . . . . . . . . . . . . . 22 80 Appendix A. Document Revision History . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 83 1. Introduction and Scope 85 The Host Identity Protocol [RFC7401] (HIP) supports an architecture 86 that decouples the transport layer (TCP, UDP, etc.) from the 87 internetworking layer (IPv4 and IPv6) by using public/private key 88 pairs, instead of IP addresses, as host identities. When a host uses 89 HIP, the overlying protocol sublayers (e.g., transport layer sockets 90 and Encapsulating Security Payload (ESP) Security Associations (SAs)) 91 are instead bound to representations of these host identities, and 92 the IP addresses are only used for packet forwarding. However, each 93 host must also know at least one IP address at which its peers are 94 reachable. Initially, these IP addresses are the ones used during 95 the HIP base exchange. 97 One consequence of such a decoupling is that new solutions to 98 network-layer mobility and host multihoming are possible. Basic host 99 mobility is defined in [I-D.ietf-hip-rfc5206-bis] and covers the case 100 in which a host has a single address and changes its network point- 101 of-attachment while desiring to preserve the HIP-enabled security 102 association. Host multihoming is somewhat of a dual case to host 103 mobility, in that a host may simultaneously have more than one 104 network point-of-attachment. There are potentially many variations 105 of host multihoming possible. [I-D.ietf-hip-rfc5206-bis] specifies 106 the format of the HIP parameter (LOCATOR_SET parameter) used to 107 convey IP addressing information between peers, the procedures for 108 sending and processing this parameter to enable basic host mobility, 109 and procedures for an address verification mechanism. The scope of 110 this document encompasses messaging and elements of procedure for 111 some basic host multihoming scenarios of interest. 113 Another variation of multihoming that has been heavily studied is 114 site multihoming. Solutions for host multihoming in multihomed IPv6 115 networks have been specified by the IETF shim6 working group. The 116 shim6 protocol [RFC5533] bears many architectural similarities to HIP 117 but there are differences in the security model and in the protocol. 119 While HIP can potentially be used with transports other than the ESP 120 transport format [RFC7402], this document largely assumes the use of 121 ESP and leaves other transport formats for further study. 123 Finally, making underlying IP multihoming transparent to the 124 transport layer has implications on the proper response of transport 125 congestion control, path MTU selection, and Quality of Service (QoS). 126 Transport-layer mobility triggers, and the proper transport response 127 to a HIP multihoming address change, are outside the scope of this 128 document. 130 This specification relies on implementing Section 4 (LOCATOR_SET 131 Parameter Format) and Section 5 (Processing Rules) of 132 [I-D.ietf-hip-rfc5206-bis] as a starting point for this 133 implementation. 135 2. Terminology and Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 The following terms used in this document are defined in 142 [I-D.ietf-hip-rfc5206-bis]: LOCATOR_SET, Locator, Address, Preferred 143 locator, and Credit Based Authorization. 145 3. Protocol Model 147 The protocol model for HIP support of host multihoming extends the 148 model for host mobility described in Section 3 of 149 [I-D.ietf-hip-rfc5206-bis]. This section only highlights the 150 differences. 152 In host multihoming, a host has multiple locators simultaneously 153 rather than sequentially, as in the case of mobility. By using the 154 LOCATOR_SET parameter defined in [I-D.ietf-hip-rfc5206-bis], a host 155 can inform its peers of additional (multiple) locators at which it 156 can be reached. When multiple locators are available and announced 157 to the peer, a host can designate a particular locator as a 158 "preferred" locator, meaning that the host prefers that its peer send 159 packets to the designated address before trying an alternative 160 address. Although this document defines a basic mechanism for 161 multihoming, it does not define all possible policies and procedures, 162 such as which locators to choose when more than one is available, the 163 operation of simultaneous mobility and multihoming, source address 164 selection policies (beyond those specified in [RFC6724]), and the 165 implications of multihoming on transport protocols. 167 4. Protocol Overview 169 In this section, we briefly introduce a number of usage scenarios for 170 HIP multihoming. These scenarios assume that HIP is being used with 171 the ESP transport [RFC7402], although other scenarios may be defined 172 in the future. To understand these usage scenarios, the reader 173 should be at least minimally familiar with the HIP protocol 174 specification [RFC7401], the use of the ESP transport format 175 [RFC7402], and the HIP mobility specification 176 [I-D.ietf-hip-rfc5206-bis]. However, for the (relatively) 177 uninitiated reader, it is most important to keep in mind that in HIP 178 the actual payload traffic is protected with ESP, and that the ESP 179 Security Parameter Index (SPI) acts as an index to the right host-to- 180 host context. 182 4.1. Background 184 The multihoming scenarios can be explained in contrast to the non- 185 multihoming case described in the base protocol specification. We 186 review the pertinent details here. In the base specification when 187 used with the ESP transport format, the HIP base exchange will set up 188 a single SA in each direction. The IP addresses associated with the 189 SAs are the same as those used to convey the HIP packets. For data 190 traffic, a security policy database (SPD) and security association 191 database (SAD) will likely exist, following the IPsec architecture. 192 One distinction between HIP and IPsec, however, is that the host IDs, 193 and not the IP addresses, are conceptually used as selectors in the 194 SPD. In the outbound direction, as a result of SPD processing, when 195 an outbound SA is selected, the correct IP destination address for 196 the peer must also be assigned. Therefore, outbound SAs are 197 conceptually associated with the peer IP address that must be used as 198 the destination IP address below the HIP layer. In the inbound 199 direction, the IP addresses may be used as selectors in the SAD to 200 look up the SA, but they are not strictly required; the ESP SPI may 201 be used alone. To summarize, in the non-multihoming case, there is 202 only one source IP address, one destination IP address, one inbound 203 SA, and one outbound SA. 205 The HIP readdressing protocol [I-D.ietf-hip-rfc5206-bis] is an 206 asymmetric protocol in which a mobile or multihomed host informs a 207 peer host about changes of IP addresses on affected SPIs. IP address 208 and ESP SPI information is carried in Locator data structures in a 209 HIP parameter called a LOCATOR_SET. The HIP mobility specification 210 [I-D.ietf-hip-rfc5206-bis] describes how the LOCATOR_SET is carried 211 in a HIP UPDATE packet. 213 To summarize the mobility elements of procedure, as background for 214 multihoming, the basic idea of host mobility is to communicate a 215 local IP address change to the peer when active HIP-maintained SAs 216 are in use. To do so, the IP address must be conveyed, any 217 association between the IP address and an inbound SA (via the SPI 218 index) may be conveyed, and protection against flooding attacks must 219 be ensured. The association of an IP address with an SPI is 220 performed by a Locator of type 1, which is a concatenation of an ESP 221 SPI with an IP address. 223 An address verification method is specified in 224 [I-D.ietf-hip-rfc5206-bis]. It is expected that addresses learned in 225 multihoming scenarios also are subject to the same verification 226 rules. The scenarios at times describe addresses as being in either 227 an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a 228 host, newly-learned addresses of the peer must be verified before put 229 into active service, and addresses removed by the peer are put into a 230 deprecated state. Under limited conditions described in 231 [I-D.ietf-hip-rfc5206-bis], an UNVERIFIED address may be used. 233 With this background, we next describe additional protocol to 234 facilitate scenarios in which one or both hosts have multiple IP 235 addresses available. Increasingly, this is the common case with 236 network-connected hosts on the Internet. 238 4.2. Usage Scenarios 240 4.2.1. Multiple Addresses 242 Hosts may have multiple IP addresses within different address 243 families (IPv4 and IPv6) and scopes available to support HIP 244 messaging and HIP-enabled SAs. The multiple addresses may be on a 245 single or multiple network interfaces. It is outside of the scope of 246 this document to specify how a host decides which of possibly 247 multiple addresses may be used to support a HIP association. Some IP 248 addresses may be held back from usage due to privacy, security, or 249 cost considerations. 251 When multiple IP addresses are shared with a peer, the procedures 252 described in the HIP mobility specification 253 [I-D.ietf-hip-rfc5206-bis] allow for a host to set a Preferred bit, 254 requesting that one of the multiple addresses be preferred for 255 control- or data-plane traffic. It is also permitted to leave the 256 Preferred bit unset for all addresses, allowing the peer to make 257 address selection decisions. 259 Hosts that use link-local addresses as source addresses in their HIP 260 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 261 provide a globally routable address either in the initial handshake 262 or via the LOCATOR_SET parameter. 264 To support mobility, as described in the HIP mobility specification 265 [I-D.ietf-hip-rfc5206-bis], the LOCATOR_SET may be sent in a HIP 266 UPDATE packet. To support multihoming, the LOCATOR_SET may also be 267 sent in R1, I2, or R2 packets defined in the HIP protocol 268 specification [RFC7401]. The reason to consider to send LOCATOR_SET 269 parameters in the base exchange packets is to convey all usable 270 addresses for fault-tolerance or load balancing considerations. 272 4.2.2. Multiple Security Associations 274 When multiple addresses are available between peer hosts, a question 275 that arises is whether to use one or multiple SAs. The intent of 276 this specification is to support different use cases but to leave the 277 policy decision to the hosts. 279 When one host has n addresses and the other host has m addresses, it 280 is possible to set up as many as (n * m) SAs in each direction. In 281 such a case, every combination of source and destination IP address 282 would have a unique SA, and the possibility of reordering of 283 datagrams on each SA will be lessened (ESP SAs may have an anti- 284 replay window [RFC4303] sensitive to reordering). However, the 285 downside to creating a mesh of SAs is the signaling overhead required 286 (for exchanging UPDATE messages conveying ESP_INFO parameters) and 287 the state maintenance required in the SPD/SAD. 289 For load balancing, when multiple paths are to be used in parallel, 290 it may make sense to create different SAs for different paths. In 291 this use case, while a full mesh of 2 * (n * m) SAs may not be 292 required, it may be beneficial to create one SA pair per load- 293 balanced path to avoid anti-replay window issues. 295 For fault tolerance, it is more likely that a single SA can be used 296 and multiple IP addresses associated with that SA, and the 297 alternative addresses used only upon failure detection of the 298 addresses in use. Techniques for path failure detection are outside 299 the scope of this specification. An implementation may use ICMP 300 interactions, reachability checks, or other means to detect the 301 failure of a locator. 303 In summary, whether and how a host decides to leverage additional 304 addresses in a load-balancing or fault-tolerant manner is outside the 305 scope of the specification (although the academic literature on 306 multipath TCP schedulers may provide guidance on how to design such a 307 policy). However, in general, this document recommends that for 308 fault tolerance, it is likely sufficient to use a single SA pair for 309 all addresses, and for load balancing, to support a different SA pair 310 for all active paths being balanced across. 312 4.2.3. Host Multihoming for Fault Tolerance 314 A (mobile or stationary) host may have more than one interface or 315 global address. The host may choose to notify the peer host of the 316 additional interface or address by using the LOCATOR_SET parameter. 317 The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, 318 or may be conveyed, after the base exchange completes in an UPDATE 319 packet. 321 When more than one locator is provided to the peer host, the host MAY 322 indicate which locator is preferred (the locator on which the host 323 prefers to receive traffic). By default, the address that a host 324 uses in the base exchange is its preferred locator (for the address 325 family and address scope in use during the base exchange) until 326 indicated otherwise. It may be the case that the host does not 327 express any preferred locators. 329 In the multihoming case, the sender may also have multiple valid 330 locators from which to source traffic. In practice, a HIP 331 association in a multihoming configuration may have both a preferred 332 peer locator and a preferred local locator. The host should try to 333 use the peer's preferred locator unless policy or other circumstances 334 prevent such usage. A preferred local locator may be overridden if 335 source address selection rules on the destination address (peer's 336 preferred locator) suggest the use of a different source address. 338 Although the protocol may allow for configurations in which there is 339 an asymmetric number of SAs between the hosts (e.g., one host has two 340 interfaces and two inbound SAs, while the peer has one interface and 341 one inbound SA), it is suggested that inbound and outbound SAs be 342 created pairwise between hosts. When an ESP_INFO arrives to rekey a 343 particular outbound SA, the corresponding inbound SA should be also 344 rekeyed at that time. Section 4.3 discusses the interaction between 345 addresses and security associations in more detail. 347 Consider the case of two hosts, one single-homed and one multihomed. 348 The multihomed host may decide to inform the single-homed host about 349 its other address(es). It may choose to do so as follows. 351 If the multihomed host wishes to convey the additional address(es) 352 for fault tolerance, it should include all of its addresses in 353 Locator records, indicating the Traffic Type, Locator Type, and 354 Preferred Locator for each address. If it wishes to bind any 355 particular address to an existing SPI, it may do so by using a 356 Locator of Type 1 as specified in the HIP mobility specification 357 [I-D.ietf-hip-rfc5206-bis]. It does not need to rekey the existing 358 SA or request additional SAs at this time. 360 Figure 1 illustrates this scenario. Note that the conventions for 361 message parameter notations in figures (use of parentheses and 362 brackets) is defined in Section 2.2 of [RFC7401]. 364 Multi-homed Host Peer Host 366 UPDATE(LOCATOR_SET, SEQ) 367 -----------------------------------> 368 UPDATE(ACK) 369 <----------------------------------- 371 Figure 1: Basic Multihoming Scenario 373 In this scenario, the peer host associates the multiple addresses 374 with the SA pair between it and the multihomed host. It may also 375 undergo address verification procedures to transition the addresses 376 to ACTIVE state. For inbound data traffic, it may choose to use the 377 addresses along with the SPI as selectors. For outbound data 378 traffic, it must choose among the available addresses of the 379 multihomed host, considering the state of address verification 380 [I-D.ietf-hip-rfc5206-bis] of each address, and also considering 381 available information about whether an address is in a working state. 383 4.2.4. Host Multihoming for Load Balancing 385 A multihomed host may decide to set up new SA pairs corresponding to 386 new addresses, for the purpose of load balancing. The decision to 387 load balance and the mechanism for splitting load across multiple SAs 388 is out of scope of this document. The scenario can be supported by 389 sending the LOCATOR_SET parameter with one or more ESP_INFO 390 parameters to initiate new ESP SAs. To do this, the multihomed host 391 sends a LOCATOR_SET with an ESP_INFO, indicating the request for a 392 new SA by setting the OLD SPI value to zero, and the NEW SPI value to 393 the newly created incoming SPI. A Locator Type of "1" is used to 394 associate the new address with the new SPI. The LOCATOR_SET 395 parameter also contains a second Type "1" locator, that of the 396 original address and SPI. To simplify parameter processing and avoid 397 explicit protocol extensions to remove locators, each LOCATOR_SET 398 parameter MUST list all locators in use on a connection (a complete 399 listing of inbound locators and SPIs for the host). The multihomed 400 host waits for a corresponding ESP_INFO (new outbound SA) from the 401 peer and an ACK of its own UPDATE. As in the mobility case, the peer 402 host must perform an address verification before actively using the 403 new address. 405 Figure 2 illustrates this scenario. 407 Multi-homed Host Peer Host 409 UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN]) 410 -----------------------------------> 411 UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 412 <----------------------------------- 413 UPDATE(ACK, ECHO_RESPONSE) 414 -----------------------------------> 416 Figure 2: Host Multihoming for Load Balancing 418 In multihoming scenarios, it is important that hosts receiving 419 UPDATEs associate them correctly with the destination address used in 420 the packet carrying the UPDATE. When processing inbound LOCATOR_SETs 421 that establish new security associations on an interface with 422 multiple addresses, a host uses the destination address of the UPDATE 423 containing the LOCATOR_SET as the local address to which the 424 LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may 425 send UPDATEs with the same (locator) IP address to different peer 426 addresses -- this has the effect of creating multiple inbound SAs 427 implicitly affiliated with different peer source addresses. 429 4.2.5. Site Multihoming 431 A host may have an interface that has multiple globally routable IP 432 addresses. Such a situation may be a result of the site having 433 multiple upper Internet Service Providers, or just because the site 434 provides all hosts with both IPv4 and IPv6 addresses. The host 435 should stay reachable at all or any subset of the currently available 436 global routable addresses, independent of how they are provided. 438 This case is handled the same as if there were different IP 439 addresses, described above in Section 4.2.3 and Section 4.2.4. Note 440 that a single interface may have addresses corresponding to site 441 multihoming while the host itself may also have multiple network 442 interfaces. 444 Note that a host may be multihomed and mobile simultaneously, and 445 that a multihomed host may want to protect the location of some of 446 its interfaces while revealing the real IP address of some others. 448 This document does not presently additional site multihoming 449 extensions to HIP; such extensions are for further study. 451 4.2.6. Dual Host Multihoming 453 Consider the case in which both hosts are multihomed and would like 454 to notify the peer of an additional address after the base exchange 455 completes. It may be the case that both hosts choose to simply 456 announce the second address in a LOCATOR_SET parameter using an 457 UPDATE message exchange. It may also be the case that one or both 458 hosts decide to ask for new SA pairs to be created using the newly 459 announced address. In the case that both hosts request this, the 460 result will be a full mesh of SAs as depicted in Figure 3. In such a 461 scenario, consider that host1, which used address addr1a in the base 462 exchange to set up SPI1a and SPI2a, wants to add address addr1b. It 463 would send an UPDATE with LOCATOR_SET (containing the address addr1b) 464 to host2, using destination address addr2a, and a new ESP_INFO, and a 465 new set of SPIs would be added between hosts 1 and 2 (call them SPI1b 466 and SPI2b; not shown in the figure). Next, consider host2 deciding 467 to add addr2b to the relationship. Host2 must select one of host1's 468 addresses towards which to initiate an UPDATE. It may choose to 469 initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send 470 to both, then a full mesh (four SA pairs) of SAs would exist between 471 the two hosts. This is the most general case; the protocol is 472 flexible enough to accommodate this choice. 474 -<- SPI1a -- -- SPI2a ->- 475 host1 < > addr1a <---> addr2a < > host2 476 ->- SPI2a -- -- SPI1a -<- 478 addr1b <---> addr2a (second SA pair) 479 addr1a <---> addr2b (third SA pair) 480 addr1b <---> addr2b (fourth SA pair) 482 Figure 3: Dual Multihoming Case in which Each Host Uses LOCATOR_SET 483 to Add a Second Address 485 4.2.7. Combined Mobility and Multihoming 487 Mobile hosts may be simultaneously mobile and multihomed, i.e., have 488 multiple mobile interfaces. Furthermore, if the interfaces use 489 different access technologies, it is fairly likely that one of the 490 interfaces may appear stable (retain its current IP address) while 491 some other(s) may experience mobility (undergo IP address change). 493 The use of LOCATOR_SET plus ESP_INFO should be flexible enough to 494 handle most such scenarios, although more complicated scenarios have 495 not been studied so far. 497 4.2.8. Initiating the Protocol in R1, I2, or R2 499 A Responder host MAY include a LOCATOR_SET parameter in the R1 packet 500 that it sends to the Initiator. This parameter MUST be protected by 501 the R1 signature. If the R1 packet contains LOCATOR_SET parameters 502 with a new Preferred locator, the Initiator SHOULD directly set the 503 new Preferred locator to status ACTIVE without performing address 504 verification first, and MUST send the I2 packet to the new Preferred 505 locator. The I1 destination address and the new Preferred locator 506 may be identical. All new non-preferred locators must still undergo 507 address verification once the base exchange completes. It is also 508 possible for the host to send the LOCATOR_SET without any Preferred 509 bits set, in which case the exchange will continue as normal and the 510 newly-learned addresses will be in an UNVERIFIED state at the 511 initiator. 513 Initiator Responder 515 R1 with LOCATOR_SET 516 <----------------------------------- 517 record additional addresses 518 change responder address 519 I2 sent to newly indicated preferred address 520 -----------------------------------> 521 (process normally) 522 R2 523 <----------------------------------- 524 (process normally, later verification of non-preferred locators) 526 Figure 4: LOCATOR_SET Inclusion in R1 528 An Initiator MAY include one or more LOCATOR_SET parameters in the I2 529 packet, independent of whether or not there was a LOCATOR_SET 530 parameter in the R1. These parameters MUST be protected by the I2 531 signature. Even if the I2 packet contains LOCATOR_SET parameters, 532 the Responder MUST still send the R2 packet to the source address of 533 the I2. The new Preferred locator, if set, SHOULD be identical to 534 the I2 source address. If the I2 packet contains LOCATOR_SET 535 parameters, all new locators must undergo address verification as 536 usual, and the ESP traffic that subsequently follows should use the 537 Preferred locator. 539 Initiator Responder 541 I2 with LOCATOR_SET 542 -----------------------------------> 543 (process normally) 544 record additional addresses 545 R2 sent to source address of I2 546 <----------------------------------- 547 (process normally) 549 Figure 5: LOCATOR_SET Inclusion in I2 551 The I1 and I2 may be arriving from different source addresses if the 552 LOCATOR_SET parameter is present in R1. In this case, 553 implementations simultaneously using multiple pre-created R1s, 554 indexed by Initiator IP addresses, may inadvertently fail the puzzle 555 solution of I2 packets due to a perceived puzzle mismatch. See, for 556 instance, the example in Appendix A of [RFC7401]. As a solution, the 557 Responder's puzzle indexing mechanism must be flexible enough to 558 accommodate the situation when R1 includes a LOCATOR_SET parameter. 560 Finally, the R2 may be used to carry the LOCATOR_SET parameter. In 561 this case, the LOCATOR_SET is covered by the HIP_MAC_2 and 562 HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have 563 some advantages when a host prefers not to divulge additional 564 locators until after the I2 is successfully processed. 566 When the LOCATOR_SET parameter is sent in an UPDATE packet, then the 567 receiver will respond with an UPDATE acknowledgment. When the 568 LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base 569 exchange retransmission mechanism will confirm its successful 570 delivery. 572 4.2.9. Using LOCATOR_SETs across Addressing Realms 574 It is possible for HIP associations to use these mechanisms to 575 migrate their HIP associations and security associations from 576 addresses in the IPv4 addressing realm to IPv6 or vice versa. It may 577 be possible for a state to arise in which both hosts are only using 578 locators in different addressing realms, but in such a case, some 579 type of mechanism for interworking between the different realms must 580 be employed; such techniques are outside the scope of the present 581 text. 583 4.3. Interaction with Security Associations 585 A host may establish any number of security associations (or SPIs) 586 with a peer. The main purpose of having multiple SPIs with a peer is 587 to group the addresses into collections that are likely to experience 588 fate sharing, or to perform load balancing. 590 A basic property of HIP SAs is that the inbound IP address is not 591 used to lookup the incoming SA. However, the use of different source 592 and destination addresses typically leads to different paths, with 593 different latencies in the network, and if packets were to arrive via 594 an arbitrary destination IP address (or path) for a given SPI, the 595 reordering due to different latencies may cause some packets to fall 596 outside of the ESP anti-replay window. For this reason, HIP provides 597 a mechanism to affiliate destination addresses with inbound SPIs, 598 when there is a concern that anti-replay windows might be violated. 599 In this sense, we can say that a given inbound SPI has an "affinity" 600 for certain inbound IP addresses, and this affinity is communicated 601 to the peer host. Each physical interface SHOULD have a separate SA, 602 unless the ESP anti-replay window is extended or disabled. 604 Moreover, even when the destination addresses used for a particular 605 SPI are held constant, the use of different source interfaces may 606 also cause packets to fall outside of the ESP anti-replay window, 607 since the path traversed is often affected by the source address or 608 interface used. A host has no way to influence the source interface 609 on which a peer sends its packets on a given SPI. A host SHOULD 610 consistently use the same source interface and address when sending 611 to a particular destination IP address and SPI. For this reason, a 612 host may find it useful to change its SPI or at least reset its ESP 613 anti-replay window when the peer host readdresses. 615 5. Processing Rules 617 Basic processing rules for the LOCATOR_SET parameter are specified in 618 [I-D.ietf-hip-rfc5206-bis]. This document focuses on multihoming- 619 specific rules. 621 5.1. Sending LOCATOR_SETs 623 The decision of when to send a LOCATOR_SET, and which addresses to 624 include, is a local policy issue. [I-D.ietf-hip-rfc5206-bis] 625 recommends that a host "send a LOCATOR_SET whenever it recognizes a 626 change of its IP addresses in use on an active HIP association, and 627 (when it) assumes that the change is going to last at least for a few 628 seconds." It is possible to delay the exposure of additional 629 locators to the peer, and to send data from previously unannounced 630 locators, as might arise in certain mobility or multihoming 631 situations. 633 When a host decides to inform its peers about changes in its IP 634 addresses, it has to decide how to group the various addresses with 635 SPIs. If hosts are deployed in an operational environment in which 636 HIP-aware NATs and firewalls (that may perform parameter inspection) 637 exist, and different such devices may exist on different paths, hosts 638 may take that knowledge into consideration about how addresses are 639 grouped, and may send the same LOCATOR_SET in separate UPDATEs on the 640 different paths. However, more detailed guidelines about how to 641 operate in the presence of such HIP-aware NATs and firewalls is a 642 topic for further study. Since each SPI is associated with a 643 different Security Association, the grouping policy may also be based 644 on ESP anti-replay protection considerations. In the typical case, 645 simply basing the grouping on actual kernel level physical and 646 logical interfaces may be the best policy. Grouping policy is 647 outside of the scope of this document. 649 Locators corresponding to tunnel interfaces (e.g. IPsec tunnel 650 interfaces or Mobile IP home addresses) or other virtual interfaces 651 MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid 652 announcing such locators as preferred locators if more direct paths 653 may be obtained by instead preferring locators from non-tunneling 654 interfaces if such locators provide a more direct path to the HIP 655 peer. 657 [I-D.ietf-hip-rfc5206-bis] specifies that hosts MUST NOT announce 658 broadcast or multicast addresses in LOCATOR_SETs. Link-local 659 addresses MAY be announced to peers that are known to be neighbors on 660 the same link, such as when the IP destination address of a peer is 661 also link-local. The announcement of link-local addresses in this 662 case is a policy decision; link-local addresses used as Preferred 663 locators will create reachability problems when the host moves to 664 another link. In any case, link-local addresses MUST NOT be 665 announced to a peer unless that peer is known to be on the same link. 667 Once the host has decided on the groups and assignment of addresses 668 to the SPIs, it creates a LOCATOR_SET parameter that serves as a 669 complete representation of the addresses and associated SPIs intended 670 for active use. We now describe a few cases introduced in Section 4. 671 We assume that the Traffic Type for each locator is set to "0" (other 672 values for Traffic Type may be specified in documents that separate 673 the HIP control plane from data plane traffic). Other mobility and 674 multihoming cases are possible but are left for further 675 experimentation. 677 1. Host multihoming (addition of an address). We only describe the 678 simple case of adding an additional address to a (previously) 679 single-homed, non-mobile host. The host MAY choose to simply 680 announce this address to the peer, for fault tolerance. To do 681 this, the multihomed host creates a LOCATOR_SET parameter 682 including the existing address and SPI as a Type "1" Locator, and 683 the new address as a Type "0" Locator. The host sends this in an 684 UPDATE message with SEQ parameter, which is acknowledged by the 685 peer. 687 2. The host MAY set up a new SA pair between this new address and an 688 address of the peer host. To do this, the multihomed host 689 creates a new inbound SA and creates a new SPI. For the outgoing 690 UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI 691 field of "0", a NEW SPI field corresponding to the new SPI, and a 692 KEYMAT Index as selected by local policy. The host adds to the 693 UPDATE message a LOCATOR_SET with two Type "1" Locators: the 694 original address and SPI active on the association, and the new 695 address and new SPI being added (with the SPI matching the NEW 696 SPI contained in the ESP_INFO). The Preferred bit SHOULD be set 697 depending on the policy to tell the peer host which of the two 698 locators is preferred. The UPDATE also contains a SEQ parameter 699 and optionally a DIFFIE_HELLMAN parameter, and follows rekeying 700 procedures with respect to this new address. The UPDATE message 701 SHOULD be sent to the peer's Preferred address with a source 702 address corresponding to the new locator. 704 The sending of multiple LOCATOR_SETs is unsupported. Note that the 705 inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" 706 locators since no SAs are set up at that point. 708 5.2. Handling Received LOCATOR_SETs 710 A host SHOULD be prepared to receive a LOCATOR_SET parameter in the 711 following HIP packets: R1, I2, R2, and UPDATE. 713 This document describes sending both ESP_INFO and LOCATOR_SET 714 parameters in an UPDATE. The ESP_INFO parameter is included when 715 there is a need to rekey or key a new SPI, and can otherwise be 716 included for the possible benefit of HIP-aware middleboxes. The 717 LOCATOR_SET parameter contains a complete map of the locators that 718 the host wishes to make or keep active for the HIP association. 720 In general, the processing of a LOCATOR_SET depends upon the packet 721 type in which it is included. Here, we describe only the case in 722 which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are 723 sent in an UPDATE message; other cases are for further study. The 724 steps below cover each of the cases described in Section 5.1. 726 The processing of ESP_INFO and LOCATOR_SET parameters is intended to 727 be modular and support future generalization to the inclusion of 728 multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host 729 SHOULD first process the ESP_INFO before the LOCATOR_SET, since the 730 ESP_INFO may contain a new SPI value mapped to an existing SPI, while 731 a Type "1" locator will only contain a reference to the new SPI. 733 When a host receives a validated HIP UPDATE with a LOCATOR_SET and 734 ESP_INFO parameter, it processes the ESP_INFO as follows. The 735 ESP_INFO parameter indicates whether an SA is being rekeyed, created, 736 deprecated, or just identified for the benefit of middleboxes. The 737 host examines the OLD SPI and NEW SPI values in the ESP_INFO 738 parameter: 740 1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both 741 correspond to an existing SPI, the ESP_INFO is gratuitous 742 (provided for middleboxes) and no rekeying is necessary. 744 2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW 745 SPI is a different non-zero value, the existing SA is being 746 rekeyed and the host follows HIP ESP rekeying procedures by 747 creating a new outbound SA with an SPI corresponding to the NEW 748 SPI, with no addresses bound to this SPI. Note that locators in 749 the LOCATOR_SET parameter will reference this new SPI instead of 750 the old SPI. 752 3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new 753 non-zero value, then a new SA is being requested by the peer. 754 This case is also treated like a rekeying event; the receiving 755 host must create a new SA and respond with an UPDATE ACK. 757 4. (deprecating the SA) If the OLD SPI indicates an existing SPI and 758 the NEW SPI is zero, the SA is being deprecated and all locators 759 uniquely bound to the SPI are put into the DEPRECATED state. 761 If none of the above cases apply, a protocol error has occurred and 762 the processing of the UPDATE is stopped. 764 Next, the locators in the LOCATOR_SET parameter are processed. For 765 each locator listed in the LOCATOR_SET parameter, check that the 766 address therein is a legal unicast or anycast address. That is, the 767 address MUST NOT be a broadcast or multicast address. Note that some 768 implementations MAY accept addresses that indicate the local host, 769 since it may be allowed that the host runs HIP with itself. 771 For each Type "1" address listed in the LOCATOR_SET parameter, the 772 host checks whether the address is already bound to the SPI 773 indicated. If the address is already bound, its lifetime is updated. 774 If the status of the address is DEPRECATED, the status is changed to 775 UNVERIFIED. If the address is not already bound, the address is 776 added, and its status is set to UNVERIFIED. If there exist remaining 777 addresses corresponding to the SPI that were NOT listed in the 778 LOCATOR_SET parameter, the host sets the status of such addresses to 779 DEPRECATED. 781 For each Type "0" address listed in the LOCATOR_SET parameter, if the 782 status of the address is DEPRECATED, or the address was not 783 previously known, the status is changed to UNVERIFIED. The host MAY 784 choose to associate this address with one or more SAs. The 785 association with different SAs is a local policy decision, unless the 786 peer has indicated that the address is Preferred, in which case the 787 address should be put into use on a SA that is prioritized in the 788 security policy database. 790 As a result, at the end of processing, the addresses listed in the 791 LOCATOR_SET parameter have either a state of UNVERIFIED or ACTIVE, 792 and any old addresses on the old SA not listed in the LOCATOR_SET 793 parameter have a state of DEPRECATED. 795 Once the host has processed the locators, if the LOCATOR_SET 796 parameter contains a new Preferred locator, the host SHOULD initiate 797 a change of the Preferred locator. This requires that the host first 798 verifies reachability of the associated address, and only then 799 changes the Preferred locator; see Section 5.4. 801 If a host receives a locator with an unsupported Locator Type, and 802 when such a locator is also declared to be the Preferred locator for 803 the peer, the host SHOULD send a NOTIFY error with a Notify Message 804 Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field 805 containing the locator(s) that the receiver failed to process. 806 Otherwise, a host MAY send a NOTIFY error if a (non-preferred) 807 locator with an unsupported Locator Type is received in a LOCATOR_SET 808 parameter. 810 5.3. Verifying Address Reachability 812 Address verification is defined in [I-D.ietf-hip-rfc5206-bis]. 814 When address verification is in progress for a new Preferred locator, 815 the host SHOULD select a different locator listed as ACTIVE, if one 816 such locator is available, to continue communications until address 817 verification completes. Alternatively, the host MAY use the new 818 Preferred locator while in UNVERIFIED status to the extent Credit- 819 Based Authorization permits. Credit-Based Authorization is explained 820 in [I-D.ietf-hip-rfc5206-bis]. Once address verification succeeds, 821 the status of the new Preferred locator changes to ACTIVE. 823 5.4. Changing the Preferred Locator 825 A host MAY want to change the Preferred outgoing locator for 826 different reasons, e.g., because traffic information or ICMP error 827 messages indicate that the currently used preferred address may have 828 become unreachable. Another reason may be due to receiving a 829 LOCATOR_SET parameter that has the "P" bit set. 831 To change the Preferred locator, the host initiates the following 832 procedure: 834 1. If the new Preferred locator has ACTIVE status, the Preferred 835 locator is changed and the procedure succeeds. 837 2. If the new Preferred locator has UNVERIFIED status, the host 838 starts to verify its reachability. The host SHOULD use a 839 different locator listed as ACTIVE until address verification 840 completes if one such locator is available. Alternatively, the 841 host MAY use the new Preferred locator, even though in UNVERIFIED 842 status, to the extent Credit-Based Authorization permits. Once 843 address verification succeeds, the status of the new Preferred 844 locator changes to ACTIVE and its use is no longer governed by 845 Credit-Based Authorization. 847 3. If the peer host has not indicated a preference for any address, 848 then the host picks one of the peer's ACTIVE addresses randomly 849 or according to policy. This case may arise if, for example, 850 ICMP error messages that deprecate the Preferred locator arrive, 851 but the peer has not yet indicated a new Preferred locator. 853 4. If the new Preferred locator has DEPRECATED status and there is 854 at least one non-deprecated address, the host selects one of the 855 non-deprecated addresses as a new Preferred locator and 856 continues. If the selected address is UNVERIFIED, the address 857 verification procedure described above will apply. 859 6. Security Considerations 861 This document extends the scope of host mobility solutions defined in 862 [I-D.ietf-hip-rfc5206-bis] to include also host multihoming, and as a 863 result, many of the same security considerations for mobility also 864 pertain to multihoming. In particular, [I-D.ietf-hip-rfc5206-bis] 865 describes how HIP host mobility is resistant to different types of 866 impersonation attacks and DoS attacks. 868 The security considerations for this document are similar to those of 869 [I-D.ietf-hip-rfc5206-bis] because the strong authentication 870 capabilities for mobility also carry over to end-host multihoming. 871 [RFC4218] provides a threat analysis for IPv6 multihoming, and the 872 remainder of this section first describes how HIP host multihoming 873 addresses those previously described threats, and then discusses some 874 additional security considerations. 876 The high-level threats discussed in [RFC4218] involve redirection 877 attacks for the purposes of packet recording, data manipulation, and 878 availability. There are a few types of attackers to consider: on- 879 path attackers, off-path attackers, and malicious hosts. 881 [RFC4218] also makes the comment that in identifier/locator split 882 solutions such as HIP, application security mechanisms should be tied 883 to the identifier, not the locator, and attacks on the identifier 884 mechanism and on the mechanism binding locators to the identifier are 885 of concern. This document does not consider the former issue 886 (application layer security bindings) to be within scope. The latter 887 issue (locator bindings to identifier) is directly addressed by the 888 cryptographic protections of the HIP protocol, in that locators 889 associated to an identifier are listed in HIP packets that are signed 890 using the identifier key. 892 Section 3.1 of [RFC4218] lists several classes of security 893 configurations in use in the Internet. HIP maps to the fourth 894 (strong identifier) and fifth ("leap-of-faith") categories, the 895 latter being associated with the optional opportunistic mode of HIP 896 operation. The remainder of Section 3 describe existing security 897 problems in the Internet, and comments that the goal of a multihoming 898 solution is not to solve them specifically but rather not to make any 899 of them worse. HIP multihoming should not increase the severity of 900 the identified risks. One concern for both HIP mobility and 901 multihoming is the susceptibility of the mechanisms to misuse for 902 flooding based redirections due to a malicious host. The mechanisms 903 described in [I-D.ietf-hip-rfc5206-bis] for address verification are 904 important in this regard. 906 Regarding the new types of threats introduced by multihoming 907 (Section 4 of [RFC4218]), HIP multihoming should not introduce new 908 concerns. Classic and premeditated redirection are prevented by the 909 strong authentication in HIP messages. Third-party denial-of-service 910 attacks are prevented by the address verification mechanism. Replay 911 attacks can be avoided via use of replay protection in Encapsulating 912 Security Payload (ESP) Security Associations (SAs). In addition, 913 accepting packets from unknown locators is protected by either the 914 strong authentication in the HIP control packets, or by the ESP-based 915 encryption in use for data packets. 917 The HIP mechanisms are designed to limit the ability to introduce DoS 918 on the mechanisms themselves (Section 7 of [RFC4218]). Care is taken 919 in the HIP base exchange to avoid creating state or performing much 920 work before hosts can authenticate one another. A malicious host 921 involved in HIP multihoming with another host might attempt to misuse 922 the mechanisms for multihoming by, for instance, increasing the state 923 required or inducing a resource limitation attack by sending too many 924 candidate locators to the peer host. Therefore, implementations 925 supporting the multihoming extensions should consider to avoid 926 accepting large numbers of peer locators, and to rate limit any 927 UPDATE messages being exchanged. 929 The exposure of a host's IP addresses through HIP mobility and 930 multihoming extensions may raise the following privacy concern. The 931 administrator of a host may be trying to hide its location in some 932 context through the use of a VPN or other virtual interfaces. 933 Similar privacy issues also arise in other frameworks such as WebRTC 934 and are not specific to HIP. Implementations SHOULD provide a 935 mechanism to allow the host administrator to block the exposure of 936 selected addresses or address ranges. 938 Finally, some implementations of VPN tunneling have experienced 939 instances of 'leakage' of flows that were intended to have been 940 protected by a security tunnel but are instead sent in the clear, 941 perhaps because some of the addresses used fall outside of the range 942 of addresses configured for the tunnel in the security policy or 943 association database. Implementers are advised to take steps to 944 ensure that the usage of multiple addresses between hosts does not 945 cause accidental leakage of some data session traffic outside of the 946 ESP-protected envelope. 948 7. IANA Considerations 950 This document has no requests for IANA actions. 952 8. Authors and Acknowledgments 954 This document contains content that was originally included in 955 RFC5206. Pekka Nikander and Jari Arkko originated RFC5206, and 956 Christian Vogt and Thomas Henderson (editor) later joined as co- 957 authors. Also in RFC5206, Greg Perkins contributed the initial draft 958 of the security section, and Petri Jokela was a co-author of the 959 initial individual submission. 961 The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan 962 Melen for many improvements to the document. Concepts from a paper 963 on host multihoming across address families, by Samu Varjonen, Miika 964 Komu, and Andrei Gurtov, contributed to this revised version. 966 9. References 968 9.1. Normative references 970 [I-D.ietf-hip-rfc5206-bis] 971 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 972 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-13 973 (work in progress), September 2016. 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, 977 DOI 10.17487/RFC2119, March 1997, 978 . 980 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 981 "Default Address Selection for Internet Protocol Version 6 982 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 983 . 985 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 986 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 987 RFC 7401, DOI 10.17487/RFC7401, April 2015, 988 . 990 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 991 Encapsulating Security Payload (ESP) Transport Format with 992 the Host Identity Protocol (HIP)", RFC 7402, 993 DOI 10.17487/RFC7402, April 2015, 994 . 996 9.2. Informative references 998 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 999 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 1000 October 2005, . 1002 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1003 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1004 . 1006 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1007 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1008 June 2009, . 1010 Appendix A. Document Revision History 1012 To be removed upon publication 1014 +----------+--------------------------------------------------------+ 1015 | Revision | Comments | 1016 +----------+--------------------------------------------------------+ 1017 | draft-00 | Initial version with multihoming text imported from | 1018 | | RFC5206. | 1019 | | | 1020 | draft-01 | Document refresh; no other changes. | 1021 | | | 1022 | draft-02 | Document refresh; no other changes. | 1023 | | | 1024 | draft-03 | Document refresh; no other changes. | 1025 | | | 1026 | draft-04 | Document refresh; no other changes. | 1027 | | | 1028 | draft-05 | Move remaining multihoming material from RFC5206-bis | 1029 | | to this document | 1030 | | | 1031 | | Update lingering references to LOCATOR parameter to | 1032 | | LOCATOR_SET | 1033 | | | 1034 | draft-06 | Document refresh with updated references. | 1035 | | | 1036 | draft-07 | Document refresh; no other changes. | 1037 | | | 1038 | draft-08 | issues 3 and 11: Address complaints of complexity due | 1039 | | to full mesh of SAs for multihoming. | 1040 | | | 1041 | | issue 5: Improve draft based on recommendations for | 1042 | | cross-family handovers in paper by Varjonen et. al. | 1043 | | | 1044 | | issue 7: Clarify and distinguish between load | 1045 | | balancing and fault tolerance use cases. | 1046 | | | 1047 | draft-09 | Update author affiliations, IPR boilerplate to | 1048 | | trust200902, and one stale reference. | 1049 | | | 1050 | draft-10 | Improve security considerations section by reviewing | 1051 | | RFC 4218. | 1052 | | | 1053 | | Clarified comment about applicability of shim6. | 1054 | | | 1055 | draft-11 | Editorial improvements based on last call comments. | 1056 | | | 1057 | draft-12 | Added section about locator privacy concerns to the | 1058 | | Security Considerations section. | 1059 | | | 1060 | | Added section about relationship to split tunnel | 1061 | | issues to the Security Considerations section. | 1062 | | | 1063 | | Editorial improvements based on last call comments. | 1064 +----------+--------------------------------------------------------+ 1066 Authors' Addresses 1068 Thomas R. Henderson (editor) 1069 University of Washington 1070 Campus Box 352500 1071 Seattle, WA 1072 USA 1074 EMail: tomhend@u.washington.edu 1076 Christian Vogt 1077 Independent 1078 3473 North First Street 1079 San Jose, CA 95134 1080 USA 1082 EMail: mail@christianvogt.net 1084 Jari Arkko 1085 Ericsson 1086 JORVAS FIN-02420 1087 FINLAND 1089 Phone: +358 40 5079256 1090 EMail: jari.arkko@piuha.net