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