--- 1/draft-ietf-hip-bone-00.txt 2009-03-09 21:12:06.000000000 +0100 +++ 2/draft-ietf-hip-bone-01.txt 2009-03-09 21:12:06.000000000 +0100 @@ -1,47 +1,56 @@ HIP Working Group G. Camarillo Internet-Draft P. Nikander -Expires: April 30, 2009 J. Hautakorpi +Expires: September 10, 2009 J. Hautakorpi Ericsson A. Johnston Avaya - October 27, 2008 + March 9, 2009 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment - draft-ietf-hip-bone-00.txt + draft-ietf-hip-bone-01.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + 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. Internet-Drafts are draft documents valid for a maximum of six months 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 April 30, 2009. + This Internet-Draft will expire on September 10, 2009. + +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 + and restrictions with respect to this document. 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. @@ -59,39 +68,41 @@ 2.3.2. Identifier Assignment and Authentication . . . . . . . 6 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 2.4. HIP Deployability and Legacy Applications . . . . . . . . 8 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. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12 + 5.1. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 12 + 5.2. Peer ID to ORCHID Transformation . . . . . . . . . . . . . 13 + 5.3. Mapping between Protocol Primitives and HIP Messages . . . 13 6. Architectural Considerations . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 1. Introduction - The Host Identity Protocol (HIP) [I-D.ietf-hip-base] 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. + 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. The remainder of this document is organized as follows. Section 2 provides background information on HIP. Section 3 describes the HIP BONE (HIP-Based Overlay Networking Environment) framework. Section 4 discusses some of the advantages derived from using the HIP BONE framework. Section 5 contains the RELOAD-based HIP BONE instance specification. Finally, before the customary sections, Section 6 attempts to put the presented proposal into a larger architectural context. @@ -179,48 +190,48 @@ | -------------------------->| | R2 | | <--------------------------| Figure 2: HIP base exchange Of course, the initiator needs the responder's locator (or locators) in order to send its I1 packet. The initiator can obtain locators for the responder in multiple ways. For example, according to the current HIP specifications the initiator can get the locators - directly from the DNS [I-D.ietf-hip-dns] or indirectly by sending - packets through a HIP rendezvous server [I-D.ietf-hip-rvs]. However, - as an architecture HIP is open ended, and allows the locators to be + directly from the DNS [RFC5205] or indirectly by sending packets + through a HIP rendezvous server [RFC5204]. However, as an + architecture HIP is open ended, and allows the locators to be obtained by any means (e.g., from packets traversing an overlay network or as part of the candidate address collection process in a NAT traversal scenario). 2.1.3. Locator Management Once a HIP connection between two hosts has been established with a HIP base exchange, the hosts can start exchanging higher-layer traffic. If any of the hosts changes its set of locators, it runs an - update exchange [I-D.ietf-hip-mm], 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. + 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. 2.2. NAT Traversal HIP's NAT traversal mechanism 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 - [I-D.ietf-behave-rfc3489bis] based connectivity checks in order to - discover which address candidate pairs yield connectivity. + [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). 2.3. Security Security is an essential part of HIP. The following sections describe the security-related functionality provided by HIP. @@ -296,32 +307,32 @@ However, such considerations go well beyond the current HIP architecture and even beyond this proposal. For the purposes of the present document, we merely want to point out that architecturally HIP supports both self-generated opportunistic identifiers and administratively assigned ones. 2.3.3. Connection Security Once two nodes complete a base exchange between them, the traffic they exchange is encrypted and integrity protected. The security - mechanism used to protect the traffic is IPsec ESP - [I-D.ietf-hip-esp]. However, there is ongoing work to specify how to - use different protection mechanisms. + mechanism used to protect the traffic is IPsec ESP [RFC5202]. + However, there is ongoing work to specify how to use different + protection mechanisms. 2.4. HIP Deployability and Legacy Applications As discussed earlier, HIP defines a native socket API [I-D.ietf-hip-native-api] that applications can use to establish and manage connections. New applications can implement this API to get full advantage of HIP. However, in most cases, legacy (i.e., non-HIP - aware) applications [I-D.ietf-hip-applications] can use HIP through - the traditional IPv4 and IPv6 socket APIs. + aware) applications [RFC5338] can use HIP through the traditional + IPv4 and IPv6 socket APIs. The idea is that when a legacy IPv6 application tries and obtains a remote host's IP address (e.g., by querying the DNS) the DNS resolver passes the remote host's ORCHID (which was also stored in the DNS) to the legacy application. At the same time, the DNS resolver stores stores the remote host's IP address internally at the HIP module. Since the ORCHID looks like an IPv6 address, the legacy application treats it 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 @@ -429,22 +440,22 @@ 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 to use a rendezvous service. Traditionally, a HIP rendezvous server - [I-D.ietf-hip-rvs] has provided such a rendezvous service. In HIP - BONE, the overlay itself provides the rendezvous service. + [RFC5204] has provided such a rendezvous service. In HIP BONE, the + overlay itself provides the rendezvous service. Therefore, in HIP BONE, a node uses an I1 packet (as usual) to establish a connection with another node in the overlay. Nodes in the overlay forward I1 packets in a hop-by-hop fashion according to the overlay's routing table towards its destination. This way, the overlay provides a rendezvous service between the nodes establishing 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 no such @@ -505,53 +516,82 @@ 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 + unspecified in order to leave their configuration up to each + particular overlays. 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 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. 5. RELOAD-based HIP BONE Instance Specification - Editor's note: To be done when details about RELOAD are more stable. + This section specifies the RELOAD-based HIP BONE instance + specification. - OPEN ISSUES: +5.1. Peer Protocol - o RELOAD uses 128-bit identifiers. Which identifiers should HIP - use? - o How does a HIP entity know which overlay an incoming I1 belongs - to? - o The RELOAD forwarding header carries Via and Destination lists. - What to use as the destination HIT? Final destination (Via and - Destination list functionality in HIP) or next hop? In any case, - intermediaries will need to process the messages to process those - lists. + The peer protocol to be used is RELOAD, which is specified in + [I-D.ietf-p2psip-base]. + +5.2. Peer ID to ORCHID Transformation + + RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit + ORCHIDs, a peer's RELOAD Node-ID is used as the peer's ORCHID. + +5.3. Mapping between Protocol Primitives and HIP Messages + + The Attach procedure in RELOAD establishes a connection between two + peers. This procedure is performed using the AttachReq and AttachAns + messages. When HIP is used, the Attach procedure is performed by + using a HIP base exchange. That is, peers send HIP I1 messages + instead of RELOAD AttachReq messages. + + The RELOAD AttachLite procedure is used for the same purpose as the + Attach procedure in scenarios with no NATs. When HIP is used, the + AttachLite procedure is also performed by using a HIP base exchange. + That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq + messages. + + OPEN ISSUE: The RELOAD forwarding header carries Via and Destination + lists. We should have the same functionality in HIP so that I1s can + be source routed and R1s can use symmetric routing. The destination + HIT for the I1 packet would be the destination peer. The header + fields defined in RFC 5204 (RVS) and in the NAT traversal draft can + be used to implement that functionality or as templates to specify + new header fields that implement that functionality. + + OPEN ISSUE: RELOAD mandates TLS. That is, it does not support plain + TCP or UDP. If HIP is used like this, there will be double + encryption (avoidable using a null encryption algorithm at one of the + levels) and double authentication. 6. 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 consist of the HIP signalling protocol and one or more data transport protocols; see Figure 4. The HIP signalling packets and the data transport packets can take different routes. In the HIP BONE, the HIP signalling packets are typically first routed through the overlay and then directly (if possible), while the data @@ -655,74 +695,70 @@ 9. IANA Considerations This document does not contain any IANA actions. 10. Normative References [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. - [I-D.ietf-hip-base] - Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, - "Host Identity Protocol", draft-ietf-hip-base-10 (work in - progress), October 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. + + [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) + Rendezvous Extension", RFC 5204, April 2008. + + [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol + (HIP) Domain Name System (DNS) Extensions", RFC 5205, + April 2008. + + [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- + 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. + + [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-05 (work in progress), July 2008. - [I-D.ietf-hip-dns] - Nikander, P. and J. Laganier, "Host Identity Protocol - (HIP) Domain Name System (DNS) Extensions", - draft-ietf-hip-dns-09 (work in progress), April 2007. - - [I-D.ietf-hip-rvs] - Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) - Rendezvous Extension", draft-ietf-hip-rvs-05 (work in - progress), June 2006. - - [I-D.ietf-hip-mm] - Henderson, T., "End-Host Mobility and Multihoming with the - Host Identity Protocol", draft-ietf-hip-mm-05 (work in - progress), March 2007. + [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. [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-behave-rfc3489bis] - Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, - "Session Traversal Utilities for (NAT) (STUN)", - draft-ietf-behave-rfc3489bis-18 (work in progress), - July 2008. - - [I-D.ietf-hip-esp] - Jokela, P., "Using ESP transport format with HIP", - draft-ietf-hip-esp-06 (work in progress), June 2007. - - [I-D.ietf-hip-applications] - Henderson, T., Nikander, P., and M. Komu, "Using the Host - Identity Protocol with Legacy Applications", - draft-ietf-hip-applications-04 (work in progress), - July 2008. - - [I-D.nikander-hip-hiccups] - Nikander, P., Camarillo, G., and J. Melen, "HIP (Host - Identity Protocol) Immediate Carriage and Conveyance of - Upper- layer Protocol Signalling (HICCUPS)", - draft-nikander-hip-hiccups-00 (work in progress), - July 2008. + [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. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com @@ -741,50 +776,10 @@ Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com Alan Johnston Avaya St. Louis, MO 63124 Email: alan@sipstation.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org.