idnits 2.17.1 draft-nikander-hip-mm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 727 has weird spacing: '...cast or multi...' -- 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 (December 29, 2003) is 7424 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 878, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 880, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-07 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-03 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft J. Arkko 4 Expires: June 28, 2004 Ericsson Research Nomadic Lab 5 December 29, 2003 7 End-Host Mobility and Multi-Homing with Host Identity Protocol 8 draft-nikander-hip-mm-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on June 28, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document specifies basic end-host mobility and multi-homing 39 mechanisms for the Host Identity Protocol. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Conventions used in this document . . . . . . . . . . . . . . 5 45 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 46 4. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 47 4.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . . 7 48 4.2 End-host multi-homing . . . . . . . . . . . . . . . . . . . . 7 49 4.3 Site multi-homing . . . . . . . . . . . . . . . . . . . . . . 7 50 4.4 Combined mobility and multi-homing . . . . . . . . . . . . . . 8 51 4.5 Network renumbering . . . . . . . . . . . . . . . . . . . . . 8 52 5. Overview of HIP basic mobility and multi-homing 53 functionality . . . . . . . . . . . . . . . . . . . . . . . . 9 54 5.1 Informing the peer about multiple or changed address(es) . . . 9 55 5.2 Address verification . . . . . . . . . . . . . . . . . . . . . 10 56 5.3 Address data structure and status . . . . . . . . . . . . . . 11 57 6. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 12 58 6.1 Initiating the protocol in NES . . . . . . . . . . . . . . . . 13 59 6.2 Initiating the protocol in R1 or I2 . . . . . . . . . . . . . 13 60 6.3 Explicit address check . . . . . . . . . . . . . . . . . . . . 15 61 7. Parameter and packet formats . . . . . . . . . . . . . . . . . 16 62 7.1 REA parameter . . . . . . . . . . . . . . . . . . . . . . . . 16 63 7.2 Modified NES_INFO parameter . . . . . . . . . . . . . . . . . 17 64 7.3 NES packet with included REA . . . . . . . . . . . . . . . . . 18 65 7.4 R1 and I2 packets with included REA . . . . . . . . . . . . . 18 66 8. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 20 67 8.1 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . . 20 68 8.2 Handling received REAs . . . . . . . . . . . . . . . . . . . . 20 69 8.3 Verifying address reachability . . . . . . . . . . . . . . . . 21 70 8.4 Changing the preferred address . . . . . . . . . . . . . . . . 22 71 9. Policy considerations . . . . . . . . . . . . . . . . . . . . 23 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 75 Normative references . . . . . . . . . . . . . . . . . . . . . 27 76 Informative references . . . . . . . . . . . . . . . . . . . . 28 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 78 A. Changes from previous versions . . . . . . . . . . . . . . . . 29 79 A.1 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 29 80 B. Implementation experiences . . . . . . . . . . . . . . . . . . 30 81 Intellectual Property and Copyright Statements . . . . . . . . 31 83 1. Introduction 85 This document specifies an extension to the Host Identity Protocol 86 [3] (HIP). The extension provides a simple and efficient means for 87 hosts to keep their communications on-going while having multiple IP 88 addresses, either at the same time or one after another. That is, 89 the extension provides basic support for multi-homing, mobility, and 90 simultaneous multi-homing and mobility. Additionally, the extension 91 allows communications to continue even when multi-homing or mobility 92 causes a change of the IP version that is available in the network; 93 that is, if one of the communicating hosts has both IPv4 and IPv6 94 connectivity, either directly or through a proxy,the other host can 95 alternate between IPv4 and IPv6 without any effects on the upper 96 layer protocols. 98 This document does not specify any rendezvous or proxy services. 99 Those are subject to other specifications . Hence, this document 100 alone does not necessarily allow two mobile hosts to communicate, 101 unless they have other means for initial rendezvous and solving the 102 simultaneous movement problem. 104 The Host Identity Protocol [3] (HIP) defines a mechanism that 105 decouples the transport layer (TCP, UDP, etc) from the 106 internetworking layer (IPv4 and IPv6), and introduces a new Host 107 Identity namespace. When a host uses HIP, the transport layer sockets 108 and IPsec Security Associations are not bound to IP addresses but to 109 Host Identifiers. This document specifies how the mapping from Host 110 Identifiers to IP addresses can be extended from a static one-to-one 111 mapping into a dynamic one-to-many mapping, thereby enabling end-host 112 mobility and multi-homing. 114 In practice, the HIP base exchange [3]creates a pair of IPsec 115 Security Associations (SA) between a pair of HIP enabled hosts. 116 These SAs are not bound to IP addresses, but to the Host Identifiers 117 (public keys) used to create them. However, the hosts must also know 118 at least one IP address where their peers are reachable. Initially 119 these IP addresses are the ones used during the HIP base exchange. 121 Since the SAs are not bound to IP addresses, the host are able to 122 receive packets that protected using a HIP created ESP SA from any 123 address. Thus, a host can change its IP address and continue to send 124 packets to its peers. However, the peers are not able to replys 125 before they can reliably and securely update the set of addresses 126 that they associate with the sending host. 128 This document specifies a mechanism that allows a HIP host to update 129 the set of addresses that its peers associate with it. The address 130 update is implemented with new HIP parameter types. Due to the danger 131 of flooding attacks (see [4]), the peers must always check the 132 reachability of the host at a new address before it can use the new 133 addresses. The reachability check is implemented by the challenger 134 creating a new SPI, announcing the new SPI, and waiting for traffic 135 on the new SPI. In addition to initiating the reachability check, 136 announcing the new SPI also acts as an acknowledgement for a 137 preceding address change. 139 There are a number of situations where the simple end-to-end 140 readdressing functionality is not sufficient. These include the 141 initial reachability of a mobile host, location privacy, end-host and 142 site multi-homing with legacy hosts, and NAT traversal. In these 143 situations there is a need for some helper functionality in the 144 network. This document does not address those needs. 146 2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC2119 [1]. 152 3. Terminology 154 Preferred address An address that a host prefers to receive data. 156 New preferred address A new preferred address sent by a host to its 157 peers. The reachability of the new preferred address often needs 158 to be verified before it can be taken into use. Consequently, 159 there may simultaneously be an active preferred address, being 160 used, and a new preferred address, whose reachability is being 161 verified. 163 Interface A logical concept used to group IP addresses together. If a 164 host announces multiple interface, each interface will be 165 associated with a different incoming Security Association. 167 4. Usage scenarios 169 In this section we briefly introduce a number of usage scenarios 170 where the HIP mobility and multi-homing facility is useful. To 171 understand these usage scenarios, the reader should be at least 172 minimally familiar with the HIP protocol specification [3]. However, 173 for the (relatively) uninitiated reader it is most important to keep 174 in mind that in HIP the actual payload traffic is protected with ESP, 175 and that the ESP SPI acts as an index to the right host-to-host 176 context. 178 4.1 End-host mobility 180 A mobile IP host must change its IP address according to 181 connectivity. The change of an IP address might be needed due to a 182 change in the advertised IPv6 prefixes on the link, a reconnected PPP 183 link, a new DHCP lease, or an actual movement to another subnet. In 184 order to maintain its communication context, the host must inform its 185 peers about the new IP address. 187 Although HIP enables ESP and the upper layer to be independent of the 188 internetworking layer, there still needs to be a mapping of the 189 pseudo-IP addresses used in the upper stack (LSI and HIT) to a real 190 IP address. Thus, from the functional point of view, it is 191 sufficient that the peer host learn the new IP address. The upper 192 layer protocols need to know about the address and connectivity 193 change only for QoS and other similar purposes. In most cases, they 194 do not need to know. 196 4.2 End-host multi-homing 198 A host may have multiple interfaces, and it is desirable that it can 199 stay reachable through all or any subset of the currently available 200 interfaces. It is expected that the set of available interfaces may 201 change dynamically, and that there may be policies associated with 202 the usage of the different interfaces. For instance, the host may 203 have a fast but low range wireless interface and a slow high range 204 interface. The host may generally prefer to use the fast interface, 205 but it may not be always available. 207 Note that a host may be multi-homed and mobile simultaneously, and 208 that a multi-homed host may want to protect the location of some of 209 its interfaces while revealing the real IP address of some others. 211 4.3 Site multi-homing 213 A host may have an interface that has multiple globally reachable IP 214 addresses. Such a situation may be a result of the site having 215 multiple upper Internet Service Providers, or just because the site 216 provides all host with both IPv4 and IPv6 addresses. It is desirable 217 that the host can stay reachable with all or any subset of the 218 currently available globally routable addresses, independent on how 219 they are provided. 221 Note that a single interface may experience site multi-homing while 222 the host itself may have multiple interfaces. 224 4.4 Combined mobility and multi-homing 226 It looks likely that in the future many mobile hosts will be 227 simultaneously mobile and multi-homed, i.e., have multiple mobile 228 interfaces. Furthermore, if the interfaces use different access 229 technologies, it is fairly likely that one of the interfaces may 230 appear stable (retain its current IP address) while some other(s) may 231 experience mobility (undergo IP address change). 233 4.5 Network renumbering 235 It is expected that IPv6 networks will be renumbered much more often 236 than most IPv4 networks are. From an end-host point of view, network 237 renumber is similar to mobility. 239 5. Overview of HIP basic mobility and multi-homing functionality 241 HIP mobility and multi-homing is fundamentally based on the HIP 242 architecture [4], where the transport and internetworking layers are 243 insulated from each other with the new host identity protocol layer. 244 In the HIP architecture, the transport layer sockets are bound to the 245 Host Identifiers (through HIT or LSI in the case of legacy APIs), and 246 the Host Identifiers are translated to the actual IP address. 248 In the HIP base protocol specification [3], it is defined how two 249 hosts exchange their Host Identifiers and establish a pair of ESP 250 Security Associations (SA). The ESP SAs are then used to carry the 251 actual payload data between the two hosts, by wrapping TCP, UDP, and 252 other upper layer packets into transport mode ESP payloads. The IP 253 header, carrying the ESP header, uses the actual IP addresses in the 254 network. 256 The base specification does not contain any mechanisms for changing 257 the IP addresses that were used during the base HIP exchange. Hence, 258 in order to remain connected any systems that implement only the 259 space specification and nothing else must retain the ability to 260 receive packets at their primary IP address; that is, those systems 261 cannot change the IP address they are using without causing loss of 262 connectivity. 264 5.1 Informing the peer about multiple or changed address(es) 266 This document specifies a new HIP protocol parameter, the REA 267 parameter (see Section 7.1), that allows the hosts to exchange 268 information about their IP address(es), and any changes in their 269 address(es). The logical structure created with REA parameters has 270 three levels: hosts, interfaces, and addresses. This is illustrated 271 in Figure 1. 273 address11 274 / 275 interface1 - address12 276 / 277 / address21 278 host -- interface2 < 279 \ address22 280 \ 281 interface3 - address31 282 \ 283 address32 285 Figure 1 287 In this document, the interfaces are considered to be logical 288 objects. A host may claim to have any number of interfaces. The 289 purpose of the interfaces is to group the addresses into collections 290 that are likely to experience fate sharing. For example, if the host 291 needs to change its addresses on interface2, it is likely that both 292 address21 and address22 will simultaneously become obsolete. Note, 293 however, that especially in the case of site multi-homing one of the 294 addresses may become unreachablewhile the other one still works. In 295 the typical case, however, this does not require the host to inform 296 its peers about the situation, since even the non-working address 297 still logically exists. 299 All addresses on a single interface share an SA. Each interface has 300 its own SA. In the usual case, the latencies experienced on distinct 301 interfaces may be considerably different. Hence, if multiple 302 interfaces were to share an SA, it would become fairly likely that 303 some of the packets would be discarded due to appearing to have been 304 received outside of the ESP reordering window. 306 While it would be possible to share an SA between multiple 307 interfaces, there would be no benefit from it. As the interfaces are 308 logical objects, and as the hosts are free to create new interface as 309 demand and to move addresses between interfaces as they will, a 310 conforming host may claim that two physical interfaces are in fact 311 one logical one, thereby allowing the two interfaces to share an SA. 313 An address may appear on more than one interface. This creates no 314 ambiguity since each interface must have a different SPI, and since 315 the receiver will ignore the IP addresses anyway. 317 A single REA parameter contains data only about one interface. To 318 signal simultaneously changes on several interfaces, it is necessary 319 to send several REA parameters. The packet structure supports this. 321 If the REA parameter is send in a NES packet and the sender wants to 322 receive an acknowledgement, it must explicitly indicate so. 323 Otherwise the recipient of the REA parameter may consider the REA as 324 informational, and act only when it needs to activate a new address. 326 5.2 Address verification 328 When a HIP host receives a group of IP addresses from another HIP 329 host in a REA, it does not necessarily know whether the other host is 330 actually reachable at the claimed addresses. In fact, a 331 maliciouspeer host may be intentionally giving a bogus addresses in 332 order to cause a packet flood towards the given address [7]. Thus, 333 before the HIP host can actually use a new address, it must first 334 check that the peer is reachable at the new address. This is 335 implemented by requesting the peer to create a new outgoing SA, using 336 a new random SPI value, and waiting for data to appear on this new 337 SA. 339 5.3 Address data structure and status 341 In a typical implementation, each remote address is represented as a 342 piece of state that contains the following data: 344 the actual bit pattern representing the IPv4 or IPv6 address, 346 lifetime (seconds), 348 status (UNVERIFIED, ACTIVE, DEPRECATED). 350 The status is used to track the reachability of the address: 352 UNVERIFIED indicates that the reachability of the address has not 353 been checked yet, 355 ACTIVE indicates that the reachability of the address has been 356 checked and the address has not been deprecated, 358 DEPRECATED indicates that the address lifetime has expired 360 The following state changes are allowed: 362 UNVERIFIED to ACTIVE The reachability procedure completes 363 succesfully. 365 UNVERIFIED to DEPRECATED The address lifetime expires while it is 366 UNVERIFIED. 368 ACTIVE to DEPRECATED The address lifetime expires while it is ACTIVE. 370 ACTIVE to UNVERIFIED There has been no traffic on the address for 371 some time, and the local policy mandates that the address 372 reachability must be verified again before starting to use it 373 again. 375 DEPRECATED to UNVERIFIED The host receives a new lifetime for the 376 address. 378 A DEPRECATED address MUST NOT be changed to ACTIVE without first 379 verifying its reachability. 381 6. Protocol overview 383 The readdressing protocol is designed to be piggybacked on a number 384 of existing HIP exchanges. The main packets on which the REA 385 parameters are expected to be carried on are New SPI (NES) packets. 386 However, some implementations may want to experiment with sending REA 387 parameters also on other packets, such as R1 and I2. 389 The protocol is an asymmetric protcool where one host, called the 390 Mobile Host, informs another host, called the Peer host, about 391 changes of IP addresses on one of its interfaces. The protocol 392 consists of three steps, illustrated in Figure 2. 394 1. The Mobile Host sends a REA parameter to the Peer host. 396 2. The Peer Host initiates an address check procedure by sending a 397 new SPI value to a new address. Any packet that contains a new 398 SPI may be used, including NES, I2 and R2. The new SPI value 399 MUST be random, i.e., the Mobile Host MUST NOT be able to guess 400 it. When the Mobile Host receives the new SPI value, it creates 401 a new outgoing SA and starts sending data on it. 403 3. The Peer Host waits for new data to arrive on the new SA, 404 indicated by the SPI. Once it has succesfully received data on 405 the SA, it marks the new address as reachable. 407 Mobile host Peer host 409 REA parameter 410 -----------------------------------> 412 new SPI 413 <----------------------------------- 415 data on new SA 416 -----------------------------------> 418 Figure 2 420 The idea of the address check procedure is that if the Mobile Host is 421 able to succesfully construct the new outgoing SA, using the new SPI 422 value, and send data on that SA, then it must have received the 423 second message in the protocol, and therefore it must be reachable at 424 the said address. 426 XXX: Residual threat: The Mobile Host able to anticipate the KEY 427 index and guess the SPI value by trying out all? Not really, I 428 think, since it would require about 2^31 packets on the average... 430 6.1 Initiating the protocol in NES 432 The most common case is to carry the readdress protocol on NES 433 packets. In this case, the Mobile Host initiates rekey (usually 434 using the current Diffie-Hellman keys) and includes a REA parameter 435 on the initial NES packet. The Peer host replies to this with a 436 reply NES packet, sent to the new preferred address. As the Mobile 437 Host receives the reply NES, it starts using the new outgoing SA. 438 Finally, as the Peer Host receives traffic on the new incoming SA, it 439 marks the new address as valid and switches over to use the new 440 outgoing SA, associated with the new address. 442 Mobile host Peer host 444 NES with REA 445 -----------------------------------> 446 record additional addresses 447 (prepare new incoming SA) 448 NES with new SPI in NES_INFO 449 <----------------------------------- 450 (prepare new incoming SA) 451 (switch to new outgoing SA) 453 data on new SA 454 -----------------------------------> 455 (switch to new outgoing SA) 456 change preferred address 458 The text in (parantheses) indicate functions that are 459 performed anyway, as a part of NES processing, and not 460 new to the REA processing. 462 Figure 3 464 Basically, the processing structure is equal to the current NES 465 processing other than that the Peer host records the additional 466 addresses form the REA parameter, sends the NES reply to the new 467 preferred address instead of the current preferred address, and 468 updates the preferred address as soon as it receives data on the new 469 SA. 471 6.2 Initiating the protocol in R1 or I2 473 A Responder host MAY include one or more REA parameters in the R1 474 packet that it sends to the Initiator. These parameters MUST be 475 protected by the R1 signature. If the R1 packet contains REA 476 parameters, the Initiator SHOULD send the I2 packet to the new 477 preferred address. The Responder MUST make sure that the puzzle 478 solution is valid BOTH for the initial IP destination address used 479 for I1 and for the new preferred address. The I1 destination address 480 and the new preferred address may be identical. 482 Initiator Responder 484 R1 with REA 485 <----------------------------------- 486 record additional addresses 487 change responder address 489 I2 with new SPI in SPI_LSI 490 -----------------------------------> 491 (process normally) 492 R2 493 <----------------------------------- 494 (process normally) 496 Figure 4 498 XXX: What about R1 source address? Most probably we want to allow it 499 to be any address to allow an optimized rendezvous server to send an 500 R1 instead of the actual host? 502 An Initiator MAY include one or more REA parameters in the I2 packet, 503 independent on whether there was REA parameter(s) in the R1 or not. 504 These parameters MUST be protected by the I2 signature. Even if the 505 I2 packet contains REA parameters, the Responder MUST still send the 506 R2 packet to the source address of the I2. The new preferred address 507 SHOULD be identical to the I2 source address. 509 Initiator Responder 511 I2 with REA 512 -----------------------------------> 513 (process normally) 514 record additional addresses 515 R2 with new SPI in LSI_SPI 516 <----------------------------------- 517 (process normally) 519 data on new SA 520 ------------------------------------> 521 (process normally) 523 Figure 5 525 6.3 Explicit address check 527 When the Peer Host wants to use a new address that has not yet been 528 checked, it must first run check the reachability of the address 529 before sending any large amounts of data to the address. See Section 530 8.3. 532 7. Parameter and packet formats 534 7.1 REA parameter 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type | Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 |P| Reserved | Interface ID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Address Lifetime | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Reserved | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Address | 548 | | 549 | | 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 . . 553 . . 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Address Lifetime | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Reserved | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Address | 560 | | 561 | | 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Type 1 (first non-critical) 567 Length Length in octets, excluding Type and Length fields. 569 P Preferred address. The first address in this REA is the new 570 preferred address. 572 Reserved Zero when sent, ignored when received. 574 Interface ID Interface ID, as defined by the sending host. The 575 interface IDs may have any values, and need not be consequtively 576 allocated. 578 Address Lifetime Address lifetime, in seconds. 580 Reserved Zero when sent, ignored when received. 582 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address [2]. 584 The Interface ID field identifies the (logical) interface that this 585 parameter applies to. It is implicitly qualified by the Host 586 Identity of the sending host. The Interface ID groups a set of 587 addresses to an interface. The sending host is free to introduce new 588 interface IDs at will. That is, if a received REA has a new 589 interface ID, it means that all the old addresses, assigned to the 590 other interface IDs, are also supposed to still work, while the new 591 addresses in the newly received REA are supposed to be associated 592 with a new interface. On the other hand, if a received REA has an 593 interface ID that the receiver already knows about, it would replace 594 (all) the address(es) currently associated with the interface with 595 the new one(s). 597 The Address Lifetime indicates how long the following address is 598 expected to be valid. The lifetime is expressed in seconds. Each 599 address MUST have a non-zero lifetime. The address is expected to 600 become deprecated when the specified number of seconds has passed 601 since the reception of the message. A deprecated address SHOULD NOT 602 be used as an destination address if an alternate (non-deprecated) is 603 available and has sufficient scope. Since IP addresses are ignored 604 upon reception, deprecation status does not have any affect on the 605 receiver. 607 The Address field contains an IPv6 address, or an IPv4 address in the 608 IPv4-in-IPv6 format [2]. The latter format denotes a plain IPv4 609 address that can be used to reach the Mobile Host. 611 7.2 Modified NES_INFO parameter 613 The NES_INFO parameter is defined in the base specification [3]. The 614 R-bit is defined to indicate wheter a NES is a reply to another NES 615 or not. If a NES is not a reply, the receiver must reply. If a NES 616 is an unexpected reply, the packet is simply dropped. 618 This specification changes the semantics of the R-bit slightly. (It 619 is expected that this change may be later incorporated to the base 620 specification.) The new semantics of the R-bit are defined as 621 follows. 623 R Zero if the sender is requesting an explicit 624 NES_INFO as a reply, one if no reply is needed. 626 Processing NES packets currently defines the following behaviour. 628 If the system is in state E3 and the NES has the R-bit set, the 629 packet is silently dropped. 631 The new behaviour is defined as follows. 633 If the system is in state E3 and the NES_INFO has the R-bit set, 634 the system initiates unidirectional rekeying, as defined in 635 Section 8.3. 637 7.3 NES packet with included REA 639 A single REA is included in a NES packet between the NES_INFO and 640 HMAC parameters: 642 IP ( HIP ( REA, NES_INFO, [ DIFFIE_HELLMAN, ] HMAC, HIP_SIGNATURE ) ) 644 If there are multiple REA parameters to be sent in a single NES, each 645 of them must be matched with a NES_INFO parameter: 647 IP ( HIP ( REA1, REA2, NES_INFO1, NES_INFO2, [ DH, ] ... ) ) 649 7.4 R1 and I2 packets with included REA 651 The REA parameter is included early in the R1 and I2 packets, since 652 middle boxes may be interested in inspecting them. If a REA is not 653 present, a typical middle box is only interested in the SPI_LSI 654 parameter and the signature. 656 IP ( HIP ( REA, 657 BIRTHDAY_COOKIE, 658 DIFFIE_HELLMAN, 659 HIP_TRANSFORM, 660 ESP_TRANSFORM, 661 ( HOST_ID | HOST_ID_FQDN ), 662 HIP_SIGNATURE_2 ) ) 664 IP ( HIP ( SPI_LSI, 665 REA, 666 BIRTHDAY_COOKIE, 667 DIFFIE_HELLMAN, 668 HIP_TRANSFORM, 669 ESP_TRANSFORM, 670 ENCRYPTED { HOST_ID | HOST_ID_FQDN }, 671 HIP_SIGNATURE ) ) 673 8. Processing rules 675 XXX: This section needs more work. 677 8.1 Sending REAs 679 The decision of when to send REAs is basically a local policy issue. 680 However, it is RECOMMENDED that a host sends a REA whenever it 681 recognizes a change of its IP addresses, and assumes that the change 682 is going to last at least for a few seconds. Rapidly sending 683 conflicting REAs SHOULD be avoided. 685 When a host decided to inform its Peers about changes in its IP 686 addresses, it has to decide how to group the various addresses into 687 interfaces, and whether to include any addresses on multiple 688 interfaces. Since each interface is associated with a different 689 Security Association, the grouping policy may be based on IPsec 690 replay protection considerations. In the typical case, simply basing 691 the grouping on actual kernel level physical and logical interfaces 692 is often the best policy. Virtual interfaces, such as IPsec tunnel 693 interfaces or Mobile IP home addresses SHOULD NOT be announced. 695 Once the host has decided on the interfaces and assingment of 696 addresses to the interfaces, it creates a REA parameter for each 697 interface. If there are multiple interfaces and therefore multiple 698 parameters, the parameters MUST be ordered so that the new preferred 699 address is in the first REA parameter. 701 The REA parameters MAY be sent in R1, I2 and NES packets. If the 702 host does not have any other reason to send R1, I2 or NES, it should 703 generate a new initial NES, SHOULD NOT include any Diffie-Hellman 704 parameter to it, and send the REA parameters in the newly generated 705 NES packet. 707 If there are multiple REA parameters leading to a packet size that 708 exceeds the MTU, the host SHOULD send multiple packets, each smaller 709 than the MTU. In the case of R1 and I2, the additional packets 710 should be NES packets that are send after the base exchange has been 711 completed. 713 8.2 Handling received REAs 715 A host SHOULD be prepared to receive REA parameters in any HIP 716 packets, excluding I1. 718 When a host receives a REA parameter, it first performs the following 719 operations: 721 1. The host checks if the Interface ID listed is a new one. If it is 722 a new one, it creates a new logical interface that contains no 723 addresses. 725 2. For each address listed in the REA parameter, check that the 726 address is a legal unicast or anycast address. That is, the 727 addres MUST NOT be a broadcast or multicast address. Note that 728 some implementations MAY accept addresses that indicate the local 729 host, since it may be allowed that the host runs HIP with itself. 731 3. For each address listed in the REA parameter, check if the 732 address is already listed at the interface. If the address is 733 listed, its lifetime is updated. If the address is status is 734 DEPRECATED, the status is changed to UNVERIFIED. if the address 735 is not listed, the address is added, and its status is set to 736 UNVERIFIED. 738 4. Mark all addresses at the interface that were NOT listed in the 739 REA parameter as DEPRECATED. 741 As a result, the interface now contains any addresses listed in the 742 REA parameter either as UNVERIFIED or ACTIVE, and any old addresses 743 not listed in the REA parameter as DEPRECATED. 745 Once the host has updated the interface, if the REA parameter 746 contains a new preferred address, the host SHOULD initiate a change 747 of the preferred address. This usually requires that the host first 748 verifies reachability of the address, and only then changes the 749 address. See Section 8.4. 751 8.3 Verifying address reachability 753 A host MAY what to verify the reachability of any UNVERIFIED address 754 at any time. However, the exact method of verification depends on 755 whether the host will next send a packet that contains a new SPI 756 value or not. That is, if the host is replying to a R1 with an I2, 757 to an I2 with an R2, or to a initial NES with a reply NES, then the 758 verification is piggybacked on the I2, R2, or reply NES packet. 759 Otherwise the verification is initiated by sending an unidirectional 760 NES packet containing REA and NES_INFO parameters. 762 Any of the I2, R2, NES-reply or unidirectional-NES packets cause 763 either the creation or change of the outgoing SA in the Mobile Host. 764 Furthermore, as part of the process to send R2, NES-reply or 765 unidirectional-NES, the Peer Host MUST prepare a new incoming SA, 766 using the SPI value included in R2 or NES, so that it is prepared to 767 receive traffic on the new SA. 769 Note that in the case of receiving a REA on an R1 and replying with 770 an I2, receiving the corresponding R2 is sufficient for marking the 771 Responder's primary address active, and there is no need to wait for 772 data to appear on the SA. On the other hand, marking the address 773 active as a part of receiving data on the SA is an idempotent 774 operation, and does not cause any harm. 776 Mobile host Peer host 778 prepare incoming SA 779 new SPI in R2, or NES 780 <----------------------------------- 781 switch to new outgoing SA 783 data on new SA 784 -----------------------------------> 785 mark address ACTIVE 787 8.4 Changing the preferred address 789 A host MAY want to change the preferred outgoing address for many 790 reasons, e.g., because traffic information or ICMP error messages 791 indicate that the currently used preferred address may have become 792 unreachable. Another reason is receiving a REA parameter that has 793 the P-bit set. 795 To change the preferred address, the host initiates the following 796 procedure: 798 1. If the new preferred address is not listed on any interface, the 799 procedure fails. 801 2. If the new preferred address has DEPRECATED status and there is 802 at least one non-depraceted address, the host selects one of the 803 non-deprecated addresses as a new preferred address and 804 continues. 806 3. If the new preferred address has ACTIVE status, the preferred 807 address is changed and the procedure succeeds. 809 4. If the new preferred address has UNVERIFIED status, the host 810 starts to verify its reachability. Once the verification has 811 succeeded, the preferred address change is completed, unless a 812 new change has been initiated in the mean while. 814 9. Policy considerations 816 XXX: This section needs to be written. 818 The host may change the status of unused ACTIVE addresses into 819 UNVERIFIED after a locally configured period if inactivity. 821 10. Security Considerations 823 XXX: This section requires lots of more work. 825 (Initial text by Jari Arkko): If not controlled in some manner, 826 messaging related to address changes would create the following types 827 of vulnerabilities: 829 Revealing the contents of the (cleartext) communications 831 Hijacking communications and man-in-the-middle attacks 833 Denial of service for the involved nodes, by disabling their 834 ability to receive the desired communications 836 Denial of service for third parties, by redirecting a large amount 837 of traffic to them 839 Revealing the location of the nodes to other parties 841 In HIP, communications are bound to the public keys of the end-points 842 and not to IP addresses. The REA message is signed with the sender's 843 public key, and hence it becomes impossible to hijack the 844 communications of another host through the use of the REA message. 845 Similarly, since only the host itself can sign messages to move its 846 traffic flows to a new IP address, denial of service attacks through 847 REA can not cause the traffic flows to be sent to an IP address that 848 the host did not wish to use. Finally, In HIP all communications are 849 encrypted with ESP, so a hijack attempt would also be unable to 850 reveal the contents of the communications. 852 Malicious nodes that use HIP can, however, try to cause a denial of 853 service attack by establishing a high-volume traffic flow, such as a 854 video stream, and then redirecting it to a victim. However, the 855 return routability check provides some assurance that the given 856 address is willing to accept the new traffic. Only attackers who are 857 on the path between the peer and the new address could respond to the 858 test. 860 11. IANA Considerations 861 12. Acknowledgments 862 Normative references 864 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 865 Levels", BCP 14, RFC 2119, March 1997. 867 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 868 Architecture", RFC 2373, July 1998. 870 [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 871 Protocol", draft-moskowitz-hip-07 (work in progress), June 2003. 873 [4] Moskowitz, R., "Host Identity Protocol Architecture", 874 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 876 Informative references 878 [5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998. 880 [6] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 881 Security Considerations", draft-iab-sec-cons-03 (work in 882 progress), February 2003. 884 [7] Nikander, P., "Mobile IP version 6 Route Optimization Security 885 Design Background", draft-nikander-mobileip-v6-ro-sec-01 (work 886 in progress), July 2003. 888 Authors' Addresses 890 Pekka Nikander 891 Ericsson Research Nomadic Lab 893 JORVAS FIN-02420 894 FINLAND 896 Phone: +358 9 299 1 897 EMail: pekka.nikander@nomadiclab.com 899 Jari Arkko 900 Ericsson Research Nomadic Lab 902 JORVAS FIN-02420 903 FINLAND 905 Phone: +358 9 299 1 906 EMail: jari.arkko@nomadiclab.com 908 Appendix A. Changes from previous versions 910 A.1 From -00 to -01 912 The actual protocol has been largely revised, based on the new 913 symmetric New SPI (NES) design adopted in the base protocol draft 914 version -08. There are no more separate REA, AC or ACR packets, but 915 their functionality has been folded into the NES packet. At the same 916 time, it has become possible to send REA parameters in R1 and I2. 918 The Forwarding Agent functionality was removed, since it looks like 919 that it will be moved to the proposed HIP Research Group. Hence, 920 there will be two other documents related to that, a simple 921 Rendezvous server document (WG item) and a Forwarding Agent document 922 (RG item). 924 Appendix B. Implementation experiences 925 Intellectual Property Statement 927 The IETF takes no position regarding the validity or scope of any 928 intellectual property or other rights that might be claimed to 929 pertain to the implementation or use of the technology described in 930 this document or the extent to which any license under such rights 931 might or might not be available; neither does it represent that it 932 has made any effort to identify any such rights. Information on the 933 IETF's procedures with respect to rights in standards-track and 934 standards-related documentation can be found in BCP-11. Copies of 935 claims of rights made available for publication and any assurances of 936 licenses to be made available, or the result of an attempt made to 937 obtain a general license or permission for the use of such 938 proprietary rights by implementors or users of this specification can 939 be obtained from the IETF Secretariat. 941 The IETF invites any interested party to bring to its attention any 942 copyrights, patents or patent applications, or other proprietary 943 rights which may cover technology that may be required to practice 944 this standard. Please address the information to the IETF Executive 945 Director. 947 Full Copyright Statement 949 Copyright (C) The Internet Society (2003). All Rights Reserved. 951 This document and translations of it may be copied and furnished to 952 others, and derivative works that comment on or otherwise explain it 953 or assist in its implementation may be prepared, copied, published 954 and distributed, in whole or in part, without restriction of any 955 kind, provided that the above copyright notice and this paragraph are 956 included on all such copies and derivative works. However, this 957 document itself may not be modified in any way, such as by removing 958 the copyright notice or references to the Internet Society or other 959 Internet organizations, except as needed for the purpose of 960 developing Internet standards in which case the procedures for 961 copyrights defined in the Internet Standards process must be 962 followed, or as required to translate it into languages other than 963 English. 965 The limited permissions granted above are perpetual and will not be 966 revoked by the Internet Society or its successors or assignees. 968 This document and the information contained herein is provided on an 969 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 970 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 971 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 972 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 973 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Acknowledgement 977 Funding for the RFC Editor function is currently provided by the 978 Internet Society.