idnits 2.17.1 draft-nikander-multi6-hip-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 171: '...multi-homed host MAY send a list of IP...' RFC 2119 keyword, line 174: '...ew addresses, it MUST verify that the ...' RFC 2119 keyword, line 176: '... an end-host MAY perform such reacha...' RFC 2119 keyword, line 255: '... of ESP MUST be used, i.e., it is no...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 479 has weird spacing: '...xchange is ru...' -- 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 2003) is 7438 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: '1' is defined on line 972, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 986, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2373 (ref. '1') (Obsoleted by RFC 3513) == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-08 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-01 -- No information found for draft-ylitalo-multi6-hc - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 10 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 Ericsson Research Nomadic Lab 4 Expires: May 31, 2004 December 2003 6 Considerations on HIP based IPv6 multi-homing 7 draft-nikander-multi6-hip-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on May 31, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 The Host Identity Protocol implements the identifier locator 38 separation by introduing a new name space and a new layer to the IP 39 stack. The new structure insulates the transport layer protocols 40 from the internetworking layer, thereby allowing transport sessions 41 to remain unaffected even if the underlying IP addresses change. 42 That, in turn, seems to make it easier to solve the so called site 43 multi-homing problem than without introducing such an indirection 44 layer. 46 This document discusses how the proposed HIP mobility and 47 multi-homing solution, described separately, would fit to the IETF 48 multi6 working group requirements. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2 Current venues for HIP work . . . . . . . . . . . . . . . . 4 55 1.3 Baseline HIP multi-homing mechanism . . . . . . . . . . . . 4 56 2. HIP as a site-multi-homing solution . . . . . . . . . . . . 6 57 2.1 Hiding of underlying IP version . . . . . . . . . . . . . . 6 58 2.2 Integrated mobility . . . . . . . . . . . . . . . . . . . . 6 59 2.3 Architectural support for multi-realm connectivity . . . . . 6 60 2.4 Integrated, mandatory end-to-end security . . . . . . . . . 6 61 2.5 High state setup cost . . . . . . . . . . . . . . . . . . . 7 62 3. Using components of HIP or modified HIP instead of full 63 HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1 Using HIP without IPsec ESP . . . . . . . . . . . . . . . . 8 65 3.2 Delaying HIP state setup . . . . . . . . . . . . . . . . . . 8 66 3.2.1 Securing LHIP state setup . . . . . . . . . . . . . . . . . 9 67 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.1 Default router and source address selection . . . . . . . . 11 69 4.2 Selecting primary destination address . . . . . . . . . . . 11 70 4.3 Reacting to addresses becoming unreachable . . . . . . . . . 11 71 5. Evaluation against of RFC 3582 and MULTI6 Solution 72 Questionaire . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.2 Answers to MULTI6 Solution Questionaire . . . . . . . . . . 12 75 5.2.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.2.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 13 77 5.2.3 On the wire . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.2.4 Names, Hosts, Endpoints, or no of the above? . . . . . . . . 16 79 5.3 RFC 3582 Section 3 considerations . . . . . . . . . . . . . 19 80 5.3.1 Multi-Homing capabilities . . . . . . . . . . . . . . . . . 19 81 5.3.2 Additional requirements . . . . . . . . . . . . . . . . . . 21 82 5.4 Security considerations . . . . . . . . . . . . . . . . . . 23 83 6. Security considerations . . . . . . . . . . . . . . . . . . 24 84 Informative references . . . . . . . . . . . . . . . . . . . 25 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 26 86 Intellectual Property and Copyright Statements . . . . . . . 27 88 1. Introduction 90 The IETF multi6 working group is currently calling various 91 alternative solutions as components for an architectural analysis. 92 The aim of that work is to try to understand the architectural design 93 choices and their tradeoffs. 95 This document discusses how a Host Identity Protocol (HIP) based 96 approach could solve the multi6 site multi-homing problem. The draft 97 also presents some ideas on how the HIP architecture could be split 98 into components, some of which could be applied to the multi6 problem 99 without adopting all of the current HIP proposal. 101 1.1 Background 103 The Host Identity Protocol (HIP) is a proposal for changing the TCP/ 104 IP stack architecture by a new name space and a new protocol layer to 105 the stack. The overall design is discussed in the HIP architecture 106 document [3]. The actual protocol details are defined in the HIP 107 protocol specification [2], and the mobility and multi-homing related 108 extensions in the HIP mobility and multi-homing specification [4]. 109 It is expected through this document that the reader is at least 110 superficially familiar with the architecture document and the 111 protocol specifications. 113 The proposed HIP multi-homing mechanism [4] is primarily aimed to be 114 a host multi-homing solution. Basically, it allows two end hosts to 115 inform each other of their IP connectivity. That is, an end-host 116 sends a set of IP addresses to its peer, and the peer makes sure that 117 the end-host is reachable through (some of) these IP addresses. 119 In the baseline HIP solution, a HIP base exchange protocol is run 120 each time a new pair of hosts starts to communicate. This protocol is 121 a four-way handshake, requiring public key cryptographic operations. 122 While such a heavy exchange makes sense for applications where the 123 hosts have a fairly long term relationship, e.g. for e-mail, disk 124 access, etc., it may be too heavy for short term transactions, such 125 as some forms of web browsing etc. It is definitely unsuitable for 126 DNS (see Section 5.2.4.1). Therefore, the architecture has been 127 defined in such a way that each application can be configured either 128 to use HIP or to use legacy IP, without the HIP overhead (and, of 129 course, without any benefits from HIP). 131 While the redundancy (Section 5.3.1.1) and especially transport layer 132 survivability (Section 5.3.1.6) make sense mostly for long term 133 transport sessions, where the state setup may be amortized over a 134 longer period of time, it would be benficial to avoid such a large 135 state setup cost. Therefore, in Section 3, we also describe how some 136 components of HIP could be applied to the multi6 site-multihoming 137 problem without adopting all of HIP. 139 1.2 Current venues for HIP work 141 At the time of writing this version of this draft, a proposal to form 142 a HIP working group is being handled by the IESG. It is expected 143 that the working group charter will be approved in time so that the 144 working group will be able to meet at the 59th IETF meeting in Seoul. 145 The working group charter is expected to be very focused, addressing 146 the more practical aspects of the current HIP proposals. 148 At the same time, there are ongoing discussions about creating a 149 parallel IRTF research group. The charter of the research group 150 would be wider than that of the working group, looking at more 151 distant aspects of HIP, and also studying other proposals for 152 splitting identifiers and locators but HIP. Since the proposed 153 research group does not have a name nor an acronym yet, it is called 154 as the "IRTF XXX RG" in the rest of this document. 156 It is currently expected that if the HIP mobility and multi-homing 157 solution, or some aspects of it, are selected for further work at the 158 multi6 working group, then the resulting work will be chartered at 159 the multi6 WG. In that case some co-operation with the HIP WG and 160 the IRTF XXX RG. 162 1.3 Baseline HIP multi-homing mechanism 164 The baseline HIP multi-homing mechanism is specified in [4]. Here we 165 briefly summarize the mechanism, giving an outline to those 166 impatitient readers that don't have cycles to read the full HIP 167 specifications. 169 As mentioned above, when two HIP hosts start to communicate, they run 170 the HIP base exchange and create an HIP association. As a part of 171 this association, a multi-homed host MAY send a list of IP addresses 172 that it believes to belong to itself. The recipient of these 173 addresses stores them as potential addresses of the peer. Before 174 using any of new addresses, it MUST verify that the peer is indeed 175 reachable through the address. According the current specification, 176 an end-host MAY perform such reachability test at any time, subject 177 to its local policy. Such a reachability test requires only the 178 tested address to work, meaning that such a test can be delayed until 179 the other address(es) become unreachable. 181 The hosts are free to change the information about their addresses at 182 any time. However, note that especially in the case of site 183 multi-homing, one of the addresses may become unreachable while the 184 other one still works. In the typical case, however, this does not 185 require the host to inform its peers about the situation, since even 186 the non-working address still logically exists. 188 Establishing the initial multi-addressing situation, and all changes 189 to that, are protected with strong cryptography. There are no known 190 vulnerabilities in the specified mechanisms. (Note, however, that 191 the fact that there are no _known_ vulnerabilities does not mean that 192 there are no unknown ones. There might be, and given the freshness 193 of the specifications, there probably are.) 195 The current specification outlines a method where one of the peer's 196 addresses is considered as a primary address. By default, all 197 traffic is sent using this address. This practise is similar to how 198 SCTP multi-addressing works, and is designed to work well with 199 current transport layer congestion control. However, the HIP 200 architecture itself would allow multiple addresses to be used in 201 parallel, even for one transport session. Experimentation of such 202 practise is assumed to take place at the IRTF XXX RG. 204 2. HIP as a site-multi-homing solution 206 As mentioned above, HIP multi-homing is primarily designed as a 207 solution for multi-homed end-hosts. As such, it offers a 208 multi-address based baseline solution, similar to other proposed 209 multi-addressing based multi6 proposal. Efforts to adopt the 210 approach to site multi-homing, especially in the case where some 211 hosts within the site and outside of the site may be legacy non-HIP 212 hosts, has been fairly minimal. 214 It is expected that most of what applies to other multi-addressing 215 based multi6 proposals apply also to HIP. 217 Since the multi-homing aspects of HIP do note seem to considerably 218 differ from other multi-address based proposals, the focus in this 219 section is on the factors that differentiate HIP from the other 220 solutions. Multi-homing aspects are covered in Section 5. 222 2.1 Hiding of underlying IP version 224 HIP hides the underlying IP version from applications. That is, an 225 IPv4 legacy application can be run over IPv6, and vice versa, HIP 226 acting as an insulation layer. This also means that the HIP mobility 227 and multi-homing solution allows existing transport sessions to 228 change their underlying connectivityfrom IPv4 to IPv6 and vice versa, 229 as long as both end-hosts remain reachable (either directly or 230 through a gateway). 232 2.2 Integrated mobility 234 The HIP multi-homing mechanism is fully integrated with mobility. In 235 fact, the two mechanism are so integrated that it would be very hard 236 to make them separate. 238 2.3 Architectural support for multi-realm connectivity 240 The HIP architecture allows HIP associations to be router through 241 layer 3.5 middle boxes, thereby extending the associations across 242 multiple IP realms. In other words, HIP would allow controlled 243 NAT-traversal that have not the ill effects of the current NAT 244 practise. However, fully realising such service requires more work, 245 and is subject to study at the IRTF XXX RG. 247 2.4 Integrated, mandatory end-to-end security 249 HIP has its origin as a security solution, aiming to simplify IPsec 250 administration and address mobility at the same time. Hence, HIP as 251 defined today, requires that all payload traffic is protected with 252 IPsec ESP. By default, this adds the overhead of carrying the ESP 253 header and trailer in all packets. Additionally, the current IPsec 254 specifications mandate that either encryption or integrity protection 255 of ESP MUST be used, i.e., it is not allowed to use IPsec without 256 encryption and without integrity protection. Hence, all HIP packets 257 are subject to the cost of symmetric crypto processing on both 258 sending and receiving ends. While this cost is fairly minor in most 259 modern architectures, it may have negative effects on small devices, 260 such as PDAs, and large scale servers. 262 In addition to the header overhead and computational cost, ESP breaks 263 some middle box functionality by making it impossible to inspect and/ 264 or modify the packet contents. 266 It should be noted that when end-to-end security is desirable, HIP 267 adds no additional overhead compared to using standard IPsec 268 mechanisms. Hence, for applications were IPsec based security is 269 adequate and desirable, HIP looks like an optimal or near-optimal 270 multi-homing solution. 272 In Section 3.1, below, we discuss how ESP could be replaced with 273 other mechanisms for the case where end-to-end security is not needed 274 for payload traffic. 276 2.5 High state setup cost 278 The HIP base exchange is a four-way cryptographic authentication 279 protocol, implementing a sigma [10] authenticated Diffie-Hellman 280 exchange, with state-space and CPU-exhaustion denial-of-service 281 protection. A single protocol run requires a few long integer 282 exponentiations, taking a fraction of a second on modern CPU 283 architectures. 285 Compared to other multi6 proposals, the state setup cost of HIP seems 286 to be largest. In Section 3.2 we discuss how this state setup cost 287 might be delayed to a later moment, allowing two hosts to start 288 communicating and creating the state only if they later determine 289 that they want security or want change active IP addresses. In 290 Section 3.2.1 we discuss how the security properties of such delayed 291 state setup might be improved with hash chains. 293 3. Using components of HIP or modified HIP instead of full HIP 295 In this section, we first briefly describe how HIP could be modified 296 so that it would impose less computational overhead, and then how 297 some HIP-like ideas could relate to other multi6 proposals, and vice 298 versa. 300 3.1 Using HIP without IPsec ESP 302 As mentioned above, some applications may have long lasting 303 connections that would benefit from redundancy and transport layer 304 survivability, but would not need end-to-end security. For example, 305 DRM protected video streams using application level encryption might 306 be one such example. In cases like that, it would be beneficial to 307 use HIP without ESP. 309 There seems at least to be two different ways how HIP could possibly 310 be used without ESP: 312 One possibility is to replace the ESP header with a simple header 313 that carries the SPI, similar to the M6 header proposed in the SIM 314 proposal [8]. In the HIP case, the context tag would be the SPI. 316 Another possibility would be to allocate a single bit in the IP 317 header, indicating whether in the receiving end the source and 318 destination locators should be rewritten into identifiers or not. 319 This would be somewhat similar to the NOID proposal [7]. When ESP 320 is not used, there is no replay protection, and therefore there is 321 no need for multiple parallel SAs. 323 Adding support for non-ESP communication would add a need for policy 324 into HIP. For each connection, the end-points would need to decide 325 whether to use ESP or not. Since one of the current HIP goals has 326 been and still is simplicity, this feature has not been added to the 327 current HIP specifications. From a functional point of view, the 328 possibility of not using ESP is a mere performance optimization. 330 3.2 Delaying HIP state setup 332 It might be possible to delay the actual HIP state setup. However, it 333 would not be possible to use ESP before the state has been 334 established. The main benefit from this kind of optimization is to 335 initially avoid the computational cost. 337 This variant is tentatively called LHIP, for Lightweight HIP. 339 The idea goes as follows: 341 1. The Initiator sends an I1, just like in the current 342 specification. However, the I1 packet would contain an extension 343 to indicate that it wants to delay state setup. It could also 344 piggyback the initial payload, e.g., TCP SYN. 346 2. The Responder checks if it already has a state established with 347 the given HITs. If it does, it replies with an R1 as usually, 348 and forgets about the packet. 350 3. The Responder checks it policy to see if it allows delayed state 351 setup for the HITs and IP addresses in I1. If it doesn't, it 352 sends an R1 as usually, and forgets about the packet. On the 353 other hand, if it does allow delayed state setup, and generates a 354 new nonce for lightweight state set up. The lightweight state 355 will consist of the HITs, the IP addresses, and the nonce. The 356 recipient will remember these, either by storing them or 357 algorithmically, for a limited delta period. The Responder 358 replies with a new packet (LR1), which contains the HITs and the 359 nonce. A TCP SYN ACK may be piggypacked on the LR1. 361 4. When the Initiator receives the LR1, it stores the nonce, and and 362 sends and LI2, containing just the HITs and the nonce. 364 5. When the Responder receives the LI2, it knows that some node is 365 reachable at the given IP address. However, it has no assurance 366 that the host is actually the one identified by the HIT. Hence, 367 the HIT cannot be used for access control or any other security 368 purposes -- any node might have claimed to be identified by the 369 HIT. 371 If the Initiator later wants to move or use ESP, it must update the 372 lightweight state to a full HIP association. Similarily, if the 373 Recipient later wants to move, use ESP, or open a new transport 374 session in the reverse direction, it must update the state. Note 375 that the notion is asymmetric here: the Recipient must update the 376 state also in the case of opening new transport sessions, since it 377 has no assurance that the other host actually "owns" the given HIT. 379 It is noteworthy that this lightweight setup is completely insecure, 380 allowing the initator to use any HIT as an identifier for itself. On 381 the other hand, it adds very little overhead to the setup of an 382 initial connection, allowing the TCP three-way handshake to be 383 piggybacked on the protocol. 385 3.2.1 Securing LHIP state setup 387 Based on some initial discussions, it may be feasible to bring some 388 security to the LHIP state setup using hash chains. However, futher 389 analysis would be needed. For an example of how hash chains could be 390 used for securing multi6 related state setup, see [11]. 392 If such hash chains (or something similar) was added to the creation 393 of the lightweight state, the state could probably be used for 394 securing changes in the mobility and multi-homing state of the hosts. 395 However, it would not be sufficient for creating ESP SAs. 397 4. Discussion 399 4.1 Default router and source address selection 401 Source address selection must be based on first selecting the 402 outgoing router, based on the current reachability state, and then 403 source address to be used, not vice versa. 405 4.2 Selecting primary destination address 407 Section 8.4 of [4] briefly discusses how the hosts should select the 408 primary destination address to use for their peers. It should be 409 noted that the currently presented discussion is probably not the 410 optimal way of solving the problem. Further engineering and maybe 411 some research is required on the topic. 413 4.3 Reacting to addresses becoming unreachable 415 In the case of site multi-homing one of the addresses may become 416 unreachablewhile the other one still works. In the typical case, 417 however, this does not require the host to inform its peers about the 418 situation, since even the non-working address still logically exists. 420 Brian Carpenter: It's just as well you don't require this 421 notification. The last node to know that an address is unreachable is 422 the node that address belongs to. Unreachability is discovered at the 423 other end of the multihomed session. 425 5. Evaluation against of RFC 3582 and MULTI6 Solution Questionaire 427 5.1 Approach 429 5.2 Answers to MULTI6 Solution Questionaire 431 5.2.1 Routing 433 As HIP is implemented on the top of IP, it does not directly affect 434 basic IP routing. Routing within any UP realm is performed just as 435 today. The end-hosts maintain a binding table that maps Host 436 Identifiers into a set of IP addresses, and the HIP mobility and 437 multi-homing protocol [4] is used to update these bindings. 439 5.2.1.1 Primary multi-homing solution idea 441 The HIP mobility and multi-homing protocol [4] allows an end-host to 442 send information about all of its IP addresses, both IPv4 and IPv6, 443 to its peers. The peers have to check reachability of these 444 addresses prior to using them for sending large amount of traffic. 445 This mechanism allows interacting HIP hosts to establish 446 multi-addressing based multi-homing state. 448 The exact mechanisms on how a host is supposed to perform address and 449 path selection are not defined in the current HIP specifications. 450 However, the required practise is assumed to be similar to any other 451 multi-addressing based multi-homing solutions. Hence, it is expected 452 that the multi6 WG (instead of the HIP WG) will define the required 453 mechanisms. 455 Some of the above described variations of HIP allow delayed 456 establishment of the multi-addressing state. However, the details 457 such practise are currently undefined and there is no implementation 458 experience on the aspect. 460 5.2.1.2 Uniqueness 462 [I don't understand what the title of this section refers to.] 464 5.2.1.2.1 Mobility 466 HIP addresses mobility. A mobile host sends HIP readdressing 467 information to all of its peer hosts, allowing them to update 468 addressing information. 470 Initial rendezvous is planned to be started with DNS. An initiating 471 host that wants to contact a mobile host is supposed to look up the 472 Host Identifier and a set of current IP addresses from the DNS. The 473 set of current IP addresses may include real active addresses of the 474 mobile host, addresses of a Rendezvous server, or both. 476 Once the initiating host has a tentative set of addresses, it sends 477 an HIP I1 packet to an address. If the address is a real address of 478 the mobile host, the mobile host will directly answer with an R1 479 packet, and the rest of the HIP base exchange is run between the 480 used addresses. At the end the hosts inform each other about their 481 multi-addressing state. 483 If the I1 destination address ia an address of a Rendezvous server, 484 the Rendezvous server will forward the packet to the currently 485 registered address of the mobile host. The mobile host will send an 486 R1 directly back to the initiating host, and the rest of the HIP base 487 exchange is run directly between the mobile host and the initiating 488 host. 490 If a mobile host changes its active address while the HIP base 491 exchange is going on, there will be a timeout and the initating host 492 needs to start again, either using another address from the set of 493 addresses received from the DNS, or remaking the DNS query if 494 necessary. 496 All hosts that use rendezvous servers are assumed to include the 497 rendezvous server address in their active address sets. Hence, if 498 two interacting mobile hosts move at the same time so that the 499 readdressing indications cross each other in the network and get 500 lost, the host will fall back to the rendezvous server address after 501 a timeout. (The length of the timeout is currently unspecified, and 502 subject to local policy of the hosts.) Hence, provided that the 503 hosts have updated their current location to the rendezvous server, 504 the hosts will be able to continue communications. 506 The HIP mobility mechanism is expected to replace Mobile IP for all 507 communication taking place between HIP enabled hosts. When a HIP 508 host is communicating with a legacy host, it may use Mobile IP, 509 provided that the host stack includes both HIP and Mobile IP 510 implementaitons. 512 5.2.2 Identifiers and locators 514 5.2.2.1 Split identifiers and locators 516 HIP is based on the idea of splitting identifiers and locators. 517 Public cryptographic keys are used as identifiers. IP addresses are 518 used as locators. From the routing point-of-view, IP addresses are 519 used just like today. From the applications and transport layer 520 point of view, identifiers (in the form of HITs and LSIs [3]) replace 521 IP addresses. 523 5.2.2.2 Binding lifetime 525 The lifetime of the binding from an identifier to a locator is 526 defined in the protocol messages. Typically it is equal to the 527 lifetime of the locator. The host creating the binding state simply 528 accepts the lifetime from the sending host. 530 5.2.2.3 Update of bindings 532 The bindings are updated by a host sending HIP readdressing 533 paramters, typically in a HIP UPDATE packet. A single packet may 534 update several sets of bindings. 536 Whenever a new address is associated with an identifier, the hosts 537 must verify the reachability of the address before using the address 538 for payload traffic. This procedure is required in order to block 539 flooding attacks [6]. 541 Updating the bindings have no direct effect on transport connections, 542 which will remain up. Changes in the actual paths may have effects 543 on transport connections, such as changes in QoS. 545 5.2.3 On the wire 547 HIP, as currently defined, consists of two protocols. One is a new 548 protocol, the HIP protocol, run directly on the the top of IP. The 549 other one is IPsec ESP. Using telecom terminology, the HIP protocol 550 forms a control plane, and all user plane traffic is encapsulated in 551 ESP. 553 As discussed above, it might be possible to use HIP without requiring 554 all user plane traffic to be ESP encapsulated. However, such 555 practise has not been defined in detail and there are no 556 implementation experience. 558 5.2.3.1 Solution layer 560 HIP can be consider to be a layer 3.5 solution. 562 HIP is applied to every packet, in the form of encapsulating them 563 into ESP envelopes. The ESP SPI field is used to associate the 564 packet with the right end-point identifiers in the receiving end. 566 As described above in Section 3.1, it ESP was not used, a single bit 567 in the IP header might suffice to allow the receiving host to 568 associate HIP and non-HIP traffic with the appropriate sockets. In 569 that case the source and destination IP addresses would be used to 570 associate the packet with the right end-points. This practice has the 571 drawback that does not allow multiple host identifiers to be hosted 572 on a single node. 574 If the single bit approach is deemed infeasible, it would be possible 575 to create a new extension header that would contain a new 576 demultiplexing field. From the HIP demultiplexing point of view, the 577 contents of the field would be similar to ESP SPI. 579 5.2.3.2 Correctness of the selected layer 581 Multi-homing is a phenomenon that clearly appears between hosts. 582 Hence, a multi-homing solution should be located at a layer that has 583 host granularity, and not any finer granularity. This leaves out 584 transport and higher layer solutions. 586 Multi-homing can be considered to be either as an end-to-end or a 587 routing level phenomenon. In the case of end-host multi-homing, 588 where a single host has multiple accesses to the Internet, the 589 situation seems to be best modelled as an end-to-end one. 590 Respectively, the case of intra-transit-provider connectivity, an 591 extreme form of site multi-homing, is probably best modeled as a part 592 of the overall routing topology. Various types of end-site 593 multi-homing (soho...multinational) fall on different locations on 594 this axis. 596 The IP layer contains both end-to-end and routing functions. Hence, 597 IP layer could implement both end-to-end and routing based 598 multi-homing solutions. 600 Since HIP introduces a new name space, Host Identifiers, it is best 601 described as a shim or 3.5 layer solution [9]. In other words, it is 602 end-to-end in nature, affecting some of the current IP layer 603 end-to-end functionality, but relies clearly below the transport 604 layer. 606 A layer 3.5 solution has a number of good proporties: 608 It is possible to continue using unmodified TCP and UDP. 610 It would become possible to move much of the SCTP and DCCP 611 multi-addressing functionality into the new layer. Such 612 functionality would then be shared between them and the legacy 613 transport protocols, TCP and UDP. 615 The approach would make it easier to collect per-path MTU and RTT 616 information, if seen approapriate from the transport 617 point-of-view. 619 The approach does not require any changes to the IP layer or the 620 pseudo header. (But see also Section 3.1.) 622 5.2.3.3 Expansion of packet size 624 The solution does not cause any expansion of packet size of than that 625 caused by ESP. If ESP is not used, the single-bit solution, outlined 626 above, would allow HIP to be used without any expansion of packet 627 size. 629 5.2.3.4 Fragmentation 631 It is expected that HIP solutions report a reduced MTU to upper 632 layer, similar to current ESP practise. Other than that, the 633 standard ESP fragmentation practise is used. The current 634 implementations seem to work, but no-one has performed a detailed 635 analysis. 637 5.2.3.5 Changes to ICMP error semantics 639 The current HIP specifications do not create any new ICMP error 640 messages. However, a detailed analysis is needed to see if there are 641 any subtle changes to the current semantics. Such an analysis has 642 not been made. 644 5.2.4 Names, Hosts, Endpoints, or no of the above? 646 5.2.4.1 Relationship with DNS 648 It is expected that the HIT (or the HI) of each HIP host is stored 649 into the DNS, in addition to the IP address(es). When a HIP host 650 starts to connect to another HIP hosts, it queries for both the HIT/ 651 HI and the addresses. If a HIT/HI is received, the initiating host 652 creates a piece of local state, attempts to create a HIP association 653 with the peer upon first connection request. If the association is 654 created, the hosts establish their multi-addressing state directly. 655 The addresses stored in the DNS are not used beyond building the HIP 656 association. If no HIT/HI are received, the initiating host falls 657 back to using legacy IP. 659 Defining the required new RR type is a working item for the HIP WG. 661 5.2.4.2 Interactions with 2-faced DNS 663 Interactions with 2-faced DNS have not been fully analyzed. However, 664 as HIP reduced the applications' dependency on IP addresses, it looks 665 like that HIP would easily allow 2-faced DNS to be used. 666 Furthermore, if there is a proper HIP aware security gateway between 667 the two domains, it should be possible to fully control the creation 668 of HIP associations between the domains. 670 5.2.4.3 (Non)need for centralized registration 672 HIP does not require centralized registration. The identifiers are 673 public keys, and typically self-generated. 675 It is expected that the IRTF XXX RG will study how to provide a 676 service similar to reverse mapping for the public keys. 678 5.2.4.4 (No) Circular dependencies with DNS 680 DNS is not expected to use HIP. In a typical implementation, this is 681 accomplised by configuring the DNS proxies and servers to bind/ 682 connect to IP addresses, not HITs. 684 5.2.4.5 Multihomed DNS servers 686 Multi-homed DNS servers are expected to continue direct utilization 687 of multiple IP addresses. 689 5.2.4.6 Application/API changes 691 Most old code will just work. Multi-party applications doing 692 IP-address-based referrals will break. 694 the IRTF XXX RG will study how to support such multi-party 695 applications. 697 To gain full benefit from HIP, extensions to the current socket API 698 are expected to be needed. However, using such extensions is not 699 required to benefit from the multi-addressing properties of HIP. 701 5.2.4.7 Backward compatibility and incremental deployment with current 702 IPv6 704 The current implementations allow full compatibility with the current 705 IPv6, with the exception of using a large but unused part of the IPv6 706 address space to represent HITs internally. No requirements are 707 placed on non-multihomed, non-mobile legacy hosts. 709 HIP is designed to be incrementally deployed. It is expected that 710 HIP capable servers announce their capability to run HIP by listing 711 the new resource record in the DNS. Possibilities to run HIP 712 opportunistically, without DNS, is being studied at the IRTF XXX RG. 714 5.2.4.8 Backward compatibility with IPv4 716 HIP works with both IPv4 and IPv6, even allowing simultaneous use of 717 both IPv4 and IPv6 connections. 719 It has not been analyzed how HIP interacts with existing 6to4 720 gateways. Such work is not on the HIP WG charter, but may be pursued 721 at the IRTF XXX RG. 723 5.2.4.9 Interaction with middleboxes 725 Firewalls Since HIP introduces a new control protocol to be run 726 directly over IP, and uses IPsec to secure payload traffic, HIP 727 would break most current firewalls. However, the HIP base 728 exchange and the rest of the control protocol has been carefully 729 designed to be friendly towards future firewalls, allowing HIP 730 aware firewalls to control HIP traffic. 732 NAT HIP, as currently defined, does not work with IP-multiplexing NAT 733 boxes. On the other hand, it would be fairly trivial to build HIP 734 aware NAT devices that would allow multiple Host Identities to be 735 NATed behind one IP address. 737 Web caches Since HIP encrypts by default all traffic, HIP does not 738 work with existing web caches or other application level middle 739 boxes. If HIP was to be used without IPsec (see Section 3.1), Web 740 proxies, and transparent application layer middle boxes might 741 work. However, that hasn't been analyzed. 743 5.2.4.10 Implications on scoped addressing 745 It has not been analyzed how HIP would effect scoped addressing. 747 Multicast Not analyzed. 749 Link local HIP should not have any effects on link local addresses or 750 using them. 752 Son-of-Sitelocal It looks like that HIP might reduce need for site 753 local kind of addresses. 755 5.2.4.11 Layer 2 implications 757 HIP, as such, does not seem to have any direct implications on layer 758 2 or neighbor discovery. However, given that HIP introduces a public 759 key per host, it might be possible to further simplify ND and layer 2 760 security mechanisms. 762 5.2.4.12 Referrals 764 As HIP replaces IP addresses with HITs in application data 765 structures, and since HITs cannot be currently resolved into IP 766 addresses, multi-party applications doing IP-address-based referrals 767 will not work. The IRTF XXX RG will study the support of such 768 multi-party applications. 770 5.2.4.13 Legal stuff / trade marks and name space management 772 Public keys or their hashes are not mnemonic. The name space does 773 not need to be managed. 775 5.3 RFC 3582 Section 3 considerations 777 5.3.1 Multi-Homing capabilities 779 5.3.1.1 Redundancy 781 Path redundancy is fully supported, similar to other solutions based 782 on multi-addressing. More specifically, as soon as the hosts have 783 established multi-addressing state by exchanging REA payloads, the 784 hosts may use the different transit providers interchangeably. The 785 current HIP specifications do not specify how a host detects a path 786 failure; such a mechanism is expected to be specified in the multi6 787 WG. 789 If a failure occurs before the multi-addressing state has been 790 established, e.g., before the HIP base exchange has been completed, 791 the hosts may try to re-create the HIP state using different IP 792 addresses, if available, e.g., from the DNS. However, the HIP 793 specifications do not currently discuss such a situation, and the 794 actual behaviour depends on local implementation. 796 5.3.1.2 Load sharing 798 Load sharing is supported, in the sense that the hosts may use 799 different transit providers interchangeably, similar to other 800 solutiosn based on multi-addressing. 802 The current specification does include a feature that allows a host 803 to control the primary address that it wants its peer to use. If 804 more fine grained control is required, suitable policy mechanisms 805 could be developed on the top of HIP. 807 5.3.1.3 Performance 809 By default, HIP based multi-homing does not require 810 intra-transit-provider links to be used. This is similar to other 811 multi-addressing based solutions. 813 As HIP insulates the transport sessions from the IP addresses, HIP 814 allows more freedom in source or destination address based policy 815 routing. 817 The baseline HIP solution adds a small delay before the first 818 transport sessions between a pair of hosts is established. The 819 duration of the delay depends on latency and available CPU resources, 820 consisting of two round trips of latency and requiring both hosts to 821 compute Diffie-Hellman shared key, one DSA signature, and verify one 822 DSA signature. Using short keys is allowed by the protocol, subject 823 to local policy considerations. 825 5.3.1.4 Policy 827 As of today, HIP does not contain any policy control mechanisms. 828 However, adding such mechanisms seems to be fairly straightforward, 829 not differing from other multi-addressing based solutions. 831 5.3.1.5 Simplicity 833 HIP requires both end hosts to be changed. Most applications do not 834 require any changes; applications that use explicit referral may need 835 to be made HIP aware. Incremental deployment is fully supported. 837 Legacy IPv6 (and IPv4) hosts can be used at a multi-homed site either 838 as such, in which case they do not benefit from multi-homing, or 839 through a HIP proxy, located at the site. If a multi-homed site 840 wants to benefit from multi-homing when communicating with legacy 841 hosts outside of the site, a HIP proxy must be deployed somewhere 842 close to the core network. 844 The exact details of HIP proxies have not been defined yet. 846 The current HIP implementations, with limited multi-homing support, 847 have aroudn 10 000 lines of C code. Adding full multi-homing support, 848 as defined in [4] is expected to add less than 3 000 lines of code. 850 5.3.1.6 Transport layer survivability 852 The solution provides full re-homing transparency for all transport 853 layer sessions, similar to other multi-addressing based solutions. 855 Most of the known current implementations do not support transparency 856 for raw IP, as raw IP is considered to be located the host identity 857 layer. 859 5.3.1.7 Impact on DNS 861 HIP adds a new DNS resource record for each HIP capable host. The 862 details are to be defined in the HIP WG. This new resource record 863 will be queried along with the IP addresses, thereby adding little 864 overhead. 866 For redundancy in initial connections, a HIP capable host should list 867 multiple IP addresses in the DNS. However, these addresses are used 868 only for the initial connection. Once the multi-addressing state has 869 been established, the hosts are independent of DNS. 871 5.3.1.8 Packet filtering 873 HIP is similar to other multi-addressing based solutions. 875 5.3.2 Additional requirements 877 5.3.2.1 Scalability 879 The solution does not impose new requirements on the routing system. 881 From a multi-homing point of view, the only required piece of new 882 infrastructure is the new DNS resource record. Adding such records 883 scales approximately as well as the DNS does today. 885 HIP uses approximately 120 bit pseudo-random identifiers for 886 identifying hosts. According to the birthday paradigm, as long as 887 the total number of hosts remains considerably lower than sqrt(2^120) 888 = 2^60, the probability of identifier collisions remains low. If the 889 number of hosts is expected to grow larger, the length of the 890 identifier can be doubled with minor modifications to the solution. 892 5.3.2.2 Impact on routers 894 The solution does not require changes to IPv6 routers, other than 895 what the multi6 wg has already determined useful for all 896 multi-addressing based solutions. 898 5.3.2.3 Impact on hosts 900 HIP provides full backwards compatibility with legacy hosts. 901 Whenever one of the two communicating hosts is not HIP aware, the 902 applications fall back to levacy IP. 904 HIP does require changes to the host stack. These changes can be 905 classified into two classes: 907 Basic packet processing must be changed to recognize HITs on 908 outgoing packets, and incoming ESP protected HIP packets must 909 replace the IP addresses with HITs. This change is minor, and can 910 be implemented either integral to IPsec, or separate. In a 911 typical implementation, the number of changed and/or added lines 912 is a few hundred. 914 A HIP protocol implementation must be added to the stack. This 915 change is a logically separate function. In a typical 916 implementation, the number of lines required is in order of 10 917 000. 919 The solution does not _require_ changes to the socket API or 920 transport layer. However, it is _expected_ that the socket API and 921 the transport layer will be changed in order to gain full benefit 922 from HIP. 924 As it is currently defined, HIP breaks some multi-party applications 925 that use IP addresses for referral. Solutions to this problem is a 926 research topic, being studied at the IRTF XXX RG. 928 5.3.2.4 Interactions between hosts and the routing system 930 HIP does not require interaction between hosts and the routing 931 system, other than what the multi6 wg has already determined for 932 other multi-addressing based solutions. 934 5.3.2.5 Operations and management 936 HIP implementations are expected to include a facility that allows an 937 administrator to view HIT to address mapping. There is no HIP MIB or 938 PIB, but it can be expected to be added as a working item for the HIP 939 working group in the future. 941 5.3.2.6 Co-operationg between transit providers 943 HIP does not require any co-operation between transit providers. If 944 such co-operation is available, HIP would benefit form it similar to 945 other multi-addressing based solutions. 947 5.3.2.7 Multiple solutions 949 HIP should work well with multi-homing solutions that are located 950 solely at the IP layer, i.e., below HIP. 952 Interoperability with other multi-addressing based solutions depend 953 on many details, and need to be analyzed case-by-case. 955 5.4 Security considerations 957 HIP attempts to raise the security baseline in the Internet by 958 employing IPsec ESP protection by default. 960 6. Security considerations 962 HIP security has been extensively discussed in [3] and [2]. Mobility 963 and multicast related security issues have been briefly discussed in 964 [4]. As this draft is more a discussion draft and not a protocol 965 specification, security considerations related to using HIP 966 components instead of full HIP are currently not discussed anywhere. 967 Such a discussion is planned to be added at a later stage, if this 968 draft goes forward. 970 Informative references 972 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 973 Architecture", RFC 2373, July 1998. 975 [2] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 976 Protocol", draft-moskowitz-hip-08 (work in progress), October 977 2003. 979 [3] Moskowitz, R., "Host Identity Protocol Architecture", 980 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 982 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 983 Identity Protocol", draft-nikander-hip-mm-01 (work in 984 progress), January 2004. 986 [5] Nikander, P., "Mobile IP version 6 Route Optimization Security 987 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 988 in progress), December 2003. 990 [6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 991 solutions", draft-nordmark-multi6-threats-00 (work in 992 progress), October 2003. 994 [7] Nordmark, E., "Multihoming without IP Identifiers", 995 draft-nordmark-multi6-noid-01 (work in progress), October 2003. 997 [8] Nordmark, E., "Strong Identity Multihoming using 128 bit 998 Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim-01 (work 999 in progress), October 2003. 1001 [9] Crocker, D., "CHOICES FOR MULTIADDRESSING", 1002 draft-crocker-mast-analysis-01 (work in progress), October 1003 2003. 1005 [10] Krawczyk, H., "The SIGMA family of key-exchange protocols", 1006 2003. 1008 [11] Ylitalo, J., "Multihoming using Reverse Hash Chains and 1009 Splitted Secrets", draft-ylitalo-multi6-hc-00 (work in 1010 progress), January 2004. 1012 Author's Address 1014 Pekka Nikander 1015 Ericsson Research Nomadic Lab 1017 JORVAS FIN-02420 1018 FINLAND 1020 Phone: +358 9 299 1 1021 EMail: pekka.nikander@nomadiclab.com 1023 Intellectual Property Statement 1025 The IETF takes no position regarding the validity or scope of any 1026 intellectual property or other rights that might be claimed to 1027 pertain to the implementation or use of the technology described in 1028 this document or the extent to which any license under such rights 1029 might or might not be available; neither does it represent that it 1030 has made any effort to identify any such rights. Information on the 1031 IETF's procedures with respect to rights in standards-track and 1032 standards-related documentation can be found in BCP-11. Copies of 1033 claims of rights made available for publication and any assurances of 1034 licenses to be made available, or the result of an attempt made to 1035 obtain a general license or permission for the use of such 1036 proprietary rights by implementors or users of this specification can 1037 be obtained from the IETF Secretariat. 1039 The IETF invites any interested party to bring to its attention any 1040 copyrights, patents or patent applications, or other proprietary 1041 rights which may cover technology that may be required to practice 1042 this standard. Please address the information to the IETF Executive 1043 Director. 1045 Full Copyright Statement 1047 Copyright (C) The Internet Society (2003). All Rights Reserved. 1049 This document and translations of it may be copied and furnished to 1050 others, and derivative works that comment on or otherwise explain it 1051 or assist in its implementation may be prepared, copied, published 1052 and distributed, in whole or in part, without restriction of any 1053 kind, provided that the above copyright notice and this paragraph are 1054 included on all such copies and derivative works. However, this 1055 document itself may not be modified in any way, such as by removing 1056 the copyright notice or references to the Internet Society or other 1057 Internet organizations, except as needed for the purpose of 1058 developing Internet standards in which case the procedures for 1059 copyrights defined in the Internet Standards process must be 1060 followed, or as required to translate it into languages other than 1061 English. 1063 The limited permissions granted above are perpetual and will not be 1064 revoked by the Internet Society or its successors or assignees. 1066 This document and the information contained herein is provided on an 1067 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1068 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1069 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1070 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1071 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1073 Acknowledgement 1075 Funding for the RFC Editor function is currently provided by the 1076 Internet Society.