idnits 2.17.1 draft-ietf-hip-bone-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5202 (Obsoleted by RFC 7402) == Outdated reference: A later version (-05) exists of draft-ietf-hip-hiccups-02 -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) -- Obsolete informational reference (is this intentional?): RFC 5205 (Obsoleted by RFC 8005) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-07 == Outdated reference: A later version (-10) exists of draft-ietf-hip-reload-instance-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group G. Camarillo 3 Internet-Draft P. Nikander 4 Intended status: Experimental J. Hautakorpi 5 Expires: September 9, 2010 A. Keranen 6 Ericsson 7 A. Johnston 8 Avaya 9 March 8, 2010 11 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking 12 Environment 13 draft-ietf-hip-bone-05.txt 15 Abstract 17 This document specifies a framework to build HIP (Host Identity 18 Protocol)-based overlay networks. This framework uses HIP to perform 19 connection management. Other functions, such as data storage and 20 retrieval or overlay maintenance, are implemented using protocols 21 other than HIP. These protocols are loosely referred to as peer 22 protocols. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 9, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 5 68 3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 69 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 70 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7 73 3.3.2. Identifier Assignment and Authentication . . . . . . . 7 74 3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8 75 3.4. HIP Deployability and Legacy Applications . . . . . . . . 8 76 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9 77 5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13 79 5.2. Connection Establishment . . . . . . . . . . . . . . . . . 14 80 5.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 81 5.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 82 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16 83 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16 84 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Host Identity Protocol (HIP) [RFC5201] defines a new name space 96 between the network and transport layers. HIP provides upper layers 97 with mobility, multihoming, NAT (Network Address Translation) 98 traversal, and security functionality. HIP implements the so called 99 identifier/locator (ID/locator) split, which implies that IP 100 addresses are only used as locators, not as host identifiers. This 101 split makes HIP a suitable protocol to build overlay networks that 102 implement identifier-based overlay routing over IP networks, which in 103 turn implement locator-based routing. 105 Using HIP BONE, as opposed to a peer protocol, to perform connection 106 management in an overlay has a set of advantages. HIP BONE can be 107 used by any peer protocol. This keeps each peer protocol from 108 defining primitives needed for connection management (e.g., 109 primitives to establish connections and to tunnel messages through 110 the overlay) and NAT traversal. Having this functionality at a lower 111 layer allows multiple upper-layer protocols to take advantage of it. 113 Additionally, having a solution that integrates mobility and 114 multihoming is useful in many scenarios. Peer protocols do not 115 typically specify mobility and multihoming solutions. Combining a 116 peer protocol including NAT traversal with a separate mobility 117 mechanism and a separate multihoming mechanism can easily lead to 118 unexpected (and unpleasant) interactions. 120 The remainder of this document is organized as follows. Section 3 121 provides background information on HIP. Section 4 gives an overview 122 of the HIP BONE (HIP-Based Overlay Networking Environment) framework 123 and architecture and Section 5 describes the framework in more 124 detail. Finally, before the customary sections, Section 6 introduces 125 new HIP parameters for overlay usage. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 The following terms are used in context of HIP BONEs: 135 Overlay network: A network built on top of another network. In case 136 of HIP BONEs, the underlying network is an IP network and the 137 overlay can be, e.g., a peer-to-peer (P2P) network. 139 Peer protocol: A protocol used by nodes in an overlay network for 140 performing, e.g., data storage and retrieval or overlay 141 maintenance. HIP is used for conveying the peer protocol messages 142 between the nodes in the overlay network. 144 HIP BONE instance: A HIP-based overlay network that uses a 145 particular peer protocol and is based on the framework presented 146 in this document. 148 Node ID: A value that uniquely identifies a node in an overlay 149 network. The value is not usually human-friendly, but for example 150 a hash of a public key. 152 Valid locator: A Locator (as defined in [RFC5206]; usually an IP 153 address or an address and a port number) that a host is known to 154 be reachable at, for example, because there is an active HIP 155 association with the host. 157 3. Background on HIP 159 This section provides background on HIP. Given the tutorial nature 160 of this section, readers that are familiar with what HIP provides and 161 how HIP works may want to skip it. All descriptions contain 162 references to the relevant HIP specifications where readers can find 163 detailed explanations on the different topics discussed in this 164 section. 166 3.1. ID/locator Split 168 In an IP network, IP addresses typically serve two roles: they are 169 used as host identifiers and as host locators. IP addresses are 170 locators because a given host's IP address indicates where in the 171 network that host is located. IP networks route based on these 172 locators. Additionally, IP addresses are used to identify remote 173 hosts. The simultaneous use of IP addresses as host identifiers and 174 locators makes mobility and multihoming complicated. For example, 175 when a host opens a TCP connection, the host identifies the remote 176 end of the connection by the remote IP address (plus port). If the 177 remote host changes its IP address, the TCP connection will not 178 survive, since the transport layer identifier of the remote end of 179 the connection has changed. 181 Mobility solutions such as Mobile IP keep the remote IP address from 182 changing so that it can still be used as an identifier. HIP, on the 183 other hand, uses IP addresses as only locators and defines a new 184 identifier space. This approach is referred to as the ID/locator 185 split and makes the implementation of mobility and multihoming more 186 natural. In the previous example, the TCP connection would be bound 187 to the remote host's identifier, which would not change when the 188 remote hosts moves to a new IP address (i.e., to a new locator). The 189 TCP connection is able to survive locator changes because the remote 190 host's identifier does not change. 192 3.1.1. Identifier Format 194 HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash 195 Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 196 addresses but cannot collide with regular IPv6 addresses because 197 ORCHID spaces are registered with the IANA. That is, a portion of 198 the IPv6 address space is reserved for ORCHIDs. The ORCHID 199 specification allows creating multiple disjoint identifier spaces. 200 Each such space is identified by a separate Context Identifier. The 201 Context Identifier can be either drawn implicitly from the context 202 the ORCHID is used in or carried explicitly in a protocol. 204 HIP defines a native socket API [I-D.ietf-hip-native-api] that 205 applications can use to establish and manage connections. 206 Additionally, HIP can also be used through the traditional IPv4 and 207 IPv6 TCP/IP socket APIs. Section 3.4 describes how an application 208 using these traditional APIs can make use of HIP. Figure 1 shows all 209 these APIs between the application and the transport layers. 211 +-----------------------------------------+ 212 | Application | 213 +----------------+------------------------+ 214 | HIP Native API | Traditional Socket API | 215 +----------------+------------------------+ 216 | Transport Layer | 217 +-----------------------------------------+ 219 Figure 1: HIP API 221 3.1.2. HIP Base Exchange 223 Before two HIP hosts exchange upper-layer traffic, they perform a 224 four-way handshake that is referred to as the HIP base exchange. 225 Figure 2 illustrates the HIP base exchange. The initiator sends an 226 I1 packet and receives an R1 packet from the responder. After that, 227 the initiator sends an I2 packet and receives an R2 packet from the 228 responder. 230 Initiator Responder 232 | I1 | 233 | -------------------------->| 234 | R1 | 235 | <--------------------------| 236 | I2 | 237 | -------------------------->| 238 | R2 | 239 | <--------------------------| 241 Figure 2: HIP Base Exchange 243 Of course, the initiator needs the responder's locator (or locators) 244 in order to send its I1 packet. The initiator can obtain locators 245 for the responder in multiple ways. For example, according to the 246 current HIP specifications the initiator can get the locators 247 directly from the DNS [RFC5205] or indirectly by sending packets 248 through a HIP rendezvous server [RFC5204]. However, as an 249 architecture HIP is open ended, and allows the locators to be 250 obtained by any means (e.g., from packets traversing an overlay 251 network or as part of the candidate address collection process in a 252 NAT traversal scenario). 254 3.1.3. Locator Management 256 Once a HIP connection between two hosts has been established with a 257 HIP base exchange, the hosts can start exchanging higher-layer 258 traffic. If any of the hosts changes its set of locators, it runs an 259 update exchange [RFC5206], which consists of three messages. If a 260 host is multihomed, it simply provides more than one locator in its 261 exchanges. However, if both of the end points move at the same time, 262 or through some other reason both lose track of the peers' currently 263 active locators, they need to resort to using a rendezvous server or 264 getting new peer locators by some other means. 266 3.2. NAT Traversal 268 HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based 269 on ICE (Interactive Connectivity Establishment) 270 [I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part 271 of the HIP base exchange, hosts perform an ICE offer/answer exchange 272 where they exchange their respective address candidates. Hosts 273 perform end-to-end STUN [RFC5389] based connectivity checks in order 274 to discover which address candidate pairs yield connectivity. 276 Even though, architecturally, HIP lies below the transport layer 277 (i.e., HIP packets are carried directly in IP packets), in presence 278 of NATs, HIP sometimes needs to be tunneled in a transport protocol 279 (i.e., HIP packets are carried by a transport protocol such as UDP). 281 3.3. Security 283 Security is an essential part of HIP. The following sections 284 describe the security-related functionality provided by HIP. 286 3.3.1. DoS Protection 288 HIP provides protection against DoS (Denial of Service) attacks by 289 having initiators resolve a cryptographic puzzle before the responder 290 stores any state. On receiving an I1 packet, a responder sends a 291 pre-generated R1 packet that contains a cryptographic puzzle and 292 deletes all the state associated with the processing of this I1 293 packet. The initiator needs to resolve the puzzle in the R1 packet 294 in order to generate an I2 packet. The difficulty of the puzzle can 295 be adjusted so that, if a receiver is under a DoS attack, it can 296 increase the difficulty of its puzzles. 298 On receiving an I2 packet, a receiver checks that the solution in the 299 packet corresponds to a puzzle generated by the receiver and that the 300 solution is correct. If it is, the receiver processes the I2 packet. 301 Otherwise, it silently discards it. 303 In an overlay scenario, there are multiple ways how this mechanism 304 can be utilized within the overlay. One possibility is to cache the 305 pre-generated R1 packets within the overlay and let the overlay 306 directly respond with R1s to I1s. In that way the responder is not 307 bothered at all until the initiator sends an I2 packet, with the 308 puzzle solution. Furthermore, a more sophisticated overlay could 309 verify that an I2 packet has a correctly solved puzzle before 310 forwarding the packet to the responder. 312 3.3.2. Identifier Assignment and Authentication 314 As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main 315 representation for identifiers. Potentially, HIP can use different 316 types of ORCHIDs as long as the probability of finding collisions 317 (i.e., two nodes with the same ORCHID) is low enough. One way to 318 completely avoid this type of collision is to have a central 319 authority generate and assign ORCHIDs to nodes. To secure the 320 binding between ORCHIDs and any higher-layer identifiers, every time 321 the central authority assigns an ORCHID to a node, it also generates 322 and signs a certificate stating who is the owner of the ORCHID. The 323 owner of the ORCHID then includes the corresponding certificate in 324 its R1 (when acting as responder) and I2 packets (when acting 325 initiator) to prove that it is actually allowed to use the ORCHID 326 and, implicitly, the associated public key. 328 Having a central authority works well to completely avoid collisions. 329 However, having a central authority is impractical in some scenarios. 330 As defined today, HIP systems generally use a self-certifying ORCHID 331 type called HIT (Host Identity Tag) that does not require a central 332 authority (but still allows one to be used). 334 A HIT is the hash of a node's public key. A node proves that it has 335 the right to use a HIT by showing its ability to sign data with its 336 associated private key. This scheme is secure due to the so called 337 second-preimage resistance property of hash functions. That is, 338 given a fixed public key K1, finding a different public key K2 such 339 that hash(K1) = hash(K2) is computationally very hard. Optimally, a 340 preimage attack on the 100-bit hash function used in ORCHIDs will 341 take an order of 2^100 operations to be successful, and can be 342 expected to take in the average 2^99 operations. Given that each 343 operation requires the attacker to generate a new key pair, the 344 attack is completely impractical (see [RFC4843]). 346 HIP nodes using HITs as ORCHIDs do not typically use certificates 347 during their base exchanges. Instead, the use a leap-of-faith 348 mechanism, similar to the Secure Shell (SSH) protocol [RFC4251], 349 whereby a node authenticates somehow remote nodes the first time they 350 connect it and, then, remembers their public keys. While user- 351 assisted leap-of-faith (such as in SSH) can be used to facilitate a 352 human-operated offline path (such as a telephone call), automated 353 leap-of-faith can be combined with a reputation management system to 354 create an incentive to behave. However, such considerations go well 355 beyond the current HIP architecture and even beyond this proposal. 356 For the purposes of the present document, we merely want to point out 357 that architecturally HIP supports both self-generated opportunistic 358 identifiers and administratively assigned ones. 360 3.3.3. Connection Security 362 Once two nodes complete a base exchange between them, the traffic 363 they exchange is encrypted and integrity protected. The security 364 mechanism used to protect the traffic is IPsec Encapsulating Security 365 Payload (ESP) [RFC5202]. However, there is ongoing work to specify 366 how to use different protection mechanisms. 368 3.4. HIP Deployability and Legacy Applications 370 As discussed earlier, HIP defines a native socket API 371 [I-D.ietf-hip-native-api] that applications can use to establish and 372 manage connections. New applications can implement this API to get 373 full advantage of HIP. However, in most cases, legacy (i.e., non-HIP 374 aware) applications [RFC5338] can use HIP through the traditional 375 IPv4 and IPv6 socket APIs. 377 The idea is that when a legacy IPv6 application tries and obtains a 378 remote host's IP address (e.g., by querying the DNS) the DNS resolver 379 passes the remote host's ORCHID (which was also stored in the DNS) to 380 the legacy application. At the same time, the DNS resolver stores 381 the remote host's IP address internally at the HIP module. Since the 382 ORCHID looks like an IPv6 address, the legacy application treats it 383 as such. It opens a connection (e.g., TCP) using the traditional 384 IPv6 socket API. The HIP module running in the same host as the 385 legacy application intercepts this call somehow (e.g., using an 386 interception library or setting up the host's routing tables so that 387 the HIP module receives the traffic) and runs HIP (on behalf of the 388 legacy application) towards the IP address corresponding to the 389 ORCHID. This mechanism works well in almost all cases. However, 390 applications involving referrals (i.e., passing of IPv6 addresses 391 between applications) present issues, to be discussed in Section 5 392 below. Additionally, management applications that care about the 393 exact IP address format may not work well with such straightforward 394 approach. 396 In order to make HIP work through the traditional IPv4 socket API, 397 the HIP module passes an LSI (Local Scope Identifier), instead of a 398 regular IPv4 address, to the legacy IPv4 application. The LSI looks 399 like an IPv4 address, but is locally bound to an ORCHID. That is, 400 when the legacy application uses the LSI in a socket call, the HIP 401 module intercepts it and replaces the LSI with its corresponding 402 ORCHID. Therefore, LSIs always have local scope. They do not have 403 any meaning outside the host running the application. The ORCHID is 404 used on the wire; not the LSI. In the referral case, if it is not 405 possible to rewrite the application level packets to use ORCHIDs 406 instead of LSIs, it may be hard to make IPv4 referrals work in 407 Internet-wide settings. IPv4 LSIs have been successfully used in 408 existing HIP deployments within a single corporate network. 410 4. Framework Overview 412 The HIP BONE framework combines HIP with different peer protocols to 413 provide robust and secure overlay network solutions. 415 Many overlays typically require three types of operations: 417 o overlay maintenance. 418 o data storage and retrieval. 420 o connection management. 422 Overlay maintenance operations deal with nodes joining and leaving 423 the overlay and with the maintenance of the overlay's routing tables. 424 Data storage and retrieval operations deal with nodes storing, 425 retrieving, and removing information in or from the overlay. 426 Connection management operations deal with the establishment of 427 connections and the exchange of lightweight messages among the nodes 428 of the overlay, potentially in the presence of NATs. 430 The HIP BONE framework uses HIP to perform connection management. 431 Data storage and retrieval and overlay maintenance are to be 432 implemented using protocols other than HIP. For lack of a better 433 name, these protocols are referred to as peer protocols. 435 One way to depict the relationship between the peer protocol and HIP 436 modules is shown in Figure 3. The peer protocol module implements 437 the overlay construction and maintenance features, and possibly 438 storage (if the particular protocol supports such a feature). The 439 HIP module consults the peer protocol's overlay topology part for 440 making routing decisions and the peer protocol uses HIP for 441 connection management and sending peer protocol messages to other 442 hosts. The HIP BONE API that applications use is a combination of 443 the HIP Native API and traditional socket API (as shown in Figure 1) 444 with any additional API a particular instance implementation 445 provides. 447 Application 448 -------------------------------- HIP BONE API 449 +---+ +--------------------+ 450 | | | Peer Protocol | 451 | | +--------+ +---------+ 452 | |<->|Topology| |(Storage)| 453 | | +---------+----------+ 454 | | ^ 455 | | v 456 | +------------------------+ 457 | HIP | 458 +----------------------------+ 460 Figure 3: HIP with Peer Protocol 462 Architecturally, HIP can be considered to create a new thin "waist" 463 layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP 464 layer itself consists of the HIP signaling protocol and one or more 465 data transport protocols; see Figure 5. The HIP signaling packets 466 and the data transport packets can take different routes. In the HIP 467 BONE, the HIP signaling packets are typically first routed through 468 the overlay and then directly (if possible), while the data transport 469 packets are typically routed only directly between the end points. 471 +--------------------------------------+ 472 | Transport (using HITs or LSIs) | 473 +--------------------------------------+ 474 | HIP | 475 +------------------+-------------------+ 476 | IPv4 | IPv6 | 477 +------------------+-------------------+ 479 Figure 4: HIP as a Thin Waist 481 +------------------+-------------------+ 482 | HIP signaling | data transports | 483 +------------------+-------------------+ 485 Figure 5: HIP Layer Structure 487 In HIP BONE, the peer protocol creates a new signaling layer on top 488 of HIP. It is used to set up forwarding paths for HIP signaling 489 messages. This is a similar relationship that an IP routing 490 protocol, such as OSPF, has to the IP protocol itself. In the HIP 491 BONE case, the peer protocol plays a role similar to OSPF, and HIP 492 plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if 493 the ORCHID prefix is not used) are used for forwarding HIP packets 494 according to the information in the routing tables. The peer 495 protocols are used to exchange routing information based on Node IDs 496 and to construct the routing tables. 498 Architecturally, routing tables are located between the peer protocol 499 and HIP, as shown in Figure 6. The peer protocol constructs the 500 routing table and keeps it updated. The HIP layer accesses the 501 routing table in order to make routing decisions. The bootstrap of a 502 HIP BONE overlay does not create circular dependencies between the 503 peer protocol (which needs to use HIP to establish connections with 504 other nodes) and HIP (which needs the peer protocol to know how to 505 route messages to other nodes) for the same reasons as the bootstrap 506 of an IP network does not create circular dependencies between OSPF 507 and IP. The first connections established by the peer protocol are 508 with nodes whose locators are known. HIP establishes those 509 connections as any connection between two HIP nodes where no overlays 510 are present. That is, there is no need for the overlay to provide a 511 rendezvous service for those connections. 513 +--------------------------------------+ 514 | Peer protocol | 515 +--------------------------------------+ 516 | Routing table | 517 +--------------------------------------+ 518 | HIP | 519 +--------------------------------------+ 521 Figure 6: Routing Tables 523 It is possible that different overlays use different routing table 524 formats. For example, the structure of the routing tables of two 525 overlays based on different DHTs (Distributed Hash Tables) may be 526 very different. In order to make routing decisions, the HIP layer 527 needs to convert the routing table generated by the peer protocol 528 into a forwarding table that allows the HIP layer select a next-hop 529 for any packet being routed. 531 In HIP BONE, the HIP usage of public keys and deriving ORCHIDs 532 through a hash function can be utilized at the peer protocol side to 533 better secure routing table maintenance and to protect against 534 chosen-peer-ID attacks. 536 The HIP BONE provides quite a lot of flexibility with regards to how 537 to arrange the different protocols in detail. Figure 7 shows one 538 potential stack structure. 540 +-----------------------+--------------+ 541 | peer protocols | media | 542 +------------------+----+--------------+ 543 | HIP signaling | data transport | 544 | | 545 +------------------+-------------------+ 546 | NAT | non-NAT | | 547 | | | 548 | IPv4 | IPv6 | 549 +------------------+-------------------+ 551 Figure 7: Example HIP BONE Stack Structure 553 5. The HIP BONE Framework 555 HIP BONE is a generic framework that allows the use of different peer 556 protocols. A particular HIP BONE instance uses a particular peer 557 protocol. The details on how to implement a HIP BONE using a given 558 peer protocol need to be specified in a, so called, HIP BONE instance 559 specification. Section 5.4 discusses what details need to be 560 specified by HIP BONE instance specifications. For example, the HIP 561 BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is 562 specified in [I-D.ietf-hip-reload-instance]. 564 5.1. Node ID Assignment and Bootstrap 566 Nodes in an overlay are primarily identified by their Node IDs. 567 Overlays typically have an enrollment server that can generate Node 568 IDs, or at least some part of the Node ID, and sign certificates. A 569 certificate generated by an enrollment server authorizes a particular 570 user to use a particular Node ID in a particular overlay. The way 571 users and overlays are identified are defined by the peer protocol 572 and HIP BONE instance specification. 574 The enrollment server of an overlay that were to use HITs derived 575 from public keys as Node IDs could just authorize users to use the 576 public keys and HITs associated to their nodes. Such a Node ID has 577 the same self-certifying property as HITs and the Node ID can also be 578 used in the HIP and legacy APIs as an ORCHID. This works well as 579 long as the enrollment server is the one generating the public/ 580 private key pairs for all those nodes. If the enrollment server 581 authorizes users to use HITs that are generated directly by the nodes 582 themselves, the system is open to a type of chosen-peer-ID attack. 584 If the overlay network or peer protocol has more specific 585 requirements for the Node ID value that prevent using HITs derived 586 from public keys, each host will need a certificate (e.g., in their 587 HIP base exchanges) provided by the enrollment server to prove that 588 they are authorized to use a particular identifier in the overlay. 589 Depending on how the certificates are constructed, they typically 590 also need to contain the host's self-generated public key. Depending 591 on how the Node IDs and public keys are attributed, different 592 scenarios become possible. For example, the Node IDs may be 593 attributed to users, there may be user public key identifiers, and 594 there may be separate host public key identifiers. Authorization 595 certificates can be used to bind the different types of identifiers 596 together. 598 HITs, as defined in [RFC5201], always start with the ORCHID prefix. 599 Therefore, there are 100 bits left in the HIT for different Node ID 600 values. If an overlay network requires larger address space, it is 601 also possible to use all the 128 bits of a HIT for addressing peer 602 layer identifiers. The benefit of using ORCHID prefix for Node IDs 603 is that it makes possible to use them with legacy socket APIs, but in 604 this context most of the applications are assumed to be HIP aware and 605 able to use a more advanced API supporting full 128-bit identifiers. 606 Even larger address spaces could be supported with an additional HIP 607 parameter giving the source and destination Node IDs, but defining 608 such a parameter, if needed, is left for future documents. 610 Bootstrap issues such as how to locate an enrollment or a bootstrap 611 server belong to the peer protocol. 613 5.2. Connection Establishment 615 Nodes in an overlay need to establish connection with other nodes in 616 different cases. For example, a node typically has connections to 617 the nodes in its forwarding table. Nodes also need to establish 618 connections with other nodes in order to exchange application-layer 619 messages. 621 As discussed earlier, HIP uses the base exchange to establish 622 connections. A HIP endpoint (the initiator) initiates a HIP base 623 exchange with a remote endpoint by sending an I1 packet. The 624 initiator sends the I1 packet to the remote endpoint's locator. 625 Initiators that do not have any locator for the remote endpoint need 626 to use a rendezvous service. Traditionally, a HIP rendezvous server 627 [RFC5204] has provided such a rendezvous service. In HIP BONE, the 628 overlay itself provides the rendezvous service. 630 Therefore, in HIP BONE, a node uses an I1 packet (as usual) to 631 establish a connection with another node in the overlay. Nodes in 632 the overlay forward I1 packets in a hop-by-hop fashion according to 633 the overlay's routing table towards its destination. This way, the 634 overlay provides a rendezvous service between the nodes establishing 635 the connection. If the overlay nodes have active connections with 636 other nodes in their forwarding tables and if those connections are 637 protected (typically with IPsec ESP), I1 packets may be sent over 638 protected connections between nodes. Alternatively, if there is no 639 such an active connection but the node forwarding the I1 packet has a 640 valid locator for the next hop, the I1 packets may be forwarded 641 directly, in a similar fashion to how I1 packets are today forwarded 642 by a HIP rendezvous server. 644 Since HIP supports NAT traversal, a HIP base exchange over the 645 overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer 646 exchange between the nodes that are establishing the connection. In 647 order to perform this exchange, the nodes need to first gather 648 candidate addresses. Which nodes can be used to obtain reflexive 649 address candidates and which ones can be used to obtain relayed 650 candidates is defined by the peer protocol. 652 5.3. Lightweight Message Exchanges 654 In some cases, nodes need to perform a lightweight query to another 655 node (e.g., a request followed by a single response). In this 656 situation, establishing a connection using the mechanisms in 657 Section 5.2 for a simple query would be an overkill. A better 658 solution is to forward a HIP message through the overlay with the 659 query and another one with the response to the query. The payload of 660 such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. 661 Nodes in the overlay forward this HIP packet in a hop-by-hop fashion 662 according to the overlay's routing table towards its destination, 663 typically through the protected connections established between them. 664 Again, the overlay acts as a rendezvous server between the nodes 665 exchanging the messages. 667 5.4. HIP BONE Instantiation 669 As discussed in Section 5, HIP BONE is a generic framework that 670 allows using different peer protocols. A particular HIP BONE 671 instance uses a particular peer protocol. The details on how to 672 implement a HIP BONE using a given peer protocol need to be specified 673 in a, so called, HIP BONE instance specification. A HIP BONE 674 instance specification needs to define, minimally: 676 o the peer protocol to be used. 677 o what kind of Node IDs are used and how they are derived. 678 o which peer protocol primitives trigger HIP messages. 679 o how the overlay identifier is generated. 681 Additionally, a HIP BONE instance specification may need to specify 682 other details that are specific to the peer protocol used. 684 As an example, the HIP BONE instance specification for RELOAD 685 [I-D.ietf-p2psip-base] is specified in 686 [I-D.ietf-hip-reload-instance]. 688 It is assumed that areas not covered by a particular HIP BONE 689 instance specification are specified by the peer protocol or 690 elsewhere. These areas include: 692 o the algorithm to create the overlay (e.g., a DHT). 693 o overlay maintenance functions. 694 o data storage and retrieval functions. 695 o the process for obtaining a Node ID. 696 o bootstrap function. 697 o how to select STUN and TURN servers for the candidate address 698 collection process in NAT traversal scenarios. 700 Note that the border between HIP BONE instance specification and a 701 peer protocol specifications is blurry. Depending on how generic the 702 specification of a given peer protocol is, its associated HIP BONE 703 instance specification may need to specify more or less details. 704 Also, a HIP BONE instance specification may leave certain areas 705 unspecified in order to leave their configuration up to each 706 particular overlay. 708 6. Overlay HIP Parameters 710 This section defines generic format and protocol behavior for the 711 Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that 712 can be used in HIP based overlay networks. HIP BONE instance 713 specifications define the exact format and content of the Overlay 714 Identifier parameter, the cases when the Overlay TTL parameter should 715 be used, and any additional behavior for each packet. 717 6.1. Overlay Identifier 719 It is possible for a HIP host to participate simultaneously in 720 multiple different overlay networks. Therefore, a host needs to know 721 to which overlay an incoming HIP message belongs to. Thus, all HIP 722 messages that are sent via an overlay, or as a part of operations 723 specific to a certain overlay, MUST contain an OVERLAY_ID parameter 724 with the identifier of the corresponding overlay network. Instance 725 specifications define how the identifier is generated for different 726 types of overlay networks. The generation mechanism MUST be such 727 that it is unlikely to generate the same identifier for two different 728 overlay instances and hence it is RECOMMENDED that the identifier 729 contains at least 32 bits of randomness. 731 The generic format of the OVERLAY_ID parameter is shown in Figure 8. 732 Instance specifications define valid length for the parameter and how 733 the identifier values are generated. 735 0 1 2 3 736 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Identifier / 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 / | Padding | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Type [ TBD by IANA; 980 ] 746 Length Length of the Identifier in octets 747 Identifier The identifier value 748 Padding 0-7 bytes of padding if needed 750 Figure 8: Format of the OVERLAY_ID Parameter 752 6.2. Overlay TTL 754 HIP packets sent in an overlay network MAY contain an Overlay Time- 755 to-live (OVERLAY_TTL) parameter whose TTL value is decremented on 756 each overlay network hop. When a HIP host receives a HIP packet with 757 an OVERLAY_TTL parameter, and the host is not the final recipient of 758 the packet, it MUST decrement the TTL value in the parameter by one 759 before forwarding the packet. 761 If the TTL value in a received HIP packet is zero, and the receiving 762 host is not the final recipient, the packet MUST be dropped and the 763 host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED 764 (value [TBD by IANA; 70]) to the sender of the original HIP packet. 765 The Notification Data field for the OVERLAY_TTL_EXCEEDED 766 notifications SHOULD contain the HIP header and the TRANSACTION_ID 767 [I-D.ietf-hip-hiccups] parameter (if one exists) of the packet whose 768 TTL exceeded. 770 Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL 771 value is given as the number of overlay hops this packet has left and 772 it is encoded as an unsigned integer. 774 0 1 2 3 775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | TTL | Reserved | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Type [ TBD by IANA; 64011 ] 783 Length 4 784 TTL The Time-to-live value 785 Reserved Reserved for future use 787 Figure 9: Format of the OVERLAY_TTL Parameter 789 The type of the OVERLAY_TTL parameter is critical (as defined in 790 Section 5.2.1 of [RFC5201]) and therefore the final recipient of the 791 packet, and all HIP hosts on the path, MUST support it. If the 792 parameter is used in a scenario where the final recipient does not 793 support the parameter, the parameter SHOULD be removed before 794 forwarding the packet to the final recipient. 796 7. Security Considerations 798 This document provides a high-level framework to build HIP-based 799 overlays. The security properties of HIP and its extensions used in 800 this framework are discussed in their respective specifications. 801 Those security properties can be affected by the way HIP is used in a 802 particular overlay. However, those properties are mostly affected by 803 the design decisions made to build a particular overlay; not so much 804 by the high-level framework specified in this document. Such design 805 decisions are typically documented in a HIP BONE instance 806 specification, which describes the security properties of the 807 resulting overlay. 809 8. Acknowledgements 811 HIP BONE is based on ideas coming from conversations and discussions 812 with a number of people in the HIP and P2PSIP communities. In 813 particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas 814 Henderson, Bruce Lowekamp, and Miika Komu provided useful input on 815 HIP BONE. 817 9. IANA Considerations 819 This section is to be interpreted according to [RFC5226]. 821 This document updates the IANA Registry for HIP Parameter Types 822 [RFC5201] by assigning HIP Parameter Type values for the new HIP 823 Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL 824 (defined in Section 6.2). This document also defines a new HIP 825 Notify packet type [RFC5201] OVERLAY_TTL_EXCEEDED in Section 6.2. 827 10. References 829 10.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 835 for Overlay Routable Cryptographic Hash Identifiers 836 (ORCHID)", RFC 4843, April 2007. 838 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 839 "Host Identity Protocol", RFC 5201, April 2008. 841 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 842 Encapsulating Security Payload (ESP) Transport Format with 843 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 845 [I-D.ietf-hip-nat-traversal] 846 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 847 Keranen, "Basic HIP Extensions for Traversal of Network 848 Address Translators", draft-ietf-hip-nat-traversal-09 849 (work in progress), October 2009. 851 [I-D.ietf-hip-hiccups] 852 Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) 853 Immediate Carriage and Conveyance of Upper- layer Protocol 854 Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in 855 progress), March 2010. 857 10.2. Informative References 859 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 860 Protocol Architecture", RFC 4251, January 2006. 862 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 863 Rendezvous Extension", RFC 5204, April 2008. 865 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 866 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 867 April 2008. 869 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 870 Host Mobility and Multihoming with the Host Identity 871 Protocol", RFC 5206, April 2008. 873 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 874 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 875 May 2008. 877 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 878 Identity Protocol with Legacy Applications", RFC 5338, 879 September 2008. 881 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 882 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 883 October 2008. 885 [I-D.ietf-hip-native-api] 886 Komu, M. and T. Henderson, "Basic Socket Interface 887 Extensions for Host Identity Protocol (HIP)", 888 draft-ietf-hip-native-api-12 (work in progress), 889 January 2010. 891 [I-D.ietf-mmusic-ice] 892 Rosenberg, J., "Interactive Connectivity Establishment 893 (ICE): A Protocol for Network Address Translator (NAT) 894 Traversal for Offer/Answer Protocols", 895 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 897 [I-D.ietf-p2psip-base] 898 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 899 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 900 Base Protocol", draft-ietf-p2psip-base-07 (work in 901 progress), February 2010. 903 [I-D.ietf-hip-reload-instance] 904 Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity 905 Protocol-Based Overlay Networking Environment (HIP BONE) 906 Instance Specification for REsource LOcation And Discovery 907 (RELOAD)", draft-ietf-hip-reload-instance-00 (work in 908 progress), January 2010. 910 Authors' Addresses 912 Gonzalo Camarillo 913 Ericsson 914 Hirsalantie 11 915 Jorvas 02420 916 Finland 918 Email: Gonzalo.Camarillo@ericsson.com 920 Pekka Nikander 921 Ericsson 922 Hirsalantie 11 923 Jorvas 02420 924 Finland 926 Email: Pekka.Nikander@ericsson.com 928 Jani Hautakorpi 929 Ericsson 930 Hirsalantie 11 931 Jorvas 02420 932 Finland 934 Email: Jani.Hautakorpi@ericsson.com 936 Ari Keranen 937 Ericsson 938 Hirsalantie 11 939 02420 Jorvas 940 Finland 942 Email: Ari.Keranen@ericsson.com 944 Alan Johnston 945 Avaya 946 St. Louis, MO 63124 948 Email: alan@sipstation.com