idnits 2.17.1 draft-nikander-hip-mm-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 923 has weird spacing: '...ming in a HIP...' -- 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 (June 17, 2003) is 7609 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 920, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 922, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 928, 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-06 -- 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-00 Summary: 2 errors (**), 0 flaws (~~), 9 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: December 16, 2003 P. Jokela 5 Ericsson Research Nomadic Lab 6 June 17, 2003 8 End-Host Mobility and Multi-Homing with Host Identity Protocol 9 draft-nikander-hip-mm-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 16, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies end-host mobility and multi-homing mechanisms 40 for the Host Identity Protocol. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 45 2. Conventions used in this document . . . . . . . . . . . . . 6 46 3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . 7 47 3.1 End-host mobility . . . . . . . . . . . . . . . . . . . . . 7 48 3.2 Location privacy . . . . . . . . . . . . . . . . . . . . . . 7 49 3.3 End-host multi-homing . . . . . . . . . . . . . . . . . . . 7 50 3.4 Site multi-homing . . . . . . . . . . . . . . . . . . . . . 8 51 3.5 Combined mobility and multi-homing . . . . . . . . . . . . . 8 52 3.6 Network renumbering . . . . . . . . . . . . . . . . . . . . 8 53 3.7 Combined all . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4. Overview of HIP mobility and multi-homing functionality . . 9 55 4.1 IP addresses assigned to a node . . . . . . . . . . . . . . 9 56 4.2 Informing the peer about multiple or changed address(es) . . 9 57 4.3 Address verification . . . . . . . . . . . . . . . . . . . . 10 58 4.4 Forwarding Agents . . . . . . . . . . . . . . . . . . . . . 10 59 4.4.1 Address leases from an Forwarding Agent . . . . . . . . . . 11 60 4.4.2 Recovering from forwarding agent crashes . . . . . . . . . . 12 61 4.5 Security Associations . . . . . . . . . . . . . . . . . . . 12 62 5. Protocol overview . . . . . . . . . . . . . . . . . . . . . 13 63 5.1 Acquiring an address lease from a Forwarding Agent . . . . . 13 64 5.2 Renewing an address lease . . . . . . . . . . . . . . . . . 14 65 5.3 Readdressing and address status . . . . . . . . . . . . . . 14 66 6. Protocol definition . . . . . . . . . . . . . . . . . . . . 16 67 6.1 Packet formats . . . . . . . . . . . . . . . . . . . . . . . 16 68 6.1.1 REA - the HIP readdress packet . . . . . . . . . . . . . . . 16 69 6.1.2 AC and ACR - the HIP Address Check and Address Check 70 Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets . . . . . . 20 72 6.2 Requesting Address Leases . . . . . . . . . . . . . . . . . 21 73 6.3 Providing address Leases . . . . . . . . . . . . . . . . . . 21 74 6.4 Sending REAs . . . . . . . . . . . . . . . . . . . . . . . . 21 75 6.5 Handling received REAs at end hosts . . . . . . . . . . . . 22 76 7. Policy considerations . . . . . . . . . . . . . . . . . . . 23 77 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 78 8.1 Why does the foreign agent may require a puzzle solution? . 24 79 8.2 Attacker masquerading as a FA . . . . . . . . . . . . . . . 24 80 8.3 Location privacy . . . . . . . . . . . . . . . . . . . . . . 25 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 83 Normative references . . . . . . . . . . . . . . . . . . . . 28 84 Informative references . . . . . . . . . . . . . . . . . . . 29 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 86 A. Site multi-homing . . . . . . . . . . . . . . . . . . . . . 31 87 A.1 A host connected to a multi-homed site . . . . . . . . . . . 31 88 A.2 Transit providers with NATs . . . . . . . . . . . . . . . . 31 89 B. Implementation experiences . . . . . . . . . . . . . . . . . 32 90 Intellectual Property and Copyright Statements . . . . . . . 33 92 1. Introduction 94 This document specifies how the Host Identity Protocol [3] (HIP) 95 provides simple and efficient means for nodes to communicate while 96 being multi-homed, mobile, or simultanously mobile and multi-homed. 97 Additionally, HIP allows communications even when the multi-homing or 98 mobility causes a change in the IP version that is available in the 99 network. 101 More specifically, the Host Identity Protocol [3] (HIP) defines a 102 mechanism that decouples the transport layer from the internetworking 103 layer, and introduces a new Host Identity namespace. When a host 104 uses HIP, the transport layer sockets and IPsec Security Associations 105 are not bound to IP addresses but to Host Identifiers. This document 106 specifies how the mapping from Host Identifiers to IP addresses can 107 be extended from a static one-to-one mapping into a dynamic 108 one-to-many mapping. This enables end-host mobility and 109 multi-homing. Additionally, this document introduces the concept of 110 Forwarding Agents. A Forwarding Agents provides Mobile IP Home Agent 111 like functionality for HIP enabled mobility. 113 In practice, the HIP base exchange creates a pair of IPsec Security 114 Associations (SA) between any communicating pair of HIP enabled 115 nodes. These SAs are not bound to IP addresses but to Host 116 Identifiers (public keys). However, the hosts must also know at 117 least one IP address where their peers are reachable. Initially this 118 IP address is the one used during the HIP base exchange. 120 Since the SAs are not bound to IP addresses, the nodes are able to 121 receive IPsec protected HIP packets from any address. Thus, a node 122 can change its IP address and continue to send packets to its peers. 123 However, the peers are not able to send replies before they can 124 reliably and securely update the sending node's address(es). 126 This document specifies a mechanism that allow a HIP node to update 127 its address(es) to its peers. The address update is implemented with 128 a new HIP packet type, the HIP Readdress (REA) packet. Due to the 129 danger of flooding attacks (see [4]), the peer must always check the 130 reachability of the node before it can use the new addresses. The 131 reachability check is implemented with a pair of new HIP packet 132 types, HIP Address Check (AC) and HIP Address Check Reply (ACR). In 133 addition to initiating and reachbility check, an AC packet may also 134 act as an acknowledgement for a preceding REA packet. 136 There are a number of situations where the simple end-to-end 137 readdressing functionality is not sufficient. These include the 138 initial reachability of a mobile node, location privacy, end-host and 139 site multi-homing with legacy hosts, and NAT traversal. In these 140 situations there is a need for some helper functionality in the 141 network. In this document we describe mechanisms for initial 142 reachability, multi-homing, recovering from simultaneous movements, 143 and combining mobility and multi-homing. Some of these functions 144 require an additional node in the network, which has been given the 145 name of Forwarding Agent. As a special case, a Forwarding Agent can 146 act as a lightweight Rendezvous server as defined in [3]. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC2119 [1]. 154 3. Usage scenarios 156 In this section we briefly introduce a number of usage scenarios 157 where the HIP mobility and multi-homing facility is useful. To 158 understand these usage scenarios, the reader should be at least 159 minimally familiar with the HIP protocol specification [3]. However, 160 for the (relatively) uninitiated reader it is most important to keep 161 in mind that in HIP the actual payload traffic is protected with ESP, 162 and that the ESP SPI acts as an index to the right host-to-host 163 context. 165 3.1 End-host mobility 167 A mobile IP host must change its IP address according to 168 connectivity. The change of an IP address might be needed due to a 169 change in the advertised IPv6 prefixes on the link, a reconnected PPP 170 link, a new DHCP lease, or an actual movement to another subnet. In 171 order to maintain its communication context, the host must inform its 172 peers about the new IP address. 174 Although HIP enables ESP and the upper layer to be independent of the 175 internetworking layer, there still needs to be a mapping of the 176 pseudo-IP addresses used in the upper stack (LSI and HIT) to a real 177 IP address. Thus, from the functional point of view, it is 178 sufficient that the peer nodes learn the new IP address. The upper 179 layer protocols need to know about the address and connectivity 180 change only for QoS and similar purposes. In most cases, they need 181 not to know. 183 3.2 Location privacy 185 To protect its privacy, an IP host may want to keep its actual IP 186 address private. Since HIP insulates the upper layer from the IP 187 address, this can be accomplished by simple address rewriting at an 188 privacy protecting node. 190 Note that a mobile node may want to keep its location private. In 191 that case, it informs its real address to the privacy protecting node 192 and not to the actual peers. 194 Full location privacy falls beyond this document. 196 3.3 End-host multi-homing 198 A host may have multiple interfaces, and it is desired that it can 199 stay reachable through all of the currently available interfaces. It 200 is expected that the set of available interfaces may change 201 dynamically, and that there may be policies associated with the usage 202 of the different interfaces. For instance, the host may have a fast 203 but low range wireless interface and a slow high range interface. 204 The host may generally prefer to use the fast interface, but it may 205 be available only some of the time. 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 interface while revealing the IP address of some others. 211 3.4 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 nodes with both IPv4 and IPv6 addresses. It is 217 desirable that the host can stay reachable with all currently 218 available globally routable addresses, independent on how they are 219 provided. 221 Note that a single interface may experience site multi-homing while 222 the host itself may have multiple interfaces. 224 3.5 Combined mobility and multi-homing 226 It looks likely that in the future many of the mobile nodes will be 227 simultaneously mobile and multi-homing, i.e., have multiple mobile 228 interfaces. Furthermore, if the interfaces use different access 229 technology, it is fairly likely that one of the interfaces may appear 230 stable (retain its current IP address) while some other(s) may 231 experience mobility (undergo IP address change). 233 3.6 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 3.7 Combined all 241 It is desirable that a host may simultaneously have multiple active 242 interfaces, be mobile (on any or all of its interfaces), utilize 243 multiple globally reachable addresses (on any or all of its 244 interfaces), and protect its location privacy (on any or all of its 245 interfaces). 247 4. Overview of HIP mobility and multi-homing functionality 249 HIP mobility and multi-homing is fundamentally based on the HIP 250 architecture [4], where the transport and internetworking layers are 251 insulated from each other with the new host identity layer. In the 252 HIP architecure, the transport layer sockets are bound to the Host 253 Identifiers (through HIT or LSI in the case of legacy APIs), and the 254 Host Identifiers are translated to the actual IP address. 256 In the base HIP protocol specification [3], it is defined how two 257 hosts exchange their Host Identifiers and establish a pair of ESP 258 Security Associations (SA). The ESP SAs are then used to carry the 259 actual payload data between the two hosts, by wrapping TCP, UDP, and 260 other upper layer headers into transport mode ESP payloads. The IP 261 header, carrying the ESP header, uses actual IP addresses in the 262 network. 264 In the base specification, hosts use the same IP addresses for nodes 265 that were used during the base HIP exchange. This specification 266 defines the way how IP addresses can be changed during the 267 communication. 269 4.1 IP addresses assigned to a node 271 A host can have multiple IP addresses. It may have many interfaces 272 that are assigned IP addresses or it may have multiple addresses 273 assigned to one interface. There may also be multiple IP addresses in 274 function of time: the node may changes its topological location in 275 the network, or its network may change addresses. 277 The interfaces are logical objects. A host may claim to have any 278 number of interfaces, as long as a single IP address does not appear 279 to be bound to more than one interface. The purpose of the 280 interfaces is to group the addresses into collections that are likely 281 to experience fate sharing. For example, if the host needs to change 282 its addresses on interface2, it is likely that both address21 and 283 address22 will simultaneously become obsolete. 285 4.2 Informing the peer about multiple or changed address(es) 287 To be able to use effectively multiple addresses assigned to the host 288 and update addresses that change during the communication with 289 another node, a HIP protocol packet, the REA packet (see Section 290 6.1.1), is specified. The logical structure created with REA packets 291 has three levels: hosts, interfaces, and addresses. This is 292 illustrated in Figure 1. 294 address11 296 / 297 interface1 - address12 298 / 299 / address21 300 host -- interface2 < 301 \ address22 302 \ 303 interface3 - address31 304 \ 305 address32 307 Figure 1 309 A single REA payload handles only one interface. To signal 310 simultaneously changes on several interfaces, it is necessary to send 311 several consequtive REA payloads. The packet structure supports 312 this. 314 4.3 Address verification 316 When a HIP host receives a group of IP addresses from another HIP 317 host in a REA, it does not necessarily know for sure whether the 318 other host is actually reachable at the claimed addresses. In fact, 319 if the other HIP host is not fully trusted, it may be giving a bogus 320 address with the intention of causing packet flood towards the given 321 address [8]. Thus, before the HIP host can actually use a new 322 address, it must first check that the peer is reachable at the new 323 address. This is implemented with the HIP Address Check (AC) and 324 Address Check Reply (ACR) packets. 326 To acknowledge that it has received the REA, and to initiate an 327 address check, the HIP host receiving a REA immediately sends an AC 328 to all addresses mentioned in the REA. 330 In a typical implementation, an address consists of the actual 331 bitpattern used in the IP source and destination fields, a lifetime, 332 and a status. The status is used to track the reachability of the 333 address. 335 4.4 Forwarding Agents 337 For nodes that are mobile, an IP address from where it can be reached 338 is necessary if the node wants to be reachable by other nodes. The 339 Forwarding Agent provides one possible solution to this. The 340 reachability of the HIP node may require usage of both IPv6 and IPv4. 341 If the HIP node itself is behind a network that supports only one of 342 the IP protocol versions, the HIP node may use the FA for acting as a 343 gateway when the peer node wants to use a IP protocol version that 344 the HIP node behind the FA does not directly support. 346 The HIP node can "lease" IP address(es) from the FA if it needs an 347 address from where it can be reached. This can be the case, for 348 example, when a mobile node needs a contact address for peer nodes. 349 The HIP node contacts the FA, requests for an IP address (and SPI 350 range), and start announcing the IP address (and some SPI) to its 351 peers. The SPI is required if the IP address leased from the FA is 352 not unique, i.e. it does not map one-to-one to the HIT of the HIP 353 node. Further ESP protected data packets arriving to the FA can thus 354 be identified using the SPI value and verifying to which HIP node 355 that particular SPI has been reserved. 357 As long as the "lease" is valid, the FA will forward any packets sent 358 to the IP address (and an SPI within the range) to the HIP host. The 359 basic operational model is depicted in Figure 2. Without mobility 360 (REA), using a FA results in triangular routing, as shown. 362 +----------+ +--------------+ 363 | HIP host |---------------------------->| Another host | 364 +----------+ +--------------+ 365 ^ real IP address | 366 | | 367 | | 368 +----------+ leased IP address | 369 | FA |<------------------------------------+ 370 +----------+ 372 Figure 2 374 The actual method of discovering FAs is beyond the scope of this 375 document, and will be specified elsewhere. 377 4.4.1 Address leases from an Forwarding Agent 379 To acquire an address lease from a given FA, the HIP host sends a 380 Forwarding Agent Query (FAQ) packet to it. In some cases, the FAQ 381 may be sent as a broadcast or multicast packet; the details of such 382 practice will be specified elsewhere. The HIP host may use any 383 identity it wishes; however, the identity may be subject to local 384 access control by the FA. That is, some FAs may be willing to serve 385 only some HIP hosts. 387 If the FA is willing to serve an address to the HIP host, it replies 388 to the FAQ with a Forwarding Agent Advice (FAA) packet. A FAA 389 establishes an address lease to the HIP host. The HIP host can rely 390 on the FA to keep forwarding packets to the HIP host until the 391 address lease expires. If the FA is not willing to serve the HIP 392 host, it responds with a Forwarding Agent Denied (FAD) packet, 393 specifying the reason for denial. 395 Each address lease has a lifetime. The HIP host may renew the 396 address lease at any time before it the lease expires. Subject to 397 its policy, the FA should renew and extend the lease, but it MAY 398 refuse any extensions. In any case, it must not reduce the lease 399 lifetime making it to expire prior to the initial expiration time. 401 The HIP host may abandon the lease at any time, either by failing to 402 renew it or by sending an Forwarding Agent Query that specifies a 403 zero lifetime. If an address lease expires without having been 404 renewed, the FA simply discards the forwarding state and any 405 resources associated with it. 407 4.4.2 Recovering from forwarding agent crashes 409 If a FA crashes, it looses its state. Consequently, it cannot 410 forward packets sent to it, since it does not know the IP address 411 associated with the leased address (and the SPI). The only thing the 412 forwarding agent could do would be to simulate lost state by the 413 actual HIP host that is leasing the address. However, since the 414 crashed FA does not know the HIT of the host, it cannot do that. 415 Effectively, the forwarding agent becomes a black hole until the HIP 416 host recognizes the situation and ackquires a new lease. 418 It is currently an open problem whether a crashed FA should send some 419 kind of error message to the hosts sending ESP packets to it. 421 4.5 Security Associations 423 The security associations between the nodes are not any longer 424 directly connected to the IP address of the node. The SA is 425 associated with the HIT and there may be either one SA between the 426 nodes, or multiple SAs when the interface capabilities require such 427 an arrangement. 429 All addresses on a single interface share an SA. Multiple interfaces 430 may share a single SA, but each interface may also have its own SA. 431 In practice, multiple interfaces may share an SA if the experienced 432 latency is fairly similar, in which case the packets are received 433 within the IPsec reordering window. However, the latencies between 434 two interfaces are considerably different, it becomes more likely 435 that some of the packets would be discarded due to appearing to have 436 been received outside of the ESP reordering window. Thus, in that 437 case it is necessary to use different SAs for different interfaces. 439 5. Protocol overview 441 The HIP mobility and multi-homing functionality consist of the 442 following subprotocols: 444 Acquiring an address lease from a Forwarding Agent 446 Renewing an address lease 448 Informing peers about multiple addresses or address changes, and 449 verifying the reachability of addresses 451 5.1 Acquiring an address lease from a Forwarding Agent 453 HIP host Forwarding Agent 454 Forwarding Agent Query 455 -----------------------------------> 457 R1 458 <----------------------------------- 460 Forwarding Agent Query 461 -----------------------------------> 463 Forwarding Agent Advice 464 <----------------------------------- 466 To acquire an address lease, the HIP host sends an FAQ, requesting 467 for an address lease. The host may specify the type of address it 468 wants to have (IPv4, IPv6, either), the number of SPIs requested, and 469 the desired lifetime. Any of these fields may be left empty, as 470 well. The FAQ is always signed. 472 If the Forwarding agent does not trust the HIP host, it may answer 473 with an R1, basically asking the HIP host to solve a puzzle before 474 the Forwarding Agent is even willing to consider the request. Once 475 the HIP host has solved the puzzle, it may send the FAQ again, this 476 time including an answer to the puzzle. 478 XXX: Is it OK that the FA answers with a normal R1, or should we use 479 some other packet type, e.g., Forwarding Agent R1 (FAR1)? 481 If the FA is willing to serve the HIP host, it answers with an FAA, 482 specifying the leased IP address, its lifetime, and if the address is 483 an IPv4 address, a range of SPIs that has been reserved for the HIP 484 host. 486 5.2 Renewing an address lease 488 Once an address lease is about to expire, the HIP host may want to 489 renew it. 491 HIP host Forwarding Agent 493 Forwarding Agent Query 494 -----------------------------------> 496 Forwarding Agent Advice 497 <----------------------------------- 499 To renew a lease, the HIP host simply sends a FAQ specifying an 500 existing lease, together with the desired extended lease time, and 501 the FA replies with an FAA. 503 5.3 Readdressing and address status 505 HIP host Another host 507 REA 508 -----------------------------------> 510 AC 511 <----------------------------------- 513 ACR 514 -----------------------------------> 516 When the host changes its IP address, gets more addresses or loses an 517 address, it may want to tell this change to peer nodes. The address 518 changing host sends the readdress packet (REA) to the peer where it 519 tells all available addresses. The address update packet is signed 520 providing proof about the sending party. 522 As the node receiving a REA packet cannot be sure if all the received 523 addresses are valid even the signature is correct, it sends the 524 Address Check (AC) packet to each of the new addresses received. If 525 the host receiving an AC message has sent the REA message that 526 matches the received AC message, it MUST send an Address Check Reply 527 (ACR) packet back to the peer for confirmation. New addresses 528 received in the REA packet are ready to be used after the ACR packet 529 has been received. 531 If a node receives an AC packet that does not match to any REA packet 532 that is has sent out, it MUST drop the packet. Such a packet may be 533 an indication that someone else is on purpose or on mistake sending a 534 false address to its peer. 536 6. Protocol definition 538 The location information update procedure in the HIP consists of the 539 readdress packet telling the current set of addresses that the node 540 is using, address check and address check replies. With this set of 541 messages the IP addresses can be updated to the peer and the peer is 542 able to verify that the addresses are valid. 544 In addition to the actual address update, the HIP node is provided a 545 possibility to get leased addresses from the FA. The FA can provide 546 address(es) (and a range of SPIs) for the HIP node and the HIP node 547 can use this towards other nodes. The FA thus forwards packets to the 548 HIP node when it receives packets sent to the leased address. 550 6.1 Packet formats 552 6.1.1 REA - the HIP readdress packet 554 A HIP readressing packet consists of one or more of REA_INFO 555 payloads, followed by a signature (HIP_SIGNATURE) and a HMAC. The 556 purpose of the signature is to allow middleboxes to verify the 557 integrity of the packet. The HMAC allows the peer node to verify the 558 packet very fast. 560 Intermediate systems that use the SPI will have to inspect ALL HIP 561 packets for a REA packet. This is a potential DoS attack against the 562 Intermediate system, as the signature processing may be relatively 563 expensive. A further step against attack for the Intermediate 564 systems is to implement ESP's replay protection of windowing the 565 sequence number. This requires the intermediate system to track ALL 566 ESP packets to follow the Sequence Number. 568 Optionally, the message may contain an ESP protected datagram. This 569 datagram is processed as if it had arrived separately. The purpose 570 of allowing datagrams to be embedded inside the REA packet is to 571 increase the efficiency of transmitting the first data packet, as 572 only one IPv6 header is required. 574 XXX Note (by Jari Arkko): I don't believe that this is a significant 575 function. In fact, header compression on links is probably more 576 efficient than this (the effect could be negative), and there might 577 be some problems that this causes. I don't think it causes the same 578 type of problems that piggybacking caused in Mobile IPv6, however, 579 because the packet is always encrypted, hence it could not receive 580 different treatment at the firewalls etc. But I'm not 100% sure that 581 there are no other problems. 583 6.1.1.1 REA_INFO payload 585 Note that the REA_INFO payload is a kind of "expanded" NES. 587 XXX (Pekka): Note that I have, for the time being, removed the old 588 ESP sequence number. Firstly, it may be hard to acquire reliably in 589 some implemtations (ours included). Secondly, we now have a REA ID 590 field, which is basically a REA sequence number. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Interface ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Current SPI in reverse direction | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Current SPI | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | New SPI | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Keymaterial index | REA ID | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Address Lifetime | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Address | 612 | | 613 | | 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 . . 617 . . 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Address Lifetime | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Reserved | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Address | 624 | | 625 | | 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Type 128 629 Length Length in octets, excluding Type and Length 630 fields 631 Interface ID Interface ID, as defined by the sending host 632 Current SPI rev. The current SPI used in the reverse direction 633 Current SPI The current SPI used for receiving ESP on this 634 interface 635 New SPI The new SPI used for receiving ESP on this 636 interface 637 Keymaterial index A bit index to the KEYMAT, where to pick up 638 the keying material for the new SA. 639 REA ID A 16-bit sequence number of nonce, used to 640 match the REA packet to the corresponding AC 641 packet. 642 Address Lifetime Address lifetime 643 Reserved Zero when sent, ignored when received 644 Address An IPv6 address or an IPv4-in-IPv6 format 645 IPv4 address 646 [2] 648 The Interface ID field identifies the (logical) interface that this 649 packet applies to. It is implicitly qualified by the Host Identity 650 of the sending host. The Interface ID groups a set of addresses to 651 an interface. The purpose of the Interface ID is to allow a 652 knowledgeable peer to interact with the sender. For example, the 653 sender could be informing its peer that that an interface has both an 654 IPv4 address and one or more IPv6 addresses. 656 The sending host is free to introduce interface IDs at will. That is, 657 if a received REA has a new interface ID, it means that all the old 658 addresses, assigned to other interface IDs, are also supposed to 659 still work, while the new addresses in the REA are supposed to be 660 associated with a new interface. On the other hand, if a received 661 REA has an interface ID that the receiver already knows about, it 662 would replace (all) the address(es) currently associated with the 663 interface with the new one(s). 665 If the SA is changed, and if the SA is not used at any other 666 interface any more, it MUST NOT be deleted until all ESP packets with 667 a lower Sequence Number have been received and processed, or a 668 reasonable time has elapsed (to account for lost packets). 670 6.1.1.2 HMAC 672 The HMAC SHA-1 is used to verify a received packet. 674 0 1 2 3 675 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Type | Length | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 / HMAC data / 681 / / 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Type 65532 685 Length Length in octets, excluding Type and Length fields 686 HMAC data 20 bytes of HMAC SHA-1 data 688 6.1.2 AC and ACR - the HIP Address Check and Address Check Reply 690 The HIP Address Check (AC) and Address Check Reply (ACR) packets 691 contain an AC_INFO payload, followed by a HMAC. 693 In addition to acting as an address probe, the Address Check packet 694 may also acts as an implicit acknowledgement to a REA packet. 696 6.1.2.1 AC_INFO payload 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Type | Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | AC ID | REA ID | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | RTT timestamp | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Reserved | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type 129 711 Length Length in octets, excluding Type and Length 712 fields 713 AC ID A 16-bit sequence number of nonce, used to match 714 the AC packet to the corresponding ACR packet. 715 REA ID A 16-bit sequence number of nonce, used to match 716 the REA packet to the corresponding AC packet. 717 RTT timestamp A timestamp field which may be used for RTT 718 estimation 719 Reserved Zero when sent, ignored when received 721 6.1.3 FAQ, FAA, FAD - the HIP Forwarding Agent packets 723 The HIP FAQ, FAA and FAD packets contain an FA_INFO payload, and 724 possibly other payloads. If a forwarding agent sends an R1 in 725 response to FAQ, the second FAQ must also contain an BIRTHDAY_COOKIE 726 payload, containing the cookie response. The FAA, and FAD packets 727 MUST contain a HOST_ID or HOST_ID_FQDN payload. The FAA packet MAY 728 contain a HOST_ID or HOST_ID_FQDN payload. 730 6.1.3.1 FA_INFO payload 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type | Length | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Request ID | Lease ID | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Lease duration | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Reserved | Addr type | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 IPv4 address: 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Min SPI | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Max SPI | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | IPv4 address | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Reserved | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 IPv6 address: 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | | 760 | IPv6 address (128 bits) | 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Type 130 765 Length Length in octets, excluding Type and Length 766 fields 768 Request ID A 16-bit sequence number of nonce, used to 769 match the FAQ packet to the corresponding 770 FAA/FAD packet. 771 Lease ID A 16-bit number XXX 772 Lease duration Duration of the lease 773 Reserved Zero when sent, ignored when received 774 Addr type Address type: 4 for IPv4 and 6 for IPv6 (TBD) 776 6.2 Requesting Address Leases 778 To request address leases from the FA, the HIP node sends an FAQ 779 packet to the FA. The FAQ packet consists of the HIP header, FA_INFO 780 payload and a HIP_SIGNATURE. If the FAQ packet is the second one sent 781 from the HIP node to the FA, i.e. the FA responded to the first FAQ 782 with an R1 packet, a BIRTHDAY_COOKIE payload containing the cookie 783 response must be included in the packet. 785 6.3 Providing address Leases 787 When the FA receives an FAQ packet from a HIP node, it may verify the 788 signature in the packet. If the FA does not trust on the requesting 789 node, it may generate an R1 packet containing a puzzle for the 790 requesting HIP node. 792 If the FA trusts to the requesting HIP node, or the HIP node 793 responded to the R1 packet with a new FAQ with a solved puzzle, the 794 FA can allocate address(es) and possibly SPIs for the requesting 795 node. The FA_INFO payload may contain information about the requested 796 addresses or the requested SPI ranges. If these requests can be met, 797 the FA may allocate address(es) and possible SPIs for the requesting 798 node. 800 If the allocation request was accepted and a successfull reservation 801 of data was performed, the FA responds to the requesting node with a 802 FAA packet. The FAA consists of an FA_INFO payload describing the 803 address(es) and possible SPIs that are reserved for the requesting 804 node. 806 However, if the FA was not able to allocate address(es), SPIs or the 807 request was malformed, the FA responds with a FAD packet. 809 6.4 Sending REAs 811 The HIP node may want to send address information to the peer node 812 whenever there are updates in the addresses that are assigned to it. 813 The leased addresses can be considered also to be possible addresses 814 and they must be assigned to a logical interface. 816 The REA packet contains the HIP header, one or more REA_INFO, 817 HIP_SIGNATURE and HMAC TLVs. The REA_INFO describes all the addresses 818 that are associated with that particular interface identifier. If a 819 previously associated address is not included in the list, the peer 820 considers it as a lost address and removes it from the address 821 associations. 823 6.5 Handling received REAs at end hosts 825 When a HIP node receives a REA packet, it verifies the signature in 826 it. If the packet was valid, it may initiate an address check 827 procedure. The address check (AC) packet is sent to all addresses 828 that were listed in the REA_INFO payload. The HIP node receiving the 829 REA packet from a node that it trusts, may accept all addresses 830 without making any address check for them. If ACs are sent, the 831 addresses in the REA_INFO must not be used until corresponding ACR 832 packet is received from the peer node. 834 7. Policy considerations 836 TBD 838 8. Security Considerations 840 (Initial text by Jari Arkko): If not controlled in some manner, 841 messaging related to address changes would create the following types 842 of vulnerabilities: 844 Revealing the contents of the (cleartext) communications 846 Hijacking communications and man-in-the-middle attacks 848 Denial of service for the involved nodes, by disabling their 849 ability to receive the desired communications 851 Denial of service for third parties, by redirecting a large amount 852 of traffic to them 854 Revealing the location of the nodes to other parties 856 In HIP, communications are bound to the public keys of the end-points 857 and not to IP addresses. The REA message is signed with the sender's 858 private key, and hence it becomes impossible to hijack the 859 communications of another node through the use of the REA message. 860 Similarly, since only the node itself can sign messages to move its 861 traffic flows to a new IP address, denial of service attacks through 862 REA can not cause the traffic flows to be sent to an IP address that 863 the node did not wish to use. Finally, In HIP all communications are 864 encrypted with ESP, so a hijack attempt would also be unable to 865 reveal the contents of the communications. 867 Malicous nodes that use HIP can, however, try to cause a denial of 868 service attack by establishing a high-volume traffic flow, such as a 869 video stream, and then redirecting it to a victim. However, the 870 return routability check provides some assurance that the given 871 address is willing to accept the new traffic. Only attackers who are 872 on the path between the peer and the new address could respond to the 873 test. 875 8.1 Why does the foreign agent may require a puzzle solution? 877 In Section 5.1 it is stated that a foreign agent may pass a puzzle, 878 in an R1, to the HIP host if it does not trust the HIP host. This 879 protects the foreing agent from CPU consuming DoS attacks. If this 880 protection were not used, an attacker could send a stream of bogus 881 FAQ packets to the foreign agent, making it to spend all of its CPU 882 to verify signatures that might be full garbage. 884 8.2 Attacker masquerading as a FA 885 The ability for an attacker to masquerade as a forwarding agent 886 depends on how the HIP host locates forwarding agents. That, in 887 turn, falls beyond the scope of this document. However, if the HIP 888 host accepts services from unknown or untrusted forwarding agents, it 889 is taking a risk of getting a black hole or eavesdropped address. 890 The resulting attack is usually not very serious, though, since all 891 actual data traffic is protected with ESP, and the HIP packets are 892 signed. Thus, the worst an untrustworthy forwarding agent can do is 893 to blackhole the packets. 895 8.3 Location privacy 897 TBD 899 9. IANA Considerations 900 10. Acknowledgments 902 Thanks to Kimmo Nieminen. 904 Normative references 906 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 907 Levels", BCP 14, RFC 2119, March 1997. 909 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 910 Architecture", RFC 2373, July 1998. 912 [3] Nikander, P. and R. Moskowitz, "Host Identity Protocol", 913 draft-moskowitz-hip-06 (work in progress), May 2003. 915 [4] Moskowitz, R., "Host Identity Protocol Architecture", 916 draft-moskowitz-hip-arch-03 (work in progress), May 2003. 918 Informative references 920 [5] Bellovin, S., "EIDs, IPsec, and HostNAT", IETF 41th, March 1998. 922 [6] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security, 923 Mobility, and Multi-Homing in a HIP Way", Network and 924 Distributed Systems Security Symposium (NDSS'03), February 6-7, 925 2003, San Diego, CA, pages 87-99, Internet Society, February 926 2003. 928 [7] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 929 Security Considerations", draft-iab-sec-cons-03 (work in 930 progress), February 2003. 932 [8] Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E. 933 Nordmark, "Mobile IP version 6 Route Optimization Security 934 Design Background", draft-nikander-mobileip-v6-ro-sec-00 (work 935 in progress), April 2003. 937 Authors' Addresses 939 Pekka Nikander 940 Ericsson Research Nomadic Lab 942 JORVAS FIN-02420 943 FINLAND 945 Phone: +358 9 299 1 946 EMail: pekka.nikander@nomadiclab.com 948 Jari Arkko 949 Ericsson Research Nomadic Lab 951 JORVAS FIN-02420 952 FINLAND 954 Phone: +358 9 299 1 955 EMail: jari.arkko@nomadiclab.com 956 Petri Jokela 957 Ericsson Research Nomadic Lab 959 JORVAS FIN-02420 960 FINLAND 962 Phone: +358 9 299 1 963 EMail: petri.jokela@nomadiclab.com 965 Appendix A. Site multi-homing 967 A site, connected to multiple transit providers, is considered to be 968 multi-homed. There is a possibility to send traffic using any of the 969 transit provider networks. A node, connected to a multi-homed site, 970 can experience this multi-homing from the received IP addresses. 972 A.1 A host connected to a multi-homed site 974 When a node connects to a multi-homed network, it may receive 975 multiple IP addresses on this connected interface. These addresses 976 can be either local IP addresses (behind a NAT) or public addresses. 978 A traditional node setting up a connection, selects one of the 979 available local addresses for this particular connection. This 980 address cannot be changed for the existing connection. 982 A HIP node experiencing similar site multi-homing is not limited to 983 the one source address selected during the connection set up. The 984 node has multiple IP addresses on one interface and the mapping 985 between the Host Identity - Interface - IP addresses is a mapping 986 from one to one to many. The used IP address can be changed while the 987 connection exists. 989 When configured multiple addresses to one interface, the node can 990 update this list of addresses to peer nodes. Thus, the different 991 transit providers can be used according to policies defined in the 992 node. The policies can be defined locally or they can be received by 993 other methods. (see policies, TBD) 995 A.2 Transit providers with NATs 997 A transit provider may have NAT boxes in the network. The HIP node 998 connected to a site that is further connected to a transit provider 999 using NATs, must get the knowledge about the NAT box between itself 1000 and the peer node. The address that the HIP node sends to the peer 1001 node must be a public one, thus NATted address is not valid. 1003 The NAT box on the path must support address (and SPI) leasing for 1004 the HIP node. When the HIP node finds out that there is a NAT box, 1005 the host must get a leased address (or a set of addresses) from the 1006 NAT. These addresses are routable at the other side of the NAT. They 1007 still need not to be globally routable as there may be another NAT 1008 box on the path. 1010 Appendix B. Implementation experiences 1011 Intellectual Property Statement 1013 The IETF takes no position regarding the validity or scope of any 1014 intellectual property or other rights that might be claimed to 1015 pertain to the implementation or use of the technology described in 1016 this document or the extent to which any license under such rights 1017 might or might not be available; neither does it represent that it 1018 has made any effort to identify any such rights. Information on the 1019 IETF's procedures with respect to rights in standards-track and 1020 standards-related documentation can be found in BCP-11. Copies of 1021 claims of rights made available for publication and any assurances of 1022 licenses to be made available, or the result of an attempt made to 1023 obtain a general license or permission for the use of such 1024 proprietary rights by implementors or users of this specification can 1025 be obtained from the IETF Secretariat. 1027 The IETF invites any interested party to bring to its attention any 1028 copyrights, patents or patent applications, or other proprietary 1029 rights which may cover technology that may be required to practice 1030 this standard. Please address the information to the IETF Executive 1031 Director. 1033 Full Copyright Statement 1035 Copyright (C) The Internet Society (2003). All Rights Reserved. 1037 This document and translations of it may be copied and furnished to 1038 others, and derivative works that comment on or otherwise explain it 1039 or assist in its implementation may be prepared, copied, published 1040 and distributed, in whole or in part, without restriction of any 1041 kind, provided that the above copyright notice and this paragraph are 1042 included on all such copies and derivative works. However, this 1043 document itself may not be modified in any way, such as by removing 1044 the copyright notice or references to the Internet Society or other 1045 Internet organizations, except as needed for the purpose of 1046 developing Internet standards in which case the procedures for 1047 copyrights defined in the Internet Standards process must be 1048 followed, or as required to translate it into languages other than 1049 English. 1051 The limited permissions granted above are perpetual and will not be 1052 revoked by the Internet Society or its successors or assignees. 1054 This document and the information contained herein is provided on an 1055 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1056 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1057 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1058 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1059 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1061 Acknowledgement 1063 Funding for the RFC Editor function is currently provided by the 1064 Internet Society.