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/ |