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