idnits 2.17.1 draft-ietf-hip-mm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1144. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2004) is 7131 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: '5' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1033, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-03) exists of draft-iab-sec-cons-00 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Nikander 2 Internet-Draft J. Arkko 3 Expires: April 17, 2005 Ericsson Research Nomadic Lab 4 T. Henderson 5 The Boeing Company 6 October 17, 2004 8 End-Host Mobility and Multi-Homing with Host Identity Protocol 9 draft-ietf-hip-mm-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 17, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document specifies basic end-host mobility and multi-homing 45 mechanisms for the Host Identity Protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions used in this document . . . . . . . . . . . . . . 5 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Overview of HIP basic mobility and multi-homing 53 functionality . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4.1 Informing the peer about multiple or changed 55 address(es) . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.2 Address verification . . . . . . . . . . . . . . . . . . . 9 57 4.3 Preferred address . . . . . . . . . . . . . . . . . . . . 10 58 4.4 Address data structure and status . . . . . . . . . . . . 11 59 5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12 60 5.1 Mobility with single SA pair . . . . . . . . . . . . . . . 12 61 5.2 Host multihoming . . . . . . . . . . . . . . . . . . . . . 14 62 5.3 Site multi-homing . . . . . . . . . . . . . . . . . . . . 16 63 5.4 Dual host multi-homing . . . . . . . . . . . . . . . . . . 16 64 5.5 Combined mobility and multi-homing . . . . . . . . . . . . 17 65 5.6 Network renumbering . . . . . . . . . . . . . . . . . . . 17 66 5.7 Initiating the protocol in R1 or I2 . . . . . . . . . . . 17 67 6. Parameter and packet formats . . . . . . . . . . . . . . . . . 19 68 6.1 REA parameter . . . . . . . . . . . . . . . . . . . . . . 19 69 6.2 UPDATE packet with included REA . . . . . . . . . . . . . 20 70 7. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 21 71 7.1 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . 21 72 7.2 Handling received REAs . . . . . . . . . . . . . . . . . . 22 73 7.3 Verifying address reachability . . . . . . . . . . . . . . 23 74 7.4 Changing the preferred address . . . . . . . . . . . . . . 24 75 8. Policy considerations . . . . . . . . . . . . . . . . . . . . 25 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 80 12.1 Normative references . . . . . . . . . . . . . . . . . . . . 29 81 12.2 Informative references . . . . . . . . . . . . . . . . . . . 29 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 83 A. Changes from previous versions . . . . . . . . . . . . . . . . 31 84 A.1 From nikander-hip-mm-00 to nikander-hip-mm-01 . . . . . . 31 85 A.2 From nikander-hip-mm-01 to nikander-hip-mm-02 . . . . . . 31 86 A.3 From -02 to draft-ietf-hip-mm-00 . . . . . . . . . . . . . 31 87 B. Implementation experiences . . . . . . . . . . . . . . . . . . 33 88 Intellectual Property and Copyright Statements . . . . . . . . 34 90 1. Introduction 92 This document specifies an extension to the Host Identity Protocol 93 [3] (HIP). The extension provides a means for hosts to keep their 94 communications on-going while having multiple IP addresses, either at 95 the same time or one after another. That is, the extension provides 96 basic end-to-end support for multi-homing, mobility, and simultaneous 97 multi-homing and mobility. Additionally, the extension allows 98 communications to continue even when multi-homing or mobility causes 99 a change of the IP version that is available in the network; that is, 100 if one of the communicating hosts has both IPv4 and IPv6 101 connectivity, either directly or through a proxy, the other host can 102 alternate between IPv4 and IPv6, without needing to tear down and 103 re-establish upper layer protocol connections or associations. In 104 other words, the way upper layer protocols need to react to 105 cross-IP-version handovers does not differ from the way they need to 106 react to intra-IP-version handovers. 108 This document does not specify any rendezvous or proxy services. 109 Those are subject to other specifications. Hence, this document 110 alone does not necessarily allow two mobile hosts to communicate, 111 unless they have other means for initial rendezvous and for solving 112 the simultaneous movement problem. 114 The Host Identity Protocol [3] (HIP) defines a mechanism that 115 decouples the transport layer (TCP, UDP, etc) from the 116 internetworking layer (IPv4 and IPv6), and introduces a new Host 117 Identity namespace. When a host uses HIP, the transport layer 118 sockets and IPsec Security Associations are not bound to IP addresses 119 but to Host Identifiers. This document specifies how the mapping 120 from Host Identifiers to IP addresses can be extended from a static 121 one-to-one mapping into a dynamic one-to-many mapping, thereby 122 enabling end-host mobility and multi-homing. 124 In practice, the HIP base exchange [3] creates a pair of IPsec 125 Security Associations (SA) between a pair of HIP enabled hosts. 126 These SAs are not bound to IP addresses, but to the Host Identifiers 127 (public keys) used to create them. However, the hosts must also know 128 at least one IP address where their peers are reachable. Initially 129 these IP addresses are the ones used during the HIP base exchange. 131 Since the SAs are not bound to IP addresses, the host is able to 132 receive packets that are protected using a HIP created ESP SA from 133 any address. Thus, a host can change its IP address and continue to 134 send packets to its peers. However, unless the host is sufficiently 135 trusted, the peers are not able to reply before they can reliably and 136 securely update the set of addresses that they associate with the 137 sending host. Furthermore, mobility may change the path 138 characteristics in such a manner that reordering occurs and packets 139 fall outside the ESP anti-replay window. 141 This document specifies a mechanism that allows a HIP host to update 142 the set of addresses that its peers associate with it. The address 143 update is implemented with new HIP parameter types. Due to the 144 danger of flooding attacks (see [4]), the peers must always check the 145 reachability of the host at a new address, unless sufficient level of 146 trust exists between the hosts. 148 The reachability check is implemented by the challenger sending some 149 piece of unguessable information to the new address, and waiting for 150 some acknowledgment from the responder that indicates reception of 151 the information at the new address. This may include exchange of a 152 nonce, or generation of a new SPI and observing data arriving on the 153 new SPI. 155 There are a number of situations where the simple end-to-end 156 readdressing functionality is not sufficient. These include the 157 initial reachability of a mobile host, location privacy, end-host and 158 site multi-homing with legacy hosts, and NAT traversal. In these 159 situations there is a need for some helper functionality in the 160 network. This document does not address those needs. 162 Finally, making underlying IP mobility transparent to the transport 163 layer has implications on the proper response of transport congestion 164 control, path MTU selection, and QoS. Transport-layer mobility 165 triggers, and the proper transport response to a HIP mobility or 166 multi-homing address change, are outside the scope of this document. 168 2. Conventions used in this document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC2119 [1]. 174 3. Terminology 176 Preferred address An address on which a host prefers to receive data. 177 With respect to a given peer, a host always has one active 178 preferred address. By default, the source address used in the HIP 179 base exchange is the preferred address. 180 New preferred address A new preferred address sent by a host to its 181 peers. The reachability of the new preferred address often needs 182 to be verified before it can be taken into use. Consequently, 183 there may simultaneously be an active preferred address, being 184 used, and a new preferred address, the reachability of which is 185 being verified. 187 4. Overview of HIP basic mobility and multi-homing functionality 189 HIP mobility and multi-homing is fundamentally based on the HIP 190 architecture [4], where the transport and internetworking layers are 191 decoupled from each other by an interposed host identity protocol 192 layer. In the HIP architecture, the transport layer sockets are 193 bound to the Host Identifiers (through HIT or LSI in the case of 194 legacy APIs), and the Host Identifiers are translated to the actual 195 IP address. 197 The HIP base protocol specification [3] defines how two hosts 198 exchange their Host Identifiers and establish a pair of ESP Security 199 Associations (SA). The ESP SAs are then used to carry the actual 200 payload data between the two hosts, by wrapping TCP, UDP, and other 201 upper layer packets into transport mode ESP payloads. The IP header 202 uses the actual IP addresses in the network. 204 The base specification does not contain any mechanisms for changing 205 the IP addresses that were used during the base HIP exchange. Hence, 206 in order to remain connected, any systems that implement only the 207 base specification and nothing else must retain the ability to 208 receive packets at their primary IP address; that is, those systems 209 cannot change the IP address on which they are using to receive 210 packets without causing loss of connectivity until a base exchange is 211 performed from the new address. 213 4.1 Informing the peer about multiple or changed address(es) 215 This document specifies a new HIP protocol parameter, the REA 216 parameter (see Section 6.1), that allows the hosts to exchange 217 information about their IP address(es), and any changes in their 218 address(es). The logical structure created with REA parameters has 219 three levels: hosts, IPsec Security Associations (SAs) indexed by 220 Security Parameter Indices (SPIs), and addresses. 222 The relation between these entities for an association negotiated as 223 defined in the base specification [3] is illustrated in Figure 1. 225 -<- SPI1a -- -- SPI2a ->- 226 host1 < > addr1a <---> addr2a < > host2 227 ->- SPI2a -- -- SPI1a -<- 229 Figure 1: Relation between hosts, SPIs, and addresses (base 230 specification) 232 In Figure 1, host1 and host2 negotiate two unidirectional IPsec SAs, 233 and each host selects the SPI value for its inbound SA. The 234 addresses addr1a and addr2a are the source addresses that each host 235 uses in the base HIP exchange. These are the "preferred" (and only) 236 addresses conveyed to the peer for each SA; even though packets sent 237 to any of the hosts' interfaces can arrive on an inbound SPI, when a 238 host sends packets to the peer on an outbound SPI, it knows of a 239 single destination address associated with that outbound SPI (for 240 host1, it sends a packet on SPI2a to addr2a to reach host2), unless 241 other mechanisms exist to learn of new addresses. 243 In general, the bindings that exist in an implementation 244 corresponding to this draft can be depicted as shown in Figure 2. In 245 this figure, a host can have multiple inbound SPIs (and, not shown, 246 multiple outbound SPIs) between itself and another host. 247 Furthermore, each SPI may have multiple addresses associated with it. 248 These addresses bound to an SPI are not used as IPsec selectors. 249 Rather, the addresses are those addresses that are provided to the 250 peer host, as hints for which addresses to use to reach the host on 251 that SPI. The REA parameter is used to change the set of addresses 252 that a peer associates with a particular SPI. 254 address11 255 / 256 SPI1 - address12 257 / 258 / address21 259 host -- SPI2 < 260 \ address22 261 \ 262 SPI3 - address31 263 \ 264 address32 266 Figure 2: Relation between hosts, SPIs, and addresses (general case) 268 A host may establish any number of security associations (or SPIs) 269 with a peer. The main purpose of having multiple SPIs is to group 270 the addresses into collections that are likely to experience fate 271 sharing. For example, if the host needs to change its addresses on 272 SPI2, it is likely that both address21 and address22 will 273 simultaneously become obsolete. In a typical case, such SPIs may 274 correspond with physical interfaces; see below. Note, however, that 275 especially in the case of site multi-homing, one of the addresses may 276 become unreachable while the other one still works. In the typical 277 case, however, this does not require the host to inform its peers 278 about the situation, since even the non-working address still 279 logically exists. 281 A basic property of HIP SAs is that the inbound IP address is not 282 used as a selector for the SA. Therefore, in Figure 2, it may seem 283 unnecessary for address31, for example, to be associated only with 284 SPI3-- in practice, a packet may arrive to SPI1 via destination 285 address address31 as well. However, the use of different source and 286 destination addresses typically leads to different paths, with 287 different latencies in the network, and if packets were to arrive via 288 an arbitrary destination IP address (or path) for a given SPI, the 289 reordering due to different latencies may cause some packets to fall 290 outside of the IPsec ESP anti-replay window. For this reason, HIP 291 provides a mechanism to affiliate destination addresses with inbound 292 SPIs, if there is a concern that replay windows might be violated 293 otherwise. In this sense, we can say that a given inbound SPI has an 294 "affinity" for certain inbound IP addresses, and this affinity is 295 communicated to the peer host. Each physical interface SHOULD have a 296 separate SA, unless the ESP reordering window is loose. 298 Moreover, even if the destination addresses used for a particular SPI 299 are held constant, the use of different source addresses may also 300 cause packets to fall outside of the ESP replay window, since the 301 path traversed is often affected by the source address or interface 302 used. A host has no way to influence the source address on which a 303 peer uses to send its packets on a given SPI. Hosts SHOULD 304 consistently use the same source address when sending to a particular 305 destination IP address and SPI. For this reason, a host may find it 306 useful to change its SPI or at least reset its ESP replay window when 307 the peer host readdresses. 309 An address may appear on more than one SPI. This creates no 310 ambiguity since the receiver will ignore the IP addresses as IPsec 311 selectors anyway. 313 A single REA parameter contains data only about one SPI. To 314 simultaneously signal changes on several SPIs, it is necessary to 315 send several REA parameters. The packet structure supports this. 317 If the REA parameter is sent in an UPDATE packet, then the receiver 318 will respond with an UPDATE acknowledgment. If the REA parameter is 319 sent in a NOTIFY, I2, or R2 packet, then the recipient may consider 320 the REA as informational, and act only when it needs to activate a 321 new address. The use of REA in a NOTIFY message may not be 322 compatible with middleboxes. 324 4.2 Address verification 326 When a HIP host receives a set of IP addresses from another HIP host 327 in a REA, it does not necessarily know whether the other host is 328 actually reachable at the claimed addresses. In fact, a malicious 329 peer host may be intentionally giving a bogus addresses in order to 330 cause a packet flood towards the given address [7]. Thus, before the 331 HIP host can actually use a new address, it must first check that the 332 peer is reachable at the new address. 334 A second benefit of performing an address check is to allow any 335 possible middleboxes in the network along the new path to obtain the 336 peer host's inbound SPI. 338 A simple technique to verify addresses is to send an UPDATE to the 339 host at the new address. The UPDATE packet SHOULD include a nonce, 340 unguessable by anyone not on the path to the new address, that forces 341 the host to reply in a manner that confirms reception of the nonce. 342 One direct way to perform this is to include an ECHO_REQUEST 343 parameter with some piece of unguessable information such as a random 344 number. If the host is sending a NES parameter, the ECHO_REQUEST MAY 345 contain the new SPI, for example. If the peer host is rekeying by 346 sending an UPDATE with NES to the new address, the arrival of data on 347 the new SPI can also be used to verify the address. 349 If middlebox traversal is possible along the path, and the peer host 350 is not rekeying, the peer host SHOULD include a SPI parameter as part 351 of its UPDATE, with the SPI corresponding to its active inbound SPI. 352 It is not specified how a host knows whether or not middleboxes might 353 lie on its path, so a conservative assumption may be to always 354 include the SPI parameter. 356 In certain networking scenarios, hosts may be trusted enough to 357 bypass performing address verification. In such a case, the host MAY 358 bypass the address verification step and put the addresses into 359 immediate service. Note that this may not be compatible with 360 middlebox traversal. 362 4.3 Preferred address 364 When a host has multiple addresses and SPIs, the peer host must 365 decide upon which to use as a destination address. It may be that a 366 host would prefer to receive data on a particular inbound interface. 367 HIP allows a particular address to be designated as a preferred 368 address, and communicated to the peer. 370 In general, when multiple addresses are used for a session, there is 371 the question of using multiple addresses for failover only or for 372 load-balancing. Due to the implications of load-balancing on the 373 transport layer that still need to be worked out, this draft assumes 374 that multiple addresses are used primarily for failover. An 375 implementation may use ICMP interactions, reachability checks, or 376 other means to detect the failure of an address. 378 4.4 Address data structure and status 380 In a typical implementation, each outgoing address is represented as 381 a piece of state that contains the following data: 382 the actual bit pattern representing the IPv4 or IPv6 address, 383 lifetime (seconds), 384 status (UNVERIFIED, ACTIVE, DEPRECATED). 385 The status is used to track the reachability of the address: 386 UNVERIFIED indicates that the reachability of the address has not 387 been verified yet, 388 ACTIVE indicates that the reachability of the address has been 389 verified and the address has not been deprecated, 390 DEPRECATED indicates that the address lifetime has expired 392 The following state changes are allowed: 393 UNVERIFIED to ACTIVE The reachability procedure completes 394 successfully. 395 UNVERIFIED to DEPRECATED The address lifetime expires while it is 396 UNVERIFIED. 397 ACTIVE to DEPRECATED The address lifetime expires while it is ACTIVE. 398 ACTIVE to UNVERIFIED There has been no traffic on the address for 399 some time, and the local policy mandates that the address 400 reachability must be verified again before starting to use it 401 again. 402 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 403 address. 404 If a host is verifying reachability with another host, a DEPRECATED 405 address MUST NOT be changed to ACTIVE without first verifying its 406 reachability. If reachability is not being verified, then the 407 UNVERIFIED state is a transient state that transitions immediately to 408 ACTIVE. 410 5. Protocol overview 412 In this section we briefly introduce a number of usage scenarios 413 where the HIP mobility and multi-homing facility is useful. To 414 understand these usage scenarios, the reader should be at least 415 minimally familiar with the HIP protocol specification [3]. However, 416 for the (relatively) uninitiated reader it is most important to keep 417 in mind that in HIP the actual payload traffic is protected with ESP, 418 and that the ESP SPI acts as an index to the right host-to-host 419 context. 421 Each of the scenarios below assumes that the HIP base exchange has 422 completed, and the hosts each have a single outbound SA to the peer 423 host. Associated with this outbound SA is a single destination 424 address of the peer host-- the source address used by the peer during 425 the base exchange. 427 The readdressing protocol is an asymmetric protocol where one host, 428 called the mobile host, informs another host, called the peer host, 429 about changes of IP addresses on affected SPIs. The readdressing 430 exchange is designed to be piggybacked on a number of existing HIP 431 exchanges. The main packets on which the REA parameters are expected 432 to be carried on are UPDATE packets. However, some implementations 433 may want to experiment with sending REA parameters also on other 434 packets, such as R1, I2, and NOTIFY. 436 5.1 Mobility with single SA pair 438 A mobile host must sometimes change an IP address bound to an 439 interface. The change of an IP address might be needed due to a 440 change in the advertised IPv6 prefixes on the link, a reconnected PPP 441 link, a new DHCP lease, or an actual movement to another subnet. In 442 order to maintain its communication context, the host must inform its 443 peers about the new IP address. This first example considers the 444 case in which the mobile host has only one interface, IP address, and 445 a single pair of SAs (one inbound, one outbound). 447 1. The mobile host is disconnected from the peer host for a brief 448 period of time while it switches from one IP address to another. 449 Upon obtaining a new IP address, the mobile host sends a REA 450 parameter to the peer host in an UPDATE message. The REA 451 indicates the following: the new IP address, the SPI associated 452 with the new IP address, the address lifetime, and whether the 453 new address is a preferred address. The mobile host may 454 optionally send a NES to create a new inbound SA, in which case 455 it transitions to state REKEYING. In this case, the REA contains 456 the new SPI to use. Otherwise, the existing SPI is identified in 457 the REA parameter, and the host waits for its UPDATE to be 458 acknowledged. 459 2. Depending on whether the mobile host initiated a rekey, and on 460 whether the peer host itself wants to rekey or verify the mobile 461 host's new address, a number of responses are possible. Figure 3 462 illustrates an exchange for which neither side initiates a 463 rekeying, but for which the peer host performs an address check. 464 If the peer host chooses not to perform an address check, the 465 UPDATE that it sends will only acknowledge the mobile host's 466 update but will not solicit a response from the mobile host. If 467 the mobile host is rekeying, the peer will also rekey, as shown 468 in Figure 4. If the mobile host did not decide to rekey but the 469 peer desires to do so, then it initiates a rekey as illustrated 470 in Figure 5. The UPDATE messages sent from the peer back to the 471 mobile are sent to the newly advertised address. 472 3. If the peer host is verifying the new address, the address is 473 marked as UNVERIFIED in the interim. Once it has successfully 474 received a reply to its UPDATE challenge, or optionally, data on 475 the new SA, it marks the new address as ACTIVE and removes the 476 old address. 478 Mobile Host Peer Host 480 UPDATE(REA, SEQ) 481 -----------------------------------> 482 UPDATE(SPI, SEQ, ACK, ECHO_REQUEST) 483 <----------------------------------- 484 UPDATE(ACK, ECHO_RESPONSE) 485 -----------------------------------> 487 Figure 3: Readdress without rekeying, but with address check 489 Mobile Host Peer Host 491 UPDATE(REA, NES, SEQ, [DIFFIE_HELLMAN]) 492 -----------------------------------> 493 UPDATE(NES, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 494 <----------------------------------- 495 UPDATE(ACK, ECHO_RESPONSE) 496 -----------------------------------> 498 Figure 4: Readdress with mobile-initiated rekey 500 Mobile Host Peer Host 502 UPDATE(REA, SEQ) 503 -----------------------------------> 504 UPDATE(NES, SEQ, ACK, [DIFFIE_HELLMAN], ECHO_REQUEST) 505 <----------------------------------- 506 UPDATE(NES, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_RESPONSE) 507 -----------------------------------> 508 UPDATE(ACK) 509 <----------------------------------- 511 Figure 5: Readdress with peer-initiated rekey 513 Hosts that use link-local addresses as source addresses in their HIP 514 handshakes may not be reachable by a mobile peer. Such hosts SHOULD 515 provide a globally routable address either in the initial handshake 516 or via the REA parameter. 518 5.2 Host multihoming 520 A (mobile or stationary) host may sometimes have more than one 521 interface. The host may notify the peer host of the additional 522 interface(s) by using the REA parameter. To avoid problems with the 523 ESP reordering window, a host SHOULD use a different SA for each 524 interface used to receive packets from the peer host. 526 When more than one address is provided to the peer host, the host 527 SHOULD indicate which address is preferred. By default, the 528 addresses used in the base exchange are preferred until indicated 529 otherwise. 531 Although the protocol may allow for configurations in which there is 532 an asymmetric number of SAs between the hosts (e.g., one host has two 533 interfaces and two inbound SAs, while the peer has one interface and 534 one inbound SA), it is RECOMMENDED that inbound and outbound SAs be 535 created pairwise between hosts. When a NES arrives to rekey a 536 particular outbound SA, the corresponding inbound SA should be also 537 rekeyed at that time. Although asymmetric SA configurations might be 538 experimented with, their usage may constrain interoperability at this 539 time. However, it is recommended that implementations attempt to 540 support peers that prefer to use non-paired SAs. It is expected that 541 this section and behavior will be modified in future revisions of 542 this protocol, once the issue and its implications are better 543 understood. 545 To add both an additional interface and SA, the host sends a REA with 546 a NES. The host uses the same (new) SPI value in the REA and both 547 the "Old SPI" and "New SPI" values in the NES-- this indicates to the 548 peer that the SPI is not replacing an existing SPI. The multihomed 549 host transitions to state REKEYING, waiting for a NES from the peer 550 and an ACK of its own UPDATE. As in the mobility case, the peer host 551 can perform an address check while it is rekeying. Figure 6 552 illustrates the basic packet exchange. 554 Multi-homed Host Peer Host 556 UPDATE(REA, NES, SEQ, [DIFFIE_HELLMAN]) 557 -----------------------------------> 558 UPDATE(NES, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST) 559 <----------------------------------- 560 UPDATE(ACK, ECHO_RESPONSE) 561 -----------------------------------> 563 Figure 6: Basic multihoming scenario 565 For the case in which multiple addresses are advertised in a REA, the 566 peer does not need to send ACK for the UPDATE(REA) in every 567 subsequent message used for the address check procedure of the 568 multiple addresses. Therefore, a sample packet exchange might look 569 as shown in Figure 7. 571 Multi-homed Host Peer Host 573 UPDATE(REA(addr_1,addr_2), SEQ) 574 -----------------------------------> 575 UPDATE(ACK) 576 <----------------------------------- 578 sent to addr_1:UPDATE(SPI, SEQ, ECHO_REQUEST) 579 <----------------------------------- 580 UPDATE(ACK, ECHO_RESPONSE) 581 -----------------------------------> 583 sent to addr_2:UPDATE(SPI, SEQ, ECHO_REQUEST) 584 <----------------------------------- 585 UPDATE(ACK, ECHO_RESPONSE) 586 -----------------------------------> 588 Figure 7: REA with multiple addresses 590 When processing inbound REAs that establish new security 591 associations, a host uses the destination address of the UPDATE 592 containing REA as the local address to which the REA plus NES is 593 targeted. Hosts may send REA with the same IP address to different 594 peer addresses-- this has the effect of creating multiple inbound SAs 595 implicitly affiliated with different source addresses. 597 When rekeying in a multihoming situation in which there is an 598 asymmetric number of SAs between two hosts, a respondent to the NES/ 599 UPDATE procedure may have some ambiguity as to which inbound SA it 600 should update in response to the peer's UPDATE. In such a case, the 601 host SHOULD choose an SA corresponding to the inbound interface on 602 which the UPDATE was received. 604 5.3 Site multi-homing 606 A host may have an interface that has multiple globally reachable IP 607 addresses. Such a situation may be a result of the site having 608 multiple upper Internet Service Providers, or just because the site 609 provides all hosts with both IPv4 and IPv6 addresses. It is 610 desirable that the host can stay reachable with all or any subset of 611 the currently available globally routable addresses, independent on 612 how they are provided. 614 This case is handled the same as if there were different IP 615 addresses, described above in Section 5.2. Note that a single 616 interface may experience site multi-homing while the host itself may 617 have multiple interfaces. 619 Note that a host may be multi-homed and mobile simultaneously, and 620 that a multi-homed host may want to protect the location of some of 621 its interfaces while revealing the real IP address of some others. 623 This document does not presently specify additional site multihoming 624 extensions to HIP to further align it with the requirements of the 625 multi6 working group. 627 5.4 Dual host multi-homing 629 Consider the case in which both hosts would like to add an additional 630 address after the base exchange completes. In Figure 8, consider 631 that host1 wants to add address addr1b. It would send a REA to host2 632 located at addr2a, and a new set of SPIs would be added between hosts 633 1 and 2 (call them SPI1b and SPI2b). Next, consider host2 deciding 634 to add addr2b to the relationship. host2 now has a choice of which 635 of host1's addresses to initiate REA to. It may choose to initiate a 636 REA to addr1a, addr1b, or both. If it chooses to send to both, then 637 a full mesh (four SA pairs) of SAs would exist between the two hosts. 638 This is the most general case; it may be often the case that hosts 639 primarily establish new SAs only with the peer's preferred address. 640 The readdressing protocol is flexible enough to accommodate this 641 choice. 643 -<- SPI1a -- -- SPI2a ->- 644 host1 < > addr1a <---> addr2a < > host2 645 ->- SPI2a -- -- SPI1a -<- 647 addr1b <---> addr2b 649 Figure 8: Dual multihoming case in which each host uses REA to add a 650 second address 652 5.5 Combined mobility and multi-homing 654 It looks likely that in the future many mobile hosts will be 655 simultaneously mobile and multi-homed, i.e., have multiple mobile 656 interfaces. Furthermore, if the interfaces use different access 657 technologies, it is fairly likely that one of the interfaces may 658 appear stable (retain its current IP address) while some other(s) may 659 experience mobility (undergo IP address change). 661 The use of REA plus NES should be flexible enough to handle most such 662 scenarios, although more complicated scenarios have not been studied 663 so far. 665 5.6 Network renumbering 667 It is expected that IPv6 networks will be renumbered much more often 668 than most IPv4 networks are. From an end-host point of view, network 669 renumbering is similar to mobility. 671 5.7 Initiating the protocol in R1 or I2 673 A Responder host MAY include one or more REA parameters in the R1 674 packet that it sends to the Initiator. These parameters MUST be 675 protected by the R1 signature. If the R1 packet contains REA 676 parameters, the Initiator SHOULD send the I2 packet to the new 677 preferred address. The I1 destination address and the new preferred 678 address may be identical. 680 Initiator Responder 682 R1 with REA 683 <----------------------------------- 684 record additional addresses 685 change responder address 686 I2 with new SPI in SPI parameter 687 -----------------------------------> 688 (process normally) 689 R2 690 <----------------------------------- 691 (process normally) 693 Figure 9: REA inclusion in R1 695 An Initiator MAY include one or more REA parameters in the I2 packet, 696 independent on whether there was REA parameter(s) in the R1 or not. 697 These parameters MUST be protected by the I2 signature. Even if the 698 I2 packet contains REA parameters, the Responder MUST still send the 699 R2 packet to the source address of the I2. The new preferred address 700 SHOULD be identical to the I2 source address. 702 Initiator Responder 704 I2 with REA 705 -----------------------------------> 706 (process normally) 707 record additional addresses 708 R2 with new SPI in SPI parameter 709 <----------------------------------- 710 (process normally) 711 data on new SA 712 ------------------------------------> 713 (process normally) 715 Figure 10: REA inclusion in I2 717 6. Parameter and packet formats 719 6.1 REA parameter 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Type | Length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | SPI | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Address Lifetime | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |P| Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Address | 733 | | 734 | | 735 | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 . . 738 . . 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Address Lifetime | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Reserved | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Address | 745 | | 746 | | 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Type: 3 751 Length: Length in octets, excluding Type and Length fields. 752 SPI: Security Parameter Index (SPI) corresponding to Addresses 753 P: Preferred address. Set to one if the first address in this REA is 754 the new preferred address; otherwise set to zero. 755 Reserved: Zero when sent, ignored when received. 756 Address Lifetime: Address lifetime, in seconds. 757 Address: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [2]. 759 The SPI field identifies the SPI that this parameter applies to. It 760 is implicitly qualified by the Host Identity of the sending host. 761 The sending host is free to introduce new SPIs at will. That is, if 762 a received REA has a new SPI, it means that all the old addresses, 763 assigned to the other SPIs, are also supposed to still work, while 764 the new addresses in the newly received REA are supposed to be 765 associated with a new SPI. On the other hand, if a received REA has 766 an SPI that the receiver already knows about, it would replace (all) 767 the address(es) currently associated with the SPI with the new 768 one(s). 770 The Address Lifetime indicates how long the following address is 771 expected to be valid. The lifetime is expressed in seconds. Each 772 address MUST have a non-zero lifetime. The address is expected to 773 become deprecated when the specified number of seconds has passed 774 since the reception of the message. A deprecated address SHOULD NOT 775 be used as an destination address if an alternate (non-deprecated) is 776 available and has sufficient scope. Since IP addresses are ignored 777 upon reception, deprecation status does not have any affect on the 778 receiver. 780 The Address field contains an IPv6 address, or an IPv4 address in the 781 IPv4-in-IPv6 format [2]. The latter format denotes a plain IPv4 782 address that can be used to reach the Mobile Host. 784 6.2 UPDATE packet with included REA 786 A number of combinations of parameters in an UPDATE packet are 787 possible (e.g., see Section 5). Any UPDATE packet that includes a 788 REA parameter SHOULD include both an HMAC and a HIP_SIGNATURE 789 parameter.> 791 If there are multiple REA parameters to be sent in a single UPDATE, 792 and at least one of the REA parameters is matched with a NES 793 parameter, then each REA must be matched with a NES parameter, to 794 avoid ambiguity: 796 IP ( HIP ( REA1, REA2, NES1, NES2, [ DH, ] ... ) ) 798 If there are multiple REA parameters to be sent and not all are 799 paired with a NES, then multiple UPDATEs must be used (some with NES, 800 some without) to avoid ambiguity in the pairing of REA with NES. 802 7. Processing rules 804 7.1 Sending REAs 806 The decision of when to send REAs is basically a local policy issue. 807 However, it is RECOMMENDED that a host sends a REA whenever it 808 recognizes a change of its IP addresses, and assumes that the change 809 is going to last at least for a few seconds. Rapidly sending 810 conflicting REAs SHOULD be avoided. 812 When a host decides to inform its peers about changes in its IP 813 addresses, it has to decide how to group the various addresses, and 814 whether to include any addresses on multiple SPIs. Since each SPI is 815 associated with a different Security Association, the grouping policy 816 may be based on IPsec replay protection considerations. In the 817 typical case, simply basing the grouping on actual kernel level 818 physical and logical interfaces is often the best policy. Virtual 819 interfaces, such as IPsec tunnel interfaces or Mobile IP home 820 addresses SHOULD NOT be announced. 822 Note that the purpose of announcing IP addresses in a REA is to 823 provide connectivity between the communicating hosts. In most cases, 824 tunnels (and therefore virtual interfaces) provide sub-optimal 825 connectivity. Furthermore, it should be possible to replace most 826 tunnels with HIP based "non-tunneling", therefore making most virtual 827 interfaces fairly unnecessary in the future. On the other hand, 828 there are clearly situations where tunnels are used for diagnostic 829 and/or testing purposes. In such and other similar cases announcing 830 the IP addresses of virtual interfaces may be appropriate. 832 Once the host has decided on the groups and assignment of addresses 833 to the SPIs, it creates a REA parameter for each group. If there are 834 multiple REA parameters, the parameters MUST be ordered so that the 835 new preferred address is in the first REA parameter. Only one 836 address (the first one, if at all) may be indicated as preferred in 837 the REA parameter. 839 If addresses are being added to an existing SPI, the REA parameter 840 indicates the existing SPI and the full set of valid addresses for 841 that SPI. Any addresses previously ACTIVE on that SPI that are not 842 included in the REA will be set to DEPRECATED by the receiver. 844 If a mobile host decides to change the SPI upon a readdress, it sends 845 a REA with the SPI field within the REA set to the new SPI, and also 846 a NES parameter with the Old SPI field set to the previous SPI and 847 the New SPI field set to the new SPI. If multiple REA and NES 848 parameters are included, the NES MUST be ordered such that they 849 appear in the same order as the set of corresponding REAs. The 850 decision as to whether to rekey and send a new Diffie-Hellman 851 parameter while performing readdressing is a local policy decision. 853 If new addresses and new SPIs are being created, the REA parameter's 854 SPI field contains the new SPI, and the NES parameter's the Old SPI 855 field and New SPI fields are both set to the new SPI, indicating that 856 this is a new and not a replacement SPI. 858 If there are multiple REA parameters leading to a packet size that 859 exceeds the MTU, the host SHOULD send multiple packets, each smaller 860 than the MTU. In the case of R1 and I2, the additional packets 861 should be UPDATE packets that are sent after the base exchange has 862 been completed. 864 7.2 Handling received REAs 866 A host SHOULD be prepared to receive REA parameters in any HIP 867 packets, excluding I1. 869 When a host receives a REA parameter, it first performs the following 870 operations: 871 1. The host checks if the SPI listed is a new one. If it is a new 872 one, it creates a new SPI that contains no addresses. If it is 873 an existing one, it prepares to change the address set on the 874 existing SPI. 875 2. For each address listed in the REA parameter, check that the 876 address is a legal unicast or anycast address. That is, the 877 address MUST NOT be a broadcast or multicast address. Note that 878 some implementations MAY accept addresses that indicate the local 879 host, since it may be allowed that the host runs HIP with itself. 880 3. For each address listed in the REA parameter, check if the 881 address is already bound to the SPI. If the address is already 882 bound, its lifetime is updated. If the status of the address is 883 DEPRECATED, the status is changed to UNVERIFIED. If the address 884 is not already bound, the address is added, and its status is set 885 to UNVERIFIED. Mark all addresses on the SPI that were NOT 886 listed in the REA parameter as DEPRECATED. As a result, the SPI 887 now contains any addresses listed in the REA parameter either as 888 UNVERIFIED or ACTIVE, and any old addresses not listed in the REA 889 parameter as DEPRECATED. 890 4. If the REA is paired with a NES parameter, the NES parameter is 891 processed. If the REA is replacing the address on an existing 892 SPI, the SPI itself may be changed-- in this case, the host 893 proceeds according to HIP rekeying procedures. This case is 894 indicated by the NES parameter including an existing SPI in the 895 Old SPI field and a new SPI in the New SPI field, and the SPI 896 field in the REA matching the New SPI in the NES. If instead the 897 REA corresponds to a new SPI, the NES will include the same SPI 898 in both its Old SPI and New SPI fields. 899 5. Mark all addresses at the address group that were NOT listed in 900 the REA parameter as DEPRECATED. 902 Once the host has updated the SPI, if the REA parameter contains a 903 new preferred address, the host SHOULD initiate a change of the 904 preferred address. This usually requires that the host first 905 verifies reachability of the address, and only then changes the 906 preferred address. See Section 7.4. 908 7.3 Verifying address reachability 910 A host MAY want to verify the reachability of any UNVERIFIED address 911 at any time. It typically does so by sending a nonce to the new 912 address. For example, if the host is changing its SPI and is sending 913 a NES to the peer, the new SPI value SHOULD be random and the value 914 MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. If 915 the host is not rekeying, it MAY still use the ECHO_REQUEST parameter 916 in an UPDATE message sent to the new address. A host MAY also use 917 other message exchanges as confirmation of the address reachability. 918 Note that in the case of receiving a REA on an R1 and replying with 919 an I2, receiving the corresponding R2 is sufficient for marking the 920 Responder's primary address active. 922 In some cases, it may be sufficient to use the arrival of data on a 923 newly advertised SA as implicit address reachability verification, 924 instead of waiting for the confirmation via a HIP packet (e.g., 925 Figure 13). In this case, a host advertising a new SPI as part of 926 its address reachability check SHOULD be prepared to receive traffic 927 on the new SA. Marking the address active as a part of receiving 928 data on the SA is an idempotent operation, and does not cause any 929 harm. 931 Mobile host Peer host 933 prepare incoming SA 934 new SPI in R2, or UPDATE 935 <----------------------------------- 936 switch to new outgoing SA 937 data on new SA 938 -----------------------------------> 939 mark address ACTIVE 941 Figure 13: Address activation via use of new SA 943 7.4 Changing the preferred address 945 A host MAY want to change the preferred outgoing address for 946 different reasons, e.g., because traffic information or ICMP error 947 messages indicate that the currently used preferred address may have 948 become unreachable. Another reason is receiving a REA parameter that 949 has the P-bit set. 951 To change the preferred address, the host initiates the following 952 procedure: 953 1. If the new preferred address has ACTIVE status, the preferred 954 address is changed and the procedure succeeds. 955 2. If the new preferred address has UNVERIFIED status, the host 956 starts to verify its reachability. Once the verification has 957 succeeded, the preferred address change is completed, unless a 958 new change has been initiated in the meantime. 959 3. If the peer host has not indicated a preference for any address, 960 then the host picks one of the peer's ACTIVE addresses randomly 961 or according to policy. This case may arise if, for example, 962 ICMP error messages arrive that deprecate the preferred address, 963 but the peer has not yet indicated a new preferred address. 964 4. If the new preferred address has DEPRECATED status and there is 965 at least one non-deprecated address, the host selects one of the 966 non-deprecated addresses as a new preferred address and 967 continues. 969 8. Policy considerations 971 XXX: This section needs to be written. 973 The host may change the status of unused ACTIVE addresses into 974 UNVERIFIED after a locally configured period of inactivity. 976 9. Security Considerations 978 XXX: This section requires lots of more work. 980 (Initial text by Jari Arkko): If not controlled in some manner, 981 messaging related to address changes would create the following types 982 of vulnerabilities: 983 Revealing the contents of the (cleartext) communications 984 Hijacking communications and man-in-the-middle attacks 985 Denial of service for the involved nodes, by disabling their 986 ability to receive the desired communications 987 Denial of service for third parties, by redirecting a large amount 988 of traffic to them 989 Revealing the location of the nodes to other parties 991 In HIP, communications are bound to the public keys of the end-points 992 and not to IP addresses. The REA message is signed with the sender's 993 public key, and hence it becomes impossible to hijack the 994 communications of another host through the use of the REA message. 995 Similarly, since only the host itself can sign messages to move its 996 traffic flows to a new IP address, denial of service attacks through 997 REA can not cause the traffic flows to be sent to an IP address that 998 the host did not wish to use. Finally, in HIP all communications are 999 encrypted with ESP, so a hijack attempt would also be unable to 1000 reveal the contents of the communications. 1002 Malicious nodes that use HIP can, however, try to cause a denial of 1003 service attack by establishing a high-volume traffic flow, such as a 1004 video stream, and then redirecting it to a victim. However, the 1005 address reachability check provides some assurance that the given 1006 address is willing to accept the new traffic. Only attackers who are 1007 on the path between the peer and the new address could respond to the 1008 test. 1010 10. IANA Considerations 1011 11. Acknowledgments 1012 12. References 1014 12.1 Normative references 1016 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1017 Levels", BCP 14, RFC 2119, March 1997. 1019 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 1020 Architecture", RFC 2373, July 1998. 1022 [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 1023 Protocol", draft-moskowitz-hip-09 (work in progress), February 1024 2004. 1026 [4] Moskowitz, R., "Host Identity Protocol Architecture", 1027 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 1029 12.2 Informative references 1031 [5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998. 1033 [6] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1034 Security Considerations", draft-iab-sec-cons-00 (work in 1035 progress), August 2002. 1037 [7] Nikander, P., "Mobile IP version 6 Route Optimization Security 1038 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 1039 in progress), December 2003. 1041 Authors' Addresses 1043 Pekka Nikander 1044 Ericsson Research Nomadic Lab 1045 JORVAS FIN-02420 1046 FINLAND 1048 Phone: +358 9 299 1 1049 EMail: pekka.nikander@nomadiclab.com 1051 Jari Arkko 1052 Ericsson Research Nomadic Lab 1053 JORVAS FIN-02420 1054 FINLAND 1056 Phone: +358 9 299 1 1057 EMail: jari.arkko@nomadiclab.com 1058 Tom Henderson 1059 The Boeing Company 1060 P.O. Box 3707 1061 Seattle, WA 1062 USA 1064 EMail: thomas.r.henderson@boeing.com 1066 Appendix A. Changes from previous versions 1068 A.1 From nikander-hip-mm-00 to nikander-hip-mm-01 1070 The actual protocol has been largely revised, based on the new 1071 symmetric New SPI (NES) design adopted in the base protocol draft 1072 version -08. There are no more separate REA, AC or ACR packets, but 1073 their functionality has been folded into the NES packet. At the same 1074 time, it has become possible to send REA parameters in R1 and I2. 1076 The Forwarding Agent functionality was removed, since it looks like 1077 that it will be moved to the proposed HIP Research Group. Hence, 1078 there will be two other documents related to that, a simple 1079 Rendezvous server document (WG item) and a Forwarding Agent document 1080 (RG item). 1082 A.2 From nikander-hip-mm-01 to nikander-hip-mm-02 1084 Alignment with base-00 draft (use of UPDATE and NOTIFY packets). 1086 The "logical interface" concept was dropped, and the SA/SPI was 1087 identified as the protocol component to which a HIP association binds 1088 addresses to. 1090 The RR was (again) made recommended, not mandatory, able to be 1091 administratively overridden. 1093 A.3 From -02 to draft-ietf-hip-mm-00 1095 REA parameter type value is now "3" (was TBD before). 1097 Recommend that in multihoming situations, that inbound/outbound SAs 1098 are paired to avoid ambiguity when rekeying them. 1100 Clarified that multihoming scenario for now was intended for failover 1101 instead of load-balancing, due to transport layer issues. 1103 Clarified that if HIP negotiates base exchange using link local 1104 addresses, that a host SHOULD provide its peer with a globally 1105 reachable address. 1107 Clarified whether REAs sent for existing SPIs update the full set of 1108 addresses associated with that SPI, or only perform an incremental 1109 (additive) update. REAs for an existing SPI should list all current 1110 addresses for that SPI, and any addresses previously in use on the 1111 SPI but not in the new REA parameter should be DEPRECATED. 1113 Clarified that address verification pertains to *outgoing* addresses. 1115 When discussing incluson of REA in I2, the draft stated "The 1116 Responder MUST make sure that the puzzle solution is valid BOTH for 1117 the initial IP destination address used for I1 and for the new 1118 preferred address." However, this statement conflicted with Appendix 1119 D of the base specification, so it has been removed for now. 1121 Appendix B. Implementation experiences 1122 Intellectual Property Statement 1124 The IETF takes no position regarding the validity or scope of any 1125 Intellectual Property Rights or other rights that might be claimed to 1126 pertain to the implementation or use of the technology described in 1127 this document or the extent to which any license under such rights 1128 might or might not be available; nor does it represent that it has 1129 made any independent effort to identify any such rights. Information 1130 on the procedures with respect to rights in RFC documents can be 1131 found in BCP 78 and BCP 79. 1133 Copies of IPR disclosures made to the IETF Secretariat and any 1134 assurances of licenses to be made available, or the result of an 1135 attempt made to obtain a general license or permission for the use of 1136 such proprietary rights by implementers or users of this 1137 specification can be obtained from the IETF on-line IPR repository at 1138 http://www.ietf.org/ipr. 1140 The IETF invites any interested party to bring to its attention any 1141 copyrights, patents or patent applications, or other proprietary 1142 rights that may cover technology that may be required to implement 1143 this standard. Please address the information to the IETF at 1144 ietf-ipr@ietf.org. 1146 Disclaimer of Validity 1148 This document and the information contained herein are provided on an 1149 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1150 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1151 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1152 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1153 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1154 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1156 Copyright Statement 1158 Copyright (C) The Internet Society (2004). This document is subject 1159 to the rights, licenses and restrictions contained in BCP 78, and 1160 except as set forth therein, the authors retain all their rights. 1162 Acknowledgment 1164 Funding for the RFC Editor function is currently provided by the 1165 Internet Society.