idnits 2.17.1 draft-ietf-hip-bone-04.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 (January 26, 2010) is 5203 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-ietf-hip-hiccups-01 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-06 == Outdated reference: A later version (-10) exists of draft-ietf-hip-reload-instance-00 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: July 30, 2010 A. Keranen 6 Ericsson 7 A. Johnston 8 Avaya 9 January 26, 2010 11 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking 12 Environment 13 draft-ietf-hip-bone-04.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 July 30, 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 . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3 67 3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4 68 3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 69 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5 70 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6 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. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 9 77 4.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9 78 4.2. Connection Establishment . . . . . . . . . . . . . . . . . 10 79 4.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11 80 4.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11 81 5. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12 82 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 13 83 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 13 84 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 14 85 7. Architectural Considerations . . . . . . . . . . . . . . . . . 14 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The Host Identity Protocol (HIP) [RFC5201] defines a new name space 97 between the network and transport layers. HIP provides upper layers 98 with mobility, multihoming, NAT (Network Address Translation) 99 traversal, and security functionality. HIP implements the so called 100 identifier/locator (ID/locator) split, which implies that IP 101 addresses are only used as locators, not as host identifiers. This 102 split makes HIP a suitable protocol to build overlay networks that 103 implement identifier-based overlay routing over IP networks, which in 104 turn implement locator-based routing. 106 The remainder of this document is organized as follows. Section 3 107 provides background information on HIP. Section 4 describes the HIP 108 BONE (HIP-Based Overlay Networking Environment) framework. Section 5 109 discusses some of the advantages derived from using the HIP BONE 110 framework. Section 6 introduces new HIP parameters for overlay 111 usage. Finally, before the customary sections, Section 7 attempts to 112 put the presented proposal into a larger architectural context. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Background on HIP 122 This section provides background on HIP. Given the tutorial nature 123 of this section, readers that are familiar with what HIP provides and 124 how HIP works may want to skip it. All descriptions contain 125 references to the relevant HIP specifications where readers can find 126 detailed explanations on the different topics discussed in this 127 section. 129 3.1. ID/locator Split 131 In an IP network, IP addresses typically serve two roles: they are 132 used as host identifiers and as host locators. IP addresses are 133 locators because a given host's IP address indicates where in the 134 network that host is located. IP networks route based on these 135 locators. Additionally, IP addresses are used to identify remote 136 hosts. The simultaneous use of IP addresses as host identifiers and 137 locators makes mobility and multihoming complicated. For example, 138 when a host opens a TCP connection, the host identifies the remote 139 end of the connection by the remote IP address (plus port). If the 140 remote host changes its IP address, the TCP connection will not 141 survive, since the transport layer identifier of the remote end of 142 the connection has changed. 144 Mobility solutions such as Mobile IP keep the remote IP address from 145 changing so that it can still be used as an identifier. HIP, on the 146 other hand, uses IP addresses as only locators and defines a new 147 identifier space. This approach is referred to as the ID/locator 148 split and makes the implementation of mobility and multihoming more 149 natural. In the previous example, the TCP connection would be bound 150 to the remote host's identifier, which would not change when the 151 remote hosts moves to a new IP address (i.e., to a new locator). The 152 TCP connection is able to survive locator changes because the remote 153 host's identifier does not change. 155 3.1.1. Identifier Format 157 HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash 158 Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 159 addresses but cannot collide with regular IPv6 addresses because 160 ORCHID spaces are registered with the IANA. That is, a portion of 161 the IPv6 address space is reserved for ORCHIDs. The ORCHID 162 specification allows creating multiple disjoint identifier spaces. 163 Each such space is identified by a separate Context Identifier. The 164 Context Identifier can be either drawn implicitly from the context 165 the ORCHID is used in or carried explicitly in a protocol. 167 HIP defines a native socket API [I-D.ietf-hip-native-api] that 168 applications can use to establish and manage connections. 169 Additionally, HIP can also be used through the traditional IPv4 and 170 IPv6 TCP/IP socket APIs. Section 3.4 describes how an application 171 using these traditional APIs can make use of HIP. Figure 1 shows all 172 these APIs between the application and the transport layers. 174 +-----------------------------------------+ 175 | Application | 176 +----------------+------------------------+ 177 | HIP Native API | Traditional Socket API | 178 +----------------+------------------------+ 179 | Transport Layer | 180 +-----------------------------------------+ 182 Figure 1: HIP API 184 3.1.2. HIP Base Exchange 186 Before two HIP hosts exchange upper-layer traffic, they perform a 187 four-way handshake that is referred to as the HIP base exchange. 188 Figure 2 illustrates the HIP base exchange. The initiator sends an 189 I1 packet and receives an R1 packet from the responder. After that, 190 the initiator sends an I2 packet and receives an R2 packet from the 191 responder. 193 Initiator Responder 195 | I1 | 196 | -------------------------->| 197 | R1 | 198 | <--------------------------| 199 | I2 | 200 | -------------------------->| 201 | R2 | 202 | <--------------------------| 204 Figure 2: HIP base exchange 206 Of course, the initiator needs the responder's locator (or locators) 207 in order to send its I1 packet. The initiator can obtain locators 208 for the responder in multiple ways. For example, according to the 209 current HIP specifications the initiator can get the locators 210 directly from the DNS [RFC5205] or indirectly by sending packets 211 through a HIP rendezvous server [RFC5204]. However, as an 212 architecture HIP is open ended, and allows the locators to be 213 obtained by any means (e.g., from packets traversing an overlay 214 network or as part of the candidate address collection process in a 215 NAT traversal scenario). 217 3.1.3. Locator Management 219 Once a HIP connection between two hosts has been established with a 220 HIP base exchange, the hosts can start exchanging higher-layer 221 traffic. If any of the hosts changes its set of locators, it runs an 222 update exchange [RFC5206], which consists of three messages. If a 223 host is multihomed, it simply provides more than one locator in its 224 exchanges. However, if both of the end points move at the same time, 225 or through some other reason both lose track of the peers' currently 226 active locators, they need to resort to using a rendezvous server or 227 getting new peer locators by some other means. 229 3.2. NAT Traversal 231 HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based 232 on ICE (Interactive Connectivity Establishment) 233 [I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part 234 of the HIP base exchange, hosts perform an ICE offer/answer exchange 235 where they exchange their respective address candidates. Hosts 236 perform end-to-end STUN [RFC5389] based connectivity checks in order 237 to discover which address candidate pairs yield connectivity. 239 Even though, architecturally, HIP lies below the transport layer 240 (i.e., HIP packets are carried directly in IP packets), in presence 241 of NATs, HIP sometimes needs to be tunneled in a transport protocol 242 (i.e., HIP packets are carried by a transport protocol such as UDP). 244 3.3. Security 246 Security is an essential part of HIP. The following sections 247 describe the security-related functionality provided by HIP. 249 3.3.1. DoS Protection 251 HIP provides protection against DoS (Denial of Service) attacks by 252 having initiators resolve a cryptographic puzzle before the responder 253 stores any state. On receiving an I1 packet, a responder sends a 254 pre-generated R1 packet that contains a cryptographic puzzle and 255 deletes all the state associated with the processing of this I1 256 packet. The initiator needs to resolve the puzzle in the R1 packet 257 in order to generate an I2 packet. The difficulty of the puzzle can 258 be adjusted so that, if a receiver is under a DoS attack, it can 259 increase the difficulty of its puzzles. 261 On receiving an I2 packet, a receiver checks that the solution in the 262 packet corresponds to a puzzle generated by the receiver and that the 263 solution is correct. If it is, the receiver processes the I2 packet. 264 Otherwise, it silently discards it. 266 In an overlay scenario, there are multiple ways how this mechanism 267 can be utilized within the overlay. One possibility is to cache the 268 pre-generated R1 packets within the overlay and let the overlay 269 directly respond with R1s to I1s. In that way the responder is not 270 bothered at all until the initiator sends an I2 packet, with the 271 puzzle solution. Furthermore, a more sophisticated overlay could 272 verify that an I2 packet has a correctly solved puzzle before 273 forwarding the packet to the responder. 275 3.3.2. Identifier Assignment and Authentication 277 As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main 278 representation for identifiers. Potentially, HIP can use different 279 types of ORCHIDs as long as the probability of finding collisions 280 (i.e., two nodes with the same ORCHID) is low enough. One way to 281 completely avoid this type of collision is to have a central 282 authority generate and assign ORCHIDs to nodes. To secure the 283 binding between ORCHIDs and any higher-layer identifiers, every time 284 the central authority assigns an ORCHID to a node, it also generates 285 and signs a certificate stating who is the owner of the ORCHID. The 286 owner of the ORCHID then includes the corresponding certificate in 287 its R1 (when acting as responder) and I2 packets (when acting 288 initiator) to prove that it is actually allowed to use the ORCHID 289 and, implicitly, the associated public key. 291 Having a central authority works well to completely avoid collisions. 292 However, having a central authority is impractical in some scenarios. 293 As defined today, HIP systems generally use a self-certifying ORCHID 294 type called HIT (Host Identity Tag) that does not require a central 295 authority (but still allows one to be used). 297 A HIT is the hash of a node's public key. A node proves that it has 298 the right to use a HIT by showing its ability to sign data with its 299 associated private key. This scheme is secure due to the so called 300 second-preimage resistance property of hash functions. That is, 301 given a fixed public key K1, finding a different public key K2 such 302 that hash(K1) = hash(K2) is computationally very hard. Optimally, a 303 preimage attack on the 100-bit hash function used in ORCHIDs will 304 take an order of 2^100 operations to be successful, and can be 305 expected to take in the average 2^99 operations. Given that each 306 operation requires the attacker to generate a new key pair, the 307 attack is completely impractical (see [RFC4843]). 309 HIP nodes using HITs as ORCHIDs do not typically use certificates 310 during their base exchanges. Instead, the use a leap-of-faith 311 mechanism, similar to SSH, whereby a node authenticates somehow 312 remote nodes the first time they connect it and, then, remembers 313 their public keys. While user-assisted leap-of-faith (such as in 314 SSH) can be used to facilitate a human-operated offline path (such as 315 a telephone call), automated leap-of-faith can be combined with a 316 reputation management system to create an incentive to behave. 317 However, such considerations go well beyond the current HIP 318 architecture and even beyond this proposal. For the purposes of the 319 present document, we merely want to point out that architecturally 320 HIP supports both self-generated opportunistic identifiers and 321 administratively assigned ones. 323 3.3.3. Connection Security 325 Once two nodes complete a base exchange between them, the traffic 326 they exchange is encrypted and integrity protected. The security 327 mechanism used to protect the traffic is IPsec ESP [RFC5202]. 328 However, there is ongoing work to specify how to use different 329 protection mechanisms. 331 3.4. HIP Deployability and Legacy Applications 333 As discussed earlier, HIP defines a native socket API 334 [I-D.ietf-hip-native-api] that applications can use to establish and 335 manage connections. New applications can implement this API to get 336 full advantage of HIP. However, in most cases, legacy (i.e., non-HIP 337 aware) applications [RFC5338] can use HIP through the traditional 338 IPv4 and IPv6 socket APIs. 340 The idea is that when a legacy IPv6 application tries and obtains a 341 remote host's IP address (e.g., by querying the DNS) the DNS resolver 342 passes the remote host's ORCHID (which was also stored in the DNS) to 343 the legacy application. At the same time, the DNS resolver stores 344 the remote host's IP address internally at the HIP module. Since the 345 ORCHID looks like an IPv6 address, the legacy application treats it 346 as such. It opens a connection (e.g., TCP) using the traditional 347 IPv6 socket API. The HIP module running in the same host as the 348 legacy application intercepts this call somehow (e.g., using an 349 interception library or setting up the host's routing tables so that 350 the HIP module receives the traffic) and runs HIP (on behalf of the 351 legacy application) towards the IP address corresponding to the 352 ORCHID. This mechanism works well in almost all cases. However, 353 applications involving referrals (i.e., passing of IPv6 addresses 354 between applications) present issues, to be discussed in Section 4 355 below. Additionally, management applications that care about the 356 exact IP address format may not work well with such straightforward 357 approach. 359 In order to make HIP work through the traditional IPv4 socket API, 360 the HIP module passes an LSI (Local Scope Identifier), instead of a 361 regular IPv4 address, to the legacy IPv4 application. The LSI looks 362 like an IPv4 address, but is locally bound to an ORCHID. That is, 363 when the legacy application uses the LSI in a socket call, the HIP 364 module intercepts it and replaces the LSI with its corresponding 365 ORCHID. Therefore, LSIs always have local scope. They do not have 366 any meaning outside the host running the application. The ORCHID is 367 used on the wire; not the LSI. In the referral case, if it is not 368 possible to rewrite the application level packets to use ORCHIDs 369 instead of LSIs, it may be hard to make IPv4 referrals work in 370 Internet-wide settings. IPv4 LSIs have been successfully used in 371 existing HIP deployments within a single corporate network. 373 4. The HIP BONE Framework 375 An overlay typically requires three types of operations: 377 o overlay maintenance. 378 o data storage and retrieval. 379 o connection management. 381 Overlay maintenance operations deal with nodes joining and leaving 382 the overlay and with the maintenance of the overlay's routing tables. 383 Data storage and retrieval operations deal with nodes storing, 384 retrieving, and removing information in or from the overlay. 385 Connection management operations deal with the establishment of 386 connections and the exchange of lightweight messages among the nodes 387 of the overlay, potentially in the presence of NATs. 389 The HIP BONE framework uses HIP to perform connection management. 390 Data storage and retrieval and overlay maintenance are to be 391 implemented using protocols other than HIP. For lack of a better 392 name, these protocols are referred to as peer protocols. 394 HIP BONE is a generic framework that allows the use of different peer 395 protocols. A particular HIP BONE instance uses a particular peer 396 protocol. The details on how to implement a HIP BONE using a given 397 peer protocol need to be specified in a, so called, HIP BONE instance 398 specification. Section 4.4 discusses what details need to be 399 specified by HIP BONE instance specifications. For example, the HIP 400 BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is 401 specified in [I-D.ietf-hip-reload-instance]. 403 4.1. Peer ID Assignment and Bootstrap 405 Nodes in an overlay are primarily identified by their Peer IDs. 406 Overlays typically have an enrollment server that can generate Peer 407 IDs, or at least some part of the Peer ID, and sign certificates. A 408 certificate generated by an enrollment server authorizes a particular 409 user to use a particular Peer ID in a particular overlay. The way 410 users and overlays are identified are defined by the peer protocol 411 and HIP BONE instance specification. 413 The enrollment server of an overlay that were to use HITs derived 414 from public keys as Peer IDs could just authorize users to use the 415 public keys and HITs associated to their nodes. Such a Peer ID has 416 the same self-certifying property as HITs and the Peer ID can also be 417 used in the HIP and legacy APIs as an ORCHID. This works well as 418 long as the enrollment server is the one generating the public/ 419 private key pairs for all those nodes. If the enrollment server 420 authorizes users to use HITs that are generated directly by the nodes 421 themselves, the system is open to a type of chosen-peer-ID attack. 423 If the overlay network or peer protocol has more specific 424 requirements for the Peer ID value that prevent using HITs derived 425 from public keys, each host will need a certificate (e.g., in their 426 HIP base exchanges) provided by the enrollment server to prove that 427 they are authorized to use a particular identifier in the overlay. 428 Depending on how the certificates are constructed, they typically 429 also need to contain the host's self-generated public key. Depending 430 on how the Peer IDs and public keys are attributed, different 431 scenarios become possible. For example, the Peer IDs may be 432 attributed to users, there may be user public key identifiers, and 433 there may be separate host public key identifiers. Authorization 434 certificates can be used to bind the different types of identifiers 435 together. 437 HITs, as defined in [RFC5201], always start with the ORCHID prefix, 438 so there are 100 bits left in the HIT for different Peer ID values. 439 If an overlay network requires larger address space, it is also 440 possible to use all the 128 bits of a HIT for addressing peer layer 441 identifiers. The benefit of using ORCHID prefix for Peer IDs is that 442 it makes possible to use them with legacy socket APIs, but in this 443 context most of the applications are assumed to be HIP aware and able 444 to use a more advanced API supporting full 128-bit identifiers. Even 445 larger address spaces could be supported with additional HIP 446 parameter giving the source and destination Peer IDs, but defining 447 such a parameter, if needed, is left for future documents. 449 Bootstrap issues such as how to locate an enrollment or a bootstrap 450 server belong to the peer protocol. 452 4.2. Connection Establishment 454 Nodes in an overlay need to establish connection with other nodes in 455 different cases. For example, a node typically has connections to 456 the nodes in its forwarding table. Nodes also need to establish 457 connections with other nodes in order to exchange application-layer 458 messages. 460 As discussed earlier, HIP uses the base exchange to establish 461 connections. A HIP endpoint (the initiator) initiates a HIP base 462 exchange with a remote endpoint by sending an I1 packet. The 463 initiator sends the I1 packet to the remote endpoint's locator. 464 Initiators that do not have any locator for the remote endpoint need 465 to use a rendezvous service. Traditionally, a HIP rendezvous server 467 [RFC5204] has provided such a rendezvous service. In HIP BONE, the 468 overlay itself provides the rendezvous service. 470 Therefore, in HIP BONE, a node uses an I1 packet (as usual) to 471 establish a connection with another node in the overlay. Nodes in 472 the overlay forward I1 packets in a hop-by-hop fashion according to 473 the overlay's routing table towards its destination. This way, the 474 overlay provides a rendezvous service between the nodes establishing 475 the connection. If the overlay nodes have active connections with 476 other nodes in their forwarding tables and if those connections are 477 protected (typically with IPsec ESP), I1 packets may be sent over 478 protected connections between nodes. Alternatively, if there is no 479 such an active connection but the node forwarding the I1 packet has a 480 valid locator for the next hop, the I1 packets may be forwarded 481 directly, in a similar fashion to how I1 packets are today forwarded 482 by a HIP rendezvous server. 484 Since HIP supports NAT traversal, a HIP base exchange over the 485 overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer 486 exchange between the nodes that are establishing the connection. In 487 order to perform this exchange, the nodes need to first gather 488 candidate addresses. Which nodes can be used to obtain reflexive 489 address candidates and which ones can be used to obtain relayed 490 candidates is defined by the peer protocol. 492 4.3. Lightweight Message Exchanges 494 In some cases, nodes need to perform a lightweight query to another 495 node (e.g., a request followed by a single response). In this 496 situation, establishing a connection using the mechanisms in 497 Section 4.2 for a simple query would be an overkill. A better 498 solution is to forward a HIP message through the overlay with the 499 query and another one with the response to the query. The payload of 500 such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. 501 Nodes in the overlay forward this HIP packet in a hop-by-hop fashion 502 according to the overlay's routing table towards its destination, 503 typically through the protected connections established between them. 504 Again, the overlay acts as a rendezvous server between the nodes 505 exchanging the messages. 507 4.4. HIP BONE Instantiation 509 As discussed in Section 4, HIP BONE is a generic framework that 510 allows using different peer protocols. A particular HIP BONE 511 instance uses a particular peer protocol. The details on how to 512 implement a HIP BONE using a given peer protocol need to be specified 513 in a, so called, HIP BONE instance specification. A HIP BONE 514 instance specification needs to define, minimally: 516 o the peer protocol to be used. 517 o what kind of Peer IDs are used and how they are derived. 518 o which peer protocol primitives trigger HIP messages. 519 o how the overlay identifier is generated. 521 Additionally, a HIP BONE instance specification may need to specify 522 other details that are specific to the peer protocol used. 524 As an example, the HIP BONE instance specification for RELOAD 525 [I-D.ietf-p2psip-base] is specified in 526 [I-D.ietf-hip-reload-instance]. 528 It is assumed that areas not covered by a particular HIP BONE 529 instance specification are specified by the peer protocol or 530 elsewhere. These areas include: 532 o the algorithm to create the overlay (e.g., a DHT). 533 o overlay maintenance functions. 534 o data storage and retrieval functions. 535 o the process for obtaining a peer ID. 536 o bootstrap function 537 o how to select STUN and TURN servers for the candidate address 538 collection process in NAT traversal scenarios. 540 Note that the border between HIP BONE instance specification and a 541 peer protocol specifications is blurry. Depending on how generic the 542 specification of a given peer protocol is, its associated HIP BONE 543 instance specification may need to specify more or less details. 544 Also, a HIP BONE instance specification may leave certain areas 545 unspecified in order to leave their configuration up to each 546 particular overlay. 548 5. Advantages of Using HIP BONE 550 Using HIP BONE, as opposed to a peer protocol, to perform connection 551 management in an overlay has a set of advantages. HIP BONE can be 552 used by any peer protocol. This keeps each peer protocol from 553 defining primitives needed for connection management (e.g., 554 primitives to establish connections and to tunnel messages through 555 the overlay) and NAT traversal. Having this functionality at a lower 556 layer allows multiple upper-layer protocols to take advantage of it. 558 Additionally, having a solution that integrates mobility and 559 multihoming is useful in many scenarios. Peer protocols do not 560 typically specify mobility and multihoming solutions. Combining a 561 peer protocol including NAT traversal with a separate mobility 562 mechanism and a separate multihoming mechanism can easily lead to 563 unexpected (and unpleasant) interactions. 565 6. Overlay HIP Parameters 567 This section defines generic format and protocol behavior for the 568 Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that 569 can be used in HIP based overlay networks. HIP BONE instance 570 specifications define the exact format and content of the Overlay 571 Identifier parameter, the cases when the Overlay TTL parameter should 572 be used, and any additional behavior for each packet. 574 6.1. Overlay Identifier 576 It is possible for a HIP host to participate simultaneously in 577 multiple different overlay networks. Therefore, a host needs to know 578 to which overlay an incoming HIP message belongs to. Thus, all HIP 579 messages that are sent via an overlay, or as a part of operations 580 specific to a certain overlay, MUST contain an OVERLAY_ID parameter 581 with the identifier of the corresponding overlay network. Instance 582 specifications define how the identifier is generated for different 583 types of overlay networks. The generation mechanism SHOULD be such 584 that it is unlikely to generate the same identifier for two different 585 overlay instances and hence it is RECOMMENDED that the identifier 586 contains at least 32 bits of randomness. 588 The generic format of the OVERLAY_ID parameter is shown in Figure 3. 589 Instance specifications define valid length for the parameter and how 590 the identifier values are generated. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Identifier / 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 / | Padding | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Type [ TBD by IANA; 980 ] 603 Length Length of the Identifier in octets 604 Identifier The identifier value 605 Padding 0-7 bytes of padding if needed 607 Figure 3: Format of the OVERLAY_ID parameter 609 6.2. Overlay TTL 611 HIP packets sent in an overlay network MAY contain an Overlay Time- 612 to-live (OVERLAY_TTL) parameter whose TTL value is decremented on 613 each overlay network hop. When a HIP host receives a HIP packet with 614 an OVERLAY_TTL parameter, and the host is not the final recipient of 615 the packet, it MUST decrement the TTL value in the parameter by one 616 before forwarding the packet. 618 If the TTL value in a received HIP packet is zero, and the receiving 619 host is not the final recipient, the packet MUST be dropped and the 620 host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED 621 (value [TBD by IANA; 70]) to the sender of the original HIP packet. 622 The Notification Data field for the OVERLAY_TTL_EXCEEDED 623 notifications SHOULD contain the HIP header and the TRANSACTION_ID 624 parameter (if one exists) of the packet whose TTL exceeded. 626 Figure 4 shows the format of the OVERLAY_TTL. The TTL value is given 627 as the number of overlay hops this packet has left and it is encoded 628 as unsigned integer. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type | Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | TTL | Reserved | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Type [ TBD by IANA; 64010 ] 639 Length 4 640 TTL The Time-to-live value 641 Reserved Reserved for future use 643 Figure 4: Format of the OVERLAY_TTL parameter 645 7. Architectural Considerations 647 Architecturally, HIP can be considered to create a new thin "waist" 648 layer on the top of the IPv4 and IPv6 networks; see Figure 5. The 649 HIP layer itself consists of the HIP signaling protocol and one or 650 more data transport protocols; see Figure 6. The HIP signaling 651 packets and the data transport packets can take different routes. In 652 the HIP BONE, the HIP signaling packets are typically first routed 653 through the overlay and then directly (if possible), while the data 654 transport packets are typically routed only directly between the end 655 points. 657 +--------------------------------------+ 658 | Transport (using HITs or LSIs) | 659 +--------------------------------------+ 660 | HIP | 661 +------------------+-------------------+ 662 | IPv4 | IPv6 | 663 +------------------+-------------------+ 665 Figure 5: HIP as a thin waist 667 +------------------+-------------------+ 668 | HIP signaling | data transports | 669 +------------------+-------------------+ 671 Figure 6: HIP layer structure 673 In HIP BONE, the peer protocol creates a new signaling layer on the 674 top of HIP. It is used to set up forwarding paths for HIP signaling 675 messages. This is a similar relationship that an IP routing 676 protocol, such as OSPF, has to the IP protocol itself. In the HIP 677 BONE case, the peer protocol plays a role similar to OSPF, and HIP 678 plays a role similar to IP. The ORCHIDs (or, in general, Peer IDs if 679 the ORCHID prefix is not used) are used for forwarding HIP packets 680 according to the information in the routing tables. The peer 681 protocols are used to exchange routing information based on Peer IDs 682 and to construct the routing tables. 684 Architecturally, routing tables are located between the peer protocol 685 and HIP, as shown in Figure 7. The peer protocol constructs the 686 routing table and keeps it updated. The HIP layer accesses the 687 routing table in order to make routing decisions. The bootstrap of a 688 HIP BONE overlay does not create circular dependencies between the 689 peer protocol (which needs to use HIP to establish connections with 690 other nodes) and HIP (which needs the peer protocol to know how to 691 route messages to other nodes) for the same reasons as the bootstrap 692 of an IP network does not create circular dependencies between OSPF 693 and IP. The first connections established by the peer protocol are 694 with nodes whose locators are known. HIP establishes those 695 connections as any connection between two HIP nodes where no overlays 696 are present. That is, there is no need for the overlay to provide a 697 rendezvous service for those connections. 699 +--------------------------------------+ 700 | Peer protocol | 701 +--------------------------------------+ 702 | Routing table | 703 +--------------------------------------+ 704 | HIP | 705 +--------------------------------------+ 707 Figure 7: Routing tables 709 It is possible that different overlays use different routing table 710 formats. For example, the structure of the routing tables of two 711 overlays based on different DHTs (Distributed Hash Tables) may be 712 very different. In order to make routing decisions, the HIP layer 713 needs to convert the routing table generated by the peer protocol 714 into a forwarding table that allows the HIP layer select a next-hop 715 for any packet being routed. 717 In HIP BONE, the HIP usage of public keys and deriving ORCHIDs 718 through a hash function can be utilized at the peer protocol side to 719 better secure routing table maintenance and to protect against 720 chosen-peer-ID attacks. 722 The HIP BONE provides quite a lot of flexibility with regards to how 723 to arrange the different protocols in detail. Figure 8 shows one 724 potential stack structure. 726 +-----------------------+--------------+ 727 | peer protocols | media | 728 +------------------+----+--------------+ 729 | HIP signaling | data transport | 730 | | 731 +------------------+-------------------+ 732 | NAT | non-NAT | | 733 | | | 734 | IPv4 | IPv6 | 735 +------------------+-------------------+ 737 Figure 8: Example HIP BONE stack structure 739 8. Security Considerations 741 This document provides a high-level framework to build HIP-based 742 overlays. The security properties of HIP and its extensions used in 743 this framework are discussed in their respective specifications. 744 Those security properties can be affected by the way HIP is used in a 745 particular overlay (e.g., by how ORCHIDs are derived from Peer IDs). 746 However, those properties are mostly affected by the design decisions 747 made to build a particular overlay; not so much by the high-level 748 framework specified in this document. Such design decisions are 749 typically documented in a HIP BONE instance specification, which 750 describes the security properties of the resulting overlay. 752 9. Acknowledgements 754 HIP BONE is based on ideas coming from conversations and discussions 755 with a number of people in the HIP and P2PSIP communities. In 756 particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas 757 Henderson, Bruce Lowekamp, and Miika Komu provided useful input on 758 HIP BONE. 760 10. IANA Considerations 762 This section is to be interpreted according to [RFC5226]. 764 This document updates the IANA Registry for HIP Parameter Types 765 [RFC5201] by assigning HIP Parameter Type values for the new HIP 766 Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL 767 (defined in Section 6.2). This document also defines new HIP Notify 768 packet type [RFC5201] OVERLAY_TTL_EXCEEDED (Section 6.2). 770 11. References 772 11.1. Normative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 778 for Overlay Routable Cryptographic Hash Identifiers 779 (ORCHID)", RFC 4843, April 2007. 781 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 782 "Host Identity Protocol", RFC 5201, April 2008. 784 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 785 Encapsulating Security Payload (ESP) Transport Format with 786 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 788 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 789 Rendezvous Extension", RFC 5204, April 2008. 791 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 792 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 793 April 2008. 795 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 796 Host Mobility and Multihoming with the Host Identity 797 Protocol", RFC 5206, April 2008. 799 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 800 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 801 May 2008. 803 [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host 804 Identity Protocol with Legacy Applications", RFC 5338, 805 September 2008. 807 [I-D.ietf-hip-native-api] 808 Komu, M. and T. Henderson, "Basic Socket Interface 809 Extensions for Host Identity Protocol (HIP)", 810 draft-ietf-hip-native-api-12 (work in progress), 811 January 2010. 813 [I-D.ietf-hip-nat-traversal] 814 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 815 Keranen, "Basic HIP Extensions for Traversal of Network 816 Address Translators", draft-ietf-hip-nat-traversal-09 817 (work in progress), October 2009. 819 [I-D.ietf-hip-hiccups] 820 Nikander, P., Camarillo, G., and J. Melen, "HIP (Host 821 Identity Protocol) Immediate Carriage and Conveyance of 822 Upper-layer Protocol Signaling (HICCUPS)", 823 draft-ietf-hip-hiccups-01 (work in progress), 824 January 2009. 826 11.2. Informative References 828 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 829 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 830 October 2008. 832 [I-D.ietf-mmusic-ice] 833 Rosenberg, J., "Interactive Connectivity Establishment 834 (ICE): A Protocol for Network Address Translator (NAT) 835 Traversal for Offer/Answer Protocols", 836 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 838 [I-D.ietf-p2psip-base] 839 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 840 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 841 Base Protocol", draft-ietf-p2psip-base-06 (work in 842 progress), November 2009. 844 [I-D.ietf-hip-reload-instance] 845 Keranen, A., Camarillo, G., and J. Maenpaa, "HIP BONE 846 Instance Specification for RELOAD", 847 draft-ietf-hip-reload-instance-00 (work in progress), 848 Jan 2010. 850 Authors' Addresses 852 Gonzalo Camarillo 853 Ericsson 854 Hirsalantie 11 855 Jorvas 02420 856 Finland 858 Email: Gonzalo.Camarillo@ericsson.com 860 Pekka Nikander 861 Ericsson 862 Hirsalantie 11 863 Jorvas 02420 864 Finland 866 Email: Pekka.Nikander@ericsson.com 868 Jani Hautakorpi 869 Ericsson 870 Hirsalantie 11 871 Jorvas 02420 872 Finland 874 Email: Jani.Hautakorpi@ericsson.com 875 Ari Keranen 876 Ericsson 877 Hirsalantie 11 878 02420 Jorvas 879 Finland 881 Email: Ari.Keranen@ericsson.com 883 Alan Johnston 884 Avaya 885 St. Louis, MO 63124 887 Email: alan@sipstation.com