draft-ietf-hip-native-nat-traversal-19.txt   draft-ietf-hip-native-nat-traversal-20.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track M. Komu, Ed. Intended status: Standards Track M. Komu, Ed.
Expires: September 28, 2017 Ericsson Expires: October 27, 2017 Ericsson
March 27, 2017 April 25, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-19 draft-ietf-hip-native-nat-traversal-20
Abstract Abstract
This document specifies a new Network Address Translator (NAT) 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 based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017. This Internet-Draft will expire on October 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9
4.2. Transport Address Candidate Gathering . . . . . . . . . . 10 4.2. Transport Address Candidate Gathering at the Relay Client 12
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 12 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 14
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 13 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 16
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 14 4.5. Base Exchange via Control Relay Server . . . . . . . . . 16
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 17 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 17 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 20
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 20 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 23
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 22 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 25
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 23 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 26
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 23 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 26
4.7.2. Base Exchange without Connectivity Checks . . . . . . 23 4.7.2. Base Exchange without Connectivity Checks . . . . . . 26
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 24 Encapsulation . . . . . . . . . . . . . . . . . . . . 28
4.8. Sending Control Packets after the Base Exchange . . . . . 25 4.8. Sending Control Packets after the Base Exchange . . . . . 28
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 29
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 32
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 32
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 32
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 32
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 33
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 30 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 34
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 35
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 36
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 36
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 36
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 37
5.6. Relay and Registration Parameters . . . . . . . . . . . . 35 5.6. Relay and Registration Parameters . . . . . . . . . . . . 38
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 36 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 39
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 38 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 41
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 38 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 41
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 38 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 41
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 38 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 42
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 39 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 42
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 40 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 43
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 41 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 44
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 42 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 45
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 45
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 43 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 46
6.3. Base Exchange Replay Protection for HIP Relay Server . . 43 6.3. Base Exchange Replay Protection for Control Relay Server 46
6.4. Demultiplexing Different HIP Associations . . . . . . . . 43 6.4. Demultiplexing Different HIP Associations . . . . . . . . 47
6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 44 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 47
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 44 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 47
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 44 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 48 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 51
Appendix B. Differences with respect to ICE . . . . . . . . . . 49 Appendix B. Differences with respect to ICE . . . . . . . . . . 52
Appendix C. Differences to Base Exchange and UPDATE procedures . 50 Appendix C. Differences to Base Exchange and UPDATE procedures . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in 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 the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, especially NATs usually require the traffic to pass [RFC5207]. Also, especially NATs usually require the
host behind a NAT to create a forwarding state in the NAT before 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. other hosts outside of the NAT can contact the host behind the NAT.
To overcome this problem, different methods, commonly referred to as To overcome this problem, different methods, commonly referred to as
NAT traversal techniques, have been developed. NAT traversal techniques, have been developed.
The HIP experiment report [RFC6538] mentions that Teredo based NAT As one solution, the HIP experiment report [RFC6538] mentions that
traversal for HIP and related ESP traffic (with double tunneling Teredo based NAT traversal for HIP and related ESP traffic (with
overhead). Two HIP specific NAT traversal techniques for HIP are double tunneling overhead). Another solution is specified in
specified in [RFC5770]. One of them uses only UDP encapsulation, [RFC5770], which will be referred as "Legacy ICE-HIP" in this
while the other uses also the Interactive Connectivity Establishment document. The experimental Legacy ICE-HIP specification combines
(ICE) [I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session Interactive Connectivity Establishment (ICE) protocol
Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using [I-D.ietf-ice-rfc5245bis] with HIP, so that basically ICE is
Relays around NAT (TURN) [RFC5766] protocols to achieve a reliable responsible of NAT penetration and connectivity testing, while HIP is
NAT traversal solution. responsible of 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.
The benefit of using ICE and STUN/TURN is that one can re-use the NAT Implementing a full ICE/STUN/TURN protocol stack as specified in
traversal infrastructure already available in the Internet, such as Legacy ICE-HIP results in a considerable amount of effort and code
STUN and TURN servers. Also, some middleboxes may be STUN-aware and which could be avoided by re-using and extending HIP messages and
may be able to do something "smart" when they see STUN being used for state machines for the same purpose. Thus, this document specifies
NAT traversal. However, implementing a full ICE/STUN/TURN protocol an alternative NAT traversal mode referred as "Native ICE-HIP" that
stack results in a considerable amount of effort and code which could employs HIP messaging format instead of STUN or TURN for the
be avoided by re-using and extending HIP messages and state machines connectivity checks, keepalives and data relaying. Native ICE-HIP
for the same purpose. Thus, this document specifies an alternative also specifies how mobility management works in the context of NAT
NAT traversal mode that uses HIP messages instead of STUN for the traversal, which is missing from the Legacy ICE-HIP specification.
connectivity check keepalives and data relaying. This document also The native specification is also based on HIPv2, whereas legacy
specifies how mobility management works in the context of NAT specification is based on HIPv1.
traversal, which was missing from [RFC5770].
Similarly as Legacy ICE-HIP, also this specification builds on the
HIP registration extensions [RFC8003] and the base exchange procedure
[RFC7401] and its closing procedures, 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 [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 [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 Appendix C.
This specification builds heavily on the ICE methodology, so it is
recommended that the reader is familiar with the ICE specification
[I-D.ietf-ice-rfc5245bis] (especially the overview). However, native
ICE-HIP does not implement all the features in ICE, and, hence, the
different features of ICE are cross referenced using [RFC2119]
terminology for clarity. Appendix B explains the differences to ICE.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The
following terms recur in the text: following terms recur in the text:
HIP relay server: ICE:
A host that forwards any kind of HIP control packets between the Interactive Connectivity Establishment (ICE) protocol as specified
Initiator and the Responder. in [I-D.ietf-ice-rfc5245bis]
HIP data relay: Legacy ICE-HIP:
A host that forwards HIP data packets, such as Encapsulating Refers to the "Basic Host Identity Protocol (HIP) Extensions for
Security Payload (ESP) [RFC7402], between two hosts. Traversal of Network Address Translators" as specified in
[RFC5770]. The protocol specified in this document offers an
alternative to Legacy ICE-HIP.
Registered host: Native ICE-HIP:
A host that has registered for a relaying service with a HIP data The protocol specified in this document (Native NAT Traversal Mode
relay. for HIP).
Initiator:
The Initiator is the host that initiates the base exchange using
I1 message.
Responder:
The Responder is the host that receives the I1 packet from the
Initiator.
Control Relay Server
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 [RFC8004] for hosts operating in private
address realms. In the Legacy ICE-HIP specification, this host is
denoted as "HIP relay server".
.
Control Relay Client:
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, this is denoted
as "HIP Relay Client".
Data Relay Server:
A registrar host that forwards HIP related data plane packets,
such as Encapsulating Security Payload (ESP) [RFC7402], between
two hosts. This host implements similar functionality as TURN
servers.
Data Relay Client:
A requester host that registers to a Data Relay Server requesting
it to forward data-plane traffic (e.g. ESP traffic).
Locator: Locator:
As defined in [RFC8046]: "A name that controls how the packet is As defined in [RFC8046]: "A name that controls how the packet is
routed through the network and demultiplexed by the end-host. It routed through the network and demultiplexed by the end-host. It
may include a concatenation of traditional network addresses such may include a concatenation of traditional network addresses such
as an IPv6 address and end-to-end identifiers such as an ESP SPI. 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 It may also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address." demultiplexing context, or it may simply be a network address."
LOCATOR_SET (written in capital letters): LOCATOR_SET (written in capital letters):
skipping to change at page 5, line 6 skipping to change at page 6, line 32
ICE offer: ICE offer:
The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. The Initiator's LOCATOR_SET parameter in a HIP I2 control packet.
Corresponds to the ICE offer parameter, but is HIP specific. Corresponds to the ICE offer parameter, but is HIP specific.
ICE answer: ICE answer:
The Responder's LOCATOR_SET parameter in a HIP R2 control packet. The Responder's LOCATOR_SET parameter in a HIP R2 control packet.
Corresponds to the ICE answer parameter, but is HIP specific. Corresponds to the ICE answer parameter, but is HIP specific.
HIP connectivity checks: HIP connectivity checks:
In order to obtain a non-relayed communication path, two In order to obtain a direct end-to-end communication path (without
communicating HIP hosts try to "punch holes" through their NAT employing a Data Relay Server), two communicating HIP hosts try to
boxes using this mechanism. Similar to the ICE connectivity "punch holes" through their NAT boxes using this mechanism. It is
checks, but implemented using HIP return routability checks. similar to the ICE connectivity checks, but implemented using HIP
return routability checks.
Controlling host: Controlling host:
The controlling host nominates the candidate pair to be used with The controlling host is the Initiator. It nominates the candidate
the controlled host. pair to be used with the controlled host.
Controlled host: Controlled host:
The controlled host waits for the controlling to nominate an The controlled host is the Responder. It waits for the
address candidate pair. controlling to nominate an address candidate pair.
Checklist: Checklist:
A list of address candidate pairs that need to be tested for A list of address candidate pairs that need to be tested for
connectivity. connectivity.
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address. Transport layer port and the corresponding IPv4/v6 address.
Candidate: Candidate:
A transport address that is a potential point of contact for A transport address that is a potential point of contact for
receiving data. receiving data.
Host candidate: Host candidate:
A candidate obtained by binding to a specific port from an IP A candidate obtained by binding to a specific port from an IP
address on the host. address on the host.
skipping to change at page 5, line 35 skipping to change at page 7, line 16
Candidate: Candidate:
A transport address that is a potential point of contact for A transport address that is a potential point of contact for
receiving data. receiving data.
Host candidate: Host candidate:
A candidate obtained by binding to a specific port from an IP A candidate obtained by binding to a specific port from an IP
address on the host. address on the host.
Server reflexive candidate: Server reflexive candidate:
A translated transport address of a host as observed by a HIP A translated transport address of a host as observed by a Control
relay server or a STUN/TURN server. or Data Relay Server.
Peer reflexive candidate: Peer reflexive candidate:
A translated transport address of a host as observed by its peer. A translated transport address of a host as observed by its peer.
Relayed candidate: Relayed candidate:
A transport address that exists on a HIP data relay. Packets that A transport address that exists on a Data Relay Server. Packets
arrive at this address are relayed towards the registered host. that arrive at this address are relayed towards the Data Relay
Client.
Permission: Permission:
In the context of HIP data relay, permission refers to a concept In the context of Data Relay Server, permission refers to a
similar to TURN's channels. Before a host can use a relayed concept similar to TURN's channels. Before a host can use a
candidate to forward traffic through a HIP data relay, the host relayed candidate to forward traffic through a Data Relay Server,
must activate the relayed candidate with a specific peer host. the host must activate the relayed candidate with a specific peer
host.
Base: Base:
The base of an candidate is the local source address a host uses The base of an candidate is the local source address a host uses
to send packets for the associated candidate. For example, the to send packets for the associated candidate. For example, the
base of a server reflexive address is the local address the host base of a server reflexive address is the local address the host
used for registering itself to the associated HIP relay. The base used for registering itself to the associated Control or Data
of a host candidate is equal to the host candidate itself. Relay Server. The base of a host candidate is equal to the host
candidate itself.
3. Overview of Operation 3. Overview of Operation
+--------------+
+-------+ | Control |
| HIP | +--------+ | Relay Server | +--------+
+--------+ | Relay | +--------+ | Data | +----+-----+---+ | Data |
| Data | +-------+ | Data | | Relay | / \ | Relay |
| Relay | / \ | Relay | | Server | / \ | Server |
+--------+ / \ +--------+ +--------+ / \ +--------+
/ \ / \
/ \ / \
/ \ / \
/ <- Signaling -> \ / <- Signaling -> \
/ \ / \
+-------+ +-------+ +-------+ +-------+
| NAT | | NAT | | NAT | | NAT |
+-------+ +-------+ +-------+ +-------+
/ \ / \
skipping to change at page 6, line 39 skipping to change at page 8, line 31
+-------+ +-------+ +-------+ +-------+
| Init- | | Resp- | | Init- | | Resp- |
| iator | | onder | | iator | | onder |
+-------+ +-------+ +-------+ +-------+
Figure 1: Example Network Configuration Figure 1: Example Network Configuration
In the example configuration depicted in Figure 1, both Initiator and In the example configuration depicted in Figure 1, both Initiator and
Responder are behind one or more NATs, and both private networks are Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
the Responder must be registered with a HIP relay server reachable on at least the Responder must be registered with a Control Relay Server
the public Internet, and we assume, as a starting point, that the reachable on the public Internet. The Responder may have also
Initiator knows both the Responder's Host Identity Tag (HIT) and the registered to a Data Relay Server that can forward the data plane in
address of one of its relay servers (how the Initiator learns of the case NAT penetration fails. While, strictly speaking, the Initiator
Responder's relay server is outside of the scope of this document, does not need any Relay Servers, it may act in the other role for
but may be through DNS or another name service). The Responder may other hosts and connectivity with the Data Relay Server of the
have also registered to a data relay that can forward the data plane Responder may fail, so it is the Initiator may also have registered
in case NAT penetration fails. It is worth noting that the HIP relay to a Control and/or Data Relay Server. It is worth noting that a
and data relay functionality may be offered by two separate servers Control and Data Relay does not forge the source address of a passing
or the same one. packet, but always translates the source address and source port of a
packet to be forwarded (to its own).
The first steps are for both the Initiator and Responder to register We assume, as a starting point, that the Initiator knows both the
with a relay server (need not be the same one) and gather a set of Responder's Host Identity Tag (HIT) and the address(es) of the
address candidates. The hosts may use HIP relay servers (or even Responder's Control Relay Server(es) (how the Initiator learns of the
STUN or TURN servers) for gathering the candidates. Next, the HIP Responder's Control Relay Server is outside of the scope of this
base exchange is carried out by encapsulating the HIP control packets document, but may be through DNS or another name service). The first
in UDP datagrams and sending them through the Responder's relay steps are for both the Initiator and Responder to register with a
server. As part of the base exchange, each HIP host learns of the Control Relay Server (need not be the same one) and gather a set of
address candidates. The hosts use either Control Relay Servers or
Data Relay Servers (or other infrastructure including STUN or TURN
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 exchange, each HIP host learns of the
peer's candidate addresses through the HIP offer/answer procedure peer's candidate addresses through the HIP offer/answer procedure
embedded in the base exchange, which follows closely the ICE embedded in the base exchange.
[I-D.ietf-ice-rfc5245bis] protocol.
Once the base exchange is completed, two HIP hosts have established a Once the base exchange is completed, two HIP hosts have established a
working communication session (for signaling) via a HIP relay server, working communication session (for signaling) via a Control Relay
but the hosts still have to find a better path, preferably without a Server, but the hosts still have to find a better path, preferably
HIP data relay, for the ESP data flow. For this, connectivity checks without a Data Relay Server, for the ESP data flow. For this,
are carried out until a working pair of addresses is discovered. At connectivity checks are carried out until a working pair of addresses
the end of the procedure, if successful, the hosts will have is discovered. At the end of the procedure, if successful, the hosts
established a UDP-based tunnel that traverses both NATs, with the will have established a UDP-based tunnel that traverses both NATs,
data flowing directly from NAT to NAT or via a HIP data relay server. with the data flowing directly from NAT to NAT or via a Data Relay
At this point, also the HIP signaling can be sent over the same Server. At this point, also the HIP signaling can be sent over the
address/port pair, and is demultiplexed from IPsec as described in same address/port pair, and is demultiplexed from IPsec as described
the UDP encapsulation standard for IPsec [RFC3948]. Finally, the two in the UDP encapsulation standard for IPsec [RFC3948]. Finally, the
hosts send NAT keepalives as needed in order keep their UDP-tunnel two hosts send NAT keepalives as needed in order keep their UDP-
state active in the associated NAT boxes. tunnel state active in the associated NAT boxes.
If either one of the hosts knows that it is not behind a NAT, hosts 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 can negotiate during the base exchange a different mode of NAT
traversal that does not use HIP connectivity checks, but only UDP traversal that does not use HIP connectivity checks, but only UDP
encapsulation of HIP and ESP. Also, it is possible for the Initiator encapsulation of HIP and ESP. Also, it is possible for the Initiator
to simultaneously try a base exchange with and without UDP to simultaneously try a base exchange with and without UDP
encapsulation. If a base exchange without UDP encapsulation encapsulation. If a base exchange without UDP encapsulation
succeeds, no HIP connectivity checks or UDP encapsulation of ESP are succeeds, no HIP connectivity checks or UDP encapsulation of ESP are
needed. needed.
4. Protocol Description 4. Protocol Description
This section describes the normative behavior of the protocol This section describes the normative behavior of the "Native ICE-HIP"
extension. Most of the procedures are similar to what is defined in protocol extension. Most of the procedures are similar to what is
[RFC5770] but with different, or additional, parameter types and defined in [RFC5770] but with different, or additional, parameter
values. In addition, a new type of relaying server, HIP data relay, types and values. In addition, a new type of relaying server, Data
is specified. Also, it should be noted that HIP version 2 [RFC7401] Relay Server, is specified. Also, it should be noted that HIP
(instead of [RFC5201] used in [RFC5770]) is expected to be used with version 2 [RFC7401] (instead of [RFC5201] used in [RFC5770]) is
this NAT traversal mode. expected to be used with this NAT traversal mode.
4.1. Relay Registration 4.1. Relay Registration
In order for two hosts to communicate over NATted environments, they In order for two hosts to communicate over NATted environments, they
need a reliable way to exchange information. HIP relay servers as need a reliable way to exchange information. To achieve this, "HIP
defined in [RFC5770] support relaying of HIP control plane traffic relay server" is defined in [RFC5770]. It supports relaying of HIP
over UDP in NATted environments. A HIP relay server forwards HIP control plane traffic over UDP in NATted environments, and forwards
control packets between the Initiator and the Responder. 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_ESP parameter as explained later in this section.
To guarantee also data plane delivery over varying types of NAT To guarantee also data plane delivery over varying types of NAT
devices, a host MAY also register for UDP encapsulated ESP relaying devices, a host MAY also register for UDP encapsulated ESP relaying
using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This
service may be coupled with the HIP relay server or offered service may be coupled with the Control Relay Server server or
separately on another server. If the server supports relaying of UDP offered separately on another server. If the server supports
encapsulated ESP, the host is allowed to register for a data relaying relaying of UDP encapsulated ESP, the host is allowed to register for
service using the registration extensions in Section 3.3 of a data relaying service using the registration extensions in
[RFC8003]). If the server has sufficient relaying resources (free Section 3.3 of [RFC8003]). If the server has sufficient relaying
port numbers, bandwidth, etc.) available, it opens a UDP port on one resources (free port numbers, bandwidth, etc.) available, it opens a
of its addresses and signals the address and port to the registering UDP port on one of its addresses and signals the address and port to
host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 the registering host using the RELAYED_ADDRESS parameter (as defined
in this document). If the relay would accept the data relaying in Section 5.12 in this document). If the Data Relay Server would
request but does not currently have enough resources to provide data accept the data relaying request but does not currently have enough
relaying service, it MUST reject the request with Failure Type resources to provide data relaying service, it MUST reject the
"Insufficient resources" [RFC8003]. request with Failure Type "Insufficient resources" [RFC8003].
A HIP relay server MUST silently drop packets to a HIP relay client A Control Relay Server MUST silently drop packets to a Control Relay
that has not previously registered with the HIP relay. The Client that has not previously registered with the HIP relay. The
registration process follows the generic registration extensions registration process follows the generic registration extensions
defined in [RFC8003]. The HIP control plane relaying registration defined in [RFC8003]. The HIP control plane relaying registration
follows [RFC5770], but the data plane registration is different. It follows [RFC5770], but the data plane registration is different. It
is worth noting that if the HIP control and data plane relay services is worth noting that if the HIP control and data plane relay services
reside on different hosts, the relay client has to register reside on different hosts, the client has to register separately to
separately to each of them. In the example shown in Figure 2, the each of them. In the example shown in Figure 2, the two services are
two services are coupled on a single host. 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.
HIP HIP Control/Data Control/Data
Relay [Data] Relay Relay Client (Initiator) Relay Server (Responder)
Client Server
| 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])) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
Figure 2: Example Registration with a HIP Relay Figure 2: Example Registration with a HIP Relay
In step 1, the relay client (Initiator) starts the registration In step 1, the Relay Client (Initiator) starts the registration
procedure by sending an I1 packet over UDP to the relay. It is procedure by sending an I1 packet over UDP to the Relay Server. It
RECOMMENDED that the Initiator select a random port number from the is RECOMMENDED that the Relay Client select a random port number from
ephemeral port range 49152-65535 for initiating a base exchange. the ephemeral port range 49152-65535 for initiating a base exchange.
Alternatively, a host MAY also use a single fixed port for initiating Alternatively, a host MAY also use a single fixed port for initiating
all outgoing connections. However, the allocated port MUST be all outgoing connections. However, the allocated port MUST be
maintained until all of the corresponding HIP Associations are maintained until all of the corresponding HIP Associations are
closed. It is RECOMMENDED that the HIP relay server listen to closed. It is RECOMMENDED that the Relay Server listen to incoming
incoming connections at UDP port 10500. If some other port number is connections at UDP port 10500. If some other port number is used, it
used, it needs to be known by potential Initiators. needs to be known by potential Relay Clients.
In step 2, the HIP relay server (Responder) lists the services that In step 2, the Relay Server (Responder) lists the services that it
it supports in the R1 packet. The support for HIP control plane over supports in the R1 packet. The support for HIP control plane over
UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP
(see Section 5.9). If the server supports also relaying of ESP (see Section 5.9). If the server supports also relaying of ESP
traffic over UDP, it includes also Registration type value traffic over UDP, it includes also Registration type value
RELAY_UDP_ESP. RELAY_UDP_ESP.
In step 3, the Initiator selects the services for which it registers In step 3, the Relay Client selects the services for which it
and lists them in the REG_REQ parameter. The Initiator registers for registers and lists them in the REG_REQ parameter. The Relay Client
HIP relay service by listing the RELAY_UDP_HIP value in the request registers for the Control Data Relay service by listing the
parameter. If the Initiator requires also ESP relaying over UDP, it RELAY_UDP_HIP value in the request parameter. If the Relay Client
lists also RELAY_UDP_ESP. requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP.
In step 4, the Responder concludes the registration procedure with an In step 4, the Relay Server concludes the registration procedure with
R2 packet and acknowledges the registered services in the REG_RES an R2 packet and acknowledges the registered services in the REG_RES
parameter. The Responder denotes unsuccessful registrations (if any) parameter. The Relay Server denotes unsuccessful registrations (if
in the REG_FAILED parameter of R2. The Responder also includes a any) in the REG_FAILED parameter of R2. The Relay Server also
REG_FROM parameter that contains the transport address of the client includes a REG_FROM parameter that contains the transport address of
as observed by the relay (Server Reflexive candidate). If the the Relay Client as observed by the Relay Server (Server Reflexive
Initiator registered to ESP relaying service, the Responder includes candidate). If the Relay Client registered to ESP relaying service,
RELAYED_ADDRESS paramater that describes the UDP port allocated to the Relay Server includes RELAYED_ADDRESS parameter that describes
the Initiator for ESP relaying. It is worth noting that this client the UDP port allocated to the Relay Client for ESP relaying. It is
must first activate this UDP port by sending an UPDATE message to the worth noting that the Data Relay Client must first activate this UDP
relay server that includes a PEER_PERMISSION parameter as described port by sending an UPDATE message to the Data Relay Server that
in Section 4.12.1 both after base exchange and handover procedures. includes a PEER_PERMISSION parameter as described in Section 4.12.1
both after base exchange and handover procedures.
After the registration, the relay client sends periodically NAT After the registration, the Relay Client sends periodically NAT
keepalives to the relay server in order to keep the NAT bindings keepalives to the Relay Server in order to keep the NAT bindings
between the initiator and the relay alive. The keepalive extensions between the Relay Client and the relay alive. The keepalive
are described in Section 4.10. extensions are described in Section 4.10.
The registered host MUST maintain an active HIP association with the The Data Relay Client MUST maintain an active HIP association with
data relay as long as it requires the data relaying service. When the Data Relay Server as long as it requires the data relaying
the HIP association is closed (or times out), or the registration service. When the HIP association is closed (or times out), or the
lifetime passes without the registered host refreshing the registration lifetime passes without the Data Relay Client refreshing
registration, the data relay MUST stop relaying packets for that host the registration, the Data Relay Server MUST stop relaying packets
and close the corresponding UDP port (unless other registered hosts for that host and close the corresponding UDP port (unless other Data
are still using it). Relay Clients are still using it).
The data relay MAY use the same relayed address and port for multiple The Data Relay Server MAY use the same relayed address and port for
registered hosts, but since this can cause problems with stateful multiple Data Relay Clients, but since this can cause problems with
firewalls (see Section 6.5) it is NOT RECOMMENDED. stateful firewalls (see Section 6.5) it is NOT RECOMMENDED.
When a registered client sends an UPDATE (e.g., due to host movement When a Control Relay Client sends an UPDATE (e.g., due to host
or to renew service registration), the relay server MUST follow the movement or to renew service registration), the Control Relay Server
general guidelines defined in [RFC8003], with the difference that all MUST follow the general guidelines defined in [RFC8003], with the
UPDATE messages are delivered on top of UDP. In addition to this, difference that all UPDATE messages are delivered on top of UDP. In
the relay server MUST include the REG_FROM parameter in all UPDATE addition to this, the Control Relay Server MUST include the REG_FROM
responses sent to the client. This applies both renewals of service parameter in all UPDATE responses sent to the Control Relay Client.
registration but also to host movement, where especially the latter This applies both renewals of service registration but also to host
requires the client to learn its new server reflexive address movement, where especially the latter requires the Control Relay
candidate. Client to learn its new server reflexive address candidate.
4.2. Transport Address Candidate Gathering 4.2. Transport Address Candidate Gathering at the Relay Client
A host needs to gather a set of address candidates before contacting An Initiator needs to gather a set of address candidates before
a non-relay host. The candidates are needed for connectivity checks contacting a (non-relay) Responder. The candidates are needed for
that allow two hosts to discover a direct, non-relayed path for connectivity checks that allow two hosts to discover a direct, non-
communicating with each other. One server reflexive candidate can be relayed path for communicating with each other. One server reflexive
discovered during the registration with the HIP relay server from the candidate can be discovered during the registration with the Control
REG_FROM parameter. Relay Server from the REG_FROM parameter (and another from Data Relay
Server if one is employed). It should be noted discovering multiple
address candidates in a multihoming configuration are left for
further study.
The candidate gathering can be done at any time, but it needs to be 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 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 mode is to be used for the connectivity checks. It is RECOMMENDED
that all three types of candidates (host, server reflexive, and that all three types of candidates (host, server reflexive, and
relayed) are gathered to maximize the probability of successful NAT relayed) are gathered to maximize the probability of successful NAT
traversal. However, if no data relay is used, and the host has only traversal. However, if no Data Relay Server is used, and the host
a single local IP address to use, the host MAY use the local address has only a single local IP address to use, the host MAY use the local
as the only host candidate and the address from the REG_FROM address as the only host candidate and the address from the REG_FROM
parameter discovered during the relay registration as a server parameter discovered during the Control Relay Server registration as
reflexive candidate. In this case, no further candidate gathering is a server reflexive candidate. In this case, no further candidate
needed. gathering is needed.
If a host has more than one network interface, additional server
reflexive candidates can be discovered by sending registration
requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by
IANA: 4]) from each of the interfaces to a HIP relay server. When a
HIP relay server receives a registration request with
CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter,
containing the same information as if this were a relay registration,
to the response. This request type SHOULD NOT create any state at
the HIP relay server.
ICE guidelines for candidate gathering MUST be followed as described ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are
in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host followed here. A number of host candidates (loopback, anycast and
candidates (loopback, anycast and others) should excluded as others) should be excluded as described in the ICE specification
described in section 4.1.1.1 of the ICE specification
[I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in
order to guarantee successful NAT traversal. It is RECOMMENDED for order to guarantee successful NAT traversal, and implementations
implementations to support this functionality even if it will not be SHOULD support this functionality even if it will not be used in
used in deployments in order to enable it by software configuration deployments in order to enable it by software configuration update if
update if needed at some point. A host SHOULD employ only a relay needed at some point. A host SHOULD employ only a single server for
server for gathering the candidates for a single HIP association; gathering the candidates for a single HIP association; either a one
either a one server providing both HIP and data relay functionality, server providing both Control and Data Relay Server functionality, or
or one HIP relay server and another one for data relaying if the one Control Relay Server and also Data Relay Server if the
functionality is offered by another server. When the relay service functionality is offered by another server. When the relay service
is split between two hosts, the server reflexive candidate from the is split between two hosts, the server reflexive candidate from the
HIP relay SHOULD be used instead of the one provided by the data Control Relay Server SHOULD be used instead of the one provided by
relay. If a relayed candidate is identical to a host candidate, the the Data Relay Server. If a relayed candidate is identical to a host
relayed candidate must be discarded. NAT64 considerations in section candidate, the relayed candidate must be discarded. NAT64
4.1.1.2 of [I-D.ietf-ice-rfc5245bis] apply as well. considerations in [I-D.ietf-ice-rfc5245bis] apply as well.
HIP based connectivity can be utilized by IPv4 applications using HIP based connectivity can be utilized by IPv4 applications using
LSIs and by IPv6 based applications using HITs. The LSIs and HITs of LSIs and by IPv6 based applications using HITs. The LSIs and HITs of
the local virtual interfaces MUST be excluded in the candidate the local virtual interfaces MUST be excluded in the candidate
gathering phase as well to avoid creating unnecessary loopback gathering phase as well to avoid creating unnecessary loopback
connectivity tests. connectivity tests.
Gathering of candidates MAY also be performed as specified in Gathering of candidates MAY also be performed by other means than
Section 4.2 of [RFC5770] if STUN servers are available, or if the described in this section. For example, the candidates could be
host has just a single interface and no STUN or HIP data relay gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
servers are available. available, or if the host has just a single interface and no STUN or
Data Relay Server are available.
Each local address candidate MUST be assigned a priority. The Each local address candidate MUST be assigned a priority. The
recommended formula in [I-D.ietf-ice-rfc5245bis] SHOULD be used: following recommended formula (as described in
[I-D.ietf-ice-rfc5245bis]) SHOULD be used:
priority = (2^24)*(type preference) + (2^8)*(local preference) + priority = (2^24)*(type preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID) (2^0)*(256 - component ID)
In the formula, type preference follows the ICE specification section In the formula, type preference follows the ICE specification section
4.1.2.2 guidelines: the RECOMMENDED values are 126 for host 4.1.2.2 guidelines: the RECOMMENDED values are 126 for host
candidates, 100 for server reflexive candidates, 110 for peer candidates, 100 for server reflexive candidates, 110 for peer
reflexive candidates, and 0 for relayed candidates. The highest reflexive candidates, and 0 for relayed candidates. The highest
value is 126 (the most preferred) and lowest is 0 (last resort). For 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 all candidates of the same type, the preference type value MUST be
skipping to change at page 12, line 7 skipping to change at page 14, line 23
value MUST be higher than for server reflexive types. It should be value MUST be higher than for server reflexive types. It should be
noted that peer reflexive values are learned later during noted that peer reflexive values are learned later during
connectivity checks, so a host cannot employ it during candidate connectivity checks, so a host cannot employ it during candidate
gathering stage yet. gathering stage yet.
Following the ICE specification, the local preference MUST be an Following the ICE specification, the local preference MUST be an
integer from 0 (lowest preference) to 65535 (highest preference) integer from 0 (lowest preference) to 65535 (highest preference)
inclusive. In the case the host has only a single address candidate, inclusive. In the case the host has only a single address candidate,
the value SHOULD be 65535. In the case of multiple candidates, each the value SHOULD be 65535. In the case of multiple candidates, each
local preference value MUST be unique. Dual-stack considerations for local preference value MUST be unique. Dual-stack considerations for
IPv6 in section 4.1.2.2 in ICE apply also here. IPv6 in ICE apply also here.
Unlike ICE, this protocol only creates a single UDP flow between the Unlike ICE, this protocol only creates a single UDP flow between the
two communicating hosts, so only a single component exists. Hence, two communicating hosts, so only a single component exists. Hence,
the component ID value MUST always be set to 1. the component ID value MUST always be set to 1.
As defined in ICE (in section 11.3), the retransmission timeout (RTO) As defined in ICE , the retransmission timeout (RTO) for address
for address gathering from a relay SHOULD be calculated as follows: gathering from a Control/Data Relay Server SHOULD be calculated as
follows:
RTO = MAX (500ms, Ta * (Num-Of-Pairs)) RTO = MAX (500ms, Ta * (Num-Of-Pairs))
where Ta is the value used for Ta is the value used for the where Ta is the value used for Ta is the value used for the
connectivity check pacing and Num-Of-Pairs is number of pairs of connectivity check pacing and Num-Of-Pairs is number of pairs of
candidates with relay servers (e.g. in the case of a single relay candidates with Control and Data Relay Servers (e.g. in the case of a
server, it would be 1). A smaller value than 500 ms for the RTO MUST single server, it would be 1). A smaller value than 500 ms for the
NOT be used. RTO MUST NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical (as defined in document. As the parameter is non-critical (as defined in
Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which
means that the host is not required to support it or may decline to means that the host is not required to support it or may decline to
use it. use it.
With registration with a HIP relay, it is usually sufficient to use With registration with a Control/Data Relay Server, it is usually
the UDP-ENCAPSULATION mode of NAT traversal since the relay is sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since
assumed to be in public address space. Thus, the relay SHOULD the Relay Server is assumed to be in public address space. Thus, the
propose the UDP-ENCAPSULATION mode as the preferred or only mode. Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the
The NAT traversal mode negotiation in a HIP base exchange is preferred or only mode. The NAT traversal mode negotiation in a HIP
illustrated in Figure 3. It is worth noting that the HIP relay could base exchange is illustrated in Figure 3. It is worth noting that
be located between the hosts, but is omitted here for simplicity. the Relay Server could be located between the hosts, but is omitted
here for simplicity.
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), LOC_SET, ..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) |
+--------------------------------------------------------------->| +--------------------------------------------------------------->|
skipping to change at page 13, line 45 skipping to change at page 16, line 7
In step 4, the Responder concludes the base exchange with an R2 In step 4, the Responder concludes the base exchange with an R2
packet. If the Initiator chose ICE NAT traversal mode, the Responder packet. If the Initiator chose ICE NAT traversal mode, the Responder
includes a LOCATOR_SET parameter in the R2 packet. The locators in includes a LOCATOR_SET parameter in the R2 packet. The locators in
R2, encoded like the locators in I2, are the "ICE answer". If the R2, encoded like the locators in I2, are the "ICE answer". If the
NAT traversal mode selected by the Initiator is not supported by the NAT traversal mode selected by the Initiator is not supported by the
Responder, the Responder SHOULD reply with a NOTIFY packet with type Responder, the Responder SHOULD reply with a NOTIFY packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
4.4. Connectivity Check Pacing Negotiation 4.4. Connectivity Check Pacing Negotiation
As explained in [RFC5770], when a NAT traversal mode with As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode
connectivity checks is used, new transactions should not be started with connectivity checks is used, new transactions should not be
too fast to avoid congestion and overwhelming the NATs. For this started too fast to avoid congestion and overwhelming the NATs. For
purpose, during the base exchange, hosts can negotiate a transaction this purpose, during the base exchange, hosts can negotiate a
pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
packets. The parameter contains the minimum time (expressed in R1 and I2 packets. The parameter contains the minimum time
milliseconds) the host would wait between two NAT traversal (expressed in milliseconds) the host would wait between two NAT
transactions, such as starting a new connectivity check or retrying a traversal transactions, such as starting a new connectivity check or
previous check. The value that is used by both of the hosts is the retrying a previous check. The value that is used by both of the
higher of the two offered values. hosts is the higher of the two offered values.
The minimum Ta value SHOULD be configurable, and if no value is The minimum Ta value SHOULD be configurable, and if no value is
configured, a value of 50 ms MUST be used. Guidelines for selecting configured, a value of 50 ms MUST be used. Guidelines for selecting
a Ta value are given in Appendix A. Hosts SHOULD NOT use values a Ta value are given in Appendix A. Hosts SHOULD NOT use values
smaller than 5 ms for the minimum Ta, since such values may not work smaller than 5 ms for the minimum Ta, since such values may not work
well with some NATs, as explained in [I-D.ietf-ice-rfc5245bis]. The well with some NATs (as explained in [I-D.ietf-ice-rfc5245bis]). The
Initiator MUST NOT propose a smaller value than what the Responder Initiator MUST NOT propose a smaller value than what the Responder
offered. If a host does not include the TRANSACTION_PACING parameter offered. If a host does not include the TRANSACTION_PACING parameter
in the base exchange, a Ta value of 50 ms MUST be used as that host's in the base exchange, a Ta value of 50 ms MUST be used as that host's
minimum value. minimum value.
4.5. Base Exchange via HIP Relay Server 4.5. Base Exchange via Control Relay Server
This section describes how the Initiator and Responder perform a base This section describes how the Initiator and Responder perform a base
exchange through a HIP relay server. Connectivity pacing (denoted as exchange through a Control Relay Server. Connectivity pacing
TA_P here) was described in Section 4.4 and is neither repeated here. (denoted as TA_P here) was described in Section 4.4 and is neither
Similarly, the NAT traversal mode negotiation process (denoted as repeated here. Similarly, the NAT traversal mode negotiation process
NAT_TM in the example) was described in Section 4.3 and is neither (denoted as NAT_TM in the example) was described in Section 4.3 and
repeated here. If a relay receives an R1 or I2 packet without the is neither repeated here. If a Control Relay Server receives an R1
NAT traversal mode parameter, it MUST drop it and SHOULD send a or I2 packet without the NAT traversal mode parameter, it MUST drop
NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER it and SHOULD send a NOTIFY error packet with type
to the sender of the R1 or I2. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2.
It is RECOMMENDED that the Initiator send an I1 packet encapsulated It is RECOMMENDED that the Initiator send an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with a Respectively, the Responder MUST respond to such an I1 packet with a
UDP-encapsulated R1 packet, and also the rest of the communication UDP-encapsulated R1 packet, and also the rest of the communication
related to the HIP association MUST also use UDP encapsulation. related to the HIP association MUST also use UDP encapsulation.
Figure 4 illustrates a base exchange via a HIP relay server. We Figure 4 illustrates a base exchange via a Control Relay Server. We
assume that the Responder (i.e. a HIP relay client) has already assume that the Responder (i.e. a Control Relay Client) has already
registered to the HIP relay server. The Initiator may have also registered to the Control Relay Server. The Initiator may have also
registered to another (or the same relay server), but the base registered to another (or the same Control Relay Server), but the
exchange will traverse always through the relay of the Responder. base exchange will traverse always through the Control Relay Server
of the Responder.
Initiator HIP relay 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 page 15, line 30 skipping to change at page 17, line 30
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(LOC_SET, RELAY_TO)) | | | 7. UDP(R2(LOC_SET, RELAY_TO)) |
| 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
Figure 4: Base Exchange via a HIP Relay Server Figure 4: Base Exchange via a HIP Relay Server
In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via
the relay server to the Responder. In the HIP header, the source HIT the Control Relay Server to the Responder. In the HIP header, the
belongs to the Initiator and the destination HIT to the Responder. source HIT belongs to the Initiator and the destination HIT to the
The initiator sends the I1 packet from its IP address to the IP Responder. The initiator sends the I1 packet from its IP address to
address of the HIP relay over UDP. the IP address of the Control Relay Server over UDP.
In step 2, the HIP relay server receives the I1 packet. If the In step 2, the Control Relay Server receives the I1 packet. If the
destination HIT belongs to a registered Responder, the relay destination HIT belongs to a registered Responder, the Control Relay
processes the packet. Otherwise, the relay MUST drop the packet Server processes the packet. Otherwise, the Control Relay Server
silently. The relay appends a RELAY_FROM parameter to the I1 packet, MUST drop the packet silently. The Control Relay Server appends a
which contains the transport source address and port of the I1 as RELAY_FROM parameter to the I1 packet, which contains the transport
observed by the relay. The relay protects the I1 packet with source address and port of the I1 as observed by the Control Relay
Server. The Control Relay Server protects the I1 packet with
RELAY_HMAC as described in [RFC8004], except that the parameter type RELAY_HMAC as described in [RFC8004], except that the parameter type
is different (see Section 5.8). The relay changes the source and is different (see Section 5.8). The Control Relay Server changes the
destination ports and IP addresses of the packet to match the values source and destination ports and IP addresses of the packet to match
the Responder used when registering to the relay, i.e., the reverse the values the Responder used when registering to the Control Relay
of the R2 used in the registration. The relay MUST recalculate the Server, i.e., the reverse of the R2 used in the registration. The
transport checksum and forward the packet to the Responder. Control Relay Server MUST recalculate the transport checksum and
forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [RFC7401]. In addition, the processes it according to the rules in [RFC7401]. In addition, the
Responder validates the RELAY_HMAC according to [RFC8004] and Responder validates the RELAY_HMAC according to [RFC8004] and
silently drops the packet if the validation fails. The Responder silently drops the packet if the validation fails. The Responder
replies with an R1 packet to which it includes RELAY_TO and NAT replies with an R1 packet to which it includes RELAY_TO and NAT
traversal mode parameters. The responder MUST include ICE-HIP-UDP in traversal mode parameters. The responder MUST include ICE-HIP-UDP in
the NAT traversal modes. The RELAY_TO parameter MUST contain the the NAT traversal modes. The RELAY_TO parameter MUST contain the
same information as the RELAY_FROM parameter, i.e., the Initiator's same information as the RELAY_FROM parameter, i.e., the Initiator's
transport address, but the type of the parameter is different. The transport address, but the type of the parameter is different. The
RELAY_TO parameter is not integrity protected by the signature of the RELAY_TO parameter is not integrity protected by the signature of the
R1 to allow pre-created R1 packets at the Responder. R1 to allow pre-created R1 packets at the Responder.
In step 4, the relay receives the R1 packet. The relay drops the In step 4, the Control Relay Server receives the R1 packet. The
packet silently if the source HIT belongs to an unregistered host. Control Relay Server drops the packet silently if the source HIT
The relay MAY verify the signature of the R1 packet and drop it if belongs to a Control Relay Client that has not successfully
the signature is invalid. Otherwise, the relay rewrites the source registered. The Control Relay Server MAY verify the signature of the
address and port, and changes the destination address and port to R1 packet and drop it if the signature is invalid. Otherwise, the
match RELAY_TO information. Finally, the relay recalculates Control Relay Server rewrites the source address and port, and
changes the destination address and port to match RELAY_TO
information. Finally, the Control Relay Server recalculates
transport checksum and forwards the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [RFC7401]. The Initiator MAY use the address in the according to [RFC7401]. The Initiator MAY use the address in the
RELAY_TO parameter as a local peer-reflexive candidate for this HIP RELAY_TO parameter as a local peer-reflexive candidate for this HIP
association if it is different from all known local candidates. The association if it is different from all known local candidates. The
Initiator replies with an I2 packet that uses the destination Initiator replies with an I2 packet that uses the destination
transport address of R1 as the source address and port. The I2 transport address of R1 as the source address and port. The I2
packet contains a LOCATOR_SET parameter that lists all the HIP packet contains a LOCATOR_SET parameter that lists all the HIP
candidates (ICE offer) of the Initiator. The candidates are encoded candidates (ICE offer) of the Initiator. The candidates are encoded
using the format defined in Section 5.7. The I2 packet MUST also using the format defined in Section 5.7. The I2 packet MUST also
contain a NAT traversal mode parameter that includes ICE-HIP-UDP contain a NAT traversal mode parameter that includes ICE-HIP-UDP
mode. mode.
In step 6, the relay receives the I2 packet. The relay appends a 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 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
in step 2, and forwards the packet to the Responder. packet similarly as explained in step 2, and forwards the packet to
the Responder.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC7401]. It replies with an R2 packet and includes a according to [RFC7401]. It replies with an R2 packet and includes a
RELAY_TO parameter as explained in step 3. The R2 packet includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a
LOCATOR_SET parameter that lists all the HIP candidates (ICE answer) LOCATOR_SET parameter that lists all the HIP candidates (ICE answer)
of the Responder. The RELAY_TO parameter is protected by the HMAC. of the Responder. The RELAY_TO parameter is protected by the HMAC.
In step 8, the relay processes the R2 as described in step 4. The In step 8, the Control Relay Server processes the R2 as described in
relay forwards the packet to the Initiator. After the Initiator has 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. successfully, the base exchange is completed.
Hosts MUST include the address of one or more HIP relay servers Hosts MUST include the address of one or more Control Relay Servers
(including the one that is being used for the initial signaling) in (including the one that is being used for the initial signaling) in
the LOCATOR_SET parameter in I2 and R2 if they intend to use such the LOCATOR_SET parameter in I2 and R2 if they intend to use such
servers for relaying HIP signaling immediately after the base servers for relaying HIP signaling immediately after the base
exchange completes. The traffic type of these addresses MUST be "HIP exchange completes. The traffic type of these addresses MUST be "HIP
signaling" and they MUST NOT be used as HIP candidates. If the HIP signaling" and they MUST NOT be used as HIP candidates. If the
relay server locator used for relaying the base exchange is not Control Relay Server locator used for relaying the base exchange is
included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be
after the base exchange. Instead, further HIP signaling SHOULD use used after the base exchange. Instead, further HIP signaling SHOULD
the same path as the data traffic. use the same path as the data traffic. It is RECOMMENDED to use the
same Control Relay Server throughout the lifetime of the host
association that was used for forwarding the base exchange if the
Responder includes it in the locator parameter of the R2 message.
4.6. Connectivity Checks 4.6. Connectivity Checks
When the Initiator and Responder complete the base exchange through When the Initiator and Responder complete the base exchange through
the HIP relay, both of them employ the IP address of the relay as the the Control Relay Server, both of them employ the IP address of the
destination address for the packets. This address MUST NOT be used Control Relay Server as the destination address for the packets.
as a destination for ESP traffic unless the HIP relay supports also This address MUST NOT be used as a destination for ESP traffic (i.e.,
ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was the corresponding Control Relay Client cannot advertise it to its
successfully negotiated and selected, the Initiator and Responder peer) unless the server supports also Data Relay Server
MUST start the connectivity checks in order to attempt to obtain functionality, for which the client has successfully registered to.
direct end-to-end connectivity through NAT devices. It is worth When NAT traversal mode with ICE-HIP-UDP was successfully negotiated
noting that the connectivity checks MUST be completed even though no and selected, the Initiator and Responder MUST start the connectivity
ESP_TRANSFORM would be negotiated and selected. checks in order to attempt to obtain direct end-to-end connectivity
through NAT devices. It is worth noting that the connectivity checks
MUST be completed even though no ESP_TRANSFORM would be negotiated
and selected.
The connectivity checks MUST follow the ICE methodology [MMUSIC-ICE], The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
but UDP encapsulated HIP control messages are used instead of ICE UDP encapsulated HIP control messages are used instead of ICE
messages. Only normal nomination MUST be used for the connectivity messages. Only normal nomination MUST be used for the connectivity
checks, i.e., aggressive nomination MUST NOT be employed. As stated checks, i.e., aggressive nomination MUST NOT be employed. As stated
in the ICE specification, the basic procedure for connectivity checks in the ICE specification, the basic procedure for connectivity checks
has three phases: sorting the candidate pairs according their has three phases: sorting the candidate pairs according their
priority, sending checks in the prioritized order and acknowledging priority, sending checks in the prioritized order and acknowledging
the checks from the peer host. the checks from the peer host.
The Initiator MUST take the role of controlling host and the The Initiator MUST take the role of controlling host and the
Responder acts as the controlled host. The roles MUST persist Responder acts as the controlled host. The roles MUST persist
throughout the HIP associate lifetime (to be reused in the possibly throughout the HIP associate lifetime (to be reused in the possibly
skipping to change at page 20, line 26 skipping to change at page 23, line 15
In step 9, the Initiator completes the candidate nomination process In step 9, the Initiator completes the candidate nomination process
by confirming the message reception to the Responder. In the by confirming the message reception to the Responder. In the
confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters
correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message
sent by the Responder in the previous step. sent by the Responder in the previous step.
In step 10, the Initiator and Responder can start sending application In step 10, the Initiator and Responder can start sending application
payload over the successfully nominated address candidates. payload over the successfully nominated address candidates.
It is worth noting that if either host has registered a relayed It is worth noting that if either host has registered a relayed
address candidate from a data relay, the host MUST activate the address candidate from a Data Relay Server, the host MUST activate
address before connectivity checks by sending an UPDATE message the address before connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1. containing PEER_PERMISSION parameter as described in Section 4.12.1.
Otherwise, the relay drops ESP packets using the relayed address. Otherwise, the Data Relay Server drops ESP packets using the relayed
address.
It should be noted that in the case both Initiator and Responder both
advertising their own relayed address candidates, it is possible that
the two hosts choose the two relayed addresses as a result of the ICE
nomination algorithm. While this is possible (and even could be
desirable for privacy reasons), it can be unlikely due to low
priority assigned for the relayed address candidates. In such a
event, the nominated address pair is always symmetric; the nomination
algorithm prevents asymmetric address pairs (i.e. each side choosing
different pair), such as a Data Relay Client using its own Data Relay
Server to send data directly to its peer while receiving data from
the Data Relay Server of its peer.
4.6.2. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
The HITs of the two communicating hosts MUST be used as credentials The HITs of the two communicating hosts MUST be used as credentials
in this protocol (in contrast to ICE which employs username-password in this protocol (in contrast to ICE which employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a association, and a SEQ number in an UPDATE message identifies a
particular connectivity check. particular connectivity check.
All of the connectivity check packets MUST be protected with HMACs All of the connectivity check packets MUST be protected with HMACs
and signatures (even though the illustrations omitted them for and signatures (even though the illustrations in this specification
simplicity). Each connectivity check sent by a host MUST include a omit them for simplicity). Each connectivity check sent by a host
SEQ parameter and ECHO_REQUEST_SIGN parameter, and correspondingly MUST include a SEQ parameter and ECHO_REQUEST_SIGN parameter, and
the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED correspondingly the peer MUST respond to these using ACK and
according to the rules specified in [RFC7401]. ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401].
The host sending a connectivity check MUST validate that the response The host sending a connectivity check MUST validate that the response
uses the same pair of UDP ports, and drop the packet if this is not uses the same pair of UDP ports, and drop the packet if this is not
the case. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A generate a response, and then continue waiting for the candidates. A
host MUST NOT select a candidate pair until it has verified the pair host MUST NOT select a candidate pair until it has verified the pair
using a connectivity check as defined in section Section 4.6.1. using a connectivity check as defined in section Section 4.6.1.
skipping to change at page 21, line 31 skipping to change at page 24, line 34
employing ICE-HIP-UDP mode. employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some be sent with the same sequence identifier in the SEQ parameter. Some
tested address candidates will never produce a working address pair, tested address candidates will never produce a working address pair,
and thus may cause retransmissions. Upon successful nomination an and thus may cause retransmissions. Upon successful nomination an
address pair, a host MAY immediately stop sending such address pair, a host MAY immediately stop sending such
retransmissions. retransmissions.
ICE procedures for prioritizing candidates, eliminating redundant ICE procedures for prioritizing candidates, eliminating redundant
candidates and forming check lists (including pruning) MUST be candidates and forming check lists (including pruning) must be
followed as specified in [I-D.ietf-ice-rfc5245bis], with the followed (as specified in [I-D.ietf-ice-rfc5245bis]), with the
exception that the foundation, frozen candidates and default exception that the foundation, frozen candidates and default
candidates are not used. From viewpoint of the ICE specification candidates are not used. From viewpoint of the ICE specification
[I-D.ietf-ice-rfc5245bis], the protocol specified in this document [I-D.ietf-ice-rfc5245bis], the protocol specified in this document
operates using Component ID of 1 on all candidates, and the operates using Component ID of 1 on all candidates, and the
foundation of all candidates is unique. This specification defines foundation of all candidates is unique. This specification defines
only "full ICE" mode, and the "lite ICE" is not supported. The only "full ICE" mode, and the "lite ICE" is not supported. The
reasoning behind the missing features is described in Appendix B. reasoning behind the missing features is described in Appendix B.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
skipping to change at page 22, line 25 skipping to change at page 25, line 27
CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority
value that would be assigned to a peer reflexive candidate if one was value that would be assigned to a peer reflexive candidate if one was
learned from the corresponding check. An UPDATE packet that learned from the corresponding check. An UPDATE packet that
acknowledges a connectivity check request MUST be sent from the same acknowledges a connectivity check request MUST be sent from the same
address that received the check and delivered to the same address address that received the check and delivered to the same address
where the check was received from. Each acknowledgment UPDATE packet where the check was received from. Each acknowledgment UPDATE packet
MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and
IP address of the address where the connectivity check request was IP address of the address where the connectivity check request was
received from. received from.
Following ICE guidelines [I-D.ietf-ice-rfc5245bis], it is RECOMMENDED Following the ICE guidelines [I-D.ietf-ice-rfc5245bis], it is
to restrict the total number of connectivity checks to 100 for each RECOMMENDED to restrict the total number of connectivity checks to
host association. This can be achieved by limiting the connectivity 100 for each host association. This can be achieved by limiting the
checks to the 100 candidate pairs with the highest priority. connectivity checks to the 100 candidate pairs with the highest
priority.
4.6.3. Rules for Concluding Connectivity Checks 4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence UPDATE message that contains a SEQ parameter (with new sequence
number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate
in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify
skipping to change at page 23, line 19 skipping to change at page 26, line 23
It is possible that packets are delayed by the network. Both hosts It is possible that packets are delayed by the network. Both hosts
MUST continue to respond to any connectivity checks despite an MUST continue to respond to any connectivity checks despite an
address pair having been nominated. address pair having been nominated.
If all the connectivity checks have failed, the hosts MUST NOT send If all the connectivity checks have failed, the hosts MUST NOT send
ESP traffic to each other but MAY continue communicating using HIP ESP traffic to each other but MAY continue communicating using HIP
packets and the locators used for the base exchange. Also, the hosts packets and the locators used for the base exchange. Also, the hosts
SHOULD notify each other about the failure with a SHOULD notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
4.7. NAT Traversal Alternatives 4.7. NAT Traversal Optimizations
4.7.1. Minimal NAT Traversal Support 4.7.1. Minimal NAT Traversal Support
If the Responder has a fixed and publicly reachable IPv4 address and If the Responder has a fixed and publicly reachable IPv4 address and
does not employ a HIP relay, the explicit NAT traversal mode does not employ a Control Relay Server, the explicit NAT traversal
negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION
does not have to be negotiated. In such a scenario, the Initiator mode does not have to be negotiated. In such a scenario, the
sends an I1 message over UDP and the Responder responds with an R1 Initiator sends an I1 message over UDP and the Responder responds
message over UDP without including any NAT traversal mode parameter. with an R1 message over UDP without including any NAT traversal mode
The rest of the base exchange follows the procedures defined in parameter. The rest of the base exchange follows the procedures
[RFC7401], except that the control and data plane use UDP defined in [RFC7401], except that the control and data plane use UDP
encapsulation. Here, the use of UDP for NAT traversal is agreed encapsulation. Here, the use of UDP for NAT traversal is agreed
implicitly. This way of operation is still subject to NAT timeouts, implicitly. This way of operation is still subject to NAT timeouts,
and the hosts MUST employ NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in section 4.8 in [RFC5770]. The procedure is applicable as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is
also in the context of this specification, so it is repeated here for applicable also in the context of this specification, so it is
completeness. repeated here for completeness.
In certain network environments, the connectivity checks can be 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 set-up 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 MUST 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 Detecting and configuring this particular scenario is prone to
failure unless carefully planned. failure unless carefully planned.
In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT
traversal mode as one of the supported modes in the R1 packet. If traversal mode as one of the supported modes in the R1 packet. If
the Responder has registered to a HIP relay server, it MUST also the Responder has registered to a Control Relay Server, it MUST also
include a LOCATOR_SET parameter in R1 that contains a preferred include a LOCATOR_SET parameter in R1 that contains a preferred
address where the Responder is able to receive UDP-encapsulated ESP address where the Responder is able to receive UDP-encapsulated ESP
and HIP packets. This locator MUST be of type "Transport address", and HIP packets. This locator MUST be of type "Transport address",
its Traffic type MUST be "both", and it MUST have the "Preferred bit" its Traffic type MUST be "both", and it MUST have the "Preferred bit"
set (see Table 1). If there is no such locator in R1, the source set (see Table 1). If there is no such locator in R1, the source
address of R1 is used as the Responder's preferred address. address of R1 is used as the Responder's preferred address.
The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder
listed it in the supported modes and the Initiator does not wish to listed it in the supported modes and the Initiator does not wish to
use the connectivity checks defined in this document for searching use the connectivity checks defined in this document for searching
skipping to change at page 24, line 32 skipping to change at page 27, line 38
connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
R2 and I2 are received and processed successfully, a security R2 and I2 are received and processed successfully, a security
association can be created and UDP-encapsulated ESP can be exchanged association can be created and UDP-encapsulated ESP can be exchanged
between the hosts after the base exchange completes. However, the between the hosts after the base exchange completes. However, the
Responder SHOULD NOT send any ESP to the Initiator's address before Responder SHOULD NOT send any ESP to the Initiator's address before
it has received data from the Initiator, as specified in Sections it has received data from the Initiator, as specified in Sections
4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of
[RFC8046]. [RFC8046].
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected
MUST NOT be sent via a relay, the Responder SHOULD reject such I2 MUST NOT be sent via a Control Relay Server, the Responder SHOULD
packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY reject such I2 packets and reply with a
packet (see Section 5.10). NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see
Section 5.10).
If there is no answer for the I2 packet sent directly to the 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 MAY send another I2 via
the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION
traversal mode for that I2. NAT traversal mode for that I2.
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation Encapsulation
It is possible to run a base exchange in parallel both with and It is possible to run a base exchange in parallel both with and
without UDP encapsulation as defined in section 4.9 in [RFC5770]. without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in
The procedure is applicable also in the context of this [RFC5770]. The procedure is applicable also in the context of this
specification, so it is repeated here for completeness. specification, so it is repeated here for completeness.
The Initiator MAY also try to simultaneously perform a base exchange The Initiator MAY also try to simultaneously perform a base exchange
with the Responder without UDP encapsulation. In such a case, the with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while 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 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 send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly, without The I1 packet without UDP encapsulation may arrive directly, without
any relays, at the Responder. When this happens, the procedures in passing any Control Data Relays, at the Responder. When this
[RFC7401] are followed for the rest of the base exchange. The happens, the procedures in [RFC7401] are followed for the rest of the
Initiator may receive multiple R1 packets, with and without UDP base exchange. The Initiator may receive multiple R1 packets, with
encapsulation, from the Responder. However, after receiving a valid and without UDP encapsulation, from the Responder. However, after
R1 and answering it with an I2, further R1 packets that are not receiving a valid R1 and answering it with an I2, further R1 packets
retransmissions of the original R1 message MUST be ignored. that are not retransmissions of the original R1 message MUST be
ignored.
The I1 packet without UDP encapsulation may also arrive at a HIP- The I1 packet without UDP encapsulation may also arrive at a HIP-
capable middlebox. When the middlebox is a HIP rendezvous server and capable middlebox. When the middlebox is a HIP rendezvous server and
the Responder has successfully registered with the rendezvous the Responder has successfully registered with the rendezvous
service, the middlebox follows rendezvous procedures in [RFC8004]. service, the middlebox follows rendezvous procedures in [RFC8004].
If the Initiator receives a NAT traversal mode parameter in R1 If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter without UDP encapsulation, the Initiator MAY ignore this parameter
and send an I2 without UDP encapsulation and without any selected NAT and send an I2 without UDP encapsulation and without any selected NAT
traversal mode. When the Responder receives the I2 without UDP traversal mode. When the Responder receives the I2 without UDP
encapsulation and without NAT traversal mode, it will assume that no encapsulation and without NAT traversal mode, it will assume that no
NAT traversal mechanism is needed. The packet processing will be NAT traversal mechanism is needed. The packet processing will be
done as described in [RFC7401]. The Initiator MAY store the NAT done as described in [RFC7401]. The Initiator MAY store the NAT
traversal modes for future use, e.g., in case of a mobility or traversal modes for future use, e.g., in case of a mobility or
multihoming event that causes NAT traversal to be used during the multihoming event that causes NAT traversal to be used during the
lifetime of the HIP association. lifetime of the HIP association.
4.8. Sending Control Packets after the Base Exchange 4.8. Sending Control Packets after the Base Exchange
The same considerations of sending control packets after the base The same considerations of sending control packets after the base
exchange described in section 5.10 in [RFC5770] apply also here, so exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply
they are repeated here for completeness. also here, so they are repeated here for completeness.
After the base exchange, the end-hosts MAY send HIP control packets After the base exchange, the two end-hosts MAY send HIP control
directly to each other using the transport address pair established packets directly to each other using the transport address pair
for a data channel without sending the control packets through the established for a data channel without sending the control packets
HIP relay server. When a host does not get acknowledgments, e.g., to through any Control Relay Servers . When a host does not receive
an UPDATE or CLOSE packet after a timeout based on local policies, acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
the host SHOULD resend the packet through the relay, if it was listed based on local policies, a host SHOULD resend the packet through the
in the LOCATOR_SET parameter in the base exchange. associated Data Relay Server of the peer (if the peer listed it in
its LOCATOR_SET parameter in the base exchange.
If control packets are sent through a HIP relay server, the host If Control Relay Client sends a packet through a Control Relay
registered with the relay MUST utilize the RELAY_TO parameter as in Server, the Control Relay Client MUST always utilize the RELAY_TO
the base exchange. The HIP relay server SHOULD forward HIP packets parameter. The Control Relay Server SHOULD forward HIP control
to the registered hosts and forward packets from a registered host to packets originating from a Control Relay Client to the address
the address in the RELAY_TO parameter. The relay MUST add a denoted in the RELAY_TO parameter. In the other direction, the
RELAY_FROM parameter to the control packets it relays to the Control Relay Server SHOULD forward HIP control packets to the
registered hosts. Control Relay Clients, and MUST add a RELAY_FROM parameter to the
control packets it relays to the Control Relay Clients.
If the HIP relay server is not willing or able to relay a HIP packet, If the Control Relay Server is not willing or able to relay a HIP
it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error packet, it MAY notify the sender of the packet with
notification (see Section 5.10). MESSAGE_NOT_RELAYED error notification (see Section 5.10).
4.9. Mobility Handover Procedure 4.9. Mobility Handover Procedure
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [RFC8046] define handover procedures Mobility extensions for HIP [RFC8046] define handover procedures
without NATs. In this section, we define how two hosts interact with without NATs. In this section, we define how two hosts interact with
handover procedures in scenarios involving NATs. The specified handover procedures in scenarios involving NATs. The specified
extensions define only simple mobility using a pair of security extensions define only simple mobility using a pair of security
associations, and multihoming extensions are left to be defined in associations, and multihoming extensions are left to be defined in
later specifications. The procedures in this section offer the same later specifications. The procedures in this section offer the same
functionality as "ICE restart" specified in functionality as "ICE restart" specified in
[I-D.ietf-ice-rfc5245bis]. The example described in this section [I-D.ietf-ice-rfc5245bis]. The example described in this section
shows only a relay server for the peer host for the sake of shows only a Control Relay Server for the peer host for the sake of
simplicity, but also the mobile host may also have a relay server. simplicity, but also the mobile host may also have a Control Relay
Server.
The assumption here is that the two hosts have successfully The assumption here is that the two hosts have successfully
negotiated and chosen the ICE-HIP-UDP mode during the base exchange negotiated and chosen the ICE-HIP-UDP mode during the base exchange
as defined in Section 4.3. The Initiator of the base exchange MUST as defined in Section 4.3. The Initiator of the base exchange MUST
store information that it was the controlling host during the base store information that it was the controlling host during the base
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
Prior to starting the handover procedures with all peer hosts, the Prior to starting the handover procedures with all peer hosts, the
mobile host SHOULD first send UPDATE messages to its HIP and data mobile host SHOULD first send UPDATE messages to its Control and Data
relays if it has registered to such. It SHOULD wait for all of them Relay Servers if it has registered to such. It SHOULD wait for all
to respond for two minutes and then continue with the handover of them to respond for two minutes and then continue with the
procedure without information from the relays that did not respond. handover procedure without information from the Relay Server that did
As defined in section Section 4.1, a response message from a relay not respond. As defined in section Section 4.1, a response message
includes a REG_FROM parameter that describes the server reflexive from a Control Relay Server includes a REG_FROM parameter that
candidate of the mobile host to be used in the candidate exchange describes the server reflexive candidate of the mobile host to be
during the handover. Similarly, an UPDATE to a data relay is used in the candidate exchange during the handover. Similarly, an
necessary to make sure the data relay can forward data to the correct UPDATE to a Data Relay Server is necessary to make sure the Data
IP address after a handoff. Relay Server can forward data to the correct IP address after a
handoff.
The mobility extensions for NAT traversal are illustrated in The mobility extensions for NAT traversal are illustrated in
Figure 6. The mobile host is the host that has changed its locators, Figure 6. The mobile host is the host that has changed its locators,
and the peer host is the host it has a host association with. The and the peer host is the host it has a host association with. The
mobile host may have multiple peers and it repeats the process with mobile host may have multiple peers and it repeats the process with
all of its peers. In the figure, the HIP relay belongs to the peer all of its peers. In the figure, the Control Relay Server belongs to
host, i.e., the peer host is a relay client for the HIP relay. Next, the peer host, i.e., the peer host is a Control Relay Client for the
we describe the procedure in the figure in detail. Control Relay Server. Next, we describe the procedure in the figure
in detail.
Mobile Host HIP relay Peer Host Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
| LOC_SET, SEQ)) | | | LOC_SET, SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | LOC_SET, SEQ, | | | LOC_SET, SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(UPDATE(ESP_INFO, ACK, | | | 3. UDP(UPDATE(ESP_INFO, ACK, |
| | ECHO_REQ_SIGN)) | | | ECHO_REQ_SIGN)) |
| 4. UDP(UPDATE(ESP_INFO, ACK, |<-------------------------------+ | 4. UDP(UPDATE(ESP_INFO, ACK, |<-------------------------------+
skipping to change at page 27, line 30 skipping to change at page 30, line 47
| 5. connectivity checks over UDP | | 5. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 6. ESP data over UDP | | 6. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
Figure 6: HIP UPDATE procedure Figure 6: HIP UPDATE procedure
In step 1, the mobile host has changed location and sends a location In step 1, the mobile host has changed location and sends a location
update to its peer through the HIP relay of the peer. It sends an update to its peer through the Control Relay Server of the peer. It
UPDATE packet with source HIT belonging to itself and destination HIT sends an UPDATE packet with source HIT belonging to itself and
belonging to the peer host. In the packet, the source IP address destination HIT belonging to the peer host. In the packet, the
belongs to the mobile host and the destination to the HIP relay. The source IP address belongs to the mobile host and the destination to
packet contains an ESP_INFO parameter, where, in this case, the OLD the Control Relay Server. The packet contains an ESP_INFO parameter,
SPI and NEW SPI parameters both contain the pre-existing incoming where, in this case, the OLD SPI and NEW SPI parameters both contain
SPI. The packet also contains the locators of the mobile host in a the pre-existing incoming SPI. The packet also contains the locators
LOCATOR_SET parameter. The packet contains also a SEQ number to be of the mobile host in a LOCATOR_SET parameter. The packet contains
acknowledged by the peer. As specified in [RFC8046], the packet may also a SEQ number to be acknowledged by the peer. As specified in
also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN [RFC8046], the packet may also include a HOST_ID (for middlebox
parameter for rekeying. inspection) and DIFFIE_HELLMAN parameter for rekeying.
In step 2, the HIP relay receives the UPDATE packet and forwards it In step 2, the Control Relay Server receives the UPDATE packet and
to the peer host (i.e. relay client). The HIP relay rewrites the forwards it to the peer host (i.e. Control Relay Client). The
destination IP address and appends a RELAY_FROM parameter to the Control Relay Server rewrites the destination IP address and appends
message. a RELAY_FROM parameter to the message.
In step 3, the peer host receives the UPDATE packet, processes it and In step 3, the peer host receives the UPDATE packet, processes it and
responds with another UPDATE message. The message is destined to the responds with another UPDATE message. The message is destined to the
HIT of mobile host and to the IP address of the HIP relay. The HIT of mobile host and to the IP address of the Control Relay Server.
message includes an ESP_INFO parameter where, in this case, the OLD The message includes an ESP_INFO parameter where, in this case, the
SPI and NEW SPI parameters both contain the pre-existing incoming OLD SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters
to be acknowledged by the mobile host. The message acknowledges the to be acknowledged by the mobile host. The message acknowledges the
SEQ parameter of the earlier message with an ACK parameter. After SEQ parameter of the earlier message with an ACK parameter. After
this step, the peer host can initiate the connectivity checks. this step, the peer host can initiate the connectivity checks.
In step 4, the HIP relay receives the message, rewrites the In step 4, the Control Relay Server receives the message, rewrites
destination IP address, appends an RELAY_TO parameter and forwards the destination IP address, appends an RELAY_TO parameter and
the modified message to the mobile host. When mobile host has forwards the modified message to the mobile host. When mobile host
processed the message successfully, it can initiate the connectivity has processed the message successfully, it can initiate the
checks. connectivity checks.
In step 5, the two hosts test for connectivity across NATs according In step 5, the two hosts test for connectivity across NATs according
to procedures described in Section 4.6. The original Initiator of to procedures described in Section 4.6. The original Initiator of
the communications is the controlling and the original Responder is the communications is the controlling and the original Responder is
the controlled host. the controlled host.
In step 6, the connectivity checks are successfully completed and the In step 6, the connectivity checks are successfully completed and the
controlling host has nominated one address pair to be used. The controlling host has nominated one address pair to be used. The
hosts set up security associations to deliver the application hosts set up security associations to deliver the application
payload. payload.
If either host has registered a relayed address candidate from a data If either host has registered a relayed address candidate from a Data
relay, the host MUST reactivate the address before connectivity Relay Server, the host MUST reactivate the address before
checks by sending an UPDATE message containing PEER_PERMISSION connectivity checks by sending an UPDATE message containing
parameter as described in Section 4.12.1. Otherwise, the relay drops PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise,
ESP packets using the relayed address. the Data Relay Server drops ESP packets using the relayed address.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts send
periodic keepalives to other hosts with which they have established a periodic keepalives to other hosts with which they have established a
host associating. Both a registered client and relay server SHOULD host associating. Both a registered client and Control/Data Relay
send HIP NOTIFY packets to each other every 15 seconds (the so called Server SHOULD send HIP NOTIFY packets to each other every 15 seconds
Tr value in ICE) unless they have exchange some other traffic over (the so called Tr value in ICE) unless they have exchange some other
the used UDP ports. Other values MAY be used, but a Tr value smaller traffic over the used UDP ports. Other values MAY be used, but a Tr
than 15 seconds MUST NOT be used. The keepalive message encoding value smaller than 15 seconds MUST NOT be used. The keepalive
format is defined in Section 5.3. If the base exchange or mobility message encoding format is defined in Section 5.3. If the base
handover procedure occurs during an extremely slow path, a host MAY exchange or mobility handover procedure occurs during an extremely
also send HIP NOTIFY packet every 15 seconds to keep the path active slow path, a host MAY also send HIP NOTIFY packet every 15 seconds to
with the recipient. keep the path active with the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP association and the related The two-way procedure for closing a HIP association and the related
security associations is defined in [RFC7401]. One host initiates security associations is defined in [RFC7401]. One host initiates
the procedure by sending a CLOSE message and the recipient confirms the procedure by sending a CLOSE message and the recipient confirms
it with CLOSE_ACK. All packets are protected using HMACs and it with CLOSE_ACK. All packets are protected using HMACs and
signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED
parameter to protect against replay attacks. parameter to protect against replay attacks.
The same procedure for closing HIP associations applies also here, The same procedure for closing HIP associations applies also here,
but the messaging occurs using the UDP encapsulated tunnel that the but the messaging occurs using the UDP encapsulated tunnel that the
two hosts employ. A host sending the CLOSE message SHOULD first send two hosts employ. A host sending the CLOSE message SHOULD first send
the message over a direct link. After a number of retransmissions, the message over a direct link. After a number of retransmissions,
it MUST send over a HIP relay of the recipient if one exists. The it MUST send over a Control Relay Server of the recipient if one
host receiving the CLOSE message directly without a relay SHOULD exists. The host receiving the CLOSE message directly without a
respond directly. If CLOSE message came via a relay, the host SHOULD Control Data Relay SHOULD respond directly. If CLOSE message came
respond using the same relay. via a Control Data Relay, the host SHOULD respond using the same
Control Data Relay.
4.12. Relaying Considerations 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions 4.12.1. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The Data Relay Server uses a similar permission model as a TURN
before the data relay forwards any ESP data packets from a peer to a server: before the Data Relay Server forwards any ESP data packets
registered host (or the other direction), the client MUST set a from a peer to a Data Relay Client (or the other direction), the
permission for the peer's address. The permissions also install a client MUST set a permission for the peer's address. The permissions
forwarding rule for each direction, similar to TURN's channels, based also install a forwarding rule for each direction, similar to TURN's
on the Security Parameter Index (SPI) values in the ESP packets. channels, based on the Security Parameter Index (SPI) values in the
ESP packets.
Permissions are not required for HIP control packets. However, if a Permissions are not required for HIP control packets. However, if a
relayed address (as conveyed in the RELAYED_ADDRESS parameter from relayed address (as conveyed in the RELAYED_ADDRESS parameter from
the data relay) is selected to be used for data, the registered host the Data Relay Server) is selected to be used for data, the Control
MUST send an UPDATE message to the data relay containing a Relay Client MUST send an UPDATE message to the Data Relay Server
PEER_PERMISSION parameter (see Section 5.13) with the address of the containing a PEER_PERMISSION parameter (see Section 5.13) with the
peer, and the outbound and inbound SPI values the registered host is address of the peer, and the outbound and inbound SPI values the
using with this particular peer. To avoid packet dropping of ESP Control Relay Client is using with this particular peer. To avoid
packets, the registered host SHOULD send the PEER_PERMISSION packet dropping of ESP packets, the Control Relay Client SHOULD send
parameter before connectivity checks both in the case of base the PEER_PERMISSION parameter before connectivity checks both in the
exchange and a mobility handover. It is worth noting that the UPDATE case of base exchange and a mobility handover. It is worth noting
message includes a SEQ parameter (as specified in [RFC7401]) that the that the UPDATE message includes a SEQ parameter (as specified in
data relay must acknowledge, so that the registered host can resend [RFC7401]) that the Data Relay Server must acknowledge, so that the
the message with PEER_PERMISSION parameter if it gets lost. Control Relay Client can resend the message with PEER_PERMISSION
parameter if it gets lost.
When a data relay receives an UPDATE with a PEER_PERMISSION When a Data Relay Server receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the relay checks if there is registered. If the host was registered, the Data Relay Server checks
a permission with matching information (address, protocol, port and if there is a permission with matching information (address,
SPI values). If there is no such permission, a new permission MUST protocol, port and SPI values). If there is no such permission, a
be created and its lifetime MUST be set to 5 minutes. If an new permission MUST be created and its lifetime MUST be set to 5
identical permission already existed, it MUST be refreshed by setting minutes. If an identical permission already existed, it MUST be
the lifetime to 5 minutes. A registered host SHOULD refresh refreshed by setting the lifetime to 5 minutes. A Data Relay Client
permissions 1 minute before the expiration when the permission is SHOULD refresh permissions 1 minute before the expiration when the
still needed. permission is still needed.
When a data relay receives an UPDATE from a registered client but When a Data Relay Server receives an UPDATE from a registered client
without a PEER_PERMISSION parameter and with a new locator set, the but without a PEER_PERMISSION parameter and with a new locator set,
relay can assume that the mobile host has changed its location and, the Data Relay Server can assume that the mobile host has changed its
thus, is not reachable in its previous location. In such an event, location and, thus, is not reachable in its previous location. In
the data relay SHOULD deactivate the permission and stop relaying such an event, the Data Relay Server SHOULD deactivate the permission
data plane traffic to the client. and stop relaying data plane traffic to the client.
The relayed address MUST be activated with the PEER_PERMISSION The relayed address MUST be activated with the PEER_PERMISSION
parameter both after a base exchange and after a handover procedure parameter both after a base exchange and after a handover procedure
with another ICE-HIP-UDP capable host. Unless activated, the data with another ICE-HIP-UDP capable host. Unless activated, the Data
relay MUST drop all ESP packets. It is worth noting that a relay Relay Server MUST drop all ESP packets. It is worth noting that a
client does not have to renew its registration upon a change of Data Relay Client does not have to renew its registration upon a
location UPDATE, but only when the lifetime of the registration is change of location UPDATE, but only when the lifetime of the
close to end. registration is close to end.
4.12.2. HIP Data Relay and Relaying of Control Packets 4.12.2. HIP Data Relay and Relaying of Control Packets
When a HIP data relay accepts to relay UDP encapsulated ESP between a When a Data Relay Server accepts to relay UDP encapsulated ESP
registered host and its peer, the relay opens a UDP port (relayed between a Data Relay Client and its peer, the Data Relay Server opens
address) for this purpose as described in Section 4.1. This port can a UDP port (relayed address) for this purpose as described in
be used for delivering also control packets because connectivity Section 4.1. This port can be used for delivering also control
checks also cover the path through the data relay. If the data relay packets because connectivity checks also cover the path through the
receives a UDP encapsulated HIP control packet on that port, it MUST Data Relay Server. If the Data Relay Server receives a UDP
forward the packet to the registered host and add a RELAY_FROM encapsulated HIP control packet on that port, it MUST forward the
parameter to the packet as if the data relay were acting as a HIP packet to the Data Relay Client and add a RELAY_FROM parameter to the
relay server. When the registered host replies to a control packet packet as if the Data Relay Server were acting as a Control Relay
with a RELAY_FROM parameter via its relay, the registered host MUST Server. When the Data Relay Client replies to a control packet with
add a RELAY_TO parameter containing the peer's address and use the a RELAY_FROM parameter via its Data Relay Server, the Data Relay
address of its data relay as the destination address. Further, the Client MUST add a RELAY_TO parameter containing the peer's address
data relay MUST send this packet to the peer's address from the and use the address of its Data Relay Server as the destination
relayed address. address. Further, the Data Relay Server MUST send this packet to the
peer's address from the relayed address.
If the data relay receives a UDP packet that is not a HIP control If the Data Relay Server receives a UDP packet that is not a HIP
packet to the relayed address, it MUST check if it has a permission control packet to the relayed address, it MUST check if it has a
set for the peer the packet is arriving from (i.e., the sender's permission set for the peer the packet is arriving from (i.e., the
address and SPI value matches to an installed permission). If sender's address and SPI value matches to an installed permission).
permissions are set, the data relay MUST forward the packet to the If permissions are set, the Data Relay Server MUST forward the packet
registered host that created the permission. The data relay MUST to the Data Relay Client that created the permission. The Data Relay
also implement the similar checks for the reverse direction (i.e. Server MUST also implement the similar checks for the reverse
ESP packets from the registered host to the peer). Packets without a direction (i.e. ESP packets from the Data Relay Client to the peer).
permission MUST be dropped silently. Packets without a permission MUST be dropped silently.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
The inbound SPI values of the registered clients should be unique so Since a Data Relay Server may have to deal with multiple Relay
that a data relay can properly demultiplex incoming packets from peer Clients and their peers, such a Relay may experience collisions in
hosts to the correct registered clients. Likewise, the inbound SPIs the SPI namespace. Two problematic cases are described in this
of the peer hosts should be unique for the same reason. These two section.
cases are discussed in this section separately.
In first case, the SPI collision problem occurs when two Initiators In the first scenario, an SPI collision may occur when two Initiators
run a base exchange to the same Responder (i.e. registered host), and run a base exchange to the same Responder (i.e. Data Relay Client),
both the Initiators claim the same inbound SPI. This is not a and both the Initiators claim the same inbound SPI at the Data Relay
problem for Responder since the two Initiators can be distinguished Server using PEER_PERMISSION Parameter. In this case, the Data Relay
by their transport addresses. However, it is an issue for the data Server cannot disambiguate the correct destination of an ESP packet
relay because the it cannot demultiplex packets from the Initiator to originating from the Data Relay Client because the SPI could belong
the correct Responder. Thus, upon receiving an I2 with a colliding to either of the peers (and destination IP and UDP port belonging to
SPI, the Responder MUST NOT include the relayed address candidate in the Data Relay Server are not unique either). The problem can be
the R2 message because the data relay would not be able demultiplex mitigated at the Data Relay Clients (i.e. Responder). Upon
the related ESP packet to the correct Initiator. The same applies receiving an I2 with a colliding SPI, the Responder MUST NOT include
also the handover procedure; the registered host MUST NOT include the the relayed address candidate in the R2 message because the Data
relayed address candidate when sending its new locator set in an Relay Server would not be able demultiplex the related ESP packet to
UPDATE to its peer if it would cause a SPI conflict with another the correct Initiator. The same applies also the handover
peer. Since the SPI space is 32 bits and the SPI values should be procedures; the Data Relay Client MUST NOT include the relayed
random, the probability for a conflicting SPI value is fairly small. address candidate when sending its new locator set in an UPDATE to
However, a registered host with many peers MAY proactively decrease its peer if it would cause a SPI conflict with another peer. Since
the odds of a conflict by registering to multiple data relays. The the SPI space is 32 bits and the SPI values should be random, the
described collision scenario can be avoided if the Responder delivers probability for a conflicting SPI value is fairly small. However, a
a new relayed address candidate upon SPI collisions. Each relayed Data Relay Client with many peers MAY proactively decrease the odds
address has a separate UDP port reserved to it, so the relay can of a conflict by registering to multiple Data Relay Servers. Thus,
demultiplex properly conflicting SPIs of the Initiators based on the the described collision scenario can be avoided if the Responder
SPI and port number towards the correct 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.
In the second case, the SPI collision problems occurs if two hosts In the second scenario, the SPI collision problems occurs if two
have registered to the same data relay and a third host initiates hosts have registered to the same Data Relay Server and a third host
base exchange with both of them. In this case, the data relay has initiates base exchange with both of them. Here, the two Responders
allocated separate UDP ports for the two registered hosts acting now (i.e. Data Relay Clients) claim the same inbound SPI number with the
as Responders. When the Responders send identical SPI values in same Initiator (peer). However, in this case, the Data Relay Server
their I2 messages via the relay, the relay can properly deliver the has allocated separate UDP ports for the two Data Relay Clients
message to the correct Responder because the UDP ports are different. acting now as Responders. When the peer sends an ESP packet, the
Data Relay Server is able to forward the packet to the correct Data
Relay Client because the destination UDP port for each of the
clients.
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be in network byte for the HIP and ESP packets. All values MUST be in network byte
order. order.
It is worth noting that most of the parameters are shown for the sake It is worth noting that most of the parameters are shown for the sake
of completeness even though they are specified already in [RFC5770]. of completeness even though they are specified already in Legacy ICE-
New parameters are explicitly described as new. HIP [RFC5770]. New parameters are explicitly described as new.
5.1. HIP Control Packets 5.1. HIP Control Packets
Figure 7 illustrates the packet format for UDP-encapsulated HIP. The Figure 7 illustrates the packet format for UDP-encapsulated HIP. The
format is identical to [RFC5770]. format is identical to Legacy ICE-HIP [RFC5770].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 39 skipping to change at page 36, line 14
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC7401] with HIP header and parameters follow the conventions of [RFC7401] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
already contains a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC7401] includes the IP addresses in the checksum calculation. The [RFC7401] includes the IP addresses in the checksum calculation. The
NATs that are unaware of HIP cannot recompute the HIP checksum after NATs that are unaware of HIP cannot recompute the HIP checksum after
changing IP addresses. changing IP addresses.
A HIP relay server or a Responder without a relay SHOULD listen at A Control/Data Relay Server or a non-relay Responder SHOULD listen at
UDP port 10500 for incoming UDP-encapsulated HIP control packets. If UDP port 10500 for incoming UDP-encapsulated HIP control packets. If
some other port number is used, it needs to be known by potential some other port number is used, it needs to be known by potential
Initiators. Initiators.
5.2. Connectivity Checks 5.2. Connectivity Checks
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
5.3. Keepalives 5.3. Keepalives
The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
as specified in [RFC7401] with Notify message type field set to as specified in [RFC7401] with Notify message type field set to
NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification
data field. It is worth noting that sending of such a HIP NOTIFY data field. It is worth noting that sending of such a HIP NOTIFY
message MAY be omitted if the host is actively (or passively) sending message MAY be omitted if the host is actively (or passively) sending
other traffic to the peer host over the UDP tunnel associate with the other traffic to the peer host over the UDP tunnel associate with the
host association (and IPsec security associations since the same port host association (and IPsec security associations since the same port
pair is reused) during the Tr period. For instance, the host MAY pair is reused) during the Tr period. For instance, the host MAY
actively send ICMPv6 requests (or respond with an ICMPv6 response) actively send ICMPv6 requests (or respond with an ICMPv6 response)
inside the ESP tunnel to test the health of the associated IPsec inside the ESP tunnel to test the health of the associated IPsec
security associations. Alternatively, the host MAY use UPDATE security associations. Alternatively, the host MAY use UPDATE
packets as a substitute. A minimal UPDATE packet would consist of a packets as a substitute. A minimal UPDATE packet would consist of a
SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
rekeying procedures as specified in section 6.8 in [RFC7402]. It is rekeying procedures as specified in section 6.8 in [RFC7402]. It is
worth noting that a host actively sending periodic UPDATE packets to worth noting that a host actively sending periodic UPDATE packets to
a busy server may increase the computational load of the server since a busy server may increase the computational load of the server since
it has to verify HMACs and signatures in UPDATE messages. it has to verify HMACs and signatures in UPDATE messages.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from The format of NAT traversal mode parameter is borrowed from Legacy
[RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is
to the format of the ESP_TRANSFORM parameter in [RFC7402] and is similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and
shown in Figure 8. This specification defines the traversal mode is shown in Figure 8. The Native ICE-HIP extension specified in this
identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from document defines the new NAT traversal mode identifier for ICE-HIP-
UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP
[RFC5770]. The identifier named RESERVED is reserved for future use. [RFC5770]. The identifier named RESERVED is reserved for future use.
Future specifications may define more traversal modes. Future specifications may define more traversal modes.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 6 skipping to change at page 39, line 6
17 for UDP, 0 for plain IP 17 for UDP, 0 for plain IP
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO
Parameters Parameters
REG_FROM contains the transport address and protocol from which the REG_FROM contains the transport address and protocol from which the
HIP relay server sees the registration coming. RELAY_FROM contains Control Relay Server sees the registration coming. RELAY_FROM
the address from which the relayed packet was received by the relay contains the address from which the relayed packet was received by
server and the protocol that was used. RELAY_TO contains the same the Control Relay Server and the protocol that was used. RELAY_TO
information about the address to which a packet should be forwarded. contains the same information about the address to which a packet
should be forwarded.
5.7. LOCATOR_SET Parameter 5.7. LOCATOR_SET Parameter
This specification reuses the format for UDP-based locators specified This specification reuses the format for UDP-based locators as
in [RFC5770] to be used for communicating the address candidates specified in Legacy ICE-HIP [RFC5770] to be used for communicating
between two hosts. The generic and NAT-traversal-specific locator the address candidates between two hosts. The generic and NAT-
parameters are illustrated in Figure 11. traversal-specific locator parameters are illustrated in Figure 11.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P| | Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 7 skipping to change at page 41, line 7
| | | the host expects to see in incoming ESP | | | | the host expects to see in incoming ESP |
| | | packets that use this locator | | | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 1: Fields of the LOCATOR_SET Parameter Table 1: Fields of the LOCATOR_SET Parameter
5.8. RELAY_HMAC Parameter 5.8. RELAY_HMAC Parameter
As specified in [RFC5770], the RELAY_HMAC parameter value has the TLV As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
type 65520. It has the same semantics as RVS_HMAC [RFC8004]. value has the TLV type 65520. It has the same semantics as RVS_HMAC
[RFC8004].
5.9. Registration Types 5.9. Registration Types
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
Registration Type [RFC8003] values for HIP relay server registration. Registration Type [RFC8003] values for Control Relay Server
The value for RELAY_UDP_HIP is 2 as specified in [RFC5770]. registration. The value for RELAY_UDP_HIP is 2 as specified in
Legacy ICE-HIP [RFC5770].
5.10. Notify Packet Types 5.10. Notify Packet Types
A HIP relay server and end-hosts can use NOTIFY packets to signal A Control Relay Server and end-hosts can use NOTIFY packets to signal
different error conditions. The NOTIFY packet types are the same as different error conditions. The NOTIFY packet types are the same as
in [RFC5770]. in Legacy ICE-HIP [RFC5770].
The Notify Packet Types [RFC7401] are shown below. The Notification The Notify Packet Types [RFC7401] are shown below. The Notification
Data field for the error notifications SHOULD contain the HIP header Data field for the error notifications SHOULD contain the HIP header
of the rejected packet and SHOULD be empty for the of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
If a HIP relay server does not forward a base exchange packet due If a Control Relay Server does not forward a base exchange packet
to missing NAT traversal mode parameter, or the Initiator selects due to missing NAT traversal mode parameter, or the Initiator
a NAT traversal mode that the Responder did not expect, the relay selects a NAT traversal mode that the (non-relay) Responder did
or the Responder may send back a NOTIFY error packet with this not expect, the Control Relay Server or the Responder may send
type. back a NOTIFY error packet with this type.
CONNECTIVITY_CHECKS_FAILED 61 CONNECTIVITY_CHECKS_FAILED 61
Used by the end-hosts to signal that NAT traversal connectivity Used by the end-hosts to signal that NAT traversal connectivity
checks failed and did not produce a working path. checks failed and did not produce a working path.
MESSAGE_NOT_RELAYED 62 MESSAGE_NOT_RELAYED 62
Used by a HIP relay server to signal that is was not able or Used by a Control Relay Server to signal that is was not able or
willing to relay a HIP packet. willing to relay a HIP packet.
5.11. ESP Data Packets 5.11. ESP Data Packets
The format for ESP data packets is identical to [RFC5770]. The format for ESP data packets is identical to Legacy ICE-HIP
[RFC5770].
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport [RFC3948] describes the UDP encapsulation of the IPsec ESP transport
and tunnel mode. On the wire, the HIP ESP packets do not differ from and tunnel mode. On the wire, the HIP ESP packets do not differ from
the transport mode ESP, and thus the encapsulation of the HIP ESP the transport mode ESP, and thus the encapsulation of the HIP ESP
packets is same as the UDP encapsulation transport mode ESP. packets is same as the UDP encapsulation transport mode ESP.
However, the (semantic) difference to Bound End-to-End Tunnel (BEET) 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 IP header is not used in BEET
integrity protection calculation. integrity protection calculation.
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
skipping to change at page 40, line 36 skipping to change at page 43, line 36
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS
Parameters Parameters
5.13. PEER_PERMISSION Parameter 5.13. PEER_PERMISSION Parameter
The format of the new PEER_PERMISSION parameter is shown in The format of the new PEER_PERMISSION parameter is shown in
Figure 13. The parameter is used for setting up and refreshing Figure 13. The parameter is used for setting up and refreshing
forwarding rules and the permissions for data packets at the data forwarding rules and the permissions for data packets at the Data
relay. The parameter contains one or more sets of Port, Protocol, Relay Server. The parameter contains one or more sets of Port,
Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI)
defines a rule for one peer address. values. One set defines a rule for one peer address.
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 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI | | OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ... | | ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4680] Type [TBD by IANA; 4680]
Length length in octets, excluding Type and Length Length length in octets, excluding Type and Length
Port the transport layer (UDP) port number of the peer Port the transport layer (UDP) port number of the peer
Protocol IANA assigned, Internet Protocol number (17 for UDP) Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address, or an IPv4 address in "IPv4-Mapped Address an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer IPv6 address" format, of the peer
OSPI the outbound SPI value the registered host is using for OSPI the outbound SPI value the Data Relay Client is using for
the peer with the Address and Port the peer with the Address and Port
ISPI the inbound SPI value the registered host is using for ISPI the inbound SPI value the Data Relay Client is using for
the peer with the Address and Port the peer with the Address and Port
Figure 13: Format of the PEER_PERMISSION Parameter Figure 13: Format of the PEER_PERMISSION Parameter
5.14. HIP Connectivity Check Packets 5.14. HIP Connectivity Check Packets
The connectivity request messages are HIP UPDATE packets containing a The connectivity request messages are HIP UPDATE packets containing a
new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE
packets contain a MAPPED_ADDRESS parameter (Figure 12). packets contain a MAPPED_ADDRESS parameter (Figure 12).
0 1 2 3 0 1 2 3
skipping to change at page 42, line 40 skipping to change at page 45, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4710] Type [TBD by IANA; 4710]
Length 4 Length 4
Reserved Reserved for future extension purposes Reserved Reserved for future extension purposes
Figure 15: Format of the NOMINATE Parameter Figure 15: Format of the NOMINATE Parameter
6. Security Considerations 6. Security Considerations
The security considerations are the same as in [RFC5770], but are The security considerations are the same as in Legacy ICE-HIP
repeated here for the sake of completeness. [RFC5770], but are repeated here for the sake of completeness.
6.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in plain text format in favor of inspection at HIP- The locators are in plain text format in favor of inspection at HIP-
aware middleboxes in the future. The current document does not aware middleboxes in the future. The current document does not
specify encrypted versions of LOCATOR_SETs, even though it could be specify encrypted versions of LOCATOR_SETs, even though it could be
beneficial for privacy reasons to avoid disclosing them to beneficial for privacy reasons to avoid disclosing them to
middleboxes. middleboxes.
It is also possible that end-users may not want to reveal all It is also possible that end-users may not want to reveal all
skipping to change at page 43, line 17 skipping to change at page 46, line 17
be allowed in all corporate environments. For these two reasons, an be allowed in all corporate environments. For these two reasons, an
end-host may exclude certain host addresses from its LOCATOR_SET end-host may exclude certain host addresses from its LOCATOR_SET
parameter. However, such behavior creates non-optimal paths when the parameter. However, such behavior creates non-optimal paths when the
hosts are located behind the same NAT. Especially, this could be hosts are located behind the same NAT. Especially, this could be
problematic with a legacy NAT that does not support routing from the problematic with a legacy NAT that does not support routing from the
private address realm back to itself through the outer address of the private address realm back to itself through the outer address of the
NAT. This scenario is referred to as the hairpin problem [RFC5128]. NAT. This scenario is referred to as the hairpin problem [RFC5128].
With such a legacy NAT, the only option left would be to use a With such a legacy NAT, the only option left would be to use a
relayed transport address from a TURN server. relayed transport address from a TURN server.
The use of HIP and data relays can be also useful for privacy The use of Control and Data Relay Servers can be also useful for
purposes. For example, a privacy concerned Responder may reveal only privacy purposes. For example, a privacy concerned Responder may
its HIP relay server and Relayed candidates to Initiators. This same reveal only its Control Relay Server and Relayed candidates to
mechanism also protects the Responder against Denial-of-Service (DoS) Initiators. This same mechanism also protects the Responder against
attacks by allowing the Responder to initiate new connections even if Denial-of-Service (DoS) attacks by allowing the Responder to initiate
its relays would be unavailable due to a DoS attack. new connections even if its relays would be unavailable due to a DoS
attack.
6.2. Opportunistic Mode 6.2. Opportunistic Mode
A HIP relay server should have one address per relay client when a A Control Relay Server should have one address per Control Relay
HIP relay is serving more than one relay client and supports Client when the Control Relay Server is serving more than one Control
opportunistic mode. Otherwise, it cannot be guaranteed that the HIP Relay Client and supports opportunistic mode. Otherwise, it cannot
relay server can deliver the I1 packet to the intended recipient. be guaranteed that the Control Relay Server can deliver the I1 packet
to the intended recipient.
6.3. Base Exchange Replay Protection for HIP Relay Server 6.3. Base Exchange Replay Protection for Control Relay Server
In certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a HIP relay attackers, can replay an earlier base exchange through a Control
server by masquerading as the original Initiator and Responder. The Relay Server by masquerading as the original Initiator and Responder.
attack does not require the attacker(s) to compromise the private The 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 Responder has to be disconnected from the HIP relay server. the legimitate Responder has to be disconnected from the Control
Relay Server.
The relay can protect itself against replay attacks by becoming The Control Relay Server can protect itself against replay attacks by
involved in the base exchange by introducing nonces that the end- becoming involved in the base exchange by introducing nonces that the
hosts (Initiator and Responder) are required to sign. One way to do end-hosts (Initiator and Responder) are required to sign. One way to
this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets
described in [HIP-MIDDLE] and drop the I2 or R2 packets if the as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the
corresponding ECHO_RESPONSE_M parameters are not present. corresponding ECHO_RESPONSE_M parameters are not present.
6.4. Demultiplexing Different HIP Associations 6.4. Demultiplexing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder uses HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
6.5. Reuse of Ports at the Data Relay 6.5. Reuse of Ports at the Data Relay Server
If the data relay uses the same relayed address and port (as conveyed If the Data Relay Server uses the same relayed address and port (as
in the RELAYED_ADDRESS parameter) for multiple registered hosts, it conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay
appears to all the peers, and their firewalls, that all the Clients, it appears to all the peers, and their firewalls, that all
registered hosts using the relay are at the same address. Thus, a the Data Relay Clients are at the same address. Thus, a stateful
stateful firewall may allow packets pass from hosts that would not firewall may allow packets pass from hosts that would not normally be
normally be able to send packets to a peer behind the firewall. able to send packets to a peer behind the firewall. Therefore, a
Therefore, a HIP data relay SHOULD NOT re-use the port numbers. If Data Relay Server SHOULD NOT re-use the port numbers. If port
port numbers need to be re-used, the relay SHOULD have a sufficiently numbers need to be re-used, the Data Relay Server SHOULD have a
large pool of port numbers and select ports from the pool randomly to sufficiently large pool of port numbers and select ports from the
decrease the chances of a registered host obtaining the same address pool randomly to decrease the chances of a Data Relay Client
that a another host behind the same firewall is using. obtaining the same address that a another host behind the same
firewall is using.
6.6. Amplification attacks 6.6. Amplification attacks
A malicious host may send an invalid list of candidates for its peer A malicious host may send an invalid list of candidates for its peer
that are used for targeting a victim host by flooding it with that are used for targeting a victim host by flooding it with
connectivity checks. To mitigate the attack, this protocol adopts connectivity checks. To mitigate the attack, this protocol adopts
the ICE mechanism to cap the total amount of connectivity checks as the ICE mechanism to cap the total amount of connectivity checks as
defined in section Section 4.7. defined in section Section 4.7.
6.7. Attacks against Connectivity Checks and Candidate Gathering 6.7. Attacks against Connectivity Checks and Candidate Gathering
Section 13.1 in [I-D.ietf-ice-rfc5245bis] discusses about attacks [I-D.ietf-ice-rfc5245bis] describes attacks against ICE connectivity
against ICE connectivity checks. HIP bases its control plane checks. HIP bases its control plane security on Diffie-Hellman key
security on Diffie-Hellman key exchange, public keys and Hashed exchange, public keys and Hashed Message Authentication codes,
Message Authentication codes, meaning that the mentioned security meaning that the mentioned security concerns do not apply to HIP
concerns do not apply to HIP either. The mentioned section discusses either. The mentioned section discusses also of man-in-the-middle
also of man-in-the-middle replay attacks that are difficult to replay attacks that are difficult to prevent. The connectivity
prevent. The connectivity checks in this protocol are immune against checks in this protocol are immune against replay attacks because a
replay attacks because a connectivity request includes a random nonce connectivity request includes a random nonce that the recipient must
that the recipient must sign and send back as a response. sign and send back as a response.
Section 13.2 in [I-D.ietf-ice-rfc5245bis] discusses attacks on server [I-D.ietf-ice-rfc5245bis] describes attacks on server reflexive
reflexive address gathering. Similarly here, if the DNS, a HIP relay address gathering. Similarly here, if the DNS, a Control Relay
or a HIP data relay server has been compromised, not much can be Server or a Data Relay Server has been compromised, not much can be
done. However, the case where attacker can inject fake messages done. However, the case where attacker can inject fake messages
(located on a shared network segment like Wifi) does not apply here. (located on a shared network segment like Wifi) does not apply here.
HIP messages are integrity and replay protected, so it is not HIP messages are integrity and replay protected, so it is not
possible inject fake server reflexive address candidates. possible inject fake server reflexive address candidates.
Section 13.3 in [I-D.ietf-ice-rfc5245bis] discusses attacks on [I-D.ietf-ice-rfc5245bis] describes attacks on relayed candidate
relayed candidate gathering. Similarly to ICE TURN servers, data gathering. Similarly to ICE TURN servers, Data Relay Server require
relays require an authenticated base exchange that protects relayed an authenticated base exchange that protects relayed address
address gathering against fake requests and responses. Further, gathering against fake requests and responses. Further, replay
replay attacks are not possible because the HIP base exchange (and attacks are not possible because the HIP base exchange (and also
also UPDATE procedure) is protected against replay attacks. UPDATE procedure) is protected against replay attacks.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC7401] by assigning new HIP Parameter Type values for the new HIP [RFC7401] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in
Section 5.12), and PEER_PERMISSION (defined in Section 5.13). Section 5.12), and PEER_PERMISSION (defined in Section 5.13).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
[RFC5770] by assigning value for the NAT traversal mode ICE-HIP-UDP specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
(defined in Section 5.4) This specification introduces a new traversal mode ICE-HIP-UDP (defined in Section 5.4) This
keepalive Notify message type field NAT_KEEPALIVE. specification introduces a new keepalive Notify message type field
NAT_KEEPALIVE.
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC8003] that allow registering with a HIP Registration Extension [RFC8003] that allow registering with a Data
relay server for ESP relaying service: RELAY_UDP_ESP (defined in Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in
Section 4.1; and performing server reflexive candidate discovery: Section 4.1.
CANDIDATE_DISCOVERY (defined in Section 4.2).
ICE specifications discuss "Unilateral Self-Address Fixing" in ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral
section 17 in [I-D.ietf-ice-rfc5245bis]. This protocol is based on Self-Address Fixing" . This protocol is based on ICE, and thus the
ICE, and thus the same considerations apply also here with one same considerations apply also here with one exception: this protocol
exception: this protocol does not hide binary IP addresses from does not hide binary IP addresses from application-level gateways.
application-level gateways.
8. Contributors 8. Contributors
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in contributed to [RFC5770]. This document leans heavily on the work in
the RFC. the RFC.
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for
skipping to change at page 47, line 47 skipping to change at page 51, line 5
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, Henderson, "Host Identity Protocol", RFC 5201,
DOI 10.17487/RFC5201, April 2008, DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>. <http://www.rfc-editor.org/info/rfc5201>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, DOI 10.17487/RFC5207, April Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <http://www.rfc-editor.org/info/rfc5207>. 2008, <http://www.rfc-editor.org/info/rfc5207>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <http://www.rfc-editor.org/info/rfc6538>. March 2012, <http://www.rfc-editor.org/info/rfc6538>.
[MMUSIC-ICE] [MMUSIC-ICE]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", Work in Progress, July 2008. Protocol (SIP) Protocols", Work in Progress, July 2008.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
skipping to change at page 48, line 47 skipping to change at page 51, line 47
The Ta value may be configured by the user in environments where the 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 set the minimum estimate the round-trip time (RTT) between them and set the minimum
Ta value so that only two connectivity check messages are sent on Ta value so that only two connectivity check messages are sent on
every RTT. every RTT.
One way to estimate the RTT is to use the time that it takes for the One way to estimate the RTT is to use the time that it takes for the
HIP relay server registration exchange to complete; this would give Control Relay Server registration exchange to complete; this would
an estimate on the registering host's access link's RTT. Also, the give an estimate on the registering host's access link's RTT. Also,
I1/R1 exchange could be used for estimating the RTT, but since the R1 the I1/R1 exchange could be used for estimating the RTT, but since
can be cached in the network, or the relaying service can increase the R1 can be cached in the network, or the relaying service can
the delay notably, this is not recommended. increase the delay notably, this is not recommended.
Appendix B. Differences with respect to ICE Appendix B. Differences with respect to ICE
The protocol specified in this document follows the semantics of ICE The Native ICE-HIP protocol specified in this document follows the
as close as possible, and most of the differences are syntactical due semantics of ICE as close as possible, and most of the differences
to the use of a different protocol. In this section, we describe the are syntactical due to the use of a different protocol. In this
differences to the ICE protocol. section, we describe the differences to the ICE protocol.
o ICE operates at the application layer, whereas this protocol o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o The STUN protocol is not employed. Instead, this protocol reuses o The STUN protocol is not employed. Instead, native ICE-HIP reuses
the HIP control plane format in order simplify demultiplexing of the HIP control plane format in order simplify demultiplexing of
different protocols. For example, the STUN binding response is different protocols. For example, the STUN binding response is
replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN
parameter and the STUN binding response with a HIP UPDATE message parameter and the STUN binding response with a HIP UPDATE message
containing an ECHO_RESPONSE_SIGNED parameter as defined in section containing an ECHO_RESPONSE_SIGNED parameter as defined in section
Section 4.6. Section 4.6.
o The TURN protocol is not utilized. Instead, this protocol reuses o The TURN protocol is not utilized. Instead, native ICE-HIP reuses
HIP relay servers for the same purpose. Control Relay Servers for the same purpose.
o ICMP errors may be used in ICE to signal failure. In this o ICMP errors may be used in ICE to signal failure. In Native ICE-
protocol, HIP NOTIFY messages are used instead. HIP protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for o Instead of the ICE username fragment and password mechanism for
credentials, this protocol uses the HIT, derived from a public credentials, native ICE-HIP uses the HIT, derived from a public
key, for the same purpose. The username fragments are "transient key, for the same purpose. The username fragments are "transient
host identifiers, bound to a particular session established as host identifiers, bound to a particular session established as
part of the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In part of the candidate exchange" [I-D.ietf-ice-rfc5245bis].
HIP, a local public key and the derived HIT are considered long- Generally in HIP, a local public key and the derived HIT are
term identifiers, and invariant across different host associations considered long-term identifiers, and invariant across different
and different transport-layer flows. host associations and different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the o In ICE, the conflict when two communicating end-points take the
same controlling role is solved using random values (so called same controlling role is solved using random values (so called
tie-breaker value). In this protocol, the conflict is solved by tie-breaker value). In Native ICE-HIP protocol, the conflict is
the standard HIP base exchange procedure, where the host with the solved by the standard HIP base exchange procedure, where the host
"larger" HIT switches to Responder role, thus changing also to with the "larger" HIT switches to Responder role, thus changing
controlled role. also to controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks. in the connectivity checks.
o The foundation concept is unnecessary in this protocol because o The foundation concept is unnecessary in native ICE-HIP because
only a single UDP flow for the IPsec tunnel will be negotiated. only a single UDP flow for the IPsec tunnel will be negotiated.
o Frozen candidates are omitted for the same reason as foundation o Frozen candidates are omitted for the same reason as foundation
concept is excluded. concept is excluded.
o Components are omitted for the same reason as foundation concept o Components are omitted for the same reason as foundation concept
is excluded. is excluded.
o This protocol supports only "full ICE" where the two communicating o Native ICE-HIP supports only "full ICE" where the two
hosts participate actively to the connectivity checks, and the communicating hosts participate actively to the connectivity
"lite" mode is not supported. This design decision follows the checks, and the "lite" mode is not supported. This design
guidelines of ICE which recommends full ICE implementations. decision follows the guidelines of ICE which recommends full ICE
However, it should be noted that a publicly reachable Responder implementations. However, it should be noted that a publicly
may refuse to negotiate the ICE mode as described in reachable Responder may refuse to negotiate the ICE mode as
Section 4.7.2. This would result in a [RFC7401] based HIP base described in Section 4.7.2. This would result in a [RFC7401]
exchange tunneled over UDP followed ESP traffic over the same based HIP base exchange tunneled over UDP followed ESP traffic
tunnel, without the connectivity check procedures defined in this over the same tunnel, without the connectivity check procedures
document (in some sense, this mode corresponds to the case where defined in this document (in some sense, this mode corresponds to
two ICE lite implementations connect since no connectivity checks the case where two ICE lite implementations connect since no
are sent). connectivity checks are sent).
o As the "ICE lite" is not adopted here and both sides are capable o As the "ICE lite" is not adopted here and both sides are capable
of ICE-HIP-HIP mode (negotiated during the base exchange), default of ICE-HIP-UDP mode (negotiated during the base exchange), default
candidates are not employed here. candidates are not employed in Native ICE-HIP.
o If the agent is using Diffserv Codepoint markings [RFC2475] in its o If the agent is using Diffserv Codepoint markings [RFC2475] in its
media packets, it SHOULD apply those same markings to its media packets, it SHOULD apply those same markings to its
connectivity checks. connectivity checks.
o Unlike in ICE, the addresses are not XOR-ed in this protocol in o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
order to avoid middlebox tampering. protocol in order to avoid middlebox tampering.
o This protocol does not employ the ICE related address and related o Native ICE-HIP protocol does not employ the ICE related address
port attributes (that are used for diagnostic or SIP purposes). and related port attributes (that are used for diagnostic or SIP
purposes).
Appendix C. Differences to Base Exchange and UPDATE procedures Appendix C. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers how the
extensions in this protocol extends and differs from [RFC7401] and extensions in this protocol extends and differs from [RFC7401] and
[RFC8046]. [RFC8046].
o Both control and data plane are operated on top of UDP, not o Both control and data plane are operated on top of UDP, not
directly on IP. directly on IP.
o A minimal implementation would conform only to Section 4.7.1 or o A minimal implementation would conform only to Section 4.7.1 or
Section 4.7.2, thus merely tunneling HIP control and data traffic Section 4.7.2, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address. cases where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has o It is worth noting that while a rendezvous server [RFC8004] has
not been designed to be used in NATted scenarios because it just not been designed to be used in NATted scenarios because it just
relays the first I1 packet and does not employ UDP encapsulation, relays the first I1 packet and does not employ UDP encapsulation,
the HIP relay forwards all control traffic and, hence, is more the Control Relay Server forwards all control traffic and, hence,
suitable in NATted environments. Further, the data relay concept is more suitable in NATted environments. Further, the Data Relay
guarantees forwarding of data plane traffic also in the cases when Server guarantees forwarding of data plane traffic also in the
the NAT penetration procedures fail. cases when the NAT penetration procedures fail.
o Registration procedures with a relay server are similar as with o Registration procedures with a Control/Data Relay Server are
rendezvous server. However, a relay has different registration similar as with rendezvous server. However, a Control/Data Relay
parameters than rendezvous because it offers a different service. Server has different registration parameters than rendezvous
Also, the relay includes also a REG_FROM parameter that informs because it offers a different service. Also, the Control/Data
the client about its server reflexive address. In the case of a Relay Server includes also a REG_FROM parameter that informs the
data relay, it includes also a RELAYED_ADDRESS containing the Control/Data Relay Client about its server reflexive address. A
relayed address for the client. Data Relay Server includes also a RELAYED_ADDRESS containing the
relayed address for the Data Relay Client.
o In [RFC7401], the Initiator and Responder can start to exchange o In [RFC7401], the Initiator and Responder can start to exchange
application payload immediately after the base exchange. While application payload immediately after the base exchange. While
exchanging data immediately after a base exchange via a data relay exchanging data immediately after a base exchange via a Data
would be possible also here, we follow the ICE methodology to Control Relay would be possible also here, we follow the ICE
establish a direct path between two hosts using connectivity methodology to establish a direct path between two hosts using
checks. This means that there will be some additional delay after connectivity checks. This means that there will be some
the base exchange before application payload can be transmitted. additional delay after the base exchange before application
The same applies for the UPDATE procedure as the connectivity payload can be transmitted. The same applies for the UPDATE
checks introduce some additional delay. procedure as the connectivity checks introduce some additional
delay.
o In HIP without NAT traversal support, the base exchange acts as an o In HIP without any NAT traversal support, the base exchange acts
implicit connectivity check, and the mobility and multihoming as an implicit connectivity check, and the mobility and
extensions support explicit connectivity checks. After a base multihoming extensions support explicit connectivity checks.
exchange or UPDATE based connectivity checks, a host can use the After a base exchange or UPDATE based connectivity checks, a host
associated address pair for transmitting application payload. In can use the associated address pair for transmitting application
this extension, we follow the ICE methodology, where one end-point payload. In this Native ICE-HIP extension, we follow the ICE
acting in the controlled role chooses the used address pair also methodology, where one end-point acting in the controlled role
on behalf of the other end-point acting in controlled role, which chooses the used address pair also on behalf of the other end-
is different from HIP without NAT traversal support. Another point acting in controlled role, which is different from HIP
difference is that the process of choosing an address pair is without NAT traversal support. Another difference is that the
explicitly signaled using the nomination packets. The nomination process of choosing an address pair is explicitly signaled using
process in this protocol supports only single address pair, and the nomination packets. The nomination process in this protocol
multihoming extensions are left for further study. supports only single address pair, and multihoming extensions are
left for further study.
o The UPDATE procedure resembles the mobility extensions defined in o The UPDATE procedure resembles the mobility extensions defined in
[RFC8046]. The first UPDATE message from the mobile host is [RFC8046]. The first UPDATE message from the mobile host is
exactly the same as in the mobility extensions. The second UPDATE exactly the same as in the mobility extensions. The second UPDATE
message from the peer host and third from the mobile host are message from the peer host and third from the mobile host are
different in the sense that they merely acknowledge and conclude different in the sense that they merely acknowledge and conclude
the reception of the candidates through the relay. In other the reception of the candidates through the Control Relay Server.
words, they do not yet test for connectivity (besides reachability In other words, they do not yet test for connectivity (besides
through the HIP relay) unlike in the mobility extensions. The reachability through the Control Relay Server) unlike in the
idea is that connectivity check procedure follows the ICE mobility extensions. The idea is that connectivity check
specification, which is somewhat different from the HIP mobility procedure follows the ICE specification, which is somewhat
extensions. different from the HIP mobility extensions.
o The connectivity checks as defined in the mobility extensions o The connectivity checks as defined in the mobility extensions
[RFC8046] are triggered only by the peer of the mobile host. [RFC8046] are triggered only by the peer of the mobile host.
Since successful NAT penetration requires that both end-points Since successful NAT penetration requires that both end-points
test connectivity, both the mobile host and its peer host have to test connectivity, both the mobile host and its peer host have to
test for connectivity. In addition, this protocol validates also test for connectivity. In addition, this protocol validates also
the UDP ports; the ports in the connectivity check must match with the UDP ports; the ports in the connectivity check must match with
the response, as required by ICE. the response, as required by ICE.
o In HIP mobility extensions [RFC8046], an outbound locator has some o In HIP mobility extensions [RFC8046], an outbound locator has some
 End of changes. 161 change blocks. 
781 lines changed or deleted 913 lines changed or added

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