rfc9028xml2.original.xml   rfc9028.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc symrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc compact="yes" ?> category="exp" docName="draft-ietf-hip-native-nat-traversal-33"
<?rfc sortrefs="no" ?> obsoletes="" updates="" submissionType="IETF" xml:lang="en"
<rfc ipr="trust200902" category="exp" symRefs="true" tocInclude="true" sortRefs="true" version="3"
docName="draft-ietf-hip-native-nat-traversal-33"> number="9028" consensus="true">
<front> <front>
<title abbrev="HIP Native NAT Traversal Mode"> <title abbrev="HIP Native NAT Traversal Mode">
Native NAT Traversal Mode for the Host&nbsp;Identity&nbsp;Protocol Native NAT Traversal Mode for the Host Identity Protocol
</title> </title>
<seriesInfo name="RFC" value="9028"/>
<author fullname="Ari Keranen" initials="A." surname="Keranen"> <author fullname="Ari Keränen" initials="A." surname="Keränen">
<organization abbrev="Ericsson">Ericsson</organization> <organization abbrev="Ericsson">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>02420 Jorvas</city> <city>Jorvas</city>
<code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>ari.keranen@ericsson.com</email> <email>ari.keranen@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="J." fullname="Jan Melén" surname="Melén">
<author initials="J." fullname="Jan Mel&eacute;n" surname="Mel&eacute;n">
<organization abbrev="Ericsson">Ericsson</organization> <organization abbrev="Ericsson">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>02420 Jorvas</city> <city>Jorvas</city>
<code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>jan.melen@ericsson.com</email> <email>jan.melen@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Miika Komu" initials="M." surname="Komu" role="editor">
<author fullname="Miika Komu" initials="M.K.T." surname="Komu" role="editor"
>
<organization abbrev="Ericsson">Ericsson</organization> <organization abbrev="Ericsson">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>02420 Jorvas</city> <city>Jorvas</city>
<code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>miika.komu@ericsson.com</email> <email>miika.komu@ericsson.com</email>
</address> </address>
</author> </author>
<date month="June" year="2021"/>
<date year="2020" />
<area>Internet</area> <area>Internet</area>
<workgroup>HIP Working Group</workgroup> <workgroup>HIP</workgroup>
<keyword>HIP, NAT, NAT traversal</keyword> <keyword>HIP</keyword>
<keyword>NAT</keyword>
<keyword>NAT traversal</keyword>
<abstract> <abstract>
<t> This document specifies a new Network Address Translator (NAT) <t> This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology and based on the Interactive Connectivity Establishment (ICE) methodology
UDP encapsulation of data and signaling traffic. The main difference from and UDP encapsulation of data and signaling traffic. The main difference
the previously specified modes is the use of HIP messages instead of ICE f from the previously specified modes is the use of HIP messages instead
or all NAT of ICE for all NAT traversal procedures due to the kernel-space
traversal procedures due to the kernel-space dependencies of HIP. dependencies of HIP.
</t> </t>
</abstract> </abstract>
</front> </front>
<!-- XX FIXME: CHECK NEW ICE SPECS? -->
<middle> <middle>
<section anchor="sec_intro" numbered="true" toc="default">
<name>Introduction</name>
<t> The Host Identity Protocol (HIP) <xref target="RFC7401"
format="default"/> is specified to run directly on top of IPv4 or
IPv6. However, many middleboxes found in the Internet, such as NATs and
firewalls, often allow only UDP or TCP traffic to pass <xref
target="RFC5207" format="default"/>. Also, NATs usually require the host
behind a NAT to create a forwarding state in the NAT before other hosts
outside of the NAT can contact the host behind the NAT. To overcome this
problem, different methods, commonly referred to as NAT traversal
techniques, have been developed. </t>
<t>As one solution, the HIP experiment report <xref target="RFC6538"
format="default"/> mentions Teredo-based NAT traversal for HIP and
related Encapsulating Security Payload (ESP) traffic (with double
tunneling overhead). Another solution is specified in <xref
target="RFC5770" format="default"/>, which will be referred to as
"Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP
specification combines the Interactive Connectivity Establishment (ICE)
protocol (originally <xref target="RFC5245" format="default"/>) with HIP s
o that
basically, ICE is responsible for NAT traversal and connectivity
testing, while HIP is responsible for end-host authentication and IPsec
key management. The resulting protocol uses HIP, Session Traversal
Utilities for NAT (STUN), and ESP messages tunneled over a single UDP
flow. The benefit of using ICE and its STUN / Traversal Using Relays
around NAT (TURN) messaging formats is
that one can reuse the NAT traversal infrastructure already available
in the Internet, such as STUN and TURN servers. Also, some middleboxes
may be STUN aware and may be able to do something "smart" when they see
STUN being used for NAT traversal.</t>
<!-- ***************************************************************** --> <t>HIP poses a unique challenge to using standard ICE, not only due to
kernel-space dependencies of HIP, but also due to its close integration
<section title="Introduction" anchor="sec:intro"> with kernel-space IPsec; and, while <xref target="RFC5770"
format="default"/> provides a technically workable path, HIP incurs
<t> The Host Identity Protocol (HIP) <xref
target="RFC7401"/> is specified to run directly on top
of IPv4 or IPv6. However, many middleboxes found in the Internet, such as
NATs and firewalls, often allow only UDP or TCP traffic to pass <xref
target="RFC5207"/>. Also, NATs usually require the host behind
a NAT to create a forwarding state in the NAT before other hosts outside
of the NAT can contact the host behind the NAT. To overcome this problem,
different methods, commonly referred to as NAT traversal techniques, have
been developed. </t>
<t>As one solution, the HIP experiment report <xref
target="RFC6538" /> mentions Teredo-based NAT traversal for
HIP and related ESP traffic (with double tunneling overhead).
Another solution is specified in <xref target="RFC5770"/>, which
will be referred to as "Legacy ICE-HIP" in this document. The
experimental Legacy ICE-HIP specification combines Interactive Connectivit
y Establishment
(ICE) protocol <xref target="RFC5245"/> with
HIP, so that basically ICE is responsible for NAT traversal and
connectivity testing, while HIP is responsible for end-host
authentication and IPsec key management. The resulting protocol
uses HIP, STUN and ESP messages tunneled over a single UDP
flow. The benefit of using ICE and its STUN/TURN messaging
formats is that one can re-use the NAT traversal infrastructure
already available in the Internet, such as STUN and TURN
servers. Also, some middleboxes may be STUN-aware and may be
able to do something "smart" when they see STUN being used for
NAT traversal.</t>
<t>HIP poses a unique challenge to using standard ICE, due not
only to kernel-space dependencies of HIP, but also due to its
close integration with kernel-space IPSec; and, that while <xref target="R
FC5770" />
provides a technically workable path, it incurs
unacceptable performance drawbacks for kernel-space unacceptable performance drawbacks for kernel-space
implementations. Also, implementing and integrating a full ICE/STUN/TURN p implementations. Also, implementing and integrating a full ICE/STUN/TURN
rotocol stack as specified protocol stack as specified in Legacy ICE-HIP results in a considerable
in Legacy ICE-HIP results in a considerable amount of effort and amount of effort and code, which could be avoided by reusing and
code which could be avoided by re-using and extending HIP extending HIP messages and state machines for the same purpose. Thus,
messages and state machines for the same purpose. this document specifies an alternative NAT traversal mode referred to as
Thus, this "Native ICE-HIP" that employs the HIP messaging format instead of STUN
document specifies an alternative NAT traversal mode referred as or TURN for the connectivity checks, keepalives, and data relaying.
"Native ICE-HIP" that employs HIP messaging format instead of Native ICE-HIP also specifies how mobility management works in the
STUN or TURN for the connectivity checks, keepalives and data context of NAT traversal, which is missing from the Legacy ICE-HIP
relaying. Native ICE-HIP also specifies how mobility management specification. The native specification is also based on HIPv2, whereas
works in the context of NAT traversal, which is missing from the the legacy specification is based on HIPv1. The differences to Legacy
Legacy ICE-HIP specification. The native specification is also based on HI ICE-HIP are further elaborated in <xref target="sec_ice_diff"
Pv2, whereas legacy specification is based on HIPv1. The differences to the format="default"/>.</t>
Legacy ICE-HIP are further elaborated in <xref target="sec:ice_diff" />.</
t>
<t>Similarly as Legacy ICE-HIP, also this specification builds
on the HIP registration extensions <xref target="RFC8003" /> and
the base exchange procedure <xref target="RFC7401" /> and its closing proc
edures, so the
reader is recommended to get familiar with the relevant
specifications. In a nutshell, the registration extensions allow
a HIP Initiator (usually a "client" host) to ask for specific
services from a HIP Responder (usually a "server" host). The
registration parameters are included in a base exchange, which
is essentially a four-way Diffie-Hellman key exchange
authenticated using the public keys of the end-hosts. When the
hosts negotiate support for ESP <xref target="RFC7402" /> during
the base exchange, they can deliver ESP protected application
payload to each other. When either of the hosts moves and
changes its IP address, the two hosts re-establish connectivity
using the mobility extensions <xref target="RFC8046" />. The
reader is also recommended to get familiar with the mobility
extensions, but basically it is a three-way procedure, where the
mobile host first announces its new location to the peer, and
then the peer tests for connectivity (so called return
routability check), for which the mobile hosts must respond in
order to activate its new location. This specification builds on
the mobility procedures, but modifies it to be compatible with
ICE. The differences to the mobility extensions specified in <xref target=
"sec:hip_diff" />.
It is worth noting that multihoming support as specified in <xref target="
RFC8047" /> is left
for further study.
</t>
<t>This specification builds heavily on the ICE methodology, so <t>Similar to Legacy ICE-HIP, this specification builds on the HIP
it is recommended that the reader is familiar with the ICE registration extensions <xref target="RFC8003" format="default"/> and
specification <xref target="RFC8445" /> the base exchange procedure <xref target="RFC7401" format="default"/>
(especially the overview). However, native ICE-HIP does not and its closing procedures; therefore, the reader is recommended to get
implement all the features in ICE, and, hence, the different familiar with the relevant specifications. In a nutshell, the
features of ICE are cross referenced using <xref registration extensions allow a HIP Initiator (usually a "client" host)
target="RFC2119"/> terminology for clarity. <xref to ask for specific services from a HIP Responder (usually a "server"
target="sec:ice_diff" /> explains the differences to ICE, and it is host). The registration parameters are included in a base exchange,
recommended that the reader would read also this section in addition to th which is essentially a four-way Diffie-Hellman key exchange
e authenticated using the public keys of the end hosts. When the hosts
ICE specification. negotiate support for ESP <xref target="RFC7402" format="default"/>
</t> during the base exchange, they can deliver ESP-protected application
payload to each other. When either of the hosts moves and changes its
IP address, the two hosts re-establish connectivity using the mobility
extensions <xref target="RFC8046" format="default"/>. The reader is also
recommended to get familiar with the mobility extensions; basically,
the process is a three-way procedure where the mobile host first
announces its new location to the peer; then, the peer tests
for connectivity (the so-called return routability check); and then, the
mobile host must respond to the announcement in order to activate its
new location. This specification builds on the mobility procedures, but
modifies them to be compatible with ICE. The differences in the mobility
extensions are specified in <xref target="sec_hip_diff"
format="default"/>. It is worth noting that multihoming support as
specified in <xref target="RFC8047" format="default"/> is left for
further study.</t>
<!-- <t>This specification builds heavily on the ICE methodology, so it is
<t>Two HIP specific NAT traversal techniques for HIP are specified in <xre recommended that the reader is familiar with the ICE specification <xref
f target="RFC8445" format="default"/> (especially the overview). However,
target="RFC5770"/>. One of them uses only UDP encapsulation, while the Native ICE-HIP does not implement all the features in ICE; hence,
other uses also the Interactive Connectivity Establishment (ICE) <xref the different features of ICE are cross referenced using <xref
target="RFC8445"/> protocol, which in turn uses Session Traversal target="RFC2119" format="default"/> terminology for clarity. <xref
Utilities for NAT (STUN) <xref target="RFC5389"/> and Traversal Using target="sec_ice_diff" format="default"/> explains the differences to
Relays around NAT (TURN) <xref target="RFC5766"/> protocols to achieve a ICE, and it is recommended that the reader read this section
reliable NAT traversal solution. </t> --> in addition to the ICE specification.</t>
</section> </section>
<!-- ***************************************************************** --> <section numbered="true" toc="default">
<name>Terminology</name>
<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>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref
target="RFC2119"/> <xref target="RFC8174" /> when, and only when,
they appear in all capitals, as shown here.</t>
<t>This document borrows terminology from <xref target="RFC5770"/>, <xref
target="RFC7401"/>, <xref
target="RFC8046"/>, <xref target="I-D.ietf-hip-rfc4423-bis"/>, <xref
target="RFC8445"/>, and <xref target="RFC5389"/>.
The following terms recur in the text:
<list style="hanging">
<!--
<t hangText="Rendezvous server:"><vspace blankLines="0"/> A host
that forwards I1 packets to the Responder.<vspace
blankLines="0"/></t> -->
<t hangText="ICE:"><vspace blankLines="0"/>
Interactive Connectivity Establishment (ICE) protocol as specified in <
xref
target="RFC8445"/>
<vspace blankLines="0"/></t>
<t hangText="Legacy ICE-HIP:"><vspace blankLines="0"/>
Refers to the "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators" as specified
in <xref target="RFC5770" />. The protocol specified in this
document offers an alternative to Legacy ICE-HIP.<vspace
blankLines="0"/></t>
<t hangText="Native ICE-HIP:"><vspace blankLines="0"/>
The protocol specified in this document (Native NAT Traversal Mode for
HIP).
<vspace blankLines="0"/></t>
<t hangText="Initiator:"><vspace
blankLines="0"/> The Initiator is the host that initiates the base exc
hange using I1 message <xref target="RFC7401" />.
</t>
<t hangText="Responder:"><vspace
blankLines="0"/> The Responder is the host that receives the I1 packet
from the Initiator <xref target="RFC7401" />.
</t>
<t hangText="Control Relay Server"><vspace blankLines="0"/> A registra
r host that
forwards any kind of HIP control plane packets between the Initiator a
nd
the Responder. This host is critical because it relays the locators be
tween the Initiator
and the Responder, so that they can try to establish a direct communic
ation path with each other.
This host is used to replace HIP rendezvous servers <xref target="RFC8
004" /> for hosts operating in private address realms.
In the Legacy ICE-HIP specification <xref target="RFC5770" />, this ho
st is denoted as "HIP Relay Server".
<vspace blankLines="0"/></t>
<t hangText="Control Relay Client:"><vspace blankLines="0"/>
A requester host that registers to a Control Relay Server requesting it
to forward
control-plane traffic (i.e. HIP control messages).
In the Legacy ICE-HIP specification <xref target="RFC5770" />, this is
denoted as "HIP Relay Client".
<vspace blankLines="1"/></t>
<t hangText="Data Relay Server:"><vspace blankLines="0"/> A new entity
introduced
in this document; a registrar host that
forwards HIP related data plane packets, such as Encapsulating Securit
y Payload
(ESP) <xref target="RFC7402"/>, between two hosts. This host implement
s similar
functionality as TURN servers.
<vspace blankLines="0"/></t>
<t hangText="Data Relay Client:"><vspace blankLines="0"/>
A requester host that registers to a Data Relay Server requesting it to
forward
data-plane traffic (e.g. ESP traffic). This functionality is a new and
introduced in this
document.
<vspace blankLines="1"/></t>
<!--
<t hangText="TURN server:"><vspace blankLines="0"/> A server that
forwards data traffic between two end-hosts as defined in <xref
target="RFC5766"/>.<vspace blankLines="0"/></t> -->
<t hangText="Locator:"><vspace blankLines="0"/> As defined in <xref
target="RFC8046"/>: "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 Security Parameter I
ndex (SPI). It may also
include transport port numbers or IPv6 Flow Labels as demultiplexing
context, or it may simply be a network address."
<vspace blankLines="0"/></t>
<t hangText="LOCATOR_SET (written in capital letters):"><vspace
blankLines="0"/> Denotes a HIP control packet parameter that bundles
multiple locators together <xref target="RFC8046" />. <vspace blankLi
nes="0"/></t>
<t hangText="HIP offer:"><vspace blankLines="0"/>
Before two end-hosts can establish a communication channel using the NA
T traversal procedures defined in this document,
they need exchange their locators (i.e. candidates) with each other. In
ICE, this procedure is called
Candidate Exchange and it does not specify how the candidates are excha
nged but Session Description Protocol (SDP) "offer/answer" is mentioned as an ex
ample.
In contrast, the Candidate Exchange in HIP is the base exchange itself
or a subsequent UPDATE prodecure occurring
after a handover. Following <xref target="RFC5770" /> and
SDP related naming conventions <xref target="RFC3264" />, "HIP offer" i
s the the Initiator's
LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet.
</t>
<t hangText="HIP answer:"><vspace blankLines="0"/> The Responder's
LOCATOR_SET parameter in a HIP R2 or UPDATE control packet. Correspond
s to the
SDP answer parameter <xref target="RFC3264" />, but is HIP specific. P
lease refer also to the longer description of the "HIP offer" term above.</t>
<t hangText="HIP connectivity checks:"><vspace
blankLines="0"/> In order to obtain a direct end-to-end
communication path (without employing a Data Relay Server), two commun
icating HIP hosts try to
"punch holes" through their NAT boxes using this mechanism.
It is similar to the ICE connectivity checks, but implemented
using HIP return routability checks.
</t>
<t hangText="Controlling host:"><vspace
blankLines="0"/>The controlling host <xref target="RFC8445" /> is alwa
ys the Initiator in the context of this specification. It nominates the candidat
e pair to be used with the controlled host.
</t>
<t hangText="Controlled host:"><vspace
blankLines="0"/>The controlled host <xref target="RFC8445" /> is alway
s the Responder in the context of this specification. It waits for the controlli
ng to nominate an address candidate pair.
</t>
<t hangText="Checklist:"><vspace blankLines="0"/>A list of address can
didate pairs that need to be tested for connectivity (same as in <xref target="R
FC8445" />).<vspace
blankLines="0"/></t>
<t hangText="Transport address:"><vspace blankLines="0"/> Transport
layer port and the corresponding IPv4/v6 address (same as in <xref tar
get="RFC8445" />).<vspace
blankLines="0"/></t>
<t hangText="Candidate:"><vspace blankLines="0"/> A transport address
that is a potential point of contact for receiving data (same as in <x
ref target="RFC8445" />).<vspace
blankLines="0"/></t>
<t hangText="Host candidate:"><vspace blankLines="0"/> A candidate
obtained by binding to a specific port from an IP address on the
host (same as in <xref target="RFC8445" />).<vspace blankLines="0"/></
t>
<t hangText="Server reflexive candidate:"><vspace blankLines="0"/> A
translated transport address of a host as observed by a Control or Dat
a Relay Server (same as in <xref target="RFC8445" />). <vspace blankLines="0"/><
/t>
<t hangText="Peer reflexive candidate:"><vspace blankLines="0"/> A
translated transport address of a host as observed by its peer (same a
s in <xref target="RFC8445" />).
<vspace blankLines="0"/></t>
<t hangText="Relayed candidate:"><vspace blankLines="0"/> A transport
address that exists on a Data Relay Server. Packets that arrive at thi
s
address are relayed towards the Data Relay Client. The concept is the
same as in <xref target="RFC8445" />,
but a Data Relay Server is used instead of a TURN server.</t>
<t hangText="Permission:"><vspace blankLines="0"/> In the context of D <t>
ata Relay Server, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
permission refers to a concept similar to TURN's (<xref target="RFC5 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
766" />) channels. Before a host can use a relayed candidate NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
to forward traffic through a Data Relay Server, the host must activa "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
te the relayed candidate with a "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
specific peer host. to be interpreted as
<vspace blankLines="0"/></t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document borrows terminology from <xref target="RFC5770"
format="default"/>, <xref target="RFC7401" format="default"/>, <xref
target="RFC8046" format="default"/>, <xref
target="RFC9068" format="default"/>, <xref
target="RFC8445" format="default"/>, and <xref target="RFC8489"
format="default"/>. The following terms recur in the text:</t>
<dl newline="true" spacing="normal">
<t hangText="Base:"><vspace blankLines="0"/> Similarly as in <xref tar <dt>ICE:</dt>
get="RFC8445" />, the base of a candidate is the local source <dd>Interactive Connectivity Establishment (ICE) protocol as specified
address a host uses to send packets for the associated candidate. For in <xref target="RFC8445" format="default"/>.</dd>
example, the base of a <dt>Legacy ICE-HIP:</dt>
server reflexive address is the local address the host used for regist <dd>Refers to the "Basic Host Identity Protocol (HIP) Extensions for
ering itself to the associated Control or Data Relay Server. The base Traversal of Network Address Translators" as specified in <xref
of a host candidate is equal to the host candidate itself. target="RFC5770" format="default"/>. The protocol specified in this
<vspace blankLines="0"/></t> document offers an alternative to Legacy ICE-HIP.</dd>
<dt>Native ICE-HIP:</dt>
<dd>The protocol specified in this document (Native NAT Traversal Mode
for HIP).</dd>
<dt>Initiator:</dt>
<dd>The host that initiates the base exchange using
I1 message <xref target="RFC7401" format="default"/>.</dd>
<dt>Responder:</dt>
<dd> The host that receives the I1 packet from the
Initiator <xref target="RFC7401" format="default"/>.</dd>
<dt>Control Relay Server</dt>
<dd>A registrar host that forwards any kind of HIP control plane
packets between the Initiator and the Responder. This host is critical
because it relays the locators between the Initiator and the
Responder so that they can try to establish a direct communication
path with each other. This host is used to replace HIP Rendezvous
Servers <xref target="RFC8004" format="default"/> for hosts operating
in private address realms. In the Legacy ICE-HIP specification <xref
target="RFC5770" format="default"/>, this host is denoted as "HIP
Relay Server".</dd>
<dt>Control Relay Client:</dt>
<dd>A requester host that registers to a Control Relay Server
requesting it to forward control plane traffic (i.e., HIP control
messages). In the Legacy ICE-HIP specification <xref target="RFC5770"
format="default"/>, this is denoted as "HIP Relay Client".</dd>
<dt>Data Relay Server:</dt>
<dd>A new entity introduced in this document; a registrar host that
forwards HIP related data plane packets, such as Encapsulating
Security Payload (ESP) <xref target="RFC7402" format="default"/>,
between two hosts. This host implements similar functionality as TURN
servers.</dd>
<dt>Data Relay Client:</dt>
<dd>A requester host that registers to a Data Relay Server requesting
it to forward data plane traffic (e.g. ESP traffic). This
functionality is a new and introduced in this document.</dd>
</list> <dt>Locator:</dt>
<dd><t>As defined in <xref target="RFC8046" format="default"/>: "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."
</t> </t>
</dd>
<dt>LOCATOR_SET (written in capital letters):</dt>
<dd>Denotes a HIP control packet parameter that bundles multiple
locators together <xref target="RFC8046" format="default"/>.</dd>
<dt>HIP offer:</dt>
<dd>Before two end hosts can establish a communication channel using
the NAT traversal procedures defined in this document, they need to
exchange their locators (i.e., candidates) with each other. In ICE,
this procedure is called Candidate Exchange; it does not specify how
the candidates are exchanged, but Session Description Protocol (SDP)
"offer/answer" is mentioned as an example. In contrast, the Candidate
Exchange in HIP is the base exchange itself or a subsequent UPDATE
procedure occurring after a handover. Following <xref target="RFC5770"
format="default"/> and SDP-related naming conventions <xref
target="RFC3264" format="default"/>, "HIP offer" is the Initiator's
LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet.</dd>
<dt>HIP answer:</dt>
<dd> The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE
control packet. The HIP answer corresponds to the SDP answer parameter <x
ref
target="RFC3264" format="default"/> but is HIP specific. Please refer
also to the longer description of the "HIP offer" term above.</dd>
<dt>HIP connectivity checks:</dt>
<dd> In order to obtain a direct end-to-end communication path
(without employing a Data Relay Server), two communicating HIP hosts
try to "punch holes" through their NAT boxes using this mechanism. It
is similar to the ICE connectivity checks but implemented using HIP
return routability checks.</dd>
<dt>Controlling host:</dt>
<dd>The controlling host <xref target="RFC8445" format="default"/> is
always the Initiator in the context of this specification. It
nominates the candidate pair to be used with the controlled host.</dd>
<dt>Controlled host:</dt>
<dd>The controlled host <xref target="RFC8445" format="default"/> is
always the Responder in the context of this specification. It waits
for the controlling host to nominate an address candidate pair.</dd>
</section><!-- Terminology --> <dt>Checklist:</dt>
<dd>A list of address candidate pairs that need to be tested for
connectivity (same as in <xref target="RFC8445"
format="default"/>).</dd>
<dt>Transport address:</dt>
<dd>Transport-layer port and the corresponding IPv4/v6 address (same
as in <xref target="RFC8445" format="default"/>).</dd>
<dt>Candidate:</dt>
<dd>A transport address that is a potential point of contact for
receiving data (same as in <xref target="RFC8445"
format="default"/>).</dd>
<dt>Host candidate:</dt>
<dd>A candidate obtained by binding to a specific port from an IP
address on the host (same as in <xref target="RFC8445"
format="default"/>).</dd>
<dt>Server-reflexive candidate:</dt>
<dd>A translated transport address of a host as observed by a Control
or Data Relay Server (same as in <xref target="RFC8445"
format="default"/>).</dd>
<dt>Peer-reflexive candidate:</dt>
<dd>A translated transport address of a host as observed by its peer
(same as in <xref target="RFC8445" format="default"/>).</dd>
<dt>Relayed candidate:</dt>
<dd>A transport address that exists on a Data Relay Server. Packets
that arrive at this address are relayed towards the Data Relay
Client. The concept is the same as in <xref target="RFC8445"
format="default"/>, but a Data Relay Server is used instead of a TURN
server.</dd>
<dt>Permission:</dt>
<dd>In the context of Data Relay Server, permission refers to a
concept similar to TURN's <xref target="RFC8656" format="default"/>
channels. Before a host can use a relayed candidate to forward traffic
through a Data Relay Server, the host must activate the relayed
candidate with a specific peer host.</dd>
<section title="Overview of Operation"> <dt>Base:</dt>
<dd>Similar to that described in <xref target="RFC8445" format="default"
/>, the
base of a candidate is the local source address a host uses to send
packets for the associated candidate. For example, the base of a
server-reflexive address is the local address the host used for
registering itself to the associated Control or Data Relay Server. The
base of a host candidate is equal to the host candidate itself.</dd>
</dl>
</section>
<?rfc needLines="20" ?> <section numbered="true" toc="default">
<figure anchor="fig:overview" <name>Overview of Operation</name>
title="Example Network Configuration"> <figure anchor="fig_overview">
<artwork align="center"><![CDATA[ <name>Example Network Configuration</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+--------------+ +--------------+
| Control | | Control |
+--------+ | Relay Server | +--------+ +--------+ | Relay Server | +--------+
| Data | +----+-----+---+ | Data | | Data | +----+-----+---+ | Data |
| Relay | / \ | Relay | | Relay | / \ | Relay |
| Server | / \ | Server | | Server | / \ | Server |
+--------+ / \ +--------+ +--------+ / \ +--------+
/ \ / \
/ \ / \
/ \ / \
skipping to change at line 370 skipping to change at line 339
+-------+ +-------+ +-------+ +-------+
| NAT | | NAT | | NAT | | NAT |
+-------+ +-------+ +-------+ +-------+
/ \ / \
/ \ / \
+-------+ +-------+ +-------+ +-------+
| Init- | | Resp- | | Init- | | Resp- |
| iator | | onder | | iator | | onder |
+-------+ +-------+ +-------+ +-------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> In the example configuration depicted in <xref target="fig_overview"
<t> In the example configuration depicted in <xref format="default"/>, both Initiator and Responder are behind one or more
target="fig:overview"/>, both Initiator and Responder are behind NATs, and both private networks are connected to the public Internet. To
one or more NATs, and both private networks are connected to the be contacted from behind a NAT, at least the Responder must be
public Internet. To be contacted from behind a NAT, at least the registered with a Control Relay Server reachable on the public
Responder must be registered with a Control Relay Server reachable Internet. The Responder may have also registered to a Data Relay Server
on the public Internet. that can forward the data plane in case NAT traversal fails. While,
The Responder may have also registered to a Data Relay Server that can for strictly speaking, the Initiator does not need a Data Relay Server, it
ward the data plane in case NAT traversal fails. may act in the other role with other hosts; connectivity with the
While, strictly speaking, the Initiator does not need a Data Relay Server, Data Relay Server of the Responder may fail, so the Initiator may also
it may act in the other role need to register to a Control and/or Data Relay Server. It is worth
with other hosts, and connectivity with the Data Relay Server of the Respo noting that a Control and Data Relay does not forge the source address
nder may fail, so the Initiator may also of a passing packet but always translates the source address and source
need to register to a Cotrol and/or Data Relay Server. port of a packet to be forwarded (to its own).</t>
It is worth noting that a Control and Data Relay does not forge the source <t>We assume, as a starting point, that the Initiator knows both the
address of a passing packet, but Responder's Host Identity Tag (HIT) and the address(es) of the
always translates the source address and source port of a packet to be for Responder's Control Relay Server(s) (how the Initiator learns of the
warded (to its own).</t> Responder's Control Relay Server is outside of the scope of this
document, but it may be learned through DNS or another name service). The
<t> first
We assume, as a starting point, that steps are for both the Initiator and Responder to register with a
the Initiator knows both the Responder's Host Identity Tag (HIT) Control Relay Server (need not be the same one) and gather a set of
and the address(es) of the Responder's Control Relay Server(s) (how the In address candidates. The hosts use either Control Relay Servers or Data
itiator Relay Servers for gathering the candidates. Next, the HIP base exchange
learns of the Responder's Control Relay Server is outside of the scope is carried out by encapsulating the HIP control packets in UDP datagrams
of this document, but may be through DNS or another name and sending them through the Responder's Control Relay Server. As part
service). of the base exchange, each HIP host learns of the peer's candidate
The first steps are for both the Initiator and Responder to register addresses through the HIP offer/answer procedure embedded in the base
with a Control Relay Server (need not be the same one) and gather a set of exchange.
address candidates. The hosts use either Control Relay Servers or Data Rel </t>
ay Servers for gathering
the candidates. Next, the HIP base exchange is carried out by
encapsulating the HIP control packets in UDP datagrams and sending them
through the Responder's Control Relay Server. As part of the base exchang
e, each
HIP host learns of the peer's candidate addresses through the HIP
offer/answer procedure embedded in the base exchange. <!--, which follows
closely the ICE <xref target="RFC8445"/> protocol. --> </t>
<!-- WHAT ABOUT HICCUPS AND DATA RELAY ???
Jeff: I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv
1). (Wait until if/when 6078 is updated for HIPv2.) -->
<!-- send ESP transform -> hiccups incompatible (no need to defined here b
ecause hiccups is not HIPv2 compatible -Jeff) -->
<t> Once the base exchange is completed, two HIP hosts have established a
working
communication session (for signaling) via a Control Relay Server, but the
hosts
still have to find a better path, preferably without a Data Relay Server,
for the ESP
data flow. For this, connectivity checks are carried out until a
working pair of addresses is discovered. At the end of the procedure, if
successful, the hosts will have established a UDP-based tunnel that traver
ses
both NATs, with the data flowing directly from NAT to NAT or via a Data Re
lay Server.
At this point, also the HIP signaling can be sent over the same address/po
rt
pair, and is demultiplexed (or, in other words, separated) from IPsec as d
escribed in the UDP encapsulation standard for IPsec <xref target="RFC3948"/>.
Finally, the two hosts send NAT keepalives as needed in order keep their U
DP-tunnel state active
in the associated NAT boxes.</t>
<t> Once the base exchange is completed, two HIP hosts have established
a working communication session (for signaling) via a Control Relay
Server, but the hosts still have to find a better path, preferably
without a Data Relay Server, for the ESP data flow. For this,
connectivity checks are carried out until a working pair of addresses is
discovered. At the end of the procedure, if successful, the hosts will
have established a UDP-based tunnel that traverses both NATs with the
data flowing directly from NAT to NAT or via a Data Relay Server. At
this point, the HIP signaling can also be sent over the same
address/port pair, and is demultiplexed (or, in other words, separated)
from IPsec as described in the UDP encapsulation standard for IPsec
<xref target="RFC3948" format="default"/>. Finally, the two hosts send
NAT keepalives as needed in order keep their UDP-tunnel state active in
the associated NAT boxes.</t>
<t> If either one of the hosts knows that it is not behind a NAT, hosts <t> If either one of the hosts knows that it is not behind a NAT, hosts
can negotiate during the base exchange a different mode of NAT traversal can negotiate during the base exchange a different mode of NAT traversal
that does not use HIP connectivity checks, but only UDP encapsulation of that does not use HIP connectivity checks, but only UDP encapsulation of
HIP and ESP. Also, it is possible for the Initiator to simultaneously try HIP and ESP. Also, it is possible for the Initiator to simultaneously try
a base exchange with and without UDP encapsulation. If a base exchange a base exchange with and without UDP encapsulation. If a base exchange
without UDP encapsulation succeeds, no HIP connectivity checks or UDP without UDP encapsulation succeeds, no HIP connectivity checks or UDP
encapsulation of ESP are needed. </t> encapsulation of ESP are needed. </t>
</section> </section>
<!-- ***************************************************************** --> <section anchor="sec_protocol" numbered="true" toc="default">
<name>Protocol Description</name>
<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> -->
<t> This section describes the normative behavior of the "Native ICE-HIP"
protocol
extension. Most of the procedures are similar to what is defined in <xref
target="RFC5770"/> but with different, or additional, parameter types and
values. In addition, a new type of relaying server, Data Relay Server, is
specified. Also, it should be noted that HIP version 2 <xref
target="RFC7401"/> MUST be used instead of HIPv1 with this NAT
traversal mode. </t>
<section anchor="sec:registration" title="Relay Registration">
<t>In order for two hosts to communicate over NATted
environments, they need a reliable way to exchange
information. To achieve this, "HIP Relay Server" is defined in <xref
target="RFC5770"/>. It supports relaying of HIP control plane
traffic over UDP in NATted environments, and
forwards HIP control packets between the Initiator and the
Responder. In this document, the HIP Relay Server is
denoted as "Control Relay Server" for better alignment with the rest of
the terminology. The registration to the
Control Relay Server can be achieved using RELAY_UDP_HIP
parameter as explained later in this section.</t>
<t>To guarantee also data plane delivery over varying types of NAT
devices, a host MAY also register for UDP encapsulated ESP
relaying using Registration Type RELAY_UDP_ESP (value [TBD by
IANA: 3]). This service may be coupled with the Control Relay Server
or offered separately on another server.
If the server supports relaying of UDP
encapsulated ESP, the host is allowed to register for a data
relaying service using the registration extensions in Section 3.3 of <xr
ef
target="RFC8003"/>). If the server has
sufficient relaying resources (free port numbers, bandwidth,
etc.) available, it opens a UDP port on one of its
addresses and signals the address and port to the registering
host using the RELAYED_ADDRESS parameter (as defined in <xref
target="sec:relayed_address"/> in this document). If the Data Relay Serv
er
would accept the data relaying request but does not currently
have enough resources to provide data relaying service, it
MUST reject the request with Failure Type "Insufficient
resources" <xref target="RFC8003"/>. </t>
<!-- <t> This section describes the normative behavior of the "Native
A Control Relay Server MUST silently drop packets to a ICE-HIP" protocol extension. Most of the procedures are similar to what
Control Relay Client that has not previously registered with is defined in <xref target="RFC5770" format="default"/> but with
the HIP relay (since it would not anyway know where to relay ). --> different, or additional, parameter types and values. In addition, a new
type of relaying server, Data Relay Server, is specified. Also, it
should be noted that HIP version 2 <xref target="RFC7401"
format="default"/> <bcp14>MUST</bcp14> be used instead of HIPv1 with
this NAT traversal mode. </t>
<section anchor="sec_registration" numbered="true" toc="default">
<name>Relay Registration</name>
<t>In order for two hosts to communicate over NATed environments,
they need a reliable way to exchange information. To achieve this,
"HIP Relay Server" is defined in <xref target="RFC5770"
format="default"/>. It supports the relaying of HIP control plane traffic
over UDP in NATed environments and forwards HIP control packets
between the Initiator and the Responder. In this document, the HIP
Relay Server is denoted as "Control Relay Server" for better alignment
with the rest of the terminology. The registration to the Control
Relay Server can be achieved using the RELAY_UDP_HIP parameter as
explained later in this section.</t>
<t> <t>To also guarantee data plane delivery over varying types of NAT
The registration process follows the generic devices, a host <bcp14>MAY</bcp14> also register for UDP-encapsulated
registration extensions defined in <xref target="RFC8003"/>. ESP relaying using Registration Type RELAY_UDP_ESP (value 3). This servi
The HIP control plane relaying registration follows <xref ce may be coupled with the Control Relay Server
target="RFC5770"/>, but the data plane registration is or offered separately on another server. If the server supports
different. It is worth noting that if the HIP control and data relaying of UDP-encapsulated ESP, the host is allowed to register for
plane relay services reside on different hosts, the client has a data-relaying service using the registration extensions in <xref
to register separately to each of them. In the example shown target="RFC8003" sectionFormat="of" section="3.3"/>. If the server
in <xref target="fig:reg"/>, the two services are coupled on a has sufficient relaying resources (free port numbers, bandwidth, etc.)
single host. The text uses "Relay Client" and "Relay available, it opens a UDP port on one of its addresses and signals the
Server" as a shorthand when the procedures apply both to control and dat address and port to the registering host using the RELAYED_ADDRESS
a cases.</t> parameter (as defined in <xref target="sec_relayed_address"
format="default"/> in this document). If the Data Relay Server would
accept the data-relaying request but does not currently have enough
resources to provide data-relaying service, it <bcp14>MUST</bcp14>
reject the request with Failure Type "Insufficient resources" <xref
target="RFC8003" format="default"/>. </t>
<figure anchor="fig:reg" title="Example Registration with a HIP Relay"> <t>The registration process follows the generic registration
<artwork align="center"><![CDATA[ extensions defined in <xref target="RFC8003" format="default"/>. The
HIP control plane relaying registration follows <xref target="RFC5770"
format="default"/>, but the data plane registration is different. It
is worth noting that if the HIP control and data plane relay services
reside on different hosts, the client has to register separately to
each of them. In the example shown in <xref target="fig_reg"
format="default"/>, the two services are coupled on a single host. The
text uses "Relay Client" and "Relay Server" as a shorthand when the
procedures apply both to control and data cases.</t>
<figure anchor="fig_reg">
<name>Example Registration with a HIP Relay</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
Control/Data Control/Data Control/Data Control/Data
Relay Client (Initiator) Relay Server (Responder) Relay Client (Initiator) Relay Server (Responder)
| 1. UDP(I1) | | 1. UDP(I1) |
+---------------------------------------------------------------->| +---------------------------------------------------------------->|
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) |
+---------------------------------------------------------------->| +---------------------------------------------------------------->|
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, |
| [RELAYED_ADDRESS])) | | [RELAYED_ADDRESS])) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> In step 1, the Relay Client (Initiator) starts the registration <t> In step 1, the Relay Client (Initiator) starts the registration
procedure by sending an I1 packet over UDP to the Relay Server. It is RE procedure by sending an I1 packet over UDP to the Relay Server. It is
COMMENDED that the <bcp14>RECOMMENDED</bcp14> that the Relay Client select a random
Relay Client select a random source port number from the ephemeral port source port number from the ephemeral port range 49152-65535 for
range initiating a base exchange. Alternatively, a host <bcp14>MAY</bcp14>
49152-65535 for initiating a base exchange. Alternatively, a host MAY also use a single fixed port for initiating all outgoing
also use a single fixed port for initiating all outgoing connections. However, the allocated port <bcp14>MUST</bcp14> be
connections. However, the allocated port MUST be maintained until all maintained until all of the corresponding HIP associations are
of the corresponding HIP Associations are closed. It is RECOMMENDED closed. It is <bcp14>RECOMMENDED</bcp14> that the Relay Server listen
that the Relay Server listen to incoming connections at UDP port to incoming connections at UDP port 10500. If some other port number
10500. If some other port number is used, it needs to be known by is used, it needs to be known by potential Relay Clients.</t>
potential Relay Clients.</t> <t> In step 2, the Relay Server (Responder) lists the services that it
supports in the R1 packet. The support for HIP control plane over UDP
<t> In step 2, the Relay Server (Responder) lists the services that relaying is denoted by the Registration Type value RELAY_UDP_HIP (see
it supports in the R1 packet. The support for HIP control plane over UDP <xref target="sec_reg-types" format="default"/>). If the server also
relaying is supports the relaying of ESP traffic over UDP, it also includes
denoted by the Registration Type value RELAY_UDP_HIP (see <xref the Registration Type value RELAY_UDP_ESP.</t>
target="sec:reg-types"/>). If the server supports also relaying of ESP t <t> In step 3, the Relay Client selects the services for which it
raffic over UDP, registers and lists them in the REG_REQ parameter. The Relay Client
it includes also Registration type value RELAY_UDP_ESP.</t> registers for the Control Relay service by listing the RELAY_UDP_HIP
value in the request parameter. If the Relay Client also requires ESP
<t> In step 3, the Relay Client selects the services for which it regist relaying over UDP, it lists also RELAY_UDP_ESP.</t>
ers and <t> In step 4, the Relay Server concludes the registration procedure
lists them in the REG_REQ parameter. The Relay Client registers for the with an R2 packet and acknowledges the registered services in the
Control Relay REG_RES parameter. The Relay Server denotes unsuccessful registrations
service by listing the RELAY_UDP_HIP value in the request (if any) in the REG_FAILED parameter of R2. The Relay Server also
parameter. If the Relay Client requires also ESP relaying over UDP, it l includes a REG_FROM parameter that contains the transport address of
ists also RELAY_UDP_ESP. the Relay Client as observed by the Relay Server (server-reflexive
</t> candidate). If the Relay Client registered to ESP-relaying service,
the Relay Server includes a RELAYED_ADDRESS parameter that describes the
<t> In step 4, the Relay Server concludes the registration procedure wit UDP port allocated to the Relay Client for ESP relaying. It is worth
h noting that the Data Relay Client must first activate this UDP port by
an R2 packet and acknowledges the registered services in the REG_RES sending an UPDATE message to the Data Relay Server that includes a
parameter. The Relay Server denotes unsuccessful registrations (if any) PEER_PERMISSION parameter as described in <xref
in target="sec_forwarding" format="default"/> both after base exchange
the REG_FAILED parameter of R2. The Relay Server also includes a REG_FRO and handover procedures. Also, the Data Relay Server should follow the
M port allocation recommendations in <xref target="sec_reuse"
parameter that contains the transport address of the Relay Client as obs format="default"/>.</t>
erved <t>After the registration, the Relay Client periodically sends NAT
by the Relay Server (Server Reflexive candidate). If the Relay Client re keepalives to the Relay Server in order to keep the NAT bindings
gistered to ESP relaying between the Relay Client and the relay alive. The keepalive extensions
service, the Relay Server includes RELAYED_ADDRESS parameter that descri are described in <xref target="sec_nat-keepalives"
bes format="default"/>.</t>
the UDP port allocated to the Relay Client for ESP relaying. It is worth <t> The Data Relay Client <bcp14>MUST</bcp14> maintain an active HIP
noting that association with the Data Relay Server as long as it requires the
the Data Relay Client must first activate this UDP port by sending an UP data-relaying service. When the HIP association is closed (or times
DATE message to the Data Relay out), or the registration lifetime passes without the Data Relay
Server that includes a PEER_PERMISSION parameter as described in <xref t Client refreshing the registration, the Data Relay Server
arget="sec:forwarding" /> <bcp14>MUST</bcp14> stop relaying packets for that host and close the
both after base exchange and handover procedures. Also, the Data Relay S corresponding UDP port (unless other Data Relay Clients are still
erver should follow the port allocation recommendations in <xref target="sec:reu using it). </t>
se" />. <t> The Data Relay Server <bcp14>SHOULD</bcp14> offer a different
</t> relayed address and port for each Data Relay Client because not doing
so can cause problems with stateful firewalls (see <xref
<t>After the registration, the target="sec_reuse" format="default"/>). </t>
Relay Client sends periodically NAT keepalives to the Relay Server in or <t>When a Control Relay Client sends an UPDATE (e.g., due to host
der to keep
the NAT bindings between the Relay Client and the relay alive. The keepa
live extensions
are described in <xref target="sec:nat-keepalives"/>.</t>
<t> The Data Relay Client MUST maintain an active HIP association with
the Data Relay Server as long as it requires the data relaying service.
When
the HIP association is closed (or times out), or the registration
lifetime passes without the Data Relay Client refreshing the
registration, the Data Relay Server MUST stop relaying packets for that
host
and close the corresponding UDP port (unless other Data Relay Clients ar
e
still using it). </t>
<t> The Data Relay Server SHOULD offer a different relayed address and p
ort for
each Data Relay Client because not doing so can cause problems with
stateful firewalls (see <xref target="sec:reuse" />). </t>
<t>When a Control Relay Client sends an UPDATE (e.g., due to host
movement or to renew service registration), the Control Relay Server movement or to renew service registration), the Control Relay Server
MUST follow the general guidelines defined in <xref <bcp14>MUST</bcp14> follow the general guidelines defined in <xref
target="RFC8003" />, with the difference that all UPDATE target="RFC8003" format="default"/>, with the difference that all
messages are delivered on top of UDP. In addition to this, UPDATE messages are delivered on top of UDP. In addition to this, the
the Control Relay Server MUST include the REG_FROM parameter in all Control Relay Server <bcp14>MUST</bcp14> include the REG_FROM
UPDATE responses sent to the Control Relay Client. parameter in all UPDATE responses sent to the Control Relay Client.
This applies to both renewals of service registration and to host This applies to both renewals of service registration and to host
movement. It is especially important for the case of host movement. It is especially important for the case of host
movement, as this is the mechanism that allows the Control Relay movement, as this is the mechanism that allows the Control Relay
Client to learn its new server reflexive address candidate. Client to learn its new server-reflexive address candidate.</t>
</t> <t>A Data Relay Client can request multiple relayed candidates from
the Data Relay Server (e.g., for the reasons described in <xref
<t>A Data Relay Client can request multiple relayed candidates target="sec_conflicting" format="default"/>). After the base exchange
from the Data Relay Server (e.g., for the reasons described with registration, the Data Relay Client can request additional
in <xref target="sec:conflicting" />). After the base exchange relayed candidates similarly as during the base exchange. The Data
with registration, the Data Relay Client can request Relay Client sends an UPDATE message REG_REQ parameter requesting for
additional relayed candidates similarly as during the base the RELAY_UDP_ESP service. The UPDATE message <bcp14>MUST</bcp14> also
exchange. The Data Relay Client sends an UPDATE message include a SEQ and an ECHO_REQUEST_SIGNED parameter. The Data Relay
REG_REQ parameter requesting for the RELAY_UDP_ESP Server <bcp14>MUST</bcp14> respond with an UPDATE message that
service. The UPDATE message MUST also include a SEQ and a includes the corresponding response parameters: REG_RES, ACK and
ECHO_REQUEST_SIGNED parameter. The Data Relay Server MUST ECHO_REQUEST_SIGNED. In case the Data Relay Server allocated a new
respond with an UPDATE message that includes the corresponding relayed UDP port for the Data Relay Client, the REG_RES parameter
response parameters: REG_RES, ACK and ECHO_REQUEST_SIGNED . In <bcp14>MUST</bcp14> list RELAY_UDP_ESP as a service and the UPDATE
case the Data Relay Server allocated a new relayed UDP port for message <bcp14>MUST</bcp14> also include a RELAYED_ADDRESS parameter
the Data Relay Client, the REG_RES parameter MUST list describing the relayed UDP port. The Data Relay Server
RELAY_UDP_ESP as a service and the UPDATE message MUST also <bcp14>MUST</bcp14> also include the server-reflexive candidate in a
include a RELAYED_ADDRESS parameter describing the relayed UDP REG_FROM parameter. It is worth mentioning that the Data Relay Client
port. The Data Relay Server MUST also include the Server <bcp14>MUST</bcp14> activate the UDP port as described in <xref
Reflexive candidate in a REG_FROM parameter. It is worth target="sec_forwarding" format="default"/> before it can be used for
mentioning that Data Relay Client MUST activate the UDP port any ESP relaying.</t>
as described in <xref target="sec:forwarding" /> before it can
be used for any ESP relaying.</t>
<t>A Data Relay Client may unregister a relayed candidate in <t>A Data Relay Client may unregister a relayed candidate in
two ways. It can wait for its lifetime to expire or it can two ways. It can wait for its lifetime to expire or it can
explicitly request it with zero lifetime using the UPDATE explicitly request it with zero lifetime using the UPDATE
mechanism. The Data Relay Client can send an REG_REQ parameter mechanism. The Data Relay Client can send a REG_REQ parameter
with zero lifetime to the Data Relay Server in order to expire with zero lifetime to the Data Relay Server in order to expire
all relayed candidates. To expire a specific relayed all relayed candidates. To expire a specific relayed
candidate, the Data Relay Client MUST also include candidate, the Data Relay Client <bcp14>MUST</bcp14> also include
RELAYED_ADDRESS parameter as sent by the server in the UPDATE a RELAYED_ADDRESS parameter as sent by the server in the UPDATE
message. Upon closing the HIP association (CLOSE-CLOSE-ACK message. Upon closing the HIP association (CLOSE-CLOSE-ACK
procedure initiated by either party), the Data Relay Server procedure initiated by either party), the Data Relay Server
MUST also expire all relayed candidates.</t> <bcp14>MUST</bcp14> also expire all relayed candidates.</t>
<t>Please also refer to <xref target="sec_cross_protocol"
<t>Please also refer to <xref target="sec:cross_protocol" /> for format="default"/> for protection against cross-protocol attacks for
protection against cross-protocol attacks for both Control both Control Relay Client and Server.</t>
Relay Client and Server.</t>
<!-- explained elsewhere...
<t>As the relay is assumed to have a publicly-reachable
address, it does not have to include a NAT_TRAVERSAL_MODE
parameter in an R1 message, thus avoiding any NAT penetration
procedures. This results in the HIP control and data plane
being tunneled over UDP as described in <xref
target="sec:minimal" />. In other words, a relay SHOULD NOT
OFFER ICE-HIP-UDP mode, but it MAY offer UDP-ENCAPSULATION as
NAT traversal mode in a NAT_TRAVERSAL_MODE parameter in an R1
message (which has the same result as omitting the parameter).
</t>
-->
</section> <!-- relay reg -->
<section anchor="sec:gathering" title="Transport Address Candidate Gatheri ng at the Relay Client"> </section>
<section anchor="sec_gathering" numbered="true" toc="default">
<name>Transport Address Candidate Gathering at the Relay Client</name>
<t> An Initiator needs to gather a set of address candidates <t> An Initiator needs to gather a set of address candidates
before contacting a (non-relay) Responder. The candidates are before contacting a (non-relay) Responder. The candidates are
needed for connectivity checks that allow two hosts to needed for connectivity checks that allow two hosts to
discover a direct, non-relayed path for communicating with discover a direct, non-relayed path for communicating with
each other. One server reflexive candidate can be discovered each other. One server-reflexive candidate can be discovered
during the registration with the Control Relay Server from the during the registration with the Control Relay Server from the
REG_FROM parameter (and another from Data Relay Server if one REG_FROM parameter (and another from Data Relay Server if one
is employed). <!-- It should be noted discovering multiple address is employed).
candidates in a multihoming configuration are left for further
study. --> </t>
</t>
<t> The candidate gathering can be done at any time, but it needs to be <t> The candidate gathering can be done at any time, but it needs to be
done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP mode is to be done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP mode is to be
used for the connectivity checks. It is RECOMMENDED that all three used for the connectivity checks. It is <bcp14>RECOMMENDED</bcp14> that all three
types of candidates (host, server reflexive, and relayed) are gathered types of candidates (host, server reflexive, and relayed) are gathered
to maximize the probability of successful NAT traversal. However, if no to maximize the probability of successful NAT traversal. However, if no
Data Relay Server is used, and the host has only a single local IP addre ss to Data Relay Server is used, and the host has only a single local IP addre ss to
use, the host MAY use the local address as the only host candidate and use, the host <bcp14>MAY</bcp14> use the local address as the only host candidate and
the address from the REG_FROM parameter discovered during the Control Re lay Server the address from the REG_FROM parameter discovered during the Control Re lay Server
registration as a server reflexive candidate. In this case, no further registration as a server-reflexive candidate. In this case, no further
candidate gathering is needed. </t> candidate gathering is needed. </t>
<t>A Data Relay Client <bcp14>MAY</bcp14> register only a single
<t>A Data Relay Client MAY register only a single relayed relayed candidate that it uses with multiple other peers. However, it
candidate that it uses with multiple other peers. However, it is is <bcp14>RECOMMENDED</bcp14> that a Data Relay Client registers a new
RECOMMENDED that a Data Relay Client registers a new server relayed server relayed candidate for each of its peers for the reasons
candidate for each of its peer for the reasons described in <xref described in <xref target="sec_conflicting" format="default"/>. The
target="sec:conflicting" />. The procedures for registering procedures for registering multiple relayed candidates are described
multiple relayed candidates are described in <xref in <xref target="sec_registration" format="default"/>.</t>
target="sec:registration" />.</t>
<t> If a Relay Client has more than one network interface, it <t> If a Relay Client has more than one network interface, it
can discover additional server reflexive candidates by sending can discover additional server-reflexive candidates by sending
UPDATE messages from each of its interfaces to the Relay UPDATE messages from each of its interfaces to the Relay
Server. Each such UPDATE message MUST include the following Server. Each such UPDATE message <bcp14>MUST</bcp14> include the follow
parameters: registration request (REG_REQ) parameter with ing
Registration Type CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) parameters: the registration request (REG_REQ) parameter with
and ECHO_REQUEST_SIGNED parameter. When a Control Relay Server Registration Type CANDIDATE_DISCOVERY (value 4)
and the ECHO_REQUEST_SIGNED parameter. When a Control Relay Server
receives an UPDATE message with registration request receives an UPDATE message with registration request
containing a CANDIDATE_DISCOVERY type, it MUST include a containing a CANDIDATE_DISCOVERY type, it <bcp14>MUST</bcp14> include a
REG_FROM parameter, containing the same information as if this REG_FROM parameter, containing the same information as if this
were a Control Relay Server registration, to the response (in were a Control Relay Server registration, to the response (in
addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request
type SHOULD NOT create any state at the Control Relay type <bcp14>SHOULD NOT</bcp14> create any state at the Control Relay
Server.</t> Server.</t>
<t>The rules in <xref target="RFC8445" sectionFormat="of"
section="5.1.1"/> for candidate gathering are followed here. A number
of host candidates (loopback, anycast and others) should be excluded as
described in the ICE specification (<xref target="RFC8445"
sectionFormat="of" section="5.1.1.1"/>). Relayed candidates
<bcp14>SHOULD</bcp14> be gathered in order to guarantee successful NAT
traversal, and implementations <bcp14>SHOULD</bcp14> support this
functionality even if it will not be used in deployments in order to
enable it by software configuration update if needed at some point.
<t>The rules in section 5.1.1 in <xref target="RFC8445" /> Similarly, as explained in the ICE specification (<xref
for candidate gathering are followed here. A number of host target="RFC8445" sectionFormat="of" section="5.1.1.2"/>), if an
candidates (loopback, anycast and others) should be excluded as IPv6-only host is in a network that utilizes NAT64 <xref
described in section 5.1.1.1 of the ICE specification <xref target="RFC84 target="RFC6146" format="default"/> and DNS64 <xref target="RFC6147"
45" />. Relayed format="default"/> technologies, it may also gather IPv4
candidates SHOULD be gathered in order to guarantee successful server-reflexive and/or relayed candidates from IPv4-only Control or
NAT traversal, and implementations SHOULD Data Relay Servers. IPv6-only hosts <bcp14>SHOULD</bcp14> also
support this functionality even if it will not be used in utilize IPv6 prefix discovery <xref target="RFC7050"
deployments in order to enable it by software configuration format="default"/> to discover the IPv6 prefix used by NAT64 (if any)
update if needed at some point. and generate server-reflexive candidates for each IPv6-only interface,
<!-- A host SHOULD employ only a single
server for gathering the candidates for a single HIP
association; either one server providing both Control and Data Relay Serv
er
functionality, or one Control Relay Server and
also Data Relay Server if the functionality is offered by another
server. When the relay service is split between two hosts, the
server reflexive candidate from the Control Relay Server SHOULD be used
instead of the one provided by the Data Relay Server. -->
<!-- If a relayed
candidate is identical to a host candidate, the relayed
candidate must be discarded. NAT64 considerations in section
4.1.1.2 of <xref target="RFC8445" /> apply as well. -->
Similarly as explained in section 5.1.1.2 of the ICE specification <xref
target="RFC8445" />,
if an IPv6-only host is in a network that utilizes NAT64 <xref target="RF
C6146" />
and DNS64 <xref target="RFC6147" /> technologies, it may also gather IPv4
server-
reflexive and/or relayed candidates from IPv4-only Control or Data Relay
Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery
<xref target="RFC7050" /> to discover the IPv6 prefix used by NAT64 (if a
ny) and
generate server-reflexive candidates for each IPv6-only interface,
accordingly. The NAT64 server-reflexive candidates are prioritized accordingly. The NAT64 server-reflexive candidates are prioritized
like IPv4 server-reflexive candidates. like IPv4 server-reflexive candidates.</t>
<t>HIP-based connectivity can be utilized by IPv4 applications using
</t> Local Scope Identifiers (LSIs) and by IPv6-based applications using
HITs. The LSIs and HITs of the local virtual interfaces
<t>HIP based connectivity can be utilized by IPv4 applications <bcp14>MUST</bcp14> be excluded in the candidate gathering phase as
using Local Scope Identifiers (LSIs) and by IPv6 based applications using well to avoid creating unnecessary loopback connectivity tests.</t>
HITs. The LSIs and HITs
of the local virtual interfaces MUST be excluded in the candidate gatherin
g
phase as well to avoid creating unnecessary loopback connectivity tests.</
t>
<!-- was: ..if STUN and *TURN* servers are available.. -->
<t>Gathering of candidates MAY also be performed by other means
than described in this section. For example, the candidates
could be gathered as specified in Section 4.2 of <xref
target="RFC5770"/> if STUN servers are available, or if the host
has just a single interface and no STUN or Data Relay Server are
available. </t>
<t>Each local address candidate MUST be assigned a
priority. The following recommended formula (as described
in <xref target="RFC8445" />) SHOULD be used:
<list style="empty">
<t>priority = (2^24)*(type preference) +
(2^8)*(local preference) +
(2^0)*(256 - component ID)</t>
</list></t>
<t>In the formula, the type preference follows the ICE specification (as d
efined in section 5.1.2.1 in <xref target="RFC8445" />):
the RECOMMENDED values are 126 for
host candidates, 100 for server reflexive candidates, 110 for
peer reflexive candidates, and 0 for relayed candidates. The
highest value is 126 (the most preferred) and lowest is 0 (last
resort). For all candidates of the same type, the preference type
value MUST be identical, and, correspondingly, the value MUST be
different for different types. For peer reflexive values, the
type preference value MUST be higher than for server reflexive
types. It should be noted that peer reflexive values are learned
later during connectivity checks, so a host cannot employ it
during candidate gathering stage yet.</t>
<t>Following the ICE specification, the local preference MUST be
an integer from 0 (lowest preference) to 65535 (highest
preference) inclusive. In the case the host has only a single address
candidate, the value SHOULD be 65535. In the case of multiple
candidates, each local preference value MUST be
unique. Dual-stack considerations for IPv6
apply also here as defined in <xref target="RFC8445" /> in section 5.1.2.2
.</t>
<t>Unlike with SDP used in conjunction with ICE, this protocol only create
s a single UDP flow
between the two communicating hosts, so only a single component
exists. Hence, the component ID value MUST always be set to
1.</t>
<t>As defined in section 14.3 in <xref target="RFC8445" />, the retransmis
sion timeout
(RTO) for address gathering from a Control/Data Relay Server SHOULD be cal
culated as
follows:
<list style="empty">
<t>RTO = MAX (1000ms, Ta * (Num-Of-Cands))</t>
</list>
</t>
<t>where Ta is the value used for the
connectivity check pacing and Num-Of-Cands
is the number of server-reflexive and relay candidates. A smaller value th
an 1000 ms for
the RTO MUST NOT be used.
</t>
<t>Gathering of candidates <bcp14>MAY</bcp14> also be performed by other
means than described in this section. For example, the candidates could
be gathered as specified in <xref target="RFC5770"
sectionFormat="of" section="4.2"/> if STUN servers are available, or if
the host has just a single interface and no STUN or Data Relay Server
are available. </t>
<t>Each local address candidate <bcp14>MUST</bcp14> be assigned a
priority. The following recommended formula (as described in <xref
target="RFC8445" format="default"/>) <bcp14>SHOULD</bcp14> be
used:</t>
<t indent="3">
priority = (2<sup>24</sup>)*(type preference) +
(2<sup>8</sup>)*(local preference) +
(2<sup>0</sup>)*(256 - component ID)
</t>
<t>In the formula, the type preference follows the ICE specification
(as defined in <xref target="RFC8445" sectionFormat="of"
section="5.1.2.1"/>): the <bcp14>RECOMMENDED</bcp14> values are 126
for host candidates, 100 for server-reflexive candidates, 110 for
peer-reflexive candidates, and 0 for relayed candidates. The highest
value is 126 (the most preferred) and lowest is 0 (last resort). For
all candidates of the same type, the preference type value
<bcp14>MUST</bcp14> be identical, and, correspondingly, the value
<bcp14>MUST</bcp14> be different for different types. For
peer-reflexive values, the type preference value <bcp14>MUST</bcp14>
be higher than for server-reflexive types. It should be noted that
peer-reflexive values are learned later during connectivity
checks.</t>
<t>Following the ICE specification, the local preference
<bcp14>MUST</bcp14> be an integer from 0 (lowest preference) to 65535
(highest preference) inclusive. In the case the host has only a single
address candidate, the value <bcp14>SHOULD</bcp14> be 65535. In the
case of multiple candidates, each local preference value
<bcp14>MUST</bcp14> be unique. Dual-stack considerations for IPv6 also
apply here as defined in <xref target="RFC8445" sectionFormat="of"
section="5.1.2.2"/>.</t>
<t>Unlike with SDP used in conjunction with ICE, this protocol only
creates a single UDP flow between the two communicating hosts, so only
a single component exists. Hence, the component ID value
<bcp14>MUST</bcp14> always be set to 1.</t>
<t>As defined in <xref target="RFC8445" sectionFormat="of"
section="14.3"/>, the retransmission timeout (RTO) for address
gathering from a Control/Data Relay Server <bcp14>SHOULD</bcp14> be
calculated as follows:</t>
<t indent="3">
RTO = MAX (1000 ms, Ta * (Num-Of-Cands))
</t>
<t>where Ta is the value used for the connectivity check pacing and
Num-Of-Cands is the number of server-reflexive and relay candidates. A
smaller value than 1000 ms for the RTO <bcp14>MUST NOT</bcp14> be
used.</t>
</section> </section>
<section anchor="sec_nat_traversal_mode" numbered="true" toc="default">
<section anchor="sec:nat_traversal_mode" <name>NAT Traversal Mode Negotiation</name>
title="NAT Traversal Mode Negotiation"> <t> This section describes the usage of a non-critical parameter type
called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
<t> This section describes the usage of a non-critical parameter presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
type called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The p base exchange means that the end host supports NAT traversal
resence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP base exchan extensions described in this document. As the parameter is
ge means that non-critical (as defined in <xref target="RFC7401" sectionFormat="of"
the end-host supports NAT traversal extensions described in this section="5.2.1"/>), it can be ignored by an end host, which means that
document. As the parameter is non-critical (as defined in Section 5.2.1 the host is not required to support it or may decline to use it.</t>
of <xref target="RFC7401"/>), it can be ignored by a end-host, which <t> With registration with a Control/Data Relay Server, it is usually
means that the host is not required to support it or may decline to sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since
use it.</t> the Relay Server is assumed to be in public address space. Thus, the
Relay Server <bcp14>SHOULD</bcp14> propose the UDP-ENCAPSULATION mode
<t> With registration with a Control/Data Relay Server, it is usually su as the preferred or only mode. The NAT traversal mode negotiation in
fficient to use a HIP base exchange is illustrated in <xref
the UDP-ENCAPSULATION mode of NAT traversal since the Relay Server is as target="fig_nat_traversal_mode" format="default"/>. It is worth noting
sumed that the Relay Server could be located between the hosts, but is
to be in public address space. Thus, the Relay Server SHOULD propose the omitted here for simplicity.</t>
UDP-ENCAPSULATION mode as the preferred or only mode. The NAT <figure anchor="fig_nat_traversal_mode">
traversal mode negotiation in a HIP base exchange is illustrated in <name>Negotiation of NAT Traversal Mode</name>
<xref target="fig:nat_traversal_mode"/>. It is worth noting that the <artwork align="center" name="" type="" alt=""><![CDATA[
Relay Server could be located between the hosts, but is omitted here for
simplicity.</t>
<figure anchor="fig:nat_traversal_mode"
title="Negotiation of NAT Traversal Mode">
<artwork align="center"><![CDATA[
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+----------------------------------------------------------------->| +----------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) |
|<-----------------------------------------------------------------+ |<-----------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))| | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+----------------------------------------------------------------->| +----------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., ENC(LOC_SET), ..)) | | 4. UDP(R2(.., ENC(LOC_SET), ..)) |
|<-----------------------------------------------------------------+ |<-----------------------------------------------------------------+
| | | |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> In step 1, the Initiator sends an I1 to the Responder.</t>
<t> In step 1, the Initiator sends an I1 to the Responder. In step 2, <t>In step 2,
the Responder responds with an R1. As specified in <xref target="RFC577 the Responder responds with an R1. As specified in <xref
0"/>, target="RFC5770" format="default"/>, the NAT_TRAVERSAL_MODE parameter
the NAT_TRAVERSAL_MODE parameter in in R1 contains a list of NAT traversal modes the Responder
R1 contains a list of NAT traversal modes the Responder supports. The supports. The mode specified in this document is ICE-HIP-UDP (value
mode specified in this document is ICE-HIP-UDP (value [TBD by IANA: 3]). 3).</t>
</t>
<t> In step 3, the Initiator sends an I2 that includes a <t> In step 3, the Initiator sends an I2 that includes a
NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
Initiator from the list of modes offered by the Responder. If ICE-HIP-UD Initiator from the list of modes offered by the Responder. If
P mode ICE-HIP-UDP mode was selected, the I2 also includes the "Transport
was selected, the I2 also includes the "Transport address" locators (as address" locators (as defined in <xref target="sec_locator_format"
defined in <xref target="sec:locator_format"/>) of the Initiator in a format="default"/>) of the Initiator in a LOCATOR_SET parameter
LOCATOR_SET parameter (denoted here with LOC_SET). (denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET
With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated wi parameter <bcp14>MUST</bcp14> be encapsulated within an ENCRYPTED
thin an ENCRYPTED parameter (denoted here with ENC) parameter (denoted here with ENC) according to the procedures in
according to the procedures in sections 5.2.18 and 6.5 in <xref target=" Sections <xref target="RFC7401" section="5.2.18"
RFC7401" />. sectionFormat="bare"/> and <xref target="RFC7401" section="6.5"
The locators in I2 are the "HIP offer".</t> sectionFormat="bare"/> in <xref target="RFC7401"
format="default"/>. The locators in I2 are the "HIP offer".</t>
<t> In step 4, the Responder concludes the base exchange with an R2 <t> In step 4, the Responder concludes the base exchange with an R2
packet. If the Initiator chose ICE-HIP-UDP traversal mode, the Responder packet. If the Initiator chose ICE-HIP-UDP traversal mode, the
includes a LOCATOR_SET parameter in the R2 packet. Responder includes a LOCATOR_SET parameter in the R2 packet. With
With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated wi ICE-HIP-UDP mode, the LOCATOR_SET parameter <bcp14>MUST</bcp14> be
thin an ENCRYPTED parameter encapsulated within an ENCRYPTED parameter according to the procedures
according to the procedures in sections 5.2.18 and 6.5 in <xref target=" in Sections <xref target="RFC7401" section="5.2.18"
RFC7401" />. sectionFormat="bare"/> and <xref target="RFC7401" section="6.5"
The locators in R2, encoded like the locators in I2, are the "ICE answer" sectionFormat="bare"/> in <xref target="RFC7401"
. If the NAT format="default"/>. The locators in R2, encoded like the locators in
traversal mode selected by the Initiator is not supported by the I2, are the "ICE answer". If the NAT traversal mode selected by the
Responder, the Responder SHOULD reply with a NOTIFY packet with type Initiator is not supported by the Responder, the Responder
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.</t> <bcp14>SHOULD</bcp14> reply with a NOTIFY packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.</t>
</section> </section>
<section anchor="sec_check_pacing_neg" numbered="true" toc="default">
<section anchor="sec:check_pacing_neg" <name>Connectivity Check Pacing Negotiation</name>
title="Connectivity Check Pacing Negotiation"> <t> As explained in Legacy ICE-HIP <xref target="RFC5770" format="defaul
t"/>, when a NAT
<t> As explained in Legacy ICE-HIP <xref target="RFC5770"/>, when a NAT
traversal mode with connectivity checks is used, new transactions traversal mode with connectivity checks is used, new transactions
should not be started too fast to avoid congestion and overwhelming the should not be started too fast to avoid congestion and overwhelming the
NATs. For this purpose, during the base exchange, hosts can negotiate a NATs. For this purpose, during the base exchange, hosts can negotiate a
transaction pacing value, Ta, using a TRANSACTION_PACING parameter in transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
R1 and I2 packets. The parameter contains the minimum time (expressed R1 and I2 packets. The parameter contains the minimum time (expressed
in milliseconds) the host would wait between two NAT traversal in milliseconds) the host would wait between two NAT traversal
transactions, such as starting a new connectivity check or retrying a transactions, such as starting a new connectivity check or retrying a
previous check. The value that is used by both of the hosts is the highe r previous check. The value that is used by both of the hosts is the highe r
of the two offered values.</t> of the two offered values.</t>
<t> The minimum Ta value <bcp14>SHOULD</bcp14> be configurable, and if
<t> The minimum Ta value SHOULD be configurable, and if no no value is configured, a value of 50 ms <bcp14>MUST</bcp14> be
value is configured, a value of 50 ms MUST be used. Guidelines for selecting a Ta value are given in <xref
used. Guidelines for selecting a Ta value are given in <xref target="sec_selecting_pacing_value" format="default"/>. Hosts
target="sec:selecting_pacing_value"/>. Hosts MUST NOT use <bcp14>MUST NOT</bcp14> use values smaller than 5 ms for the minimum
values smaller than 5 ms for the minimum Ta, since such Ta, since such values may not work well with some NATs (as explained
values may not work well with some NATs (as explained in <xref in <xref target="RFC8445" format="default"/>). The Initiator
target="RFC8445"/>). The Initiator MUST NOT propose a smaller <bcp14>MUST NOT</bcp14> propose a smaller value than what the
value than what the Responder offered. If a host does not Responder offered. If a host does not include the TRANSACTION_PACING
include the TRANSACTION_PACING parameter in the base exchange, parameter in the base exchange, a Ta value of 50 ms
a Ta value of 50 ms MUST be used as that host's minimum <bcp14>MUST</bcp14> be used as that host's minimum value.</t>
value.</t>
</section> </section>
<section anchor="sec_relay_bex" numbered="true" toc="default">
<section anchor="sec:relay_bex" <name>Base Exchange via Control Relay Server</name>
title="Base Exchange via Control Relay Server"> <t> This section describes how the Initiator and Responder perform a
base exchange through a Control Relay Server. Connectivity pacing
<t> This section describes how the Initiator and Responder (denoted as TA_P here) was described in <xref
perform a base exchange through a Control Relay Server. target="sec_check_pacing_neg" format="default"/> and is not repeated
Connectivity pacing (denoted as TA_P here) was described in here. Similarly, the NAT traversal mode negotiation process (denoted
<xref target="sec:check_pacing_neg"/> and is not repeated as NAT_TM in the example) was described in <xref
here. Similarly, the NAT traversal mode negotiation process target="sec_nat_traversal_mode" format="default"/> and is also not
(denoted as NAT_TM in the example) was described in <xref repeated here. If a Control Relay Server receives an R1 or I2 packet
target="sec:nat_traversal_mode"/> and is also not repeated without the NAT traversal mode parameter, it <bcp14>MUST</bcp14> drop
here. If it and <bcp14>SHOULD</bcp14> send a NOTIFY error packet with type
a Control Relay Server receives an R1 or I2 packet without the NAT trave NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or
rsal I2.</t>
mode parameter, it MUST drop it and SHOULD send a NOTIFY error <t> It is <bcp14>RECOMMENDED</bcp14> that the Initiator send an I1 packe
packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the t
sender of the R1 or I2.
</t>
<t> It is RECOMMENDED that the Initiator send an I1 packet
encapsulated in UDP when it is destined to an IP address of the encapsulated in UDP when it is destined to an IP address of the
Responder. Respectively, the Responder MUST respond to such an I1 Responder. Respectively, the Responder <bcp14>MUST</bcp14> respond to su ch an I1
packet with a UDP-encapsulated R1 packet, and also the rest of the commu nication packet with a UDP-encapsulated R1 packet, and also the rest of the commu nication
related to the HIP association MUST also use UDP encapsulation.</t> related to the HIP association <bcp14>MUST</bcp14> also use UDP encapsul
ation.</t>
<t><xref target="fig:bex"/> illustrates a base exchange <t><xref target="fig_bex" format="default"/> illustrates a base
via a Control Relay Server. We assume that the Responder (i.e. a Control exchange via a Control Relay Server. We assume that the Responder
Relay Client) (i.e., a Control Relay Client) has already registered to the Control
has already registered to the Control Relay Server. The Initiator may ha Relay Server. The Initiator may have also registered to another (or
ve also registered the same Control Relay Server), but the base exchange will traverse
to another (or the same Control Relay Server), but the base exchange wil always through the Control Relay Server of the Responder.</t>
l traverse always through <figure anchor="fig_bex">
the Control Relay Server of the Responder. <name>Base Exchange via a HIP Relay Server</name>
</t> <artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig:bex" title="Base Exchange via a HIP Relay Server">
<artwork align="center"><![CDATA[
Initiator Control Relay Server Responder Initiator Control Relay Server Responder
| 1. UDP(I1) | | | 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) | +--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TM, | | | 3. UDP(R1(RELAY_TO, NAT_TM, |
| | TA_P)) | | | TA_P)) |
| 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+
| TA_P)) | | | TA_P)) | |
|<---------------------------------+ | |<---------------------------------+ |
skipping to change at line 932 skipping to change at line 837
| NAT_TM, TA_P)) | | | NAT_TM, TA_P)) | |
+--------------------------------->| 6. UDP(I2(ENC(LOC_SET), | +--------------------------------->| 6. UDP(I2(ENC(LOC_SET), |
| | RELAY_FROM, NAT_TM, TA_P))| | | RELAY_FROM, NAT_TM, TA_P))|
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(ENC(LOC_SET), | | | 7. UDP(R2(ENC(LOC_SET), |
| 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) | | 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) |
| RELAY_TO)) |<-------------------------------+ | RELAY_TO)) |<-------------------------------+
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t> In step 1 of <xref target="fig_bex" format="default"/>, the
<t> In step 1 of <xref target="fig:bex"/>, the Initiator sends an I1 Initiator sends an I1 packet over UDP via the Control Relay Server to
packet over UDP via the Control Relay Server to the Responder. In the HI the Responder. In the HIP header, the source HIT belongs to the
P header, Initiator and the destination HIT to the Responder. The Initiator
the source HIT belongs to the Initiator and the destination HIT to the sends the I1 packet from its IP address to the IP address of the
Responder. The initiator sends the I1 packet from its IP address to the Control Relay Server over UDP.</t>
IP address of the Control Relay Server over UDP.</t>
<t> In step 2, the Control Relay Server receives the I1 packet. If the <t> In step 2, the Control Relay Server receives the I1 packet. If the
destination HIT belongs to a successfully registered Control Relay Clien destination HIT belongs to a successfully registered Control Relay
t (i.e., the host marked "Responder" in <xref target="fig:bex"/>), the Control R Client (i.e., the host marked "Responder" in <xref target="fig_bex"
elay Server processes format="default"/>), the Control Relay Server processes the
the packet. Otherwise, the Control Relay Server MUST drop the packet sil packet. Otherwise, the Control Relay Server <bcp14>MUST</bcp14> drop
ently. The the packet silently. The Control Relay Server appends a RELAY_FROM
Control Relay Server appends a RELAY_FROM parameter to the I1 packet, wh parameter to the I1 packet, which contains the transport source
ich contains address and port of the I1 as observed by the Control Relay
the transport source address and port of the I1 as observed by the Server. The Control Relay Server protects the I1 packet with
Control Relay Server. The Control Relay Server protects the I1 packet wi RELAY_HMAC, except that the parameter type is different as described
th RELAY_HMAC, in <xref target="sec_relay-hmac" format="default"/>. The Control Relay
except that the parameter type is different as described in Server changes the source and destination ports and IP addresses of
<xref target="sec:relay-hmac"/>. The Control Relay Server changes the so the packet to match the values the Responder used when registering to
urce and the Control Relay Server, i.e., the reverse of the R2 used in the
destination ports and IP addresses of the packet to match the values registration. The Control Relay Server <bcp14>MUST</bcp14> recalculate
the Responder used when registering to the Control Relay Server, i.e., t the transport checksum and forward the packet to the Responder. </t>
he reverse of
the R2 used in the registration. The Control Relay Server MUST recalcula
te the
transport checksum and forward the packet to the Responder. </t>
<t> In step 3, the Responder receives the I1 packet. The Responder <t> In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in <xref target="RFC7401"/>. In processes it according to the rules in <xref target="RFC7401"
addition, the Responder validates the RELAY_HMAC according to <xref targ format="default"/>. In addition, the Responder validates the
et="sec:relay-hmac"/> RELAY_HMAC according to <xref target="sec_relay-hmac"
and silently drops the packet if the validation format="default"/> and silently drops the packet if the validation
fails. The Responder replies with an R1 packet to which it includes fails. The Responder replies with an R1 packet to which it includes
RELAY_TO and NAT traversal mode parameters. The responder MUST RELAY_TO and NAT traversal mode parameters. The Responder
include ICE-HIP-UDP in the NAT traversal modes. <bcp14>MUST</bcp14> include ICE-HIP-UDP in the NAT traversal
The RELAY_TO parameter MUST modes. The RELAY_TO parameter <bcp14>MUST</bcp14> contain the same
contain the same information as the RELAY_FROM parameter, i.e., the information as the RELAY_FROM parameter, i.e., the Initiator's
Initiator's transport address, but the type of the parameter is transport address, but the type of the parameter is different. The
different. The RELAY_TO parameter is not integrity protected by the RELAY_TO parameter is not integrity protected by the signature of the
signature of the R1 to allow pre-created R1 packets at the R1 to allow pre-created R1 packets at the Responder. </t>
Responder. </t> <t> In step 4, the Control Relay Server receives the R1 packet. The
Control Relay Server drops the packet silently if the source HIT
<t> In step 4, the Control Relay Server receives the R1 packet. The Cont belongs to a Control Relay Client that has not successfully
rol Relay Server drops the registered. The Control Relay Server <bcp14>MAY</bcp14> verify the
packet silently if the source HIT belongs to a Control Relay Client that signature of the R1 packet and drop it if the signature is
has not successfully registered. The invalid. Otherwise, the Control Relay Server rewrites the source
Control Relay Server MAY verify the signature of the R1 packet and drop address and port, and changes the destination address and port to
it if the match RELAY_TO information. Finally, the Control Relay Server
signature is invalid. Otherwise, the Control Relay Server rewrites the s recalculates the transport checksum and forwards the packet. </t>
ource address
and port, and changes the destination address and port to match
RELAY_TO information. Finally, the Control Relay Server recalculates the
transport
checksum and forwards the packet. </t>
<!-- XX FIXME: remove HIP candidate term -->
<t> In step 5, the Initiator receives the R1 packet and processes it <t> In step 5, the Initiator receives the R1 packet and processes it
according to <xref target="RFC7401"/>. The Initiator MAY use the according to <xref target="RFC7401" format="default"/>. The Initiator
address in the RELAY_TO parameter as a local peer-reflexive candidate <bcp14>MAY</bcp14> use the address in the RELAY_TO parameter as a
for this HIP association if it is different from all known local local peer-reflexive candidate for this HIP association if it is
candidates. The Initiator replies with an I2 packet that uses the different from all known local candidates. The Initiator replies with
destination transport address of R1 as the source address and port. The an I2 packet that uses the destination transport address of R1 as the
I2 packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter source address and port. The I2 packet contains a LOCATOR_SET
that lists all the HIP parameter inside an ENCRYPTED parameter that lists all the HIP
candidates (HIP offer) of the Initiator. The candidates are encoded candidates (HIP offer) of the Initiator. The candidates are encoded
using the format defined in <xref target="sec:locator_format"/>. The I2 using the format defined in <xref target="sec_locator_format"
packet MUST also contain a NAT traversal mode parameter that includes IC format="default"/>. The I2 packet <bcp14>MUST</bcp14> also contain a
E-HIP-UDP mode. NAT traversal mode parameter that includes ICE-HIP-UDP mode. The
The ENCRYPTED parameter along with its key material generation are descr ENCRYPTED parameter along with its key material generation is
ibed in detail described in detail in Sections <xref target="RFC7401"
in sections 5.2.18 and 6.5 in <xref target="RFC7401" />.</t> section="5.2.18" sectionFormat="bare"/> and <xref target="RFC7401"
section="6.5" sectionFormat="bare"/> in <xref target="RFC7401"
<t> In step 6, the Control Relay Server receives the I2 packet. The Cont format="default"/>.</t>
rol Relay Server appends a <t> In step 6, the Control Relay Server receives the I2 packet. The
RELAY_FROM and a RELAY_HMAC to the I2 packet similarly as explained in s Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
tep packet similar to that explained in step 2, and forwards the packet to
2, and forwards the packet to the Responder. </t> the Responder. </t>
<t> In step 7, the Responder receives the I2 packet and processes it <t> In step 7, the Responder receives the I2 packet and processes it
according to <xref target="RFC7401"/>. according to <xref target="RFC7401" format="default"/>. The Responder
The Responder validates the RELAY_HMAC according to <xref target="sec:rel validates the RELAY_HMAC according to <xref target="sec_relay-hmac"
ay-hmac"/> format="default"/> and silently drops the packet if the validation
and silently drops the packet if the validation fails. It replies with an R2 packet and includes a RELAY_TO parameter
fails. as explained in step 3. The R2 packet includes a LOCATOR_SET parameter
It replies with an R2 packet and inside an ENCRYPTED parameter that lists all the HIP candidates (ICE
includes a RELAY_TO parameter as explained in step 3. The R2 packet
includes a LOCATOR_SET parameter inside an ENCRYPTED parameter that list
s all the HIP candidates (ICE
answer) of the Responder. The RELAY_TO parameter is protected by the answer) of the Responder. The RELAY_TO parameter is protected by the
HMAC. The ENCRYPTED parameter along with its key material generation are Hashed Message Authentication Code (HMAC). The ENCRYPTED parameter
described in detail along with its key material generation is described in detail in
in sections 5.2.18 and 6.5 in <xref target="RFC7401" />.</t> Sections <xref target="RFC7401" section="5.2.18"
sectionFormat="bare"/> and <xref target="RFC7401" section="6.5"
<t> In step 8, the Control Relay Server processes the R2 as described in sectionFormat="bare"/> in <xref target="RFC7401"
step 4. The format="default"/>.</t>
Control Relay Server forwards the packet to the Initiator. After the Ini <t> In step 8, the Control Relay Server processes the R2 as described
tiator has in step 4. The Control Relay Server forwards the packet to the
received the R2 and processed it successfully, the base exchange is Initiator. After the Initiator has received the R2 and processed it
completed. </t> successfully, the base exchange is completed. </t>
<t> Hosts <bcp14>MUST</bcp14> include the address of one or more
<t> Hosts MUST include the address of one or more Control Relay Servers Control Relay Servers (including the one that is being used for the
(including the one that is being used for the initial signaling) in the initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages
LOCATOR_SET parameter in I2 and R2 messages if they intend to use such s if they intend to use such servers for relaying HIP signaling
ervers for immediately after the base exchange completes. The traffic type of
relaying HIP signaling immediately after the base exchange completes. these addresses <bcp14>MUST</bcp14> be "HIP signaling" (see <xref
The traffic type of these addresses MUST be "HIP signaling" (see <xref t target="sec_locator_format" format="default"/>) and they <bcp14>MUST
arget="sec:locator_format" />) and they NOT</bcp14> be used for the connectivity tests described in <xref
MUST NOT be used for the connectivity tests described in <xref target="s target="sec_conn_checks" format="default"/>. If the Control Relay
ec:conn_checks" />. If the Control Relay Server locator Server locator used for relaying the base exchange is not included in
used for relaying the base exchange is not included in I2 or R2 LOCATOR_ I2 or R2 LOCATOR_SET parameters, it <bcp14>SHOULD NOT</bcp14> be used
SET parameters, after the base exchange. Instead, further HIP signaling
it SHOULD NOT be used after the base exchange. Instead, further HIP <bcp14>SHOULD</bcp14> use the same path as the data traffic. It is
signaling SHOULD use the same path as the data traffic. It is RECOMMENDE <bcp14>RECOMMENDED</bcp14> to use the same Control Relay Server
D to use the throughout the lifetime of the host association that was used for
same Control Relay Server throughout the lifetime of the host association forwarding the base exchange if the Responder includes it in the
that locator parameter of the R2 message.</t>
was used for forwarding the base exchange if the Responder includes it i </section>
n the locator parameter of the R2 message.</t>
</section> <!-- Base Exchange via HIP Relay Server -->
<section anchor="sec:conn_checks" title="Connectivity Checks">
<t>When the Initiator and Responder complete the base exchange
through the Control Relay Server, both of them employ the IP address of
the Control Relay Server as the destination address for the packets.
The address of the Control Relay Server MUST NOT be used as a destination
for data plane traffic unless
the server supports also Data Relay Server functionality, and the Client
has successfully
registered to use it.
When NAT
traversal mode with ICE-HIP-UDP was successfully negotiated
and selected, the Initiator and Responder MUST start the
connectivity checks in order to attempt to obtain direct end-to-end
connectivity through NAT devices. It is worth noting that the connectivi
ty checks
MUST be completed even though no ESP_TRANSFORM would be negotiated and s
elected.
</t>
<section anchor="sec_conn_checks" numbered="true" toc="default">
<name>Connectivity Checks</name>
<t>When the Initiator and Responder complete the base exchange through
the Control Relay Server, both of them employ the IP address of the
Control Relay Server as the destination address for the packets. The
address of the Control Relay Server <bcp14>MUST NOT</bcp14> be used as
a destination for data plane traffic unless the server also supports
Data Relay Server functionality, and the Client has successfully
registered to use it. When NAT traversal mode with ICE-HIP-UDP was
successfully negotiated and selected, the Initiator and Responder
<bcp14>MUST</bcp14> start the connectivity checks in order to attempt
to obtain direct end-to-end connectivity through NAT devices. It is
worth noting that the connectivity checks <bcp14>MUST</bcp14> be
completed even though no ESP_TRANSFORM would be negotiated and
selected.</t>
<t>The connectivity checks follow the ICE methodology <xref <t>The connectivity checks follow the ICE methodology <xref
target="I-D.rosenberg-mmusic-ice-nonsip"/>, but UDP encapsulated HIP con target="I-D.rosenberg-mmusic-ice-nonsip" format="default"/>, but
trol UDP-encapsulated HIP control messages are used instead of ICE
messages are used instead of ICE messages. messages. As stated in the ICE specification, the basic procedure for
As stated in the ICE specification, the basic procedure for connectivity connectivity checks has three phases: sorting the candidate pairs
checks has three phases: according to their priority, sending checks in the prioritized order,
sorting the candidate pairs according their priority, sending checks in t and acknowledging the checks from the peer host.
he prioritized order and </t>
acknowledging the checks from the peer host.
</t>
<t>The Initiator MUST take the role of controlling host and
the Responder acts as the controlled host. The roles MUST
persist throughout the HIP associate lifetime (to be reused in
the possibly mobility UPDATE procedures). In the case both
communicating nodes are initiating the communications to each
other using an I1 packet, the conflict is resolved as defined
in section 6.7 in <xref target="RFC7401" />: the host with the
"larger" HIT changes to its Role to Responder. In such a case,
the host changing its role to Responder MUST also switch to
controlled role.
</t>
<t>The protocol follows standard HIP UPDATE sending and <t>The Initiator <bcp14>MUST</bcp14> take the role of controlling
processing rules as defined in section 6.11 and 6.12 in <xref host, and the Responder acts as the controlled host. The roles
target="RFC7401" />, but some new parameters are introduced <bcp14>MUST</bcp14> persist throughout the HIP associate lifetime (to
(CANDIDATE_PRIORITY, MAPPED_ADDRESS and NOMINATE).</t> be reused even during mobility UPDATE procedures). In the case in
which both communicating nodes are initiating communication to
each other using an I1 packet, the conflict is resolved as defined in
<xref target="RFC7401" sectionFormat="of" section="6.7"/>; the host
with the "larger" HIT changes its role to Responder. In such a
case, the host changing its role to Responder <bcp14>MUST</bcp14> also
switch to the controlled role.</t>
<section anchor="sec:conn_check_proc" title="Connectivity Check Procedur <t>The protocol follows standard HIP UPDATE sending and processing
e"> rules as defined in Sections <xref target="RFC7401" section="6.11"
sectionFormat="bare"/> and <xref target="RFC7401" section="6.12"
sectionFormat="bare"/> in <xref target="RFC7401" format="default"/>,
but some new parameters are introduced (CANDIDATE_PRIORITY,
MAPPED_ADDRESS, NOMINATE, PEER_PERMISSION, and RELAYED_ADDRESS).</t>
<t><xref target="fig:cc1"/> illustrates connectivity checks <section anchor="sec_conn_check_proc" numbered="true" toc="default">
in a simplified scenario, where the Initiator and Responder <name>Connectivity Check Procedure</name>
<t><xref target="fig_cc1" format="default"/> illustrates connectivity
checks
in a simplified scenario where the Initiator and Responder
have only a single candidate pair to check. Typically, NATs have only a single candidate pair to check. Typically, NATs
drop messages until both sides have sent messages using the drop messages until both sides have sent messages using the
same port pair. In this scenario, the Responder sends a same port pair. In this scenario, the Responder sends a
connectivity check first but the NAT of the Initiator drops connectivity check first but the NAT of the Initiator drops
it. However, the connectivity check from the Initiator it. However, the connectivity check from the Initiator
reaches the Responder because it uses the same port pair as reaches the Responder because it uses the same port pair as
the first message. It is worth noting that the message flow the first message. It is worth noting that the message flow
in this section is idealistic, and, in practice, more in this section is idealistic, and, in practice, more
messages would be dropped, especially in the beginning. For messages would be dropped, especially in the beginning. For
instance, connectivity tests always start with the instance, connectivity tests always start with the
candidates with the highest priority, which would be host candidates with the highest priority, which would be host
candidates (which would not reach the recipient in this candidates (which would not reach the recipient in this
scenario).</t> scenario).</t>
<figure anchor="fig_cc1">
<?rfc needLines="30" ?> <name>Connectivity Checks</name>
<figure anchor="fig:cc1" title="Connectivity Checks"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
Initiator NAT1 NAT2 Responder Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | | | | ECHO_REQ_SIGN)) | |
| X<-----------------------------------+----------------+ | X<-----------------------------------+----------------+
| | | | | | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->| +-------------+------------------------------------+--------------->|
| | | | | | | |
| 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
|<------------+------------------------------------+----------------+ |<------------+------------------------------------+----------------+
skipping to change at line 1122 skipping to change at line 1037
| 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | | | NOMINATE)) | |
|<------------+------------------------------------+----------------+ |<------------+------------------------------------+----------------+
| | | | | | | |
| 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
+-------------+------------------------------------+--------------->+ +-------------+------------------------------------+--------------->+
| | | | | | | |
| 10. ESP data traffic over UDP | | | 10. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+ +<------------+------------------------------------+--------------->+
| | | | | | | |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t>In step 1, the Responder sends a connectivity check to the <t>In step 1, the Responder sends a connectivity check to the
Initiator that the NAT of the Initiator drops. The message Initiator that the NAT of the Initiator drops. The message includes
includes a number of parameters. As specified in <xref a number of parameters. As specified in <xref target="RFC7401"
target="RFC7401" />), the SEQ parameter includes a running format="default"/>, the SEQ parameter includes a running sequence
sequence identifier for the connectivity check. identifier for the connectivity check. The candidate priority
The candidate priority (denoted "CAND_PRIO" in the figure) (denoted CAND_PRIO in the figure) describes the priority of the
describes the priority of the address candidate being address candidate being tested. The ECHO_REQUEST_SIGNED (denoted
tested. The ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the ECHO_REQ_SIGN in the figure) includes a nonce that the recipient
figure) includes a nonce that the recipient must sign and echo back as must sign and echo back as it is.</t>
it is.</t>
<t>In step 2, the Initiator sends a connectivity check, using <t>In step 2, the Initiator sends a connectivity check, using
the same address pair candidate as in the previous step, and the the same address pair candidate as in the previous step, and the
message traverses successfully the NAT boxes. The message message successfully traverses the NAT boxes. The message
includes the same parameters as in the previous step. It includes the same parameters as in the previous step. It
should be noted that the sequence identifier is locally should be noted that the sequence identifier is locally
assigned by the Initiator, so it can be different than in assigned by the Initiator, so it can be different than in
the previous step.</t> the previous step.</t>
<t>In step 3, the Responder has successfully received the previous
<!-- XX FIXME: explain what happens to the SEQ ids of dropped packets a connectivity check from the Initiator and starts to build a response
nd SEQ window --> message. Since the message from the Initiator included a SEQ, the
Responder must acknowledge it using an ACK parameter. Also, the
<t>In step 3, the Responder has successfully received the nonce contained in the echo request must be echoed back in an
previous connectivity check from the Initiator and starts to build a r ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The
esponse message. Since the Responder also includes a MAPPED_ADDRESS parameter (denoted
message from the Initiator included a SEQ, the Responder must acknowle MAPPED_ADDR in the figure) that contains the transport address of
dge it using an ACK the Initiator as observed by the Responder (i.e., peer-reflexive
parameter. Also, the nonce contained in the echo request must candidate). This message is successfully delivered to the Initiator;
be echoed back in an ECHO_RESPONSE_SIGNED (denoted upon reception, the Initiator marks the candidate pair as valid.</t>
ECHO_RESP_SIGN) parameter. The
Responder includes also a MAPPED_ADDRESS parameter (denoted MAPPED_ADD
R in the figure) that
contains the transport address of the Initiator as observed by
the Responder (i.e. peer reflexive candidate). This message is success
fully delivered to the Initiator, and upon reception
the Initiator marks the candidate pair as valid.
</t>
<t>In step 4, the Responder retransmits the connectivity <t>In step 4, the Responder retransmits the connectivity
check sent in the first step, since it was not acknowledged check sent in the first step, since it was not acknowledged
yet.</t> yet.</t>
<t>In step 5, the Initiator responds to the previous <t>In step 5, the Initiator responds to the previous
connectivity check message from the Responder. The Initiator connectivity check message from the Responder. The Initiator
acknowledges the SEQ parameter from the previous message acknowledges the SEQ parameter from the previous message
using ACK parameter and the ECHO_REQUEST_SIGNED parameter with using an ACK parameter and the ECHO_REQUEST_SIGNED parameter with
ECHO_RESPONSE_SIGNED. In addition, it includes MAPPED_ADDR ECHO_RESPONSE_SIGNED. In addition, it includes the MAPPED_ADDR
parameter that includes the peer reflexive candidate. This parameter that includes the peer-reflexive candidate. This
response message is successfully delivered to the response message is successfully delivered to the
Responder, and upon reception the Initiator marks the candidate pair a Responder; upon reception, the Initiator marks the candidate pair as v
s valid.</t> alid.</t>
<t>In step 6, despite the two hosts now having valid address
<t>In step 6, despite the two hosts now having valid address
candidates, the hosts still test the remaining address candidates candidates, the hosts still test the remaining address candidates
in a similar way as in the previous steps. It should be noted that each in a similar way as in the previous steps. It should be noted that each
connectivity check has a unique sequence number in the SEQ connectivity check has a unique sequence number in the SEQ
parameter.</t> parameter.</t>
<t>In step 7, the Initiator has completed testing all <t>In step 7, the Initiator has completed testing all
address candidates and nominates one address candidate to be address candidates and nominates one address candidate to be
used. It sends an UPDATE message using the selected address used. It sends an UPDATE message using the selected address
candidates that includes a number of parameters: SEQ, candidates that includes a number of parameters: SEQ,
ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the NOMINATE parameter.</t ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY, and the NOMINATE parameter.</
> t>
<t>In step 8, the Responder receives the message with the NOMINATE
<t>In step 8, the Responder receives the message with parameter from the Initiator. It sends a response that includes the
NOMINATE parameter from the Initiator. It sends a response NOMINATE parameter in addition to a number of other parameters. The
that includes the NOMINATE parameter in addition to a number ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
of other parameters. The ACK and ECHO_RESPONSE_SIGNED parameters ECHO_REQUEST_SIGNED parameters from the previous message from the
acknowledge the SEQ and ECHO_REQUEST_SIGNED parameters from previous m
essage from the
Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED
parameters in order to receive an acknowledgment from the parameters in order to receive an acknowledgment from the
Responder.</t> Responder.</t>
<t>In step 9, the Initiator completes the candidate <t>In step 9, the Initiator completes the candidate
nomination process by confirming the message reception to nomination process by confirming the message reception to
the Responder. In the confirmation message, the ACK and the Responder. In the confirmation message, the ACK and
ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and
ECHO_REQUEST_SIGNED parameters in the message sent by the ECHO_REQUEST_SIGNED parameters in the message sent by the
Responder in the previous step.</t> Responder in the previous step.</t>
<t>In step 10, the Initiator and Responder can start sending <t>In step 10, the Initiator and Responder can start sending
application payload over the successfully nominated address application payload over the successfully nominated address
candidates.</t> candidates.</t>
<t>It is worth noting that if either host has registered a relayed
<t>It is worth noting that if either host has registered a address candidate from a Data Relay Server, the host
relayed address candidate from a Data Relay Server, the host MUST <bcp14>MUST</bcp14> activate the address before connectivity checks
activate the address before connectivity checks by sending by sending an UPDATE message containing the PEER_PERMISSION parameter a
an UPDATE message containing PEER_PERMISSION parameter as s
described in <xref target="sec:forwarding" />. Otherwise, described in <xref target="sec_forwarding"
the Data Relay Server drops ESP packets using the relayed address. format="default"/>. Otherwise, the Data Relay Server drops ESP
</t> packets using the relayed address.</t>
<t>It should be noted that in the case in which both the Initiator and
<t>It should be noted that in the case both Initiator and Responder are advertising their own relayed address
Responder both advertising their own relayed address
candidates, it is possible that the two hosts choose the two candidates, it is possible that the two hosts choose the two
relayed addresses as a result of the ICE nomination relayed addresses as a result of the ICE nomination
algorithm. While this is possible (and even could be algorithm. While this is possible (and even could be
desirable for privacy reasons), it can be unlikely due to desirable for privacy reasons), it can be unlikely due to
low priority assigned for the relayed address candidates. In low priority assigned for the relayed address candidates. In
such a event, the nominated address pair is always such an event, the nominated address pair is always
symmetric; the nomination algorithm prevents asymmetric symmetric; the nomination algorithm prevents asymmetric
address pairs (i.e. each side choosing different pair), such address pairs (i.e., each side choosing different pair) such
as a Data Relay Client using its own Data Relay Server to as a Data Relay Client using its own Data Relay Server to
send data directly to its peer while receiving data from the send data directly to its peer while receiving data from the
Data Relay Server of its peer. Data Relay Server of its peer.
</t>
</section> <!-- "Connectivity Check Procedure" -->
<!--
seq: 385
ack: 449
echo_req_sign: 897
echo_resp_sign: 961
mapped_address: 4660
cand_prio: 4700
NOMINATE: 4710
<section title="Rules for Connectivity Checks">
<!-- XX FIXME: should we explicitly explain here the ordering of the I
CE candidates? -->
<t>The HITs of the two communicating hosts MUST be used as
credentials in this protocol (in contrast to ICE which
employs username-password fragments). A HIT
pair uniquely identifies the corresponding HIT association,
and a SEQ number in an UPDATE message identifies a
particular connectivity check.</t>
<t>All of the connectivity check messages MUST be protected
with HIP_HMAC and signatures (even though the illustrations
in this specification omit them for simplicity) according to <xref tar
get="RFC7401"/>. Each connectivity check sent
by a host MUST include a SEQ parameter and ECHO_REQUEST_SIGNED
parameter, and correspondingly the peer MUST respond to
these using ACK and ECHO_RESPONSE_SIGNED according to the rules
specified in <xref target="RFC7401" />.
</t> </t>
</section>
<!-- <t>The host sending a connectivity check should check that <section numbered="true" toc="default">
the response uses also the same pair of UDP ports. If the <name>Rules for Connectivity Checks</name>
UDP ports do not match, the connectivity checks for this
candidate pair MUST be considered to have failed.</t>
XX FIXME: vurnerable to replay attacks??? <t>The HITs of the two communicating hosts <bcp14>MUST</bcp14> be
--> used as credentials in this protocol (in contrast to ICE, which
employs username-password fragments). A HIT pair uniquely identifies
the corresponding HIT association, and a SEQ number in an UPDATE
message identifies a particular connectivity check.</t>
<t>All of the connectivity check messages <bcp14>MUST</bcp14> be
protected with HIP_HMAC and signatures (even though the
illustrations in this specification omit them for simplicity)
according to <xref target="RFC7401" format="default"/>. Each
connectivity check sent by a host <bcp14>MUST</bcp14> include a SEQ
parameter and ECHO_REQUEST_SIGNED parameter; correspondingly, the
peer <bcp14>MUST</bcp14> respond to these using ACK and
ECHO_RESPONSE_SIGNED according to the rules specified in <xref
target="RFC7401" format="default"/>.</t>
<t>The host sending a connectivity check MUST validate that <t>The host sending a connectivity check <bcp14>MUST</bcp14> validate t hat
the response uses the same pair of UDP ports, and drop the the response uses the same pair of UDP ports, and drop the
packet if this is not the case.</t> packet if this is not the case.</t>
<t>A host may receive a connectivity check before it has received
<t>A host may receive a connectivity check before it has the candidates from its peer. In such a case, the host
received the candidates from its peer. In such a case, the <bcp14>MUST</bcp14> immediately queue a response by placing it in
host MUST immediately queue a response by placing it in the triggered-c the triggered-check queue and then continue waiting for the
heck queue, and then continue candidates. A host <bcp14>MUST NOT</bcp14> select a candidate pair
waiting for the candidates. A host MUST NOT select a until it has verified the pair using a connectivity check as defined
candidate pair until it has verified the pair using a in <xref target="sec_conn_check_proc" format="default"/>.</t>
connectivity check as defined in <xref <t><xref target="RFC7401" sectionFormat="of" section="5.3.5"/>
target="sec:conn_check_proc" />.</t> states that UPDATE packets have to include either a SEQ or ACK
parameter (but can include both). In the connectivity check
<t><xref target="RFC7401"/> section 5.3.5 states that UPDATE packets h procedure specified in <xref target="sec_conn_check_proc"
ave format="default"/>, each SEQ parameter should be acknowledged
to include either a SEQ or ACK parameter (but can include separately. In the context of NATs, this means that some of the SEQ
both). In the connectivity check procedure specified in <xref target=" parameters sent in connectivity checks will be lost or arrive out of
sec:conn_check_proc" />, each SEQ parameter should be order. From the viewpoint of the recipient, this is not a problem
acknowledged separately. In the context of NATs, this means since the recipient will just "blindly" acknowledge the
that some of the SEQ parameters sent in connectivity checks SEQ. However, the sender needs to be prepared for lost sequence
will be lost or arrive out of order. From the viewpoint of the identifiers and ACK parameters that arrive out of order.</t>
recipient, this is not a problem since the recipient <t>As specified in <xref target="RFC7401" format="default"/>, an ACK
will just "blindly" acknowledge the SEQ. However, the sender
needs to be prepared for lost sequence identifiers and ACKs
parameters that arrive out of order.</t>
<t>As specified in <xref target="RFC7401"/>, an ACK
parameter may acknowledge multiple sequence parameter may acknowledge multiple sequence
identifiers. While the examples in the previous sections do identifiers. While the examples in the previous sections do
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode.</t> employing ICE-HIP-UDP mode.</t>
<t>In ICE-HIP-UDP mode, a retransmission of a connectivity check
<t>In ICE-HIP-UDP mode, a retransmission of a connectivity <bcp14>SHOULD</bcp14> be sent with the same sequence identifier in
check SHOULD be sent with the same sequence identifier in the the SEQ parameter. Some tested address candidates will never produce
SEQ parameter. Some tested address candidates will never a working address pair and may thus cause retransmissions. Upon
produce a working address pair, and thus may cause successful nomination of an address pair, a host
retransmissions. Upon successful nomination of an address pair, <bcp14>SHOULD</bcp14> immediately stop sending such
a host SHOULD immediately stop sending such retransmissions.</t> retransmissions.</t>
<!-- XX FIXME: no lite mode anymore in ICE -->
<t>Full ICE procedures for prioritizing candidates, eliminating <t>Full ICE procedures for prioritizing candidates, eliminating
redundant candidates, forming check lists (including redundant candidates, forming checklists (including pruning), and
pruning) and triggered check-queues MUST be followed as specified in se triggered-check queues <bcp14>MUST</bcp14> be followed as specified
ction 6.1 <xref in <xref target="RFC8445" sectionFormat="of" section="6.1"/>, with
target="RFC8445"/>, with the exception of that the exception being that the foundation, frozen candidates, and
the foundation, frozen candidates and default candidates are not used. default candidates are not used. From the viewpoint of the ICE
From specification <xref target="RFC8445" format="default"/>, the
viewpoint of the ICE specification <xref target="RFC8445"/>, the protoc protocol specified in this document operates using a component ID of
ol specified in 1 on all candidates, and the foundation of all candidates is
this document operates using Component ID of 1 on all unique. This specification defines only "full ICE" mode, and the
candidates, and the foundation of all candidates is "lite ICE" is not supported. The reasoning behind the missing
unique. This specification defines only "full ICE" mode, and features is described in <xref target="sec_ice_diff"
the "lite ICE" is not supported. The reasoning behind format="default"/>.</t>
the missing features is described in <xref <t> The connectivity check messages <bcp14>MUST</bcp14> be paced by
target="sec:ice_diff" />.</t> the Ta value negotiated during the base exchange as described in
<xref target="sec_check_pacing_neg" format="default"/>. If neither
<t> The connectivity check messages MUST be paced by the Ta value one of the hosts announced a minimum pacing value, a value of 50 ms
negotiated during the base exchange as described in <xref <bcp14>MUST</bcp14> be used.</t>
target="sec:check_pacing_neg"/>. If neither one of the hosts announced <t>Both hosts <bcp14>MUST</bcp14> form a
a minimum pacing value, a value of 50 ms MUST be used. </t>
<t>Both hosts MUST form a
priority ordered checklist and begin to check transactions every Ta priority ordered checklist and begin to check transactions every Ta
milliseconds as long as the checks are running and there are candidate milliseconds as long as the checks are running and there are candidate
pairs whose tests have not started. The retransmission timeout (RTO) pairs whose tests have not started. The retransmission timeout (RTO)
for the connectivity check UPDATE packets SHOULD be calculated as foll for the connectivity check UPDATE packets <bcp14>SHOULD</bcp14> be
ows: calculated as follows:</t>
<t indent="3">
<list style="empty"> RTO = MAX (1000 ms, Ta * (Num-Waiting + Num-In-Progress))
<t>RTO = MAX (1000ms, Ta * (Num-Waiting + Num-In-Progress))</t>
</list>
</t> </t>
<t> In the RTO formula, Ta is the value used for the connectivity
<t> In the RTO formula, Ta is the value used for the check pacing, Num-Waiting is the number of pairs in the checklist in
connectivity check pacing, Num-Waiting is the number of the "Waiting" state, and Num-In-Progress is the number of pairs in
pairs in the checklist in the "Waiting" state, and the "In-Progress" state. This is identical to the formula in <xref
Num-In-Progress is the number of pairs in the "In-Progress" target="RFC8445" format="default"/> when there is only one
state. This is identical to the formula in <xref checklist. A smaller value than 1000 ms for the RTO <bcp14>MUST
target="RFC8445"/> when there is only one NOT</bcp14> be used.</t>
checklist. A smaller value than 1000 ms for the RTO MUST NOT <t> Each connectivity check request packet <bcp14>MUST</bcp14> contain
be used.</t> a
CANDIDATE_PRIORITY parameter (see <xref target="sec_con-check" format=
<t> Each connectivity check request packet MUST contain a "default"/>) with
CANDIDATE_PRIORITY parameter (see <xref target="sec:con-check"/>) with the priority value that would be assigned to a peer-reflexive candidat
the priority value that would be assigned to a peer reflexive candidat e
e
if one was learned from the corresponding check. An UPDATE packet that acknowledges if one was learned from the corresponding check. An UPDATE packet that acknowledges
a connectivity check request MUST be sent from the same address that a connectivity check request <bcp14>MUST</bcp14> be sent from the same address that
received the check and delivered to the same address where the check w as received received the check and delivered to the same address where the check w as received
from. Each acknowledgment UPDATE packet MUST contain a MAPPED_ADDRESS from. Each acknowledgment UPDATE packet <bcp14>MUST</bcp14> contain a MAPPED_ADDRESS
parameter with the port, protocol, and IP address of the address where parameter with the port, protocol, and IP address of the address where
the connectivity check request was received from.</t> the connectivity check request was received from.</t>
<!-- XX FIXME: reference UDP-over-ESP --> <t>Following the ICE guidelines <xref target="RFC8445"
format="default"/>, it is <bcp14>RECOMMENDED</bcp14> to restrict the
<t>Following the ICE guidelines <xref total number of connectivity checks to 100 for each host
target="RFC8445"/>, it is RECOMMENDED to association. This can be achieved by limiting the connectivity
restrict the total number of connectivity checks to 100 for each checks to the 100 candidate pairs with the highest priority.</t>
host association. This can be achieved by limiting the </section>
connectivity checks to the 100 candidate pairs with the
highest priority.</t>
</section> <!-- Rules for Connectivity Checks -->
<section title="Rules for Concluding Connectivity Checks">
<t>The controlling agent may find multiple working candidate
pairs. To conclude the connectivity checks, it SHOULD
nominate the pair with the highest priority. The controlling
agent MUST nominate a candidate pair essentially by
repeating a connectivity check using an UPDATE message that
contains a SEQ parameter (with new sequence number), a
ECHO_REQUEST_SIGNED parameter, the priority of the candidate
in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify
conclusion of the connectivity checks. Since the nominated
address pair has already been tested for reachability, the
controlled host should be able to receive the message. Upon
reception, the controlled host SHOULD select the nominated
address pair. The response message MUST include a SEQ
parameter with a new sequence id, acknowledgment of the
sequence from the controlling host in an ACK parameter, a
new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED parameter
corresponding to the ECHO_REQUEST_SIGNED parameter from the
controlling host and the NOMINATE parameter. After sending
this packet, the controlled host can create IPsec security
associations using the nominated address candidate for
delivering application payload to the controlling host. Since
the message from the controlled host included a new sequence
id and echo request for signature, the controlling host MUST
acknowledge this with a new UPDATE message that includes an
ACK and ECHO_RESPONSE_SIGNED parameters. After this final
concluding message, the controlling host also can create
IPsec security associations for delivering application payload
to the controlled host.
</t>
<t>It is possible that packets are delayed by the
network. Both hosts MUST continue to respond to any
connectivity checks despite an address pair having been nominated.</t>
<t> If all the connectivity checks have failed, the hosts MUST NOT sen
d ESP
traffic to each other but MAY continue communicating using HIP packets
and the locators used for the base exchange. Also, the hosts SHOULD
notify each other about the failure with a CONNECTIVITY_CHECKS_FAILED
NOTIFY packet (see <xref target="sec:notify-types"/>).</t>
</section> <!-- Rules for Concluding Connectivity Checks -->
</section> <!-- connectivity checks -->
<section anchor="sec:alternatives" title="NAT Traversal Optimizations"> <section numbered="true" toc="default">
<name>Rules for Concluding Connectivity Checks</name>
<t>The controlling agent may find multiple working candidate
pairs. To conclude the connectivity checks, it <bcp14>SHOULD</bcp14>
nominate the pair with the highest priority. The controlling agent
<bcp14>MUST</bcp14> nominate a candidate pair essentially by
repeating a connectivity check using an UPDATE message that contains
a SEQ parameter (with a new sequence number), an ECHO_REQUEST_SIGNED
parameter, the priority of the candidate in a CANDIDATE_PRIORITY
parameter, and a NOMINATE parameter to signify conclusion of the
connectivity checks. Since the nominated address pair has already
been tested for reachability, the controlled host should be able to
receive the message. Upon reception, the controlled host
<bcp14>SHOULD</bcp14> select the nominated address pair. The
response message <bcp14>MUST</bcp14> include a SEQ parameter with a
new sequence identifier, acknowledgment of the sequence from the contr
olling
host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter,
an ECHO_RESPONSE_SIGNED parameter corresponding to the
ECHO_REQUEST_SIGNED parameter from the controlling host, and the
NOMINATE parameter. After sending this packet, the controlled host
can create IPsec security associations using the nominated address
candidate for delivering application payload to the controlling
host. Since the message from the controlled host included a new
sequence identifier echo request for the signature, the controlling ho
st
<bcp14>MUST</bcp14> acknowledge this with a new UPDATE message that
includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this
final concluding message, the controlling host also can create IPsec
security associations for delivering application payload to the
controlled host.</t>
<t>It is possible that packets are delayed by the network. Both
hosts <bcp14>MUST</bcp14> continue to respond to any connectivity
checks despite an address pair having been nominated.</t>
<t> If all the connectivity checks have failed, the hosts
<bcp14>MUST NOT</bcp14> send ESP traffic to each other but
<bcp14>MAY</bcp14> continue communicating using HIP packets and the
locators used for the base exchange. Also, the hosts
<bcp14>SHOULD</bcp14> notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see <xref
target="sec_notify-types" format="default"/>).</t>
</section>
<section title="Minimal NAT Traversal Support" anchor="sec:minimal"> </section>
<section anchor="sec_alternatives" numbered="true" toc="default">
<name>NAT Traversal Optimizations</name>
<section anchor="sec_minimal" numbered="true" toc="default">
<name>Minimal NAT Traversal Support</name>
<t>If the Responder has a fixed and publicly reachable IPv4 <t>If the Responder has a fixed and publicly reachable IPv4
address and does not employ a Control Relay Server, the explicit NAT address and does not employ a Control Relay Server, the explicit NAT
traversal mode negotiation MAY be omitted, and thus even the traversal mode negotiation <bcp14>MAY</bcp14> be omitted; thus, even t he
UDP-ENCAPSULATION mode does not have to be negotiated. In UDP-ENCAPSULATION mode does not have to be negotiated. In
such a scenario, the Initiator sends an I1 message over UDP such a scenario, the Initiator sends an I1 message over UDP
and the Responder responds with an R1 message over UDP without and the Responder responds with an R1 message over UDP without
including any NAT traversal mode parameter. The rest of the including any NAT traversal mode parameter. The rest of the
base exchange follows the procedures defined in <xref base exchange follows the procedures defined in <xref
target="RFC7401"/>, except that the control and data plane target="RFC7401" format="default"/>, except that the control and
use UDP encapsulation. Here, the use of UDP for NAT data plane use UDP encapsulation. Here, the use of UDP for NAT
traversal is agreed implicitly. This way of operation is traversal is agreed upon implicitly. This way of operation is still
still subject to NAT timeouts, and the hosts MUST employ NAT subject to NAT timeouts, and the hosts <bcp14>MUST</bcp14> employ
keepalives as defined in <xref NAT keepalives as defined in <xref target="sec_nat-keepalives"
target="sec:nat-keepalives"/>.</t> format="default"/>.</t>
<t>When UDP-ENCAPSULATION mode is chosen either explicitly
or implicitly, the connectivity checks as defined in this
document MUST NOT be used. When hosts lose connectivity,
they MUST instead utilize <xref target="RFC8046" /> or <xref
target="RFC8047" /> procedures, but with the difference being that
UDP-based tunneling MUST be employed for the entire lifetime of
the corresponding Host Association.</t>
<t>When UDP-ENCAPSULATION mode is chosen either explicitly or
implicitly, the connectivity checks as defined in this document
<bcp14>MUST NOT</bcp14> be used. When hosts lose connectivity, they
<bcp14>MUST</bcp14> instead utilize <xref target="RFC8046"
format="default"/> or <xref target="RFC8047" format="default"/>
procedures, but with the difference being that UDP-based tunneling
<bcp14>MUST</bcp14> be employed for the entire lifetime of the
corresponding HIP association.</t>
</section> </section>
<section anchor="sec:no_relay" <section anchor="sec_no_relay" numbered="true" toc="default">
title="Base Exchange without Connectivity Checks"> <name>Base Exchange without Connectivity Checks</name>
<t>It is possible to run a base exchange without any connectivity
<t>It is possible to run a base exchange without any checks as defined in Legacy ICE-HIP (<xref target="RFC5770"
connectivity checks as defined in Legacy ICE-HIP section 4.8 <xref sectionFormat="of" section="4.8"/>). The procedure is also applicable
target="RFC5770" />. The procedure is applicable also in the in the context of this specification, so it is repeated here for
context of this specification, so it is repeated here for
completeness.</t> completeness.</t>
<t> In certain network environments, the connectivity checks can be <t> In certain network environments, the connectivity checks can be
omitted to reduce initial connection set-up latency because a base omitted to reduce initial connection setup latency because a base
exchange acts as an implicit connectivity test itself. For this to exchange acts as an implicit connectivity test itself. For this to
work, the Initiator MUST be able to reach the Responder by simply UDP work, the Initiator <bcp14>MUST</bcp14> be able to reach the Responder by simply UDP
encapsulating HIP and ESP packets sent to the Responder's address. encapsulating HIP and ESP packets sent to the Responder's address.
Detecting and configuring this particular scenario is prone to failure Detecting and configuring this particular scenario is prone to failure
unless carefully planned. </t> unless carefully planned. </t>
<t> In such a scenario, the Responder <bcp14>MAY</bcp14> include
<t> In such a scenario, the Responder MAY include UDP-ENCAPSULATION NA UDP-ENCAPSULATION NAT traversal mode as one of the supported modes
T in the R1 packet. If the Responder has registered to a Control Relay
traversal mode as one of the supported modes in the R1 packet. If the Server in order to discover its address candidates, it
Responder has registered to a Control Relay Server in order to discove <bcp14>MUST</bcp14> also include a LOCATOR_SET parameter
r its address candidates, it MUST also include a encapsulated inside an ENCRYPTED parameter in an R1 message that
LOCATOR_SET parameter encapsulated inside an ENCRYPTED parameter in R1 contains a preferred address where the Responder is able to receive
message that contains a preferred address where the UDP-encapsulated ESP and HIP packets. This locator
Responder is able to receive UDP-encapsulated ESP and HIP packets. Thi <bcp14>MUST</bcp14> be of type "Transport address", its Traffic type
s <bcp14>MUST</bcp14> be "both", and it <bcp14>MUST</bcp14> have the
locator MUST be of type "Transport address", its Traffic type MUST be "Preferred bit" set (see <xref target="tbl_locator"
"both", and it MUST have the "Preferred bit" set (see <xref format="default"/>). If there is no such locator in R1, the
target="tbl:locator"/>). If there is no such locator in R1, the Initia Initiator <bcp14>MUST</bcp14> use the source address of the R1 as
tor MUST use the source the Responder's preferred address. </t>
address of the R1 as the Responder's preferred address. </t> <t> The Initiator <bcp14>MAY</bcp14> choose the UDP-ENCAPSULATION
mode if the Responder listed it in the supported modes and the
<t> The Initiator MAY choose the UDP-ENCAPSULATION mode if the Initiator does not wish to use the connectivity checks defined in
Responder listed it in the supported modes and the Initiator does not this document for searching for a more optimal path. In this case,
wish to use the connectivity checks defined in this document for searc the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT
hing for a more optimal path. In this case, traversal mode parameter directly to the Responder's preferred
the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT address (i.e., to the preferred locator in R1 or to the address
traversal mode parameter directly to the Responder's preferred address where R1 was received from if there was no preferred locator in
(i.e., to the preferred locator in R1 or to the address where R1 was R1). The Initiator <bcp14>MAY</bcp14> include locators in I2 but
received from if there was no preferred locator in R1). The Initiator they <bcp14>MUST NOT</bcp14> be taken as address candidates, since
MAY include locators in I2 but they MUST NOT be taken as address connectivity checks defined in this document will not be used for
candidates, since connectivity checks defined in this document will no connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
t be used for connections with R2 and I2 are received and processed successfully, a security
UDP-ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are association can be created and UDP-encapsulated ESP can be exchanged
received and processed successfully, a security association can be between the hosts after the base exchange completes according to the
created and UDP-encapsulated ESP can be exchanged between the hosts rules in <xref target="RFC7401" sectionFormat="of" section="4.4"/>.
after the base exchange completes according to the rules in Section 4. </t>
4 in <xref target="RFC7401" />. <t>The Control Relay Server can be used for discovering address
<!-- However, the Responder SHOULD NOT candidates but it is not intended to be used for relaying end-host
send any ESP to the Initiator's address before it has received data packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet
from the Initiator, as specified in Sections 4.4.3. and 6.9 of <xref with UDP-ENCAPSULATION NAT traversal mode selected <bcp14>MUST
target="RFC7401"/> and in Sections 3.3.1 and 5.4 of <xref NOT</bcp14> be sent via a Control Relay Server, the Responder
target="RFC8046"/>. --> </t> <bcp14>SHOULD</bcp14> reject such I2 packets and reply with a
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see <xref
<t>The Control Relay Server can be used for discovering address candid target="sec_notify-types" format="default"/>).</t>
ates but it is not intended to be used
for relaying end-host packets using the UDP-ENCAPSULATION NAT mode.
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode
selected MUST NOT be sent via a Control Relay Server, the Responder SH
OULD reject such
I2 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTI
FY
packet (see <xref target="sec:notify-types"/>). </t>
<t> If there is no answer for the I2 packet sent directly to the <t> If there is no answer for the I2 packet sent directly to the
Responder's preferred address, the Initiator MAY send another I2 via Responder's preferred address, the Initiator <bcp14>MAY</bcp14> send
the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION NAT another I2 via the Control Relay Server, but it <bcp14>MUST
traversal mode for that I2. </t> NOT</bcp14> choose UDP-ENCAPSULATION NAT traversal mode for that
I2.</t>
</section> <!-- Base Exchange without ICE Connectivity Checks --> </section>
<section anchor="sec:no_udp"
title="Initiating a Base Exchange both with and without UDP Enc
apsulation">
<t>It is possible to run a base exchange in parallel both with
and without UDP encapsulation as defined in Legacy ICE-HIP section 4.9
in <xref
target="RFC5770" />. The procedure is applicable also in the
context of this specification, so it is repeated here for
completeness.</t>
<t>The Initiator MAY also try to simultaneously perform a base exchang
e
with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while
before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated.</t>
<t>The I1 packet without UDP encapsulation may arrive directly, withou <section anchor="sec_no_udp" numbered="true" toc="default">
t <name>Initiating a Base Exchange Both with and without UDP Encapsulati
passing any a Control Relay Server, at the Responder. When this happen on</name>
s, the procedures in <t>It is possible to run a base exchange in parallel both with and
<xref target="RFC7401" /> are followed for the rest of the base without UDP encapsulation as defined in Legacy ICE-HIP (<xref
target="RFC5770" sectionFormat="of" section="4.9"/>). The procedure
is also applicable in the context of this specification, so it is
repeated here for completeness.</t>
<t>The Initiator <bcp14>MAY</bcp14> also try to simultaneously
perform a base exchange with the Responder without UDP
encapsulation. In such a case, the Initiator sends two I1 packets,
one without and one with UDP encapsulation, to the Responder. The
Initiator <bcp14>MAY</bcp14> wait for a while before sending the
other I1. How long to wait and in which order to send the I1 packets
can be decided based on local policy. For retransmissions, the
procedure is repeated.</t>
<t>The I1 packet without UDP encapsulation may arrive directly,
without passing a Control Relay Server, at the Responder. When
this happens, the procedures in <xref target="RFC7401"
format="default"/> are followed for the rest of the base
exchange. The Initiator may receive multiple R1 packets, with and exchange. The Initiator may receive multiple R1 packets, with and
without UDP encapsulation, from the Responder. However, after receivin without UDP encapsulation, from the Responder. However, after
g receiving a valid R1 and answering it with an I2, further R1 packets
a valid R1 and answering it with an I2, further R1 packets that are no that are not retransmissions of the R1 message received first
t <bcp14>MUST</bcp14> be ignored. </t>
retransmissions of the R1 message received first MUST be ignored. </t>
<t>The I1 packet without UDP encapsulation may also arrive at a <t>The I1 packet without UDP encapsulation may also arrive at a
HIP-capable middlebox. When the middlebox is a HIP rendezvous server HIP-capable middlebox. When the middlebox is a HIP Rendezvous Server
and the Responder has successfully registered with the rendezvous and the Responder has successfully registered with the rendezvous
service, the middlebox follows rendezvous procedures in <xref service, the middlebox follows rendezvous procedures in <xref
target="RFC8004" />. </t> target="RFC8004" format="default"/>.</t>
<t>If the Initiator receives a NAT traversal mode parameter in R1 <t>If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter and without UDP encapsulation, the Initiator <bcp14>MAY</bcp14> ignore
send an I2 without UDP encapsulation and without any selected NAT this parameter and send an I2 without UDP encapsulation and without
traversal mode. When the Responder receives the I2 without UDP any selected NAT traversal mode. When the Responder receives the I2
encapsulation and without NAT traversal mode, it will assume that no without UDP encapsulation and without NAT traversal mode, it will
NAT traversal mechanism is needed. The packet processing will be done assume that no NAT traversal mechanism is needed. The packet
as described in <xref target="RFC7401"/>. The Initiator MAY store the processing will be done as described in <xref target="RFC7401"
NAT traversal modes for future use, e.g., in case of a mobility or format="default"/>. The Initiator <bcp14>MAY</bcp14> store the NAT
multihoming event that causes NAT traversal to be used during the traversal modes for future use, e.g., in case of a mobility or
lifetime of the HIP association. </t> multihoming event that causes NAT traversal to be used during the
lifetime of the HIP association. </t>
</section> <!-- Base Exchange without UDP Encapsulation --> </section>
</section> <!-- NAT Traversal Alternatives -->
<section anchor="sec:control_no_relay"
title="Sending Control Packets after the Base Exchange">
<t>The same considerations of sending control packets after
the base exchange described in legacy ICE-HIP section 5.10 in <xref
target="RFC5770"/> apply also here, so they are repeated here
for completeness.</t>
<t>After the base exchange, the two end-hosts MAY send HIP control packe
ts
directly to each other using the transport address pair established for
a data channel without sending the control packets through any Control R
elay
Servers . When a host does not receive acknowledgments, e.g., to an
UPDATE or CLOSE packet after a timeout based on local policies, a
host SHOULD resend the packet through the associated Data Relay Server o
f the peer (if the peer listed it in
its LOCATOR_SET parameter in the base exchange according the rules speci
fied in section 4.4.2 in <xref
target="RFC7401"/>.
</t>
<t> If Control Relay Client sends a packet through a Control Relay Serve </section>
r, the Control Relay Client
MUST always utilize the RELAY_TO parameter. The Control Relay Server SHO
ULD forward HIP control packets originating from a Control Relay Client to the
address denoted in the RELAY_TO parameter. In the other direction, the C
ontrol Relay Server SHOULD forward HIP control packets to the
Control Relay Clients, and MUST add a RELAY_FROM parameter to the contro
l packets it relays to the Control Relay Clients.
</t>
<section anchor="sec_control_no_relay" numbered="true" toc="default">
<name>Sending Control Packets after the Base Exchange</name>
<t>The same considerations with regard to sending control packets after
the base
exchange as described in Legacy ICE-HIP (<xref target="RFC5770"
sectionFormat="of" section="5.10"/>) also apply here, so they are
repeated here for completeness.</t>
<t>After the base exchange, the two end hosts <bcp14>MAY</bcp14> send
HIP control packets directly to each other using the transport address
pair established for a data channel without sending the control
packets through any Control Relay Servers. When a host does not
receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a
timeout based on local policies, a host <bcp14>SHOULD</bcp14> resend
the packet through the associated Data Relay Server of the peer (if
the peer listed it in its LOCATOR_SET parameter in the base exchange
according to the rules specified in <xref target="RFC7401"
sectionFormat="of" section="4.4.2"/>).</t>
<t> If a Control Relay Client sends a packet through a Control Relay
Server, the Control Relay Client <bcp14>MUST</bcp14> always utilize
the RELAY_TO parameter. The Control Relay Server <bcp14>SHOULD</bcp14>
forward HIP control packets originating from a Control Relay Client to
the address denoted in the RELAY_TO parameter. In the other direction,
the Control Relay Server <bcp14>SHOULD</bcp14> forward HIP control
packets to the Control Relay Clients and <bcp14>MUST</bcp14> add a
RELAY_FROM parameter to the control packets it relays to the Control
Relay Clients.</t>
<t> If the Control Relay Server is not willing or able to relay a HIP <t> If the Control Relay Server is not willing or able to relay a HIP
packet, it MAY notify the sender of the packet with packet, it <bcp14>MAY</bcp14> notify the sender of the packet with a
MESSAGE_NOT_RELAYED error notification (see <xref MESSAGE_NOT_RELAYED error notification (see <xref
target="sec:notify-types"/>). </t> target="sec_notify-types" format="default"/>). </t>
</section>
</section> <!-- Sending Control Packets after the Base Exchange -->
<section anchor="sec:mobility" title="Mobility Handover Procedure">
<section anchor="sec_mobility" numbered="true" toc="default">
<name>Mobility Handover Procedure</name>
<t>A host may move after base exchange and connectivity <t>A host may move after base exchange and connectivity
checks. Mobility extensions for HIP <xref checks. Mobility extensions for HIP <xref target="RFC8046"
target="RFC8046"/> define handover procedures format="default"/> define handover procedures
without NATs. In this section, we define how two hosts without NATs. In this section, we define how two hosts
interact with handover procedures in scenarios involving interact with handover procedures in scenarios involving
NATs. The specified extensions define only simple mobility NATs. The specified extensions define only simple mobility
using a pair of security associations, and multihoming using a pair of security associations, and multihoming
extensions are left to be defined in later specifications. extensions are left to be defined in later specifications.
The procedures in this section offer the same functionality as "ICE rest The procedures in this section offer the same functionality as "ICE
art" specified in <xref restart" specified in <xref target="RFC8445" format="default"/>. The
target="RFC8445"/>. The
example described in this section shows only a Control Relay Server example described in this section shows only a Control Relay Server
for the peer host for the sake of simplicity, but the for the peer host for the sake of simplicity, but the
mobile host may also have a Control Relay Server.</t> mobile host may also have a Control Relay Server.</t>
<t>The assumption here is that the two hosts have successfully negotiate d <t>The assumption here is that the two hosts have successfully negotiate d
and chosen the ICE-HIP-UDP mode during the base exchange as and chosen the ICE-HIP-UDP mode during the base exchange as
defined in <xref defined in <xref target="sec_nat_traversal_mode"
target="sec:nat_traversal_mode"/>. The Initiator of the base format="default"/>. The Initiator of the base
exchange MUST store information that it was the controlling exchange <bcp14>MUST</bcp14> store information that it was the controlli
host during the base exchange. Similarly, the Responder MUST ng
host during the base exchange. Similarly, the Responder <bcp14>MUST</bcp
14>
store information that it was the controlled host during the store information that it was the controlled host during the
base exchange.</t> base exchange.</t>
<t>Prior to starting the handover procedures with all peer <t>Prior to starting the handover procedures with all peer hosts, the
hosts, the mobile host SHOULD first send its locators in UPDATE messages mobile host <bcp14>SHOULD</bcp14> first send its locators in UPDATE
to messages to its Control and Data Relay Servers if it has registered to
its Control and Data Relay Servers if it has registered to such. It such. It <bcp14>SHOULD</bcp14> wait for all of them to respond for a
SHOULD wait for all of them to respond for a configurable time, by defaul configurable time, by default two minutes, and then continue with the
t two minutes, and handover procedure without information from the Relay Server that did
then continue with the handover procedure without information not respond. As defined in <xref target="sec_registration"
from the Relay Server that did not respond. As defined in format="default"/>, a response message from a Control Relay Server
<xref target="sec:registration" />, a response message from a includes a REG_FROM parameter that describes the server-reflexive
Control Relay Server includes a REG_FROM parameter that describes the ser candidate of the mobile host to be used in the candidate exchange
ver during the handover. Similarly, an UPDATE to a Data Relay Server is
reflexive candidate of the mobile host to be used in the necessary to make sure the Data Relay Server can forward data to the
candidate exchange during the handover. Similarly, an UPDATE correct IP address after a handover.</t>
to a Data Relay Server is necessary to make sure the Data Relay Server ca
n
forward data to the correct IP address after a handoff.</t>
<t>The mobility extensions for NAT traversal are illustrated <t>The mobility extensions for NAT traversal are illustrated
in <xref target="fig:update"/>. The mobile host is the in <xref target="fig_update" format="default"/>. The mobile host is the
host that has changed its locators, and the peer host is the host that has changed its locators, and the peer host is the
host it has a host association with. The mobile host may have host it has a host association with. The mobile host may have
multiple peers and it repeats the process with all of its multiple peers, and it repeats the process with all of its
peers. In the figure, the Control Relay Server belongs to the peer host, peers. In the figure, the Control Relay Server belongs to the peer host,
i.e., the peer host is a Control Relay Client for the Control Relay Serv er. i.e., the peer host is a Control Relay Client for the Control Relay Serv er.
Note that the figure corresponds to figure 3 in <xref Note that the figure corresponds to figure 3 in <xref target="RFC8046"
target="RFC8046"/>, but the difference is that the main format="default"/>, but the difference is that the main
UPDATE procedure is carried over the relay and the UPDATE procedure is carried over the relay and the
connectivity is tested separately. Next, we describe the connectivity is tested separately. Next, we describe the
procedure in the figure in detail.</t> procedure of that figure in detail.</t>
<figure anchor="fig_update">
<?rfc needLines="21" ?> <name>HIP UPDATE Procedure</name>
<figure anchor="fig:update" title="HIP UPDATE procedure"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
Mobile Host Control Relay Server Peer Host Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
| ENC(LOC_SET), SEQ)) | | | ENC(LOC_SET), SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | ENC(LOC_SET), SEQ, | | | ENC(LOC_SET), SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(UPDATE(ESP_INFO, SEQ, | | | 3. UDP(UPDATE(ESP_INFO, SEQ, |
| | ACK, ECHO_REQ_SIGN, | | | ACK, ECHO_REQ_SIGN, |
skipping to change at line 1661 skipping to change at line 1519
| | ECHO_RESP_SIGNED, | | | ECHO_RESP_SIGNED, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| 7. connectivity checks over UDP | | 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 8. ESP data over UDP | | 8. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t>In step 1, the mobile host has changed location and sends a <t>In step 1, the mobile host has changed location and sends a
location update to its peer through the Control Relay Server of the location update to its peer through the Control Relay Server of the
peer. It sends an UPDATE packet with source HIT belonging to peer. It sends an UPDATE packet with the source HIT belonging to
itself and destination HIT belonging to the peer host. In the itself and destination HIT belonging to the peer host. In the packet,
packet, the source IP address belongs to the mobile host and the source IP address belongs to the mobile host and the destination
the destination to the Control Relay Server. The packet contains an to the Control Relay Server. The packet contains an ESP_INFO parameter
ESP_INFO parameter, where, in this case, the OLD SPI and NEW where, in this case, the OLD SPI and NEW SPI parameters both contain
SPI parameters both contain the pre-existing incoming SPI. The the pre-existing incoming SPI. The packet also contains the locators
packet also contains the locators of the mobile host in a of the mobile host in a LOCATOR_SET parameter, encapsulated inside an
LOCATOR_SET parameter, encapsulated inside an ENCRYPTED parameter ENCRYPTED parameter (see Sections <xref target="RFC7401"
(see sections 5.2.18 and 6.5 in <xref target="RFC7401" /> for details on section="5.2.18" sectionFormat="bare"/> and <xref target="RFC7401"
the ENCRYPTED parameter). section="6.5" sectionFormat="bare"/> in <xref target="RFC7401"
The packet contains also a SEQ number to be acknowledged by the peer. As format="default"/> for details on the ENCRYPTED parameter). The packet
specified in <xref also contains a SEQ number to be acknowledged by the peer. As
target="RFC8046"/>, the packet may also include a HOST_ID (for specified in <xref target="RFC8046" format="default"/>, the packet may
middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying.</t> also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN
parameter for rekeying.</t>
<t>In step 2, the Control Relay Server receives the UPDATE packet and fo rwards it <t>In step 2, the Control Relay Server receives the UPDATE packet and fo rwards it
to the peer host (i.e. Control Relay Client). The Control Relay Server to the peer host (i.e., Control Relay Client). The Control Relay Server
rewrites the destination IP address and appends a RELAY_FROM rewrites the destination IP address and appends a RELAY_FROM
parameter to the message.</t> parameter to the message.</t>
<t>In step 3, the peer host receives the UPDATE packet, <t>In step 3, the peer host receives the UPDATE packet,
processes it and responds with another UPDATE message. The processes it, and responds with another UPDATE message. The
message is destined to the HIT of mobile host and to the IP message is destined to the HIT of the mobile host and to the IP
address of the Control Relay Server. The message includes an ESP_INFO address of the Control Relay Server. The message includes an ESP_INFO
parameter where, in this case, the OLD SPI and NEW SPI parameter where, in this case, the OLD SPI and NEW SPI
parameters both contain the pre-existing incoming SPI. The parameters both contain the pre-existing incoming SPI. The
peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters to be peer includes a new SEQ and ECHO_REQUEST_SIGNED parameter to be
acknowledged by the mobile host. The message acknowledges the acknowledged by the mobile host. The message acknowledges the
SEQ parameter of the earlier message with an ACK parameter. SEQ parameter of the earlier message with an ACK parameter.
The RELAY_TO parameter specifies the address of the mobile host where th e The RELAY_TO parameter specifies the address of the mobile host where th e
Control Relay Server should forward the message. Control Relay Server should forward the message.
</t> </t>
<t>In step 4, the Control Relay Server receives the message, rewrites th e <t>In step 4, the Control Relay Server receives the message, rewrites th e
destination IP address and UDP port according to the RELAY_TO parameter, and destination IP address and UDP port according to the RELAY_TO parameter, and
then forwards the modified message to the mobile host. then forwards the modified message to the mobile host.
</t> </t>
<t>In step 5, the mobile host receives the UPDATE packet and processes
<t>In step 5, the mobile host receives the UPDATE packet and processes i it. The mobile host concludes the handover procedure by acknowledging
t. The mobile host concludes the handover procedure the received SEQ parameter with an ACK parameter and the
by acknowledging the received SEQ parameter with an ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED
ACK parameter and the ECHO_REQUEST_SIGNED parameter with parameter. The mobile host sends the packet to the HIT of the peer and
ECHO_RESPONSE_SIGNED parameter. The mobile host delivers the to the address of the HIP relay. The mobile host can start
packet to the HIT of the peer and to the address of the HIP connectivity checks after this packet. </t>
relay. The mobile host can start connectivity checks after this packet. <t>In step 6, the HIP relay receives the UPDATE packet and
</t> forwards it to the peer host (i.e., Relay Client). The HIP
<t>In step 6, HIP relay receives the UPDATE packet and
forwards it to the peer host (i.e. Relay Client). The HIP
relay rewrites the destination IP address and port, and then appends a relay rewrites the destination IP address and port, and then appends a
RELAY_FROM parameter to the message. When the peer host RELAY_FROM parameter to the message. When the peer host
receives this concluding UPDATE packet, it can initiate the receives this concluding UPDATE packet, it can initiate the
connectivity checks. connectivity checks.
</t> </t>
<t>In step 7, the two hosts test for connectivity across NATs <t>In step 7, the two hosts test for connectivity across NATs
according to procedures described in <xref according to procedures described in <xref target="sec_conn_checks"
target="sec:conn_checks"/>. The original Initiator of the format="default"/>. The original Initiator of the
communications is the controlling and the original Responder is communications is the controlling host and the original Responder is
the controlled host.</t> the controlled host.</t>
<t>In step 8, the connectivity checks are successfully <t>In step 8, the connectivity checks are successfully
completed and the controlling host has nominated one address completed and the controlling host has nominated one address
pair to be used. The hosts set up security associations to pair to be used. The hosts set up security associations to
deliver the application payload.</t> deliver the application payload.</t>
<t>It is worth noting that the Control and Data Relay Client <t>It is worth noting that the Control and Data Relay Client
do not have to re-register for the related services after a do not have to reregister for the related services after a
handoff. However, if a Data Relay Client has registered a handover. However, if a Data Relay Client has registered a
relayed address candidate from a Data Relay Server, the Data relayed address candidate from a Data Relay Server, the Data
Relay Client MUST reactivate the address before the Relay Client <bcp14>MUST</bcp14> reactivate the address before the
connectivity checks by sending an UPDATE message containing connectivity checks by sending an UPDATE message containing
PEER_PERMISSION parameter as described in <xref the PEER_PERMISSION parameter as described in <xref
target="sec:forwarding" />. Otherwise, the Data Relay Server target="sec_forwarding" format="default"/>. Otherwise, the Data Relay
Server
drops ESP packets sent to the relayed address.</t> drops ESP packets sent to the relayed address.</t>
<t>In the so-called "double jump" or simultaneous mobility
<t>In so called "double jump" or simultaneous mobility scenario, both peers change their location simultaneously. In
scenario both peers change their location simultaneously. In
such a case, both peers trigger the procedure described such a case, both peers trigger the procedure described
earlier in this section at the same time. In other words, both earlier in this section at the same time. In other words, both
of the communicating hosts send an UPDATE packet carrying of the communicating hosts send an UPDATE packet carrying
locators at the same time or with some delay. When the locators at the same time or with some delay. When the
locators are exchanged almost simultaneously (reliably via locators are exchanged almost simultaneously (reliably via
Control Relay Servers), the two hosts can continue with Control Relay Servers), the two hosts can continue with
connectivity checks after both have completed separately the connectivity checks after both have completed separately the
steps in <xref target="fig:update" />. The problematic case steps in <xref target="fig_update" format="default"/>. The problematic ca
occurs when one of the hosts (referred here as host "M") se
occurs when one of the hosts (referred to here as host "M")
moves later during the connectivity checks. In such a case, moves later during the connectivity checks. In such a case,
host M sends a locator to the peer which is in the middle of host M sends a locator to the peer, which is in the middle of
connectivity checks. Upon receiving the UPDATE message, the connectivity checks. Upon receiving the UPDATE message, the
peer responds with an UPDATE with ECHO_REQ_SIGN as described peer responds with an UPDATE with ECHO_REQ_SIGN as described
in step 3 in <xref target="fig:update" />. Upon receiving the in step 3 in <xref target="fig_update" format="default"/>. Upon receiving the
valid response from host M as described in step 6, the peer valid response from host M as described in step 6, the peer
host MUST restart the connectivity checks with host M. This host <bcp14>MUST</bcp14> restart the connectivity checks with host M. Thi s
way, both hosts start the connectivity checks roughly in a way, both hosts start the connectivity checks roughly in a
synchronized way. It is also important that peer host does not synchronized way. It is also important that the peer host does not
restart the connectivity checks until the step 6 is restart the connectivity checks until step 6 is
successfully completed because the UPDATE message successfully completed, because the UPDATE message
carrying locators in step 1 could be replayed by an attacker.</t> carrying locators in step 1 could be replayed by an attacker.</t>
</section> </section>
<section anchor="sec_nat-keepalives" numbered="true" toc="default">
<section title="NAT Keepalives" anchor="sec:nat-keepalives"> <name>NAT Keepalives</name>
<t>To prevent NAT states from expiring, communicating hosts <t>To prevent NAT states from expiring, communicating hosts
MUST send periodic keepalives to other hosts with which they <bcp14>MUST</bcp14> send periodic keepalives to other hosts with which
have established a Host Association every 15 seconds (the so they have established a HIP association every 15 seconds (the
called Tr value in ICE). Other values MAY be used, so-called Tr value in ICE). Other values <bcp14>MAY</bcp14> be used,
but a Tr value smaller than 15 seconds MUST NOT be used. but a Tr value smaller than 15 seconds <bcp14>MUST NOT</bcp14> be
Both a Control/Data Relay Client and Control/Data Relay used. Both a Control/Data Relay Client and Control/Data Relay Server,
Server, as well as two peers employing UDP-ENCAPSULATION or as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-UDP mode,
ICE-HIP-UDP mode, SHOULD send HIP NOTIFY packets unless they <bcp14>SHOULD</bcp14> send HIP NOTIFY packets unless they have
have exchanged some other traffic over the used UDP ports. exchanged some other traffic over the used UDP ports. However, the
However, the Data Relay Client and Data Relay Server MUST employ only HIP Data Relay Client and Data Relay Server <bcp14>MUST</bcp14> employ
NOTIFY packets only HIP NOTIFY packets in order to keep the server-reflexive
in order to keep the server reflexive candidates alive. candidates alive. The keepalive message encoding format is defined in
The keepalive message encoding format is defined in <xref <xref target="sec_keepalive" format="default"/>.
target="sec:keepalive" />.
<!-- only NOTIFY works for the reflexive candidates because this address
is not really a part of the Host Association of the Data Relay Server) -->
<!-- Likewise, if a host has not sent any data to another If the base exchange or mobility handover procedure occurs during an
host it has established a host association in the ICE-HIP_UDP extremely slow path, a host (with a HIP association with the peer)
mode within 15 seconds, it MUST send either a HIP NOTIFY packet or, alte <bcp14>MAY</bcp14> also
rnatively, an ICMPv6
echo request inside the related ESP tunnel. Control Relay Server
servers MAY refrain from sending keepalives if it's known that
they are not behind a middlebox that requires keepalives. -->
If the base exchange or mobility handover procedure occurs during an ext
remely slow path, a host (with a Host Association with the peer) MAY also
send HIP NOTIFY packets every 15 seconds to keep the path active with th e recipient. send HIP NOTIFY packets every 15 seconds to keep the path active with th e recipient.
</t> </t>
</section> </section>
<section anchor="sec_close" numbered="true" toc="default">
<section anchor="sec:close" title="Closing Procedure"> <name>Closing Procedure</name>
<t>The two-way procedure for closing a HIP association and the related <t>The two-way procedure for closing a HIP association and the related
security associations is defined in <xref security associations is defined in <xref target="RFC7401"
target="RFC7401"/>. One host initiates the procedure by format="default"/>. One host initiates the procedure by sending a
sending a CLOSE message and the recipient confirms it with CLOSE message and the recipient confirms it with CLOSE_ACK. All
CLOSE_ACK. All packets are protected using HMACs and packets are protected using HMACs and signatures, and the CLOSE
signatures, and the CLOSE messages includes a messages include an ECHO_REQUEST_SIGNED parameter to protect against
ECHO_REQUEST_SIGNED parameter to protect against replay attacks.</t> replay attacks.</t>
<t>The same procedure for closing HIP associations also applies here,
<t>The same procedure for closing HIP associations applies but the messaging occurs using the UDP-encapsulated tunnel that the
also here, but the messaging occurs using the UDP encapsulated two hosts employ. A host sending the CLOSE message
tunnel that the two hosts employ. A host sending the CLOSE <bcp14>SHOULD</bcp14> first send the message over a direct link. After
message SHOULD first send the message over a direct a number of retransmissions, it <bcp14>MUST</bcp14> send over a
link. After a number of retransmissions, it MUST send over a Control Relay Server of the recipient if one exists. The host
Control Relay Server of the recipient if one exists. The host receiving receiving the CLOSE message directly without a Control Relay Server
the CLOSE message directly without a Control Relay Server SHOULD respond <bcp14>SHOULD</bcp14> respond directly. If the CLOSE message came via a
directly. If CLOSE message came via a Control Relay Server, the host SHO Control Relay Server, the host <bcp14>SHOULD</bcp14> respond using the
ULD same Control Relay Server.</t>
respond using the same Control Relay Server.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Relaying Considerations"> <name>Relaying Considerations</name>
<section anchor="sec_forwarding" numbered="true" toc="default">
<section anchor="sec:forwarding" title="Forwarding Rules and Permissions <name>Forwarding Rules and Permissions</name>
">
<t> The Data Relay Server uses a similar permission model as a <t> The Data Relay Server uses a similar permission model as a
TURN server: before the Data Relay Server forwards any ESP data TURN server: before the Data Relay Server forwards any ESP data
packets from a peer to a Data Relay Client (or the other direction), packets from a peer to a Data Relay Client (or the other direction),
the client MUST set a permission for the peer's address. The the client <bcp14>MUST</bcp14> set a permission for the peer's address . The
permissions also install a forwarding rule for each direction, similar to permissions also install a forwarding rule for each direction, similar to
TURN's channels, based on the Security Parameter Index (SPI) TURN's channels, based on the Security Parameter Index (SPI)
values in the ESP packets. values in the ESP packets.</t>
</t>
<t>Permissions are not required for HIP control packets. <t>Permissions are not required for HIP control packets.
However, if a relayed address (as conveyed in the RELAYED_ADDRESS para However, if a relayed address (as conveyed in the RELAYED_ADDRESS
meter from the Data Relay Server) is selected to be used for parameter from the Data Relay Server) is selected to be used for
data, the Control Relay Client MUST send an UPDATE message to the data, the Control Relay Client <bcp14>MUST</bcp14> send an UPDATE mess
age to the
Data Relay Server containing a PEER_PERMISSION parameter (see <xref Data Relay Server containing a PEER_PERMISSION parameter (see <xref
target="sec:peer_permission"/>) with the following information: the UD target="sec_peer_permission" format="default"/>) with the following
P port and address for the server reflexive address, the UDP port and information: the UDP port and address for the server-reflexive
address, the UDP port and
address of the peer, and the inbound and outbound SPIs used for ESP. address of the peer, and the inbound and outbound SPIs used for ESP.
The packet MUST be sent to the same UDP tunnel The packet <bcp14>MUST</bcp14> be sent to the same UDP tunnel
the Client employed in the base exchange to contact the Server (i.e., the Client employed in the base exchange to contact the Server
not to the port occupied by the server reflexive candidate). (i.e., not to the port occupied by the server-reflexive candidate).
To avoid packet To avoid packet
dropping of ESP packets, the Control Relay Client SHOULD send the dropping of ESP packets, the Control Relay Client <bcp14>SHOULD</bcp14 > send the
PEER_PERMISSION parameter before connectivity checks both in PEER_PERMISSION parameter before connectivity checks both in
the case of base exchange and a mobility handover. It is the case of base exchange and a mobility handover. It is
worth noting that the UPDATE message includes a SEQ worth noting that the UPDATE message includes a SEQ
parameter (as specified in <xref target="RFC7401"/>) that parameter (as specified in <xref target="RFC7401" format="default"/>) that
the Data Relay Server must acknowledge, so that the Control Relay Clie nt the Data Relay Server must acknowledge, so that the Control Relay Clie nt
can resend the message with PEER_PERMISSION parameter if it can resend the message with the PEER_PERMISSION parameter if it
gets lost.</t> gets lost.</t>
<!-- should the message with PEER_PERMISSION include ECHO_SIGNED? NO (W
OULD ACTUALLY REQUIRE 3-WAY MESSAGING) -->
<!-- should the ESP data relay really do DPI or just use ports? Ari: r
elay can run out of ports. Miika: new SPI collision mechanism -->
<t> When a Data Relay Server receives an UPDATE with a <t> When a Data Relay Server receives an UPDATE with a
PEER_PERMISSION parameter, it MUST check if the sender of the PEER_PERMISSION parameter, it <bcp14>MUST</bcp14> check if the
UPDATE is registered for data relaying service, and drop the sender of the UPDATE is registered for data-relaying service, and
UPDATE if the host was not registered. If the host was drop the UPDATE if the host was not registered. If the host was
registered, the Data Relay Server checks if there is a permission with registered, the Data Relay Server checks if there is a permission
matching information (protocol, addresses, ports and SPI with matching information (protocol, addresses, ports, and SPI
values). If there is no such permission, a new permission MUST values). If there is no such permission, a new permission
be created and its lifetime MUST be set to 5 minutes. If an <bcp14>MUST</bcp14> be created and its lifetime <bcp14>MUST</bcp14>
identical permission already existed, it MUST be refreshed by be set to 5 minutes. If an identical permission already existed, it
setting the lifetime to 5 minutes. A Data Relay Client SHOULD <bcp14>MUST</bcp14> be refreshed by setting the lifetime to 5
refresh permissions 1 minute before the expiration when the minutes. A Data Relay Client <bcp14>SHOULD</bcp14> refresh
permission is still needed. </t> permissions 1 minute before the expiration when the permission is
still needed. </t>
<t>When a Data Relay Server receives an UPDATE from a registered client <t>When a Data Relay Server receives an UPDATE from a registered
but without a client but without a PEER_PERMISSION parameter and with a new
PEER_PERMISSION parameter and with a new locator set, the locator set, the Data Relay Server can assume that the mobile host
Data Relay Server can assume that the mobile host has changed its has changed its location and is thus not reachable in its previous
location and, thus, is not reachable in its previous location. In such an event, the Data Relay Server
location. In such an event, the Data Relay Server SHOULD deactivate <bcp14>SHOULD</bcp14> deactivate the permission and stop relaying
the permission and stop relaying data plane traffic to the client.</t> data plane traffic to the client.</t>
<t>The relayed address <bcp14>MUST</bcp14> be activated with the
<t>The relayed address MUST be activated with the PEER_PERMISSION parameter both after a base exchange and after a
PEER_PERMISSION parameter both after a base exchange and handover procedure with another ICE-HIP-UDP-capable host. Unless
after a handover procedure with another ICE-HIP-UDP capable activated, the Data Relay Server <bcp14>MUST</bcp14> drop all ESP
host. Unless activated, the Data Relay Server MUST drop all ESP packets. It is worth noting that a Data Relay Client does not have
packets. It is worth noting that a Data Relay Client does not to renew its registration upon a change of location UPDATE, but only
have to renew its registration upon a change of location when the lifetime of the registration is close to end.</t>
UPDATE, but only when the lifetime of the registration is close to end </section>
.</t>
</section> <!-- Forwarding Rules and Permissions -->
<section title="HIP Data Relay and Relaying of Control Packets">
<t>When a Data Relay Server accepts to relay UDP encapsulated
ESP between a Data Relay Client and its peer, the Data Relay Server op
ens a UDP port (relayed
address) for this purpose as described in <xref
target="sec:registration"/>. This port can be used for delivering also
control packets because
connectivity checks also cover the path through the Data Relay Server.
If the Data Relay Server receives a UDP encapsulated HIP control
packet on that port, it MUST forward the packet to the
Data Relay Client and add a RELAY_FROM parameter to the packet
as if the Data Relay Server were acting as a Control Relay Server.
When the Data Relay Client replies to a control
packet with a RELAY_FROM parameter via its Data Relay Server, the
Data Relay Client MUST add a RELAY_TO parameter containing the
peer's address and use the address of its Data Relay Server as the
destination address. Further, the Data Relay Server MUST send this
packet to the peer's address from the relayed address.</t>
<section numbered="true" toc="default">
<name>HIP Data Relay and Relaying of Control Packets</name>
<t>When a Data Relay Server accepts to relay UDP-encapsulated ESP
between a Data Relay Client and its peer, the Data Relay Server
opens a UDP port (relayed address) for this purpose as described in
<xref target="sec_registration" format="default"/>. This port can be
used for also delivering control packets because connectivity checks
also cover the path through the Data Relay Server. If the Data Relay
Server receives a UDP-encapsulated HIP control packet on that port,
it <bcp14>MUST</bcp14> forward the packet to the Data Relay Client
and add a RELAY_FROM parameter to the packet as if the Data Relay
Server were acting as a Control Relay Server. When the Data Relay
Client replies to a control packet with a RELAY_FROM parameter via
its Data Relay Server, the Data Relay Client <bcp14>MUST</bcp14> add
a RELAY_TO parameter containing the peer's address and use the
address of its Data Relay Server as the destination
address. Further, the Data Relay Server <bcp14>MUST</bcp14> send
this packet to the peer's address from the relayed address.</t>
<t> If the Data Relay Server receives a UDP packet that is not a <t> If the Data Relay Server receives a UDP packet that is not a
HIP control packet to the relayed address, it MUST check if HIP control packet to the relayed address, it <bcp14>MUST</bcp14> chec k if
it has a permission set for the peer the packet is arriving it has a permission set for the peer the packet is arriving
from (i.e., the sender's address and SPI value matches to an from (i.e., the sender's address and SPI value matches to an
installed permission). If permissions are set, the Data Relay Server installed permission). If permissions are set, the Data Relay Server
MUST forward the packet to the Data Relay Client that <bcp14>MUST</bcp14> forward the packet to the Data Relay Client that
created the permission. The Data Relay Server MUST also implement created the permission. The Data Relay Server <bcp14>MUST</bcp14> also
the similar checks for the reverse direction (i.e. ESP packets implement
from the Data Relay Client to the peer). Packets without a permission the similar checks for the reverse direction (i.e., ESP packets
MUST be dropped from the Data Relay Client to the peer). Packets without a
silently.</t> permission <bcp14>MUST</bcp14> be dropped silently.</t>
</section>
</section> <!-- HIP Data Relay and Relaying of Control Packets -->
<section title="Handling Conflicting SPI Values" anchor="sec:conflicting
">
<t>From the viewpoint of a host, its remote peers can have
overlapping inbound SPI numbers because the IPsec uses also
the destination IP address to index the remote peer
host. However, a Data Relay Server can represent multiple
remote peers, thus masquerading the actual
destination. Since a Data Relay Server may have to deal with
a multitude of Relay Clients and their peers, a Data Relay
Server may experience collisions in the SPI namespace, thus
being unable forward datagrams to the correct
destination. Since the SPI space is 32 bits and the SPI
values should be random, the probability for a conflicting
SPI value is fairly small, but could occur on a busy Data Relay Server.
The two problematic cases are described in this section.</t>
<t>In the first scenario, the SPI collision problems occurs <section anchor="sec_conflicting" numbered="true" toc="default">
<name>Handling Conflicting SPI Values</name>
<t>From the viewpoint of a host, its remote peers can have
overlapping inbound SPI numbers because the IPsec also uses the
destination IP address to index the remote peer host. However, a
Data Relay Server can represent multiple remote peers, thus
masquerading the actual destination. Since a Data Relay Server may
have to deal with a multitude of Relay Clients and their peers, a
Data Relay Server may experience collisions in the SPI namespace,
thus being unable to forward datagrams to the correct
destination. Since the SPI space is 32 bits and the SPI values
should be random, the probability for a conflicting SPI value is
fairly small but could occur on a busy Data Relay Server. The two
problematic cases are described in this section.</t>
<t>In the first scenario, the SPI collision problem occurs
if two hosts have registered to the same Data Relay Server if two hosts have registered to the same Data Relay Server
and a third host initiates base exchange with both of and a third host initiates base exchange with both of
them. Here, the two Responders (i.e. Data Relay Clients) them. Here, the two Responders (i.e., Data Relay Clients)
claim the same inbound SPI number with the same Initiator claim the same inbound SPI number with the same Initiator
(peer). However, in this case, the Data Relay Server has (peer). However, in this case, the Data Relay Server has
allocated separate UDP ports for the two Data Relay Clients allocated separate UDP ports for the two Data Relay Clients
acting now as Responders (as recommended in <xref acting now as Responders (as recommended in <xref target="sec_reuse"
target="sec:reuse" />). When the third host sends an ESP packet, format="default"/>). When the third host sends an ESP packet,
the Data Relay Server is able to forward the packet to the the Data Relay Server is able to forward the packet to the
correct Data Relay Client because the destination UDP port correct Data Relay Client because the destination UDP port
is different for each of the clients.</t> is different for each of the clients.</t>
<t>In the second scenario, an SPI collision may occur when
<t>In the second scenario, an SPI collision may occur when
two Initiators run a base exchange to the same Responder two Initiators run a base exchange to the same Responder
(i.e. Data Relay Client), and both of the Initiators claim (i.e., Data Relay Client), and both of the Initiators claim
the same inbound SPI at the Data Relay Server using the same inbound SPI at the Data Relay Server using
PEER_PERMISSION Parameter. In this case, the Data Relay the PEER_PERMISSION parameter. In this case, the Data Relay
Server cannot disambiguate the correct destination of an ESP Server cannot disambiguate the correct destination of an ESP
packet originating from the Data Relay Client because the packet originating from the Data Relay Client because the
SPI could belong to either of the peers (and destination IP SPI could belong to either of the peers (and the destination IP
and UDP port belonging to the Data Relay Server are not and UDP port belonging to the Data Relay Server are not
unique either). The recommended way and a contingency plan unique either). The recommended way and a contingency plan
to solve this issue are described below.</t> to solve this issue are described below.</t>
<t>The recommend way to mitigate the problem is as follows. For each
<t>The recommend way to mitigate the problem is as new HIP association, a Data Relay Client acting as a Responder
follows. For each new Host Association, A Data Relay Client acting as <bcp14>SHOULD</bcp14> register a new server-reflexive candidate as
a Responder SHOULD register described in <xref target="sec_gathering"
a new server reflexive candidate as described in <xref format="default"/>. Similarly, the Data Relay Server <bcp14>SHOULD
target="sec:gathering" />. Similarly, the Data Relay Server NOT</bcp14> reuse the port numbers as described in <xref
SHOULD NOT re-use the port numbers as described in <xref target="sec_reuse" format="default"/>. This way, each
target="sec:reuse" />. This way, each server reflexive server-reflexive candidate for the Data Relay Client has a separate
candidate for the Data Relay Client has a separate UDP port UDP port that the Data Relay Server can use to disambiguate packet
that the Data Relay Server can use to disambiguate packet destinations destinations in case of SPI collisions.</t>
in case of SPI collisions.</t> <t>When the Data Relay Client is not registering or failed
<t>When the Data Relay Client is not registering or failed
to register a new relay candidate for a new peer, the Data to register a new relay candidate for a new peer, the Data
Relay Client MUST follow a contingency plan as follows. Relay Client <bcp14>MUST</bcp14> follow a contingency plan as follows.
Upon receiving an I2 with a colliding SPI, the Data Relay Upon receiving an I2 with a colliding SPI, the Data Relay
client acting as the Responder MUST NOT include the relayed Client acting as the Responder <bcp14>MUST NOT</bcp14> include the rela yed
address candidate in the R2 message because the Data Relay address candidate in the R2 message because the Data Relay
Server would not be able demultiplex the related ESP packet Server would not be able to demultiplex the related ESP packet
to the correct Initiator. The same applies also the to the correct Initiator. The same also applies to the
handover procedures; the Data Relay Client MUST NOT include handover procedures; the Data Relay Client <bcp14>MUST NOT</bcp14> incl
ude
the relayed address candidate when sending its new locator the relayed address candidate when sending its new locator
set in an UPDATE to its peer if it would cause a SPI set in an UPDATE to its peer if it would cause an SPI
conflict with another peer. conflict with another peer.
<!--
However, a Data
Relay Client with many peers MAY proactively decrease the
odds of a conflict by registering to multiple Data Relay
Servers. Thus, the described collision scenario can be
avoided if the Responder delivers a new relayed address
candidate upon SPI collisions. Each relayed address has a
separate UDP port reserved to it, so collision problem does
not occur. -->
</t>
<!--
<t>The inbound SPI values of the registered
clients should be unique so that a Control and Data Relay Server can p
roperly demultiplex
incoming packets from peer hosts to the correct registered clients. Li
kewise,
the inbound SPIs of the peer hosts should be unique for the same reaso
n. These two cases are
discussed in this section separately.</t>
-->
<!-- registeration using multiple local addresses does not work in the
case of HIP? -->
<!-- no sending of NOTIFYs upon SPI collisions -->
<!-- </t>
<t>In first case, the SPI collision problem occurs when two
Initiators run a base exchange to the same Responder
(i.e. Data Relay Client), and both the Initiators claim the
same inbound SPI. This is not a problem for the Responder since
the two Initiators can be distinguished by their transport
addresses. However, it is an issue for the Data Relay Server
because it cannot demultiplex packets from the Initiator
to the correct Responder.
-->
</section> <!-- Handling Conflicting SPI Values --> </section>
</section> <!-- Relay Considerations --> </section>
</section> </section>
<!-- ***************************************************************** --> <section anchor="sec_format" numbered="true" toc="default">
<name>Packet Formats</name>
<section anchor="sec:format" title="Packet Formats">
<t> The following subsections define the parameter and packet encodings <t> The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be for the HIP and ESP packets. All values <bcp14>MUST</bcp14> be in
in network byte order.</t> network byte order.</t>
<t>It is worth noting that all of the parameters are shown for the sake
<t>It is worth noting that all of the parameters are shown for of completeness even though they are specified already in Legacy ICE-HIP
the sake of completeness even though they are specified already in Legacy <xref target="RFC5770" format="default"/>. New parameters are explicitly
ICE-HIP <xref described as new.</t>
target="RFC5770" />. New parameters are explicitly described as new.</t> <section anchor="sec_udphip" numbered="true" toc="default">
<name>HIP Control Packets</name>
<section anchor="sec:udphip" title="HIP Control Packets"> <t><xref target="fig_udphip" format="default"/> illustrates the packet
format for UDP-encapsulated HIP. The format is identical to Legacy
<t><xref target="fig:udphip"/> illustrates the packet ICE-HIP <xref target="RFC5770" format="default"/>.</t>
format for UDP-encapsulated HIP. The format is identical to Legacy ICE-H <figure anchor="fig_udphip">
IP <xref target="RFC5770"/>.</t> <name>Format of UDP-Encapsulated HIP Control Packets</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig:udphip"
title="Format of UDP-Encapsulated HIP Control Packets">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes | | 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> HIP control packets are encapsulated in UDP packets as defined in <t> HIP control packets are encapsulated in UDP packets as defined in
Section 2.2 of <xref target="RFC3948"/>, "IKE Header Format for Port <xref target="RFC3948" sectionFormat="of" section="2.2"/>, "IKE Header
4500", except that a different port number is used. <xref Format for Port 4500", except that a different port number is
target="fig:udphip"/> illustrates the encapsulation. The UDP header is used. <xref target="fig_udphip" format="default"/> illustrates the
followed by 32 zero bits that can be used to differentiate HIP control encapsulation. The UDP header is followed by 32 zero bits that can be
packets from ESP packets. The HIP header and parameters follow the used to differentiate HIP control packets from ESP packets. The HIP
conventions of <xref target="RFC7401"/> with the exception that the HIP header and parameters follow the conventions of <xref target="RFC7401"
header checksum MUST be zero. The HIP header checksum is zero for two format="default"/> with the exception that the HIP header checksum
reasons. First, the UDP header already contains a checksum. Second, the <bcp14>MUST</bcp14> be zero. The HIP header checksum is zero for two
checksum definition in <xref target="RFC7401"/> includes the IP reasons. First, the UDP header already contains a checksum. Second,
addresses in the checksum calculation. The NATs that are unaware of HIP the checksum definition in <xref target="RFC7401" format="default"/>
cannot includes the IP addresses in the checksum calculation. The NATs that
recompute the HIP checksum after changing IP addresses. </t> are unaware of HIP cannot recompute the HIP checksum after changing IP
addresses.</t>
<t> A Control/Data Relay Server or a non-relay Responder SHOULD listen a <t> A Control/Data Relay Server or a non-relay Responder
t <bcp14>SHOULD</bcp14> listen at UDP port 10500 for incoming
UDP port 10500 for incoming UDP-encapsulated HIP control packets. If UDP-encapsulated HIP control packets. If some other port number is
some other port number is used, it needs to be known by potential used, it needs to be known by potential Initiators. </t>
Initiators. </t>
<!--
<t>It is worth noting that UDP encapsulation of HIP packets
reduces the Maximum Transfer Unit (MTU) size of the control
plane by 12 bytes.</t> -->
<t>UDP encapsulation of HIP packets reduces the Maximum <t>UDP encapsulation of HIP packets reduces the Maximum
Transfer Unit (MTU) size of the control plane by 12 bytes Transmission Unit (MTU) size of the control plane by 12 bytes
(8-byte UDP header plus 4-byte zero SPI marker), and the data (8-byte UDP header plus 4-byte zero SPI marker), and the data
plane by 8 bytes. Additional HIP relay parameters, such as plane by 8 bytes. Additional HIP relay parameters, such as
RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further
increase the size of certain HIP packets. In regard to MTU, increase the size of certain HIP packets. In regard to MTU,
the following aspects need to be considered in an the following aspects need to be considered in an
implementation: implementation:
</t> </t>
<t><list style="symbols">
<t>A HIP host SHOULD implement ICMP message handling to
support path MTU discovery (PMTUD) discovery as
described in <xref target="RFC1063" /> <xref target="RFC8201"
/></t>
<t>Reliance on IP fragmentation is unlikely to be a viable
strategy through NATs. If ICMP MTU discovery is not working,
MTU related path black holes may occur.</t>
<t>A mitigation strategy is to constrain the MTU, especially for
virtual interfaces, to expected safe MTU values,
e.g., 1400 bytes for the underlying interfaces that support 1500
bytes MTU.</t>
<t>Further extensions to this specification may define a HIP-based mechan
ism
to find a working path MTU without unnecessary constraining that size usi
ng
Packetization Layer Path MTU Discovery for Datagram Transports <xref targ
et="I-D.ietf-tsvwg-datagram-plpmtud"/>.
For instance, such mechanism could be implemented between a HIP Relay Cli
ent and HIP Relay Server.
</t>
<t>It is worth noting that further HIP extensions can trim off
8 bytes in the ESP header by negotiating implicit IV support
in the ESP_TRANSFORM parameter as described in <xref
target="RFC8750" />.</t>
</list></t>
</section> <!-- HIP Control Packets --> <ul spacing="normal">
<li>A HIP host <bcp14>SHOULD</bcp14> implement ICMP message handling
to support Path MTU Discovery (PMTUD) as described in
<xref target="RFC1191" format="default"/> and <xref target="RFC8201"
format="default"/>.</li>
<li>Reliance on IP fragmentation is unlikely to be a viable strategy
through NATs. If ICMP MTU discovery is not working, MTU-related path
black holes may occur.</li>
<section anchor="sec:con_checks" title="Connectivity Checks"> <li>A mitigation strategy is to constrain the MTU, especially for
virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
for the underlying interfaces that support 1500 bytes MTU.</li>
<li>Further extensions to this specification may define a HIP-based
mechanism to find a working path MTU without unnecessary
constraining that size using Packetization Layer Path MTU Discovery
for Datagram Transports <xref
target="RFC8899" format="default"/>. For
instance, such a mechanism could be implemented between a HIP Relay
Client and HIP Relay Server.</li>
<li>It is worth noting that further HIP extensions can trim off 8
bytes in the ESP header by negotiating implicit initialization
vector (IV) support in the ESP_TRANSFORM parameter as described in
<xref target="RFC8750" format="default"/>.</li>
</ul>
</section>
<section anchor="sec_con_checks" numbered="true" toc="default">
<name>Connectivity Checks</name>
<t>HIP connectivity checks are HIP UPDATE packets. The format <t>HIP connectivity checks are HIP UPDATE packets. The format
is specified in <xref target="RFC7401"/>.</t> is specified in <xref target="RFC7401" format="default"/>.</t>
</section>
<section anchor="sec_keepalive" numbered="true" toc="default">
<name>Keepalives</name>
<t>The <bcp14>RECOMMENDED</bcp14> encoding format for keepalives is
HIP NOTIFY packets as specified in <xref target="RFC7401"
format="default"/> with the Notify message type field set to
NAT_KEEPALIVE (16385) and with an empty Notification data field. It is
worth noting that the sending of such a HIP NOTIFY message
<bcp14>SHOULD</bcp14> be omitted if the host is sending some other
traffic (HIP or ESP) to the peer host over the related UDP tunnel
during the Tr period. For instance, the host <bcp14>MAY</bcp14>
actively send ICMPv6 requests (or respond with an ICMPv6 response)
inside the ESP tunnel to test the health of the associated IPsec
security association. Alternatively, the host <bcp14>MAY</bcp14> use
UPDATE packets as a substitute. A minimal UPDATE packet would consist
of a SEQ and a single ECHO_REQ_SIGN parameter, and a more complex one
would involve rekeying procedures as specified in <xref
target="RFC7402" sectionFormat="of" section="6.8"/>. It is worth
noting that a host actively sending periodic UPDATE packets to a busy
server may increase the computational load of the server since it has
to verify HMACs and signatures in UPDATE messages.</t>
</section> </section>
<section anchor="sec:keepalive" title="Keepalives"> <section anchor="sec_nat_tm-param" numbered="true" toc="default">
<name>NAT Traversal Mode Parameter</name>
<t>The RECOMMENDED encoding format for keepalives is HIP
NOTIFY packets as specified in <xref target="RFC7401"/> with
Notify message type field set to NAT_KEEPALIVE [TBD by IANA:
16385] and with an empty Notification data field. It is worth noting
that sending of such a HIP NOTIFY message SHOULD be omitted if the host
is actively (or passively) sending some other traffic (HIP or ESP) to th
e peer
host over the related UDP tunnel during the Tr period. For instance, the
host MAY
actively send ICMPv6 requests (or respond with an ICMPv6
response) inside the ESP tunnel to test the health of the
associated IPsec security association. Alternatively, the
host MAY use UPDATE packets as a substitute. A minimal UPDATE
packet would consist of a SEQ and ECHO_REQ_SIGN parameters,
and a more complex would involve rekeying procedures as
specified in section 6.8 in <xref target="RFC7402" />. It is
worth noting that a host actively sending periodic UPDATE packets to
a busy server may increase the computational load of the server since it
has to verify
HMACs and signatures in UPDATE messages.</t>
</section> <!-- keepalive -->
<section anchor="sec:nat_tm-param" title="NAT Traversal Mode Parameter">
<!-- XX FIXME: TRANSPORT_MODE MISSING -->
<t>The format of NAT traversal mode parameter is defined in Legacy ICE-H
IP <xref target="RFC5770"/> but repeated here for completeness.
The format of the NAT_TRAVERSAL_MODE parameter is similar to the format
of the ESP_TRANSFORM parameter in <xref target="RFC7402"/> and is shown
in <xref target="fig:nat_tfm" />. The Native ICE-HIP extension specified
in this document defines the new NAT traversal
mode identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode fr
om Legacy ICE-HIP <xref target="RFC5770"/>. The identifier
named RESERVED is reserved for future use. Future specifications may def
ine
more traversal modes. </t>
<figure anchor="fig:nat_tfm"
title="Format of the NAT_TRAVERSAL_MODE Parameter">
<artwork align="center"><![CDATA[
<t>The format of the NAT traversal mode parameter is defined in Legacy
ICE-HIP <xref target="RFC5770" format="default"/> but repeated here
for completeness. The format of the NAT_TRAVERSAL_MODE parameter is
similar to the format of the ESP_TRANSFORM parameter in <xref
target="RFC7402" format="default"/> and is shown in <xref
target="fig_nat_tfm" format="default"/>. The Native ICE-HIP extension
specified in this document defines the new NAT traversal mode
identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
Legacy ICE-HIP <xref target="RFC5770" format="default"/>. The
identifier named RESERVED is reserved for future use. Future
specifications may define more traversal modes. </t>
<figure anchor="fig_nat_tfm">
<name>Format of the NAT_TRAVERSAL_MODE Parameter</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 | | Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding | | Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type 608
Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received
Mode ID defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined:
ID name Value
RESERVED 0
UDP-ENCAPSULATION 1
ICE-STUN-UDP 2
ICE-HIP-UDP 3
]]></artwork>
</figure> </figure>
<t> The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that <dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<dd>608</dd>
<dt>Length:</dt>
<dd>Length in octets, excluding Type, Length, and Padding</dd>
<dt>Reserved:</dt>
<dd>Zero when sent, ignored when received</dd>
<dt>Mode ID:</dt>
<dd>Defines the proposed or selected NAT traversal mode(s)</dd>
</dl>
<t>The following NAT traversal mode IDs are defined:</t>
<table align="center">
<name>NAT Traversal Mode IDs
</name>
<thead>
<tr>
<th>ID name</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>RESERVED</td>
<td>0</td>
</tr>
<tr>
<td>UDP-ENCAPSULATION</td>
<td>1</td>
</tr>
<tr>
<td>ICE-STUN-UDP</td>
<td>2</td>
</tr>
<tr>
<td>ICE-HIP-UDP</td>
<td>3</td>
</tr>
</tbody>
</table>
<t> The sender of a NAT_TRAVERSAL_MODE parameter <bcp14>MUST</bcp14> mak
e sure that
there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. Conversely, a recipient MUST be prepared to handle received parameter. Conversely, a recipient <bcp14>MUST</bcp14> be prepared to ha ndle received
NAT traversal mode parameters that contain more than six Mode IDs by NAT traversal mode parameters that contain more than six Mode IDs by
accepting the first six Mode IDs and dropping the rest. The limited accepting the first six Mode IDs and dropping the rest. The limited
number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE
parameter. The modes MUST be in preference order, most preferred parameter. The modes <bcp14>MUST</bcp14> be in preference order, most pr eferred
mode(s) first. </t> mode(s) first. </t>
<t>Implementations conforming to this specification
<bcp14>MUST</bcp14> implement UDP-ENCAPSULATION and
<bcp14>SHOULD</bcp14> implement ICE-HIP-UDP modes.</t>
</section>
<t>Implementations conforming to this specification MUST <section anchor="sec_check-pacing-param" numbered="true" toc="default">
implement UDP-ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes.</t> <name>Connectivity Check Transaction Pacing Parameter</name>
<t> The TRANSACTION_PACING parameter is defined in <xref target="RFC5770
</section> <!-- NAT Traversal Mode Parameter --> "
format="default"/> but repeated in <xref target="fig_check_pacing"
<section anchor="sec:check-pacing-param" format="default"/> for completeness. It contains only the connectivity
title="Connectivity Check Transaction Pacing Parameter"> check pacing value, expressed in milliseconds, as a 32-bit unsigned
integer.</t>
<t> The TRANSACTION_PACING is defined in <xref target="RFC5770"/>, but r <figure anchor="fig_check_pacing">
epeated in <name>Format of the TRANSACTION_PACING Parameter</name>
<xref target="fig:check_pacing"/> for completeness. It contains onl <artwork name="" type="" alt=""><![CDATA[
y the connectivity check pacing
value, expressed in milliseconds, as a 32-bit unsigned integer.</t>
<figure anchor="fig:check_pacing"
title="Format of the TRANSACTION_PACING Parameter">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta | | Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type 610
Length 4
Min Ta the minimum connectivity check transaction pacing
value the host would use (in milliseconds)
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<dd>610</dd>
<dt>Length:</dt>
<dd>4</dd>
<dt>Min Ta:</dt>
<dd>The minimum connectivity check transaction pacing value the host would
use (in milliseconds)</dd>
</dl>
</section> </section>
<section anchor="sec:rel-reg-params" <section anchor="sec_rel-reg-params" numbered="true" toc="default">
title="Relay and Registration Parameters"> <name>Relay and Registration Parameters</name>
<t> The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
<t> The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is s shown in <xref target="fig_reg_from" format="default"/>. All
hown parameters are identical except for the type. Of the three, only
in <xref target="fig:reg_from" />. All parameters are identical except REG_FROM is covered by the signature. </t>
for the type. Of the three, only REG_FROM is covered by the <figure anchor="fig_reg_from">
signature. </t> <name>Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters</nam
e>
<figure anchor="fig:reg_from" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type REG_FROM: 950
RELAY_FROM: 63998
RELAY_TO: 64002
Length 20
Port transport port number; zero when plain IP is used
Protocol IANA assigned, Internet Protocol number.
17 for UDP, 0 for plain IP
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<dd>
<dl newline="false" spacing="compact">
<dt>REG_FROM:</dt>
<dd>950</dd>
<dt>RELAY_FROM:</dt>
<dd>63998</dd>
<dt>RELAY_TO:</dt>
<dd>64002</dd>
</dl>
</dd>
<dt>Length:</dt>
<dd>20 </dd>
<dt>Port:</dt>
<dd>Transport port number; zero when plain IP is used</dd>
<dt>Protocol:</dt>
<dd>IANA-assigned, Internet Protocol number. 17 for UDP; 0 for plain
IP</dd>
<dt>Reserved:</dt>
<dd>Reserved for future use; zero when sent, ignored when received</dd>
<dt>Address:</dt>
<dd>An IPv6 address or an IPv4 address in "IPv4-mapped IPv6 address"
format</dd>
</dl>
<t> REG_FROM contains the transport address and protocol from which the Control <t> REG_FROM contains the transport address and protocol from which the Control
Relay Server sees the registration coming. RELAY_FROM contains the Relay Server sees the registration coming. RELAY_FROM contains the
address from which the relayed packet was received by the Control Relay Server address from which the relayed packet was received by the Control Relay Server
and the protocol that was used. RELAY_TO contains the same information and the protocol that was used. RELAY_TO contains the same information
about the address to which a packet should be forwarded. </t> about the address to which a packet should be forwarded. </t>
</section>
</section> <!-- Relay and Registration Parameters --> <section anchor="sec_locator_format" numbered="true" toc="default">
<name>LOCATOR_SET Parameter</name>
<section title="LOCATOR_SET Parameter" anchor="sec:locator_format"> <t>This specification reuses the format for UDP-based locators as
specified in Legacy ICE-HIP <xref target="RFC5770" format="default"/>
<t>This specification reuses the format for UDP-based locators as specif to be used for communicating the address candidates between two
ied hosts. The generic and NAT-traversal-specific locator parameters are
in Legacy ICE-HIP <xref target="RFC5770"/> to be used for communicating illustrated in <xref target="fig_locator" format="default"/>. </t>
the <figure anchor="fig_locator">
address candidates between two hosts. The generic and NAT-traversal-spec <name>LOCATOR_SET Parameter</name>
ific locator parameters <artwork align="center" name="" type="" alt=""><![CDATA[
are illustrated in <xref target="fig:locator"/>. </t>
<figure anchor="fig:locator" title="LOCATOR_SET Parameter">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P| | Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator | | Locator |
skipping to change at line 2320 skipping to change at line 2147
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | | Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> The individual fields in the LOCATOR_SET parameter are described in <t> The individual fields in the LOCATOR_SET parameter are described in
<xref target="tbl:locator"/>. </t> <xref target="tbl_locator" format="default"/>. </t>
<table anchor="tbl_locator" align="center">
<texttable anchor="tbl:locator" <name>Fields of the LOCATOR_SET Parameter</name>
title="Fields of the LOCATOR_SET Parameter"> <thead>
<ttcol align="left">Field</ttcol> <tr>
<ttcol align="left">Value(s)</ttcol> <th align="left">Field</th>
<ttcol align="left">Purpose</ttcol> <th align="left">Value(s)</th>
<c>Type</c> <th align="left">Purpose</th>
<c>193</c> </tr>
<c>Parameter type</c> </thead>
<c>Length</c> <tbody>
<c>Variable</c> <tr>
<c>Length in octets, excluding Type and Length fields and padding</c> <td align="left">Type</td>
<c>Traffic Type</c> <td align="left">193</td>
<c>0-2</c> <td align="left">Parameter type</td>
<c>Is the locator for HIP signaling (1), for ESP (2), or for </tr>
both (0)</c> <tr>
<c>Locator Type</c> <td align="left">Length</td>
<c>2</c> <td align="left">Variable</td>
<c>"Transport address" locator type</c> <td align="left">Length in octets, excluding Type and Length field
<c>Locator Length</c> s and padding</td>
<c>7</c> </tr>
<c>Length of the fields after Locator Lifetime in 4-octet units</c> <tr>
<c>Reserved</c> <td align="left">Traffic Type</td>
<c>0</c> <td align="left">0-2</td>
<c>Reserved for future extensions</c> <td align="left">The locator for either HIP signaling (1) or ESP (
<c>Preferred (P) bit</c> 2), or for
<c>0 or 1</c> both (0)</td>
<c>Set to 1 for a Locator in R1 if the Responder can use it for the </tr>
rest of the base exchange, otherwise set to zero</c> <tr>
<c>Locator Lifetime</c> <td align="left">Locator Type</td>
<c>Variable</c> <td align="left">2</td>
<c>Locator lifetime in seconds, see Section 4 in <xref target="RFC8046 <td align="left">"Transport address" locator type</td>
" /></c> </tr>
<c>Transport Port</c> <tr>
<c>Variable</c> <td align="left">Locator Length</td>
<c>Transport layer port number</c> <td align="left">7</td>
<c>Transport Protocol</c> <td align="left">Length of the fields after Locator Lifetime in 4-
<c>Variable</c> octet units</td>
<c>IANA assigned, transport layer Internet Protocol number. </tr>
Currently only UDP (17) is supported.</c> <tr>
<c>Kind</c> <td align="left">Reserved</td>
<c>Variable</c> <td align="left">0</td>
<c>0 for host, 1 for server reflexive, 2 for peer reflexive (currently <td align="left">Reserved for future extensions</td>
unused) or 3 for </tr>
relayed address</c> <tr>
<c>Priority</c> <td align="left">Preferred (P) bit</td>
<c>Variable</c> <td align="left">0 or 1</td>
<c>Locator's priority as described in <td align="left">Set to 1 for a Locator in R1 if the Responder can
<xref target="RFC8445"/>. It is worth noting that while the priority use it for the
of a single locator candidate is 32-bits, but rest of the base exchange, otherwise set to zero</td>
an implementation should use a 64-bit integer to calculate the priori </tr>
ty of a candidate pair for the ICE priority algorithm.</c> <tr>
<c>SPI</c> <td align="left">Locator Lifetime</td>
<c>Variable</c> <td align="left">Variable</td>
<c>Security Parameter Index (SPI) value that the host expects to see i <td align="left">Locator lifetime in seconds, see
n incoming ESP packets <xref target="RFC8046" sectionFormat="of" section="4"/></td>
that use this locator</c> </tr>
<c>Address</c> <tr>
<c>Variable</c> <td align="left">Transport Port</td>
<c>IPv6 address or an "IPv4-Mapped IPv6 address" format IPv4 <td align="left">Variable</td>
address <xref target="RFC4291"/></c> <td align="left">Transport-layer port number</td>
</texttable> </tr>
<tr>
<t>The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED paramet <td align="left">Transport Protocol</td>
er.</t> <td align="left">Variable</td>
<td align="left">IANA-assigned, transport-layer Internet Protocol
</section> <!-- locator parameter format --> number.
Currently, only UDP (17) is supported.</td>
<section anchor="sec:relay-hmac" title="RELAY_HMAC Parameter"> </tr>
<tr>
<t>As specified in Legacy ICE-HIP <xref target="RFC5770"/>, <td align="left">Kind</td>
the RELAY_HMAC parameter value has the TLV type 65520. It has <td align="left">Variable</td>
the same semantics as RVS_HMAC as specified in section 4.2.1 <td align="left">0 for host, 1 for server reflexive, 2 for peer
in <xref target="RFC8004"/>. Similarly as with RVS_HMAC, also reflexive (currently unused), or 3 for relayed address</td>
RELAY_HMAC is keyed with the HIP integrity key (HIP-lg or </tr>
HIP-gl as specified in section 6.5 in <xref target="RFC7401" <tr>
/>), established during the relay registration procedure as <td align="left">Priority</td>
described in <xref target="sec:registration" />.</t> <td align="left">Variable</td>
<td align="left">Locator's priority as described in <xref
target="RFC8445" format="default"/>. It is worth noting that
while the priority of a single locator candidate is 32 bits, an
implementation should a 64-bit integer to calculate the priority
of a candidate pair for the ICE priority algorithm.</td>
</section> <!-- RELAY_HMAC --> </tr>
<tr>
<td align="left">SPI</td>
<td align="left">Variable</td>
<td align="left">Security Parameter Index (SPI) value that the
host expects to see in incoming ESP packets that use this
locator</td>
</tr>
<tr>
<td align="left">Address</td>
<td align="left">Variable</td>
<td align="left">IPv6 address or an "IPv4-mapped IPv6 address"
format IPv4 address <xref target="RFC4291"
format="default"/></td>
</tr>
</tbody>
</table>
<t>The LOCATOR parameter <bcp14>MUST</bcp14> be encapsulated inside an
ENCRYPTED parameter.</t>
</section>
<section anchor="sec:reg-types" title="Registration Types"> <section anchor="sec_relay-hmac" numbered="true" toc="default">
<name>RELAY_HMAC Parameter</name>
<t>As specified in Legacy ICE-HIP <xref target="RFC5770"
format="default"/>, the RELAY_HMAC parameter value has the TLV type
65520. It has the same semantics as RVS_HMAC as specified in <xref
target="RFC8004" sectionFormat="of" section="4.2.1"/>. Similar to
RVS_HMAC, RELAY_HMAC is also keyed with the HIP integrity key
(HIP-lg or HIP-gl as specified in <xref target="RFC7401" section="6.5"
sectionFormat="of"/>), established during the relay registration
procedure as described in <xref target="sec_registration"
format="default"/>.</t>
</section>
<section anchor="sec_reg-types" numbered="true" toc="default">
<name>Registration Types</name>
<t> The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain <t> The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
Registration Type <xref target="RFC8003"/> values for Control Relay Serv Registration Type <xref target="RFC8003" format="default"/> values for
er Control Relay Server registration. The value for RELAY_UDP_HIP is 2 as
registration. The value for RELAY_UDP_HIP is 2 as specified in Legacy IC specified in Legacy ICE-HIP <xref target="RFC5770"
E-HIP <xref target="RFC5770"/>. format="default"/>. The value for RELAY_UDP_ESP is 3.</t>
The value for RELAY_UDP_ESP is (value [TBD by IANA: 3]). </section>
</t>
</section> <!-- Registration Types -->
<section anchor="sec:notify-types" title="Notify Packet Types">
<t>A Control/Data Relay Server and end-hosts can use NOTIFY packets to s
ignal
different error conditions. The NOTIFY packet types are the same as in L
egacy ICE-HIP <xref target="RFC5770"/> except for the two last ones, which are n
ew.</t>
<t>The Notify Packet Types <xref
target="RFC7401"/> are shown below. The
Notification Data field for the error notifications SHOULD contain the
HIP header of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. </t>
<figure> <artwork>
NOTIFICATION PARAMETER - ERROR TYPES Value
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
</artwork> </figure>
<t><list>
<t> If a Control Relay Server does not forward a base exchange
packet due to missing NAT traversal mode parameter, or the
Initiator selects a NAT traversal mode that the (non-relay) Responde
r did not
expect, the Control Relay Server or the Responder may send back a NO
TIFY error
packet with this type. </t>
</list></t>
<figure> <artwork>
CONNECTIVITY_CHECKS_FAILED 61
</artwork> </figure>
<t><list>
<t> Used by the end-hosts to signal that NAT traversal connectivity
checks failed and did not produce a working path. </t>
</list> </t>
<figure> <artwork>
MESSAGE_NOT_RELAYED 62
</artwork> </figure>
<t><list> <section anchor="sec_notify-types" numbered="true" toc="default">
<t> Used by a Control Relay Server to signal that is was not able or <name>Notify Packet Types</name>
willing to relay a HIP packet. </t> <t>A Control/Data Relay Server and end hosts can use NOTIFY packets to
</list> </t> signal different error conditions. The NOTIFY packet types are the
same as in Legacy ICE-HIP <xref target="RFC5770" format="default"/>
except for the two last ones, which are new.</t>
<t>The Notify Packet Types <xref target="RFC7401" format="default"/>
are shown below. The Notification Data field for the error
notifications <bcp14>SHOULD</bcp14> contain the HIP header of the
rejected packet and <bcp14>SHOULD</bcp14> be empty for the
CONNECTIVITY_CHECKS_FAILED type. </t>
<figure> <artwork> <table anchor="notif-param-error-types">
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63 <name>Notify Packet Types
</artwork> </figure> </name>
<thead>
<t><list> <tr>
<t> Used by a Data Relay Server to signal that is was not able or <th>NOTIFICATION PARAMETER - ERROR TYPES</th>
willing to allocate a new server reflexive candidate for the Data Re <th>Value</th>
lay Client</t> </tr>
</list> </t> </thead>
<tbody>
<tr>
<td><t>NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER</t>
<t>If a Control Relay Server does not forward a base exchange packet due
to a missing NAT traversal mode parameter, or the Initiator selects a
NAT traversal mode that the (non-relay) Responder did not expect, the
Control Relay Server or the Responder may send back a NOTIFY error
packet with this type.</t></td>
<td>60</td>
</tr>
<tr>
<figure> <artwork> <td><t>CONNECTIVITY_CHECKS_FAILED</t>
RVS_HMAC_PROHIBITED_WITH_RELAY 64 <t>Used by the end hosts to signal that NAT traversal
</artwork> </figure> connectivity checks failed and did not produce a working path.</t></td>
<td>61</td>
</tr>
<t><list> <tr>
<t> In the unintended event that a Control Relay Server sends any HIP <td><t>MESSAGE_NOT_RELAYED</t>
message with a RVS_HMAC parameter, <t>Used by a Control Relay Server to signal that it was not able or
the Control Relay Client drops the received HIP message and sends a willing to relay a HIP packet.</t></td>
notify message back to the Control Relay Server using this notify type</t> <td>62</td>
</list></t> </tr>
</section> <!-- Notify Packet Types --> <tr>
<td><t>SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED</t>
<t>Used by a Data Relay Server to signal that it was not able or
willing to allocate a new server-reflexive candidate for the Data
Relay Client.</t></td>
<td>63</td>
</tr>
<tr>
<section anchor="sec:udpesp" title="ESP Data Packets"> <td><t>RVS_HMAC_PROHIBITED_WITH_RELAY</t>
<t>In the unintended event that a Control Relay Server sends any HIP
message with an RVS_HMAC parameter, the Control Relay Client drops the
received HIP message and sends a notify message back to the Control
Relay Server using this notify type.</t></td>
<td>64</td>
</tr>
</tbody>
</table>
<t>The format for ESP data packets is identical to Legacy ICE-HIP <xref target="RFC5770"/>.</t> </section>
<t> <xref target="RFC3948"/> describes the UDP encapsulation of the <section anchor="sec_udpesp" numbered="true" toc="default">
<name>ESP Data Packets</name>
<t>The format for ESP data packets is identical to Legacy ICE-HIP
<xref target="RFC5770" format="default"/>.</t>
<t> <xref target="RFC3948" format="default"/> describes the UDP encapsul
ation of the
IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets 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 do not differ from the transport mode ESP; thus, the encapsulation
of the HIP ESP packets is same as the UDP encapsulation transport mode of the HIP ESP packets is same as the UDP encapsulation transport mode
ESP. However, the (semantic) difference to Bound End-to-End Tunnel ESP. However, the (semantic) difference to Bound End-to-End Tunnel
(BEET) mode ESP packets used by HIP is that IP header is not used in (BEET) mode ESP packets used by HIP is that the IP header is not used in
BEET integrity protection calculation.</t> BEET integrity protection calculation.</t>
<t> During the HIP base exchange, the two peers exchange parameters <t> During the HIP base exchange, the two peers exchange parameters
that enable them to define a pair of IPsec ESP security associations that enable them to define a pair of IPsec ESP security associations
(SAs) as described in <xref target="RFC7402"/>. When two peers perform (SAs) as described in <xref target="RFC7402" format="default"/>. When tw
a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs o peers perform
a UDP-encapsulated base exchange, they <bcp14>MUST</bcp14> define a pair
of IPsec SAs
that produces UDP-encapsulated ESP data traffic. </t> that produces UDP-encapsulated ESP data traffic. </t>
<t> The management of encryption/authentication protocols and SPIs is <t> The management of encryption/authentication protocols and SPIs is
defined in <xref target="RFC7402"/>. The UDP encapsulation format and defined in <xref target="RFC7402" format="default"/>. The UDP
processing of HIP ESP traffic is described in Section 6.1 of <xref encapsulation format and processing of HIP ESP traffic is described in
target="RFC7402"/>. </t> <xref target="RFC7402" sectionFormat="of" section="6.1"/>. </t>
<!--
<t>It is worth noting that UDP encapsulation of ESP reduces
the MTU size of data plane by 8 bytes.
</t>
-->
</section> </section>
<section anchor="sec_relayed_address" numbered="true" toc="default">
<section anchor="sec:relayed_address" <name>RELAYED_ADDRESS and MAPPED_ADDRESS Parameters</name>
title="RELAYED_ADDRESS and MAPPED_ADDRESS Parameters"> <t>While the type values are new, the format of the RELAYED_ADDRESS
and MAPPED_ADDRESS parameters (<xref target="fig_relayed_address"
<t>While the type values are new, the format of the RELAYED_ADDRESS and format="default"/>) is identical to REG_FROM, RELAY_FROM, and RELAY_TO
MAPPED_ADDRESS parameters parameters. This document specifies only the use of UDP relaying;
(<xref target="fig:relayed_address"/>) is identical to REG_FROM, thus, only protocol 17 is allowed. However, future documents may
RELAY_FROM and RELAY_TO parameters. This document specifies only the use specify support for other protocols.</t>
of <figure anchor="fig_relayed_address">
UDP relaying, and, thus, only protocol 17 is allowed. However, future <name>Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters</nam
documents may specify support for other protocols.</t> e>
<artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig:relayed_address"
title="Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters">
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type [TBD by IANA;
RELAYED_ADDRESS: 4650
MAPPED_ADDRESS: 4660]
Length 20
Port the UDP port number
Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format
]]></artwork>
</figure> </figure>
<!-- These parameters are not in the RVS and relaying range <dl newline="false" spacing="normal" indent="12">
since they should be signed by the Relay Server --> <dt>Type:</dt>
<dd>
<dl newline="false" spacing="compact">
<dt>RELAYED_ADDRESS:</dt>
<dd>4650</dd>
<dt>MAPPED_ADDRESS:</dt>
<dd>4660</dd>
</dl>
</dd>
<dt>Length:</dt>
<dd>20</dd>
<dt>Port:</dt>
<dd>The UDP port number</dd>
<dt>Protocol:</dt>
<dd>IANA-assigned, Internet Protocol number (17 for UDP)</dd>
<dt>Reserved:</dt>
<dd>Reserved for future use; zero when sent, ignored when received</dd>
<dt>Address:</dt>
<dd>An IPv6 address or an IPv4 address in "IPv4-mapped IPv6 address"
format</dd>
</dl>
</section> </section>
<section anchor="sec_peer_permission" numbered="true" toc="default">
<section anchor="sec:peer_permission" <name>PEER_PERMISSION Parameter</name>
title="PEER_PERMISSION Parameter">
<t> The format of the new PEER_PERMISSION parameter is shown in <xref <t> The format of the new PEER_PERMISSION parameter is shown in <xref
target="fig:peer_permission"/>. The parameter is used for setting up target="fig_peer_permission" format="default"/>. The parameter is used
and refreshing forwarding rules and the permissions for data packets at for setting up and refreshing forwarding rules and the permissions for
the Data Relay Server. The parameter contains one or more sets of Port, data packets at the Data Relay Server. The parameter contains one or
Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) more sets of Port, Protocol, Address, Outbound SPI (OSPI), and Inbound
values. One set defines a rule for one peer address. </t> SPI (ISPI) values. One set defines a rule for one peer address. </t>
<figure anchor="fig_peer_permission">
<figure anchor="fig:peer_permission" <name>Format of the PEER_PERMISSION Parameter</name>
title="Format of the PEER_PERMISSION Parameter"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPort | PPort | | RPort | PPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 2582 skipping to change at line 2446
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| PAddress | | PAddress |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI | | OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type [TBD by IANA; 4680]
Length 48
RPort the transport layer (UDP) port at the Data Relay Server
(i.e. the port of the server reflexive candidate)
PPort the transport layer (UDP) port number of the peer
Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored
when received
RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the server reflexive candidate
PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer
OSPI the outbound SPI value the Data Relay Client is using for
the peer
ISPI the inbound SPI value the Data Relay Client is using for
the peer
]]></artwork>
</figure> </figure>
</section> <dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<section anchor="sec:con-check" title="HIP Connectivity Check Packets"> <dd>4680</dd>
<dt>Length:</dt>
<t>The connectivity request messages are HIP UPDATE packets containing a <dd>48</dd>
new <dt>RPort:</dt>
CANDIDATE_PRIORITY parameter (<xref target="fig:candidate_priority"/>). <dd>The transport-layer (UDP) port at the Data Relay Server (i.e., the port
Response UPDATE packets contain a MAPPED_ADDRESS parameter (<xref of the server-reflexive candidate)</dd>
target="fig:relayed_address"/>). </t> <dt>PPort:</dt>
<dd>The transport-layer (UDP) port number of the peer</dd>
<dt>Protocol:</dt>
<dd>IANA-assigned, Internet Protocol number (17 for UDP)</dd>
<dt>Reserved:</dt>
<dd>Reserved for future use; zero when sent, ignored when received</dd>
<dt>RAddress:</dt>
<dd>An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address"
format, of the server-reflexive candidate</dd>
<dt>PAddress:</dt>
<dd>An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6 address"
format, of the peer</dd>
<dt>OSPI:</dt>
<dd>The outbound SPI value the Data Relay Client is using for the peer</dd>
<dt>ISPI:</dt>
<dd>The inbound SPI value the Data Relay Client is using for the peer</dd>
</dl>
<figure anchor="fig:candidate_priority" </section>
title="Format of the CANDIDATE_PRIORITY Parameter"> <section anchor="sec_con-check" numbered="true" toc="default">
<artwork align="center"><![CDATA[ <name>HIP Connectivity Check Packets</name>
<t>The connectivity request messages are HIP UPDATE packets containing
a new CANDIDATE_PRIORITY parameter (<xref
target="fig_candidate_priority" format="default"/>). Response UPDATE
packets contain a MAPPED_ADDRESS parameter (<xref
target="fig_relayed_address" format="default"/>). </t>
<figure anchor="fig_candidate_priority">
<name>Format of the CANDIDATE_PRIORITY Parameter</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type [TBD by IANA; 4700]
Length 4
Priority the priority of a (potential) peer reflexive candidate
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<dd>4700</dd>
<dt>Length:</dt>
<dd>4</dd>
<dt>Priority:</dt>
<dd>The priority of a (potential) peer-reflexive candidate</dd>
</dl>
</section> </section>
<section anchor="sec:nominate" title="NOMINATE parameter"> <section anchor="sec_nominate" numbered="true" toc="default">
<name>NOMINATE Parameter</name>
<t><xref target="fig:nominate"/> shows the NOMINATE <t><xref target="fig_nominate" format="default"/> shows the NOMINATE
parameter that is used to conclude the candidate nomination parameter that is used to conclude the candidate nomination
process.</t> process.</t>
<figure anchor="fig_nominate">
<figure anchor="fig:nominate" <name>Format of the NOMINATE Parameter</name>
title="Format of the NOMINATE Parameter"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type [TBD by IANA; 4710]
Length 4
Reserved Reserved for future extension purposes
]]></artwork>
</figure> </figure>
</section> <dl newline="false" spacing="normal" indent="12">
<dt>Type:</dt>
<dd>4710</dd>
<dt>Length:</dt>
<dd>4</dd>
<dt>Reserved:</dt>
<dd>Reserved for future extension purposes</dd>
</dl>
</section>
</section> </section>
<!-- ***************************************************************** --> <section>
<name>IAB Considerations
<section title="Security Considerations"> </name>
<t>Since the control plane protocol and Control Relay Server are <t>The ICE specification <xref target="RFC8445" format="default"/> discuss
essentially the same (with some minor differences) in this es
document as in Legacy ICE-HIP <xref target="RFC5770"/>, the "Unilateral Self-Address Fixing" in Section <xref target="RFC8445"
same security considerations (in <xref target="sec:privacy" />, <xref targ sectionFormat="bare" section="18"/>. This protocol is based on ICE; thus,
et="sec:opportunistic" />, <xref target="sec:bex_replay" /> and <xref target="se the same considerations also apply here.
c:demux" />,) are still
valid, but are repeated here for the sake of completeness.
New security considerations related to the new Data Relay Server are discu
ssed in <xref target="sec:reuse"/>, and considerations related to the new
connectivity check protocol are discussed in <xref target="sec:amplificati
on" /> and <xref target="sec:conn_attack" />.
</t> </t>
</section>
<section anchor="sec:privacy" title="Privacy Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<!--
<t> The locators are in plain text format in favor of inspection at <t>Since the control plane protocol and Control Relay Server are
HIP-aware middleboxes in the future. The current document does not speci essentially the same (with some minor differences) in this document as
fy in Legacy ICE-HIP <xref target="RFC5770" format="default"/>, the same
encrypted versions of LOCATOR_SETs, even though it could be beneficial f security considerations (in Sections <xref target="sec_privacy"
or format="counter"/>, <xref target="sec_opportunistic" format="counter"/>,
privacy reasons to avoid disclosing them to middleboxes. </t> <xref target="sec_bex_replay" format="counter"/>, and <xref
--> target="sec_demux" format="counter"/>) are still valid, but are
repeated here for the sake of completeness. New security considerations
related to the new Data Relay Server are discussed in <xref
target="sec_reuse" format="default"/>, and considerations related to the
new connectivity check protocol are discussed in Sections <xref
target="sec_amplification" format="counter"/> and <xref
target="sec_conn_attack" format="counter"/>.</t>
<section anchor="sec_privacy" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t> It is also possible that end-users may not want to reveal all <t> It is also possible that end users may not want to reveal all
locators to each other. For example, tracking the physical location of locators to each other. For example, tracking the physical location of
a multihoming end-host may become easier if it reveals all locators to a multihoming end host may become easier if it reveals all locators to
its peer during a base exchange. Also, revealing host addresses exposes its peer during a base exchange. Also, revealing host addresses exposes
information about the local topology that may not be allowed in all information about the local topology that may not be allowed in all
corporate environments. corporate environments.
For these two local policy reasons, it might be tempting exclude For these two local policy reasons, it might be tempting to exclude
certain host addresses from the LOCATOR_SET parameter of an end-host but certain host addresses from the LOCATOR_SET parameter of an end host, bu
this is NOT RECOMMENDED. t
<!-- but this requires further experimentation. --> this is <bcp14>NOT RECOMMENDED</bcp14>.
For instance, such For instance, such
behavior creates non-optimal paths when the hosts are located behind behavior creates non-optimal paths when the hosts are located behind
the same NAT. Especially, this could be problematic with a legacy NAT the same NAT. Especially, this could be problematic with a legacy NAT
that does not support routing from the private address realm back to that does not support routing from the private address realm back to
itself through the outer address of the NAT. This scenario is referred itself through the outer address of the NAT. This scenario is referred
to as the hairpin problem <xref target="RFC5128"/>. With such a legacy to as the hairpin problem <xref target="RFC5128" format="default"/>. Wit h such a legacy
NAT, the only option left would be to use a relayed transport address NAT, the only option left would be to use a relayed transport address
from an Data Relay Server.</t> from a Data Relay Server.</t>
<t> The use of Control and Data Relay Servers can also be useful for
<t> The use of Control and Data Relay Servers can be also useful for privacy purposes. For example, a privacy-concerned Responder may reveal
privacy purposes. For example, a privacy concerned Responder may reveal
only its Control Relay Server and Relayed candidates to Initiators. This only its Control Relay Server and Relayed candidates to Initiators. This
partially protects the Responder against Denial-of-Service (DoS) partially protects the Responder against Denial-of-Service (DoS)
attacks by allowing the Responder to initiate new connections even if attacks by allowing the Responder to initiate new connections even if
its relays would be unavailable due to a DoS attack. </t> its relays would be unavailable due to a DoS attack. </t>
</section>
</section> <!-- privacy --> <section anchor="sec_opportunistic" numbered="true" toc="default">
<name>Opportunistic Mode</name>
<section anchor="sec:opportunistic" title="Opportunistic Mode"> <t>In opportunistic HIP mode (cf.&nbsp;<xref target="RFC7401"
sectionFormat="of" section="4.1.8"/>), an Initiator sends an I1
<t>In opportunistic HIP mode (cf. Section 4.1.8 in <xref target="RFC7401 without setting the destination HIT of the Responder (i.e., the
" />), an Initiator sends an I1 with Control Relay Client). A Control Relay Server <bcp14>SHOULD</bcp14>
without setting the destination HIT of the Responder (i.e. the have a unique IP address per the Control Relay Client when the Control
Control Relay Client). A Control Relay Server SHOULD have a
unique IP address per Control Relay Client when the Control
Relay Server is serving more than one Control Relay Client and Relay Server is serving more than one Control Relay Client and
supports opportunistic mode. Otherwise, the Control Relay supports opportunistic mode. Otherwise, the Control Relay Server
Server cannot guarantee to deliver the I1 packet to the cannot guarantee to deliver the I1 packet to the intended recipient.
intended recipient. Future extensions of this document may Future extensions of this document may allow opportunistic mode to be
allow opportunistic mode to be used with non-unique IP used with non-unique IP addresses to be utilized either as a HIP-level
addresses to be utilized either as a HIP-level anycast or multicast anycast or multicast mechanism. Both of the mentioned cases would
mechanism. Both of the mentioned cases would require a separate registra require separate registration parameters that the Control Relay
tion Server proposes and the Control Client Server accepts during
parameters that the Control Relay Server proposes and the registration.</t>
Control Client Server accepts during registration.</t> </section>
</section> <!-- opportunistic -->
<section anchor="sec:bex_replay" title="Base Exchange Replay Protection fo
r Control Relay Server">
<section anchor="sec_bex_replay" numbered="true" toc="default">
<name>Base Exchange Replay Protection for Control Relay Server</name>
<t> In certain scenarios, it is possible that an attacker, or two <t> In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a Control Relay S erver attackers, can replay an earlier base exchange through a Control Relay S erver
by masquerading as the original Initiator and Responder. The by masquerading as the original Initiator and Responder. The
attack does not require the attacker(s) to compromise the private attack does not require the attacker(s) to compromise the private
key(s) of the attacked host(s). However, for this attack to succeed, key(s) of the attacked host(s). However, for this attack to succeed,
the legitimate Responder has to be disconnected from the Control Relay S erver. </t> the legitimate Responder has to be disconnected from the Control Relay S erver. </t>
<t> The Control Relay Server can protect itself against replay attacks b y becoming <t> The Control Relay Server can protect itself against replay attacks b y becoming
involved in the base exchange by introducing nonces that the end-hosts involved in the base exchange by introducing nonces that the end hosts
(Initiator and Responder) are required to sign. One way to do this is (Initiator and Responder) are required to sign. One way to do this is
to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described
in <xref target="I-D.heer-hip-middle-auth" /> and drop the I2 or R2 in <xref target="I-D.heer-hip-middle-auth" format="default"/> and drop t he I2 or R2
packets if the corresponding ECHO_RESPONSE_M parameters are not packets if the corresponding ECHO_RESPONSE_M parameters are not
present. </t> present. </t>
</section> </section>
<section anchor="sec_demux" numbered="true" toc="default">
<name>Demultiplexing Different HIP Associations</name>
<section anchor="sec:demux" title="Demultiplexing Different HIP Associatio <t><xref target="RFC3948" sectionFormat="of" section="5.1"/> describes
ns"> a security issue for the UDP encapsulation in the standard IP tunnel
mode when two hosts behind different NATs have the same private IP
<t> Section 5.1 of <xref target="RFC3948"/> describes a security issue address and initiate communication to the same Responder in the public
for the UDP encapsulation in the standard IP tunnel mode when two hosts Internet. The Responder cannot distinguish between two hosts because
behind different NATs have the same private IP address and initiate security associations are based on the same inner IP addresses. </t>
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 <t> This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder uses HITs to distinguish between transport format because the Responder uses HITs to distinguish between
different Initiators. </t> different Initiators. </t>
</section>
<section anchor="sec_reuse" numbered="true" toc="default">
<name>Reuse of Ports at the Data Relay Server</name>
<t> If the Data Relay Server uses the same relayed address and port
(as conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay
Clients, it appears to all the peers, and their firewalls, that all
the Data Relay Clients are at the same address. Thus, a stateful
firewall may allow packets to pass from hosts that would not normally be
able to send packets to a peer behind the firewall. Therefore, a Data
Relay Server <bcp14>SHOULD NOT</bcp14> reuse the port numbers. If
port numbers need to be reused, the Data Relay Server
<bcp14>SHOULD</bcp14> have a sufficiently large pool of port numbers
and randomly select ports from the pool to decrease the chances of a
Data Relay Client obtaining the same address that another host
behind the same firewall is using. </t>
</section> </section>
<section anchor="sec:reuse" title="Reuse of Ports at the Data Relay Server <section anchor="sec_amplification" numbered="true" toc="default">
"> <name>Amplification Attacks</name>
<t>A malicious host may send an invalid list of candidates to
<t> If the Data Relay Server uses the same relayed address and port (as
conveyed in the RELAYED_ADDRESS parameter) for multiple
Data Relay Clients, it appears to all the peers, and their firewalls, th
at
all the Data Relay Clients are at the same address. Thus, a
stateful firewall may allow packets pass from hosts that would not
normally be able to send packets to a peer behind the
firewall. Therefore, a Data Relay Server SHOULD NOT re-use the port
numbers. If port numbers need to be re-used, the Data Relay Server SHOUL
D have a
sufficiently large pool of port numbers and select ports from the pool
randomly to decrease the chances of a Data Relay Client obtaining the sa
me
address that a another host behind the same firewall is using. </t>
</section> <!-- Reuse of Ports at the Data Relay -->
<section anchor="sec:amplification" title="Amplification attacks">
<t>A malicious host may send an invalid list of candidates to
its peer that are used for targeting a victim host by flooding its peer that are used for targeting a victim host by flooding
it with connectivity checks. To mitigate the attack, this it with connectivity checks. To mitigate the attack, this
protocol adopts the ICE mechanism to cap the total amount of protocol adopts the ICE mechanism to cap the total amount of
connectivity checks as defined in <xref connectivity checks as defined in <xref target="sec_alternatives"
target="sec:alternatives" />.</t> format="default"/>.</t>
</section>
</section> <!-- Amplification attacks -->
<section anchor="sec:conn_attack" title="Attacks against Connectivity Chec
ks and Candidate Gathering">
<t>Section 19.2 in <xref target="RFC8445" />
describes attacks against ICE connectivity checks. HIP
bases its control plane security on Diffie-Hellman key
exchange, public keys and Hashed Message Authentication codes,
meaning that the mentioned security concerns do not apply to
HIP either. The mentioned section discusses also of
man-in-the-middle replay attacks that are difficult to
prevent. The connectivity checks in this protocol are effectively immune
against replay attacks because a connectivity request includes
a random nonce that the recipient must sign and send back as a response.
</t>
<t>Section 19.3 in <xref target="RFC8445" /> <section anchor="sec_conn_attack" numbered="true" toc="default">
describes attacks on server reflexive address <name>Attacks against Connectivity Checks and Candidate Gathering</name>
gathering. Similarly here, if the DNS, a Control Relay Server or a Data R <t><xref target="RFC8445" sectionFormat="of" section="19.2"/>
elay Server describes attacks against ICE connectivity checks. HIP bases its
control plane security on Diffie-Hellman key exchange, public keys,
and Hashed Message Authentication codes, meaning that the mentioned
security concerns do not apply to HIP either. The mentioned section
also discusses man-in-the-middle replay attacks that are difficult to
prevent. The connectivity checks in this protocol are effectively
immune against replay attacks because a connectivity request includes
a random nonce that the recipient must sign and send back as a
response.
</t>
<t><xref target="RFC8445" sectionFormat="of" section="19.3"/>
describes attacks on server-reflexive address
gathering. Similarly here, if the DNS, a Control Relay Server, or a Data
Relay Server
has been compromised, not much can be done. However, has been compromised, not much can be done. However,
the case where attacker can inject fake messages (located on a the case where attackers can inject fake messages (located on a
shared network segment like Wifi) does not apply here. HIP shared network segment like Wi-Fi) does not apply here. HIP
messages are integrity and replay protected, so it is not messages are integrity and replay protected, so it is not
possible inject fake server reflexive address candidates. possible to inject fake server-reflexive address candidates.
</t> </t>
<t><xref target="RFC8445" sectionFormat="of" section="19.4"/>
<t>Section 19.4 in <xref target="RFC8445" />
describes attacks on relayed candidate gathering. Similarly to describes attacks on relayed candidate gathering. Similarly to
ICE TURN servers, Data Relay Server require an authenticated base ICE TURN servers, a Data Relay Server requires an authenticated base
exchange that protects relayed address gathering against fake exchange that protects relayed address gathering against fake
requests and responses. Further, replay attacks are not requests and responses. Further, replay attacks are not
possible because the HIP base exchange (and also UPDATE possible because the HIP base exchange (and also UPDATE
procedure) is protected against replay attacks. procedure) is protected against replay attacks.
</t> </t>
</section>
</section> <!-- Attacks against Connectivity Checks and Candidate Gatheri
ng -->
<section anchor="sec:cross_protocol" title="Cross-Protocol Attacks">
<t><xref target="sec:registration"/> explains how a Control
Relay Client registers for the RELAY_UDP_HIP service from a
Control Relay Server. However, the same server may offer also
Rendezvous functionality, and, thus, a client can register
both to a RELAY_UDP_HIP and a RENDEZVOUS (see <xref
target="RFC8004"/>) service from the same server. Potentially,
this introduces a cross-protocol attack (or actually a
"cross-message" attack) because the key material is the same
for the Control Relay Service and Rendezvous HMACs. While the
problem could be avoided by deriving different keys for the
Control Relay Service, a more simple measure was chosen
because the exact attack scenario was unclear. Consequently,
this section defines a mandatory mitigation mechanism against
the cross-protocol attack that works by preventing the
simultanous use of Rendezvous and Control Relay Service in the
context of a single HIP Association.</t>
<t>The registration involves three parameters typically <section anchor="sec_cross_protocol" numbered="true" toc="default">
delivered sequentally in R1 (REG_INFO parameter), I2 <name>Cross-Protocol Attacks</name>
(REG_REQUEST) and R2 (REG_RESPONSE) messages but can also be <t><xref target="sec_registration" format="default"/> explains how a
delivered in UPDATE messages as described in <xref target="RFC8003" />. T Control Relay Client registers for the RELAY_UDP_HIP service from a
he parameters and the Control Relay Server. However, the same server may also offer
Rendezvous functionality; thus, a client can register both to a
RELAY_UDP_HIP and a RENDEZVOUS (see <xref target="RFC8004"
format="default"/>) service from the same server. Potentially, this
introduces a cross-protocol attack (or actually a "cross-message"
attack) because the key material is the same for the Control Relay
Service and Rendezvous HMACs. While the problem could be avoided by
deriving different keys for the Control Relay Service, a more simple
measure was chosen because the exact attack scenario was
unclear. Consequently, this section defines a mandatory mitigation
mechanism against the cross-protocol attack that works by preventing
the simultaneous use of Rendezvous and Control Relay Service in the
context of a single HIP Association.</t>
<t>The registration involves three parameters typically
delivered sequentially in R1 (REG_INFO parameter), I2
(REG_REQUEST), and R2 (REG_RESPONSE) messages but can also be
delivered in UPDATE messages as described in <xref target="RFC8003"
format="default"/>. The parameters and the
modifications to their processing are described below:</t> modifications to their processing are described below:</t>
<dl newline="false" spacing="normal">
<dt>REG_INFO:</dt>
<dd>The Control Relay Server advertises its available services using
this parameter. RELAY_UDP_HIP and RENDEZVOUS services
<bcp14>MAY</bcp14> be included in the first advertisement for the
HIP association, but subsequent ones <bcp14>MUST</bcp14> include only
one of them as agreed in earlier registrations (see steps 2 and
3).</dd>
<dt>REG_REQUEST:</dt>
<dd>The Control Relay Client chooses the services it requires using
this parameter. If the Control Relay Server offered both RENDEZVOUS
or RELAY_UDP_HIP, the Control Relay Client <bcp14>MUST</bcp14>
choose only one of them in the REG_REQUEST parameter. Upon choosing
one of the two, it persists throughout the lifetime of the HIP
association, and the Control Relay Client <bcp14>MUST NOT</bcp14>
register the other remaining one in a subsequent UPDATE
message.</dd>
<dt>REG_RESPONSE:</dt>
<dd>The Control Relay Server verifies the services requested by the
Control Relay Client using this parameter. If the Control Relay
Server offered both RENDEZVOUS and RELAY_UDP_HIP service, and the
Control Relay Client requested for both of them, the Control Relay
Client <bcp14>MUST</bcp14> offer only RELAY_UDP_HIP service in the
REG_RESPONSE parameter and include a REG_FAILED parameter in the
same message, with RENDEZVOUS as the Registration Type and
9 as the Failure Type.</dd>
</dl>
<t>As a further measure against cross-protocol attacks, the Control Rela
y
Client <bcp14>MUST</bcp14> drop any HIP message that includes an
RVS_HMAC parameter when it originates from a successfully registered
Control Relay Server. Upon such an (unintended) event, the Control
Relay Client <bcp14>MUST</bcp14> send a NOTIFY message with
RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Message Type to the
Control Relay Server.</t>
</section>
</section>
<t><list style="numbers"> <section anchor="sec_iana" numbered="true" toc="default">
<t>REG_INFO: the Control Relay Server advertizes its available services <name>IANA Considerations</name>
using this parameter. RELAY_UDP_HIP and RENDEZVOUS services MAY be included in
the first advertizement for the HIP association but subsequent ones MUST include
only one of them as agreed in earlier registrations (see steps 2 and 3).</t>
<t>REG_REQUEST: the Control Relay Client chooses the services it requir
es using this parameter. If the Control Relay Server offered both RENDEZVOUS or
RELAY_UDP_HIP, the Control Relay Client MUST choose only one of them in the REG_
REQUEST parameter. Upon choosing one of of the two, it persists throughout the l
ifetime of the HIP association, and the Control Relay Client MUST NOT register t
he other remaining one in a subsequent UPDATE message.</t>
<t>REG_RESPONSE: the Control Relay Server verifies the services request
ed by the Control Relay Client using this parameter. If the Control Relay Server
offered both RENDEZVOUS and RELAY_UDP_HIP service, and the Control Relay Client
requested for both of them, the Control Relay Client MUST offer only RELAY_UDP_
HIP service in the REG_RESPONSE parameter and include a REG_FAILED parameter in
the same message, with RENDEZVOUS as the Registration Type and [TBD by IANA: 9]
as the Failure Type.</t>
</list></t>
<t>As a further measure against cross-protocol attacks,
Control Relay Client MUST drop any HIP message that includes an
RVS_HMAC parameter when it originates from successfully
registered Control Relay Server. Upon such an (unintended) event, the Con
trol Relay Client
MUST send a NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Not
ify Message Type to the Control Relay Server.
</t>
</section> <!-- Cross-Protocol Attacks -->
</section> <!-- security considerations -->
<!-- ***************************************************************** -->
<section title="IANA Considerations" anchor="sec:iana">
<t> This section is to be interpreted according to <xref <t> This section is to be interpreted according to <xref
target="RFC8126"/>. </t> target="RFC8126" format="default"/>. </t>
<!--
This document should also update the IANA port registry to add a
reference to this RFC-to-be to the existing entry for port 10500
(eventually even with note that this RFC-to-be discusses how to
distinguish the services using NAT_TRAVERSAL_MODE) -->
<t>This document reuses the same default UDP port number 10500
as specified by Legacy ICE-HIP <xref target="RFC5770"/> for
tunneling both HIP control plane and data plane traffic.
The port was was registered separately for RFC5770 to co-author Ari Kerane
n but should now be re-assigned for IESG
control. With the permission of Ari Keranen, the new assignee is IESG and
contact "chair@ietf.org".
In addition, IANA is requested to add a reference to this document in the
entry for UDP port 10500 in the Transport Protocol Port Number Registry.
The selection between Legacy ICE-HIP and Native ICE-HIP mode is negotiated
using NAT_TRAVERSAL_MODE parameter during the base exchange.
By default, hosts listen this port for incoming UDP datagrams and can use
it also for
sending UDP datagrams. Other emphemeral port numbers are negotiated and ut
ilized dynamically.</t>
<t> This document updates the IANA Registry for HIP Parameter Types <xref
target="RFC7401"/> by assigning new HIP Parameter Type
values for the new HIP Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADD
RESS
(length 20, defined in <xref target="sec:relayed_address"/>), PEER_PERMISS
ION
(length 48, defined in <xref target="sec:peer_permission"/>),
CANDIDATE_PRIORITY (length 4, defined in <xref target="sec:con-check"/>)
and NOMINATE (length 4, defined in <xref target="sec:nominate"/>).</t>
<t> This document updates the IANA Registry for HIP NAT
traversal modes specified in Legacy ICE-HIP <xref target="RFC5770"/> by as
signing value for
the NAT traversal mode ICE-HIP-UDP (defined in <xref
target="sec:nat_tm-param"/>).</t>
<t>This document updates the IANA Registry for HIP Notify Message Types:
type field NAT_KEEPALIVE in <xref target="sec:keepalive"/>, a new error ty
pe
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED
and RVS_HMAC_PROHIBITED_WITH_RELAY in <xref target="sec:notify-types"/>.
.</t>
<t> This document defines additional registration types for the HIP
Registration Extension <xref target="RFC8003"/> that
allow registering with a Data Relay Server for ESP relaying service:
RELAY_UDP_ESP (defined in <xref target="sec:reg-types"/>, and performing
server reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in
<xref target="sec:gathering"/>).</t>
<t>This document defines an additional Registration Failure
Type as defined in <xref target="sec:cross_protocol" />. The value is [TBD
by IANA: 9] and the Registration Failure
Type is "Simultaneous Rendezvous and Control Relay Service usage prohibite
d".</t>
<t>ICE specification <xref target="RFC8445" /> discusses "Unilateral Self-
Address Fixing"
in section 18. This
protocol is based on ICE, and thus the same considerations apply
also here. <!-- with one exception: this protocol does not hide binary
IP addresses from application-level gateways. (xx fix: assuming that we sw
itch to encrypted addresses) --></t>
</section> <!-- IANA -->
<!-- ***************************************************************** -->
<section title="Contributors">
<!-- <t> This RFC is a product of a design team that also included Marcelo
Bagnulo and Philip Matthews, who both have made major contributions to
this document. </t> -->
<t>
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have contributed
to <xref target="RFC5770" />. This document leans heavily on the work in t
he RFC.
</t>
</section> <t>This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP <xref target="RFC5770" format="default"/>
for tunneling both HIP control and data plane traffic. The port was
registered separately for <xref target="RFC5770" format="default"/> to
coauthor <contact fullname="Ari Keränen"/> originally, but it has been
reassigned for IESG control. With the permission of <contact
fullname="Ari Keränen"/>, the new assignee is the IESG and the contact
is &lt;chair@ietf.org&gt;. In addition, IANA has added a reference to
this document in the entry for UDP port 10500 in the "Service Name and
Transport Protocol Port Number Registry". The selection between Legacy
ICE-HIP and Native ICE-HIP mode is negotiated using the
NAT_TRAVERSAL_MODE parameter during the base exchange. By default, hosts
listen to this port for incoming UDP datagrams and can also use it for
sending UDP datagrams. Other ephemeral port numbers are negotiated and
utilized dynamically.</t>
<!-- contributors --> <t>IANA has assigned the following values in the HIP "Parameter Types" reg
istry
<xref target="RFC7401" format="default"/>:
4650 for RELAYED_ADDRESS (length 20),
4660 for MAPPED_ADDRESS (length 20; defined in <xref target="sec_relayed_a
ddress"
format="default"/>),
4680 for PEER_PERMISSION (length 48; defined in <xref
target="sec_peer_permission" format="default"/>),
4700 for CANDIDATE_PRIORITY
(length 4; defined in <xref target="sec_con-check" format="default"/>), an
d
4710 for NOMINATE (length 4; defined in <xref target="sec_nominate"
format="default"/>).</t>
<!-- *************************************************************** --> <t>IANA has assigned the following value in the "HIP NAT Traversal Modes"
registry specified in Legacy ICE-HIP <xref target="RFC5770" format="defaul
t"/>:
3 for ICE-HIP-UDP (defined in <xref
target="sec_nat_tm-param" format="default"/>).</t>
<section title="Acknowledgments"> <t>IANA has assigned the following values in the HIP "Notify Message Types
" registry:
16385 for NAT_KEEPALIVE in <xref target="sec_keepalive"
format="default"/>, 63 for
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in <xref target="sec_notify-t
ypes"
format="default"/>, and 64 for
RVS_HMAC_PROHIBITED_WITH_RELAY in <xref target="sec_notify-types"
format="default"/>.</t>
<t>Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the MMU <t> IANA has assigned the following values in the "Registration Types" reg
SIC WG folks for istry for the HIP
the excellent work on ICE. The authors would like to thank also Registration Extension <xref target="RFC8003" format="default"/>:
Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien 3 for RELAY_UDP_ESP (defined in <xref target="sec_reg-types"
Schmitt, and Abhinav Pathak for their contributions and Tobias Heer, Teemu format="default"/>) for allowing registration with a Data Relay Server for
Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Slavov, Janne ESP-relaying service, and
Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha 4 for CANDIDATE_DISCOVERY (defined in <xref target="sec_gathering"
Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Els format="default"/>) for performing server-reflexive candidate discovery.</
ayed, Jani Hautakorpi, Tero Kauppinen and Timo Simanainen for t>
their comments to <xref target="RFC5770" /> and this document.
Thanks for Eric Vyncke, Alvaro Retana, Adam Roach, Ben Campbell, Eric Resc
orla, Mirja Kuhlewind, Spencer Dawkins, Derek Fawcus,
Tianran Zhou, Amanda Barber, Colin Perkins, Roni Even, Alissa Cooper, Carl
Wallace, Martin Duke and Benjamin Kaduk for reviewing this document.
</t>
<t>This work has been partially funded by CyberTrust programme <t>IANA has assigned one value in the "Registration Failure Types" registr
by Digile/Tekes in Finland.</t> y as
defined in <xref target="sec_cross_protocol" format="default"/>. The
value is 9, and the Registration Failure Type is
"Simultaneous Rendezvous and Control Relay Service usage
prohibited".</t>
</section> </section>
<!-- Acknowlegements -->
<!-- *************************************************************** -->
</middle> </middle>
<back> <back>
<displayreference target="I-D.rosenberg-mmusic-ice-nonsip" to="ICE-NONSIP"/>
<displayreference target="I-D.heer-hip-middle-auth" to="HIP-MIDDLEBOXES"/>
<references title="Normative References"> <references>
<name>References</name>
<?rfc include="reference.RFC.2119" ?> <references>
<?rfc include="reference.RFC.8174" ?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.7401" ?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8003" ?> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8004" ?> FC.7401.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8046" ?> FC.8003.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8047" ?> FC.8004.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- <?rfc include="reference.I-D.ietf-mmusic-ice" ?> --> FC.8046.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- XX FIXME: update these references when the individual RFCs are published -- FC.8047.xml"/>
>
<!-- <?rfc include="reference.I-D.ietf-behave-turn" ?> -->
<!-- XX FIXME: move RFC5770 to informative references? -->
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.7402" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.8126" ?>
<?rfc include="reference.RFC.8445" ?> <!-- former reference.I-D.ietf-ice-r
fc5245bis -->
<?rfc include="reference.RFC.7050" ?>
<?rfc include="reference.RFC.8005" ?>
<?rfc include="reference.RFC.1063" ?>
<?rfc include="reference.RFC.8201" ?>
<?rfc include="reference.RFC.5770" ?>
<?rfc include="reference.I-D.ietf-tcpm-rto-consider.xml" ?>
</references>
<references title="Informative References">
<!--<?rfc include="reference.RFC.4423" ?> -->
<?rfc include="reference.I-D.ietf-hip-rfc4423-bis.xml"?>
<?rfc include="reference.RFC.2475" ?>
<?rfc include="reference.RFC.5207" ?>
<!-- <?rfc include="reference.RFC.6336" ?> -->
<?rfc include="reference.I-D.rosenberg-mmusic-ice-nonsip" ?>
<?rfc include="reference.RFC.6538" ?>
<!--
<reference anchor='MMUSIC-ICE'>
<front>
<title>Guidelines for Usage of Interactive Connectivity Establishment (ICE) by n
on Session Initiation Protocol (SIP) Protocols</title>
<author initials='J' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization />
</author>
<date month='July' day='14' year='2008' />
<abstract><t>Interactive Connectivity Establishment (ICE) has been specified as
a NAT traversal mechanism for protocols based on the offer/answer exchange model
. In practice, only the Session Initiation Protocol (SIP) has used ICE. This d
ocument provides guidance on how other protocols can make use of ICE.</t></abstr
act>
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>
<!-- <?rfc include="reference.RFC.4787" ?> -->
<?rfc include="reference.RFC.5128" ?>
<?rfc include="reference.I-D.heer-hip-middle-auth" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<!-- C.8489.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8445.xml"/>
<reference anchor='HIP-MIDDLE'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<front> .7050.xml"/>
<title>End-Host Authentication for HIP Middleboxes</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8005.xml"/>
<author initials='T' surname='Heer' fullname='Tobias Heer'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization /> FC.1191.xml"/>
</author>
<author initials='K' surname='Wehrle' fullname='Klaus Wehrle'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization /> FC.8201.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5770.xml"/>
<author initials='M' surname='Komu' fullname='Miika Komu'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<organization /> C.8961.xml"/>
</author>
<date month='February' day='27' year='2009' /> </references>
<references>
<name>Informative References</name>
<abstract><t>The Host Identity Protocol [RFC7401] is a signaling protocol for se <!-- reference.I-D.ietf-hip-rfc4423-bis.xml -->
cure communication, mobility, and multihoming that introduces a cryptographic na <reference anchor="RFC9068" target="https://www.rfc-editor.org/info/rfc9068">
mespace. This document specifies an extension for HIP that enables middleboxes
to unambiguously verify the identities of hosts that communicate across them. T
his extension allows middleboxes to verify the liveness and freshness of a HIP a
ssociation and, thus, to secure access control in middleboxes.</t></abstract>
</front> <front>
<title>Host Identity Protocol Architecture</title>
<seriesInfo name='Work in' value='Progress' /> <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz" rol
e="editor">
<organization />
</author>
<author initials="M." surname="Komu" fullname="Miika Komu">
<organization />
</author>
</reference> <date month="June" year="2021" />
</front>
<seriesInfo name="RFC" value="9063" />
<seriesInfo name="DOI" value="10.17487/RFC9068"/>
<?rfc include="reference.RFC.3948" ?> </reference>
<?rfc include="reference.RFC.3264" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2475.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5207.xml"/>
<?rfc include="reference.RFC.5245" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5245.xml"/>
<?rfc include="reference.RFC.8750" ?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.r
osenberg-mmusic-ice-nonsip.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6538.xml"/>
<?rfc include="reference.I-D.ietf-tsvwg-datagram-plpmtud.xml"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5128.xml
"/>
<?rfc include="reference.RFC.5766" ?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .heer-hip-middle-auth.xml"/>
<?rfc include="reference.RFC.6146" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3948.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3264.xml"/>
<?rfc include="reference.RFC.6147" ?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8750.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8899.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6146.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6147.xml"/>
</references>
</references> </references>
<!-- ***************************************************************** --> <section anchor="sec_selecting_pacing_value" numbered="true" toc="default">
<name>Selecting a Value for Check Pacing</name>
<section anchor="sec:selecting_pacing_value"
title="Selecting a Value for Check Pacing">
<t> Selecting a suitable value for the connectivity check transaction <t> Selecting a suitable value for the connectivity check transaction
pacing is essential for the performance of connectivity check-based NAT pacing is essential for the performance of connectivity check-based NAT
traversal. The value should not be so small that the checks cause network traversal. The value should not be so small that the checks cause
congestion or overwhelm the NATs. On the other hand, a pacing value that network congestion or overwhelm the NATs. On the other hand, a pacing
is too high makes the checks last for a long time, thus increasing the value that is too high makes the checks last for a long time, thus
connection setup delay. </t> increasing the connection setup delay. </t>
<t> The Ta value may be configured by the user in environments where the <t> The Ta value may be configured by the user in environments where the
network characteristics are known beforehand. However, if the network characteristics are known beforehand. However, if the
characteristics are not known, it is recommended that the value is characteristics are not known, it is recommended that the value is
adjusted dynamically. In this case, it is recommended that the hosts adjusted dynamically. In this case, it is recommended that the hosts
estimate the round-trip time (RTT) between them and SHOULD set the minimum estimate the round-trip time (RTT) between them, and they
Ta <bcp14>SHOULD</bcp14> set the minimum Ta value so that at most a single
value so that at most a single connectivity check message is sent on every connectivity check message is sent on every RTT. </t>
RTT. </t>
<t> One way to estimate the RTT is to use the time that it takes for the <t> One way to estimate the RTT is to use the time that it takes for the
Control Relay Server registration exchange to complete; this would give an Control Relay Server registration exchange to complete; this would give
estimate on the registering host's access link's RTT. Also, the I1/R1 an estimate on the registering host's access link's RTT. Also, the I1/R1
exchange could be used for estimating the RTT, but since the R1 can be exchange could be used for estimating the RTT, but since the R1 can be
cached in the network, or the relaying service can increase the delay cached in the network, or the relaying service can increase the delay
notably, this is not recommended. notably, this is not recommended. In general, estimating RTT can be
In general, estimating RTT can be difficult and error prone, thus difficult and error prone; thus, the guidelines for choosing a Ta value
the guidelines for choosing a Ta value in <xref target="sec:check_pacing_n in <xref target="sec_check_pacing_neg" format="default"/>
eg" /> <bcp14>MUST</bcp14> be followed. </t>
MUST be followed.
</t>
</section> </section>
<!-- <section anchor="sec_ice_diff" numbered="true" toc="default">
<name>Differences with Respect to ICE</name>
<section title="Base Exchange through a Rendezvous Server"> <t>Legacy ICE-HIP reuses the ICE/STUN/TURN protocol stack as it is. The
benefits of such as an approach include the reuse of STUN/TURN
<t> When the Initiator looks up the information of the Responder from infrastructure and possibly the reuse of existing software libraries,
DNS, it is possible that it discovers a rendezvous server (RVS) record but there are also drawbacks with the approach. For example, ICE is
<xref target="RFC8004" />. In this case, if the Initiator uses NAT meant for application-layer protocols, whereas HIP operates at layer 3.5
traversal methods described in this document, it MAY use its own HIP between transport and network layers. This is particularly problematic
Relay Server to forward HIP traffic to the rendezvous server. The because the implementations employ kernel-space IPsec ESP as their data
Initiator will send the I1 packet using its Control Relay Server server, w plane: demultiplexing of incoming ESP, HIP, and TURN messages required
hich will the capturing of all UDP packets destined to port 10500 to the userspace
then forward it to the RVS server of the Responder. In this case, the (due to different, incompatible markers in ESP and STUN), thus causing
value of the protocol field in the RELAY_TO parameter MUST be IP since additional software complexity and an unnecessary latency/throughput
RVS does not support UDP-encapsulated base exchange packets. The bottleneck for the dataplane performance. It is also worth noting that
Responder will send the R1 packet directly to the Initiator's Control Rela the demultiplexing of STUN packets in the kernel would also incur a
y Server performance impact (albeit smaller than with userspace demultiplexing),
server and the following I2 and R2 packets are also sent directly using and secure verification of STUN messages would require communication
the relay. </t> between the kernel-space STUN detector and HIP daemon typically residing
in the userspace (thus again increasing the performance overhead).</t>
<t> In case the Initiator is not able to distinguish which records are <t>Legacy ICE-HIP also involves some other complexities when compared to
RVS address records and which are Responder's address records (e.g., if the approach taken in this document. The relaying of ESP packets via
the DNS server did not support HIP extensions), the Initiator SHOULD TURN relays was not considered that simple because TURN relays require
first try to contact the Responder directly, without using a Control Relay adding and removing extra TURN framing for the relayed packets. Finally,
Server the developers of the two Legacy ICE-HIP implementations concluded that
server. If none of the addresses are reachable, it MAY try them out using
its own Control Relay Server server as described above. </t>
</section> --> <!-- Base Exchange through a Rendezvous Server -->
<section anchor="sec:ice_diff" title="Differences with respect to ICE">
<t>Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it effort needed for integrating an ICE library into a HIP implementation turned
is. The benefits of such as an approach include the reuse of out to be quite a bit higher than initially estimated. Also, the amount of
STUN/TURN infrastructure and possibly the reuse of existing extra code (some 10 kLoC) needed for all the new parsers, state machines,
software libraries, but there are also drawbacks with the etc., was quite high and by reusing the HIP code, one should be able to do
approach. For example, ICE is meant for application-layer with much less. This should result in smaller binary size, less bugs, and
protocols, whereas HIP operates at layer 3.5 between transport easier debugging.
and network layers. This is particularly problematic because the
implementations employ kernelspace IPsec ESP as their data plane:
demultiplexing of incoming ESP, HIP and TURN messages required
capturing of all UDP packets destined to port 10500 to the
userspace (due to different, incompatible markers in ESP and STUN), thus c
ausing additional software complexity and an
unnecessary latency/throughput bottleneck for the dataplane
performance. It is also worth noting that demultiplexing of STUN packets
in the kernel would incur an also a performance impact (albeit
smaller than with userspace demultiplexing), and secure verification of
STUN messages would require communication between the kernelspace STUN det
ector
and HIP daemon typically residing in the userspace (thus, again increasing
the performance overhead).
</t>
<t>Legacy ICE-HIP involves also some other complexities when compared to t </t>
he approach <t> Consequently, the HIP working group decided to follow ICE
taken in this document. methodology but reuse HIP messaging format to achieve the same
Relaying of ESP packets via TURN relays was not considered that simple bec functionality as ICE; the result of that is this document, which
ause specifies the Native ICE-HIP protocol.
TURN relays require adding and removing extra TURN framing for the
relayed packets. Finally, the developers of the two Legacy ICE-HIP
implementations concluded that "effort needed for integrating an ICE
library into a HIP implementation turned out to be quite a bit
higher that initially estimated. Also, the amount of extra code
(some 10 kLoC) needed for all the new parsers, state machines,
etc., is quite high and by re-using the HIP code one should be
able to do with much less. This should result in smaller binary
size, less bugs, and easier debugging.". Consequently, the HIP
working group decided to follow ICE methodology but reuse HIP
messaging format to achieve the same functionality as ICE, and
consequently the result is this document that specifies the Native ICE-HIP
protocol.
</t> </t>
<t>The Native ICE-HIP protocol specified in this document follows the sema ntics <t>The Native ICE-HIP protocol specified in this document follows the sema ntics
of ICE as close as possible, and most of the differences are of ICE as close as possible, and most of the differences are
syntactical due to the use of a different protocol. In this syntactical due to the use of a different protocol. In this
section, we describe the differences to the ICE protocol.</t> section, we describe the differences to the ICE protocol.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>ICE operates at the application layer, whereas this
<t>ICE operates at the application layer, whereas this
protocol operates between transport and network layers, thus protocol operates between transport and network layers, thus
hiding the protocol details from the application.</t> hiding the protocol details from the application.</li>
<li>The STUN protocol is not employed. Instead, Native ICE-HIP
<t>The STUN protocol is not employed. Instead, native ICE-HIP reuses the HIP control plane format in order to simplify
reuses the HIP control plane format in order simplify the demultiplexing of different protocols. For example, the STUN
demultiplexing of different protocols. For example, the STUN
binding response is replaced with a HIP UPDATE message binding response is replaced with a HIP UPDATE message
containing an ECHO_REQUEST_SIGNED parameter and the STUN containing an ECHO_REQUEST_SIGNED parameter and the STUN
binding response with a HIP UPDATE message containing an binding response with a HIP UPDATE message containing an
ECHO_RESPONSE_SIGNED parameter as defined in <xref ECHO_RESPONSE_SIGNED parameter as defined in <xref
target="sec:conn_checks" />. It is worth noting that a target="sec_conn_checks" format="default"/>. It is worth noting that
a
drawback of not employing STUN is that discovery of the address drawback of not employing STUN is that discovery of the address
candidates requires creating (using HIP base exchange) and candidates requires creating (using HIP base exchange) and
maintaining (using HIP UPDATE procedures) state at the Control Relay Clie nt and maintaining (using HIP UPDATE procedures) state at the Control Relay Clie nt and
Control Relay Server. Future extensions to this document may define Control Relay Server. Future extensions to this document may define
a stateless, HIP-specific mechanism for an end-host to discover its addre a stateless, HIP-specific mechanism for an end host to discover its addre
ss candidates. ss candidates.
</t> </li>
<li>The TURN protocol is not utilized. Instead, Native ICE-HIP reuses
<t>The TURN protocol is not utilized. Instead, native ICE-HIP reuses Control Relay Servers for the same purpose.</li>
Control Relay Servers for the same purpose.</t> <li>ICMP errors may be used in ICE to signal failure. In the Native ICE-
HIP
<t>ICMP errors may be used in ICE to signal failure. In Native ICE-HIP protocol, HIP NOTIFY messages are used instead.</li>
protocol, HIP NOTIFY messages are used instead.</t> <li>Instead of the ICE username fragment and password mechanism for
credentials, Native ICE-HIP uses the HIT, derived from a public key,
<t>Instead of the ICE username fragment and password mechanism for the same purpose. The username fragments are "transient host
for credentials, native ICE-HIP uses the HIT, derived from a public key, identifiers, bound to a particular session established as part of the
for the same purpose. The username fragments are "transient candidate exchange" <xref target="RFC8445"
host identifiers, bound to a particular session established as format="default"/>. Generally in HIP, a local public key and the
part of the candidate exchange" <xref derived HIT are considered long-term identifiers and invariant across
target="RFC8445" />. Generally in HIP, a local public different host associations and different transport-layer flows.</li>
key and the derived HIT are considered long-term identifiers, <li>In ICE, the conflict when two communicating endpoints take the
and invariant across different host associations and different same controlling role is solved using random values (a so-called
transport-layer flows.</t> tie-breaker value). In the Native ICE-HIP protocol, the conflict is solv
ed
<t>In ICE, the conflict when two communicating end-points take by the standard HIP base exchange procedure, where the host with the
the same controlling role is solved using "larger" HIT switches to the Responder role, thus also changing to
random values (so called tie-breaker value). In Native ICE-HIP protocol, the controlled role.</li>
the conflict is solved by the <li>The ICE-CONTROLLED and ICE-CONTROLLING attributes are not
standard HIP base exchange procedure, where the host with the
"larger" HIT switches to Responder role, thus changing also to
controlled role.</t>
<t>The ICE-CONTROLLED and ICE-CONTROLLING attributes are not
included in the connectivity checks. included in the connectivity checks.
<!-- The attributes make it
easier to build gateways between different protocols using
ICE. -rosenberg-mmusic-ice-nonsip --></t>
<t>The foundation concept is unnecessary in native ICE-HIP </li>
<li>The foundation concept is unnecessary in Native ICE-HIP
because only a single UDP flow for the IPsec tunnel will be because only a single UDP flow for the IPsec tunnel will be
negotiated.</t> negotiated.</li>
<li>Frozen candidates are omitted for the same reason the
<t>Frozen candidates are omitted for the same reason as foundation concept is excluded.</li>
foundation concept is excluded.</t> <li>Components are omitted for the same reason the
foundation concept is excluded.</li>
<t>Components are omitted for the same reason as
foundation concept is excluded.</t>
<!-- XX FIXME: no lite mode anymore in ICE -->
<t>Native ICE-HIP supports only "full ICE" where the two
communicating hosts participate actively to the connectivity
checks, and the "lite" mode is not supported. This design
decision follows the guidelines of ICE which recommends full
ICE implementations. However, it should be noted that a
publicly reachable Responder may refuse to negotiate the ICE
mode as described in <xref target="sec:no_relay" />. This
would result in a <xref target="RFC7401" /> based HIP base
exchange tunneled over UDP followed ESP traffic over the same
tunnel, without the connectivity check procedures defined in
this document (in some sense, this mode corresponds to the
case where two ICE lite implementations connect since no
connectivity checks are sent).</t>
<t>As the "ICE lite" is not adopted here and both sides are <li>Native ICE-HIP supports only "full ICE" where the two
communicating hosts participate actively to the connectivity checks,
and the "lite" mode is not supported. This design decision follows
the guidelines of ICE, which recommends full ICE implementations.
However, it should be noted that a publicly reachable Responder may
refuse to negotiate the ICE mode as described in <xref
target="sec_no_relay" format="default"/>. This would result in a HIP
base exchange (as per <xref target="RFC7401" format="default"/>)
tunneled over UDP, followed by ESP traffic over the same tunnel, without
the connectivity check procedures defined in this document (in some
sense, this mode corresponds to the case where two ICE lite
implementations connect since no connectivity checks are sent).</li>
<li>As the "ICE lite" is not adopted here and both sides are
capable of ICE-HIP-UDP mode (negotiated during the base capable of ICE-HIP-UDP mode (negotiated during the base
exchange), default candidates are not employed in Native ICE-HIP.</t> exchange), default candidates are not employed in Native ICE-HIP.</li>
<li> If the agent is using Diffserv Codepoint markings <xref
<t> If the agent is using Diffserv Codepoint markings target="RFC2475" format="default"/> in its media packets, it
<xref target="RFC2475" /> in its media packets, it SHOULD apply those sam <bcp14>SHOULD</bcp14> apply those same markings to its connectivity
e checks.</li>
markings to its connectivity checks.</t>
<!-- <t>Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
protocol in order to avoid middlebox tampering.</t> -->
<t>Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
protocol but rather encrypted to avoid middlebox tampering.</t>
<t>Native ICE-HIP protocol does not employ the ICE related address and
related port attributes (that are used for diagnostic or SIP purposes).</
t>
<t>Minimum RTO is 500 ms in ICE but 1000 ms in Native ICE-HIP protocol in
favor of <xref target="I-D.ietf-tcpm-rto-consider"/></t>
</list></t>
</section> <!-- ice diff -->
<section anchor="sec:hip_diff" title="Differences to Base Exchange and UPDAT
E procedures">
<t>This section gives some design guidance for implementers how the extens
ions in
this protocol extend and differ from <xref target="RFC7401" /> and <xref
target="RFC8046" />.</t>
<t><list style="symbols">
<t>Both control and data plane are operated on top of UDP, not directly o <li>Unlike in ICE, the addresses are not XORed in the Native ICE-HIP
n IP.</t> protocol but rather encrypted to avoid middlebox tampering.</li>
<t>A minimal implementation would conform only to <xref <li>ICE defines Related Address and Port attributes used for diagnostic/SIP
target="sec:minimal" /> or <xref target="sec:no_relay" />, purposes, but the Native ICE-HIP protocol does not employ these attributes.
thus merely tunneling HIP control and data traffic over </li>
UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address.</t>
<t>It is worth noting that while a rendezvous server <xref <li>The minimum RTO is 500 ms in ICE but 1000 ms in the Native ICE-HIP
target="RFC8004" /> has not been designed to be protocol in favor of <xref target="RFC8961" format="default"/>.</li>
used in NATted scenarios because it just relays the first I1 </ul>
packet and does not employ UDP encapsulation, the Control Relay Server </section>
forwards all control traffic and, hence, is more suitable in
NATted environments. Further, the Data Relay Server
guarantees forwarding of data plane traffic also in the cases
when the NAT traversal procedures fail.</t>
<t>Registration procedures with a Control/Data Relay Server are similar a <section anchor="sec_hip_diff" numbered="true" toc="default">
s <name>Differences to Base Exchange and UPDATE Procedures</name>
with rendezvous server. However, a Control/Data Relay Server has differen <t>This section gives some design guidance for implementers on how the
t extensions in this protocol extend and differ from <xref
registration parameters than rendezvous because it offers a target="RFC7401" format="default"/> and <xref target="RFC8046"
different service. Also, the Control/Data Relay Server includes also a RE format="default"/>.</t>
G_FROM <ul spacing="normal">
parameter that informs the Control/Data Relay Client about its server ref <li>Both the control and data plane are operated on top of UDP, not dire
lexive ctly on IP.</li>
address. A Data Relay Server includes also a <li>A minimal implementation would conform only to Sections <xref
RELAYED_ADDRESS containing the relayed address for the target="sec_minimal" format="counter"/> or <xref target="sec_no_relay"
Data Relay Client.</t> format="counter"/>, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited cases
where the Responder has a public address.</li>
<li>It is worth noting that while a Rendezvous Server <xref
target="RFC8004" format="default"/> has not been designed to be used
in NATed scenarios because it just relays the first I1 packet and does
not employ UDP encapsulation, the Control Relay Server forwards all
control traffic and, hence, is more suitable in NATed
environments. Further, the Data Relay Server guarantees forwarding of
data plane traffic also in cases where the NAT traversal procedures
fail.</li>
<t>In <xref target="RFC7401" />, the Initiator and Responder <li>Registration procedures with a Control/Data Relay Server are
similar as with a Rendezvous Server. However, a Control/Data Relay
Server has different registration parameters than a Rendezvous Server
because it offers a different service. Also, the Control/Data Relay
Server also includes a REG_FROM parameter that informs the
Control/Data Relay Client about its server-reflexive address. A Data
Relay Server also includes a RELAYED_ADDRESS containing the relayed
address for the Data Relay Client.</li>
<li>In <xref target="RFC7401" format="default"/>, the Initiator and Resp
onder
can start to exchange application payload immediately after can start to exchange application payload immediately after
the base exchange. While exchanging data immediately after a the base exchange. While exchanging data immediately after a
base exchange via a Data Control Relay would be possible also here, we base exchange via a Data Control Relay would also be possible here, we
follow the ICE methodology to establish a direct path between follow the ICE methodology to establish a direct path between
two hosts using connectivity checks. This means that there two hosts using connectivity checks. This means that there
will be some additional delay after the base exchange before will be some additional delay after the base exchange before
application payload can be transmitted. The same applies for application payload can be transmitted. The same applies for
the UPDATE procedure as the connectivity checks introduce some the UPDATE procedure as the connectivity checks introduce some
additional delay.</t> additional delay.</li>
<li>In HIP without any NAT traversal support, the base exchange
<t>In HIP without any NAT traversal support, the base exchange
acts as an implicit connectivity check, and the mobility and acts as an implicit connectivity check, and the mobility and
multihoming extensions support explicit connectivity multihoming extensions support explicit connectivity
checks. After a base exchange or UPDATE based connectivity checks. After a base exchange or UPDATE-based connectivity
checks, a host can use the associated address pair for checks, a host can use the associated address pair for
transmitting application payload. In this Native ICE-HIP extension, we fo llow transmitting application payload. In this Native ICE-HIP extension, we fo llow
the ICE methodology, where one end-point acting in the the ICE methodology where one endpoint acting in the
controlled role chooses the used address pair also on behalf controlled role chooses the used address pair also on behalf
of the other end-point acting in controlled role, which is of the other endpoint acting in the controlled role, which is
different from HIP without NAT traversal support. Another different from HIP without NAT traversal support. Another
difference is that the process of choosing an address pair is difference is that the process of choosing an address pair is
explicitly signaled using the nomination packets. The explicitly signaled using the nomination packets. The
nomination process in this protocol supports only single nomination process in this protocol supports only a single
address pair, and multihoming extensions are left for further address pair, and multihoming extensions are left for further
study.</t> study.</li>
<li>The UPDATE procedure resembles the mobility extensions
<t>The UPDATE procedure resembles the mobility extensions defined in <xref target="RFC8046" format="default"/>. The
defined in <xref target="RFC8046" />. The
first UPDATE message from the mobile host is exactly the same first UPDATE message from the mobile host is exactly the same
as in the mobility extensions. The second UPDATE message from as in the mobility extensions. The second UPDATE message from
the peer host and third from the mobile host are different in the peer host and third from the mobile host are different in
the sense that they merely acknowledge and conclude the the sense that they merely acknowledge and conclude the
reception of the candidates through the Control Relay Server. In other wo rds, reception of the candidates through the Control Relay Server. In other wo rds,
they do not yet test for connectivity (besides reachability they do not yet test for connectivity (besides reachability
through the Control Relay Server) unlike in the mobility extensions. The through the Control Relay Server) unlike in the mobility extensions. The
idea is that connectivity check procedure follows the ICE idea is that the connectivity check procedure follows the ICE
specification, which is somewhat different from the HIP specification, which is somewhat different from the HIP
mobility extensions.</t> mobility extensions.</li>
<li>The connectivity checks as defined in the mobility
<t>The connectivity checks as defined in the mobility extensions <xref target="RFC8046" format="default"/> are
extensions <xref target="RFC8046" /> are
triggered only by the peer of the mobile host. Since triggered only by the peer of the mobile host. Since
successful NAT traversal requires that both end-points test successful NAT traversal requires that both endpoints test
connectivity, both the mobile host and its peer host have to connectivity, both the mobile host and its peer host have to
test for connectivity. In addition, this protocol test for connectivity. In addition, this protocol
validates also the UDP ports; the ports in the connectivity also validates the UDP ports; the ports in the connectivity
check must match with the response, as required by ICE.</t> check must match with the response, as required by ICE.</li>
<li>In HIP mobility extensions <xref target="RFC8046"
<t>In HIP mobility extensions <xref format="default"/>, an outbound locator has some associated state:
target="RFC8046" />, an outbound locator has UNVERIFIED means that the locator has not been tested for
some associated state: UNVERIFIED mean that the locator has reachability, ACTIVE means that the address has been verified for
not been tested for reachability, ACTIVE means that the reachability and is being used actively, and DEPRECATED means that the
address has been verified for reachability and is being used locator lifetime has expired. In the subset of ICE specifications used
actively, and DEPRECATED means that the locator lifetime has by this protocol, an individual address candidate has only two
expired. In the subset of ICE specifications used by this properties: type and priority. Instead, the actual state in ICE is
protocol, an individual address candidate has only two associated with candidate pairs rather than individual addresses. The
properties: type and priority. Instead, the actual state in subset of ICE specifications utilized by this protocol require the
ICE is associated with candidate pairs rather than individual following attributes for a candidate pair: valid bit, nominated bit,
addresses. The subset of ICE specifications utilized by this base, and the state of the connectivity check. The connectivity checks
protocol require the following attributes for a candidate have the following states: Waiting, In-progress, Succeeded, and
pair: valid bit, nominated bit, base and the state of Failed. Handling of this state attribute requires some additional
connectivity check. The connectivity checks have the following logic when compared to the mobility extensions, since the state is
states: Waiting, In-progress, Succeeded and Failed. Handling associated with a local-remote address pair rather than just a remote
of this state attribute requires some additional logic when address; thus, the mobility and ICE states do not have an unambiguous
compared to the mobility extensions since the state is one-to-one mapping.
associated with a local-remote address pair rather just a </li>
remote address, and, thus, the mobility and ICE states <li>Credit-based authorization as defined in <xref target="RFC8046" form
do not have an unambiguous one-to-one mapping. at="default"/> could be used before
</t>
<t>Credit-based authorization as defined in <xref
target="RFC8046" /> could be used before
candidate nomination has been concluded upon discovering candidate nomination has been concluded upon discovering
working candidate pairs. However, this may result in the use working candidate pairs. However, this may result in the use
of asymmetric paths for a short time period in the beginning of asymmetric paths for a short time period in the beginning
of communications. Thus, support of credit-based authorization is left of communications. Thus, support of credit-based authorization is left
for further study.</t> for further study.</li>
</ul>
</list></t> </section>
</section> <!-- hip diff -->
<section anchor="sec:multihoming" title="Multihoming Considerations">
<t>This document allows a host to collect address candidates
from multiple interfaces, but does not support activation and
the simultaneous use of multiple address candidates. While
multihoming extensions to support <xref target="RFC8047" /> like
functionality are left for further study and experimentation, we
envision here some potential compatibility improvements to
support multihoming:</t>
<t><list style="symbols"> <section anchor="sec_multihoming" numbered="true" toc="default">
<name>Multihoming Considerations</name>
<t>This document allows a host to collect address candidates from
multiple interfaces but does not support activation and the simultaneous
use of multiple address candidates. While multihoming extensions to
support functionality similar to that found in <xref target="RFC8047"
format="default"/> are left for further study and experimentation, we
envision here some potential compatibility improvements to support
multihoming:</t>
<t>Data Relay Registration: a Data Relay Client acting as an <dl newline="false" spacing="normal">
<dt>Data Relay Registration:</dt>
<dd>a Data Relay Client acting as an
Initiator with another peer host should register a new Initiator with another peer host should register a new
server reflexive candidate for each local transport address candidate. A server-reflexive candidate for each local transport address candidate. A
Data Relay Client acting as an Responder should register a new Data Relay Client acting as a Responder should register a new
server reflexive candidate for each { local transport address candidate, server-reflexive candidate for each {local transport address candidate,
new peer host} pair for the reasons described in <xref new peer host} pair for the reasons described in <xref
target="sec:conflicting" />. In both cases, the Data Relay Client should target="sec_conflicting" format="default"/>. In both cases, the Data
request the additional server reflexive candidates by sending UPDATE Relay Client should
request the additional server-reflexive candidates by sending UPDATE
messages originating from each of the local address candidates as messages originating from each of the local address candidates as
described in <xref target="sec:registration" />. As the described in <xref target="sec_registration" format="default"/>. As the
UPDATE messages are originating from an unknown location from the viewpo UPDATE messages are originating from an unknown location from the
int of the Data Relay Server, viewpoint of the Data Relay Server,
it must include also a ECHO_REQUEST_SIGNED in the response in order to t it must also include an ECHO_REQUEST_SIGNED in the response in order to
est for return routability. test for return routability. </dd>
</t> <dt>Data Relay unregistration:</dt>
<dd>This follows the procedure in <xref target="sec_protocol"
<t>Data Relay unregistration: this follows the procedure in format="default"/>, but the Data Relay Client should unregister using
<xref target="sec:protocol" /> but the Data Relay Client should unregiste the particular transport address to be unregistered. All transport
r address pair registrations can be unregistered when no RELAYED_ADDRESS
using the particular transport address to be unregistered. parameter is included.</dd>
All transport address pair registrations can be <dt>PEER_PERMISSION parameter:</dt>
unregistered when no RELAYED_ADDRESS parameter is <dd>This needs to be extended or
included.</t>
<t>PEER_PERMISSION parameter: this needs to be extended or
an additional parameter is needed to declare the specific local an additional parameter is needed to declare the specific local
candidate of the Data Relay Client. Alternatively, the use of candidate of the Data Relay Client. Alternatively, the use of
the PEER_PERMISSION could be used as a wild card to open permissions for the PEER_PERMISSION could be used as a wild card to open permissions
a specific peer to all for a specific peer to all
of the candidates of the Data Relay Client.</t> of the candidates of the Data Relay Client.</dd>
<dt>Connectivity checks:</dt>
<t>Connectivity checks: the controlling host should be able to <dd>The controlling host should be able to
nominate multiple candidates (by repeating step 7 in <xref nominate multiple candidates (by repeating step 7 in <xref
target="fig:cc1" /> in <xref target="sec:conn_checks" /> using the additi target="fig_cc1" format="default"/> in <xref target="sec_conn_checks"
onal candidate pairs).</t> format="default"/> using the additional candidate pairs).</dd>
<dt>Keepalives:</dt>
<t>Keepalives should be sent for all the nominated candidate <dd>These should be sent for all the nominated candidate
pairs. Similarly, the Control/Data Relay Client should send keepalives fr pairs. Similarly, the Control/Data Relay Client should send keepalives
om its local candidates from its local candidates to its Control/Data Relay Server transport
to its Control/Data Relay Server transport addresses.</t> addresses.</dd>
</dl>
</list></t> </section>
<section anchor="sec_dns" numbered="true" toc="default">
</section> <name>DNS Considerations</name>
<t>This section updates <xref target="RFC5770" sectionFormat="of"
<section anchor="sec:dns" title="DNS Considerations"> section="B"/>, which will be replaced with the mechanism described in
this section.</t>
<t>This section updates <xref target="RFC5770" /> Appendix B <t><xref target="RFC5770" format="default"/> did not specify how an
which will be replaced with the mechanism described in this section.</t> end host can look up another end host via DNS and initiate a UDP-based
HIP base exchange with it, so this section makes an attempt to fill this
<t><xref target="RFC5770" /> did not specify how an end-host can gap.</t>
look up another end-host via DNS and initiate an UDP-based HIP
base exchange with it, so this section makes an attempt to
fill this gap.
</t>
<t><xref target="RFC8005" /> specifies how a HIP end-host and <t><xref target="RFC8005" format="default"/> specifies how a HIP end
its Rendezvous server is registered to DNS. Essentially, the host and its Rendezvous Server is registered to DNS. Essentially, the
public key of the end-host is stored as HI record and its public key of the end host is stored as a HI record and its Rendezvous
Rendezvous Server as A or AAAA record. This way, the Rendezvous Server as an A or AAAA record. This way, the Rendezvous Server can act
Server can act as an intermediary for the end-host and forward as an intermediary for the end host and forward packets to it based on
packets to it based on the DNS configuration. the DNS configuration. The Control Relay Server offers similar
Control Relay Server offers similar functionality as Rendezvous Server, wi functionality to the Rendezvous Server, with the difference being that the
th Control Relay Server forwards all control messages, not just the first
the difference that the Control Relay Server forwards all control messages I1 message.
, not just the first I1 message.
<!--
The end-host has registered as a Rendezvous Client to the
Rendezvous server, so they share a Host Association with each
other and the end-host updates its locators to the Rendezvous
Server when it moves. This way, a new HIP base exchange destined
to the end-host is always delivered to the correct location
since the Rendezvous Server has always the up-to-date location
of the end-host. As an alternative the Rendezvous Server, the
DNS could be configured with actual IP addresses the end-host in
A and AAAA records. This works with static hosts, and in the
case of a mobile host, it can update its location using Dynamic
DNS <xref target="I-D.ietf-hip-rfc4423-bis" />.
-->
</t> </t>
<t> <t>
Prior to this document, the A and AAAA records in the DNS Prior to this document, the A and AAAA records in the DNS
refer either to the HIP end-host itself or a Rendezvous Server <xref targe t="RFC8005" />, refer either to the HIP end host itself or a Rendezvous Server <xref targe t="RFC8005" format="default"/>,
and control and data plane communication with the associated and control and data plane communication with the associated
host has been assumed to occur directly over IPv4 or host has been assumed to occur directly over IPv4 or
IPv6. However, this specification extends the records to be used for IPv6. However, this specification extends the records to be used for
UDP-based communications.</t> UDP-based communications.</t>
<t>Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this document.
The Initiator looks up the Fully Qualified Domain Name (FQDN) of a
Responder, and retrieves its HI, A, and AAAA records. Since the default
policy is to use UDP encapsulation, the Initiator <bcp14>MUST</bcp14>
send the I1 message over UDP to destination port 10500 (either over IPv4
in the case of an A record or over IPv6 in the case of an AAAA
record). It <bcp14>MAY</bcp14> send an I1 message both with and without
UDP encapsulation in parallel.
<t>Let us consider the case of a HIP Initiator with the default In the case in which the Initiator receives R1 messages both with and with
policy to employ UDP encapsulation and the extensions defined in this docu out UDP
ment. encapsulation from the Responder, the Initiator <bcp14>SHOULD</bcp14>
The Initiator looks up ignore the R1 messages without UDP encapsulation.
the FQDN of a Responder, and retrieves its HI, A and AAAA records.
Since the default policy is to use UDP encapsulation, the Initiator MUST s
end the I1 message over UDP to destination port 10500
(either over IPv4 in the case of a A record or over IPv6 in the case of
a AAAA record). It MAY send an I1 message both with and without UDP encaps
ulation in parallel.
<!-- but, when
sending multiple I1 message, the Initiator SHOULD
wait for a small amount of time (a reasonable time may be
2 * expected RTT) after the first R1 reception to allow possibly
multiple R1s to arrive as described in section 4.1.4 in <xref target="RFC7
401" />. -->
In the case the Initiator receives R1 messages both with and without UDP e
ncapsulation from the Responder, the Initiator SHOULD ignore the R1 messages wit
hout
UDP encapsulation.
<!--
In the other case, the host sends the I1 directly over IPv4 in the case of
a
A-record or directly over IPv6 in the case of an AAAA-record as
specified in <xref target="RFC8005" />.-->
</t>
<t>The UDP encapsulated I1 packet could be received by three different
types of hosts:
</t> </t>
<t><list style="numbers"> <t>The UDP-encapsulated I1 packet could be received by four different
<t>HIP Control Relay Server: in this case the A/AAAA records refers to a types of hosts:
Control Relay Server,
and it will forward the packet to the corresponding Control Relay Client
based on the destination HIT in the I1 packet.</t>
<t>HIP Responder supporting UDP encapsulation: in this case, the A/AAAA r
ecords refers to the end-host. Assuming the destination HIT belongs to the Respo
nder, it receives and processes it according to the negotiated NAT traversal mec
hanism. The support for the protocol defined in this
document vs <xref target="RFC5770" /> is dynamically negotiated during the
base exchange. The details are specified in <xref target="sec:nat_traversa
l_mode"/>.</t>
<t>HIP Rendezvous Server: this entity is not listening to UDP port 10500,
so it will drop the I1 message.</t>
<t>HIP Responder not supporting UDP encapsulation: the targeted end-host
is not listening to UDP port 10500, so it will drop the I1 message.</t>
</list></t>
<t>The A/AAAA-record MUST NOT be configured to refer to a Data Relay Serve
r unless the host in question supports also Control Relay Server functionality.
</t> </t>
<dl newline="false" spacing="normal">
<dt>HIP Control Relay Server:</dt>
<dd>In this case, the A/AAAA records refer to a Control Relay Server,
which will forward the packet to the corresponding Control Relay
Client based on the destination HIT in the I1 packet.</dd>
<dt>HIP Responder supporting UDP encapsulation:</dt>
<!-- <dd>In this case, the A/AAAA records refer to the end host. Assuming
<t>It is also worth mentioning that the Control Relay Server specification the destination HIT belongs to the Responder, the Responder receives
in this document and <xref target="RFC5770" /> and processes the I1 packet according to the negotiated NAT traversal
are compatible with each other. mechanism. The support for the protocol defined in this document, as
</t>--> opposed to the support defined in <xref target="RFC5770"
format="default"/>, is dynamically negotiated during the base
exchange. The details are specified in <xref
target="sec_nat_traversal_mode" format="default"/>.</dd>
<dt>HIP Rendezvous Server:</dt>
<dd>This entity is not listening to UDP port 10500, so it will drop
the I1 message.</dd>
<dt>HIP Responder not supporting UDP encapsulation:</dt>
<dd>The targeted end host is not listening to UDP port 10500, so it
will drop the I1 message.</dd>
</dl>
<t>The A/AAAA record <bcp14>MUST NOT</bcp14> be configured to refer to a
Data Relay Server unless the host in question also supports Control
Relay Server functionality.</t>
<t>It also worth noting that SRV records are not employed in this <t>It is also worth noting that SRV records are not employed in this
specification. While they could be used for more flexible UDP specification. While they could be used for more flexible UDP
port selection, they are not suitable for end-host discovery but port selection, they are not suitable for end-host discovery but
rather would be more suitable for the discovery of HIP-specific infrastruc ture. Further rather would be more suitable for the discovery of HIP-specific infrastruc ture. Further
extensions to this document may define SRV records for Control extensions to this document may define SRV records for Control
and Data Relay Server discovery within a DNS domain. and Data Relay Server discovery within a DNS domain.
</t> </t>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Jonathan Rosenberg"/>, <contact
fullname="Christer Holmberg"/>, and the rest of the MMUSIC WG folks for
the excellent work on ICE. The authors would also like to thank <contact
fullname="Andrei Gurtov"/>, <contact fullname="Simon Schuetz"/>,
<contact fullname="Martin Stiemerling"/>, <contact fullname="Lars
Eggert"/>, <contact fullname="Vivien Schmitt"/>, and <contact
fullname="Abhinav Pathak"/> for their contributions, and <contact
fullname="Tobias Heer"/>, <contact fullname="Teemu Koponen"/>, <contact
fullname="Juhana Mattila"/>, <contact fullname="Jeffrey M. Ahrenholz"/>,
<contact fullname="Kristian Slavov"/>, <contact fullname="Janne
Lindqvist"/>, <contact fullname="Pekka Nikander"/>, <contact
fullname="Lauri Silvennoinen"/>, <contact fullname="Jukka Ylitalo"/>,
<contact fullname="Juha Heinanen"/>, <contact fullname="Joakim
Koskela"/>, <contact fullname="Samu Varjonen"/>, <contact fullname="Dan
Wing"/>, <contact fullname="Tom Henderson"/>, <contact fullname="Alex
Elsayed"/>, <contact fullname="Jani Hautakorpi"/>, <contact
fullname="Tero Kauppinen"/>, and <contact fullname="Timo Simanainen"/>
for their comments to <xref target="RFC5770" format="default"/> and this
document. Thanks to <contact fullname="Éric Vyncke"/>, <contact
fullname="Alvaro Retana"/>, <contact fullname="Adam Roach"/>, <contact
fullname="Ben Campbell"/>, <contact fullname="Eric Rescorla"/>, <contact
fullname="Mirja Kühlewind"/>, <contact fullname="Spencer Dawkins"/>,
<contact fullname="Derek Fawcus"/>, <contact fullname="Tianran Zhou"/>,
<contact fullname="Amanda Barber"/>, <contact fullname="Colin
Perkins"/>, <contact fullname="Roni Even"/>, <contact fullname="Alissa
Cooper"/>, <contact fullname="Carl Wallace"/>, <contact fullname="Martin
Duke"/>, and <contact fullname="Benjamin Kaduk"/> for reviewing this
document.
</t>
<t>This work has been partially funded by the Cyber Trust Program
by Digile/Tekes in Finland.</t>
</section> </section>
<!-- ***************************************************************** --> <section numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Marcelo Bagnulo"/>, <contact fullname="Philip
Matthews"/>, and <contact fullname="Hannes Tschofenig"/> have
contributed to <xref target="RFC5770" format="default"/>. This document
leans heavily on the work in that RFC.</t>
</section>
</back> </back>
</rfc> </rfc>
<!-- LocalWords: xref CDATA -->
 End of changes. 379 change blocks. 
3067 lines changed or deleted 2518 lines changed or added

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