draft-ietf-hip-nat-traversal-03.txt   draft-ietf-hip-nat-traversal-04.txt 
HIP Working Group M. Komu HIP Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Experimental T. Henderson Intended status: Experimental T. Henderson
Expires: August 28, 2008 The Boeing Company Expires: January 16, 2009 The Boeing Company
P. Matthews P. Matthews
Avaya (Unaffiliated)
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
A. Keraenen A. Keraenen, Ed.
J. Melen
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
M. Bagnulo July 15, 2008
Huawei Lab at UC3M
February 25, 2008
Basic HIP Extensions for Traversal of Network Address Translators and Basic HIP Extensions for Traversal of Network Address Translators
Firewalls draft-ietf-hip-nat-traversal-04.txt
draft-ietf-hip-nat-traversal-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 45 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on January 16, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Host Identity Protocol (HIP) provides a new namespace that can be The Host Identity Protocol (HIP) provides a new namespace that can be
used for uniquely identifying hosts. Existing HIP experimental used for uniquely identifying hosts. Existing HIP experimental
specifications do not specify protocol operations across Network specifications do not specify protocol operations across Network
Address Translators (NATs). Address Translators (NATs).
This document specifies NAT traversal extensions for HIP. The HIP This document specifies basic NAT traversal extensions for HIP. The
shim layer is located between the network and transport layer, the HIP shim layer is located between the network and transport layer,
extensions can also provide a more general-purpose NAT traversal the extensions can also provide a more general-purpose NAT traversal
support for higher-layer networking applications. The extensions are support for higher-layer networking applications. The extensions are
based on the use of the The Interactive Connectivity Establishment based on the use of the The Interactive Connectivity Establishment
(ICE) methodology to discover a working path between two end-hosts. (ICE) methodology to discover a working path between two end-hosts.
Using the specified extensions, two HIP-capable hosts are able to
communicate with each other even when both nodes are behind NATs or
firewalls.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
3.1. Relay Registration and NAT Detection . . . . . . . . . . . 7 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 6
3.2. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9 3.2. NAT Transformation Negotiation . . . . . . . . . . . . . . 8
4. Connectivity Tests . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Base Exchange via HIP Relay . . . . . . . . . . . . . . . 9
4.1. NAT Transformation Negotiation . . . . . . . . . . . . . . 11 3.4. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 11
4.2. ICE Procedure . . . . . . . . . . . . . . . . . . . . . . 12 3.5. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 12
4.3. NAT Keep-alives . . . . . . . . . . . . . . . . . . . . . 12 3.6. Base Exchange without ICE Connectivity Checks . . . . . . 12
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Base Exchange without UDP Encapsulation . . . . . . . . . 13
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 13 3.8. Sending Control Messages using the Data Plane . . . . . . 13
5.2. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 13 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Relay and Registration Parameters . . . . . . . . . . . . 14 4.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 14
5.4. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 14 4.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 14
5.5. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 15
5.6. Registration Types . . . . . . . . . . . . . . . . . . . . 16 4.4. Relay and Registration Parameters . . . . . . . . . . . . 16
5.7. HIP ESP Data Packet Formats . . . . . . . . . . . . . . . 17 4.5. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.6. RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 17 4.7. Registration Types . . . . . . . . . . . . . . . . . . . . 19
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 18 4.8. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 20
9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Base Exchange Replay Protection for HIP Relay Server . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 5.4. Demuxing Different HIP Associations . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Firewall Traversal . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Base Exchange without ICE Connectivity Checks . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix C. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix D. Base Exchange through a Rendezvous Server . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
Appendix E. Document Revision History . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Appendix B. Base Exchange through a Rendezvous Server . . . . . . 24
Appendix C. Document Revision History . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
HIP [I-D.ietf-hip-base] is defined as a protocol that runs directly HIP [RFC5201] is defined as a protocol that runs directly over IPv4
over IPv4 or IPv6. This approach is known to have problems or IPv6. This approach is known to have problems traversing NATs. A
traversing NATs. Several different types of NATs exist, see detailed description of HIP problems with traversing legacy
[RFC2663]. This document describes HIP extensions for the traversal middleboxes is documented in [I-D.irtf-hiprg-nat]. This document
of both Network Address Translator (NAT) and Network Address and Port describes HIP extensions for the traversal of both Network Address
Translator (NAPT) middleboxes. Additionally, it covers firewalls to Translator (NAT) and Network Address and Port Translator (NAPT)
a certain extend (see Appendix A for a more detailed discussion). middleboxes. The document generally uses the term NAT to refer to
The document generally uses the term NAT to refer to these types of these types of middleboxes.
middleboxes. A detailed description of HIP problems with traversing
legacy middleboxes is documented in [I-D.irtf-hiprg-nat].
NAT devices do not operate consistently even though a recommended Currently deployed NAT devices do not operate consistently even
behavior is described in [RFC4787]. The HIP protocol extensions in though a recommended behavior is described in [RFC4787]. The HIP
this document make as few assumptions as possible about the behavior protocol extensions in this document make as few assumptions as
of the NAT devices so that NAT traversal will work even with legacy possible about the behavior of the NAT devices so that NAT traversal
NAT devices. The purpose of these extensions is to allow two HIP- will work even with legacy NAT devices. The purpose of these
enabled hosts to communicate with each other even if one or both extensions is to allow two HIP-enabled hosts to communicate with each
communicating hosts are in private address realms. With some legacy other even if one or both communicating hosts are in private address
NAT devices, utilizing the shortest path between two end hosts realms.
Using the extensions defined in this draft, HIP end-hosts use the HIP
control channel to communicate their current locators to each other
to find a operational path for the ESP encapsulated data traffic.
The hosts test connectivity between different locators and try to
discover direct end-to-end path between the end-hosts. However, With
some legacy NATs, utilizing the shortest path between two end hosts
located behind NATs is not possible without relaying the traffic located behind NATs is not possible without relaying the traffic
through a relay, such as a TURN server [I-D.ietf-behave-p2p-state]. through a relay, such as a TURN server [RFC5128]. As a consequence,
As a consequence, the TURN server increases the roundtrip delay and the TURN server increases the roundtrip delay and may become a point
may become a point of network congestion. With the extensions of network congestion. With the extensions described in this
described in this document, hosts try to avoid the use of such a document, hosts try to avoid the use the TURN server when possible.
relay when possible.
A distinction must be made between a HIP rendezvous server (defined This document defines new middlebox extensions to allow NAT traversal
in [I-D.ietf-hip-rvs]) and a HIP Relay, defined herein. HIP for HIP control plane. The HIP Relay extensions define mechanisms to
forward HIP control plane. A distinction must be made here between a
HIP rendezvous services [RFC5204]) and HIP Relay services. HIP
rendezvous servers solve initial contact and mobility related rendezvous servers solve initial contact and mobility related
problems in networks without NATs. HIP Relay solve the same problems in networks without NATs. HIP Relay servers solve the same
problems, in addition to NAT traversal problems. HIP Relay servers problems, in addition to NAT traversal problems. HIP Relay servers
can be used both in NATted and non-NATted networks. can be used both in NATed and non-NATed networks.
Both rendezvous and relay services forward HIP control packets, but Both rendezvous and relay services forward HIP control packets, but
the main difference is that the rendezvous service forwards only the the main difference is that the rendezvous service forwards only the
initial I1 packet of the base exchange while all other HIP control initial I1 packet of the base exchange while all other HIP control
packets are sent directly between the communicating hosts. In packets are sent directly between the communicating hosts. In
contrast, the relay service relays all HIP control packets because contrast, the relay service relays all HIP control packets because
p2p-unfriendly NAT devices drop the packets otherwise NATs can drop the packets otherwise [RFC5128].
[I-D.ietf-behave-p2p-state]. The peers use the control channel to
communicate their current locators to each other to find a direct
path for carrying ESP encapsulated data traffic. A direct path
between the hosts enables efficient delivery of data traffic without
relaying of ESP packets through an intermediary TURN server. The
direct path is searched using connectivity tests.
The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice]. The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice].
[I-D.ietf-mmusic-ice] describes ICE as follows: [I-D.ietf-mmusic-ice] describes ICE as follows:
"The Interactive Connectivity Establishment (ICE) methodology is a "The Interactive Connectivity Establishment (ICE) methodology is a
technique for NAT traversal for UDP-based media streams (though technique for NAT traversal for UDP-based media streams (though
ICE can be extended to handle other transport protocols, such as ICE can be extended to handle other transport protocols, such as
TCP) established by the offer/answer model. ICE is an extension TCP) established by the offer/answer model. ICE is an extension
to the offer/answer model, and works by including a multiplicity to the offer/answer model, and works by including a multiplicity
of IP addresses and ports in SDP offers and answers, which are of IP addresses and ports in SDP offers and answers, which are
then tested for connectivity by peer-to-peer connectivity checks. then tested for connectivity by peer-to-peer connectivity checks.
The IP addresses and ports included in the SDP and the The IP addresses and ports included in the SDP and the
connectivity checks are performed using the revised STUN connectivity checks are performed using the revised STUN
specification [I-D.ietf-behave-rfc3489bis], now renamed to Session specification [I-D.ietf-behave-rfc3489bis], now renamed to Session
Traversal Utilities for NAT." Traversal Utilities for NAT."
ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP
protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip]. protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip].
Two hosts communicate their peer address set (typically consisting of Two hosts communicate their locators to each other in the HIP base
IP address and port number pairs) to each other in the HIP base
exchange. They are then paired with the locally operational address exchange. They are then paired with the locally operational address
of the other end point and prioritized according to some policy. of the other endpoint and prioritized according local and recommended
These address sets are then tested sequentially based on the policies. These address sets are then tested sequentially based on
procedure specified in ICE. Both sides participate in the the procedures specified in ICE. Both sides participate in the
connectivity tests. The tests also determine whether operational connectivity checks. The tests may also discover multiple
address pairs and select the preferred address pair to be used for operational address pairs but determine a single preferred address
subsequent communication. pair to be used for subsequent communication.
As a summary, the extensions in this document In a nutshell, the extensions in this document defines:
o illustrate how to encapsulate HIP packets in UDP o encapsulatation of HIP packets in UDP
o refer to the UDP encapsulation of IPsec ESP packets defined in o UDP encapsulation of IPsec ESP packets
Section 2.1 of RFC 3948 [RFC3948]
o define how a node interacts with a HIP rendezvous server (defined o registration extensions for HIP Relay services
in [I-D.ietf-hip-rvs]) when middleboxes are present
o describe a methodology to determine operational address pairs o how the "offer" and "answer" are carried in the base exchange
between two end hosts based on ICE.
o interaction with ICE connectivity messages
o backwards compatibility issues with rendezvous servers
o a number of optimizations (such when the ICE connectivity tests
can be excluded)
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [I-D.ietf-hip-base], This document borrows terminology from [RFC5201], [RFC5206],
[I-D.ietf-hip-mm], [RFC4423], [I-D.ietf-mmusic-ice], and [RFC4423], [I-D.ietf-mmusic-ice], and [I-D.ietf-behave-rfc3489bis].
[I-D.ietf-behave-rfc3489bis]. Additionally, the following terms are Additionally, the following terms are used:
used:
Rendezvous server: Rendezvous server:
A host that forwards I1 packets to the Responder A host that forwards I1 packets to the Responder
HIP Relay: HIP Relay:
A host that forwards all HIP control packets between an Initiator A host that forwards all HIP control packets between an Initiator
and Responder and Responder
TURN server: TURN server:
A server that forwards data traffic between two end-hosts A server that forwards data traffic between two end-hosts
Locator: Locator:
A name that controls how the packet is routed through the network As defined in [RFC5206]: "A name that controls how the packet is
and demultiplexed by the end host. It may include a concatenation routed through the network and demultiplexed by the end host. It
of traditional network addresses such as an IPv6 address and end- may include a concatenation of traditional network addresses such
to-end identifiers such as an ESP SPI. It may also include as an IPv6 address and end-to-end identifiers such as an ESP SPI.
transport port numbers or IPv6 Flow Labels as demultiplexing It may also include transport port numbers or IPv6 Flow Labels as
context, or it may simply be a network address. [I-D.ietf-hip-mm] demultiplexing context, or it may simply be a network address."
"Address" is used in this document as a synonym for locator. It should noticed that "address" is used in this document as a
synonym for locator.
HIP Relay:
LOCATOR (written in capital letters) denotes a HIP control message
parameter that bundles multiple locators together
ICE Offer:
The Initiator's LOCATOR parameter in HIP I2 control message.
ICE Answer:
The Responder's LOCATOR parameter in HIP R2 control message
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address Transport layer port and the corresponding IPv4/v6 address
Candidate: Candidate:
A transport address that has not been verified yet for A transport address that has not been verified yet for
reachability using ICE reachability using ICE
skipping to change at page 7, line 15 skipping to change at page 6, line 33
A translated transport address of a host as observed by a HIP A translated transport address of a host as observed by a HIP
Relay or a STUN server Relay or a STUN server
Peer reflexive transport candidate: Peer reflexive transport candidate:
A translated transport address of a host as observed by its peer A translated transport address of a host as observed by its peer
Relayed transport candidate: Relayed transport candidate:
A transport address that exists on a TURN server. If a permission A transport address that exists on a TURN server. Packets that
exists, packets that arrive at this address are relayed towards arrive at this address are relayed towards the TURN client.
the TURN client.
3. Protocol Description 3. Protocol Description
This section describes the normative behavior of the protocol This section describes the normative behavior of the protocol
extension. Examples of packet exchanges are provided for extension. Examples of packet exchanges are provided for
illustration purposes. illustration purposes.
3.1. Relay Registration and NAT Detection 3.1. Relay Registration
HIP rendezvous servers are used in non-NATted environments and their HIP rendezvous servers operate in non-NATed environments and their
use is described in [I-D.ietf-hip-rvs]. This section specifies a new use is described in [RFC5204]. This section specifies a new
role for these rendezvous servers to act as HIP Relays. HIP Relays middlebox extension, called the HIP Relay, to perate in NATted
forward HIP control packets between the Initiator and the Responder. environments. HIP Relay servers forward all HIP control packets
TURN servers [I-D.ietf-behave-turn] are used for relaying ESP between the Initiator and the Responder over UDP.
traffic. A host SHOULD register to a TURN server before registering
to a HIP Relay to guarantee that the host can accept ESP traffic
immediately after HIP Relay registration.
A HIP relay forwards UDP-encapsulated HIP traffic, and in future End-hosts cannot use the HIP Relay service for forward ESP data
extensions, a relay may also forward TCP-encapsulated traffic. The plane. Instead, they use TURN servers [I-D.ietf-behave-turn] for
HIP Relay forwards HIP control packets. NAT traversal for HIP relaying the ESP traffic. A HIP end-host SHOULD register to a TURN
between two end-hosts may require the use of relays in certain server before registering to a HIP Relay to guarantee that the host
scenarios. A successful NAT traversal therefore requires at least can accept ESP traffic immediately after HIP Relay registration.
the Responder located behind a NAT to register with a HIP Relay.
A HIP Relay MUST silently drop packets to a HIP Relay Client that has A HIP Relay MUST silently drop packets to a HIP Relay Client that has
not previously registered with the HIP Relay. The registration not previously registered with the HIP Relay. The registration
process follows the generic registration extensions defined in process follows the generic registration extensions defined in
[I-D.ietf-hip-registration] and is illustrated in Figure 1. [RFC5203] and is illustrated in Figure 1.
HIP HIP HIP HIP
Relay Relay Relay Relay
Client Server Client Server
| 1. UDP(I1) | | 1. UDP(I1) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
| | | |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->| +------------------------------------------------------->|
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+ |<-------------------------------------------------------+
Figure 1: Example Registration to a HIP Relay Figure 1: Example Registration to a HIP Relay
In step 1, the Initiator starts the registration procedure by sending In step 1, the Relay Client (Initiator) starts the registration
an I1 packet over UDP. It is RECOMMENDED that the Initiator selects procedure by sending an I1 packet over UDP. It is RECOMMENDED that
a random port number from the ephemeral port range 49152-65535 for the Initiator selects a random port number from the ephemeral port
initiating a base exchange. However, the allocated port MUST be range 49152-65535 for initiating a base exchange. However, the
maintained until all of the corresponding HIP Associations are allocated port MUST be maintained until all of the corresponding HIP
closed. Alternatively, a host MAY also use a single fixed port for Associations are closed. Alternatively, a host MAY also use a single
initiating all outgoing connections. fixed port for initiating all outgoing connections.
In step 2, the Responder lists the services that it supports in the In step 2, the Relay Server (Responder) lists the services that it
R1 packet. The support for HIP-over-UDP relaying is denoted by the supports in the R1 packet. The support for HIP-over-UDP relaying is
RELAY_UDP_HIP value. The R1 does not contain any NAT transform denoted by the RELAY_UDP_HIP value. The R1 SHOULD not contain any
parameter (see Section 4.1) as discussed in Appendix B. NAT transform parameter.
In step 3, the Initiator selects the services it registers for and In step 3, the Initiator selects the services it registers for and
lists them in the REG_REQ parameter. In this example, the Initiator lists them in the REG_REQ parameter. In this example, the Initiator
registers for HIP Relay service. registers for HIP Relay service.
In step 4, the Responder concludes the registration procedure with an In step 4, the Responder concludes the registration procedure with an
R2 packet and acknowledges the registered services in the REG_RES R2 packet and acknowledges the registered services in the REG_RES
parameter. The Responder may also denote unsuccessful registrations parameter. The Responder denotes unsuccessful registrations in the
in the REG_FAILED parameter in R2. The Responder also includes a REG_FAILED parameter in R2. The Responder also includes a REG_FROM
REG_FROM parameter that contains the transport address of the client parameter that contains the transport address of the client as
as observed by the Relay (Server Reflexive candidate). After the observed by the Relay (Server Reflexive candidate). After the
registration, the Initiator needs to send periodically NAT keep- registration, the Initiator sends periodically NAT keepalives.
alives.
There are different ways for an Initiator to learn it's publically There are different ways for an Initiator to learn it's publicly
visible IP address and port that are referred to as the "server visible IP address and port that are referred to as the "server
reflexive transport candidate" in this document. This document makes reflexive transport candidate" in this document. It is a local
use of two ways: decision on how the end-host learnds the candidate, but either of the
following methods is RECOMMENDED:
o The Relay client may use STUN servers to detect the server o The Relay client may use STUN servers to detect the server
reflexive locator, as described in [I-D.ietf-behave-p2p-state]. reflexive locator, as described in [RFC5128].
o Alternatively, the Relay Client can learn it from the REG_FROM o Alternatively, the Relay Client can learn it from the REG_FROM
parameter when registering to a Relay. parameter when registering to a Relay.
3.2. Base Exchange via HIP Relay 3.2. NAT Transformation Negotiation
This section describes the usage of a new non-critical transform
parameter type. The presence of the parameter in HIP base exchange
means that the end-host supports ICE connectivity checks. As the
parameter is non-critical, it can be ignored by an end-host which
means that the host does not support or is not willing to use ICE
connectivity checks.
The NAT transform parameter applies to a base exchange between end-
hosts, but currently does not apply to with a registration with a HIP
Relay server. The NAT transform applies only to a base exchange with
transport layer encapsulation and MUST not be included without
transport layer encapsulation. The NAT transform negotiation in base
exchange is illustrated in Figure 2.
Initiator Responder
| 1. UDP(I1) |
+------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) |
|<-------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) |
+------------------------------------------------------------->|
| |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<-------------------------------------------------------------+
| .... |
Figure 2: Negotiation of NAT Transforms
In step 1, the Initiator sends an I1 to the Responder. In step 2,
the Responder responds with an R1. The R1 contains a list of
transforms the Responder supports in NAT_TRANSFORM parameter as shown
in Table 1.
+--------------+----------------------------------------------------+
| Transform | Purpose |
| Type | |
+--------------+----------------------------------------------------+
| RESERVED | Reserved for future use |
| ICE-STUN-UDP | UDP encapsulated control and data traffic with |
| | ICE-based connectivity checks using STUN messages |
+--------------+----------------------------------------------------+
Table 1: Locator Transformations
In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM
parameter. It contains the transform type selected by the Initiator
from the list of transforms offered by the Responder. The I2 also
includes the locators of the Initiator in a LOCATOR parameter. The
locator parameter in I2 is the "ICE offer".
In step 4, the Responder concludes the base exchange with an R2
packet. The Responder includes a LOCATOR parameter in the R2 packet.
The locators parameter in R2 is the "ICE answer".
3.3. Base Exchange via HIP Relay
This section describes how Initiator and Responder establish a base
exchange through a HIP Relay. The NAT transform negotiation (denoted
as NAT_TFM in the example) was described in previous section and
shall not be repeated here. When a Relay receives an R1 or I2 packet
without the NAT transform packet, it drops it and sends a NOTIFY
error message to the originator.
It is RECOMMENDED that the Initiator sends an I1 packet encapsulated It is RECOMMENDED that the Initiator sends an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to a such I1 packet with an Respectively, the Responder MUST respond to such an I1 packet with an
R1 packet over the transport layer and using the same transport R1 packet over the transport layer and using the same transport
protocol. The rest of the base exchange, I2 and R2, MUST also use protocol. The rest of the base exchange, I2 and R2, MUST also use
the same transport layer. the same transport layer.
I HIP Relay R I HIP Relay R
| 1. UDP(I1) | | | 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) | +----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO)) | | | 3. UDP(R1(RELAY_TO, NAT_TFM)) |
| 4. UDP(R1(RELAY_TO)) |<-------------------------------+ | 4. UDP(R1(RELAY_TO),NAT_TFM) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
| 5. UDP(I2(LOCATOR)) | | | 5. UDP(I2(LOCATOR),NAT_TFM) | |
+----------------------------->| | +----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),|
| | 6. UDP(I2(LOCATOR,RELAY_FROM)) | | | NAT_TFM) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(LOCATOR,RELAY_TO)) | | | 7. UDP(R2(LOCATOR,RELAY_TO)) |
| 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
Figure 2: Base Exchange via a HIP Relay Figure 3: Base Exchange via a HIP Relay
In step 1 of Figure 2, the Initiator sends an I1 packet over the In step 1 of Figure 3, the Initiator sends an I1 packet over the
transport layer to the HIT of the Responder. The source address is transport layer to the HIT of the Responder. The source address is
one of the locators of the host. The locators of the end-hosts are one of the locators of the host. The locators belonging to the end-
referred as "host candidates" in this document. hosts are referred as "host candidates" in this document.
In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If
the destination HIT belongs to a registered Responder, the Relay the destination HIT belongs to a registered Responder, the Relay
processes the packet. Otherwise, the Relay MUST drop the packet processes the packet. Otherwise, the Relay MUST drop the packet
silently. The Relay appends a RELAY_FROM parameter to the I1 packet silently. The Relay appends a RELAY_FROM parameter to the I1 packet
which constains the transport source address and port of the I1 as which contains the transport source address and port of the I1 as
observed by the Relay. The Relay protects the I1 packet with observed by the Relay. The Relay protects the I1 packet with
RELAY_HMAC as described in [I-D.ietf-hip-rvs], except that the RELAY_HMAC as described in [RFC5204], except that the parameter type
parameter type is different. The Relay changes the source and is different. The Relay changes the source and destination ports and
destination ports and IP addresses of the packet to match the values IP addresses of the packet to match the values the Responder used
the Responder used when registering to the Relay, i.e., the reverse when registering to the Relay, i.e., the reverse of the R2 used in
of the R2 used in the registration. The Relay MUST recalculate the the registration. The Relay MUST recalculate the transport checksum
transport checksum and forward the packet to the Responder. and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [I-D.ietf-hip-base]. In processes it according to the rules in [RFC5201]. In addition, the
addition, the Responder validates the RELAY_HMAC according to Responder validates the RELAY_HMAC according to [RFC5204] and
[I-D.ietf-hip-rvs] and silenty drops the packet if the validation silently drops the packet if the validation fails. The Responder
fails. The Responder replies with an R1 packet to which it includes replies with an R1 packet to which it includes a RELAY_TO parameter.
a RELAY_TO parameter. The RELAY_TO parameter contains same The RELAY_TO parameter MUST contain same information as the
information as the RELAY_FROM parameter, i.e., Initiator transport RELAY_FROM parameter, i.e., the Initiator's transport address and the
address, but the type of the parameter is different. The RELAY_TO nonce, but the type of the parameter is different. The RELAY_TO
parameter is not integrity protected by the signature of the R1 to parameter is not integrity protected by the signature of the R1 to
allow pre-created R1 packets at the Responder. allow pre-created R1 packets at the Responder.
In step 4, the Relay receives the R1 packet. The Relay drops the In step 4, the Relay receives the R1 packet. The Relay drops the
packet silently if the source HIT belongs to an unregistered host. packet silently if the source HIT belongs to an unregistered host.
The Relay MAY verify the signature of the R1 packet and drop it if The Relay MAY verify the signature of the R1 packet and drop it if
the signature is invalid. Otherwise, the Relay rewrites to source the signature is invalid. Otherwise, the Relay rewrites the source
address and port, changes the destination address and port to match address and port, and changes the destination address and port to
RELAY_TO information, recalculates transport checksum and forwards match RELAY_TO information. Finally, the Relay recalculates
the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [I-D.ietf-hip-base]. It replies with an I2 packet that according to [RFC5201]. It replies with an I2 packet that uses the
uses the destination transport address of R1 as the source address destination transport address of R1 as the source address and port.
and port. The I2 contains a LOCATOR parameter that lists all the ICE The I2 contains a LOCATOR parameter that lists all the ICE candidates
candidates (offer) of the Initiator. The candidates are encoded (ICE offer) of the Initiator. The candidates are encoded using the
using the format defined in Section 5.4. format defined in Section 4.5. The I2 packet MUST also contain the
NAT transform parameter with ICE-STUN-UDP or some other transform
selected because otherwise the Relay may drop the I2 packet.
In step 6, the Relay receives the I2 packet. The relay appends a In step 6, the Relay receives the I2 packet. The relay appends a
RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step. RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in the
second step.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [I-D.ietf-hip-base]. It replies with a R2 packet and according to [RFC5201]. It replies with a R2 packet and includes a
includes a RELAY_TO parameter as in step three. The R2 packet RELAY_TO parameter as explained in step three. The R2 packet
includes a LOCATOR parameter that lists all the ICE candidates includes a LOCATOR parameter that lists all the ICE candidates (ICE
(answer) of the Responder. The RELAY_TO parameter is protected by answer) of the Responder. The RELAY_TO parameter is protected by the
the HMAC. HMAC.
In step 8, the Relay processes the R2 as described in step four. The In step 8, the Relay processes the R2 as described in step four. The
Relay forwards the packet to the Responder. Relay forwards the packet to the Responder.
4. Connectivity Tests 3.4. ICE Connectivity Checks
4.1. NAT Transformation Negotiation
This section describes usage of a new optional transform parameter
type. The presence of the parameter in HIP base exchange means that
the host supports all of the extensions defined in this document. If
the transform parameter is used, hosts MUST use a password for STUN
HMACs that is drawn from the DH keying material.
The transform parameter applies both to the registration to the HIP
Relay as well as to a base exchange between end-hosts. The transform
negotiation in base exchange is illustrated in Figure 3.
Initiator Responder
| 1. UDP(I1) |
+------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..)) |
|<-------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) |
+------------------------------------------------------------->|
| |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<-------------------------------------------------------------+
| .... |
Figure 3: Negotiation of NAT Transforms The Responder completes the base exchange with the R2 packet through
the Relay. When Initiator successfully receives and processes the
R2, both hosts have transitioned to ESTABLISHED state. However, the
destination address the Initiator and Responder used for delivering
base exchange packets belonged to the Relay as indicated by the
RELAY_FROM and RELAY_TO parameters. Therefore, the address of the
Relay MUST not be used for sending ESP traffic unless it was listed
as a TURN server in the offer/answer. Instead, the Initiator and
Responder MUST start ICE connectivity tests after they have
transitioned to ESTABLISHED state after the base exchange when they
do not have valid locator pair for ESP traffic and the NAT transform
parameter was negotiated successfully.
In step 1, the Initiator sends an I1 to the Responder. In step 2, The ICE connectivity checks are defined in [I-D.ietf-mmusic-ice].
the Responder responds with an R1. The R1 contains a list of Section Section 4.2 defines the details of the STUN control packets.
transforms the Responder supports in NAT_TRANSFORM parameter as shown As a result of the ICE connectivity checks, ICE nominates a single
in Table 1. transport address pair to be used if an operational address could be
found. The end-hosts MUST use this address pair for the ESP traffic.
+--------------+----------------------------------------------------+ 3.5. NAT Keepalives
| Transform | Purpose |
| Type | |
+--------------+----------------------------------------------------+
| RESERVED | Reserved for future use |
| ICE-STUN-UDP | UDP encapsulated control and data traffic with |
| | ICE-based connectivity tests using STUN messages |
+--------------+----------------------------------------------------+
Table 1: Locator Transformations To prevent NAT state from expiring, communicating end-hosts hosts
send periodically keepalives to each other. NAT Relays MUST not send
any keepalives. An end-host MUST send keepalives every 15 seconds to
refresh the UDP port mapping at the NAT(s) when the control or data
channel is idle. To implement failure tolerance, an end-host SHOULD
have shorter keepalive period.
In step 3, the Initiator sends an I2 that includes a NAT_TRANSFORM The keepalives are STUN Binding Indications if the hosts have agreed
parameter. It contains the transform type selected by the Initiator on NAT_TRANSFORM during the base exchange, or HIP NOTIFY messages
from the list of transforms offered by the Responder. The I2 also otherwise. A HIP Relay MUST not forward NOTIFY messages.
includes the locators of the Initiator in a LOCATOR parameter.
In step 4, the Responder concludes the base exchange with an R2 The communicating hosts MUST send keepalives to each other using the
packet. The Responder includes a LOCATOR parameter in the R2 packet. transport locators exchanged in the base exchange when they are in
ESTABLISHED state. Also, the Initiator MUST send a NOTIFY message to
the Relay to refresh the NAT state alive on the path between the
Initiator and Relay when the Initiator has not received any response
to its I1 or I2 from the Responder in 15 seconds. The Relay MUST not
forward the NOTIFY messages.
4.2. ICE Procedure 3.6. Base Exchange without ICE Connectivity Checks
Hosts exchange HIP control packets through the HIP Relay. In certain network environments, the ICE connectivity checks can be
Connectivity tests are, however, directly exchanged between the omitted to reduce initial connection set up latency because base
address pairs to determine operational address pairs. If a working exchange acts an implicit connectivity test itself. There are three
direct path between the hosts is found, also the HIP control traffic assumptions about such as environments. First, the Responder should
MAY start using it. have a long-term, fixed locator in the network. Second, the
Responder should not have a HIP Relay configured for itself. Third,
the Initiator can reach the Responder by simply UDP encapsulating HIP
and ESP packets to the host. Detecting and configuring this
particular scenario is prone to administrative failure unless
carefully planned.
The base exchange is completed with an R2 packet. Then, the state of In such a scenario, the Initiator sends an I1 packet over UDP to the
the HIP associations at both peers is ESTABLISHED, but the peers MUST Responder. The Responder replies with a R1 packet that does not
NOT allow any ESP traffic until the connectivity tests are performed contain the NAT transform parameter. The Initiator receives the R1
successfully. All of the locators, except the HIP Relay address, are packet and determines from the absence of the NAT transform and
in UNVERIFIED state. In the connectivity tests, the hosts test RELAY_TO parameters that ICE connectivity checks can be omitted.
connectivity between different locator pairs in order to find a Finally, the hosts can start to use the locators from the concluding
working one. The connectivity tests are illustrated in Figure 4. In I2 and R2 packets of the base exchange for ESP without ICE
this example, both hosts are behind NATs. connectivity checks.
I HIP Relay R 3.7. Base Exchange without UDP Encapsulation
| 2. UDP(R2(LOCATOR,RELAY_TO)) | 1. UDP(R2(LOCATOR,RELAY_TO)) |
|<------------------------------+-------------------------------|
| |
| 3. Connectivity tests for address pairs |
|<------------------------------------------------------------->|
| |
| 4. HIP UPDATE for preferred address pair |
|<------------------------------------------------------------->|
| |
Figure 4: Connectivity tests The Initiator MAY also try to establish a base exchange with the
Responder without UDP encapsulation. In such a case, the Initiator
sends first an I1 packet without UDP encapsulation to the Responder.
After 100 ms, the Initiator MUST then send an UDP-encapsulated I1
packet. For retransmissions, the procedure is repeated.
In steps 1 and 2, the R2 packet is relayed from the Responder through The I1 packet may arrive directly at the Responder. When the
the Relay to the Initiator. recipient is the Responder, the proceduces in [RFC5201] are followed
for the rest of the base exchange. The Initiator may receive
multiple R1 messages from the Responder, but upon receiving a valid
R1 without UDP encapsulation, the Initiator MUST ignore further R1
messages with UDP encapsulation encapsulation. The end-hosts do not
trigger ICE connectivity checks after the base exchange since the UDP
encapsulation was excluded.
Afterwards, connectivity tests are started based on the procedure The packet may also arrive at a HIP-capable middlebox. When the
described in [I-D.rosenberg-mmusic-ice-nonsip] by using the candiates middlebox is a HIP rendezvous server and the Responder has
previously exchanged in the HIP base exchange. successfully registered to the rendezvous service, the middlebox
follows rendezvous procedures in [RFC5204]. If the middlebox is a
HIP Relay server, it drops the I1 packet silently.
4.3. NAT Keep-alives 3.8. Sending Control Messages using the Data Plane
Data channel keepalives are STUN Binding Indications. Keepalives The end-hosts MAY send control messages directly to each other using
MUST be sent every 20 seconds at the minimum when the channel is the transport address pair established for data channel without
idle. To implement failure tolerance, a host SHOULD have smaller sending the control packets through the Relay. When a host does not
keepalive period. When data traffic is exchanged between the end get acknowledgements e.g. to an UPDATE or CLOSE message after a
points then no further STUN keepalives need to be exchanged. timeout based on local policies, the host SHOULD resend the packet
through the Relay. This optimization requires further
experimentation.
5. Packet Formats 4. Packet Formats
The following subsections define the parameter and packet encodings. The following subsections define the parameter and packet encodings.
All values MUST be in network byte order. All values MUST be in network byte order.
5.1. HIP Control Packets 4.1. HIP Control Packets
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes | | 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format for UDP-encapsulated HIP Control Packets Figure 4: Format for UDP-encapsulated HIP Control Packets
HIP control packets are encapsulated in UDP packets like in Section HIP control packets are encapsulated in UDP packets as defined in
2.2 of [RFC3948], "rules for encapsulating IKE messages", except that Section 2.2 of [RFC3948], "rules for encapsulating IKE messages"
a different port number is used. Figure 5 shows the encapsulation: except for a different port number. Figure 4 illustrates the
UDP header is followed by 32 zero bits that can be used to encapsulation. The UDP header is followed by 32 zero bits that can
differentiate HIP control packets from ESP packets. The HIP header be used to differentiate HIP control packets from ESP packets. The
and parameters follow the conventions of [I-D.ietf-hip-base] with the HIP header and parameters follow the conventions of [RFC5201] with
exception that the HIP header checksum MUST be zero. The HIP header the exception that the HIP header checksum MUST be zero. The HIP
checksum is zero for two reasons. First, the UDP header contains header checksum is zero for two reasons. First, the UDP header
already a checksum. Second, the checksum definition in contains already a checksum. Second, the checksum definition in
[I-D.ietf-hip-base] includes the IP addresses in the checksum [RFC5201] includes the IP addresses in the checksum calculation. The
calculation. The NATs unaware of HIP cannot recompute the HIP NATs unaware of HIP cannot recompute the HIP checksum after changing
checksum after changing IP addresses. IP addresses.
A HIP Relay or a Responder without a relay MUST listen at transport A HIP Relay or a Responder without a relay MUST listen at transport
port HIPPORT for incoming UDP-encapsulated HIP control packets. port HIPPORT for incoming UDP-encapsulated HIP control packets.
5.2. Keep-Alives 4.2. Connectivity Checks
Control and data channel keep-alives are STUN Binding Indications, as The connectivity checks are performed using STUN Binding Requests.
defined in [I-D.ietf-behave-rfc3489bis]. They use the same UDP This section describes the details of the parameters in the STUN
header as the HIP control packets but there is no non-ESP-marker messages.
between the UDP header and the STUN header. STUN messages are
demultiplexed from ESP and HIP control messages using the STUN
markers, such as the magic cookie value.
5.3. Relay and Registration Parameters The username is formed from the username fragments as defined in
section 7.1.1.3 of [I-D.ietf-mmusic-ice]. The requests MUST use STUN
short term credentials with HITs of the Initiator and Responder
concatenated as a username fragment. The HITs are concatenated
according to the Sort(HIT-I, HIT-R) algorithm defined in [RFC5201]
section 6.5. The HIT username fragment MUST contain a UTF-8
[RFC3629] encoded sequence and MUST have been processed using
SASLPrep [RFC4013] as defined section 15.3 of
[I-D.ietf-behave-rfc3489bis]. The concatenated HIT pair MUST have a
fixed size that is accomplished by including the leading zeroes for
the HITs.
Drawing of HIP keys is defined in [RFC5201] section 6.5 and drawing
of ESP keys in [RFC5202] section 7. Correspondingly, the hosts MUST
draw symmetric keys for STUN according to [RFC5201] section 6.5. The
hosts draw the STUN keys after HIP keys, or after ESP keys if ESP
transform was successfully negotiated in the base exchange. The
hosts draw two keys which they MUST use to generate the STUN
password. As the STUN password is the same at both ends, the two
drawn keys MUST be concatenated with the key for the greater HIT
first. Section 15.4 of [I-D.ietf-behave-rfc3489bis] describes how
hosts use the password for message integrity of STUN messages.
The connectivity checks MUST contain PRIORITY attribute. They MAY
contain USE-CANDIDATE attributes as defined in section 7.1.1.1 of
[I-D.ietf-mmusic-ice].
The Initiator is always in the controller role during a base
exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes
are not needed and SHOULD NOT be used. When two hosts are initiating
to each other simultaneously, HIP state machine detects it and
assigns the host with the larger HIT as the Responder as explained in
sections 4.4.2 and and 6.7 in [RFC5201].
4.3. Keepalives
The keepalives for HIP associations agreed that are NAT_TRANSFORM
capable are STUN Binding Indications, as defined in
[I-D.ietf-behave-rfc3489bis]. The source and destination ports are
in the UDP header are the same as used for HIP (50500). However, in
contrast to the UDP encapsulated HIP header, there non-ESP-marker
between the UDP header and the STUN header is excluded. Keepalives
MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain
any other STUN attributes and SHOULD NOT utilize any authentication
mechanism. STUN messages are demultiplexed from ESP and HIP control
messages using the STUN markers, such as the magic cookie value and
the FINGERPRINT attribute.
Keepalives for aHIP associations that are not NAT_TRANSFORM capable
are HIP control messages that have NOTIFY as the packet type. The
NOTIFY messages do not contain any parameters.
4.4. Relay and Registration Parameters
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport | | Port | Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type [ TBD by IANA:
RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2)
REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ] REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ]
Length 20 Length 20
Address An IPv6 address or an IPv4 address in "IPv4-compatible Address An IPv6 address or an IPv4 address in "IPv4-compatible
IPv6 address" format IPv6 address" format
Port Transport port number; zero when plain IP is used Port Transport port number; zero when plain IP is used
Transport Transport protocol type; zero for UDP Transport Transport protocol type; zero for UDP
Figure 6: Format for the RELAY_FROM, RELAY_TO and REG_FROM Figure 5: Format for REG_FROM parameter
parameters 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of the RELAY_FROM, RELAY_TO and REG_FROM parameters is shown Type [ TBD by IANA:
in Figure 6. Parameters are identical except for the type field. Critical parameters:
RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2)
5.4. LOCATOR Parameter Length 24
Address An IPv6 address or an IPv4 address in "IPv4-compatible
IPv6 address" format
Port Transport port number; zero when plain IP is used
Transport Transport protocol type; zero for UDP
Nonce A nonce assigned by the Relay server.
The generic LOCATOR parameter format is the same as in Figure 6: Format for the RELAY_FROM and RELAY_TO parameters
[I-D.ietf-hip-mm]. However, presenting ICE candidates requires a new
locator type. The generic and NAT traversal specific locator Format for the REG_FROM parameter is shown in Figure 5, and
parameters are illustrated in Figure 7. RELAY_FROM and RELAY_TO in Figure 6. Parameters are identical except
for the type and nonce fields.
The nonce field is an experimental field for the RELAY_FROM and
RELAY_TO parameters. It allows the Relay to have constant state
towards the Initiators without allowing the Responder to send R1 or
R2 packets to arbitrary hosts through the Relay.
4.5. LOCATOR Parameter
The generic LOCATOR parameter format is the same as in [RFC5206].
However, presenting ICE candidates requires a new locator type. The
generic and NAT traversal specific locator parameters are illustrated
in Figure 7.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P| | Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 34 skipping to change at page 19, line 34
| Transport | 0 | 0 for UDP | | Transport | 0 | 0 for UDP |
| Protocol | | | | Protocol | | |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-mmusic-ice] | | | | [I-D.ietf-mmusic-ice] |
| SPI | Variable | SPI value which the host expects to see in | | SPI | Variable | SPI value which the host expects to see in |
| | | incoming ESP packets that use this locator | | | | incoming ESP packets that use this locator |
| Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 | | Locator | Variable | IPv6 address or an "IPv4-compatible IPv6 |
| | | address" format IPv4 address [RFC3513], | | | | address" format IPv4 address [RFC3513], |
| | | obfuscated by XORring it with the owner's | | | | obfuscated by XORing it with the owner's |
| | | HIT | | | | HIT |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR parameter Table 2: Fields of the LOCATOR parameter
5.5. RELAY_HMAC 4.6. RELAY_HMAC
The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
2^4). It has the same semantics as RVS_HMAC [I-D.ietf-hip-rvs]. 2^4). It has the same semantics as RVS_HMAC [RFC5204].
5.6. Registration Types 4.7. Registration Types
The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contain
values for HIP Relay registration. The value for RELAY_UDP_HIP is 2. values for HIP Relay registration. The value for RELAY_UDP_HIP is 2.
The value for RELAY_UDP_ESP is 3. The value for RELAY_UDP_ESP is 3.
5.7. HIP ESP Data Packet Formats 4.8. ESP Data Packets
[RFC3948] describes UDP encapsulation of the IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. On the wire the HIP ESP packets do not differ from the tunnel mode. On the wire, the HIP ESP packets do not differ from the
transport mode ESP and thus the encapsulation of the HIP ESP packets transport mode ESP and thus the encapsulation of the HIP ESP packets
is same as the UDP encapsulation transport mode ESP. is same as the UDP encapsulation transport mode ESP. However, the
(semantic) difference to BEET mode ESP packets used by HIP is that IP
header is not used in BEET integrity protection calculation.
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations enable them to define a pair of IPsec ESP security associations (SAs)
(SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a as described in [RFC5202]. When two peers perform a UDP-encapsulated
UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs base exchange, they MUST define a pair of IPsec SAs that produces
that produces UDP-encapsulated ESP data traffic. UDP-encapsulated ESP data traffic.
The management of encryption/authentication protocols and security
parameter indices (SPIs) is defined in [I-D.ietf-hip-esp]. The UDP
encapsulation format and processing of HIP ESP traffic is described
in Section 6.1 of [I-D.ietf-hip-esp].
Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP The management of encryption/authentication protocols and SPIs is
transport format because the Responder use HITs to distinguish defined in [RFC5202]. The UDP encapsulation format and processing of
between different communication instances. HIP ESP traffic is described in Section 6.1 of [RFC5202].
6. Security Considerations 5. Security Considerations
6.1. Privacy Considerations 5.1. Privacy Considerations
The LOCATORs are sent XORed format in plain text in favour of The locators are in XORed format in plain text in favor of inspection
inspection at HIP-aware middleboxes in the future. The current draft at HIP-aware middleboxes in the future. The current draft does not
does not specify encrypted versions of LOCATORs even though it could specify encrypted versions of LOCATORs even though it could be
be beneficial for privacy reasons. beneficial for privacy reasons.
It is possible that an Initiator or Responder may not want to reveal It is possible that an Initiator or Responder may not want to reveal
all of its locators to its peer. For example, a host may not want to all of its locators to its peer. For example, a host may not want to
reveal the internal topology of the private address realm and it reveal the internal topology of the private address realm and it
discards host addresses. Such behavior creates non-optimal paths discards host addresses. Such behavior creates non-optimal paths
when the hosts are located behind the same NAT. Especially, this when the hosts are located behind the same NAT. Especially, this
could be a problem with a legacy NAT that does not support routing could be a problem with a legacy NAT that does not support routing
from the private address realm back to itself through the outer from the private address realm back to itself through the outer
address of the NAT. This scenario is referred to as the hairpin address of the NAT. This scenario is referred to as the hairpin
problem [I-D.ietf-behave-p2p-state]. With such a legacy NAT, the problem [RFC5128]. With such a legacy NAT, the only option left
only option left would be to use a relayed transport address from a would be to use a relayed transport address from a TURN server.
TURN server. As a consequence, a host may support locator-based
privacy by leaving out the reflexive candidates. Using only host
candidates can produce suboptimal paths possibly causing congestion.
The use of HIP Relays or TURN Relays can be useful for protection As a consequence, a host may support locator-based privacy by leaving
against Denial-of-Service attacks. If a Responder reveals only its out the reflexive candidates. However, the trade-off in using only
HIP and ESP relay candidates to malign Initiators, the Initiators can host candidates can produce suboptimal paths that can congest the
only attack the relays that does not prevent the Responder from TURN server. The use of HIP Relays or TURN Relays can be useful for
initiating new outgoing connections if a path around the relay protection against Denial-of-Service attacks. If a Responder reveals
exists. only its HIP Relay addresses and Relayed transport candidates to
Initiators, the Initiators can only attack the relays that does not
prevent the Responder from initiating new outgoing connections if a
path around the relay exists.
6.2. Opportunistic Mode 5.2. Opportunistic Mode
A HIP Relay should have one address per Relay Client when a HIP Relay A HIP Relay server should have one address per Relay Client when a
is serving more than one Relay Clients and is willing to support HIP Relay is serving more than one Relay Clients and supports
opportunistic mode. Otherwise, it cannot be guaranteed that the opportunistic mode. Otherwise, it cannot be guaranteed that the
Relay can deliver the I1 packet to the intended recipient. Relay can deliver the I1 packet to the intended recipient.
7. IANA Considerations 5.3. Base Exchange Replay Protection for HIP Relay Server
On certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a Relay server
by masquerading as the original Initiator and Responder. The attack
does not require the attacker(s) to compromise the private key(s) of
the attacked host(s). However, Responder has to be disconnected from
the Relay in order to masquarade successfully as the Responder.
The Relay can protect itself against Replay attacks by involving in
the base exchange by introducing nonces that the end-hosts (Initiator
and Responder) have to sign. The Relay MAY add ECHO_REQUEST_M
parameters to the R1 and I2 messages as described in
[I-D.heer-hip-middle-auth] and drops the I2 or R2 messages if the
corresponding ECHO_RESPONSE_M parameters are not present.
5.4. Demuxing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder use HITs to distinguish
between different Initiators.
6. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
This draft currently uses a UDP port in the "Dynamic and/or Private This draft currently uses a UDP port in the "Dynamic and/or Private
Port" and HIPPORT. Upon publication of this document, IANA is Port" and HIPPORT. Upon publication of this document, IANA is
requested to register a UDP port and the RFC editor is requested to requested to register a UDP port and the RFC editor is requested to
change all occurrences of port HIPPORT to the port IANA has change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial registered. The HIPPORT number 50500 should be used for initial
experimentation. experimentation.
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA Registry for HIP Parameter Types by
assigning new HIP Parameter Type values for the new HIP Parameters: assigning new HIP Parameter Type values for the new HIP Parameters:
RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 5.3) and RELAY_FROM, RELAY_TO and REG_FROM (defined in Section 4.4) and
RELAY_HMAC (defined in Section 5.5). RELAY_HMAC (defined in Section 4.6). NAT_TRANSFORM is also a new
parameter.
8. Contributors 7. Contributors
Marcelo Bagnulo, Jan Melen, Simon Schuetz, Martin Stiemerling, Lars This draft is a product of a design team which also included Marcelo
Eggert, Vivien Schmitt, Abhinav Pathak and Andrei Gurtov have Bagnulo and Jan Melen who both have made major contributions to this
contributed to the initial versions of this draft. document.
9. Acknowlegements 8. Acknowledgments
Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for
the excellent work on ICE. In addition, the authors would like to the excellent work on ICE. In addition, the authors would like to
thank Andrei Gurtov, Tobias Heer, Teemu Koponen, Juhana Mattila, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne Vivien Schmitt, Abhinav Pathak for their contributions and Tobias
Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas
Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Hannes Tschofenig, Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri
Jan Melen, Jani Hautakorpi and Ari Keraenen For their comments on Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu
this document. Varjonen, Dan Wing and Jani Hautakorpi for their comments on this
document.
Miika Komu is working in the Networking Research group at Helsinki Miika Komu is working in the Networking Research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project Institute for Information Technology (HIIT). The InfraHIP project
was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
Forces, and Ericsson and Birdstep. Forces, and Ericsson and Birdstep.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress), draft-ietf-behave-rfc3489bis-16 (work in progress),
February 2008. July 2008.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-06 (work in progress), draft-ietf-behave-turn-08 (work in progress), June 2008.
January 2008.
[I-D.ietf-hip-base]
Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007.
[I-D.ietf-hip-esp]
Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-06 (work in progress), June 2007.
[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007.
[I-D.ietf-hip-registration]
Laganier, J., "Host Identity Protocol (HIP) Registration
Extension", draft-ietf-hip-registration-02 (work in
progress), June 2006.
[I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), June 2006.
[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.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "NICE: Non Session Initiation Protocol Rosenberg, J., "NICE: Non Session Initiation Protocol
(SIP) usage of Interactive Connectivity Establishment (SIP) usage of Interactive Connectivity Establishment
skipping to change at page 20, line 32 skipping to change at page 23, line 28
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
10.2. Informative References [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[I-D.ietf-behave-p2p-state] [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Encapsulating Security Payload (ESP) Transport Format with
Peer(P2P) Communication Across Network Address the Host Identity Protocol (HIP)", RFC 5202, April 2008.
Translators(NATs)", draft-ietf-behave-p2p-state-06 (work
in progress), November 2007. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203,
April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
9.2. Informative References
[I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-01 (work in progress),
July 2008.
[I-D.irtf-hiprg-nat] [I-D.irtf-hiprg-nat]
Stiemerling, M., "NAT and Firewall Traversal Issues of Stiemerling, M., "NAT and Firewall Traversal Issues of
Host Identity Protocol (HIP) Communication", Host Identity Protocol (HIP) Communication",
draft-irtf-hiprg-nat-04 (work in progress), March 2007. draft-irtf-hiprg-nat-04 (work in progress), March 2007.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
Appendix A. Firewall Traversal [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
This section describes firewall traversal issues separately from NAT Translators (NATs)", RFC 5128, March 2008.
issues. When the Initiator or the Responder of a HIP association is
behind a firewall, additional issues arise. The firewall discussion
applies both to IPv4 and IPv6 addressing.
The NAT traversal mechanisms described in this document require that
the firewall - stateful or not - allows UDP traffic. At the minimum,
successful firewall control packet traversal requires that the host
behind the firewall is allowed to communicate packets with a HIP
Relay (or a Responder without HIP Relay) that is listening on UDP
port HIPPORT. Successful ESP data packet traversal requires the same
for the TURN server. For unrelayed traffic, the destination port
HIPPORT should be open at the firewall to all hosts behind the
firewall.
Most firewall implementations support "UDP connection tracking",
i.e., after a host behind a firewall has initiated UDP communication
to the public Internet, the firewall accepts UDP response traffic in
the return direction. If no such return traffic arrives for a
specific period of time, the firewall stops accepting the given IP
address and port pair. The mechanisms described in this document
already enable traversal of such firewalls, if the keep-alive
interval used is less than the refresh interval of the firewall.
When the Initiator is behind a firewall, the NAT traversal mechanisms
described in this document depend on the ability to initiate
communication via UDP to the destination port HIPPORT from arbitrary
source ports and to receive UDP response traffic from that port to
the chosen source port. If the Initiator is behind a firewall that
does not support "UDP connection tracking", the NAT traversal
mechanisms described in this document can still be supported, if the
firewall allows permanently inbound UDP traffic from the port HIPPORT
and destined to arbitrary source IP addresses and UDP ports.
When the Responder is behind a firewall, the NAT traversal mechanisms
described in this document depend on the ability to send and receive
UDP traffic originating from HIPPORT of the HIP Relays and TURN
servers. When end-to-end traffic is preferred, arbitrary source IP
addresses and ports are required.
Appendix B. Base Exchange without ICE Connectivity Checks
In certain network environments, the ICE connectivity tests can be
omitted to reduce initial connection set up latency because base
exchange acts an implicit connectivity test itself. There are three
assumptions about such as environments. First, the Responder should
have a long-term, fixed locator in the network. Second, the
Responder should not have a HIP Relay configured for itself. Third,
the Initiator can reach the Responder by simply UDP encapsulating HIP
and ESP packets to the host. Detecting and configuring this
particular scenario is prone administrative failure unless carefully
planned.
In such a scenario, the Initiator sends an I1 packet over UDP to the
Responder. The Responder replies with a R1 packet that does not
contain the transform parameter as explained in Section 4.1. The
Initiator receives the R1 packet and determines from the absence of
the transform and RELAY_TO parameters that ICE connectivity tests can
be omitted with the Responder. Finally, the hosts set up IPsec
security associations using the locators observed from the concluding
I2 and R2 packets of the base exchange without ICE connectivity
tests.
Appendix C. IPv4-IPv6 Interoperability Appendix A. IPv4-IPv6 Interoperability
Currently Relay Client and Server do not have to run any ICE Currently Relay Client and Server do not have to run any ICE
connectivity tests as described in Appendix B. However, it could be connectivity tests as described in Section 3.6. However, it could be
useful for IPv4-IPv6 interoperability when the Relay Server actually useful for IPv4-IPv6 interoperability when the Relay Server actually
includes both the NAT transform parameter and multiple locators in includes both the NAT transform parameter and multiple locators in
R2. The interoperability benefit is that the Relay could support R2. The interoperability benefit is that the Relay could support
IPv4-based Initiators and IPv6-based Responders by converting the IPv4-based Initiators and IPv6-based Responders by converting the
network headers and recalculating UDP checksums. network headers and recalculating UDP checksums.
Such an approach is underspecified in this document currently. It is Such an approach is underspecified in this document currently. It is
not yet recommended because it may consume resources at the Relay and not yet recommended because it may consume resources at the Relay and
requires also similar conversion support at the TURN relay for data requires also similar conversion support at the TURN relay for data
packets. packets.
Appendix D. Base Exchange through a Rendezvous Server Appendix B. Base Exchange through a Rendezvous Server
This section describes handling for a scenario where Initiator looks This section describes handling for a scenario where Initiator looks
up the information of the Responder from DNS and discovers a RVS up the information of the Responder from DNS and discovers a RVS
record [I-D.ietf-hip-rvs]. In such a case, the Initiator uses its record [RFC5204]. In such a case, the Initiator uses its own HIP
own HIP Relay to forward HIP traffic to the Rendezvous server. The Relay to forward HIP traffic to the Rendezvous server. The Initiator
Initiator will send the I1 message using the its HIP Relay server will send the I1 message using the its HIP Relay server which will
which will then forward it to the RVS server of the responder. The then forward it to the RVS server of the responder. The responder
responder will send the R1 packet directly to the Initiator's HIP will send the R1 packet directly to the Initiator's HIP Relay server
Relay server and the following I2 and R2 packets are also sent and the following I2 and R2 packets are also sent directly using the
directly using the Relay. Relay.
In case the Initiator is not able to distinguish which records are In case the Initiator is not able to distinguish which records are
RVS address records and which are Responders address records, then RVS address records and which are Responders address records, then
the Initiator SHOULD first try to contact the Responder directly and the Initiator SHOULD first try to contact the Responder directly and
if none of the addresses is reachable it MAY try out them using its if none of the addresses is reachable it MAY try out them using its
own HIP Relay as described in the above. own HIP Relay as described in the above.
Appendix E. Document Revision History Appendix C. Document Revision History
To be removed upon publication To be removed upon publication
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| draft-ietf-nat-traversal-00 | Initial version. | | draft-ietf-nat-traversal-00 | Initial version. |
| draft-ietf-nat-traversal-01 | Draft based on RVS. | | draft-ietf-nat-traversal-01 | Draft based on RVS. |
| draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and |
| | ICE concepts. | | | ICE concepts. |
| draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. |
| draft-ietf-nat-traversal-04 | Issues 25-27,29-36 |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
skipping to change at page 24, line 13 skipping to change at page 26, line 13
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Thomas Henderson Thomas Henderson
The Boeing Company The Boeing Company
P.O. Box 3707 P.O. Box 3707
Seattle, WA Seattle, WA
USA USA
Email: thomas.r.henderson@boeing.com Email: thomas.r.henderson@boeing.com
Philip Matthews Philip Matthews
Avaya (Unaffiliated)
100 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 224
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Ari Keraenen Ari Keraenen (editor)
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Phone: +358 9 2991 Phone: +358 9 2991
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Jan Melen
Ericsson Research Nomadiclab
Hirsalantie 11
02420 Jorvas
Finland
Phone: +358 9 2991
Email: jan.melen@ericsson.com
Marcelo Bagnulo
Huawei Lab at UC3M
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 26, line 44 skipping to change at line 1189
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 123 change blocks. 
512 lines changed or deleted 594 lines changed or added

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