One document matched: draft-ietf-hip-nat-traversal-04.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.89 2008/07/14 20:51:17 mkomu Exp $ -->
<rfc category="exp" ipr="full3978" docName="draft-ietf-hip-nat-traversal-04.txt">
<front>
<title abbrev="Basic NAT Traversal for HIP">Basic HIP Extensions for Traversal of
Network Address Translators</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>(Unaffiliated)</organization>
<address>
<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" role="editor">
<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 basic 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="RFC5201"/> is defined as a protocol that runs directly over
IPv4 or IPv6. This approach is known to have problems traversing NATs.
A detailed description of HIP problems with traversing legacy middleboxes is documented
in <xref target="I-D.irtf-hiprg-nat"/>. This document describes HIP extensions for the
traversal of both Network Address Translator (NAT) and Network Address and Port Translator
(NAPT) middleboxes. The document generally uses the term NAT to refer to these types of
middleboxes.</t>
<t>Currently deployed 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.</t>
<t>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
through a relay, such as a TURN server <xref target="RFC5128"/>. 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 the TURN server when possible. </t>
<t>This document defines new middlebox extensions to allow
NAT traversal 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 <xref target="RFC5204"/>)
and HIP Relay services. HIP rendezvous servers solve
initial contact and mobility related problems in networks
without NATs. HIP Relay servers solve the same problems, in
addition to NAT traversal problems. HIP Relay servers can
be used both in NATed and non-NATed networks. </t>
<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 NATs
can drop the packets otherwise <xref target="RFC5128"/>.</t>
<t>The basis for the connectivity checks 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 locators to each other in the HIP base exchange. They are then paired with the
locally operational address of the other endpoint and prioritized according local and recommended
policies. These address sets are then tested sequentially based on the procedures specified
in ICE. Both sides participate in the connectivity checks. The tests may also discover multiple
operational address pairs but determine a single preferred address pair to be used for
subsequent communication.</t>
<t>In a nutshell, the extensions in this document defines:</t>
<t>
<list style="symbols">
<t>encapsulatation of HIP packets in UDP</t>
<t>UDP encapsulation of IPsec ESP packets</t>
<t>registration extensions for HIP Relay services</t>
<t>how the "offer" and "answer" are carried in the base exchange</t>
<t>interaction with ICE connectivity messages</t>
<t>backwards compatibility issues with rendezvous servers</t>
<t>a number of optimizations (such when the ICE connectivity tests can be excluded)</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="RFC5201"/>, <xref
target="RFC5206"/>, <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"/> As defined in <xref target="RFC5206"/>:
"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." It should noticed that "address" is used in this
document as a synonym for locator.<vspace blankLines="1"/>
</t>
<t hangText="HIP Relay:"><vspace blankLines="1"/> LOCATOR (written in capital letters)
denotes a HIP control message parameter that bundles multiple locators together
<vspace blankLines="1"/></t>
<t hangText="ICE Offer:"><vspace blankLines="1"/> The Initiator's LOCATOR parameter
in HIP I2 control message.</t>
<t hangText="ICE Answer:"><vspace blankLines="1"/> The Responder's LOCATOR parameter
in HIP R2 control message</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. 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">
<t> HIP rendezvous servers operate in non-NATed
environments and their use is described in
<xref target="RFC5204"/>. This section specifies a new
middlebox extension, called the HIP Relay, to perate in
NATted environments. HIP Relay servers forward all HIP
control packets between the Initiator and the Responder
over UDP.</t>
<t>End-hosts cannot use the HIP Relay service for forward
ESP data plane. Instead, they use TURN servers
<xref target="I-D.ietf-behave-turn"/> for
relaying the ESP traffic. A HIP end-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 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="RFC5203"/> 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="RFC5203"/>. </t>
-->
<t> In step 1, the Relay Client (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 Relay Server (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 SHOULD not contain any
NAT transform parameter.</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
denotes 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 sends periodically NAT keepalives.</t>
<t> There are different ways for an Initiator to learn it's publicly visible IP
address and port that are referred to as the "server reflexive transport candidate"
in this document. It is a local decision on how the end-host learnds the candidate, but
either of the following methods is RECOMMENDED:</t>
<t>
<list style="symbols">
<t>The Relay client may use STUN servers to detect the server reflexive locator,
as described in <xref target="RFC5128"/>. </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 anchor="sec:nat_transform" title="NAT Transformation Negotiation">
<t>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.</t>
<t>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
<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 checks 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. The locator parameter in I2 is the "ICE offer".</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. The locators parameter in R2
is the "ICE answer".</t>
</section>
<section anchor="sec:relay_bex" title="Base Exchange via HIP Relay">
<t>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.</t>
<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 such an 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, NAT_TFM)) |
| 4. UDP(R1(RELAY_TO),NAT_TFM) |<-------------------------------+
|<-----------------------------+ |
| | |
| 5. UDP(I2(LOCATOR),NAT_TFM) | |
+----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),|
| | NAT_TFM) |
| +------------------------------->|
| | |
| | 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 belonging to 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 contains 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="RFC5204"/>, 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="RFC5201"/>. In addition, the
Responder validates the RELAY_HMAC according to <xref target="RFC5204"/> and
silently 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 MUST contain
same information as the RELAY_FROM parameter, i.e., the Initiator's transport address and the nonce, 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
the source address and port, and changes the destination address and port to match
RELAY_TO information. Finally, the Relay 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="RFC5201"/>. 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 (ICE offer) of the Initiator.
The candidates are encoded using the format defined in
<xref target="sec:locator_format"/>. 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.
</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 explained in the second step. </t>
<t> In step 7, the Responder receives the I2 packet and processes it according to <xref
target="RFC5201"/>. It replies with a R2 packet and includes a RELAY_TO
parameter as explained in step three. The R2 packet includes a LOCATOR parameter that lists all
the ICE candidates (ICE 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 title="ICE Connectivity Checks">
<t>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.
</t>
<!-- I think we need more details on ICE below. Try avoid too much redundancy with section sec:con_checks -->
<t>The ICE connectivity checks are defined in
<xref target="I-D.ietf-mmusic-ice"/>. Section
<xref target="sec:con_checks" /> defines the details of
the STUN control packets. As a result of the ICE
connectivity checks, ICE nominates a single 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.
</t>
</section>
<section title="NAT Keepalives">
<!-- Miika: what about when NAT device is mobile? Then
end-host does not detect address change. Are STUN Binding
indications and NOTIFY message secure enough for that? Can
STUN even be used for that? -->
<!-- Miika: is it important that both hosts send keepalives or
was other direction more important? -->
<t>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.</t>
<t>The keepalives are STUN Binding Indications if the
hosts have agreed on NAT_TRANSFORM during the base
exchange, or HIP NOTIFY messages otherwise. A HIP Relay
MUST not forward NOTIFY messages.
</t>
<!-- Should we have a new type for NAT keepalives? Otherwise
I and R may not report errors with NOTIFY messages to
each other through the Relay. But maybe this is actually
a good restriction.
-->
<t>The communicating hosts MUST send keepalives to each
other using the 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.
</t>
</section>
<!-- XX TODO: add a section on TURN usage with an example -->
<section anchor="sec:no_relay" title="Base Exchange without ICE Connectivity Checks">
<t> In certain network environments, the ICE connectivity checks 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 to 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 NAT transform
parameter. The Initiator receives the R1 packet and
determines from the absence of the NAT transform and
RELAY_TO parameters that ICE connectivity checks can be
omitted. Finally, the hosts can start to use the
locators from the concluding I2 and R2 packets of the
base exchange for ESP without ICE connectivity
checks.</t>
</section> <!-- Communication with HIP Hosts without NAT Traversal Support -->
<section anchor="sec:no_udp" title="Base Exchange without UDP Encapsulation">
<t>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.
</t>
<!-- What about replay attacks with R1 that cause DoS for Initiator? -->
<t>The I1 packet may arrive directly at the
Responder. When the recipient is the Responder, the
proceduces in <xref target="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.</t>
<t>The packet may also arrive at a HIP-capable
middlebox. When the middlebox is a HIP rendezvous
server and the Responder has successfully registered to
the rendezvous service, the middlebox follows
rendezvous procedures in <xref target="RFC5204" />. If
the middlebox is a HIP Relay server, it drops the I1
packet silently.</t>
<!-- Mobility extensions need to take care that we can
switch back to UDP encapsulation again -->
</section> <!-- Base Exchange without UDP Encapsulation -->
<section anchor="sec:control_no_relay" title="Sending Control Messages using the Data Plane">
<t>The end-hosts MAY send control messages directly to each
other using the transport address pair established for
data channel without sending the control packets through the
Relay. When a host does not get acknowledgements
e.g. to an UPDATE or CLOSE message after a timeout based on
local policies, the host SHOULD resend the packet through
the Relay. This optimization requires further experimentation.
</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 as defined in Section 2.2 of
<xref target="RFC3948"/>, "rules for encapsulating IKE messages" except for a different port number.
<xref target="fig:udphip"/> illustrates the encapsulation.
The 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="RFC5201"/> 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="RFC5201"/> 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>
<!-- HIP Control Packets -->
<section anchor="sec:con_checks" title="Connectivity Checks">
<t>The connectivity checks are performed using STUN Binding
Requests. This section describes the details of the
parameters in the STUN messages.</t>
<!-- XX TODO: we should tell that the HIT/passwd is converted in the HEX?? -->
<t>The username is formed from the username fragments as
defined in section 7.1.1.3 of
<xref target="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 <xref target="RFC5201" /> section
6.5. The HIT username fragment MUST contain a UTF-8
<xref target="RFC3629" /> encoded sequence and MUST have
been processed using SASLPrep <xref target="RFC4013" /> as
defined section 15.3 of
<xref target="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.
</t>
<t>Drawing of HIP keys is defined in <xref target="RFC5201"
/> section 6.5 and drawing of ESP keys in
<xref target="RFC5202" /> section 7. Correspondingly, the
hosts MUST draw symmetric keys for STUN according to
<xref target="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
<xref target="I-D.ietf-behave-rfc3489bis" /> describes how
hosts use the password for message integrity of STUN
messages.
</t>
<t>The connectivity checks MUST contain
PRIORITY attribute. They MAY contain USE-CANDIDATE
attributes as defined in section 7.1.1.1 of
<xref target="I-D.ietf-mmusic-ice"/>.</t>
<t>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 <xref target="RFC5201"/>.
</t>
</section>
<section anchor="sec:keep-alive" title="Keepalives">
<t>The keepalives for HIP associations agreed that are NAT_TRANSFORM capable are STUN Binding Indications, as defined in
<xref target="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.
<!-- The "only FINGERPRINT attribute" recommendation is from the (next version of) ice draft -->
<!-- figure of STUN BI format here? -->
</t>
<t>
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.
</t>
</section>
<!-- Keep-alive -->
<section anchor="sec:rel-reg-params" title="Relay and Registration Parameters">
<figure anchor="fig:reg_from"
title="Format for REG_FROM 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA:
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>
<figure anchor="fig:relay"
title="Format for the RELAY_FROM and RELAY_TO 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA:
Critical parameters:
RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
RELAY_TO: (64002 = 2^16 - 2^11 + 2^9 + 2)
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.
]]></artwork>
</figure>
<t> Format for the REG_FROM parameter is shown in <xref target="fig:reg_from" />, and RELAY_FROM and RELAY_TO in <xref
target="fig:relay"/>. Parameters are identical except for the type and nonce fields. </t>
<t>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.</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="RFC5206"/>. 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 XORing 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="RFC5204"/>. </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="ESP Data Packets">
<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. However, the (semantic) difference to BEET mode
ESP packets used by HIP is that IP header is not used
in BEET integrity protection calculation.</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="RFC5202"/>. 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 SPIs
is defined in <xref target="RFC5202"/>. The UDP encapsulation format
and processing of HIP ESP traffic is described in Section 6.1 of <xref
target="RFC5202"/>. </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 in XORed format in plain text in favor 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="RFC5128"/>. With such a legacy NAT, the only option left
would be to use a relayed transport address from a TURN server.</t>
<t>As a consequence, a host may support locator-based
privacy by leaving out the reflexive candidates. However, the trade-off in using
only host candidates can produce suboptimal paths
that can congest the TURN server.
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 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. </t>
</section>
<!-- privacy -->
<section title="Opportunistic Mode">
<t> A HIP Relay server should have one address per Relay Client when a HIP Relay is serving
more than one Relay Clients and supports opportunistic mode. Otherwise,
it cannot be guaranteed that the Relay can deliver the I1 packet to the intended
recipient. </t>
</section>
<!-- opportunistic -->
<section title="Base Exchange Replay Protection for HIP Relay Server">
<t>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.
</t>
<t>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
<xref target="I-D.heer-hip-middle-auth" /> and drops the I2
or R2 messages if the corresponding ECHO_RESPONSE_M
parameters are not present.
</t>
</section>
<section title="Demuxing Different HIP Associations">
<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 Initiators. </t>
</section>
</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"/>). NAT_TRANSFORM is also a new parameter.</t>
</section>
<!-- IANA -->
<!-- ************************************************************************************************** -->
<section title="Contributors">
<!-- TODO: Change "draft" to "RFC" when the time is right -->
<t>This draft is a product of a design team which also included Marcelo Bagnulo and Jan Melén who
both have made major contributions to this document.</t>
</section>
<!-- contributors -->
<!-- ************************************************************************************************** -->
<section title="Acknowledgments">
<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, Simon Schuetz,
Martin Stiemerling, Lars Eggert, Vivien Schmitt, Abhinav Pathak for their contributions and
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 and Jani Hautakorpi 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.RFC.5201" ?>
<?rfc include="reference.RFC.4423" ?>
<?rfc include="reference.I-D.ietf-mmusic-ice" ?>
<?rfc include="reference.RFC.5204" ?>
<?rfc include="reference.RFC.5206" ?>
<?rfc include="reference.RFC.5203" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.ietf-behave-turn" ?>
<?rfc include="reference.I-D.ietf-behave-rfc3489bis" ?>
<?rfc include="reference.RFC.5202" ?>
<!-- <?rfc include="reference.RFC.0768" ?> -->
<?rfc include="reference.RFC.3513" ?>
<?rfc include="reference.RFC.2434" ?>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.RFC.4013" ?>
<?rfc include="reference.I-D.rosenberg-mmusic-ice-nonsip" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.irtf-hiprg-nat" ?>
<!-- <?rfc include="reference.RFC.2663" ?> -->
<?rfc include="reference.RFC.4787" ?>
<?rfc include="reference.RFC.5128" ?>
<!-- <?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: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="RFC5204" />. 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="RFC5204" /> 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>
<c>draft-ietf-nat-traversal-04</c>
<c>Issues 25-27,29-36</c>
</texttable>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:33 |