HIP Working Group A. Keranen Internet-Draft G. Camarillo Intended status: Experimental Ericsson Expires: January 7, 2010 July 6, 2009 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) draft-keranen-hip-reload-instance-00.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. 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 January 7, 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 and restrictions with respect to this document. Abstract This document specifies the HIP BONE instance specification for RELOAD. It provides the details needed to build a RELOAD-based Keranen & Camarillo Expires January 7, 2010 [Page 1] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 overlay that uses HIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Peer ID to ORCHID Transformation . . . . . . . . . . . . . . . 3 5. Mapping between Protocol Primitives and HIP Messages . . . . . 3 6. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 4 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 8. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 11. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Keranen & Camarillo Expires January 7, 2010 [Page 2] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 1. Introduction The HIP BONE (Host Identify Protocol-Based Overlay Networking Environment) specification [I-D.ietf-hip-bone] provides a high-level framework for building HIP-based [RFC5201] overlays. The HIP BONE framework leaves the specification of the details on how to combine a particular peer protocol with HIP to build an overlay up to documents referred to as HIP BONE instance specifications. 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 (Overlay Routable Cryptographic Hash Identifiers) [RFC4843] that will be used in HIP o which peer protocol primitives trigger HIP messages This document addresses all the previous items and provides additional details needed to built RELOAD-based HIP BONEs. 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]. 3. Peer Protocol The peer protocol to be used is RELOAD, which is specified in [I-D.ietf-p2psip-base]. When used with RELOAD, HIP takes the role of the RELOAD's Forwarding and Link Management Layer (described in Section 5.5. of [I-D.ietf-p2psip-base]). The RELOAD HIP BONE instance provides to the applications the RELOAD Messaging API. 4. Peer ID to ORCHID Transformation RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit ORCHIDs, peer's ORCHID can be used as such as the RELOAD Node-ID. 5. 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 Keranen & Camarillo Expires January 7, 2010 [Page 3] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 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. All other RELOAD messages are sent as such between the peers using the paths set up by HIP. 6. Routing HIP Messages via the Overlay If a host has no valid locator for the receiver of a new HIP packet, and the receiver is part of a RELOAD HIP BONE overlay the host is participating in, the host can send the HIP packet to the receiver using the overlay routing. When sending a HIP packet via the overlay, the host MUST add an empty ROUTE_VIA parameter [I-D.ietf-camarillo-hip-via] to the packet with the SYMMETRIC flag set and with an OVERLAY_ID parameter (see Section 7) containing the identifier of the right overlay network. Host consults the RELOAD Topology Plugin for the next hop and sends the HIP packet to that host. An intermediate host receiving a HIP packet with the OVERLAY_ID parameter checks if it is participating in that overlay, and drops packets sent to unknown overlays. If the host is not the final destination of the packet (i.e., the HIP header's receiver's HIT does not match to any of its HITs), it checks if the packet contains a ROUTE_DST parameter. Such packets are forwarded to the next hop as specified in [I-D.ietf-camarillo-hip-via]. Otherwise, the host finds the next hop from the RELOAD Topology Plugin and forwards the packet there. The host MUST add the HIT it uses on the HIP association with the next hop host to the end of the ROUTE_VIA parameter, if present. When the final destination host receives the HIP packet, the host processes it as specified in [RFC5201]. If the HIP packet generates a response, the response is routed back on the same path using ROUTE_DST parameter as specified in [I-D.ietf-camarillo-hip-via]. Keranen & Camarillo Expires January 7, 2010 [Page 4] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 7. Packet Formats 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [ TBD by IANA: 980 ] Length 4 Identifier 32 bit identifier for the overlay Figure 1: Format of the OVERLAY_ID parameter Figure 1 shows the format of a new HIP parameter used for identifying the right overlay if a host participates in multiple overlay networks. For RELOAD HIP BONE overlay networks, the identifier is calculated as defined in Section 5.3.2 of [I-D.ietf-p2psip-base]. 8. NAT Traversal RELOAD relies on the Forwarding and Link Management Layer providing NAT traversal capabilities. Thus, the RELOAD HIP BONE instance implementation MUST implement [I-D.ietf-hip-nat-traversal] or some other reliable NAT traversal mechanism. HIP relay servers are not generally needed with this HIP BONE instance since the overlay network can be used for relaying the Base Exchange and further HIP signaling can be done directly between the peers. 9. Security Considerations TBD. 10. IANA Considerations This section is to be interpreted according to [RFC5226]. This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning new HIP Parameter Type value for the new HIP Parameter OVERLAY_ID (defined in Section 7). Keranen & Camarillo Expires January 7, 2010 [Page 5] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [I-D.ietf-hip-bone] Camarillo, G., Nikander, P., Hautakorpi, J., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", draft-ietf-hip-bone-01 (work in progress), March 2009. [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. [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.ietf-camarillo-hip-via] Camarillo, G. and A. Keranen, "Host Identity Protocol (HIP) Multi-hop Routing Extension", draft-ietf-camarillo-hip-via-00 (work in progress), July 2009. Keranen & Camarillo Expires January 7, 2010 [Page 6] Internet-Draft HIP BONE Instance Spec for RELOAD July 2009 Authors' Addresses Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland Email: ari.keranen@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Keranen & Camarillo Expires January 7, 2010 [Page 7]