--- 1/draft-ietf-hip-bone-02.txt 2009-10-26 15:12:15.000000000 +0100 +++ 2/draft-ietf-hip-bone-03.txt 2009-10-26 15:12:15.000000000 +0100 @@ -1,22 +1,23 @@ HIP Working Group G. Camarillo Internet-Draft P. Nikander Intended status: Experimental J. Hautakorpi -Expires: January 7, 2010 Ericsson +Expires: April 29, 2010 A. Keranen + Ericsson A. Johnston Avaya - July 6, 2009 + October 26, 2009 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment - draft-ietf-hip-bone-02.txt + draft-ietf-hip-bone-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,21 +26,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 January 7, 2010. + This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -65,30 +66,31 @@ 2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Identifier Assignment and Authentication . . . . . . . 6 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 2.4. HIP Deployability and Legacy Applications . . . . . . . . 7 3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8 3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9 3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10 3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11 - 3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11 - 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12 - 5. Architectural Considerations . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.4. Participating in Multiple Overlays . . . . . . . . . . . . 11 + 3.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 12 + 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 13 + 5. Architectural Considerations . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 @@ -243,21 +245,21 @@ in order to generate an I2 packet. The difficulty of the puzzle can be adjusted so that, if a receiver is under a DoS attack, it can increase the difficulty of its puzzles. On receiving an I2 packet, a receiver checks that the solution in the packet corresponds to a puzzle generated by the receiver and that the solution is correct. If it is, the receiver processes the I2 packet. Otherwise, it silently discards it. In an overlay scenario, there are multiple ways how this mechanism - can be utilised within the overlay. One possibility is to cache the + can be utilized within the overlay. One possibility is to cache the pre-generated R1 packets within the overlay and let the overlay directly respond with R1s to I1s. In that way the responder is not bothered at all until the initiator sends an I2 packet, with the puzzle solution. Furthermore, a more sophisticated overlay could verify that an I2 packet has a correctly solved puzzle before forwarding the packet to the responder. 2.3.2. Identifier Assignment and Authentication As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main @@ -332,35 +334,35 @@ 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 3 below. Additionally, management applications that care about the - exact IP address format may not work well with such straigthforward + exact IP address format may not work well with such 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 used on the wire; not the LSI. In the referral case, if it is not possible to rewrite the application level packets to use ORCHIDs instead of LSIs, it may be hard to make IPv4 referrals work in - Internet-wide settings. IPv4 LSIs have been succesfully used in + Internet-wide settings. IPv4 LSIs have been successfully used in existing HIP deployments within a single corporate network. 3. The HIP BONE Framework An overlay typically requires three types of operations: o overlay maintenance. o data storage and retrieval. o connection management. @@ -374,21 +376,21 @@ The HIP BONE framework uses HIP to perform connection management. Data storage and retrieval and overlay maintenance are to be implemented using protocols other than HIP. For lack of a better name, these protocols are referred to as peer protocols. 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 3.4 discusses what details need to be + specification. Section 3.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.keranen-hip-reload-instance]. 3.1. Peer ID Assignment and Bootstrap Nodes in an overlay are primarily identified by their Peer IDs. (Note that the Peer ID concept here is a peer-layer protocol concept, distinct from the HIP-layer node identifiers. Peer IDs may be long, may have some structure, and may consist of multiple parts.) @@ -417,21 +419,21 @@ key. That is a similar process to the one a host follows to generate a HIT from a public key. In such scenarios, 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 ORCHID 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 Peer IDs and public keys are attributed, different scenarios become possible. For example, the Peer IDs may be attributed to users, there may be user public key identifiers, and there may be separate host public key identifiers. - Authorisation certificates can be used to bind the different types of + Authorization certificates can be used to bind the different types of identifiers together. Bootstrap issues such as how to locate an enrollment or a bootstrap server belong to the peer protocol. 3.2. 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 @@ -477,62 +479,98 @@ Section 3.2 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.nikander-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. -3.4. HIP BONE Instantiation +3.4. Participating in Multiple Overlays + + It is possible for a HIP host to participate simultaneously in + multiple different overlay networks and 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 specific to + a certain overlay, MUST contain an OVERLAY_ID parameter (shown in + Figure 3) 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 SHOULD + 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. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type [ TBD by IANA: 980 ] + Length Length of the Identifier in octets + Identifier The overlay identifier + Padding 0-7 bytes of padding if the identifier length is not + multiple of 8 bytes + + Figure 3: Format of the OVERLAY_ID parameter + + OPEN ISSUE: this introduces normative language to the architecture + draft. Should this parameter be defined in some other (possibly + stand alone) draft? + +3.5. HIP BONE Instantiation As discussed in Section 3, 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 how to transform the peer IDs used by the peer protocol into the ORCHIDs that will be used in HIP. 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.keranen-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: o the algorithm to create the overlay (e.g., a DHT). o overlay maintenance functions. o data storage and retrieval functions. o format and structure of peer IDs. o the process for obtaining a peer ID. - o overlay identification. o bootstrap function o how to select STUN and TURN servers for the candidate address collection process in NAT traversal scenarios. o for what type of traffic or messages it is appropriate to use lightweight message exchanges. Note that the border between HIP BONE instance specification and a peer protocol specifications is blurry. Depending on how generic the specification of a given peer protocol is, its associated HIP BONE instance specification may need to specify more or less details. - Also, a particular HIP BONE instance specification left certain areas + Also, a HIP BONE instance specification may leave certain areas unspecified in order to leave their configuration up to each particular overlay. 4. Advantages of Using HIP BONE Using 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 @@ -542,57 +580,57 @@ 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. 5. Architectural Considerations Architecturally, HIP can be considered to create a new thin "waist" - layer on the top of the IPv4 and IPv6 networks; see Figure 3. The - HIP layer itself consists of the HIP signalling protocol and one or - more data transport protocols; see Figure 4. The HIP signalling + layer on the top of the IPv4 and IPv6 networks; see Figure 4. The + HIP layer itself consists of the HIP signaling protocol and one or + more data transport protocols; see Figure 5. The HIP signaling packets and the data transport packets can take different routes. In - the HIP BONE, the HIP signalling packets are typically first routed + the HIP BONE, the HIP signaling packets are typically first routed through the overlay and then directly (if possible), while the data transport packets are typically routed only directly between the end points. +--------------------------------------+ | Transport (using HITs or LSIs) | +--------------------------------------+ | HIP | +------------------+-------------------+ | IPv4 | IPv6 | +------------------+-------------------+ - Figure 3: HIP as a thin waist + Figure 4: HIP as a thin waist +------------------+-------------------+ - | HIP signalling | data transports | + | HIP signaling | data transports | +------------------+-------------------+ - Figure 4: HIP layer structure + Figure 5: HIP layer structure - In HIP BONE, the peer protocol creates a new signalling layer on the - top of HIP. It is used to set up forwarding paths for HIP signalling + In HIP BONE, the peer protocol creates a new signaling layer on the + top of HIP. It is used to set up forwarding paths for HIP signaling messages. This is a similar relationship that an IP routing protocol, such as OSPF, has to the IP protocol itself. In the HIP BONE case, the peer protocol plays a role similar to OSPF, and HIP plays a role similar to IP. The ORCHIDs are used for forwarding HIP packets according to the information in the routing tables. The peer protocols are used to exchange routing information based on Peer IDs and public keys, and to construct the routing tables. Architecturally, routing tables are located between the peer protocol - and HIP, as shown in Figure 5. The peer protocol constructs the + and HIP, as shown in Figure 6. The peer protocol constructs the routing table and keeps it updated. The HIP layer accesses the routing table in order to make routing decisions. The bootstrap of a HIP BONE overlay does not create circular dependencies between the peer protocol (which needs to use HIP to establish connections with other nodes) and HIP (which needs the peer protocol to know how to route messages to other nodes) for the same reasons as the bootstrap of an IP network does not create circular dependencies between OSPF and IP. The first connections established by the peer protocol are with nodes whose locators are known. HIP establishes those connections as any connection between two HIP nodes where no overlays @@ -600,51 +638,51 @@ rendezvous service for those connections. +--------------------------------------+ | Peer protocol | +--------------------------------------+ | Routing table | +--------------------------------------+ | HIP | +--------------------------------------+ - Figure 5: Routing tables + Figure 6: Routing tables It is possible that different overlays use different routing table formats. For example, the structure of the routing tables of two overlays based on different DHTs (Distributed Hash Tables) may be very different. In order to make routing decisions, the HIP layer needs to convert the routing table generated by the peer protocol into a forwarding table that allows the HIP layer select a next-hop for any packet being routed. In HIP BONE, the HIP usage of public keys and deriving ORCHIDs - through a hash function can be utilised at the peer protocol side to + through a hash function can be utilized at the peer protocol side to better secure routing table maintenance and to protect against chosen-peer-ID attacks. The HIP BONE provides quite a lot of flexibility with regards to how - to arrange the different protocols in detail. Figure 6 shows one + to arrange the different protocols in detail. Figure 7 shows one potential stack structure. +-----------------------+--------------+ | peer protocols | media | +------------------+----+--------------+ - | HIP signalling | data transport | + | HIP signaling | data transport | | | +------------------+-------------------+ | NAT | non-NAT | | | | | | IPv4 | IPv6 | +------------------+-------------------+ - Figure 6: Example HIP BONE stack structure + Figure 7: Example HIP BONE stack structure 6. 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 particular overlay (e.g., by how ORCHIDs are derived from Peer IDs). However, those properties are mostly affected by the design decisions made to build a particular overlay; not so much by how this high- @@ -690,52 +728,53 @@ Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 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-06 (work in progress), May 2009. + draft-ietf-hip-native-api-09 (work in progress), + September 2009. [I-D.ietf-hip-nat-traversal] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keraenen, "Basic HIP Extensions for Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-08 (work in progress), June 2009. [I-D.nikander-hip-hiccups] Nikander, P., Camarillo, G., and J. Melen, "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", - draft-nikander-hip-hiccups-01 (work in progress), - November 2008. + draft-nikander-hip-hiccups-04 (work in progress), + August 2009. 9.2. Informative References [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [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-02 (work in - progress), March 2009. + Base Protocol", draft-ietf-p2psip-base-04 (work in + progress), October 2009. [I-D.keranen-hip-reload-instance] Keranen, A. and G. Camarillo, "HIP BONE Instance Specification for RELOAD", draft-keranen-hip-reload-instance-00 (work in progress), July 2009. Authors' Addresses Gonzalo Camarillo @@ -755,15 +794,23 @@ Email: Pekka.Nikander@ericsson.com Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com + Ari Keranen + Ericsson + Hirsalantie 11 + 02420 Jorvas + Finland + + Email: Ari.Keranen@ericsson.com + Alan Johnston Avaya St. Louis, MO 63124 Email: alan@sipstation.com