--- 1/draft-ietf-hip-bone-06.txt 2010-06-22 14:13:12.000000000 +0200 +++ 2/draft-ietf-hip-bone-07.txt 2010-06-22 14:13:12.000000000 +0200 @@ -1,23 +1,23 @@ HIP Working Group G. Camarillo Internet-Draft P. Nikander Intended status: Experimental J. Hautakorpi -Expires: October 11, 2010 A. Keranen +Expires: December 24, 2010 A. Keranen Ericsson A. Johnston Avaya - April 9, 2010 + June 22, 2010 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment - draft-ietf-hip-bone-06.txt + draft-ietf-hip-bone-07.txt Abstract This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. @@ -35,21 +35,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 11, 2010. + This Internet-Draft will expire on December 24, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -58,79 +58,80 @@ the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 5 - 3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 + 3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 6 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 - 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7 - 3.3.2. Identifier Assignment and Authentication . . . . . . . 7 - 3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8 - 3.4. HIP Deployability and Legacy Applications . . . . . . . . 8 - 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9 - 5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12 + 3.3.2. Identifier Assignment and Authentication . . . . . . . 8 + 3.3.3. Connection Security . . . . . . . . . . . . . . . . . 9 + 3.4. HIP Deployability and Legacy Applications . . . . . . . . 9 + 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 10 + 5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 13 5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13 5.2. Overlay Network Identification . . . . . . . . . . . . . . 14 - 5.3. Connection Establishment . . . . . . . . . . . . . . . . . 14 + 5.3. Connection Establishment . . . . . . . . . . . . . . . . . 15 5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 - 5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 - 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16 - 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16 + 5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 16 + 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 17 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The Host Identity Protocol (HIP) [RFC5201] defines a new name space between the network and transport layers. HIP provides upper layers with mobility, multihoming, NAT (Network Address Translation) traversal, and security functionality. HIP implements the so called identifier/locator (ID/locator) split, which implies that IP addresses are only used as locators, not as host identifiers. This split makes HIP a suitable protocol to build overlay networks that implement identifier-based overlay routing over IP networks, which in turn implement locator-based routing. - Using HIP BONE, as opposed to a peer protocol, to perform connection + Using Host Identity Protocol Based Overlay Networking Environment + (HIP BONE), as opposed to a peer protocol, to perform connection management in an overlay has a set of advantages. HIP BONE can be used by any peer protocol. This keeps each peer protocol from defining primitives needed for connection management (e.g., primitives to establish connections and to tunnel messages through the overlay) and NAT traversal. Having this functionality at a lower layer allows multiple upper-layer protocols to take advantage of it. Additionally, having a solution that integrates mobility and multihoming is useful in many scenarios. Peer protocols do not typically specify mobility and multihoming solutions. Combining a peer protocol including NAT traversal with a separate mobility mechanism and a separate multihoming mechanism can easily lead to unexpected (and unpleasant) interactions. The remainder of this document is organized as follows. Section 3 provides background information on HIP. Section 4 gives an overview of the HIP BONE (HIP-Based Overlay Networking Environment) framework and architecture and Section 5 describes the framework in more - detail. Finally, before the customary sections, Section 6 introduces - new HIP parameters for overlay usage. + detail. Finally, Section 6 introduces new HIP parameters for overlay + usage. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms are used in context of HIP BONEs: Overlay network: A network built on top of another network. In case @@ -140,28 +141,35 @@ Peer protocol: A protocol used by nodes in an overlay network for performing, e.g., data storage and retrieval or overlay maintenance. HIP is used for conveying the peer protocol messages between the nodes in the overlay network. HIP BONE instance: A HIP-based overlay network that uses a particular peer protocol and is based on the framework presented in this document. Node ID: A value that uniquely identifies a node in an overlay - network. The value is not usually human-friendly, but for example - a hash of a public key. + network. The value is not usually human-friendly. As an example, + it may be a hash of a public key. + + HIP association: An IP-layer communications context created using + the Host Identity Protocol. Valid locator: A Locator (as defined in [RFC5206]; usually an IP address or an address and a port number) that a host is known to be reachable at, for example, because there is an active HIP association with the host. + Final recipient: A node is the final recipient of a HIP signaling + packet if one of its Host Identity Tags (HITs) matches to the + Receiver's HIT in the HIP packet header. + 3. Background on HIP This section provides background on HIP. Given the tutorial nature of this section, readers that are familiar with what HIP provides and how HIP works may want to skip it. All descriptions contain references to the relevant HIP specifications where readers can find detailed explanations on the different topics discussed in this section. 3.1. ID/locator Split @@ -259,27 +267,27 @@ traffic. If any of the hosts changes its set of locators, it runs an update exchange [RFC5206], which consists of three messages. If a host is multihomed, it simply provides more than one locator in its exchanges. However, if both of the end points move at the same time, or through some other reason both lose track of the peers' currently active locators, they need to resort to using a rendezvous server or getting new peer locators by some other means. 3.2. NAT Traversal - HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based - on ICE (Interactive Connectivity Establishment) - [I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part - of the HIP base exchange, hosts perform an ICE offer/answer exchange - where they exchange their respective address candidates. Hosts - perform end-to-end STUN [RFC5389] based connectivity checks in order - to discover which address candidate pairs yield connectivity. + HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive + Connectivity Establishment) [RFC5245]. Hosts gather address + candidates and, as part of the HIP base exchange, hosts perform an + ICE offer/answer exchange where they exchange their respective + address candidates. Hosts perform end-to-end STUN [RFC5389] based + connectivity checks in order to discover which address candidate + pairs yield connectivity. Even though, architecturally, HIP lies below the transport layer (i.e., HIP packets are carried directly in IP packets), in presence of NATs, HIP sometimes needs to be tunneled in a transport protocol (i.e., HIP packets are carried by a transport protocol such as UDP). 3.3. Security Security is an essential part of HIP. The following sections describe the security-related functionality provided by HIP. @@ -335,21 +343,22 @@ A HIT is the hash of a node's public key. A node proves that it has the right to use a HIT by showing its ability to sign data with its associated private key. This scheme is secure due to the so called second-preimage resistance property of hash functions. That is, given a fixed public key K1, finding a different public key K2 such that hash(K1) = hash(K2) is computationally very hard. Optimally, a preimage attack on the 100-bit hash function used in ORCHIDs will take an order of 2^100 operations to be successful, and can be expected to take in the average 2^99 operations. Given that each operation requires the attacker to generate a new key pair, the - attack is completely impractical (see [RFC4843]). + attack is fully impractical with current technology and techniques + (see [RFC4843]). HIP nodes using HITs as ORCHIDs do not typically use certificates during their base exchanges. Instead, the use a leap-of-faith mechanism, similar to the Secure Shell (SSH) protocol [RFC4251], whereby a node authenticates somehow remote nodes the first time they connect it and, then, remembers their public keys. While user- assisted leap-of-faith (such as in SSH) can be used to facilitate a human-operated offline path (such as a telephone call), automated leap-of-faith can be combined with a reputation management system to create an incentive to behave. However, such considerations go well @@ -384,21 +393,21 @@ as such. It opens a connection (e.g., TCP) using the traditional IPv6 socket API. The HIP module running in the same host as the legacy application intercepts this call somehow (e.g., using an interception library or setting up the host's routing tables so that the HIP module receives the traffic) and runs HIP (on behalf of the legacy application) towards the IP address corresponding to the ORCHID. This mechanism works well in almost all cases. However, applications involving referrals (i.e., passing of IPv6 addresses between applications) present issues, to be discussed in Section 5 below. Additionally, management applications that care about the - exact IP address format may not work well with such straightforward + exact IP address format may not work well with such a straightforward approach. In order to make HIP work through the traditional IPv4 socket API, the HIP module passes an LSI (Local Scope Identifier), instead of a regular IPv4 address, to the legacy IPv4 application. The LSI looks like an IPv4 address, but is locally bound to an ORCHID. That is, when the legacy application uses the LSI in a socket call, the HIP module intercepts it and replaces the LSI with its corresponding ORCHID. Therefore, LSIs always have local scope. They do not have any meaning outside the host running the application. The ORCHID is @@ -565,29 +573,29 @@ 5.1. Node ID Assignment and Bootstrap Nodes in an overlay are primarily identified by their Node IDs. Overlays typically have an enrollment server that can generate Node IDs, or at least some part of the Node ID, and sign certificates. A certificate generated by an enrollment server authorizes a particular user to use a particular Node ID in a particular overlay. The way users are identified is defined by the peer protocol and HIP BONE instance specification. - The enrollment server of an overlay that were to use HITs derived - from public keys as Node IDs could just authorize users to use the - public keys and HITs associated to their nodes. Such a Node ID has - the same self-certifying property as HITs and the Node ID can also be - used in the HIP and legacy APIs as an ORCHID. This works well as - long as the enrollment server is the one generating the public/ - private key pairs for all those nodes. If the enrollment server - authorizes users to use HITs that are generated directly by the nodes - themselves, the system is open to a type of chosen-peer-ID attack. + The enrollment server of an overlay using HITs derived from public + keys as Node IDs could just authorize users to use the public keys + and HITs associated to their nodes. Such a Node ID has the same + self-certifying property as HITs and the Node ID can also be used in + the HIP and legacy APIs as an ORCHID. This works well as long as the + enrollment server is the one generating the public/private key pairs + for all those nodes. If the enrollment server authorizes users to + use HITs that are generated directly by the nodes themselves, the + system is open to a type of chosen-peer-ID attack. If the overlay network or peer protocol has more specific requirements for the Node ID value that prevent using HITs derived from public keys, each host will need a certificate (e.g., in their HIP base exchanges) provided by the enrollment server to prove that they are authorized to use a particular identifier in the overlay. Depending on how the certificates are constructed, they typically also need to contain the host's self-generated public key. Depending on how the Node IDs and public keys are attributed, different scenarios become possible. For example, the Node IDs may be @@ -628,21 +636,21 @@ HITs to be be bound to certain overlays or by defining the overlay identifier using advanced HIP socket options or other suitable APIs. On the other hand, if no explicit configuration for a HIP association is used, a host may have a configured default overlay where all HIP messages without a valid locator are sent. The specification for how to implement this coordination for locally originated messages is out of scope for this document. 5.3. Connection Establishment - Nodes in an overlay need to establish connection with other nodes in + Nodes in an overlay need to establish connections with other nodes in different cases. For example, a node typically has connections to the nodes in its forwarding table. Nodes also need to establish connections with other nodes in order to exchange application-layer messages. As discussed earlier, HIP uses the base exchange to establish connections. A HIP endpoint (the initiator) initiates a HIP base exchange with a remote endpoint by sending an I1 packet. The initiator sends the I1 packet to the remote endpoint's locator. Initiators that do not have any locator for the remote endpoint need @@ -658,26 +666,26 @@ the connection. If the overlay nodes have active connections with other nodes in their forwarding tables and if those connections are protected (typically with IPsec ESP), I1 packets may be sent over protected connections between nodes. Alternatively, if there is no such an active connection but the node forwarding the I1 packet has a valid locator for the next hop, the I1 packets may be forwarded directly, in a similar fashion to how I1 packets are today forwarded by a HIP rendezvous server. Since HIP supports NAT traversal, a HIP base exchange over the - overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer - exchange between the nodes that are establishing the connection. In - order to perform this exchange, the nodes need to first gather - candidate addresses. Which nodes can be used to obtain reflexive - address candidates and which ones can be used to obtain relayed - candidates is defined by the peer protocol. + overlay will perform an ICE [RFC5245] offer/answer exchange between + the nodes that are establishing the connection. In order to perform + this exchange, the nodes need to first gather candidate addresses. + Which nodes can be used to obtain reflexive address candidates and + which ones can be used to obtain relayed candidates is defined by the + peer protocol. 5.4. Lightweight Message Exchanges In some cases, nodes need to perform a lightweight query to another node (e.g., a request followed by a single response). In this situation, establishing a connection using the mechanisms in Section 5.3 for a simple query would be an overkill. A better solution is to forward a HIP message through the overlay with the query and another one with the response to the query. The payload of such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. @@ -692,33 +701,32 @@ As discussed in Section 5, HIP BONE is a generic framework that allows using different peer protocols. A particular HIP BONE instance uses a particular peer protocol. The details on how to implement a HIP BONE using a given peer protocol need to be specified in a, so called, HIP BONE instance specification. A HIP BONE instance specification needs to define, minimally: o the peer protocol to be used. o what kind of Node IDs are used and how they are derived. o which peer protocol primitives trigger HIP messages. - o how the overlay identifier is generated. Additionally, a HIP BONE instance specification may need to specify other details that are specific to the peer protocol used. As an example, the HIP BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is specified in [I-D.ietf-hip-reload-instance]. - It is assumed that areas not covered by a particular HIP BONE - instance specification are specified by the peer protocol or - elsewhere. These areas include: + The areas not covered by a particular HIP BONE instance specification + are specified by the peer protocol or elsewhere. These areas + include: o the algorithm to create the overlay (e.g., a DHT). o overlay maintenance functions. o data storage and retrieval functions. o the process for obtaining a Node ID. o bootstrap function. o how to select STUN and TURN servers for the candidate address collection process in NAT traversal scenarios. Note that the border between HIP BONE instance specification and a @@ -740,22 +748,22 @@ 6.1. Overlay Identifier To identify to which overlay network a HIP message belongs to, all HIP messages that are sent via an overlay, or as a part of operations specific to a certain overlay, MUST contain an OVERLAY_ID parameter with the identifier of the corresponding overlay network. Instance specifications define how the identifier is generated for different types of overlay networks. The generation mechanism MUST be such that it is unlikely to generate the same identifier for two different - overlay instances and hence it is RECOMMENDED that the identifier - contains at least 32 bits of randomness. + overlay instances and any other means possible for preventing + collisions SHOULD be used. The generic format of the OVERLAY_ID parameter is shown in Figure 8. Instance specifications define valid length for the parameter and how the identifier values are generated. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -784,40 +792,40 @@ host is not the final recipient, the packet MUST be dropped and the host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED (value [TBD by IANA; 70]) to the sender of the original HIP packet. The Notification Data field for the OVERLAY_TTL_EXCEEDED notifications SHOULD contain the HIP header and the TRANSACTION_ID [I-D.ietf-hip-hiccups] parameter (if one exists) of the packet whose TTL exceeded. Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL value is given as the number of overlay hops this packet has left and - it is encoded as an unsigned integer. + it is encoded as an unsigned integer using network byte order. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA; 64011 ] Length 4 TTL The Time-to-live value Reserved Reserved for future use Figure 9: Format of the OVERLAY_TTL Parameter The type of the OVERLAY_TTL parameter is critical (as defined in - Section 5.2.1 of [RFC5201]) and therefore the final recipient of the - packet, and all HIP hosts on the path, MUST support it. If the + Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes + forwarding a packet with this parameter MUST support it. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient. 7. Security Considerations This document provides a high-level framework to build HIP-based overlays. The security properties of HIP and its extensions used in this framework are discussed in their respective specifications. Those security properties can be affected by the way HIP is used in a @@ -857,25 +865,24 @@ for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008. - [I-D.ietf-hip-nat-traversal] - Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. - Keranen, "Basic HIP Extensions for Traversal of Network - Address Translators", draft-ietf-hip-nat-traversal-09 - (work in progress), October 2009. + [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. + Keranen, "Basic Host Identity Protocol (HIP) Extensions + for Traversal of Network Address Translators", RFC 5770, + April 2010. [I-D.ietf-hip-hiccups] Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in progress), March 2010. 10.2. Informative References [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) @@ -903,25 +910,24 @@ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [I-D.ietf-hip-native-api] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", draft-ietf-hip-native-api-12 (work in progress), January 2010. - [I-D.ietf-mmusic-ice] - Rosenberg, J., "Interactive Connectivity Establishment + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", - draft-ietf-mmusic-ice-19 (work in progress), October 2007. + Traversal for Offer/Answer Protocols", RFC 5245, + April 2010. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-08 (work in progress), March 2010. [I-D.ietf-hip-reload-instance] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)