idnits 2.17.1 draft-nikander-multi6-hip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 169: '...multi-homed host MAY send a list of IP...' RFC 2119 keyword, line 172: '...ew addresses, it SHOULD verify that th...' RFC 2119 keyword, line 173: '.... This verification MAY be skipped if...' RFC 2119 keyword, line 175: '...ion, an end-host MAY perform such reac...' RFC 2119 keyword, line 254: '... 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 546 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 (July 15, 2004) is 7225 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 1051, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1064, 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 (-10) exists of draft-ietf-hip-base-00 == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-01 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Nikander 2 Internet-Draft Ericsson Research Nomadic Lab 3 Expires: January 13, 2005 T. Henderson 4 The Boeing Company 5 July 15, 2004 7 Considerations on HIP based IPv6 multi-homing 8 draft-nikander-multi6-hip-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 13, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 The Host Identity Protocol implements the identifier locator 39 separation by introducing a new name space and a new layer to the IP 40 stack. The new structure insulates the transport layer protocols 41 from the internetworking layer, thereby allowing transport sessions 42 to remain unaffected even if the underlying IP addresses change. 43 That, in turn, seems to make it easier to solve the so called site 44 multi-homing problem than without introducing such an indirection 45 layer. 47 This document discusses how the proposed HIP mobility and 48 multi-homing solution, described separately, would fit to the IETF 49 multi6 working group requirements. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Current venues for HIP work . . . . . . . . . . . . . . . . 4 56 1.3 Baseline HIP multi-homing mechanism . . . . . . . . . . . . 4 57 2. HIP as a site-multi-homing solution . . . . . . . . . . . . 6 58 2.1 Hiding of underlying IP version . . . . . . . . . . . . . . 6 59 2.2 Integrated mobility . . . . . . . . . . . . . . . . . . . . 6 60 2.3 Architectural support for multi-realm connectivity . . . . . 6 61 2.4 Integrated, mandatory end-to-end security . . . . . . . . . 6 62 2.5 High state setup cost . . . . . . . . . . . . . . . . . . . 7 63 2.6 Comparison with other Group-F multi6 proposals . . . . . . . 7 64 3. Using components of HIP or modified HIP instead of full 65 HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1 Using HIP without IPsec ESP . . . . . . . . . . . . . . . . 9 67 3.2 Delaying HIP state setup . . . . . . . . . . . . . . . . . . 9 68 3.2.1 Securing LHIP state setup . . . . . . . . . . . . . . . . . 10 69 3.3 Using HIP with routable AIDs . . . . . . . . . . . . . . . . 11 70 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.1 Default router and source address selection . . . . . . . . 12 72 4.2 Selecting primary destination address . . . . . . . . . . . 12 73 4.3 Reacting to addresses becoming unreachable . . . . . . . . . 12 74 5. Evaluation against of RFC 3582 and MULTI6 Solution 75 Questionaire . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2 Answers to MULTI6 Solution Questionaire . . . . . . . . . . 13 78 5.2.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 14 80 5.2.3 On the wire . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.2.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 17 82 5.3 RFC 3582 Section 3 considerations . . . . . . . . . . . . . 20 83 5.3.1 Multi-Homing capabilities . . . . . . . . . . . . . . . . . 20 84 5.3.2 Additional requirements . . . . . . . . . . . . . . . . . . 22 85 5.4 Security considerations . . . . . . . . . . . . . . . . . . 24 86 6. Security considerations . . . . . . . . . . . . . . . . . . 25 87 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Informative references . . . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 90 Intellectual Property and Copyright Statements . . . . . . . 29 92 1. Introduction 94 The IETF multi6 working group is currently calling various 95 alternative solutions as components for an architectural analysis. 96 The aim of that work is to try to understand the architectural design 97 choices and their tradeoffs. 99 This document discusses how a Host Identity Protocol (HIP) based 100 approach could solve the multi6 site multi-homing problem. The draft 101 also presents some ideas on how the HIP architecture could be split 102 into components, some of which could be applied to the multi6 problem 103 without adopting all of the current HIP proposal. 105 1.1 Background 107 The Host Identity Protocol (HIP) is a proposal for changing the TCP/ 108 IP stack architecture by introducing a new name space and a new 109 protocol layer to the stack. The overall design is discussed in the 110 HIP architecture document [3]. The actual protocol details are 111 defined in the HIP protocol specification [2], and the mobility and 112 multi-homing related extensions in the HIP mobility and multi-homing 113 specification [4]. It is expected through this document that the 114 reader is at least superficially familiar with the architecture 115 document and the protocol specifications. 117 The proposed HIP multi-homing mechanism [4] is primarily aimed to be 118 a host multi-homing solution. Basically, it allows two end hosts to 119 inform each other of their IP connectivity. That is, an end-host 120 sends a set of IP addresses to its peer, and the peer makes sure that 121 the end-host is reachable through (some of) these IP addresses. 123 In the baseline HIP solution, a HIP base exchange protocol is run 124 each time a new pair of hosts starts to communicate. This protocol is 125 a four-way handshake, requiring public key cryptographic operations. 126 While such a heavy exchange makes sense for applications where the 127 hosts have a fairly long term relationship, e.g. for e-mail, disk 128 access, etc., it may be too heavy for short term transactions, such 129 as some forms of web browsing etc. It is definitely unsuitable for 130 DNS (see Section 5.2.4.1). Therefore, the architecture has been 131 defined in such a way that each application can be configured either 132 to use HIP or to use legacy IP, without the HIP overhead (and, of 133 course, without any benefits from HIP). 135 While the redundancy (Section 5.3.1.1) and especially transport layer 136 survivability (Section 5.3.1.6) make sense mostly for long term 137 transport sessions, where the state setup may be amortized over a 138 longer period of time, it would be benficial to avoid such a large 139 state setup cost. Therefore, in Section 3, we also describe how some 140 components of HIP could be applied to the multi6 site-multihoming 141 problem without adopting all of HIP. 143 1.2 Current venues for HIP work 145 HIP is being developed in an IETF Working Group within the Internet 146 Area, and a parallel IRTF Research Group. The charter of the IETF 147 Working Group is to develop a minimal set of specifications that can 148 enable HIP experimentation on a wide scale, including the base 149 protocol, DNS resource record definition, and basic mobility and host 150 multihoming. The charter of the IRTF Research Group is to study the 151 potential effects on the Internet of wide scale HIP deployment, and 152 more broadly, the consequences of wide scale adoption of any type of 153 separation of the identifier and locator roles of IP addresses. 155 It is currently expected that if the HIP mobility and multi-homing 156 solution, or some aspects of it, are selected for further work at the 157 multi6 working group, then the resulting work will be chartered at 158 the multi6 WG. In that case, some co-operation with the HIP WG and 159 the IRTF HIP RG is needed. 161 1.3 Baseline HIP multi-homing mechanism 163 The baseline HIP multi-homing mechanism is specified in [4]. Here we 164 briefly summarize the mechanism, giving an outline to those impatient 165 readers that don't have cycles to read the full HIP specifications. 167 As mentioned above, when two HIP hosts start to communicate, they run 168 the HIP base exchange and create an HIP association. As a part of 169 this association, a multi-homed host MAY send a list of IP addresses 170 that it believes to belong to itself. The recipient of these 171 addresses stores them as potential addresses of the peer. Before 172 using any of new addresses, it SHOULD verify that the peer is indeed 173 reachable through the address. This verification MAY be skipped if 174 the peer host is fully trusted; see [4] for details. According to 175 the current specification, an end-host MAY perform such reachability 176 test at any time, subject to its local policy. Such a reachability 177 test requires only the tested address to work, meaning that such a 178 test can be delayed until the other address(es) become unreachable. 180 The hosts are free to change the information about their addresses at 181 any time. However, note that especially in the case of site 182 multi-homing, one of the addresses may become unreachable while the 183 other one still works. In the typical case, however, this does not 184 require the host to inform its peers about the situation, since even 185 the non-working address still logically exists. 187 Establishing the initial multi-addressing situation, and all changes 188 to that, are protected with strong cryptography. There are no known 189 vulnerabilities in the specified mechanisms. (Note, however, that 190 the fact that there are no _known_ vulnerabilities does not mean that 191 there are no unknown ones. There might be, and given the freshness 192 of the specifications, there probably are.) 194 The current specification outlines a method where one of the peer's 195 addresses is considered as a primary address. By default, all 196 traffic is sent using this address. This practise is similar to how 197 SCTP multi-addressing works, and is designed to work well with 198 current transport layer congestion control. However, the HIP 199 architecture itself would allow multiple addresses to be used in 200 parallel, even for one transport session. Experimentation of such 201 practise is assumed to take place at the IRTF HIP RG. 203 2. HIP as a site-multi-homing solution 205 As mentioned above, HIP multi-homing is primarily designed as a 206 solution for multi-homed end-hosts. As such, it offers a 207 multi-address based baseline solution, similar to other 208 multi-addressing based multi6 proposals. Efforts to adopt the 209 approach to site multi-homing, especially in the case where some 210 hosts within the site and outside of the site may be legacy non-HIP 211 hosts, has been fairly minimal. 213 It is expected that most of what applies to other multi-addressing 214 based multi6 proposals apply also to HIP. 216 Since the multi-homing aspects of HIP do not seem to considerably 217 differ from other multi-address based proposals, the focus in this 218 section is on the factors that differentiate HIP from the other 219 solutions. Multi-homing aspects are covered in Section 5. 221 2.1 Hiding of underlying IP version 223 HIP hides the underlying IP version from applications. That is, an 224 IPv4 legacy application can be run over IPv6, and vice versa, HIP 225 acting as an insulation layer. This also means that the HIP mobility 226 and multi-homing solution allows existing transport sessions to 227 change their underlying connectivity from IPv4 to IPv6 and vice 228 versa, as long as both end-hosts remain reachable (either directly or 229 through a gateway). 231 2.2 Integrated mobility 233 The HIP multi-homing mechanism is fully integrated with mobility. In 234 fact, the two mechanism are so integrated that it would be very hard 235 to make them separate. 237 2.3 Architectural support for multi-realm connectivity 239 The HIP architecture allows HIP associations to be routed through 240 layer 3.5 middle boxes, thereby extending the associations across 241 multiple IP realms. In other words, HIP would allow controlled 242 NAT-traversal that does not have the ill effects of the current NAT 243 practise. However, fully realising such service requires more work, 244 and is subject to study at the IRTF HIP RG. 246 2.4 Integrated, mandatory end-to-end security 248 HIP has its origin as a security solution, aiming to simplify IPsec 249 administration and to address mobility at the same time. Hence, HIP 250 as defined today, requires that all payload traffic is protected with 251 IPsec ESP. By default, this adds the overhead of carrying the ESP 252 header and trailer in all packets. Additionally, the current IPsec 253 specifications mandate that either encryption or integrity protection 254 of ESP MUST be used, i.e., it is not allowed to use IPsec without 255 encryption and without integrity protection. Hence, all HIP packets 256 are subject to the cost of symmetric crypto processing on both 257 sending and receiving ends. While this cost is fairly minor in most 258 modern architectures, it may have negative effects on small devices, 259 such as PDAs, and large scale servers. 261 In addition to the header overhead and computational cost, ESP breaks 262 some middle box functionality by making it impossible to inspect and/ 263 or modify the packet contents. 265 It should be noted that when end-to-end security is desirable, HIP 266 adds no additional overhead compared to using standard IPsec 267 mechanisms. Hence, for applications were IPsec based security is 268 adequate and desirable, HIP looks like an optimal or near-optimal 269 multi-homing solution. 271 In Section 3.1, below, we discuss how ESP could be replaced with 272 other mechanisms for the case where end-to-end security is not needed 273 for payload traffic. 275 2.5 High state setup cost 277 The HIP base exchange is a four-way cryptographic authentication 278 protocol, implementing a sigma [11] authenticated Diffie-Hellman 279 exchange, with state-space and CPU-exhaustion denial-of-service 280 protection. The initiator performs one public-key (DSA) signature and 281 two signature verifications, while the responder performs one or two 282 signatures and one verification. A single protocol run requires a few 283 long integer exponentiations, taking a fraction of a second on modern 284 CPU architectures. 286 2.6 Comparison with other Group-F multi6 proposals 288 HIP has been classified into one of a set of multi6 proposals, known 289 as "Group F", that propose a "Wedgelayer 3.5 / Fat IP" solution as 290 shown in Figure 1. 292 +-----------------------------------+ 293 | Transport Protocols | 294 +-----------------------------------+ 295 | AH | ESP | Frag/reass | Dest opts | 296 +-----------------------------------+ 297 | Wedge layer | 298 +-----------------------------------+ 299 | IP | 300 ------------------------------------+ 302 Figure 1: Protocol stack 304 Recently on the multi6 mailing list, a number of these Group F 305 proposals have been contrasted with respect to how they make use of 306 Application Identifiers (AIDs), Context Identifiers (CIDs), Context 307 Identification Tags (CIDTs), and IP layer locators. As presently 308 specified in [2], HIP uses Host Identity Tags (HITs), which are 309 hashes of the host identity public keys, as both AIDs and CIDs, and 310 uses IPsec SPIs as CIDTs. 312 Compared to other multi6 proposals, the state setup cost of HIP seems 313 to be largest. In Section 3.2 we discuss how this state setup cost 314 might be delayed to a later moment, allowing two hosts to start 315 communicating and creating the state only if they later determine 316 that they want security or want to change active IP addresses. In 317 Section 3.2.1 we discuss how the security properties of such delayed 318 state setup might be improved with hash chains. 320 In HIP, the AIDs have strong cryptographic properties but are not 321 routable, which can cause problems for application level referrals. 322 In Section 3.3, we discuss the potential for making HIP AIDs 323 routable. 325 3. Using components of HIP or modified HIP instead of full HIP 327 In this section, we first briefly describe how HIP could be modified 328 so that it would impose less computational overhead, and then how 329 some HIP-like ideas could relate to other multi6 proposals, and vice 330 versa. 332 3.1 Using HIP without IPsec ESP 334 As mentioned above, some applications may have long lasting 335 connections that would benefit from redundancy and transport layer 336 survivability, but would not need end-to-end security. DRM protected 337 video streams using application level encryption might be one such 338 example. In cases like that, it would be beneficial to use HIP 339 without ESP. 341 There seems at least to be two different ways how HIP could possibly 342 be used without ESP: 344 1. One possibility is to replace the ESP header with a simple header 345 that carries the SPI, similar to the M6 header proposed in the 346 SIM proposal [9]. In the HIP case, the context tag (CIDT) would 347 be the SPI. 349 2. Another possibility would be to allocate a single bit in the IP 350 header, indicating whether in the receiving end the source and 351 destination locators should be rewritten into identifiers or not. 352 This would be somewhat similar to the NOID [7] and CB64 [8] 353 proposals. When ESP is not used, there is no replay protection, 354 and therefore there is no need for multiple parallel SAs. In 355 this case, the CIDTs would be based on the IPv6 flow IDs and the 356 locators. 358 Adding support for non-ESP communication would add a need for policy 359 into HIP. For each connection, the end-points would need to decide 360 whether to use ESP or not. Since one of the current HIP goals has 361 been and still is simplicity, this feature has not been added to the 362 current HIP specifications. From a functional point of view, the 363 possibility of not using ESP is a mere performance optimization. 365 3.2 Delaying HIP state setup 367 It might be possible to delay the actual HIP state setup. However, it 368 would not be possible to use ESP before the state has been 369 established. The main benefit from this kind of optimization is to 370 initially avoid the computational cost. 372 This variant is tentatively called LHIP, for Lightweight HIP. 374 The idea goes as follows: 376 1. The Initiator sends an I1, just like in the current 377 specification. However, the I1 packet would contain an extension 378 to indicate that it wants to delay state setup. It could also 379 piggyback the initial payload, e.g., TCP SYN. 381 2. The Responder checks it policy to see if it allows delayed state 382 setup for the HITs and IP addresses in I1. If it doesn't, it 383 sends an R1 as usual, and forgets about the packet. On the other 384 hand, if it does allow delayed state setup, it generates a new 385 nonce for lightweight state set up. The lightweight state will 386 consist of the HITs, the IP addresses, and the nonce. The 387 recipient will remember these, either by storing them or 388 algorithmically, for a limited delta period. The Responder 389 replies with a new packet (LR1), which contains the HITs and the 390 nonce. A TCP SYN ACK may be piggybacked on the LR1. 392 3. When the Initiator receives the LR1, it stores the nonce, and 393 sends an LI2, containing just the HITs and the nonce. 395 4. When the Responder receives the LI2, it knows that some node is 396 reachable at the given IP address. However, it has no assurance 397 that the host is actually the one identified by the HIT. Hence, 398 the HIT cannot be used for access control or any other security 399 purposes -- any node might have claimed to be identified by the 400 HIT. 402 If the Initiator later wants to move or use ESP, it must update the 403 lightweight state to a full HIP association. Similarily, if the 404 Recipient later wants to move, use ESP, or open a new transport 405 session in the reverse direction, it must update the state. Note 406 that the notion is asymmetric here: the Recipient must update the 407 state also in the case of opening new transport sessions, since it 408 has no assurance that the other host actually "owns" the given HIT. 410 It is noteworthy that this lightweight setup is completely insecure, 411 allowing the initator to use any HIT as an identifier for itself. On 412 the other hand, it adds very little overhead to the setup of an 413 initial connection, allowing the TCP three-way handshake to be 414 piggybacked on the protocol. 416 3.2.1 Securing LHIP state setup 418 Based on some initial discussions, it may be feasible to bring some 419 security to the LHIP state setup using hash chains. However, futher 420 analysis would be needed. For an example of how hash chains could be 421 used for securing multi6 related state setup, see [12]. 423 If such hash chains (or something similar) was added to the creation 424 of the lightweight state, the state could probably be used for 425 securing changes in the mobility and multi-homing state of the hosts. 426 However, it would not be sufficient for creating ESP SAs. 428 3.3 Using HIP with routable AIDs 430 As mentioned above in Section 2.6, HIP completely decouples upper 431 layer protocols (ULP) from IP layer locators. Specifically, HITs are 432 used in the transport layer pseudoheader for checksum computations, 433 and HITs may be passed to the application, depending on the 434 implementation. Because locators are not used in the checksum, the 435 transport layer entities cannot communicate until a protocol exchange 436 establishes the AIDs to use for the session. Because HITs may be 437 passed to the application, application level referrals may cause a 438 HIT, treated as a locator by the application, to be passed to another 439 non-multi6-aware host. 441 It seems possible to modify HIP to use routable AIDs rather than HITs 442 as the AIDs. One such possibility would be to use the lower-order 443 bits of the HIT as the interface ID of the primary locator of the 444 host, which is then combined with the subnet prefix to form a 445 routable AID. This type of AID has cryptographic authentication 446 properties, although weaker than those of full HITs, and somewhat 447 more susceptible to collisions. Such a change does not seem to 448 detract from the cryptographic properties of a full HIP base 449 exchange, which could be conducted later or upon detection of 450 collision, or initially as presently defined in [2]. In combination 451 with a lighter-weight initial exchange, this could make the protocol 452 very similar to CB64 [8]. Note also that there is no requirement to 453 use a crypto-based locator; if an initial exchange establishes 454 context that prevents session theft, such as described in the WIMP 455 [12] proposal, any type of AID may be used. This type of operation 456 may have certain privacy advantages. 458 The change required to the HIP base specification would be to use the 459 initial locators as the AIDs of the transport layer checksums. Note 460 that HITs may still be passed to applications for HIP-aware 461 applications, but HITs would no longer be passed in place of locators 462 to non-HIP-aware applications. 464 4. Discussion 466 4.1 Default router and source address selection 468 Source address selection must be based on first selecting the 469 outgoing router, based on the current reachability state, and then 470 source address to be used, not vice versa. 472 4.2 Selecting primary destination address 474 Section 8.4 of [4] briefly discusses how the hosts should select the 475 primary destination address to use for their peers. It should be 476 noted that the currently presented discussion is probably not the 477 optimal way of solving the problem. Further engineering and maybe 478 some research is required on the topic. 480 4.3 Reacting to addresses becoming unreachable 482 In the case of site multi-homing one of the addresses may become 483 unreachable while the other one still works. In the typical case, 484 however, this does not require the host to inform its peers about the 485 situation, since even the non-working address still logically exists. 487 Brian Carpenter: It's just as well you don't require this 488 notification. The last node to know that an address is unreachable is 489 the node that address belongs to. Unreachability is discovered at the 490 other end of the multihomed session. 492 5. Evaluation against of RFC 3582 and MULTI6 Solution Questionaire 494 5.1 Approach 496 5.2 Answers to MULTI6 Solution Questionaire 498 5.2.1 Routing 500 As HIP is implemented on top of IP, it does not directly affect basic 501 IP routing. Routing within any IP realm is performed just as today. 502 The end-hosts maintain a binding table that maps Host Identifiers 503 into a set of IP addresses, and the HIP mobility and multi-homing 504 protocol [4] is used to update these bindings. 506 5.2.1.1 Primary multi-homing solution idea 508 The HIP mobility and multi-homing protocol [4] allows an end-host to 509 send information about all of its IP addresses, both IPv4 and IPv6, 510 to its peers. The peers have to check reachability of these 511 addresses prior to using them for sending large amount of traffic. 512 This mechanism allows interacting HIP hosts to establish 513 multi-addressing based multi-homing state. 515 The exact mechanisms on how a host is supposed to perform address and 516 path selection are not defined in the current HIP specifications. 517 However, the required practise is assumed to be similar to any other 518 multi-addressing based multi-homing solutions. Hence, it is expected 519 that the multi6 WG (instead of the HIP WG) will define the required 520 mechanisms. 522 Some of the above described variations of HIP allow delayed 523 establishment of the full HIP association. However, the details such 524 practise are currently undefined and there is no implementation 525 experience on the aspect. 527 5.2.1.2 Uniqueness 529 [I don't understand what the title of this section refers to.] 531 5.2.1.2.1 Mobility 533 HIP addresses mobility. A mobile host sends HIP readdressing 534 information to all of its peer hosts, allowing them to update 535 addressing information. 537 Initial rendezvous is planned to be started with DNS. An initiating 538 host that wants to contact a mobile host is supposed to look up the 539 Host Identifier and a set of current IP addresses from the DNS. The 540 set of current IP addresses may include real active addresses of the 541 mobile host, addresses of a Rendezvous server, or both. 543 Once the initiating host has a tentative set of addresses, it sends 544 an HIP I1 packet to an address. If the address is a real address of 545 the mobile host, the mobile host will directly answer with an R1 546 packet, and the rest of the HIP base exchange is run between the 547 used addresses. At the end the hosts inform each other about their 548 multi-addressing state. 550 If the I1 destination address is an address of a Rendezvous server, 551 the Rendezvous server will forward the packet to the currently 552 registered address of the mobile host. The mobile host will send an 553 R1 directly back to the initiating host, and the rest of the HIP base 554 exchange is run directly between the mobile host and the initiating 555 host. 557 If a mobile host changes its active address while the HIP base 558 exchange is going on, there will be a timeout and the initating host 559 needs to start again, either using another address from the set of 560 addresses received from the DNS, or remaking the DNS query if 561 necessary. 563 All hosts that use rendezvous servers are assumed to include the 564 rendezvous server address in their active address sets. Hence, if 565 two interacting mobile hosts move at the same time so that the 566 readdressing indications cross each other in the network and get 567 lost, the host will fall back to the rendezvous server address after 568 a timeout. (The length of the timeout is currently unspecified, and 569 subject to local policy of the hosts.) Hence, provided that the 570 hosts have updated their current location to the rendezvous server, 571 the hosts will be able to continue communications. 573 The HIP mobility mechanism is expected to replace Mobile IP for all 574 communication taking place between HIP enabled hosts. When a HIP 575 host is communicating with a legacy host, it may use Mobile IP, 576 provided that the host stack includes both HIP and Mobile IP 577 implementaitons. 579 5.2.2 Identifiers and locators 581 5.2.2.1 Split identifiers and locators 583 HIP is based on the idea of splitting identifiers and locators. 584 Public cryptographic keys are used as identifiers. IP addresses are 585 used as locators. From the routing point-of-view, IP addresses are 586 used just like today. From the applications and transport layer 587 point of view, identifiers (in the form of HITs and LSIs [3]) replace 588 IP addresses, unless a change as described in Section 3.3 is made to 589 HIP. 591 5.2.2.2 Binding lifetime 593 The lifetime of the binding from an identifier to a locator is 594 defined in the protocol messages. Typically it is equal to the 595 lifetime of the locator. The host creating the binding state simply 596 accepts the lifetime from the sending host. 598 5.2.2.3 Update of bindings 600 The bindings are updated by a host sending HIP readdressing 601 paramters, typically in a HIP UPDATE packet. A single packet may 602 update several sets of bindings. 604 Whenever a new address is associated with an identifier, the hosts 605 must verify the reachability of the address before using the address 606 for payload traffic. This procedure is required in order to block 607 flooding attacks [6]. 609 Updating the bindings have no direct effect on transport connections, 610 which will remain up. Changes in the actual paths may have effects 611 on transport connections, such as changes in QoS. 613 5.2.3 On the wire 615 HIP, as currently defined, consists of two protocols. One is a new 616 protocol, the HIP protocol, run directly on the the top of IP. The 617 other one is IPsec ESP. Using telecom terminology, the HIP protocol 618 forms a control plane, and all user plane traffic is encapsulated in 619 ESP. 621 As discussed above, it might be possible to use HIP without requiring 622 all user plane traffic to be ESP encapsulated. However, such 623 practise has not been defined in detail and there are no 624 implementation experience. 626 5.2.3.1 Solution layer 628 HIP can be consider to be a layer 3.5 solution. 630 HIP is applied to every packet, in the form of encapsulating them 631 into ESP envelopes. The ESP SPI field is used to associate the 632 packet with the right end-point identifiers in the receiving end. 634 As described above in Section 3.1, it ESP was not used, a single bit 635 in the IP header might suffice to allow the receiving host to 636 associate HIP and non-HIP traffic with the appropriate sockets. In 637 that case the source and destination IP addresses would be used to 638 associate the packet with the right end-points. This practice has the 639 drawback that does not allow multiple host identifiers to be hosted 640 on a single node. 642 If the single bit approach is deemed infeasible, it would be possible 643 to create a new extension header that would contain a new 644 demultiplexing field. From the HIP demultiplexing point of view, the 645 contents of the field would be similar to ESP SPI. 647 5.2.3.2 Correctness of the selected layer 649 Multi-homing is a phenomenon that clearly appears between hosts, not 650 between applications or transport sessions. Hence, a multi-homing 651 solution should be located at a layer that has host granularity, and 652 not any finer granularity. This leaves out transport and higher 653 layer solutions. 655 Multi-homing can be considered to be either as an end-to-end or a 656 routing level phenomenon. In the case of end-host multi-homing, 657 where a single host has multiple accesses to the Internet, the 658 situation seems to be best modelled as an end-to-end one. 659 Respectively, the case of intra-transit-provider connectivity, an 660 extreme form of site multi-homing, is probably best modeled as a part 661 of the overall routing topology. Various types of end-site 662 multi-homing (soho...multinational) fall on different locations on 663 this axis. 665 The IP layer contains both end-to-end and routing functions. Hence, 666 IP layer could implement both end-to-end and routing based 667 multi-homing solutions. 669 Since HIP introduces a new name space, Host Identifiers, it is best 670 described as a shim or 3.5 layer solution [10]. In other words, it 671 is end-to-end in nature, affecting some of the current IP layer 672 end-to-end functionality, but relies clearly below the transport 673 layer. 675 A layer 3.5 solution has a number of good properties: 677 It is possible to continue using unmodified TCP and UDP. 679 It would become possible to move much of the SCTP and DCCP 680 multi-addressing functionality into the new layer. Such 681 functionality would then be shared between them and the legacy 682 transport protocols, TCP and UDP. 684 The approach would make it easier to collect per-path MTU and RTT 685 information, if seen appropriate from the transport point-of-view. 687 The approach does not require any changes to the IP layer or the 688 pseudo header. (But see also Section 3.1.) 690 5.2.3.3 Expansion of packet size 692 The solution does not cause any expansion of packet size other than 693 that caused by ESP. If ESP is not used, the single-bit solution, 694 outlined above, would allow HIP to be used without any expansion of 695 packet size. 697 5.2.3.4 Fragmentation 699 It is expected that HIP solutions report a reduced MTU to upper 700 layer, similar to current ESP practise. Other than that, the 701 standard ESP fragmentation practise is used. The current 702 implementations seem to work, but no-one has performed a detailed 703 analysis. 705 5.2.3.5 Changes to ICMP error semantics 707 The current HIP specifications do not create any new ICMP error 708 messages. However, a detailed analysis is needed to see if there are 709 any subtle changes to the current semantics. Such an analysis has 710 not been made. 712 5.2.4 Names, Hosts, Endpoints, or none of the above? 714 5.2.4.1 Relationship with DNS 716 It is expected that the HIT (or the HI) of each HIP host is stored 717 into the DNS, in addition to the IP address(es). When a HIP host 718 starts to connect to another HIP host, it queries for both the HIT/HI 719 and the addresses. If a HIT/HI is received, the initiating host 720 creates a piece of local state, attempts to create a HIP association 721 with the peer upon first connection request. If the association is 722 created, the hosts establish their multi-addressing state directly. 723 The addresses stored in the DNS are not used beyond building the HIP 724 association. If no HIT/HI are received, the initiating host falls 725 back to using legacy IP. 727 Defining the required new RR type is a working item for the HIP WG. 729 5.2.4.2 Interactions with 2-faced DNS 731 Interactions with 2-faced DNS have not been fully analyzed. However, 732 as HIP reduced the applications' dependency on IP addresses, it looks 733 like that HIP would easily allow 2-faced DNS to be used. 734 Furthermore, if there is a proper HIP aware security gateway between 735 the two domains, it should be possible to fully control the creation 736 of HIP associations between the domains. 738 5.2.4.3 (Non)need for centralized registration 740 HIP does not require centralized registration. The identifiers are 741 public keys, and typically self-generated. 743 It is expected that the IRTF HIP RG will study how to provide a 744 service similar to reverse mapping for the public keys. 746 5.2.4.4 (No) Circular dependencies with DNS 748 DNS is not expected to use HIP. In a typical implementation, this is 749 accomplised by configuring the DNS proxies and servers to bind/ 750 connect to IP addresses, not HITs. 752 5.2.4.5 Multihomed DNS servers 754 Multi-homed DNS servers are expected to continue direct utilization 755 of multiple IP addresses. 757 5.2.4.6 Application/API changes 759 Most old code will just work. Multi-party applications doing 760 IP-address-based referrals will break, unless HIP uses routable AIDs 761 as described in Section 3.3. The IRTF HIP RG will study how to 762 support such multi-party applications. 764 To gain full benefit from HIP, extensions to the current socket API 765 are expected to be needed. However, using such extensions is not 766 required to benefit from the multi-addressing properties of HIP. 768 5.2.4.7 Backward compatibility and incremental deployment with current 769 IPv6 771 The current implementations allow full compatibility with the current 772 IPv6, with the exception of using a large but unused part of the IPv6 773 address space to represent HITs internally. No requirements are 774 placed on non-multihomed, non-mobile legacy hosts. 776 HIP is designed to be incrementally deployed. It is expected that 777 HIP capable servers announce their capability to run HIP by listing 778 the new resource record in the DNS. Possibilities to run HIP 779 opportunistically, without DNS, are to be studied at the IRTF HIP RG. 781 5.2.4.8 Backward compatibility with IPv4 783 HIP works with both IPv4 and IPv6, even allowing simultaneous use of 784 both IPv4 and IPv6 connections. 786 It has not been analyzed how HIP interacts with existing 6to4 787 gateways. Such work is not on the HIP WG charter, but may be pursued 788 at the IRTF HIP RG. 790 5.2.4.9 Interaction with middleboxes 792 Firewalls. Since HIP introduces a new control protocol to be run 793 directly over IP, and uses IPsec to secure payload traffic, HIP 794 would break most current firewalls. However, the HIP base 795 exchange and the rest of the control protocol has been carefully 796 designed to be friendly towards future firewalls, allowing HIP 797 aware firewalls to control HIP traffic. 799 NAT. HIP, as currently defined, does not work with IP-multiplexing 800 NAT boxes. On the other hand, it would be fairly trivial to build 801 HIP aware NAT devices that would allow multiple Host Identities to 802 be NATed behind one IP address. 804 Web caches. Since HIP encrypts by default all traffic, HIP does not 805 work with existing web caches or other application level middle 806 boxes. If HIP was to be used without IPsec (see Section 3.1), Web 807 proxies, and transparent application layer middle boxes might 808 work. However, that hasn't been analyzed. 810 5.2.4.10 Implications on scoped addressing 812 It has not been analyzed how HIP would affect scoped addressing. 814 Multicast. Not analyzed. 816 Link local. HIP should not have any effects on link local addresses 817 or using them. 819 Son-of-Sitelocal. It looks like HIP might reduce need for site local 820 kind of addresses. 822 5.2.4.11 Layer 2 implications 824 HIP, as such, does not seem to have any direct implications on layer 825 2 or neighbor discovery. However, given that HIP introduces a public 826 key per host, it might be possible to further simplify ND and layer 2 827 security mechanisms. 829 5.2.4.12 Referrals 831 As HIP replaces IP addresses with HITs in application data 832 structures, and since HITs cannot be currently resolved into IP 833 addresses, multi-party applications doing IP-address-based referrals 834 will not work. The IRTF HIP RG will study the support of such 835 multi-party applications. 837 5.2.4.13 Legal stuff / trade marks and name space management 839 Public keys or their hashes are not mnemonic. The name space does 840 not need to be managed. 842 5.3 RFC 3582 Section 3 considerations 844 5.3.1 Multi-Homing capabilities 846 5.3.1.1 Redundancy 848 Path redundancy is fully supported, similar to other solutions based 849 on multi-addressing. More specifically, as soon as the hosts have 850 established multi-addressing state by exchanging REA payloads, the 851 hosts may use the different transit providers interchangeably. The 852 current HIP specifications do not specify how a host detects a path 853 failure; such a mechanism is expected to be specified in the multi6 854 WG. 856 If a failure occurs before the multi-addressing state has been 857 established, e.g., before the HIP base exchange has been completed, 858 the hosts may try to re-create the HIP state using different IP 859 addresses, if available, e.g., from the DNS. However, the HIP 860 specifications do not currently discuss such a situation, and the 861 actual behaviour depends on local implementation. 863 5.3.1.2 Load sharing 865 Load sharing is supported, in the sense that the hosts may use 866 different transit providers interchangeably, similar to other 867 solutions based on multi-addressing. 869 The current specification does include a feature that allows a host 870 to control the primary address that it wants its peer to use. If 871 more fine grained control is required, suitable policy mechanisms 872 could be developed on the top of HIP. 874 5.3.1.3 Performance 876 By default, HIP based multi-homing does not require 877 intra-transit-provider links to be used. This is similar to other 878 multi-addressing based solutions. 880 As HIP insulates the transport sessions from the IP addresses, HIP 881 allows more freedom in source or destination address based policy 882 routing. 884 The baseline HIP solution adds a small delay before the first 885 transport session between a pair of hosts is established. The 886 duration of the delay depends on latency and available CPU resources, 887 consisting of two round trips of latency and requiring hosts to 888 compute Diffie-Hellman shared key, one or two DSA signatures, and 889 verify one or two DSA signatures. Using short keys is allowed by the 890 protocol, subject to local policy considerations. 892 5.3.1.4 Policy 894 As of today, HIP does not contain any policy control mechanisms. 895 However, adding such mechanisms seems to be fairly straightforward, 896 not differing from other multi-addressing based solutions. 898 5.3.1.5 Simplicity 900 HIP requires both end hosts to be changed. Most applications do not 901 require any changes; applications that use explicit referral may need 902 to be made HIP aware. Incremental deployment is fully supported. 904 Legacy IPv6 (and IPv4) hosts can be used at a multi-homed site either 905 as such, in which case they do not benefit from multi-homing, or 906 through a HIP proxy, located at the site. If a multi-homed site 907 wants to benefit from multi-homing when communicating with legacy 908 hosts outside of the site, a HIP proxy must be deployed somewhere 909 close to the core network. 911 The exact details of HIP proxies have not been defined yet. 913 The current HIP implementations, with limited multi-homing support, 914 have around 10 000 lines of C code. Adding full multi-homing support, 915 as defined in [4] is expected to add less than 3 000 lines of code. 917 5.3.1.6 Transport layer survivability 919 The solution provides full re-homing transparency for all transport 920 layer sessions, similar to other multi-addressing based solutions. 922 Most of the known current implementations do not support transparency 923 for raw IP, as raw IP is considered to be located the host identity 924 layer. 926 5.3.1.7 Impact on DNS 928 HIP adds a new DNS resource record for each HIP capable host. The 929 details are to be defined in the HIP WG. This new resource record 930 will be queried along with the IP addresses, thereby adding little 931 overhead. 933 For redundancy in initial connections, a HIP capable host should list 934 multiple IP addresses in the DNS. However, these addresses are used 935 only for the initial connection. Once the multi-addressing state has 936 been established, the hosts are independent of DNS. 938 5.3.1.8 Packet filtering 940 HIP is similar to other multi-addressing based solutions. 942 5.3.2 Additional requirements 944 5.3.2.1 Scalability 946 The solution does not impose new requirements on the routing system. 948 From a multi-homing point of view, the only required piece of new 949 infrastructure is the new DNS resource record. Adding such records 950 scales approximately as well as the DNS does today. 952 HIP uses approximately 120 bit pseudo-random identifiers for 953 identifying hosts. According to the birthday paradigm, as long as 954 the total number of hosts remains considerably lower than sqrt(2^120) 955 = 2^60, the probability of identifier collisions remains low. If the 956 number of hosts is expected to grow larger, the length of the 957 identifier can be doubled with minor modifications to the solution. 959 5.3.2.2 Impact on routers 961 The solution does not require changes to IPv6 routers, other than 962 what the multi6 wg has already determined useful for all 963 multi-addressing based solutions. 965 5.3.2.3 Impact on hosts 967 HIP provides full backwards compatibility with legacy hosts. 968 Whenever one of the two communicating hosts is not HIP aware, the 969 applications fall back to legacy IP. 971 HIP does require changes to the host stack. These changes can be 972 classified into two classes: 974 1. Basic packet processing must be changed to recognize HITs on 975 outgoing packets, and incoming ESP protected HIP packets must 976 replace the IP addresses with HITs. This change is minor, and 977 can be implemented either integral to IPsec, or separate. In a 978 typical implementation, the number of changed and/or added lines 979 of code is a few hundred. 981 2. A HIP protocol implementation must be added to the stack. This 982 change is a logically separate function. In a typical 983 implementation, the number of lines of code required is in order 984 of 10000-20000. 986 The solution does not _require_ changes to the socket API or 987 transport layer. However, it is _expected_ that the socket API and 988 the transport layer will be changed in order to gain full benefit 989 from HIP. 991 As it is currently defined, HIP breaks some multi-party applications 992 that use IP addresses for referral. Solutions to this problem is a 993 research topic, being studied at the IRTF HIP RG. 995 5.3.2.4 Interactions between hosts and the routing system 997 HIP does not require interaction between hosts and the routing 998 system, other than what the multi6 wg has already determined for 999 other multi-addressing based solutions. 1001 5.3.2.5 Operations and management 1003 HIP implementations are expected to include a facility that allows an 1004 administrator to view HIT to address mapping. There is no HIP MIB or 1005 PIB, but it can be expected to be added as a working item for the HIP 1006 working group in the future. 1008 5.3.2.6 Co-operationg between transit providers 1010 HIP does not require any co-operation between transit providers. If 1011 such co-operation is available, HIP would benefit from it similar to 1012 other multi-addressing based solutions. 1014 5.3.2.7 Multiple solutions 1016 HIP should work well with multi-homing solutions that are located 1017 solely at the IP layer, i.e., below HIP. 1019 Interoperability with other multi-addressing based solutions depend 1020 on many details, and need to be analyzed case-by-case. 1022 5.4 Security considerations 1024 HIP attempts to raise the security baseline in the Internet by 1025 employing IPsec ESP protection by default. 1027 6. Security considerations 1029 HIP security has been extensively discussed in [3] and [2]. Mobility 1030 and multicast related security issues have been briefly discussed in 1031 [4]. As this draft is more a discussion draft and not a protocol 1032 specification, security considerations related to using HIP 1033 components instead of full HIP are currently not discussed anywhere. 1034 Such a discussion is planned to be added at a later stage, if this 1035 draft goes forward. 1037 7. Change log 1039 Changes between this version (-01) and -00 draft 1041 - added Section 2.6 comparing HIP with other group F multi6 1042 proposals 1044 - added Section 3.3 describing how HIP could be possibly changed 1045 to include routable AIDs 1047 - updated references to HIP WG and HIP RG (Section 1.2) 1049 Informative references 1051 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 1052 Architecture", RFC 2373, July 1998. 1054 [2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 1055 (work in progress), June 2004. 1057 [3] Moskowitz, R., "Host Identity Protocol Architecture", 1058 draft-moskowitz-hip-arch-06 (work in progress), June 2004. 1060 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1061 Identity Protocol", draft-nikander-hip-mm-01 (work in 1062 progress), January 2004. 1064 [5] Nikander, P., "Mobile IP version 6 Route Optimization Security 1065 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 1066 in progress), December 2003. 1068 [6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 1069 solutions", draft-nordmark-multi6-threats-02 (work in 1070 progress), June 2004. 1072 [7] Nordmark, E., "Multihoming without IP Identifiers", 1073 draft-nordmark-multi6-noid-01 (work in progress), October 2003. 1075 [8] Nordmark, E., "Multihoming using 64-bit Crypto-based IDs", 1076 draft-nordmark-multi6-cb64-00 (work in progress), November 1077 2003. 1079 [9] Nordmark, E., "Strong Identity Multihoming using 128 bit 1080 Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim-01 (work 1081 in progress), October 2003. 1083 [10] Crocker, D., "CHOICES FOR MULTIADDRESSING", 1084 draft-crocker-mast-analysis-01 (work in progress), October 1085 2003. 1087 [11] Krawczyk, H., "The SIGMA family of key-exchange protocols", 1088 2003. 1090 [12] Ylitalo, J., "Weak Identifier Multihoming Protocol Framework 1091 (WIMP-F)", draft-ylitalo-multi6-wimp-01 (work in progress), 1092 June 2004. 1094 Authors' Addresses 1096 Pekka Nikander 1097 Ericsson Research Nomadic Lab 1099 JORVAS FIN-02420 1100 FINLAND 1102 Phone: +358 9 299 1 1103 EMail: pekka.nikander@nomadiclab.com 1105 Tom Henderson 1106 The Boeing Company 1107 P.O. Box 3707 1108 Seattle, WA 1109 USA 1111 EMail: thomas.r.henderson@boeing.com 1113 Intellectual Property Statement 1115 The IETF takes no position regarding the validity or scope of any 1116 intellectual property or other rights that might be claimed to 1117 pertain to the implementation or use of the technology described in 1118 this document or the extent to which any license under such rights 1119 might or might not be available; neither does it represent that it 1120 has made any effort to identify any such rights. Information on the 1121 IETF's procedures with respect to rights in standards-track and 1122 standards-related documentation can be found in BCP-11. Copies of 1123 claims of rights made available for publication and any assurances of 1124 licenses to be made available, or the result of an attempt made to 1125 obtain a general license or permission for the use of such 1126 proprietary rights by implementors or users of this specification can 1127 be obtained from the IETF Secretariat. 1129 The IETF invites any interested party to bring to its attention any 1130 copyrights, patents or patent applications, or other proprietary 1131 rights which may cover technology that may be required to practice 1132 this standard. Please address the information to the IETF Executive 1133 Director. 1135 Full Copyright Statement 1137 Copyright (C) The Internet Society (2004). All Rights Reserved. 1139 This document and translations of it may be copied and furnished to 1140 others, and derivative works that comment on or otherwise explain it 1141 or assist in its implementation may be prepared, copied, published 1142 and distributed, in whole or in part, without restriction of any 1143 kind, provided that the above copyright notice and this paragraph are 1144 included on all such copies and derivative works. However, this 1145 document itself may not be modified in any way, such as by removing 1146 the copyright notice or references to the Internet Society or other 1147 Internet organizations, except as needed for the purpose of 1148 developing Internet standards in which case the procedures for 1149 copyrights defined in the Internet Standards process must be 1150 followed, or as required to translate it into languages other than 1151 English. 1153 The limited permissions granted above are perpetual and will not be 1154 revoked by the Internet Society or its successors or assignees. 1156 This document and the information contained herein is provided on an 1157 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1158 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1159 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1160 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1161 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1163 Acknowledgment 1165 Funding for the RFC Editor function is currently provided by the 1166 Internet Society.