draft-ietf-hip-reload-instance-06.txt   draft-ietf-hip-reload-instance-07.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: May 9, 2013 Ericsson Expires: November 07, 2013 Ericsson
November 5, 2012 May 06, 2013
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-06 draft-ietf-hip-reload-instance-07
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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 9, 2013. This Internet-Draft will expire on November 07, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . . 3 4. Node ID Generation . . . . . . . . . . . . . . . . . . . . . 3
5. Mapping between Protocol Primitives and HIP Messages . . . . . 4 5. Mapping between Protocol Primitives and HIP Messages . . . . 3
5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4 5.1. Forwarding Header . . . . . . . . . . . . . . . . . . . . 4
5.2. Security Block . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Security Block . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 6
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 7
10. RELOAD Overlay Configuration Document Extension . . . . . . . 7 10. RELOAD Overlay Configuration Document Extension . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
14.1. Normative References . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . 8
14.2. Informational References . . . . . . . . . . . . . . . . . 10 14.2. Informational References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The HIP BONE (Host Identify Protocol-Based Overlay Networking The HIP BONE (Host Identify Protocol-Based Overlay Networking
Environment) specification [RFC6079] provides a high-level framework Environment) specification [RFC6079] provides a high-level framework
for building HIP-based [RFC5201] overlays. The HIP BONE framework for building HIP-based [RFC5201] overlays. The HIP BONE framework
leaves the specification of the details on how to combine a leaves the specification of the details on how to combine a
particular peer protocol with HIP to build an overlay up to documents particular peer protocol with HIP to build an overlay up to documents
referred to as HIP BONE instance specifications. As discussed in referred to as HIP BONE instance specifications. As discussed in
[RFC6079], a HIP BONE instance specification needs to define, [RFC6079], a HIP BONE instance specification needs to define,
skipping to change at page 3, line 39 skipping to change at page 3, line 27
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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],
[RFC6079], [RFC6028], and [I-D.ietf-p2psip-base]. [RFC6079], [RFC6028], 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
6.5. of [I-D.ietf-p2psip-base]). Section 6.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 and Resource
mode is used in an actual overlay is defined by the overlay IDs. Which mode is used in an actual overlay is defined by the
configuration. 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.
RELOAD uses 128-bit Node IDs. Since HIP uses 128-bit ORCHIDs HIP uses 128-bit ORCHIDs [RFC4843] as identifiers. In a RELOAD HIP
[RFC4843], a peer's ORCHID can be used as such as a RELOAD Node ID BONE a peer's ORCHID can be used as such as a RELOAD Node ID (the
(the "ORCHID" mode). In this mode, also all the RELOAD Resource IDs "ORCHID" mode). In this mode all the RELOAD IDs, including Resource
are prefixed with the ORCHID prefix and the lower 100 bits of the IDs, are prefixed with the ORCHID prefix and the lower 100 bits of
IDs, as defined by RELOAD usage documents, are used after the prefix. the IDs 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. The downside of not using the ORCHID prefix is
that such Node IDs can not be used with legacy applications and APIs,
as discussed in Section 5.1 of [RFC6079].
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, whereas 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 6.5. of [I-D.ietf-p2psip-base], including all the NAT in Section 6.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, existing extensions of
defined in this document. HIP, and the extensions 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 [RFC6078] messages, but the Contents are used as such within HIP DATA [RFC6078] messages, but the
functionality of the Forwarding Header and Security Block are functionality of the Forwarding Header and Security Block are
replaced with HIP header, HIP Destination and Via lists [RFC6028], replaced with HIP header, HIP Destination and Via lists [RFC6028],
and CERT [RFC6253], TRANSACTION_ID [RFC6078], OVERLAY_ID and and CERT [RFC6253], TRANSACTION_ID [RFC6078], OVERLAY_ID and
OVERLAY_TTL [RFC6079] parameters. OVERLAY_TTL [RFC6079] parameters, as defined in the following
sections.
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 Destination length of the TRANSACTION_ID's identifier 8 octets. HIP Destination
skipping to change at page 5, line 29 skipping to change at page 5, line 19
[I-D.ietf-p2psip-base] while the "Subject" field contains the HIT [I-D.ietf-p2psip-base] while the "Subject" field contains the HIT
calculated from the Host Identity. calculated from the Host Identity.
5.3. Replaced RELOAD Messages 5.3. Replaced RELOAD Messages
The Attach procedure in RELOAD establishes a connection between two The Attach procedure in RELOAD establishes a connection between two
peers. This procedure is performed using the AttachReq and AttachAns peers. This procedure is performed using the AttachReq and AttachAns
messages. When HIP is used, the Attach procedure is performed by messages. When HIP is used, the Attach procedure is performed by
using a HIP base exchange. That is, peers send HIP I1 messages using a HIP base exchange. That is, peers send HIP I1 messages
instead of RELOAD AttachReq messages. This behavior replaces the one instead of RELOAD AttachReq messages. This behavior replaces the one
described in Section 6.5. of [I-D.ietf-p2psip-base]. described in Section 6.5 of [I-D.ietf-p2psip-base].
The AppAttach procedure in RELOAD is used for creating a connection The AppAttach procedure in RELOAD is used for creating a connection
for other applications than RELOAD. Also the AppAttach procedure is for other applications than RELOAD. Also the AppAttach procedure is
replaced with HIP base exchange and after the base exchange peers can replaced with HIP base exchange and after the base exchange peers can
exchange any application layer data using the normal transport layer exchange any application layer data using the normal transport layer
ports over the NAT traversing IPsec connection. ports over the NAT traversing IPsec connection.
This specification does not support flooding of configuration files, This specification does not support flooding of configuration files,
so ConfigUpdate requests and responses (Section 6.5.4. of so ConfigUpdate requests and responses (Section 6.5.4 of
[I-D.ietf-p2psip-base]) MUST NOT be sent in the overlay. RELOAD Ping [I-D.ietf-p2psip-base]) MUST NOT be sent in the overlay. RELOAD Ping
messages (Section 6.5.3 of [I-D.ietf-p2psip-base]) MAY be used. messages (Section 6.5.3 of [I-D.ietf-p2psip-base]) MAY be used.
For all other RELOAD messages the Message Contents are used as such For all other RELOAD messages the Message Contents are used as such
within HIP DATA messages. within HIP DATA messages.
6. Securing Communication 6. Securing Communication
RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop RELOAD uses TLS [RFC5246] connections for securing the hop-by-hop
messaging and certificates and signatures for providing integrity messaging and certificates and signatures for providing integrity
skipping to change at page 6, line 17 skipping to change at page 6, line 5
sent using encrypted connections (such as IPsec ESP tunnel between sent using encrypted connections (such as IPsec ESP tunnel between
two peers [RFC6261]) or the contents of the messages SHOULD be in an two peers [RFC6261]) or the contents of the messages SHOULD be in an
ENCRYPTED parameter (see Section 5.2.15 of [RFC5201]). Use of ENCRYPTED parameter (see Section 5.2.15 of [RFC5201]). Use of
encrypted connections is RECOMMENDED since that provides encrypted connections is RECOMMENDED since that provides
confidentiality also for the HIP headers. confidentiality also for the HIP headers.
The data objects stored in the RELOAD HIP BONE overlay are signed and The data objects stored in the RELOAD HIP BONE overlay are signed and
the signatures are stored as defined in [I-D.ietf-p2psip-base] with the signatures are stored as defined in [I-D.ietf-p2psip-base] with
the exception that SignerIdentity is carried in the HIP DATA the exception that SignerIdentity is carried in the HIP DATA
message's HOST_ID parameter instead of using the RELOAD message's HOST_ID parameter instead of using the RELOAD
SecurityBlock. If certificates are needed, they are sent using the SecurityBlock. Where certificates are needed, they are sent using
CERT parameter. the HIP CERT parameter.
7. Routing HIP Messages via the Overlay 7. Routing HIP Messages via the Overlay
If a host has no valid locator for the receiver of a new HIP packet, 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 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 participating in, the host can send the HIP packet to the receiver
using the overlay routing. using the overlay routing.
When sending a HIP packet via the overlay, the host MUST add an empty 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 ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and
skipping to change at page 8, line 26 skipping to change at page 8, line 12
in the configuration document's overlay-link-protocol element. The in the configuration document's overlay-link-protocol element. The
enrolling node MUST check the overlay-link-protocol element and enrolling node MUST check the overlay-link-protocol element and
proceed with procedures defined in this document only if "HIP" link proceed with procedures defined in this document only if "HIP" link
type is found. type is found.
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. 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 11. Security Considerations
The security considerations of RELOAD (Section 13 of The security considerations of RELOAD (Section 13 of
[I-D.ietf-p2psip-base]), with the exception of TLS specific features, [I-D.ietf-p2psip-base]), with the exception of TLS specific features,
apply also to RELOAD HIP BONE instances. 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
skipping to change at page 9, line 34 skipping to change at page 9, line 22
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol
(HIP) Multi-Hop Routing Extension", RFC 6028, (HIP) Multi-Hop Routing Extension", RFC 6028, October
October 2010. 2010.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, January 2011. Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., [RFC6079] 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 (BONE)", RFC 6079, Based Overlay Networking Environment (BONE)", RFC 6079,
January 2011. January 2011.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, May 2011. Certificates", RFC 6253, May 2011.
[RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the
Host Identity Protocol", RFC 6261, May 2011. Host Identity Protocol", RFC 6261, May 2011.
[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-22 (work in Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), July 2012. progress), February 2013.
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
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: Ari.Keranen@ericsson.com Email: Ari.Keranen@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
 End of changes. 20 change blocks. 
52 lines changed or deleted 58 lines changed or added

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