One document matched: draft-ietf-hip-reload-instance-10.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="exp" ipr="trust200902"
docName="draft-ietf-hip-reload-instance-10">
<front>
<title abbrev="HIP BONE Instance Spec for RELOAD">
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD)
</title>
<author fullname="Ari Keranen" initials="A." surname="Keranen">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>02420 Jorvas</city>
<country>Finland</country>
</postal>
<email>Ari.Keranen@ericsson.com</email>
</address>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author initials="J." surname="Maenpaa" fullname="Jouni Maenpaa">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Jouni.Maenpaa@ericsson.com</email>
</address>
</author>
<date year="2013" />
<area>Internet</area>
<workgroup>HIP Working Group</workgroup>
<keyword>HIP, overlay, P2P</keyword>
<abstract>
<t> This document is the Host Identity Protocol-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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> The Host Identify Protocol-Based Overlay Networking
Environment (HIP BONE) specification <xref target="RFC6079"/>
provides a high-level framework for building HIP-based <xref
target="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. As discussed in <xref
target="RFC6079"/>, a HIP BONE instance specification needs to
define, minimally: </t>
<t> <list style="symbols">
<t>the peer protocol to be used. </t>
<t>what kind of Node IDs are used and how they are derived. </t>
<t>which peer protocol primitives trigger HIP messages. </t>
<t>how the overlay identifier is generated. </t>
</list> </t>
<t> 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. </t>
</section>
<section title="Terminology">
<t> 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 <xref
target="RFC2119"/>. In addition, this document uses the terms defined in
<xref target="RFC5201"/>, <xref target="RFC6079"/>, <xref
target="RFC6028"/>, and <xref target="I-D.ietf-p2psip-base"/>.
</t>
</section>
<section title="Peer Protocol">
<t> The peer protocol to be used is REsource LOcation And
Discovery (RELOAD) <xref target="I-D.ietf-p2psip-base"/>. When
used with RELOAD, HIP replaces the RELOAD's Forwarding and Link
Management Layer (described in Section 6.5 of <xref
target="I-D.ietf-p2psip-base"/>). </t>
</section>
<section title="Node ID Generation" anchor="sec-id-generation">
<t> 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, and hence only 16-byte RELOAD Node
and Resource IDs MUST be used in a RELOAD HIP BONE. </t>
<t> HIP uses 128-bit Overlay Routable Cryptographic Hash
Identifiers (ORCHIDs) <xref target="RFC4843"/> as
identifiers. In a RELOAD HIP BONE a peer's ORCHID can be used as
such 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. </t>
<t> In the other Node ID mode, namely "RELOAD", all 128 bits are
generated as defined in <xref target="I-D.ietf-p2psip-base"/>.
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
<xref target="RFC6079"/>.</t>
</section>
<section title="Mapping between Protocol Primitives and HIP Messages">
<t> 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. </t>
<t> The standard RELOAD messages consist of three parts:
Forwarding Header, 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 <xref
target="RFC6078"/> messages, but the functionality of the
Forwarding Header and Security Block are replaced with HIP
header, HIP Destination and Via lists <xref target="RFC6028"/>,
and CERT <xref target="RFC6253"/>, TRANSACTION_ID <xref
target="RFC6078"/>, OVERLAY_ID and OVERLAY_TTL <xref
target="RFC6079"/> parameters, as defined in the following
sections. </t>
<section title="Forwarding Header">
<t> 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 TTL value
in the OVERLAY_TTL parameter is used like the ttl field in the
Forwarding Header. </t>
<t> 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 and options field,
if needed eventually for some extensions, can be replaced with
additional HIP parameters. </t>
</section>
<section title="Security Block">
<t> 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 <xref target="RFC6253"/> or stored to the overlay
using the RELOAD Certificate Storage Usage. </t>
<t> 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 host's Node ID instead of HIT in the "Subject Alternative
Name" of the certificate as described in Section 11.3 of <xref
target="I-D.ietf-p2psip-base"/> while the "Subject" field contains the
HIT calculated from the Host Identity. </t>
</section>
<section title="Replaced RELOAD Messages">
<t> 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. This behavior replaces the one described in
Section 6.5 of <xref target="I-D.ietf-p2psip-base"/>. </t>
<t> The AppAttach procedure in RELOAD is used for creating a connection
for other applications than RELOAD. Also the AppAttach procedure is
replaced with 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. </t>
<t> This specification does not support flooding of configuration
files, so ConfigUpdate requests and responses (Section 6.5.4 of <xref
target="I-D.ietf-p2psip-base"/>) MUST NOT be sent in the
overlay. RELOAD Ping messages (Section 6.5.3 of <xref
target="I-D.ietf-p2psip-base"/>) MAY be used.</t>
<t> For all other RELOAD messages the Message Contents are used as such
within HIP DATA messages. </t>
</section>
</section>
<section title="Securing Communication">
<t> RELOAD uses TLS <xref target="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.</t>
<t> With a RELOAD HIP BONE, instead of using TLS connections as
defined in <xref target="I-D.ietf-p2psip-base"/>, all HIP
overlay messages MUST be sent using encrypted connections <xref
target="RFC6261"/>. </t>
<t> The data objects stored in the RELOAD HIP BONE overlay are
signed and the signatures are stored as defined in <xref
target="I-D.ietf-p2psip-base"/> with the exception that
SignerIdentity is carried in the HIP DATA message's HOST_ID
parameter instead of using the RELOAD SecurityBlock. Where
certificates are needed, they are sent using the HIP CERT
parameter. </t>
</section>
<section title="Routing HIP Messages via the Overlay" anchor="routing-hip">
<t> 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. </t>
<t> When sending a HIP packet via the overlay, the host MUST add an empty
ROUTE_VIA parameter <xref target="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. </t>
<t> 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 <xref target="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 <xref target="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. </t>
<t> When the final destination host receives the HIP packet, the host
processes it as specified in <xref target="RFC5201"/> and in case of HIP
DATA packet, the contents are processed as specified in <xref
target="I-D.ietf-p2psip-base"/>. If the HIP packet generates a response,
the response is routed back on the same path using the ROUTE_DST
parameter as specified in <xref target="RFC6028"/>. </t>
</section>
<section title="Enrollment and Bootstrapping">
<t>The RELOAD HIP BONE instance uses the enrollment and bootstrap
procedure defined by RELOAD <xref target="I-D.ietf-p2psip-base"/> with
the exceptions listed below.</t>
<t><list style="symbols">
<t>In RELOAD, a node wishing to enroll in an overlay starts
with obtaining a configuration document as explained in <xref
target="I-D.ietf-p2psip-base"/>. This specification extends
the RELOAD overlay configuration document as defined in <xref
target="sec-config"/>. </t>
<t>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 <xref target="RFC6253"/>.</t>
<t> When contacting a bootstrap node, instead of forming a 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. </t>
</list></t>
<t> </t>
</section>
<section title="NAT Traversal">
<t> 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
<xref target="RFC5770"/>. </t>
<t> 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. </t>
</section>
<section title="RELOAD Overlay Configuration Document Extension"
anchor="sec-config">
<t> This document modifies the bootstrap-node element of the RELOAD
overlay configuration document. The modified bootstrap-node element
contains the following attributes: </t>
<t><list style="hanging">
<t hangText="address:">The locator of the bootstrap node.</t>
<t hangText="port:">The HIP port of the bootstrap node.</t>
<t hangText="hit:">The HIT of the bootstrap node.</t>
</list></t>
<t> If the bootstrap-node element does not contain a HIT, the
opportunistic mode (as specified in <xref target="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 <xref
target="RFC5201"/>. Otherwise, the base exchange MUST be
started UDP-encapsulated as defined in <xref target="RFC5770"/>
using the given port as the destination port number. </t>
<t> A RELOAD HIP BONE overlay MUST use 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 "HIP" link type is found. </t>
<t> This document also adds a new element inside the
configuration element that defines which mode (see <xref
target="sec-id-generation"/>) 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 <xref target="sec-id-generation"/>. </t>
</section>
<section title="Security Considerations" anchor="sec-security">
<t> The security considerations of RELOAD (Section 13 of <xref
target="I-D.ietf-p2psip-base"/>), with the exception of TLS specific
features, apply also to RELOAD HIP BONE instances. </t>
<t> 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. </t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t> This section is to be interpreted according to <xref
target="RFC5226"/>. </t>
<t> IANA is requested to update the "Overlay Link Protocol"
registry <xref target="I-D.ietf-p2psip-base"/> by assigning new
Overlay Link Protocol type "HIP" (see <xref
target="sec-config"/>). </t>
</section>
<section title="Acknowledgements" anchor="sec-acks">
<t> Tom Henderson, Spencer Dawkins, and Christer Holmberg have provided valuable
reviews and comments on the draft. </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4843" ?>
<?rfc include="reference.RFC.5201" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.5770" ?>
<?rfc include="reference.RFC.6028" ?>
<?rfc include="reference.RFC.6078" ?>
<?rfc include="reference.RFC.6079" ?>
<?rfc include="reference.RFC.6253" ?>
<?rfc include="reference.RFC.6261" ?>
<?rfc include="reference.I-D.ietf-p2psip-base" ?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.5246" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:33:48 |