idnits 2.17.1 draft-ietf-hip-bone-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** 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 495: '...certain overlay, MUST contain an OVERL...' RFC 2119 keyword, line 498: '...orks. The generation mechanism SHOULD...' RFC 2119 keyword, line 500: '...s and hence it is RECOMMENDED that the...' 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 (October 26, 2009) is 5289 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) ** Obsolete normative reference: RFC 5204 (Obsoleted by RFC 8004) ** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) == Outdated reference: A later version (-12) exists of draft-ietf-hip-native-api-09 == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-08 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-04 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: April 29, 2010 A. Keranen 6 Ericsson 7 A. Johnston 8 Avaya 9 October 26, 2009 11 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking 12 Environment 13 draft-ietf-hip-bone-03.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 29, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document specifies a framework to build HIP (Host Identity 52 Protocol)-based overlay networks. This framework uses HIP to perform 53 connection management. Other functions, such as data storage and 54 retrieval or overlay maintenance, are implemented using protocols 55 other than HIP. These protocols are loosely referred to as peer 56 protocols. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3 63 2.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4 64 2.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 4 65 2.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5 66 2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6 69 2.3.2. Identifier Assignment and Authentication . . . . . . . 6 70 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 71 2.4. HIP Deployability and Legacy Applications . . . . . . . . 7 72 3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9 74 3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10 75 3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11 76 3.4. Participating in Multiple Overlays . . . . . . . . . . . . 11 77 3.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 12 78 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 13 79 5. Architectural Considerations . . . . . . . . . . . . . . . . . 13 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The Host Identity Protocol (HIP) [RFC5201] defines a new name space 91 between the network and transport layers. HIP provides upper layers 92 with mobility, multihoming, NAT (Network Address Translation) 93 traversal, and security functionality. HIP implements the so called 94 identifier/locator (ID/locator) split, which implies that IP 95 addresses are only used as locators, not as host identifiers. This 96 split makes HIP a suitable protocol to build overlay networks that 97 implement identifier-based overlay routing over IP networks, which in 98 turn implement locator-based routing. 100 The remainder of this document is organized as follows. Section 2 101 provides background information on HIP. Section 3 describes the HIP 102 BONE (HIP-Based Overlay Networking Environment) framework. Section 4 103 discusses some of the advantages derived from using the HIP BONE 104 framework. Finally, before the customary sections, Section 5 105 attempts to put the presented proposal into a larger architectural 106 context. 108 2. Background on HIP 110 This section provides background on HIP. Given the tutorial nature 111 of this section, readers that are familiar with what HIP provides and 112 how HIP works may want to skip it. All descriptions contain 113 references to the relevant HIP specifications where readers can find 114 detailed explanations on the different topics discussed in this 115 section. 117 2.1. ID/locator Split 119 In an IP network, IP addresses typically serve two roles: they are 120 used as host identifiers and as host locators. IP addresses are 121 locators because a given host's IP address indicates where in the 122 network that host is located. IP networks route based on these 123 locators. Additionally, IP addresses are used to identify remote 124 hosts. The simultaneous use of IP addresses as host identifiers and 125 locators makes mobility and multihoming complicated. For example, 126 when a host opens a TCP connection, the host identifies the remote 127 end of the connection by the remote IP address (plus port). If the 128 remote host changes its IP address, the TCP connection will not 129 survive, since the transport layer identifier of the remote end of 130 the connection has changed. 132 Mobility solutions such as Mobile IP keep the remote IP address from 133 changing so that it can still be used as an identifier. HIP, on the 134 other hand, uses IP addresses as only locators and defines a new 135 identifier space. This approach is referred to as the ID/locator 136 split and makes the implementation of mobility and multihoming more 137 natural. In the previous example, the TCP connection would be bound 138 to the remote host's identifier, which would not change when the 139 remote hosts moves to a new IP address (i.e., to a new locator). The 140 TCP connection is able to survive locator changes because the remote 141 host's identifier does not change. 143 2.1.1. Identifier Format 145 HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash 146 Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 147 addresses but cannot collide with regular IPv6 addresses because 148 ORCHID spaces are registered with the IANA. That is, a portion of 149 the IPv6 address space is reserved for ORCHIDs. The ORCHID 150 specification allows creating multiple disjoint identifier spaces. 151 Each such space is identified by a separate Context Identifier. The 152 Context Identifier can be either drawn implicitly from the context 153 the ORCHID is used in or carried explicitly in a protocol. 155 HIP defines a native socket API [I-D.ietf-hip-native-api] that 156 applications can use to establish and manage connections. 157 Additionally, HIP can also be used through the traditional IPv4 and 158 IPv6 TCP/IP socket APIs. Section 2.4 describes how an application 159 using these traditional APIs can make use of HIP. Figure 1 shows all 160 these APIs between the application and the transport layers. 162 +-----------------------------------------+ 163 | Application | 164 +----------------+------------------------+ 165 | HIP Native API | Traditional Socket API | 166 +----------------+------------------------+ 167 | Transport Layer | 168 +-----------------------------------------+ 170 Figure 1: HIP API 172 2.1.2. HIP Base Exchange 174 Before two HIP hosts exchange upper-layer traffic, they perform a 175 four-way handshake that is referred to as the HIP base exchange. 176 Figure 2 illustrates the HIP base exchange. The initiator sends an 177 I1 packet and receives an R1 packet from the responder. After that, 178 the initiator sends an I2 packet and receives an R2 packet from the 179 responder. 181 Initiator Responder 183 | I1 | 184 | -------------------------->| 185 | R1 | 186 | <--------------------------| 187 | I2 | 188 | -------------------------->| 189 | R2 | 190 | <--------------------------| 192 Figure 2: HIP base exchange 194 Of course, the initiator needs the responder's locator (or locators) 195 in order to send its I1 packet. The initiator can obtain locators 196 for the responder in multiple ways. For example, according to the 197 current HIP specifications the initiator can get the locators 198 directly from the DNS [RFC5205] or indirectly by sending packets 199 through a HIP rendezvous server [RFC5204]. However, as an 200 architecture HIP is open ended, and allows the locators to be 201 obtained by any means (e.g., from packets traversing an overlay 202 network or as part of the candidate address collection process in a 203 NAT traversal scenario). 205 2.1.3. Locator Management 207 Once a HIP connection between two hosts has been established with a 208 HIP base exchange, the hosts can start exchanging higher-layer 209 traffic. If any of the hosts changes its set of locators, it runs an 210 update exchange [RFC5206], which consists of three messages. If a 211 host is multihomed, it simply provides more than one locator in its 212 exchanges. However, if both of the end points move at the same time, 213 or through some other reason both lose track of the peers' currently 214 active locators, they need to resort to using a rendezvous server or 215 getting new peer locators by some other means. 217 2.2. NAT Traversal 219 HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based 220 on ICE (Interactive Connectivity Establishment) 221 [I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part 222 of the HIP base exchange, hosts perform an ICE offer/answer exchange 223 where they exchange their respective address candidates. Hosts 224 perform end-to-end STUN [RFC5389] based connectivity checks in order 225 to discover which address candidate pairs yield connectivity. 227 Even though, architecturally, HIP lies below the transport layer 228 (i.e., HIP packets are carried directly in IP packets), in presence 229 of NATs, HIP sometimes needs to be tunneled in a transport protocol 230 (i.e., HIP packets are carried by a transport protocol such as UDP). 232 2.3. Security 234 Security is an essential part of HIP. The following sections 235 describe the security-related functionality provided by HIP. 237 2.3.1. DoS Protection 239 HIP provides protection against DoS (Denial of Service) attacks by 240 having initiators resolve a cryptographic puzzle before the responder 241 stores any state. On receiving an I1 packet, a responder sends a 242 pre-generated R1 packet that contains a cryptographic puzzle and 243 deletes all the state associated with the processing of this I1 244 packet. The initiator needs to resolve the puzzle in the R1 packet 245 in order to generate an I2 packet. The difficulty of the puzzle can 246 be adjusted so that, if a receiver is under a DoS attack, it can 247 increase the difficulty of its puzzles. 249 On receiving an I2 packet, a receiver checks that the solution in the 250 packet corresponds to a puzzle generated by the receiver and that the 251 solution is correct. If it is, the receiver processes the I2 packet. 252 Otherwise, it silently discards it. 254 In an overlay scenario, there are multiple ways how this mechanism 255 can be utilized within the overlay. One possibility is to cache the 256 pre-generated R1 packets within the overlay and let the overlay 257 directly respond with R1s to I1s. In that way the responder is not 258 bothered at all until the initiator sends an I2 packet, with the 259 puzzle solution. Furthermore, a more sophisticated overlay could 260 verify that an I2 packet has a correctly solved puzzle before 261 forwarding the packet to the responder. 263 2.3.2. Identifier Assignment and Authentication 265 As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main 266 representation for identifiers. Potentially, HIP can use different 267 types of ORCHIDs as long as the probability of finding collisions 268 (i.e., two nodes with the same ORCHID) is low enough. One way to 269 completely avoid this type of collision is to have a central 270 authority generate and assign ORCHIDs to nodes. To secure the 271 binding between ORCHIDs and any higher-layer identifiers, every time 272 the central authority assigns an ORCHID to a node, it also generates 273 and signs a certificate stating who is the owner of the ORCHID. The 274 owner of the ORCHID then includes the corresponding certificate in 275 its R1 (when acting as responder) and I2 packets (when acting 276 initiator) to prove that it is actually allowed to use the ORCHID 277 and, implicitly, the associated public key. 279 Having a central authority works well to completely avoid collisions. 280 However, having a central authority is impractical in some scenarios. 281 As defined today, HIP systems generally use a self-certifying ORCHID 282 type called HIT (Host Identity Tag) that does not require a central 283 authority (but still allows one to be used). 285 A HIT is the hash of a node's public key. A node proves that it has 286 the right to use a HIT by showing its ability to sign data with its 287 associated private key. This scheme is secure due to the so called 288 second-preimage resistance property of hash functions. That is, 289 given a fixed public key K1, finding a different public key K2 such 290 that hash(K1) = hash(K2) is computationally very hard. Optimally, a 291 preimage attack on the 100-bit hash function used in ORCHIDs will 292 take an order of 2^100 operations to be successful, and can be 293 expected to take in the average 2^99 operations. Given that each 294 operation requires the attacker to generate a new key pair, the 295 attack is completely impractical (see [RFC4843]). 297 HIP nodes using HITs as ORCHIDs do not typically use certificates 298 during their base exchanges. Instead, the use a leap-of-faith 299 mechanism, similar to SSH, whereby a node authenticates somehow 300 remote nodes the first time they connect it and, then, remembers 301 their public keys. While user-assisted leap-of-faith (such as in 302 SSH) can be used to facilitate a human-operated offline path (such as 303 a telephone call), automated leap-of-faith can be combined with a 304 reputation management system to create an incentive to behave. 305 However, such considerations go well beyond the current HIP 306 architecture and even beyond this proposal. For the purposes of the 307 present document, we merely want to point out that architecturally 308 HIP supports both self-generated opportunistic identifiers and 309 administratively assigned ones. 311 2.3.3. Connection Security 313 Once two nodes complete a base exchange between them, the traffic 314 they exchange is encrypted and integrity protected. The security 315 mechanism used to protect the traffic is IPsec ESP [RFC5202]. 316 However, there is ongoing work to specify how to use different 317 protection mechanisms. 319 2.4. HIP Deployability and Legacy Applications 321 As discussed earlier, HIP defines a native socket API 322 [I-D.ietf-hip-native-api] that applications can use to establish and 323 manage connections. New applications can implement this API to get 324 full advantage of HIP. However, in most cases, legacy (i.e., non-HIP 325 aware) applications [RFC5338] can use HIP through the traditional 326 IPv4 and IPv6 socket APIs. 328 The idea is that when a legacy IPv6 application tries and obtains a 329 remote host's IP address (e.g., by querying the DNS) the DNS resolver 330 passes the remote host's ORCHID (which was also stored in the DNS) to 331 the legacy application. At the same time, the DNS resolver stores 332 the remote host's IP address internally at the HIP module. Since the 333 ORCHID looks like an IPv6 address, the legacy application treats it 334 as such. It opens a connection (e.g., TCP) using the traditional 335 IPv6 socket API. The HIP module running in the same host as the 336 legacy application intercepts this call somehow (e.g., using an 337 interception library or setting up the host's routing tables so that 338 the HIP module receives the traffic) and runs HIP (on behalf of the 339 legacy application) towards the IP address corresponding to the 340 ORCHID. This mechanism works well in almost all cases. However, 341 applications involving referrals (i.e., passing of IPv6 addresses 342 between applications) present issues, to be discussed in Section 3 343 below. Additionally, management applications that care about the 344 exact IP address format may not work well with such straightforward 345 approach. 347 In order to make HIP work through the traditional IPv4 socket API, 348 the HIP module passes an LSI (Local Scope Identifier), instead of a 349 regular IPv4 address, to the legacy IPv4 application. The LSI looks 350 like an IPv4 address, but is locally bound to an ORCHID. That is, 351 when the legacy application uses the LSI in a socket call, the HIP 352 module intercepts it and replaces the LSI with its corresponding 353 ORCHID. Therefore, LSIs always have local scope. They do not have 354 any meaning outside the host running the application. The ORCHID is 355 used on the wire; not the LSI. In the referral case, if it is not 356 possible to rewrite the application level packets to use ORCHIDs 357 instead of LSIs, it may be hard to make IPv4 referrals work in 358 Internet-wide settings. IPv4 LSIs have been successfully used in 359 existing HIP deployments within a single corporate network. 361 3. The HIP BONE Framework 363 An overlay typically requires three types of operations: 365 o overlay maintenance. 366 o data storage and retrieval. 367 o connection management. 369 Overlay maintenance operations deal with nodes joining and leaving 370 the overlay and with the maintenance of the overlay's routing tables. 371 Data storage and retrieval operations deal with nodes storing, 372 retrieving, and removing information in or from the overlay. 373 Connection management operations deal with the establishment of 374 connections and the exchange of lightweight messages among the nodes 375 of the overlay, potentially in the presence of NATs. 377 The HIP BONE framework uses HIP to perform connection management. 378 Data storage and retrieval and overlay maintenance are to be 379 implemented using protocols other than HIP. For lack of a better 380 name, these protocols are referred to as peer protocols. 382 HIP BONE is a generic framework that allows the use of different peer 383 protocols. A particular HIP BONE instance uses a particular peer 384 protocol. The details on how to implement a HIP BONE using a given 385 peer protocol need to be specified in a, so called, HIP BONE instance 386 specification. Section 3.5 discusses what details need to be 387 specified by HIP BONE instance specifications. For example, the HIP 388 BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is 389 specified in [I-D.keranen-hip-reload-instance]. 391 3.1. Peer ID Assignment and Bootstrap 393 Nodes in an overlay are primarily identified by their Peer IDs. 394 (Note that the Peer ID concept here is a peer-layer protocol concept, 395 distinct from the HIP-layer node identifiers. Peer IDs may be long, 396 may have some structure, and may consist of multiple parts.) 397 Overlays typically have an enrollment server that can generate Peer 398 IDs, or at least some part of the Peer ID, and sign certificates. A 399 certificate generated by an enrollment server authorizes a particular 400 user to use a particular Peer ID in a particular overlay. The way 401 users and overlays are identified and the format for Peer IDs are 402 defined by the peer protocol. 404 The enrollment server of an overlay that were to use plain public 405 keys as Peer IDs could just authorize users to use the public keys 406 and HITs associated to their nodes. This works well as long as the 407 enrollment server is the one generating the public/private key pairs 408 for all those nodes. If the enrollment server authorizes users to 409 use HITs that are generated directly by the nodes themselves, the 410 system is open to a type of chosen-peer-ID attack. 412 However, in some cases it is impractical to have the enrollment 413 server generate public/private key pairs for devices. In these 414 cases, the enrollment server simply generates Peer IDs whose format 415 is defined by the peer protocol used in the overlay. Since HIP needs 416 ORCHIDs (and not any type of Peer ID) to work, hosts in the overlay 417 will transform their Peer IDs into ORCHIDs, for example, by taking a 418 hash of the Peer IDs or taking a hash of the Peer ID and the public 419 key. That is a similar process to the one a host follows to generate 420 a HIT from a public key. In such scenarios, each host will need a 421 certificate (e.g., in their HIP base exchanges) provided by the 422 enrollment server to prove that they are authorized to use a 423 particular ORCHID in the overlay. Depending on how the certificates 424 are constructed, they typically also need to contain the host's self- 425 generated public key. Depending on how the Peer IDs and public keys 426 are attributed, different scenarios become possible. For example, 427 the Peer IDs may be attributed to users, there may be user public key 428 identifiers, and there may be separate host public key identifiers. 429 Authorization certificates can be used to bind the different types of 430 identifiers together. 432 Bootstrap issues such as how to locate an enrollment or a bootstrap 433 server belong to the peer protocol. 435 3.2. Connection Establishment 437 Nodes in an overlay need to establish connection with other nodes in 438 different cases. For example, a node typically has connections to 439 the nodes in its forwarding table. Nodes also need to establish 440 connections with other nodes in order to exchange application-layer 441 messages. 443 As discussed earlier, HIP uses the base exchange to establish 444 connections. A HIP endpoint (the initiator) initiates a HIP base 445 exchange with a remote endpoint by sending an I1 packet. The 446 initiator sends the I1 packet to the remote endpoint's locator. 447 Initiators that do not have any locator for the remote endpoint need 448 to use a rendezvous service. Traditionally, a HIP rendezvous server 449 [RFC5204] has provided such a rendezvous service. In HIP BONE, the 450 overlay itself provides the rendezvous service. 452 Therefore, in HIP BONE, a node uses an I1 packet (as usual) to 453 establish a connection with another node in the overlay. Nodes in 454 the overlay forward I1 packets in a hop-by-hop fashion according to 455 the overlay's routing table towards its destination. This way, the 456 overlay provides a rendezvous service between the nodes establishing 457 the connection. If the overlay nodes have active connections with 458 other nodes in their forwarding tables and if those connections are 459 protected (typically with IPsec ESP), I1 packets may be sent over 460 protected connections between nodes. Alternatively, if there is no 461 such an active connection but the node forwarding the I1 packet has a 462 valid locator for the next hop, the I1 packets may be forwarded 463 directly, in a similar fashion to how I1 packets are today forwarded 464 by a HIP rendezvous server. 466 Since HIP supports NAT traversal, a HIP base exchange over the 467 overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer 468 exchange between the nodes that are establishing the connection. In 469 order to perform this exchange, the nodes need to first gather 470 candidate addresses. Which nodes can be used to obtain reflexive 471 address candidates and which ones can be used to obtain relayed 472 candidates is defined by the peer protocol. 474 3.3. Lightweight Message Exchanges 476 In some cases, nodes need to perform a lightweight query to another 477 node (e.g., a request followed by a single response). In this 478 situation, establishing a connection using the mechanisms in 479 Section 3.2 for a simple query would be an overkill. A better 480 solution is to forward a HIP message through the overlay with the 481 query and another one with the response to the query. The payload of 482 such HIP packets is integrity protected [I-D.nikander-hip-hiccups]. 483 Nodes in the overlay forward this HIP packet in a hop-by-hop fashion 484 according to the overlay's routing table towards its destination, 485 typically through the protected connections established between them. 486 Again, the overlay acts as a rendezvous server between the nodes 487 exchanging the messages. 489 3.4. Participating in Multiple Overlays 491 It is possible for a HIP host to participate simultaneously in 492 multiple different overlay networks and a host needs to know to which 493 overlay an incoming HIP message belongs to. Thus all HIP messages 494 that are sent via an overlay, or as a part of operations specific to 495 a certain overlay, MUST contain an OVERLAY_ID parameter (shown in 496 Figure 3) with the identifier of the corresponding overlay network. 497 Instance specifications define how the identifier is generated for 498 different types of overlay networks. The generation mechanism SHOULD 499 be such that it is unlikely to generate the same identifier for two 500 different overlay instances and hence it is RECOMMENDED that the 501 identifier contains at least 32 bits of randomness. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Identifier / 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 / | Padding | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Type [ TBD by IANA: 980 ] 514 Length Length of the Identifier in octets 515 Identifier The overlay identifier 516 Padding 0-7 bytes of padding if the identifier length is not 517 multiple of 8 bytes 519 Figure 3: Format of the OVERLAY_ID parameter 521 OPEN ISSUE: this introduces normative language to the architecture 522 draft. Should this parameter be defined in some other (possibly 523 stand alone) draft? 525 3.5. HIP BONE Instantiation 527 As discussed in Section 3, HIP BONE is a generic framework that 528 allows using different peer protocols. A particular HIP BONE 529 instance uses a particular peer protocol. The details on how to 530 implement a HIP BONE using a given peer protocol need to be specified 531 in a, so called, HIP BONE instance specification. A HIP BONE 532 instance specification needs to define, minimally: 534 o the peer protocol to be used. 535 o how to transform the peer IDs used by the peer protocol into the 536 ORCHIDs that will be used in HIP. 537 o which peer protocol primitives trigger HIP messages. 538 o how the overlay identifier is generated. 540 Additionally, a HIP BONE instance specification may need to specify 541 other details that are specific to the peer protocol used. 543 As an example, the HIP BONE instance specification for RELOAD 544 [I-D.ietf-p2psip-base] is specified in 545 [I-D.keranen-hip-reload-instance]. 547 It is assumed that areas not covered by a particular HIP BONE 548 instance specification are specified by the peer protocol or 549 elsewhere. These areas include: 551 o the algorithm to create the overlay (e.g., a DHT). 552 o overlay maintenance functions. 553 o data storage and retrieval functions. 554 o format and structure of peer IDs. 555 o the process for obtaining a peer ID. 556 o bootstrap function 557 o how to select STUN and TURN servers for the candidate address 558 collection process in NAT traversal scenarios. 559 o for what type of traffic or messages it is appropriate to use 560 lightweight message exchanges. 562 Note that the border between HIP BONE instance specification and a 563 peer protocol specifications is blurry. Depending on how generic the 564 specification of a given peer protocol is, its associated HIP BONE 565 instance specification may need to specify more or less details. 566 Also, a HIP BONE instance specification may leave certain areas 567 unspecified in order to leave their configuration up to each 568 particular overlay. 570 4. Advantages of Using HIP BONE 572 Using HIP BONE, as opposed to a peer protocol, to perform connection 573 management in an overlay has a set of advantages. HIP BONE can be 574 used by any peer protocol. This keeps each peer protocol from 575 defining primitives needed for connection management (e.g., 576 primitives to establish connections and to tunnel messages through 577 the overlay) and NAT traversal. Having this functionality at a lower 578 layer allows multiple upper-layer protocols to take advantage of it. 580 Additionally, having a solution that integrates mobility and 581 multihoming is useful in many scenarios. Peer protocols do not 582 typically specify mobility and multihoming solutions. Combining a 583 peer protocol including NAT traversal with a separate mobility 584 mechanism and a separate multihoming mechanism can easily lead to 585 unexpected (and unpleasant) interactions. 587 5. Architectural Considerations 589 Architecturally, HIP can be considered to create a new thin "waist" 590 layer on the top of the IPv4 and IPv6 networks; see Figure 4. The 591 HIP layer itself consists of the HIP signaling protocol and one or 592 more data transport protocols; see Figure 5. The HIP signaling 593 packets and the data transport packets can take different routes. In 594 the HIP BONE, the HIP signaling packets are typically first routed 595 through the overlay and then directly (if possible), while the data 596 transport packets are typically routed only directly between the end 597 points. 599 +--------------------------------------+ 600 | Transport (using HITs or LSIs) | 601 +--------------------------------------+ 602 | HIP | 603 +------------------+-------------------+ 604 | IPv4 | IPv6 | 605 +------------------+-------------------+ 607 Figure 4: HIP as a thin waist 609 +------------------+-------------------+ 610 | HIP signaling | data transports | 611 +------------------+-------------------+ 613 Figure 5: HIP layer structure 615 In HIP BONE, the peer protocol creates a new signaling layer on the 616 top of HIP. It is used to set up forwarding paths for HIP signaling 617 messages. This is a similar relationship that an IP routing 618 protocol, such as OSPF, has to the IP protocol itself. In the HIP 619 BONE case, the peer protocol plays a role similar to OSPF, and HIP 620 plays a role similar to IP. The ORCHIDs are used for forwarding HIP 621 packets according to the information in the routing tables. The peer 622 protocols are used to exchange routing information based on Peer IDs 623 and public keys, and to construct the routing tables. 625 Architecturally, routing tables are located between the peer protocol 626 and HIP, as shown in Figure 6. The peer protocol constructs the 627 routing table and keeps it updated. The HIP layer accesses the 628 routing table in order to make routing decisions. The bootstrap of a 629 HIP BONE overlay does not create circular dependencies between the 630 peer protocol (which needs to use HIP to establish connections with 631 other nodes) and HIP (which needs the peer protocol to know how to 632 route messages to other nodes) for the same reasons as the bootstrap 633 of an IP network does not create circular dependencies between OSPF 634 and IP. The first connections established by the peer protocol are 635 with nodes whose locators are known. HIP establishes those 636 connections as any connection between two HIP nodes where no overlays 637 are present. That is, there is no need for the overlay to provide a 638 rendezvous service for those connections. 640 +--------------------------------------+ 641 | Peer protocol | 642 +--------------------------------------+ 643 | Routing table | 644 +--------------------------------------+ 645 | HIP | 646 +--------------------------------------+ 648 Figure 6: Routing tables 650 It is possible that different overlays use different routing table 651 formats. For example, the structure of the routing tables of two 652 overlays based on different DHTs (Distributed Hash Tables) may be 653 very different. In order to make routing decisions, the HIP layer 654 needs to convert the routing table generated by the peer protocol 655 into a forwarding table that allows the HIP layer select a next-hop 656 for any packet being routed. 658 In HIP BONE, the HIP usage of public keys and deriving ORCHIDs 659 through a hash function can be utilized at the peer protocol side to 660 better secure routing table maintenance and to protect against 661 chosen-peer-ID attacks. 663 The HIP BONE provides quite a lot of flexibility with regards to how 664 to arrange the different protocols in detail. Figure 7 shows one 665 potential stack structure. 667 +-----------------------+--------------+ 668 | peer protocols | media | 669 +------------------+----+--------------+ 670 | HIP signaling | data transport | 671 | | 672 +------------------+-------------------+ 673 | NAT | non-NAT | | 674 | | | 675 | IPv4 | IPv6 | 676 +------------------+-------------------+ 678 Figure 7: Example HIP BONE stack structure 680 6. Security Considerations 682 This document provides a high-level framework to build HIP-based 683 overlays. The security properties of HIP and its extensions used in 684 this framework are discussed in their respective specifications. 685 Those security properties can be affected by the way HIP is used in a 686 particular overlay (e.g., by how ORCHIDs are derived from Peer IDs). 687 However, those properties are mostly affected by the design decisions 688 made to build a particular overlay; not so much by how this high- 689 level framework is specified in this document. Such design decisions 690 are typically documented in a HIP BONE instance specification, which 691 will describe the security properties of the resulting overlay. 693 7. Acknowledgements 695 HIP BONE is based on ideas coming from conversations and discussions 696 with a number of people in the HIP and P2PSIP communities. In 697 particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas 698 Henderson, Bruce Lowekamp, and Miika Komu provided useful input on 699 HIP BONE. 701 8. IANA Considerations 703 This document does not contain any IANA actions. 705 9. References 707 9.1. Normative References 709 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 710 for Overlay Routable Cryptographic Hash Identifiers 711 (ORCHID)", RFC 4843, April 2007. 713 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 714 "Host Identity Protocol", RFC 5201, April 2008. 716 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 717 Encapsulating Security Payload (ESP) Transport Format with 718 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 720 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 721 Rendezvous Extension", RFC 5204, April 2008. 723 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 724 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 725 April 2008. 727 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 728 Host Mobility and Multihoming with the Host Identity 729 Protocol", RFC 5206, April 2008. 731 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 732 Identity Protocol with Legacy Applications", RFC 5338, 733 September 2008. 735 [I-D.ietf-hip-native-api] 736 Komu, M. and T. Henderson, "Basic Socket Interface 737 Extensions for Host Identity Protocol (HIP)", 738 draft-ietf-hip-native-api-09 (work in progress), 739 September 2009. 741 [I-D.ietf-hip-nat-traversal] 742 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 743 Keraenen, "Basic HIP Extensions for Traversal of Network 744 Address Translators", draft-ietf-hip-nat-traversal-08 745 (work in progress), June 2009. 747 [I-D.nikander-hip-hiccups] 748 Nikander, P., Camarillo, G., and J. Melen, "HIP (Host 749 Identity Protocol) Immediate Carriage and Conveyance of 750 Upper- layer Protocol Signaling (HICCUPS)", 751 draft-nikander-hip-hiccups-04 (work in progress), 752 August 2009. 754 9.2. Informative References 756 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 757 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 758 October 2008. 760 [I-D.ietf-mmusic-ice] 761 Rosenberg, J., "Interactive Connectivity Establishment 762 (ICE): A Protocol for Network Address Translator (NAT) 763 Traversal for Offer/Answer Protocols", 764 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 766 [I-D.ietf-p2psip-base] 767 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 768 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 769 Base Protocol", draft-ietf-p2psip-base-04 (work in 770 progress), October 2009. 772 [I-D.keranen-hip-reload-instance] 773 Keranen, A. and G. Camarillo, "HIP BONE Instance 774 Specification for RELOAD", 775 draft-keranen-hip-reload-instance-00 (work in progress), 776 July 2009. 778 Authors' Addresses 780 Gonzalo Camarillo 781 Ericsson 782 Hirsalantie 11 783 Jorvas 02420 784 Finland 786 Email: Gonzalo.Camarillo@ericsson.com 788 Pekka Nikander 789 Ericsson 790 Hirsalantie 11 791 Jorvas 02420 792 Finland 794 Email: Pekka.Nikander@ericsson.com 796 Jani Hautakorpi 797 Ericsson 798 Hirsalantie 11 799 Jorvas 02420 800 Finland 802 Email: Jani.Hautakorpi@ericsson.com 804 Ari Keranen 805 Ericsson 806 Hirsalantie 11 807 02420 Jorvas 808 Finland 810 Email: Ari.Keranen@ericsson.com 812 Alan Johnston 813 Avaya 814 St. Louis, MO 63124 816 Email: alan@sipstation.com