draft-ietf-hip-bone-02.txt   draft-ietf-hip-bone-03.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: January 7, 2010 Ericsson Expires: April 29, 2010 A. Keranen
Ericsson
A. Johnston A. Johnston
Avaya Avaya
July 6, 2009 October 26, 2009
HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
Environment Environment
draft-ietf-hip-bone-02.txt draft-ietf-hip-bone-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 January 7, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5 2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6 2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Identifier Assignment and Authentication . . . . . . . 6 2.3.2. Identifier Assignment and Authentication . . . . . . . 6
2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7
2.4. HIP Deployability and Legacy Applications . . . . . . . . 7 2.4. HIP Deployability and Legacy Applications . . . . . . . . 7
3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8 3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8
3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9 3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9
3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10 3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10
3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11 3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11
3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11 3.4. Participating in Multiple Overlays . . . . . . . . . . . . 11
4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12 3.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 12
5. Architectural Considerations . . . . . . . . . . . . . . . . . 12 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Architectural Considerations . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC5201] defines a new name space The Host Identity Protocol (HIP) [RFC5201] defines a new name space
between the network and transport layers. HIP provides upper layers between the network and transport layers. HIP provides upper layers
with mobility, multihoming, NAT (Network Address Translation) with mobility, multihoming, NAT (Network Address Translation)
traversal, and security functionality. HIP implements the so called traversal, and security functionality. HIP implements the so called
identifier/locator (ID/locator) split, which implies that IP identifier/locator (ID/locator) split, which implies that IP
addresses are only used as locators, not as host identifiers. This addresses are only used as locators, not as host identifiers. This
split makes HIP a suitable protocol to build overlay networks that split makes HIP a suitable protocol to build overlay networks that
skipping to change at page 6, line 30 skipping to change at page 6, line 30
in order to generate an I2 packet. The difficulty of the puzzle can in order to generate an I2 packet. The difficulty of the puzzle can
be adjusted so that, if a receiver is under a DoS attack, it can be adjusted so that, if a receiver is under a DoS attack, it can
increase the difficulty of its puzzles. increase the difficulty of its puzzles.
On receiving an I2 packet, a receiver checks that the solution in the On receiving an I2 packet, a receiver checks that the solution in the
packet corresponds to a puzzle generated by the receiver and that the packet corresponds to a puzzle generated by the receiver and that the
solution is correct. If it is, the receiver processes the I2 packet. solution is correct. If it is, the receiver processes the I2 packet.
Otherwise, it silently discards it. Otherwise, it silently discards it.
In an overlay scenario, there are multiple ways how this mechanism In an overlay scenario, there are multiple ways how this mechanism
can be utilised within the overlay. One possibility is to cache the can be utilized within the overlay. One possibility is to cache the
pre-generated R1 packets within the overlay and let the overlay pre-generated R1 packets within the overlay and let the overlay
directly respond with R1s to I1s. In that way the responder is not directly respond with R1s to I1s. In that way the responder is not
bothered at all until the initiator sends an I2 packet, with the bothered at all until the initiator sends an I2 packet, with the
puzzle solution. Furthermore, a more sophisticated overlay could puzzle solution. Furthermore, a more sophisticated overlay could
verify that an I2 packet has a correctly solved puzzle before verify that an I2 packet has a correctly solved puzzle before
forwarding the packet to the responder. forwarding the packet to the responder.
2.3.2. Identifier Assignment and Authentication 2.3.2. Identifier Assignment and Authentication
As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main
skipping to change at page 8, line 23 skipping to change at page 8, line 23
as such. It opens a connection (e.g., TCP) using the traditional as such. It opens a connection (e.g., TCP) using the traditional
IPv6 socket API. The HIP module running in the same host as the IPv6 socket API. The HIP module running in the same host as the
legacy application intercepts this call somehow (e.g., using an legacy application intercepts this call somehow (e.g., using an
interception library or setting up the host's routing tables so that interception library or setting up the host's routing tables so that
the HIP module receives the traffic) and runs HIP (on behalf of the the HIP module receives the traffic) and runs HIP (on behalf of the
legacy application) towards the IP address corresponding to the legacy application) towards the IP address corresponding to the
ORCHID. This mechanism works well in almost all cases. However, ORCHID. This mechanism works well in almost all cases. However,
applications involving referrals (i.e., passing of IPv6 addresses applications involving referrals (i.e., passing of IPv6 addresses
between applications) present issues, to be discussed in Section 3 between applications) present issues, to be discussed in Section 3
below. Additionally, management applications that care about the below. Additionally, management applications that care about the
exact IP address format may not work well with such straigthforward exact IP address format may not work well with such straightforward
approach. approach.
In order to make HIP work through the traditional IPv4 socket API, In order to make HIP work through the traditional IPv4 socket API,
the HIP module passes an LSI (Local Scope Identifier), instead of a the HIP module passes an LSI (Local Scope Identifier), instead of a
regular IPv4 address, to the legacy IPv4 application. The LSI looks regular IPv4 address, to the legacy IPv4 application. The LSI looks
like an IPv4 address, but is locally bound to an ORCHID. That is, like an IPv4 address, but is locally bound to an ORCHID. That is,
when the legacy application uses the LSI in a socket call, the HIP when the legacy application uses the LSI in a socket call, the HIP
module intercepts it and replaces the LSI with its corresponding module intercepts it and replaces the LSI with its corresponding
ORCHID. Therefore, LSIs always have local scope. They do not have ORCHID. Therefore, LSIs always have local scope. They do not have
any meaning outside the host running the application. The ORCHID is any meaning outside the host running the application. The ORCHID is
used on the wire; not the LSI. In the referral case, if it is not used on the wire; not the LSI. In the referral case, if it is not
possible to rewrite the application level packets to use ORCHIDs possible to rewrite the application level packets to use ORCHIDs
instead of LSIs, it may be hard to make IPv4 referrals work in instead of LSIs, it may be hard to make IPv4 referrals work in
Internet-wide settings. IPv4 LSIs have been succesfully used in Internet-wide settings. IPv4 LSIs have been successfully used in
existing HIP deployments within a single corporate network. existing HIP deployments within a single corporate network.
3. The HIP BONE Framework 3. The HIP BONE Framework
An overlay typically requires three types of operations: An overlay typically requires three types of operations:
o overlay maintenance. o overlay maintenance.
o data storage and retrieval. o data storage and retrieval.
o connection management. o connection management.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
The HIP BONE framework uses HIP to perform connection management. The HIP BONE framework uses HIP to perform connection management.
Data storage and retrieval and overlay maintenance are to be Data storage and retrieval and overlay maintenance are to be
implemented using protocols other than HIP. For lack of a better implemented using protocols other than HIP. For lack of a better
name, these protocols are referred to as peer protocols. name, these protocols are referred to as peer protocols.
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 3.4 discusses what details need to be specification. Section 3.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.keranen-hip-reload-instance]. specified in [I-D.keranen-hip-reload-instance].
3.1. Peer ID Assignment and Bootstrap 3.1. Peer ID Assignment and Bootstrap
Nodes in an overlay are primarily identified by their Peer IDs. Nodes in an overlay are primarily identified by their Peer IDs.
(Note that the Peer ID concept here is a peer-layer protocol concept, (Note that the Peer ID concept here is a peer-layer protocol concept,
distinct from the HIP-layer node identifiers. Peer IDs may be long, distinct from the HIP-layer node identifiers. Peer IDs may be long,
may have some structure, and may consist of multiple parts.) may have some structure, and may consist of multiple parts.)
skipping to change at page 10, line 13 skipping to change at page 10, line 13
key. That is a similar process to the one a host follows to generate key. That is a similar process to the one a host follows to generate
a HIT from a public key. In such scenarios, each host will need a a HIT from a public key. In such scenarios, each host will need a
certificate (e.g., in their HIP base exchanges) provided by the certificate (e.g., in their HIP base exchanges) provided by the
enrollment server to prove that they are authorized to use a enrollment server to prove that they are authorized to use a
particular ORCHID in the overlay. Depending on how the certificates particular ORCHID in the overlay. Depending on how the certificates
are constructed, they typically also need to contain the host's self- are constructed, they typically also need to contain the host's self-
generated public key. Depending on how the Peer IDs and public keys generated public key. Depending on how the Peer IDs and public keys
are attributed, different scenarios become possible. For example, are attributed, different scenarios become possible. For example,
the Peer IDs may be attributed to users, there may be user public key the Peer IDs may be attributed to users, there may be user public key
identifiers, and there may be separate host public key identifiers. identifiers, and there may be separate host public key identifiers.
Authorisation certificates can be used to bind the different types of Authorization certificates can be used to bind the different types of
identifiers together. identifiers together.
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.
3.2. Connection Establishment 3.2. 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
skipping to change at page 11, line 25 skipping to change at page 11, line 25
Section 3.2 for a simple query would be an overkill. A better Section 3.2 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.nikander-hip-hiccups]. such HIP packets is integrity protected [I-D.nikander-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.
3.4. HIP BONE Instantiation 3.4. Participating in Multiple Overlays
It is possible for a HIP host to participate simultaneously in
multiple different overlay networks and a host needs to know 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 (shown in
Figure 3) with the identifier of the corresponding overlay network.
Instance specifications define how the identifier is generated for
different types of overlay networks. The generation mechanism SHOULD
be such that it is unlikely to generate the same identifier for two
different overlay instances and hence it is RECOMMENDED that the
identifier contains at least 32 bits of randomness.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: 980 ]
Length Length of the Identifier in octets
Identifier The overlay identifier
Padding 0-7 bytes of padding if the identifier length is not
multiple of 8 bytes
Figure 3: Format of the OVERLAY_ID parameter
OPEN ISSUE: this introduces normative language to the architecture
draft. Should this parameter be defined in some other (possibly
stand alone) draft?
3.5. HIP BONE Instantiation
As discussed in Section 3, HIP BONE is a generic framework that As discussed in Section 3, 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 how to transform the peer IDs used by the peer protocol into the o how to transform the peer IDs used by the peer protocol into the
ORCHIDs that will be used in HIP. ORCHIDs that will be used in HIP.
o which peer protocol primitives trigger HIP messages. o which peer protocol primitives trigger HIP messages.
o how the overlay identifier is generated.
Additionally, a HIP BONE instance specification may need to specify Additionally, a HIP BONE instance specification may need to specify
other details that are specific to the peer protocol used. other details that are specific to the peer protocol used.
As an example, the HIP BONE instance specification for RELOAD As an example, the HIP BONE instance specification for RELOAD
[I-D.ietf-p2psip-base] is specified in [I-D.ietf-p2psip-base] is specified in
[I-D.keranen-hip-reload-instance]. [I-D.keranen-hip-reload-instance].
It is assumed that areas not covered by a particular HIP BONE It is assumed that areas not covered by a particular HIP BONE
instance specification are specified by the peer protocol or instance specification are specified by the peer protocol or
elsewhere. These areas include: elsewhere. These areas include:
o the algorithm to create the overlay (e.g., a DHT). o the algorithm to create the overlay (e.g., a DHT).
o overlay maintenance functions. o overlay maintenance functions.
o data storage and retrieval functions. o data storage and retrieval functions.
o format and structure of peer IDs. o format and structure of peer IDs.
o the process for obtaining a peer ID. o the process for obtaining a peer ID.
o overlay identification.
o bootstrap function o bootstrap function
o how to select STUN and TURN servers for the candidate address o how to select STUN and TURN servers for the candidate address
collection process in NAT traversal scenarios. collection process in NAT traversal scenarios.
o for what type of traffic or messages it is appropriate to use o for what type of traffic or messages it is appropriate to use
lightweight message exchanges. lightweight message exchanges.
Note that the border between HIP BONE instance specification and a Note that the border between HIP BONE instance specification and a
peer protocol specifications is blurry. Depending on how generic the peer protocol specifications is blurry. Depending on how generic the
specification of a given peer protocol is, its associated HIP BONE specification of a given peer protocol is, its associated HIP BONE
instance specification may need to specify more or less details. instance specification may need to specify more or less details.
Also, a particular HIP BONE instance specification left certain areas Also, a HIP BONE instance specification may leave certain areas
unspecified in order to leave their configuration up to each unspecified in order to leave their configuration up to each
particular overlay. particular overlay.
4. Advantages of Using HIP BONE 4. Advantages of Using HIP BONE
Using HIP BONE, as opposed to a peer protocol, to perform connection Using HIP BONE, as opposed to a peer protocol, to perform connection
management in an overlay has a set of advantages. HIP BONE can be management in an overlay has a set of advantages. HIP BONE can be
used by any peer protocol. This keeps each peer protocol from used by any peer protocol. This keeps each peer protocol from
defining primitives needed for connection management (e.g., defining primitives needed for connection management (e.g.,
primitives to establish connections and to tunnel messages through primitives to establish connections and to tunnel messages through
skipping to change at page 12, line 45 skipping to change at page 13, line 44
Additionally, having a solution that integrates mobility and Additionally, having a solution that integrates mobility and
multihoming is useful in many scenarios. Peer protocols do not multihoming is useful in many scenarios. Peer protocols do not
typically specify mobility and multihoming solutions. Combining a typically specify mobility and multihoming solutions. Combining a
peer protocol including NAT traversal with a separate mobility peer protocol including NAT traversal with a separate mobility
mechanism and a separate multihoming mechanism can easily lead to mechanism and a separate multihoming mechanism can easily lead to
unexpected (and unpleasant) interactions. unexpected (and unpleasant) interactions.
5. Architectural Considerations 5. Architectural Considerations
Architecturally, HIP can be considered to create a new thin "waist" Architecturally, HIP can be considered to create a new thin "waist"
layer on the top of the IPv4 and IPv6 networks; see Figure 3. The layer on the top of the IPv4 and IPv6 networks; see Figure 4. The
HIP layer itself consists of the HIP signalling protocol and one or HIP layer itself consists of the HIP signaling protocol and one or
more data transport protocols; see Figure 4. The HIP signalling more data transport protocols; see Figure 5. The HIP signaling
packets and the data transport packets can take different routes. In packets and the data transport packets can take different routes. In
the HIP BONE, the HIP signalling packets are typically first routed the HIP BONE, the HIP signaling packets are typically first routed
through the overlay and then directly (if possible), while the data through the overlay and then directly (if possible), while the data
transport packets are typically routed only directly between the end transport packets are typically routed only directly between the end
points. points.
+--------------------------------------+ +--------------------------------------+
| Transport (using HITs or LSIs) | | Transport (using HITs or LSIs) |
+--------------------------------------+ +--------------------------------------+
| HIP | | HIP |
+------------------+-------------------+ +------------------+-------------------+
| IPv4 | IPv6 | | IPv4 | IPv6 |
+------------------+-------------------+ +------------------+-------------------+
Figure 3: HIP as a thin waist Figure 4: HIP as a thin waist
+------------------+-------------------+ +------------------+-------------------+
| HIP signalling | data transports | | HIP signaling | data transports |
+------------------+-------------------+ +------------------+-------------------+
Figure 4: HIP layer structure Figure 5: HIP layer structure
In HIP BONE, the peer protocol creates a new signalling layer on the In HIP BONE, the peer protocol creates a new signaling layer on the
top of HIP. It is used to set up forwarding paths for HIP signalling top of HIP. It is used to set up forwarding paths for HIP signaling
messages. This is a similar relationship that an IP routing messages. This is a similar relationship that an IP routing
protocol, such as OSPF, has to the IP protocol itself. In the HIP protocol, such as OSPF, has to the IP protocol itself. In the HIP
BONE case, the peer protocol plays a role similar to OSPF, and HIP BONE case, the peer protocol plays a role similar to OSPF, and HIP
plays a role similar to IP. The ORCHIDs are used for forwarding HIP plays a role similar to IP. The ORCHIDs are used for forwarding HIP
packets according to the information in the routing tables. The peer packets according to the information in the routing tables. The peer
protocols are used to exchange routing information based on Peer IDs protocols are used to exchange routing information based on Peer IDs
and public keys, and to construct the routing tables. and public keys, and to construct the routing tables.
Architecturally, routing tables are located between the peer protocol Architecturally, routing tables are located between the peer protocol
and HIP, as shown in Figure 5. The peer protocol constructs the and HIP, as shown in Figure 6. The peer protocol constructs the
routing table and keeps it updated. The HIP layer accesses the routing table and keeps it updated. The HIP layer accesses the
routing table in order to make routing decisions. The bootstrap of a routing table in order to make routing decisions. The bootstrap of a
HIP BONE overlay does not create circular dependencies between the HIP BONE overlay does not create circular dependencies between the
peer protocol (which needs to use HIP to establish connections with peer protocol (which needs to use HIP to establish connections with
other nodes) and HIP (which needs the peer protocol to know how to other nodes) and HIP (which needs the peer protocol to know how to
route messages to other nodes) for the same reasons as the bootstrap route messages to other nodes) for the same reasons as the bootstrap
of an IP network does not create circular dependencies between OSPF of an IP network does not create circular dependencies between OSPF
and IP. The first connections established by the peer protocol are and IP. The first connections established by the peer protocol are
with nodes whose locators are known. HIP establishes those with nodes whose locators are known. HIP establishes those
connections as any connection between two HIP nodes where no overlays connections as any connection between two HIP nodes where no overlays
skipping to change at page 14, line 13 skipping to change at page 15, line 13
rendezvous service for those connections. rendezvous service for those connections.
+--------------------------------------+ +--------------------------------------+
| Peer protocol | | Peer protocol |
+--------------------------------------+ +--------------------------------------+
| Routing table | | Routing table |
+--------------------------------------+ +--------------------------------------+
| HIP | | HIP |
+--------------------------------------+ +--------------------------------------+
Figure 5: Routing tables Figure 6: Routing tables
It is possible that different overlays use different routing table It is possible that different overlays use different routing table
formats. For example, the structure of the routing tables of two formats. For example, the structure of the routing tables of two
overlays based on different DHTs (Distributed Hash Tables) may be overlays based on different DHTs (Distributed Hash Tables) may be
very different. In order to make routing decisions, the HIP layer very different. In order to make routing decisions, the HIP layer
needs to convert the routing table generated by the peer protocol needs to convert the routing table generated by the peer protocol
into a forwarding table that allows the HIP layer select a next-hop into a forwarding table that allows the HIP layer select a next-hop
for any packet being routed. for any packet being routed.
In HIP BONE, the HIP usage of public keys and deriving ORCHIDs In HIP BONE, the HIP usage of public keys and deriving ORCHIDs
through a hash function can be utilised at the peer protocol side to through a hash function can be utilized at the peer protocol side to
better secure routing table maintenance and to protect against better secure routing table maintenance and to protect against
chosen-peer-ID attacks. chosen-peer-ID attacks.
The HIP BONE provides quite a lot of flexibility with regards to how The HIP BONE provides quite a lot of flexibility with regards to how
to arrange the different protocols in detail. Figure 6 shows one to arrange the different protocols in detail. Figure 7 shows one
potential stack structure. potential stack structure.
+-----------------------+--------------+ +-----------------------+--------------+
| peer protocols | media | | peer protocols | media |
+------------------+----+--------------+ +------------------+----+--------------+
| HIP signalling | data transport | | HIP signaling | data transport |
| | | |
+------------------+-------------------+ +------------------+-------------------+
| NAT | non-NAT | | | NAT | non-NAT | |
| | | | | |
| IPv4 | IPv6 | | IPv4 | IPv6 |
+------------------+-------------------+ +------------------+-------------------+
Figure 6: Example HIP BONE stack structure Figure 7: Example HIP BONE stack structure
6. Security Considerations 6. Security Considerations
This document provides a high-level framework to build HIP-based This document provides a high-level framework to build HIP-based
overlays. The security properties of HIP and its extensions used in overlays. The security properties of HIP and its extensions used in
this framework are discussed in their respective specifications. this framework are discussed in their respective specifications.
Those security properties can be affected by the way HIP is used in a Those security properties can be affected by the way HIP is used in a
particular overlay (e.g., by how ORCHIDs are derived from Peer IDs). particular overlay (e.g., by how ORCHIDs are derived from Peer IDs).
However, those properties are mostly affected by the design decisions However, those properties are mostly affected by the design decisions
made to build a particular overlay; not so much by how this high- made to build a particular overlay; not so much by how this high-
skipping to change at page 16, line 12 skipping to change at page 17, line 12
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, Identity Protocol with Legacy Applications", RFC 5338,
September 2008. September 2008.
[I-D.ietf-hip-native-api] [I-D.ietf-hip-native-api]
Komu, M. and T. Henderson, "Basic Socket Interface Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for Host Identity Protocol (HIP)", Extensions for Host Identity Protocol (HIP)",
draft-ietf-hip-native-api-06 (work in progress), May 2009. draft-ietf-hip-native-api-09 (work in progress),
September 2009.
[I-D.ietf-hip-nat-traversal] [I-D.ietf-hip-nat-traversal]
Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keraenen, "Basic HIP Extensions for Traversal of Network Keraenen, "Basic HIP Extensions for Traversal of Network
Address Translators", draft-ietf-hip-nat-traversal-08 Address Translators", draft-ietf-hip-nat-traversal-08
(work in progress), June 2009. (work in progress), June 2009.
[I-D.nikander-hip-hiccups] [I-D.nikander-hip-hiccups]
Nikander, P., Camarillo, G., and J. Melen, "HIP (Host Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
Identity Protocol) Immediate Carriage and Conveyance of Identity Protocol) Immediate Carriage and Conveyance of
Upper- layer Protocol Signaling (HICCUPS)", Upper- layer Protocol Signaling (HICCUPS)",
draft-nikander-hip-hiccups-01 (work in progress), draft-nikander-hip-hiccups-04 (work in progress),
November 2008. August 2009.
9.2. Informative References 9.2. Informative References
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[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-02 (work in Base Protocol", draft-ietf-p2psip-base-04 (work in
progress), March 2009. progress), October 2009.
[I-D.keranen-hip-reload-instance] [I-D.keranen-hip-reload-instance]
Keranen, A. and G. Camarillo, "HIP BONE Instance Keranen, A. and G. Camarillo, "HIP BONE Instance
Specification for RELOAD", Specification for RELOAD",
draft-keranen-hip-reload-instance-00 (work in progress), draft-keranen-hip-reload-instance-00 (work in progress),
July 2009. July 2009.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
skipping to change at page 17, line 31 skipping to change at page 18, line 31
Email: Pekka.Nikander@ericsson.com Email: Pekka.Nikander@ericsson.com
Jani Hautakorpi Jani Hautakorpi
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com Email: Jani.Hautakorpi@ericsson.com
Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
Email: Ari.Keranen@ericsson.com
Alan Johnston Alan Johnston
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan@sipstation.com Email: alan@sipstation.com
 End of changes. 30 change blocks. 
42 lines changed or deleted 89 lines changed or added

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