draft-ietf-hip-bone-05.txt   draft-ietf-hip-bone-06.txt 
HIP Working Group G. Camarillo HIP Working Group G. Camarillo
Internet-Draft P. Nikander Internet-Draft P. Nikander
Intended status: Experimental J. Hautakorpi Intended status: Experimental J. Hautakorpi
Expires: September 9, 2010 A. Keranen Expires: October 11, 2010 A. Keranen
Ericsson Ericsson
A. Johnston A. Johnston
Avaya Avaya
March 8, 2010 April 9, 2010
HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking HIP BONE: Host Identity Protocol (HIP)
Environment Based Overlay Networking Environment
draft-ietf-hip-bone-05.txt draft-ietf-hip-bone-06.txt
Abstract Abstract
This document specifies a framework to build HIP (Host Identity This document specifies a framework to build HIP (Host Identity
Protocol)-based overlay networks. This framework uses HIP to perform Protocol)-based overlay networks. This framework uses HIP to perform
connection management. Other functions, such as data storage and connection management. Other functions, such as data storage and
retrieval or overlay maintenance, are implemented using protocols retrieval or overlay maintenance, are implemented using protocols
other than HIP. These protocols are loosely referred to as peer other than HIP. These protocols are loosely referred to as peer
protocols. protocols.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 11, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6
3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7 3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Identifier Assignment and Authentication . . . . . . . 7 3.3.2. Identifier Assignment and Authentication . . . . . . . 7
3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8 3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8
3.4. HIP Deployability and Legacy Applications . . . . . . . . 8 3.4. HIP Deployability and Legacy Applications . . . . . . . . 8
4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9
5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12 5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12
5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13 5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13
5.2. Connection Establishment . . . . . . . . . . . . . . . . . 14 5.2. Overlay Network Identification . . . . . . . . . . . . . . 14
5.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 5.3. Connection Establishment . . . . . . . . . . . . . . . . . 14
5.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15
5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15
6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16
6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16
6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 13, line 4 skipping to change at page 13, line 4
+------------------+-------------------+ +------------------+-------------------+
Figure 7: Example HIP BONE Stack Structure Figure 7: Example HIP BONE Stack Structure
5. The HIP BONE Framework 5. The HIP BONE Framework
HIP BONE is a generic framework that allows the use of different peer HIP BONE is a generic framework that allows the use of different peer
protocols. A particular HIP BONE instance uses a particular peer protocols. A particular HIP BONE instance uses a particular peer
protocol. The details on how to implement a HIP BONE using a given protocol. The details on how to implement a HIP BONE using a given
peer protocol need to be specified in a, so called, HIP BONE instance peer protocol need to be specified in a, so called, HIP BONE instance
specification. Section 5.4 discusses what details need to be specification. Section 5.5 discusses what details need to be
specified by HIP BONE instance specifications. For example, the HIP specified by HIP BONE instance specifications. For example, the HIP
BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is
specified in [I-D.ietf-hip-reload-instance]. specified in [I-D.ietf-hip-reload-instance].
5.1. Node ID Assignment and Bootstrap 5.1. Node ID Assignment and Bootstrap
Nodes in an overlay are primarily identified by their Node IDs. Nodes in an overlay are primarily identified by their Node IDs.
Overlays typically have an enrollment server that can generate Node Overlays typically have an enrollment server that can generate Node
IDs, or at least some part of the Node ID, and sign certificates. A IDs, or at least some part of the Node ID, and sign certificates. A
certificate generated by an enrollment server authorizes a particular certificate generated by an enrollment server authorizes a particular
user to use a particular Node ID in a particular overlay. The way user to use a particular Node ID in a particular overlay. The way
users and overlays are identified are defined by the peer protocol users are identified is defined by the peer protocol and HIP BONE
and HIP BONE instance specification. instance specification.
The enrollment server of an overlay that were to use HITs derived The enrollment server of an overlay that were to use HITs derived
from public keys as Node IDs could just authorize users to use the from public keys as Node IDs could just authorize users to use the
public keys and HITs associated to their nodes. Such a Node ID has public keys and HITs associated to their nodes. Such a Node ID has
the same self-certifying property as HITs and the Node ID can also be the same self-certifying property as HITs and the Node ID can also be
used in the HIP and legacy APIs as an ORCHID. This works well as used in the HIP and legacy APIs as an ORCHID. This works well as
long as the enrollment server is the one generating the public/ long as the enrollment server is the one generating the public/
private key pairs for all those nodes. If the enrollment server private key pairs for all those nodes. If the enrollment server
authorizes users to use HITs that are generated directly by the nodes authorizes users to use HITs that are generated directly by the nodes
themselves, the system is open to a type of chosen-peer-ID attack. themselves, the system is open to a type of chosen-peer-ID attack.
skipping to change at page 14, line 10 skipping to change at page 14, line 10
is that it makes possible to use them with legacy socket APIs, but in is that it makes possible to use them with legacy socket APIs, but in
this context most of the applications are assumed to be HIP aware and this context most of the applications are assumed to be HIP aware and
able to use a more advanced API supporting full 128-bit identifiers. able to use a more advanced API supporting full 128-bit identifiers.
Even larger address spaces could be supported with an additional HIP Even larger address spaces could be supported with an additional HIP
parameter giving the source and destination Node IDs, but defining parameter giving the source and destination Node IDs, but defining
such a parameter, if needed, is left for future documents. such a parameter, if needed, is left for future documents.
Bootstrap issues such as how to locate an enrollment or a bootstrap Bootstrap issues such as how to locate an enrollment or a bootstrap
server belong to the peer protocol. server belong to the peer protocol.
5.2. Connection Establishment 5.2. Overlay Network Identification
It is possible for a HIP host to participate simultaneously in
multiple different overlay networks. It is also possible that some
HIP traffic is not intended to be forwarded over an overlay.
Therefore, a host needs to know to which overlay an incoming HIP
message belongs to and the outgoing HIP messages need to be labeled
belonging to a certain overlay. This document specifies a new
generic HIP parameter (in Section 6.1) for the purpose of directing
HIP messages to the right overlay.
In addition, an application using HIP BONE needs to define, either
implicitly or explicitly, the overlay to use for communication.
Explicit configuration can happen, e.g., by configuring certain local
HITs to be be bound to certain overlays or by defining the overlay
identifier using advanced HIP socket options or other suitable APIs.
On the other hand, if no explicit configuration for a HIP association
is used, a host may have a configured default overlay where all HIP
messages without a valid locator are sent. The specification for how
to implement this coordination for locally originated messages is out
of scope for this document.
5.3. Connection Establishment
Nodes in an overlay need to establish connection with other nodes in Nodes in an overlay need to establish connection with other nodes in
different cases. For example, a node typically has connections to different cases. For example, a node typically has connections to
the nodes in its forwarding table. Nodes also need to establish the nodes in its forwarding table. Nodes also need to establish
connections with other nodes in order to exchange application-layer connections with other nodes in order to exchange application-layer
messages. messages.
As discussed earlier, HIP uses the base exchange to establish As discussed earlier, HIP uses the base exchange to establish
connections. A HIP endpoint (the initiator) initiates a HIP base connections. A HIP endpoint (the initiator) initiates a HIP base
exchange with a remote endpoint by sending an I1 packet. The exchange with a remote endpoint by sending an I1 packet. The
skipping to change at page 15, line 5 skipping to change at page 15, line 23
by a HIP rendezvous server. by a HIP rendezvous server.
Since HIP supports NAT traversal, a HIP base exchange over the Since HIP supports NAT traversal, a HIP base exchange over the
overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer
exchange between the nodes that are establishing the connection. In exchange between the nodes that are establishing the connection. In
order to perform this exchange, the nodes need to first gather order to perform this exchange, the nodes need to first gather
candidate addresses. Which nodes can be used to obtain reflexive candidate addresses. Which nodes can be used to obtain reflexive
address candidates and which ones can be used to obtain relayed address candidates and which ones can be used to obtain relayed
candidates is defined by the peer protocol. candidates is defined by the peer protocol.
5.3. Lightweight Message Exchanges 5.4. Lightweight Message Exchanges
In some cases, nodes need to perform a lightweight query to another In some cases, nodes need to perform a lightweight query to another
node (e.g., a request followed by a single response). In this node (e.g., a request followed by a single response). In this
situation, establishing a connection using the mechanisms in situation, establishing a connection using the mechanisms in
Section 5.2 for a simple query would be an overkill. A better Section 5.3 for a simple query would be an overkill. A better
solution is to forward a HIP message through the overlay with the solution is to forward a HIP message through the overlay with the
query and another one with the response to the query. The payload of query and another one with the response to the query. The payload of
such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. such HIP packets is integrity protected [I-D.ietf-hip-hiccups].
Nodes in the overlay forward this HIP packet in a hop-by-hop fashion Nodes in the overlay forward this HIP packet in a hop-by-hop fashion
according to the overlay's routing table towards its destination, according to the overlay's routing table towards its destination,
typically through the protected connections established between them. typically through the protected connections established between them.
Again, the overlay acts as a rendezvous server between the nodes Again, the overlay acts as a rendezvous server between the nodes
exchanging the messages. exchanging the messages.
5.4. HIP BONE Instantiation 5.5. HIP BONE Instantiation
As discussed in Section 5, HIP BONE is a generic framework that As discussed in Section 5, HIP BONE is a generic framework that
allows using different peer protocols. A particular HIP BONE allows using different peer protocols. A particular HIP BONE
instance uses a particular peer protocol. The details on how to instance uses a particular peer protocol. The details on how to
implement a HIP BONE using a given peer protocol need to be specified implement a HIP BONE using a given peer protocol need to be specified
in a, so called, HIP BONE instance specification. A HIP BONE in a, so called, HIP BONE instance specification. A HIP BONE
instance specification needs to define, minimally: instance specification needs to define, minimally:
o the peer protocol to be used. o the peer protocol to be used.
o what kind of Node IDs are used and how they are derived. o what kind of Node IDs are used and how they are derived.
skipping to change at page 16, line 24 skipping to change at page 16, line 45
This section defines generic format and protocol behavior for the This section defines generic format and protocol behavior for the
Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that
can be used in HIP based overlay networks. HIP BONE instance can be used in HIP based overlay networks. HIP BONE instance
specifications define the exact format and content of the Overlay specifications define the exact format and content of the Overlay
Identifier parameter, the cases when the Overlay TTL parameter should Identifier parameter, the cases when the Overlay TTL parameter should
be used, and any additional behavior for each packet. be used, and any additional behavior for each packet.
6.1. Overlay Identifier 6.1. Overlay Identifier
It is possible for a HIP host to participate simultaneously in To identify to which overlay network a HIP message belongs to, all
multiple different overlay networks. Therefore, a host needs to know HIP messages that are sent via an overlay, or as a part of operations
to which overlay an incoming HIP message belongs to. Thus, all HIP
messages that are sent via an overlay, or as a part of operations
specific to a certain overlay, MUST contain an OVERLAY_ID parameter specific to a certain overlay, MUST contain an OVERLAY_ID parameter
with the identifier of the corresponding overlay network. Instance with the identifier of the corresponding overlay network. Instance
specifications define how the identifier is generated for different specifications define how the identifier is generated for different
types of overlay networks. The generation mechanism MUST be such types of overlay networks. The generation mechanism MUST be such
that it is unlikely to generate the same identifier for two different that it is unlikely to generate the same identifier for two different
overlay instances and hence it is RECOMMENDED that the identifier overlay instances and hence it is RECOMMENDED that the identifier
contains at least 32 bits of randomness. contains at least 32 bits of randomness.
The generic format of the OVERLAY_ID parameter is shown in Figure 8. The generic format of the OVERLAY_ID parameter is shown in Figure 8.
Instance specifications define valid length for the parameter and how Instance specifications define valid length for the parameter and how
skipping to change at page 20, line 40 skipping to change at page 20, line 40
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[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-reload-instance] [I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE) Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery Instance Specification for REsource LOcation And Discovery
(RELOAD)", draft-ietf-hip-reload-instance-00 (work in (RELOAD)", draft-ietf-hip-reload-instance-01 (work in
progress), January 2010. progress), March 2010.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
 End of changes. 14 change blocks. 
24 lines changed or deleted 45 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/