--- 1/draft-ietf-hip-bone-05.txt 2010-04-09 14:11:03.000000000 +0200 +++ 2/draft-ietf-hip-bone-06.txt 2010-04-09 14:11:03.000000000 +0200 @@ -1,23 +1,23 @@ HIP Working Group G. Camarillo Internet-Draft P. Nikander Intended status: Experimental J. Hautakorpi -Expires: September 9, 2010 A. Keranen +Expires: October 11, 2010 A. Keranen Ericsson A. Johnston Avaya - March 8, 2010 + April 9, 2010 - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking - Environment - draft-ietf-hip-bone-05.txt + HIP BONE: Host Identity Protocol (HIP) + Based Overlay Networking Environment + draft-ietf-hip-bone-06.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 September 9, 2010. + This Internet-Draft will expire on October 11, 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 @@ -69,23 +69,24 @@ 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 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 5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13 - 5.2. Connection Establishment . . . . . . . . . . . . . . . . . 14 - 5.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 - 5.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 + 5.2. Overlay Network Identification . . . . . . . . . . . . . . 14 + 5.3. Connection Establishment . . . . . . . . . . . . . . . . . 14 + 5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 + 5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 @@ -549,34 +550,34 @@ +------------------+-------------------+ Figure 7: Example HIP BONE Stack Structure 5. The HIP BONE Framework HIP BONE is a generic framework that allows the use of 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. Section 5.4 discusses what details need to be + specification. Section 5.5 discusses what details need to be specified by HIP BONE instance specifications. For example, the HIP BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is specified in [I-D.ietf-hip-reload-instance]. 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 and overlays are identified are defined by the peer protocol - and HIP BONE instance specification. + 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. @@ -603,21 +604,43 @@ is that it makes possible to use them with legacy socket APIs, but in this context most of the applications are assumed to be HIP aware and able to use a more advanced API supporting full 128-bit identifiers. Even larger address spaces could be supported with an additional HIP parameter giving the source and destination Node IDs, but defining such a parameter, if needed, is left for future documents. Bootstrap issues such as how to locate an enrollment or a bootstrap server belong to the peer protocol. -5.2. Connection Establishment +5.2. Overlay Network Identification + + It is possible for a HIP host to participate simultaneously in + multiple different overlay networks. It is also possible that some + HIP traffic is not intended to be forwarded over an overlay. + Therefore, a host needs to know to which overlay an incoming HIP + message belongs to and the outgoing HIP messages need to be labeled + belonging to a certain overlay. This document specifies a new + generic HIP parameter (in Section 6.1) for the purpose of directing + HIP messages to the right overlay. + + In addition, an application using HIP BONE needs to define, either + implicitly or explicitly, the overlay to use for communication. + Explicit configuration can happen, e.g., by configuring certain local + 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 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 @@ -642,36 +665,36 @@ 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. -5.3. Lightweight Message Exchanges +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.2 for a simple query would be an overkill. A better + 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]. Nodes in the overlay forward this HIP packet in a hop-by-hop fashion according to the overlay's routing table towards its destination, typically through the protected connections established between them. Again, the overlay acts as a rendezvous server between the nodes exchanging the messages. -5.4. HIP BONE Instantiation +5.5. HIP BONE Instantiation 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. @@ -709,24 +733,22 @@ This section defines generic format and protocol behavior for the Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that can be used in HIP based overlay networks. HIP BONE instance specifications define the exact format and content of the Overlay Identifier parameter, the cases when the Overlay TTL parameter should be used, and any additional behavior for each packet. 6.1. Overlay Identifier - It is possible for a HIP host to participate simultaneously in - multiple different overlay networks. Therefore, a host needs to know - to which overlay an incoming HIP message belongs to. Thus, all HIP - messages that are sent via an overlay, or as a part of operations + 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. The generic format of the OVERLAY_ID parameter is shown in Figure 8. Instance specifications define valid length for the parameter and how @@ -890,29 +912,29 @@ [I-D.ietf-mmusic-ice] 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. [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-07 (work in - progress), February 2010. + 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) Instance Specification for REsource LOcation And Discovery - (RELOAD)", draft-ietf-hip-reload-instance-00 (work in - progress), January 2010. + (RELOAD)", draft-ietf-hip-reload-instance-01 (work in + progress), March 2010. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com