summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7086.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7086.txt')
-rw-r--r--doc/rfc/rfc7086.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7086.txt b/doc/rfc/rfc7086.txt
new file mode 100644
index 0000000..5123f01
--- /dev/null
+++ b/doc/rfc/rfc7086.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Keranen
+Request for Comments: 7086 G. Camarillo
+Category: Experimental J. Maenpaa
+ISSN: 2070-1721 Ericsson
+ January 2014
+
+
+ Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
+ Instance Specification for REsource LOcation And Discovery (RELOAD)
+
+Abstract
+
+ This document is the HIP-Based Overlay Networking Environment (HIP
+ BONE) instance specification for the REsource LOcation And Discovery
+ (RELOAD) protocol. The document provides the details needed to build
+ a RELOAD-based overlay that uses HIP.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7086.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen, et al. Experimental [Page 1]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . 3
+ 5. Mapping between Protocol Primitives and HIP Messages . . . . 3
+ 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
+ 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . 4
+ 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . 5
+ 6. Securing Communication . . . . . . . . . . . . . . . . . . . 5
+ 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . 5
+ 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . 6
+ 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10. RELOAD Overlay Configuration Document Extension . . . . . . . 7
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . 8
+ 14.2. Informative References . . . . . . . . . . . . . . . . . 9
+
+1. Introduction
+
+ The HIP-Based Overlay Networking Environment (HIP BONE) specification
+ [RFC6079] provides a high-level framework for building HIP-based
+ [RFC5201] overlays. The HIP BONE framework does not address the
+ specification of the details on how to combine a particular peer
+ protocol with HIP to build an overlay. It leaves this up to
+ documents referred to as HIP BONE instance specifications. As
+ discussed in [RFC6079], a HIP BONE instance specification needs to
+ define, minimally:
+
+
+
+
+Keranen, et al. Experimental [Page 2]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+ 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.
+
+ This document addresses all the previous items and provides
+ additional details needed to build RELOAD-based HIP BONEs, referred
+ to here as RELOAD HIP BONEs. The details on how different RELOAD
+ modules would be integrated to a HIP implementation and what kind of
+ APIs are used between them are left as implementation details or to
+ be defined by other documents.
+
+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 [RFC2119]. In
+ addition, this document uses the terms defined in [RFC5201],
+ [RFC6079], [RFC6028], and [RFC6940].
+
+3. Peer Protocol
+
+ The peer protocol to be used is REsource LOcation And Discovery
+ (RELOAD) [RFC6940]. When used with RELOAD, HIP replaces the RELOAD's
+ Forwarding and Link Management Layer (described in Section 6.5 of
+ [RFC6940]).
+
+4. Node ID Generation
+
+ This document specifies two modes for generating Node and Resource
+ IDs. Which mode is used in an actual overlay is defined by the
+ overlay configuration. Both of the modes are based on 16-byte ID
+ mode of RELOAD; hence, only 16-byte RELOAD Node and Resource IDs MUST
+ be used in a RELOAD HIP BONE.
+
+ HIP uses 128-bit Overlay Routable Cryptographic Hash Identifiers
+ (ORCHIDs) [RFC4843] as identifiers. In a RELOAD HIP BONE, a peer's
+ ORCHID can be used as a RELOAD Node ID (the "ORCHID" mode). In this
+ mode, all the RELOAD IDs, including Resource IDs, are prefixed with
+ the ORCHID prefix, and the lower 100 bits of the IDs defined by
+ RELOAD usage documents are used after the prefix.
+
+
+
+
+
+
+
+Keranen, et al. Experimental [Page 3]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+ In the other Node ID mode, namely "RELOAD", all 128 bits are
+ generated as defined in [RFC6940]. This results in a larger usable
+ address space than using the ORCHID mode, but the resulting Node IDs
+ cannot be used with legacy applications and APIs, as discussed in
+ Section 5.1 of [RFC6079].
+
+5. Mapping between Protocol Primitives and HIP Messages
+
+ RELOAD HIP BONE replaces the RELOAD protocol primitives taking care
+ of connection establishment with the HIP base exchange, whereas the
+ rest of the RELOAD messages are conveyed within HIP messages. The
+ Forwarding and Link Management Layer functionality of RELOAD,
+ including all the NAT traversal functionality, is replaced by HIP,
+ existing extensions of HIP, and the extensions defined in this
+ document.
+
+ The standard RELOAD messages consist of three parts: the forwarding
+ header, the message contents, and the security block. When RELOAD
+ messages are sent in a RELOAD HIP BONE overlay, the RELOAD message
+ contents are used as such within HIP DATA [RFC6078] messages, but the
+ functionality of the forwarding header and security block are
+ replaced with the HIP header, HIP Destination and Via lists
+ [RFC6028], CERT [RFC6253], TRANSACTION_ID [RFC6078], and the
+ OVERLAY_ID and OVERLAY_TTL [RFC6079] parameters, as defined in the
+ following sections.
+
+5.1. Forwarding Header
+
+ The RELOAD forwarding header is used for forwarding messages between
+ peers and to their final destination. The forwarding header's
+ overlay field value MUST be used as such in an OVERLAY_ID parameter
+ and the transaction_id field in a TRANSACTION_ID parameter. That is,
+ all RELOAD HIP BONE messages MUST contain these parameters; and, the
+ length of the OVERLAY_ID parameter's identifier field is 4, and the
+ length of the TRANSACTION_ID parameter is 8 octets. HIP Destination
+ and Via lists are used for the same purpose as the destination_list
+ and via_list in the forwarding header, with the exception that all
+ Resource IDs MUST be of the same length as Node IDs, and compressed
+ IDs MUST NOT be used. The Time to Live (TTL) value in the
+ OVERLAY_TTL parameter is used like the ttl field in the forwarding
+ header.
+
+ The functionality of the fragment and length fields are provided by
+ the HIP headers. The relo_token, version, and max_response_length
+ are not needed with HIP. The forwarding header's options field, if
+ needed eventually for some extensions, can be substituted with
+ additional HIP parameters.
+
+
+
+
+Keranen, et al. Experimental [Page 4]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+5.2. Security Block
+
+ The RELOAD security block contains certificates and digital
+ signatures of the message. All the HIP DATA messages are digitally
+ signed by the originator of the message and contain the HOST_ID
+ parameter with the identifier that can be used for verifying the
+ signature. Certificates are delivered in a HIP CERT parameter as
+ defined in [RFC6253] or stored to the overlay using the RELOAD
+ Certificate Storage Usage.
+
+ Note that when the RELOAD mode for Node ID generation is used, the
+ certificate certifying that a host is allowed to use a certain Node
+ ID MUST contain the host's Node ID instead of the Host Identity Tag
+ (HIT) in the "subjectAltName" field of the certificate as described
+ in Section 11.3 of [RFC6940], while the "Subject" field contains the
+ HIT calculated from the Host Identity.
+
+5.3. Replaced RELOAD 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 first Initiator
+ (I1) messages instead of RELOAD AttachReq messages. This behavior
+ replaces the one described in Section 6.5 of [RFC6940].
+
+ The AppAttach procedure in RELOAD is used for creating a connection
+ for other applications than RELOAD. Also, the AppAttach procedure is
+ replaced with the HIP base exchange, and after the base exchange,
+ peers can exchange any application layer data using the normal
+ transport layer ports over the NAT traversing IPsec connection.
+
+ This specification does not support flooding of configuration files,
+ so ConfigUpdate requests and responses (Section 6.5.4 of [RFC6940])
+ MUST NOT be sent in the overlay. RELOAD Ping messages (Section 6.5.3
+ of [RFC6940]) MAY be used.
+
+ For all other RELOAD messages, the message contents are used as such
+ within HIP DATA messages.
+
+6. Securing Communication
+
+ RELOAD uses Transport Layer Security (TLS) [RFC5246] connections for
+ securing the hop-by-hop messaging and certificates and signatures for
+ providing integrity protection for the overlay messages and for the
+ data stored in the overlay.
+
+
+
+
+
+Keranen, et al. Experimental [Page 5]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+ With a RELOAD HIP BONE, instead of using TLS connections as defined
+ in [RFC6940], all HIP overlay messages MUST be sent using encrypted
+ connections [RFC6261].
+
+ The data objects stored in the RELOAD HIP BONE overlay are signed,
+ and the signatures are stored as defined in [RFC6940] with the
+ exception that SignerIdentity is carried in the HIP DATA message's
+ HOST_ID parameter instead of using the RELOAD security block. Where
+ certificates are needed, they are sent using the HIP CERT parameter.
+
+7. 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 [RFC6028] to the packet with the SYMMETRIC and
+ MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the
+ identifier of the right overlay network. The 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 SHOULD
+ drop packets sent to unknown overlays. If the host is not the final
+ destination of the packet (i.e., the Receiver HIT in the HIP header
+ 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 [RFC6028]. If the packet does not contain a ROUTE_DST
+ parameter, the host finds the next hop from the RELOAD Topology
+ Plugin and forwards the packet there. As specified in [RFC6028], the
+ host adds 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]; and, if the packet is a HIP
+ DATA packet, the contents are processed as specified in [RFC6940].
+ If the HIP packet generates a response, the response is routed back
+ on the same path using the ROUTE_DST parameter as specified in
+ [RFC6028].
+
+
+
+
+
+
+
+
+
+Keranen, et al. Experimental [Page 6]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+8. Enrollment and Bootstrapping
+
+ The RELOAD HIP BONE instance uses the enrollment and bootstrap
+ procedure defined by RELOAD [RFC6940] with the exceptions listed
+ below.
+
+ o In RELOAD, a node wishing to enroll in an overlay starts with
+ obtaining a configuration document as explained in [RFC6940].
+ This specification extends the RELOAD overlay configuration
+ document as defined in Section 10.
+
+ o The X.509 certificates used by the RELOAD HIP BONE instance are
+ similar to those of RELOAD except that they contain HITs instead
+ of RELOAD URIs. The HITs are included in the SubjectAltName field
+ of the certificate as described in [RFC6253].
+
+ o When contacting a bootstrap node, instead of forming a Datagram
+ Transport Layer Security (DTLS) or TLS connection, the host MUST
+ perform a HIP base exchange with the bootstrap node. The base
+ exchange MAY be performed using a HIP rendezvous or relay server.
+
+9. NAT Traversal
+
+ RELOAD relies on the Forwarding and Link Management Layer providing
+ NAT traversal capabilities. Thus, the RELOAD HIP BONE instance
+ implementations MUST implement some reliable NAT traversal mechanism.
+ To maximize interoperability, all implementations SHOULD implement at
+ least [RFC5770].
+
+ HIP relay servers are not necessarily 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. However, if it is possible that a bootstrap peer is behind a
+ NAT, it MUST register with a HIP relay so that there is a reliable
+ way to connect to it.
+
+10. RELOAD Overlay Configuration Document Extension
+
+ This document modifies the bootstrap-node element of the RELOAD
+ overlay configuration document. The modified bootstrap-node element
+ contains the following attributes:
+
+ address: The locator of the bootstrap node.
+
+ port: The HIP port of the bootstrap node.
+
+ hit: The HIT of the bootstrap node.
+
+
+
+
+Keranen, et al. Experimental [Page 7]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+ If the bootstrap-node element does not contain a HIT, the
+ opportunistic mode (as specified in [RFC5201]) SHOULD be used for
+ contacting the bootstrap node. If the element does not contain a
+ port number, the bootstrap node SHOULD be contacted by starting the
+ base exchange as defined in [RFC5201]. Otherwise, the base exchange
+ MUST be started with UDP encapsulation, as defined in [RFC5770],
+ using the given port as the destination port number.
+
+ A RELOAD HIP BONE overlay MUST use the Overlay Link Protocol type
+ "HIP" in the configuration document's overlay-link-protocol element.
+ The enrolling node MUST check the overlay-link-protocol element and
+ proceed with procedures defined in this document only if the "HIP"
+ link type is found.
+
+ This document also adds a new element inside the configuration
+ element that defines which mode (see Section 4) is used for
+ generating the Node and Resource IDs. The name of the element is
+ "hipbone-id-mode" and the content is the identifier of the mode:
+ "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that
+ use the whole 128 bits as defined by the RELOAD specification. The
+ NodeIdLength MUST be set to 16 in the configuration document, and the
+ 16 bytes are used, depending on the generation mode, as defined in
+ Section 4.
+
+11. Security Considerations
+
+ The security considerations of RELOAD (Section 13 of [RFC6940]), with
+ the exception of TLS-specific features, also apply to RELOAD HIP BONE
+ instances.
+
+ Limiting the Node ID and Resource ID space into 128 bits (or 100 bits
+ with ORCHID prefixes) results in a higher probability for ID
+ collisions, both unintentional and intentional, than using larger
+ address spaces.
+
+12. IANA Considerations
+
+ This section is to be interpreted according to [RFC5226].
+
+ IANA has updated the "RELOAD Overlay Link Protocol Registry"
+ [RFC6940] by assigning the new Overlay Link Protocol type "HIP" (see
+ Section 10).
+
+13. Acknowledgements
+
+ Tom Henderson, Spencer Dawkins, and Christer Holmberg have provided
+ valuable reviews and comments on the document.
+
+
+
+
+Keranen, et al. Experimental [Page 8]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+14. References
+
+14.1. 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.
+
+ [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.
+
+ [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol
+ (HIP) Multi-Hop Routing Extension", RFC 6028, October
+ 2010.
+
+ [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
+ Immediate Carriage and Conveyance of Upper-Layer Protocol
+ Signaling (HICCUPS)", RFC 6078, January 2011.
+
+ [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
+ and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
+ Based Overlay Networking Environment (BONE)", RFC 6079,
+ January 2011.
+
+ [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
+ Certificates", RFC 6253, May 2011.
+
+ [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the
+ Host Identity Protocol", RFC 6261, May 2011.
+
+ [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
+ H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
+ Base Protocol", January 2014.
+
+
+
+
+
+
+Keranen, et al. Experimental [Page 9]
+
+RFC 7086 HIP BONE Instance Spec for RELOAD January 2014
+
+
+14.2. Informative References
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+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
+
+
+ Jouni Maenpaa
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Jouni.Maenpaa@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Keranen, et al. Experimental [Page 10]
+