One document matched: draft-ietf-hip-nat-traversal-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc strict="no"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<!--<?rfc rfcedstyle="yes"?>-->
<?rfc sortrefs="yes" ?>
<!-- $Id: draft-hip-nat-base.xml,v 1.47 2008/02/25 17:41:24 mkomu Exp $ -->
<rfc category="exp" ipr="full3978" docName="draft-ietf-hip-nat-traversal-03.txt">
<front>
<title abbrev="Basic NAT and Firewall Traversal for HIP">Basic HIP Extensions for Traversal of
Network Address Translators and Firewalls</title>
<author fullname="Miika Komu" initials="M.K.T." surname="Komu">
<organization abbrev="HIIT">Helsinki Institute for Information Technology</organization>
<address>
<postal>
<street>Metsanneidonkuja 4</street>
<city>Espoo</city>
<country>Finland</country>
</postal>
<phone>+358503841531</phone>
<facsimile>+35896949768</facsimile>
<email>miika@iki.fi</email>
<uri>http://www.hiit.fi/</uri>
</address>
</author>
<author initials="T." fullname="Thomas Henderson" surname="Henderson">
<organization>The Boeing Company</organization>
<address>
<postal>
<street>P.O. Box 3707</street>
<city>Seattle, WA</city>
<country>USA</country>
</postal>
<email>thomas.r.henderson@boeing.com</email>
</address>
</author>
<author initials="P." fullname="Philip Matthews" surname="Matthews">
<organization>Avaya</organization>
<address>
<postal>
<street>100 Innovation Drive</street>
<city>Ottawa, Ontario K2K 3G7</city>
<country>Canada</country>
</postal>
<phone>+1 613 592 4343 224</phone>
<email>philip_matthews@magma.ca</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<author initials="A." fullname="Ari Keränen" surname="Keränen">
<organization>Ericsson Research Nomadiclab</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>02420 Jorvas</city>
<country>Finland</country>
</postal>
<phone>+358 9 2991</phone>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<author initials="J." fullname="Jan Melén" surname="Melén">
<organization>Ericsson Research Nomadiclab</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>02420 Jorvas</city>
<country>Finland</country>
</postal>
<phone>+358 9 2991</phone>
<email>jan.melen@ericsson.com</email>
</address>
</author>
<author initials="M." fullname="Marcelo Bagnulo" surname="Bagnulo">
<organization>Huawei Lab at UC3M</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes, Madrid 28911</city>
<country>Spain</country>
</postal>
<phone>34 91 6249500</phone>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/</uri>
</address>
</author>
<date year="2008"/>
<area>Internet</area>
<workgroup>HIP Working Group</workgroup>
<keyword>HIP</keyword>
<keyword>host identity protocol</keyword>
<keyword>host identity payload</keyword>
<keyword>NAT traversal</keyword>
<keyword>NAT traversal</keyword>
<abstract>
<t> The Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely
identifying hosts. Existing HIP experimental specifications do not specify protocol
operations across Network Address Translators (NATs).</t>
<t> This document specifies NAT traversal extensions for HIP. The HIP shim layer is located
between the network and transport layer, the extensions can also provide a more
general-purpose NAT traversal support for higher-layer networking applications. The
extensions are based on the use of the The Interactive Connectivity Establishment (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. </t>
</abstract>
</front>
<middle>
<!-- ************************************************************************************************** -->
<section title="Introduction" anchor="sec:intro">
<t> HIP <xref target="I-D.ietf-hip-base"/> is defined as a protocol that runs directly over
IPv4 or IPv6. This approach is known to have problems traversing NATs. Several different
types of NATs exist, see <xref target="RFC2663"/>. This document describes HIP
extensions for the traversal of both Network Address Translator (NAT) and Network
Address and Port Translator (NAPT) middleboxes. Additionally, it covers firewalls to a
certain extend (see <xref target="firewalls"/> for a more detailed discussion). The
document generally uses the term NAT to refer to these types of middleboxes. A detailed
description of HIP problems with traversing legacy middleboxes is documented in <xref
target="I-D.irtf-hiprg-nat"/>. </t>
<t> NAT devices do not operate consistently even though a recommended behavior is described
in <xref target="RFC4787"/>. The HIP protocol extensions in this document make as few
assumptions as possible about the behavior of the NAT devices so that NAT traversal will
work even with legacy NAT devices. The purpose of these extensions is to allow two
HIP-enabled hosts to communicate with each other even if one or both communicating hosts
are in private address realms. With some legacy NAT devices, utilizing the shortest path
between two end hosts located behind NATs is not possible without relaying the traffic
through a relay, such as a TURN server <xref target="I-D.ietf-behave-p2p-state"/>. As a
consequence, the TURN server increases the roundtrip delay and may become a point of
network congestion. With the extensions described in this document, hosts try to avoid
the use of such a relay when possible. </t>
<t> A distinction must be made between a HIP rendezvous server (defined in <xref
target="I-D.ietf-hip-rvs"/>) and a HIP Relay, defined herein. HIP rendezvous servers
solve initial contact and mobility related problems in networks without NATs. HIP Relay
solve the same problems, in addition to NAT traversal problems. HIP Relay servers can be
used both in NATted and non-NATted networks. </t>
<!-- XX FIXME: replace p2p-unfriendly NAT with something else -->
<t> Both rendezvous and relay services forward HIP control packets, but the main difference
is that the rendezvous service forwards only the initial I1 packet of the base exchange
while all other HIP control packets are sent directly between the communicating hosts.
In contrast, the relay service relays all HIP control packets because p2p-unfriendly NAT
devices drop the packets otherwise <xref target="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. </t>
<t> The basis for the connectivity tests is ICE <xref target="I-D.ietf-mmusic-ice"/>. </t>
<t><xref target="I-D.ietf-mmusic-ice"/> describes ICE as follows: </t>
<t>
<list style="empty">
<t>"The Interactive Connectivity Establishment (ICE) methodology is a technique for
NAT traversal for UDP-based media streams (though ICE can be extended to handle
other transport protocols, such as TCP) established by the offer/answer model. ICE
is an extension to the offer/answer model, and works by including a multiplicity
of IP addresses and ports in SDP offers and answers, which are then tested for
connectivity by peer-to-peer connectivity checks. The IP addresses and ports
included in the SDP and the connectivity checks are performed using the revised
STUN specification <xref target="I-D.ietf-behave-rfc3489bis"/>, now renamed to
Session Traversal Utilities for NAT." </t>
</list>
</t>
<t> ICE for SIP is specified in <xref target="I-D.ietf-mmusic-ice"/> and ICE for non-SIP
protocols is specified in <xref target="I-D.rosenberg-mmusic-ice-nonsip"/>. </t>
<t> Two hosts communicate their peer address set (typically consisting of IP address and
port number pairs) to each other in the HIP base exchange. They are then paired with the
locally operational address of the other end point and prioritized according to some
policy. These address sets are then tested sequentially based on the procedure specified
in ICE. Both sides participate in the connectivity tests. The tests also determine
whether operational address pairs and select the preferred address pair to be used for
subsequent communication.</t>
<t>As a summary, the extensions in this document </t>
<t>
<list style="symbols">
<t>illustrate how to encapsulate HIP packets in UDP</t>
<t>refer to the UDP encapsulation of IPsec ESP packets defined in Section 2.1 of RFC
3948 <xref target="RFC3948"/>
</t>
<t>define how a node interacts with a HIP rendezvous server (defined in <xref
target="I-D.ietf-hip-rvs"/>) when middleboxes are present </t>
<t>describe a methodology to determine operational address pairs between two end
hosts based on ICE.</t>
</list>
</t>
</section>
<!-- ************************************************************************************************** -->
<section title="Terminology">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>. </t>
<t>This document borrows terminology from <xref target="I-D.ietf-hip-base"/>, <xref
target="I-D.ietf-hip-mm"/>, <xref target="RFC4423"/>, <xref
target="I-D.ietf-mmusic-ice"/>, and <xref target="I-D.ietf-behave-rfc3489bis"/>.
Additionally, the following terms are used:</t>
<t>
<list style="hanging">
<t hangText="
Rendezvous server:"><vspace blankLines="1"/> A host
that forwards I1 packets to the Responder<vspace blankLines="1"/></t>
<t hangText="HIP Relay:"><vspace blankLines="1"/> A host that forwards all HIP
control packets between an Initiator and Responder<vspace blankLines="1"/></t>
<t hangText="TURN server:"><vspace blankLines="1"/> A server that forwards data
traffic between two end-hosts<vspace blankLines="1"/></t>
<t hangText="Locator:"><vspace blankLines="1"/> A name that controls how the packet
is routed through the network and demultiplexed by the end host. It may include a
concatenation of traditional network addresses such as an IPv6 address and
end-to-end identifiers such as an ESP SPI. It may also include transport port
numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a
network address. <xref target="I-D.ietf-hip-mm"/> "Address" is used in this
document as a synonym for locator.<vspace blankLines="1"/>
</t>
<t hangText="Transport address:"><vspace blankLines="1"/> Transport layer port and
the corresponding IPv4/v6 address<vspace blankLines="1"/></t>
<t hangText="Candidate:"><vspace blankLines="1"/> A transport address that has not
been verified yet for reachability using ICE<vspace blankLines="1"/></t>
<t hangText="Host candidate:"><vspace blankLines="1"/> An IPv4 or IPv6 address of a
network interface of a host<vspace blankLines="1"/></t>
<t hangText="Server reflexive transport candidate:"><vspace blankLines="1"/> A
translated transport address of a host as observed by a HIP Relay or a STUN server<vspace
blankLines="1"/></t>
<t hangText="Peer reflexive transport candidate:"><vspace blankLines="1"/> A
translated transport address of a host as observed by its peer<vspace
blankLines="1"/></t>
<t hangText="Relayed transport candidate:"><vspace blankLines="1"/> A transport
address that exists on a TURN server. If a permission exists, packets that arrive
at this address are relayed towards the TURN client. </t>
</list>
</t>
</section>
<!-- Terminology -->
<!-- ************************************************************************************************** -->
<section anchor="sec:protocol" title="Protocol Description">
<t> This section describes the normative behavior of the protocol extension. Examples of
packet exchanges are provided for illustration purposes.</t>
<!-- XX FIXME: Philip suggested: I think we want a figure that illustrates how things work. See
for example figure 1 in the TURN spec -->
<section anchor="sec:registration" title="Relay Registration and NAT Detection">
<t> HIP rendezvous servers are used in non-NATted environments and their use is
described in <xref target="I-D.ietf-hip-rvs"/>. This section specifies a new role for
these rendezvous servers to act as HIP Relays. HIP Relays forward HIP control packets
between the Initiator and the Responder. TURN servers <xref
target="I-D.ietf-behave-turn"/> are used for relaying ESP 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. </t>
<t> A HIP relay forwards UDP-encapsulated HIP traffic, and in future extensions, a relay
may also forward TCP-encapsulated traffic. The HIP Relay forwards HIP control
packets. <!-- It MAY also forward ESP traffic. --> NAT traversal for HIP between two
end-hosts may require the use of relays in certain scenarios. A successful NAT
traversal therefore requires at least the Responder located behind a NAT to register
with a HIP Relay.
<!--
A host acting as a Responder in
a private address realm SHOULD use a HIP Relay for NAT traversal. It is
RECOMMENDED that the Responder uses also a TURN server to guarantee successful
NAT traversal with p2p-unfriendly NAT devices. -->
</t>
<t> A HIP Relay MUST silently drop packets to a HIP Relay Client that has not previously
registered with the HIP Relay. The registration process follows the generic
registration extensions defined in <xref target="I-D.ietf-hip-registration"/> and is
illustrated in <xref target="fig:reg"/>. </t>
<figure anchor="fig:reg" title="Example Registration to a HIP Relay">
<artwork align="center"><![CDATA[
HIP HIP
Relay Relay
Client Server
| 1. UDP(I1) |
+------------------------------------------------------->|
| |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+
| |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->|
| |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+
]]></artwork>
</figure>
<!-- The registration
is piggybacked to a base exchange, but it can be done also using HIP UPDATE
control packets as described in <xref target="I-D.ietf-hip-registration"/>. </t>
-->
<t> In step 1, the Initiator starts the registration procedure by sending an I1 packet
over UDP. It is RECOMMENDED that the Initiator selects a random port number from the ephemeral
port range 49152-65535 for initiating a base exchange. However, the allocated port
MUST be maintained until all of the corresponding HIP Associations are closed.
Alternatively, a host MAY also use a single fixed port for initiating all outgoing
connections. </t>
<t> In step 2, the Responder lists the services that it supports in the R1 packet. The
support for HIP-over-UDP relaying is denoted by the RELAY_UDP_HIP value. The R1 does not contain any
NAT transform parameter (see <xref target="sec:nat_transform" />)
as discussed in <xref target="sec:no_relay" />.</t>
<t> In step 3, the Initiator selects the services it registers for and lists them in the
REG_REQ parameter. In this example, the Initiator registers for HIP Relay service. </t>
<t>In step 4, the Responder concludes the registration procedure with an R2 packet and
acknowledges the registered services in the REG_RES parameter. The Responder may also
denote unsuccessful registrations in the REG_FAILED parameter in R2. The Responder
also includes a REG_FROM parameter that contains the transport address of the client
as observed by the Relay (Server Reflexive candidate). After the registration, the
Initiator needs to send periodically NAT keep-alives. </t>
<t> There are different ways for an Initiator to learn it's publically visible IP
address and port that are referred to as the "server reflexive transport candidate"
in this document. This document makes use of two ways:</t>
<t>
<list style="symbols">
<t>The Relay client may use STUN servers to detect the server reflexive locator,
as described in <xref target="I-D.ietf-behave-p2p-state"/>. </t>
<t>Alternatively, the Relay Client can learn it from the REG_FROM parameter when
registering to a Relay.</t>
</list>
</t>
</section>
<!-- relay and nat reg -->
<section title="Base Exchange via HIP Relay">
<t> It is RECOMMENDED that the Initiator sends an I1 packet encapsulated 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 R1 packet over the transport layer and using the
same transport protocol. The rest of the base exchange, I2 and R2, MUST also use the
same transport layer.</t>
<figure anchor="fig:bex" title="Base Exchange via a HIP Relay">
<artwork align="center"><![CDATA[
I HIP Relay R
| 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(R1(RELAY_TO)) |
| 4. UDP(R1(RELAY_TO)) |<-------------------------------+
|<-----------------------------+ |
| | |
| 5. UDP(I2(LOCATOR)) | |
+----------------------------->| |
| | 6. UDP(I2(LOCATOR,RELAY_FROM)) |
| +------------------------------->|
| | |
| | 7. UDP(R2(LOCATOR,RELAY_TO)) |
| 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-----------------------------+ |
| | |
]]></artwork>
</figure>
<t> In step 1 of <xref target="fig:bex"/>, the Initiator sends an I1 packet over the
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 referred as "host candidates"
in this document. </t>
<t> In step 2, the HIP Relay receives the I1 packet at port HIPPORT. If the destination
HIT belongs to a registered Responder, the Relay processes the packet. Otherwise, the
Relay MUST drop the 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 observed
by the Relay. The Relay protects the I1 packet with RELAY_HMAC as described in <xref
target="I-D.ietf-hip-rvs"/>, except that the parameter type is different. The
Relay changes the source and destination ports and IP addresses of the packet to
match the values the Responder used when registering to the Relay, i.e., the reverse
of the R2 used in the registration. The Relay MUST recalculate the transport checksum
and forward the packet to the Responder.</t>
<t> In step 3, the Responder receives the I1 packet. The Responder processes it
according to the rules in <xref target="I-D.ietf-hip-base"/>. In addition, the
Responder validates the RELAY_HMAC according to <xref target="I-D.ietf-hip-rvs"/> and
silenty drops the packet if the validation fails. The Responder replies with an R1
packet to which it includes a RELAY_TO parameter. The RELAY_TO parameter contains
same information as the RELAY_FROM parameter, i.e., Initiator transport address, but
the type of the parameter is different. The RELAY_TO parameter is not integrity
protected by the signature of the R1 to allow pre-created R1 packets at the
Responder. </t>
<t> In step 4, the Relay receives the R1 packet. The Relay drops the 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 signature is invalid. Otherwise, the Relay rewrites
to source address and port, changes the destination address and port to match
RELAY_TO information, recalculates transport checksum and forwards the packet. </t>
<t> In step 5, the Initiator receives the R1 packet and processes it according to <xref
target="I-D.ietf-hip-base"/>. It replies with an I2 packet that uses the
destination transport address of R1 as the source address and port. The I2 contains a
LOCATOR parameter that lists all the ICE candidates (offer) of the Initiator.
The candidates are encoded using the format defined in
<xref target="sec:locator_format"/>.</t>
<t> 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. </t>
<t> In step 7, the Responder receives the I2 packet and processes it according to <xref
target="I-D.ietf-hip-base"/>. It replies with a R2 packet and includes a RELAY_TO
parameter as in step three. The R2 packet includes a LOCATOR parameter that lists all
the ICE candidates (answer) of the Responder. The RELAY_TO parameter is protected by the HMAC. </t>
<t> In step 8, the Relay processes the R2 as described in step four. The Relay forwards
the packet to the Responder. </t>
</section>
</section>
<!-- ************************************************************************************************** -->
<section title="Connectivity Tests" anchor="sec:connectivity">
<section anchor="sec:nat_transform" title="NAT Transformation Negotiation">
<t> 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.
<!-- TODO: this still needs a definition on how to draw the password --> </t>
<t> 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 <xref target="fig:nat_transform"/>. </t>
<figure anchor="fig:nat_transform" title="Negotiation of NAT Transforms">
<artwork align="center"><![CDATA[
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, ..)) |
|<-------------------------------------------------------------+
| .... |
]]></artwork>
</figure>
<t> 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 <xref target="tbl:locator_transform"/>. </t>
<texttable anchor="tbl:locator_transform" title="Locator Transformations">
<ttcol align="left">Transform Type</ttcol>
<ttcol align="left">Purpose</ttcol>
<c>RESERVED</c>
<c>Reserved for future use</c>
<c>ICE-STUN-UDP</c>
<c>UDP encapsulated control and data traffic with ICE-based connectivity tests using
STUN messages</c>
</texttable>
<t> 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. </t>
<t> In step 4, the Responder concludes the base exchange with an R2 packet. The
Responder includes a LOCATOR parameter in the R2 packet. </t>
</section>
<section title="ICE Procedure">
<t> Hosts exchange HIP control packets through the HIP Relay. Connectivity tests
are, however, directly exchanged between the address pairs to determine operational
address pairs. If a working direct path between the hosts is found, also the HIP
control traffic MAY start using it.</t>
<t> The base exchange is completed with an R2 packet. Then, the state of the HIP
associations at both peers is ESTABLISHED, but the peers MUST NOT allow any ESP
traffic until the connectivity tests are performed successfully. All of the locators,
except the HIP Relay address, are in UNVERIFIED state. In the connectivity tests, the
hosts test connectivity between different locator pairs in order to find a working
one. The connectivity tests are illustrated in <xref target="fig:connectivity"/>. In
this example, both hosts are behind NATs. </t>
<figure anchor="fig:connectivity" title="Connectivity tests">
<artwork align="center"><![CDATA[
I HIP Relay R
| 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 |
|<------------------------------------------------------------->|
| |
]]></artwork>
</figure>
<t> In steps 1 and 2, the R2 packet is relayed from the Responder through the Relay to
the Initiator.</t>
<t>Afterwards, connectivity tests are started based on the procedure described in <xref
target="I-D.rosenberg-mmusic-ice-nonsip"/> by using the candiates previously
exchanged in the HIP base exchange.</t>
</section>
<section title="NAT Keep-alives">
<t>Data channel keepalives are STUN Binding Indications. Keepalives MUST be sent every
20 seconds at the minimum when the channel is idle. To implement failure tolerance, a
host SHOULD have smaller keepalive period. When data traffic is exchanged between the
end points then no further STUN keepalives need to be exchanged.</t>
</section>
</section>
<!-- ************************************************************************************************** -->
<section anchor="sec:format" title="Packet Formats">
<t> The following subsections define the parameter and packet encodings. All values MUST be
in network byte order. </t>
<section anchor="sec:udphip" title="HIP Control Packets">
<figure anchor="fig:udphip" title="Format for UDP-encapsulated HIP Control Packets">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIP Header and Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
HIP control packets are encapsulated in UDP packets like in Section 2.2 of
<xref target="RFC3948"/>, "rules for encapsulating IKE messages", except that a
different port number is used. <xref target="fig:udphip"/> shows the encapsulation:
UDP header is followed by 32 zero bits that can be used to differentiate HIP control
packets from ESP packets. The HIP header and parameters follow the conventions of
<xref target="I-D.ietf-hip-base"/> with the exception that the HIP header checksum
MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header
contains already a checksum. Second, the checksum definition in <xref
target="I-D.ietf-hip-base"/> includes the IP addresses in the checksum
calculation. The NATs unaware of HIP cannot recompute the HIP checksum after changing
IP addresses. </t>
<t> A HIP Relay or a Responder without a relay MUST listen at transport port HIPPORT for
incoming UDP-encapsulated HIP control packets. </t>
</section>
<!-- UDP-HIP -->
<section anchor="sec:keep-alive" title="Keep-Alives">
<t> Control and data channel keep-alives are STUN Binding Indications, as defined in
<xref target="I-D.ietf-behave-rfc3489bis"/>. They use the same UDP header as the
HIP control packets but there is no non-ESP-marker 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.
<!-- figure of STUN BI format here -->
</t>
</section>
<!-- Keep-alive -->
<section anchor="sec:rel-reg-params" title="Relay and Registration Parameters">
<figure anchor="fig:udpparams"
title="Format for the RELAY_FROM,
RELAY_TO and REG_FROM parameters">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ]
Length 20
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
]]></artwork>
</figure>
<t> Format of the RELAY_FROM, RELAY_TO and REG_FROM parameters is shown in <xref
target="fig:udpparams"/>. Parameters are identical except for the type field. </t>
</section>
<!-- Relay and Registration Parameters -->
<section title="LOCATOR Parameter" anchor="sec:locator_format">
<t> The generic LOCATOR parameter format is the same as in <xref
target="I-D.ietf-hip-mm"/>. However, presenting ICE candidates requires a new
locator type. The generic and NAT traversal specific locator parameters are illustrated in
<xref target="fig:locator"/>. </t>
<figure anchor="fig:locator" title="LOCATOR parameter">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Loc Type = 2 | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> The individual fields in the LOCATOR parameter are described in <xref
target="tbl:locator"/>. </t>
<texttable anchor="tbl:locator" title="Fields of the LOCATOR parameter">
<ttcol align="left">Field</ttcol>
<ttcol align="left">Value(s)</ttcol>
<ttcol align="left">Purpose</ttcol>
<c>Type</c>
<c>193</c>
<c>Parameter type</c>
<c>Length</c>
<c>Variable</c>
<c>Length in octets, excluding Type and Length fields and padding</c>
<c>Traffic Type</c>
<c>0-2</c>
<c>Is the locator for HIP signaling (1), for ESP (2), or for both (0)</c>
<c>Locator Type</c>
<c>2</c>
<c>"Transport address" locator type</c>
<c>Locator Length</c>
<c>7</c>
<c>Length of the Locator field in 4-octet units</c>
<c>Reserved</c>
<c>0</c>
<c>Reserved for future extensions</c>
<c>Preferred (P) bit</c>
<c>0</c>
<c>Not used for transport address locators; MUST be ignored by the receiver.</c>
<c>Locator Lifetime</c>
<c>Variable</c>
<c>Locator lifetime in seconds</c>
<c>Transport Port</c>
<c>Variable</c>
<c>Transport layer port number</c>
<c>Transport Protocol</c>
<c>0</c>
<c>0 for UDP</c>
<c>Kind</c>
<c>Variable</c>
<c>0 for host, 1 for server reflexive, 2 for peer reflexive or 3 for relayed address</c>
<c>Priority</c>
<c>Variable</c>
<c>Locator's priority as described in <xref target="I-D.ietf-mmusic-ice"/></c>
<c>SPI</c>
<c>Variable</c>
<c>SPI value which the host expects to see in incoming ESP packets that use this
locator</c>
<c>Locator</c>
<c>Variable</c>
<c>IPv6 address or an "IPv4-compatible IPv6 address" format IPv4 address <xref
target="RFC3513"/>, obfuscated by XORring it with the owner's HIT</c>
</texttable>
</section>
<!-- locator parameter format -->
<section anchor="sec:relay-hmac" title="RELAY_HMAC">
<t> The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + 2^4). It has the
same semantics as RVS_HMAC <xref target="I-D.ietf-hip-rvs"/>. </t>
</section>
<!-- RELAY_HMAC -->
<section title="Registration Types">
<t> 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. The value for RELAY_UDP_ESP is
3. </t>
</section>
<!-- Registration Types -->
<section anchor="sec:udpesp" title="HIP ESP Data Packet Formats">
<t>
<xref target="RFC3948"/> describes UDP encapsulation of the IPsec ESP transport and
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 is same as the UDP
encapsulation transport mode ESP. </t>
<t> During the HIP base exchange, the two peers exchange parameters that enable them to
define a pair of IPsec ESP security associations (SAs), as described in <xref
target="I-D.ietf-hip-esp"/>. When two peers perform a UDP-encapsulated base
exchange, they MUST define a pair of IPsec SAs that produces UDP-encapsulated ESP
data traffic. </t>
<t> The management of encryption/authentication protocols and security parameter indices
(SPIs) is defined in <xref target="I-D.ietf-hip-esp"/>. The UDP encapsulation format
and processing of HIP ESP traffic is described in Section 6.1 of <xref
target="I-D.ietf-hip-esp"/>. </t>
<t> Section 5.1 of <xref target="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. </t>
<t> This issue does not exist with the UDP encapsulation of HIP ESP transport format
because the Responder use HITs to distinguish between different communication
instances. </t>
</section>
</section>
<!-- ************************************************************************************************** -->
<section title="Security Considerations">
<!-- XX FIXME: cookie indexing must not use ports due to NAT timeouts -->
<section title="Privacy Considerations">
<t> The LOCATORs are sent XORed format in plain text in favour of inspection at
HIP-aware middleboxes in the future. The current draft does not specify encrypted
versions of LOCATORs even though it could be beneficial for privacy reasons. </t>
<t> 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 reveal the internal
topology of the private address realm and it discards host addresses. Such behavior
creates non-optimal paths when the hosts are located behind the same NAT. Especially,
this could be a problem with a legacy NAT that does not support routing from the
private address realm back to itself through the outer address of the NAT. This
scenario is referred to as the hairpin problem <xref
target="I-D.ietf-behave-p2p-state"/>. With such a legacy NAT, the only option left
would be to use a relayed transport address from a 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. </t>
<t> The use of HIP Relays or TURN Relays can be useful for protection against
Denial-of-Service attacks. If a Responder reveals only its HIP and ESP relay
candidates to malign 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. </t>
</section>
<!-- privacy -->
<section title="Opportunistic Mode">
<t> A HIP Relay should have one address per Relay Client when a HIP Relay is serving
more than one Relay Clients and is willing to support opportunistic mode. Otherwise,
it cannot be guaranteed that the Relay can deliver the I1 packet to the intended
recipient. </t>
</section>
<!-- opportunistic -->
</section>
<!-- security considerations -->
<!-- ************************************************************************************************** -->
<section title="IANA Considerations">
<t> This section is to be interpreted according to <xref target="RFC2434"/>. </t>
<t> This draft currently uses a UDP port in the "Dynamic and/or Private Port" and HIPPORT.
Upon publication of this document, IANA is requested to register a UDP port and the RFC
editor is requested to change all occurrences of port HIPPORT to the port IANA has
registered. The HIPPORT number 50500 should be used for initial experimentation. </t>
<t> This document updates the IANA Registry for HIP Parameter Types by assigning new HIP
Parameter Type values for the new HIP Parameters: RELAY_FROM, RELAY_TO and REG_FROM
(defined in <xref target="sec:rel-reg-params"/>) and RELAY_HMAC (defined in
<xref target="sec:relay-hmac"/>). </t>
</section>
<!-- IANA -->
<!-- ************************************************************************************************** -->
<section title="Contributors">
<t> Marcelo Bagnulo, Jan Melén, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien
Schmitt, Abhinav Pathak and Andrei Gurtov have contributed to the initial versions of
this draft. </t>
</section>
<!-- contributors -->
<!-- ************************************************************************************************** -->
<section title="Acknowlegements">
<t> 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 thank Andrei Gurtov, Tobias Heer,
Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov,
Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen,
Joakim Koskela, Samu Varjonen, Dan Wing, Hannes Tschofenig, Jan Melén, Jani
Hautakorpi and Ari Keränen For their comments on this document. </t>
<t>Miika Komu is working in the Networking Research group at Helsinki Institute for
Information Technology (HIIT). The InfraHIP project was funded by Tekes, Telia-Sonera,
Elisa, Nokia, the Finnish Defence Forces, and Ericsson and Birdstep. </t>
</section>
<!-- Acknowlegements -->
<!-- ************************************************************************************************** -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-hip-base" ?>
<?rfc include="reference.RFC.4423" ?>
<?rfc include="reference.I-D.ietf-mmusic-ice" ?>
<?rfc include="reference.I-D.ietf-hip-rvs" ?>
<?rfc include="reference.I-D.ietf-hip-mm" ?>
<?rfc include="reference.I-D.ietf-hip-registration" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.ietf-behave-turn" ?>
<?rfc include="reference.I-D.ietf-behave-rfc3489bis" ?>
<?rfc include="reference.I-D.ietf-hip-esp" ?>
<!-- <?rfc include="reference.RFC.0768" ?> -->
<?rfc include="reference.RFC.3513" ?>
<?rfc include="reference.RFC.2434" ?>
<?rfc include="reference.I-D.rosenberg-mmusic-ice-nonsip" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-behave-p2p-state" ?>
<?rfc include="reference.I-D.irtf-hiprg-nat" ?>
<?rfc include="reference.RFC.2663" ?>
<?rfc include="reference.RFC.4787" ?>
<!-- <?rfc include="reference.I-D.oliva-hiprg-reap4hip" ?> -->
<!-- <?rfc include="reference.I-D.heer-hip-middle-auth" ?> -->
<?rfc include="reference.RFC.3948" ?>
</references>
<!-- ************************************************************************************************** -->
<section anchor="firewalls" title="Firewall Traversal">
<t> This section describes firewall traversal issues separately from NAT 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. </t>
<t> 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. </t>
<t> 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. </t>
<t> 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. </t>
<t> 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. </t>
</section>
<section anchor="sec:no_relay" title="Base Exchange without ICE Connectivity Checks">
<!-- XX TODO: relay registration currently depends on this, so it should be moved away from appendix -->
<t>
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.
</t>
<t>
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
<xref target="sec:nat_transform" />. 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.
</t>
</section> <!-- Communication with HIP Hosts without NAT Traversal Support -->
<section anchor="sec:interoperability" title="IPv4-IPv6 Interoperability">
<t>
Currently Relay Client and Server do not have to run any ICE connectivity
tests as described in <xref target="sec:no_relay" />. However, it could
be useful for IPv4-IPv6 interoperability when the Relay Server actually
includes both the NAT transform parameter and multiple locators in R2.
The interoperability benefit is that the Relay could support IPv4-based
Initiators and IPv6-based Responders by converting the network headers and
recalculating UDP checksums.
</t>
<t>
Such an approach is underspecified in this document currently. It is not yet
recommended because it may consume resources at the Relay and requires
also similar conversion support at the TURN relay for data packets.
</t>
</section>
<section title="Base Exchange through a Rendezvous Server">
<t>
This section describes handling for a scenario where Initiator looks
up the information of the Responder from DNS and discovers a RVS
record <xref target="I-D.ietf-hip-rvs" />. In such a case, the
Initiator uses its own HIP Relay to forward HIP traffic to the Rendezvous
server. The Initiator will send the I1 message using the its HIP Relay server
which will then forward it to the RVS server of the responder. The responder
will send the R1 packet directly to the Initiator's HIP Relay server and the
following I2 and R2 packets are also sent directly using the Relay.
</t>
<t>
In case the Initiator is not able to distinguish which records are RVS
address records and which are Responders address records, then 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 own HIP Relay as described
in the above.
</t>
<!--
<t>
A single server can provide multiple HIP middlebox services or the
services can be distributed among multiple servers. The difference
between a HIP rendezvous server <xref target="I-D.ietf-hip-rvs" /> and
a HIP Relay server depends on the registration. The rendezvous server
processing rules apply when the Responder has registered to a
middlebox with the RVS registration type. Correspondingly, the
middlebox applies the relay extensions defined in this document
when the Responder has registered using the relay registration
types. When a single server provides both rendezvous and relay
services, they are multiplexed depending on the absence or presence
of transport layer encapsulation.
</t>
MB: Question, is it possible to register with the same registration process both
for HIP and ESP relay services? If yes, i would put it explicitly
-->
</section> <!-- Base Exchange with a Rendezvous Server -->
<!-- ************************************************************************************************** -->
<section title="Document Revision History">
<t>To be removed upon publication</t>
<texttable>
<ttcol>Revision</ttcol>
<ttcol width="85%">Comments</ttcol>
<c>draft-ietf-nat-traversal-00</c>
<c>Initial version.</c>
<c>draft-ietf-nat-traversal-01</c>
<c>Draft based on RVS.</c>
<c>draft-ietf-nat-traversal-02</c>
<c>Draft based on Relay proxies and ICE concepts.</c>
<c>draft-ietf-nat-traversal-03</c>
<c>Draft based on STUN/ICE formats.</c>
</texttable>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:24 |