draft-ietf-hip-reload-instance-01.txt   draft-ietf-hip-reload-instance-02.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Experimental J. Maenpaa Intended status: Experimental J. Maenpaa
Expires: September 9, 2010 Ericsson Expires: January 13, 2011 Ericsson
March 8, 2010 July 12, 2010
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD) Instance Specification for REsource LOcation And Discovery (RELOAD)
draft-ietf-hip-reload-instance-01.txt draft-ietf-hip-reload-instance-02.txt
Abstract Abstract
This document is the Host Identity Protocol-Based Overlay Networking This document is the Host Identity Protocol-Based Overlay Networking
Environment (HIP BONE) instance specification for the REsource Environment (HIP BONE) instance specification for the REsource
LOcation And Discovery (RELOAD) protocol. The document provides the LOcation And Discovery (RELOAD) protocol. The document provides the
details needed to build a RELOAD-based overlay that uses HIP. details needed to build a RELOAD-based overlay that uses HIP.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
5. Mapping between Protocol Primitives and HIP Messages . . . . . 4 5. Mapping between Protocol Primitives and HIP Messages . . . . . 4
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5 5.3. Replaced RELOAD Messages . . . . . . . . . . . . . . . . . 5
6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5 6. Securing Communication . . . . . . . . . . . . . . . . . . . . 5
7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6 7. Routing HIP Messages via the Overlay . . . . . . . . . . . . . 6
8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7 8. Enrollment and Bootstrapping . . . . . . . . . . . . . . . . . 7
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 8 10. RELOAD Overlay Configuration Document Extension . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . . 9
14.2. Informational References . . . . . . . . . . . . . . . . . 10 14.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The HIP BONE (Host Identify Protocol-Based Overlay Networking The HIP BONE (Host Identify Protocol-Based Overlay Networking
Environment) specification [I-D.ietf-hip-bone] provides a high-level Environment) specification [I-D.ietf-hip-bone] provides a high-level
framework for building HIP-based [RFC5201] overlays. The HIP BONE framework for building HIP-based [RFC5201] overlays. The HIP BONE
skipping to change at page 3, line 40 skipping to change at page 3, line 40
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, this document uses the terms defined in [RFC5201], In addition, this document uses the terms defined in [RFC5201],
[I-D.ietf-hip-bone], [I-D.ietf-hip-via], and [I-D.ietf-p2psip-base]. [I-D.ietf-hip-bone], [I-D.ietf-hip-via], and [I-D.ietf-p2psip-base].
3. Peer Protocol 3. Peer Protocol
The peer protocol to be used is RELOAD, which is specified in The peer protocol to be used is RELOAD, which is specified in
[I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the [I-D.ietf-p2psip-base]. When used with RELOAD, HIP replaces the
RELOAD's Forwarding and Link Management Layer (described in Section RELOAD's Forwarding and Link Management Layer (described in Section
5.5. of [I-D.ietf-p2psip-base]. 5.5. of [I-D.ietf-p2psip-base]).
4. Node ID Generation 4. Node ID Generation
This document specifies two modes for generating Node IDs. Which This document specifies two modes for generating Node IDs. Which
mode is used in an actual overlay is defined by the overlay mode is used in an actual overlay is defined by the overlay
configuration. configuration.
RELOAD uses 128-bit Node IDs. Since HIP uses 128-bit ORCHIDs RELOAD uses 128-bit Node IDs. Since HIP uses 128-bit ORCHIDs
[RFC4843], a peer's ORCHID can be used as such as a RELOAD Node ID [RFC4843], a peer's ORCHID can be used as such as a RELOAD Node ID
(the "ORCHID" mode). In this mode, also all the RELOAD Resource IDs (the "ORCHID" mode). In this mode, also all the RELOAD Resource IDs
are prefixed with the ORCHID prefix and the lower 100 bits of the are prefixed with the ORCHID prefix and the lower 100 bits of the
IDs, as defined by RELOAD usage documents, are used after the prefix. IDs, as defined by RELOAD usage documents, are used after the prefix.
In the other Node ID mode, namely "RELOAD", all 128 bits are In the other Node ID mode, namely "RELOAD", all 128 bits are
generated as defined in [I-D.ietf-p2psip-base] resulting in a larger generated as defined in [I-D.ietf-p2psip-base] resulting in a larger
usable address space. usable address space.
5. Mapping between Protocol Primitives and HIP Messages 5. Mapping between Protocol Primitives and HIP Messages
RELOAD HIP BONE replaces the RELOAD protocol primitives taking care RELOAD HIP BONE replaces the RELOAD protocol primitives taking care
of connection establishment with the HIP base exchange, where as the of connection establishment with the HIP base exchange, whereas the
rest of the RELOAD messages are conveyed within HIP messages. The rest of the RELOAD messages are conveyed within HIP messages. The
Forwarding and Link Management Layer functionality of RELOAD defined Forwarding and Link Management Layer functionality of RELOAD defined
in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT
traversal functionality, is replaced by HIP and the extensions traversal functionality, is replaced by HIP and the extensions
defined in this document. defined in this document.
The standard RELOAD messages consist of three parts: Forwarding The standard RELOAD messages consist of three parts: Forwarding
Header, Message Contents and the Security Block. When RELOAD Header, Message Contents and the Security Block. When RELOAD
messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message messages are sent in a RELOAD HIP BONE overlay, the RELOAD Message
Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups] Contents are used as such within HIP DATA [I-D.ietf-hip-hiccups]
messages, but the functionality of the Forwarding Header and Security messages, but the functionality of the Forwarding Header and Security
Block are replaced with HIP header, HIP VIA lists [I-D.ietf-hip-via], Block are replaced with HIP header, HIP Destination and Via lists
and CERT [I-D.ietf-hip-cert], TRANSACTION_ID [I-D.ietf-hip-hiccups], [I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID
OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-bone] parameters. [I-D.ietf-hip-hiccups], OVERLAY_ID and OVERLAY_TTL
[I-D.ietf-hip-bone] parameters.
5.1. Forwarding Header 5.1. Forwarding Header
The RELOAD Forwarding Header is used for forwarding messages between The RELOAD Forwarding Header is used for forwarding messages between
peers and to their final destination. The Forwarding Header's peers and to their final destination. The Forwarding Header's
overlay field's value MUST be used as such in an OVERLAY_ID parameter overlay field's value MUST be used as such in an OVERLAY_ID parameter
and the transaction_id field in a TRANSACTION_ID parameter. That is, and the transaction_id field in a TRANSACTION_ID parameter. That is,
all RELOAD HIP BONE messages MUST contain these parameters and the 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 OVERLAY_ID parameter's identifier field is 4 and the
length of the TRANSACTION_ID's identifier 8 octets. HIP VIA lists length of the TRANSACTION_ID's identifier 8 octets. HIP Destination
are used for the same purpose as the destination_list and via_list in and Via lists are used for the same purpose as the destination_list
the Forwarding Header, with the exception that all Resource IDs MUST and via_list in the Forwarding Header, with the exception that all
be of the same length as Node IDs and compressed IDs MUST NOT be Resource IDs MUST be of the same length as Node IDs and compressed
used. The TTL value in the OVERLAY_TTL parameter is used like the IDs MUST NOT be used. The TTL value in the OVERLAY_TTL parameter is
ttl field in the Forwarding Header. used like the ttl field in the Forwarding Header.
The functionality of the fragment and length fields are provided by The functionality of the fragment and length fields are provided by
the HIP headers. The relo_token, version, and max_res_len are not the HIP headers. The relo_token, version, and max_res_len are not
needed with HIP and options field, if needed eventually for some needed with HIP and options field, if needed eventually for some
extensions, can be replaced with additional HIP parameters. extensions, can be replaced with additional HIP parameters.
5.2. Security Block 5.2. Security Block
The RELOAD Security Block contains certificates and digital The RELOAD Security Block contains certificates and digital
signatures of the message. All the HIP DATA messages are digitally signatures of the message. All the HIP DATA messages are digitally
skipping to change at page 6, line 40 skipping to change at page 6, line 40
containing the identifier of the right overlay network. The host containing the identifier of the right overlay network. The host
consults the RELOAD Topology Plugin for the next hop and sends the consults the RELOAD Topology Plugin for the next hop and sends the
HIP packet to that host. HIP packet to that host.
An intermediate host receiving a HIP packet with the OVERLAY_ID An intermediate host receiving a HIP packet with the OVERLAY_ID
parameter checks if it is participating in that overlay, and SHOULD parameter checks if it is participating in that overlay, and SHOULD
drop packets sent to unknown overlays. If the host is not the final drop 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 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 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 ROUTE_DST parameter. Such packets are forwarded to the next hop as
specified in [I-D.ietf-hip-via]. Otherwise, the host finds the next specified in [I-D.ietf-hip-via]. If the packet does not contain a
hop from the RELOAD Topology Plugin and forwards the packet there. ROUTE_DST parameter, the host finds the next hop from the RELOAD
As specified in [I-D.ietf-hip-via], the host adds the HIT it uses on Topology Plugin and forwards the packet there. As specified in
the HIP association with the next hop host to the end of the [I-D.ietf-hip-via], the host adds the HIT it uses on the HIP
ROUTE_VIA parameter, if present. 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 When the final destination host receives the HIP packet, the host
processes it as specified in [RFC5201] and in case of HIP DATA processes it as specified in [RFC5201] and in case of HIP DATA
packet, the contents are processed as specified in packet, the contents are processed as specified in
[I-D.ietf-p2psip-base]. If the HIP packet generates a response, the [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 response is routed back on the same path using the ROUTE_DST
parameter as specified in [I-D.ietf-hip-via]. parameter as specified in [I-D.ietf-hip-via].
8. Enrollment and Bootstrapping 8. Enrollment and Bootstrapping
skipping to change at page 7, line 33 skipping to change at page 7, line 34
document is fetched from the enrollment server. document is fetched from the enrollment server.
o The X.509 certificates used by the RELOAD HIP BONE instance are o The X.509 certificates used by the RELOAD HIP BONE instance are
similar to those of RELOAD except that they contain HITs instead similar to those of RELOAD except that they contain HITs instead
of RELOAD URIs. The HITs are included in the SubjectAltName field of RELOAD URIs. The HITs are included in the SubjectAltName field
of the certificate as described in [I-D.ietf-hip-cert]. of the certificate as described in [I-D.ietf-hip-cert].
o When contacting a bootstrap node, instead of forming a DTLS or TLS o When contacting a bootstrap node, instead of forming a DTLS or TLS
connection, the host MUST perform a HIP base exchange with the connection, the host MUST perform a HIP base exchange with the
bootstrap node. The base exchange MAY be performed using a HIP bootstrap node. The base exchange MAY be performed using a HIP
rendezvous or relay server. rendezvous or relay server.
The RELOAD HIP BONE instance extends the RELOAD overlay configuration This instance specification extends the RELOAD overlay configuration
document by adding new elements inside each "configuration" element document by adding a new element and attribute. These changes are
of the document. These new elements are listed in Section 10. listed in Section 10.
9. NAT Traversal 9. NAT Traversal
RELOAD relies on the Forwarding and Link Management Layer providing RELOAD relies on the Forwarding and Link Management Layer providing
NAT traversal capabilities. Thus, the RELOAD HIP BONE instance NAT traversal capabilities. Thus, the RELOAD HIP BONE instance
implementations MUST implement some reliable NAT traversal mechanism. implementations MUST implement some reliable NAT traversal mechanism.
To maximize interoperability, all implementations SHOULD implement at To maximize interoperability, all implementations SHOULD implement at
least [I-D.ietf-hip-nat-traversal]. least [RFC5770].
HIP relay servers are not necessarily needed with this HIP BONE HIP relay servers are not necessarily needed with this HIP BONE
instance since the overlay network can be used for relaying the Base instance since the overlay network can be used for relaying the Base
Exchange and further HIP signaling can be done directly between the Exchange and further HIP signaling can be done directly between the
peers. However, if it is possible that a bootstrap peer is behind a 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 NAT, it MUST register with a HIP relay so that there is a reliable
way to connect to it. way to connect to it.
10. RELOAD Overlay Configuration Document Extension 10. RELOAD Overlay Configuration Document Extension
This document modifies the bootstrap-node element of the RELOAD This document modifies the bootstrap-node element of the RELOAD
overlay configuration document. The modified bootstrap-node element overlay configuration document. The modified bootstrap-node element
contains the following elements: contains the following attributes:
address: The locator of the bootstrap node. address: The locator of the bootstrap node.
port: The port of the bootstrap node. port: The HIP port of the bootstrap node.
hit: The HIT of the bootstrap node. hit: The HIT of the bootstrap node.
If the bootstrap-node element does not contain a HIT, opportunistic If the bootstrap-node element does not contain a HIT, opportunistic
mode SHOULD be used for contacting the bootstrap node. mode 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 UDP-encapsulated as
defined in [RFC5770] using the given port as the destination port
number.
This document also adds a new element inside the configuration This document also adds a new element inside the configuration
element that defines which mode (see Section 4) is used for element that defines which mode (see Section 4) is used for
generating the Node and Resource IDs. The name of the element is generating the Node and Resource IDs. The name of the element is
"hipbone-id-mode" and the content is the identifier of the mode: "hipbone-id-mode" and the content is the identifier of the mode:
"ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that "ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that
use the whole 128 bits as defined by the RELOAD specification. use the whole 128 bits as defined by the RELOAD specification.
11. Security Considerations 11. Security Considerations
The security considerations of RELOAD (Section 12 of
[I-D.ietf-p2psip-base]), with the exception of TLS specific features,
apply also to RELOAD HIP BONE instances.
The option to send overlay messages unencrypted makes it possible for The option to send overlay messages unencrypted makes it possible for
hosts that are not part of the overlay to inspect the contents of the hosts that are not part of the overlay to inspect the contents of the
messages and thus should be avoided when possible. If the ENCRYPTED messages and thus should be avoided when possible. If the ENCRYPTED
parameter is used instead of encrypted connections, the HIP header parameter is used instead of encrypted connections, the HIP header
remains visible but the contents are protected. remains visible but the contents are protected.
Limiting the Node ID and Resource ID space into 128 bits (or 100 bits Limiting the Node ID and Resource ID space into 128 bits (or 100 bits
with ORCHID prefixes) results in a higher probability for ID with ORCHID prefixes) results in a higher probability for ID
collisions, both unintentional and intentional, than using larger collisions, both unintentional and intentional, than using larger
address spaces. address spaces.
skipping to change at page 9, line 20 skipping to change at page 9, line 31
for Overlay Routable Cryptographic Hash Identifiers for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[I-D.ietf-hip-bone] [I-D.ietf-hip-bone]
Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment", Based Overlay Networking Environment",
draft-ietf-hip-bone-04 (work in progress), January 2010. draft-ietf-hip-bone-07 (work in progress), June 2010.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-07 (work in Base Protocol", draft-ietf-p2psip-base-08 (work in
progress), February 2010. progress), March 2010.
[I-D.ietf-hip-nat-traversal] [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions
Keranen, "Basic HIP Extensions for Traversal of Network for Traversal of Network Address Translators", RFC 5770,
Address Translators", draft-ietf-hip-nat-traversal-09 April 2010.
(work in progress), October 2009.
[I-D.ietf-hip-via] [I-D.ietf-hip-via]
Camarillo, G. and A. Keranen, "Host Identity Protocol Camarillo, G. and A. Keranen, "Host Identity Protocol
(HIP) Multi-hop Routing Extension", draft-ietf-hip-via-00 (HIP) Multi-hop Routing Extension", draft-ietf-hip-via-03
(work in progress), October 2009. (work in progress), June 2010.
[I-D.ietf-hip-hiccups] [I-D.ietf-hip-hiccups]
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
Immediate Carriage and Conveyance of Upper- layer Protocol Immediate Carriage and Conveyance of Upper- layer Protocol
Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in Signaling (HICCUPS)", draft-ietf-hip-hiccups-03 (work in
progress), March 2010. progress), July 2010.
[I-D.ietf-hip-cert] [I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "HIP Certificates", Heer, T. and S. Varjonen, "HIP Certificates",
draft-ietf-hip-cert-02 (work in progress), October 2009. draft-ietf-hip-cert-03 (work in progress), April 2010.
14.2. Informational References 14.2. Informational References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 21 change blocks. 
42 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/