draft-ietf-hip-native-nat-traversal-13.txt   draft-ietf-hip-native-nat-traversal-14.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: January 2, 2017 Ericsson Expires: May 28, 2017 Ericsson
July 1, 2016 November 24, 2016
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-13 draft-ietf-hip-native-nat-traversal-14
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 January 2, 2017. This Internet-Draft will expire on May 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7
4.2. Transport Address Candidate Gathering . . . . . . . . . . 10 4.2. Transport Address Candidate Gathering . . . . . . . . . . 10
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 11
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 13
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 16
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 15 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 16
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 18 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 19
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 19 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 21
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 19 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 22
4.7.2. Base Exchange without Connectivity Checks . . . . . . 20 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 22
4.7.2. Base Exchange without Connectivity Checks . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . 21 Encapsulation . . . . . . . . . . . . . . . . . . . . 23
4.8. Sending Control Packets after the Base Exchange . . . . . 22 4.8. Sending Control Packets after the Base Exchange . . . . . 24
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 22 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 25
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 24 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 27
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 25 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 25 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 28
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 25 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 28
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 26 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 29
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 26 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 30
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 27 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 30
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 27 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 31
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 28 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 31
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 29 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 32
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 30 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 33
5.6. Relay and Registration Parameters . . . . . . . . . . . . 30 5.6. Relay and Registration Parameters . . . . . . . . . . . . 33
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 31 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 34
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 33 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 36
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 33 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 37
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 34 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 37
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 34 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 37
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 35 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 38
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 35 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 39
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 36 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 40
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 37 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 37 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 41
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 38 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 41
6.3. Base Exchange Replay Protection for HIP Relay Server . . 38 6.3. Base Exchange Replay Protection for HIP Relay Server . . 41
6.4. Demuxing Different HIP Associations . . . . . . . . . . . 38 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 42
6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 39 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 42
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 6.7. Attacks against Connectivity Checks and Candidate
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 40 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 41 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix B. Base Exchange through a Rendezvous Server . . . . . 43 10.1. Normative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 46
Appendix B. Base Exchange through a Rendezvous Server . . . . . 47
Appendix C. Differences to ICE . . . . . . . . . . . . . . . . . 47
Appendix D. Differences to Base Exchange and UPDATE procedures . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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.
Two NAT traversal techniques for HIP are specified in [RFC5770]. One HIP experiment report [RFC6538] mentions that Teredo based NAT
of them uses only UDP encapsulation, while the other uses also the traversal for HIP and related ESP traffic (with double tunneling
Interactive Connectivity Establishment (ICE) overhead). Two HIP specific NAT traversal techniques for HIP are
[I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session specified in [RFC5770]. One of them uses only UDP encapsulation,
while the other uses also the Interactive Connectivity Establishment
(ICE) [I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session
Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using
Relays around NAT (TURN) [RFC5766] protocols to achieve a reliable Relays around NAT (TURN) [RFC5766] protocols to achieve a reliable
NAT traversal solution. NAT traversal solution.
The benefit of using ICE and STUN/TURN is that one can re-use the NAT The benefit of using ICE and STUN/TURN is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
STUN and TURN servers. Also, some middleboxes may be STUN-aware and STUN and TURN servers. Also, some middleboxes may be STUN-aware and
could be able to do something "smart" when they see STUN being used could be able to do something "smart" when they see STUN being used
for NAT traversal. However, implementing a full ICE/STUN/TURN for NAT traversal. However, implementing a full ICE/STUN/TURN
protocol stack results in a considerable amount of effort and code protocol stack results in a considerable amount of effort and code
skipping to change at page 5, line 41 skipping to change at page 5, line 48
A translated transport address of a host as observed by a HIP A translated transport address of a host as observed by a HIP
relay server or a STUN/TURN server. relay server or a STUN/TURN 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 HIP data relay. Packets that
arrive at this address are relayed towards the registered host. arrive at this address are relayed towards the registered host.
Permission:
In the context of HIP data relay, permission refers to a concept
similar to TURN's channels. Before a host can use a relayed
candidate to forward traffic through a HIP data relay, the host
must activate the relayed candidate with a specific peer host.
Base:
The base of an candidate is the local source address a host uses
to send packets for the associated candidate. For example, the
base of a server reflexive address is the local address the host
used for registering itself to the associated HIP relay. The base
of a host candidate is equal to the host candidate itself.
3. Overview of Operation 3. Overview of Operation
+-------+ +-------+
| HIP | | HIP |
+--------+ | Relay | +--------+ +--------+ | Relay | +--------+
| Data | +-------+ | Data | | Data | +-------+ | Data |
| Relay | / \ | Relay | | Relay | / \ | Relay |
+--------+ / \ +--------+ +--------+ / \ +--------+
/ \ / \
/ \ / \
/ \ / \
/ <- Signaling -> \ / <- Signaling -> \
skipping to change at page 8, line 4 skipping to change at page 8, line 14
over UDP in NATted environments. A HIP relay server forwards HIP over UDP in NATted environments. A HIP relay server forwards HIP
control packets between the Initiator and the Responder. control packets between the Initiator and the Responder.
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 HIP relay server or offered
separately on another server. If the server supports relaying of UDP separately on another server. If the server supports relaying of UDP
encapsulated ESP, the host is allowed to register for a data relaying encapsulated ESP, the host is allowed to register for a data relaying
service using the registration extensions in Section 3.3 of service using the registration extensions in Section 3.3 of
[RFC8003]). If the server has sufficient relaying resources (free
[I-D.ietf-hip-rfc5203-bis]). 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 relay would accept the request but does not currently have enough resources to provide data
data relaying request but does not currently have enough resources to relaying service, it MUST reject the request with Failure Type
provide data relaying service, it MUST reject the request with "Insufficient resources" [RFC8003].
Failure Type "Insufficient resources" [I-D.ietf-hip-rfc5203-bis].
A HIP relay server MUST silently drop packets to a HIP relay client A HIP relay server MUST silently drop packets to a HIP relay client
that has not previously registered with the HIP relay. The 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 [I-D.ietf-hip-rfc5203-bis]. The HIP control plane defined in [RFC8003]. The HIP control plane relaying registration
relaying registration follows [RFC5770], but the data plane follows [RFC5770], but the data plane registration is different. It
registration is different. It is worth noting that if the HIP is worth noting that if the HIP control and data plane relay services
control and data plane relay services reside on different hosts, the reside on different hosts, the relay client has to register
relay client has to register separately to each of them. In the separately to each of them. In the example shown in Figure 2, the
example shown in Figure 2, the two services are coupled on a single two services are coupled on a single host.
host.
HIP HIP HIP HIP
Relay [Data] Relay Relay [Data] Relay
Client Server 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]))) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
skipping to change at page 10, line 5 skipping to change at page 10, line 11
the HIP association is closed (or times out), or the registration the HIP association is closed (or times out), or the registration
lifetime passes without the registered host refreshing the lifetime passes without the registered host refreshing the
registration, the data relay MUST stop relaying packets for that host registration, the data relay MUST stop relaying packets for that host
and close the corresponding UDP port (unless other registered hosts and close the corresponding UDP port (unless other registered hosts
are still using it). are still using it).
The data relay MAY use the same relayed address and port for multiple The data relay MAY use the same relayed address and port for multiple
registered hosts, but since this can cause problems with stateful registered hosts, but since this can cause problems with stateful
firewalls (see Section 6.5) it is NOT RECOMMENDED. firewalls (see Section 6.5) it is NOT RECOMMENDED.
When a registered client sends an UPDATE (e.g., due to host movement
or the renew service registration), the relay server MUST follow the
general guidelines defined in [RFC8003], with the difference that all
UPDATE messages are delivered on top of UDP. In addition to this,
the relay server MUST include the REG_FROM parameter in all UPDATE
responses sent to the client. This applies both renewals of service
registration but also to host movement, where especially the latter
requires the client to learn its new server reflexive address
candidate.
4.2. Transport Address Candidate Gathering 4.2. Transport Address Candidate Gathering
A host needs to gather a set of address candidates before contacting A host needs to gather a set of address candidates before contacting
a non-relay host. The candidates are needed for connectivity checks a non-relay host. The candidates are needed for connectivity checks
that allow two hosts to discover a direct, non-relayed path for that allow two hosts to discover a direct, non-relayed path for
communicating with each other. One server reflexive candidate can be communicating with each other. One server reflexive candidate can be
discovered during the registration with the HIP relay server from the discovered during the registration with the HIP relay server from the
REG_FROM parameter. REG_FROM parameter.
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 is to be done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP
used for the connectivity checks. It is RECOMMENDED that all three mode is to be used for the connectivity checks. It is RECOMMENDED
types of candidates (host, server reflexive, and relayed) are that all three types of candidates (host, server reflexive, and
gathered to maximize the probability of successful NAT traversal. relayed) are gathered to maximize the probability of successful NAT
However, if no data relay is used, and the host has only a single traversal. However, if no data relay is used, and the host has only
local IP address to use, the host MAY use the local address as the a single local IP address to use, the host MAY use the local address
only host candidate and the address from the REG_FROM parameter as the only host candidate and the address from the REG_FROM
discovered during the relay registration as a server reflexive parameter discovered during the relay registration as a server
candidate. In this case, no further candidate gathering is needed. reflexive candidate. In this case, no further candidate gathering is
needed.
If a host has more than one network interface, additional server If a host has more than one network interface, additional server
reflexive candidates can be discovered by sending registration reflexive candidates can be discovered by sending registration
requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by
IANA: 4]) from each of the interfaces to a HIP relay server. When a IANA: 4]) from each of the interfaces to a HIP relay server. When a
HIP relay server receives a registration request with HIP relay server receives a registration request with
CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter,
containing the same information as if this was a relay registration, containing the same information as if this was a relay registration,
to the response. This request type SHOULD NOT create any state at to the response. This request type SHOULD NOT create any state at
the HIP relay server. the HIP relay server.
ICE guidelines for candidate gathering MUST be followed as described
in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host
candidates (loopback, anycast and others) should excluded as
described in section 4.1.1.1 of the ICE document. Relayed candidates
SHOULD be gathered in order to guarantee successful NAT traversal.
It is RECOMMENDED for implementations to support this functionality
even if it will not be used in deployments in order to enable it by
software configuration update if needed at some point. A host SHOULD
employ only a relay server for gathering the candidates for a single
HIP association; either a one server providing both HIP and data
relay functionality, or one HIP relay server and another one for data
relaying if the functionality is offered by another server. When the
relay service is split between two hosts, the server reflexive
candidate from the HIP relay SHOULD be used instead of the one
provided by the data relay. If a relayed candidate is identical to a
host candidate, the relayed candidate must be discarded. NAT64
considerations in section 4.1.1.2 in the ICE document apply as well.
HIP based connectivity can be utilized by IPv4 applications using
LSIs and by IPv6 based applications using HITs. The LSIs and HITs of
the local virtual interfaces MUST be excluded in the candidate
gathering phase as well to avoid creating unnecessary loopback
connectivity tests.
Gathering of candidates MAY also be performed as specified in Gathering of candidates MAY also be performed as specified in
Section 4.2 of [RFC5770] if STUN servers are available, or if the Section 4.2 of [RFC5770] if STUN servers are available, or if the
host has just a single interface and no STUN or HIP data relay host has just a single interface and no STUN or HIP data relay
servers are available. servers are available.
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
skipping to change at page 12, line 19 skipping to change at page 13, line 9
too fast to avoid congestion and overwhelming the NATs. For this too fast to avoid congestion and overwhelming the NATs. For this
purpose, during the base exchange, hosts can negotiate a transaction purpose, during the base exchange, hosts can negotiate a transaction
pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2
packets. The parameter contains the minimum time (expressed in packets. The parameter contains the minimum time (expressed in
milliseconds) the host would wait between two NAT traversal milliseconds) the host would wait between two NAT traversal
transactions, such as starting a new connectivity check or retrying a transactions, such as starting a new connectivity check or retrying a
previous check. The value that is used by both of the hosts is the previous check. The value that is used by both of the hosts is the
higher out of the two offered values. higher out 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 500 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 20 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 500 ms MUST be used as that in the base exchange, a Ta value of 50 ms MUST be used as that host's
host's minimum value. minimum value.
4.5. Base Exchange via HIP Relay Server 4.5. Base Exchange via HIP 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 HIP relay server. Connectivity pacing (denoted as
TA_P here) was described in Section 4.4 and is neither repeated here. TA_P here) was described in Section 4.4 and is neither repeated here.
Similarly, the NAT traversal mode negotiation process (denoted as Similarly, the NAT traversal mode negotiation process (denoted as
NAT_TM in the example) was described in Section 4.3 and is neither NAT_TM in the example) was described in Section 4.3 and is neither
repeated here. If a relay receives an R1 or I2 packet without the repeated here. If a relay receives an R1 or I2 packet without the
NAT traversal mode parameter, it MUST drop it and SHOULD send a NAT traversal mode parameter, it MUST drop it and SHOULD send a
skipping to change at page 13, line 41 skipping to change at page 14, line 41
belongs to the Initiator and the destination HIT to the Responder. belongs to the Initiator and the destination HIT to the Responder.
The initiator sends the I1 packet from its IP address to the IP The initiator sends the I1 packet from its IP address to the IP
address of the HIP relay over UDP. address of the HIP relay over UDP.
In step 2, the HIP relay server receives the I1 packet. If the In step 2, the HIP 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 relay
processes the packet. Otherwise, the relay MUST drop the packet processes the packet. Otherwise, the relay MUST drop the packet
silently. The relay appends a RELAY_FROM parameter to the I1 packet, silently. The relay appends a RELAY_FROM parameter to the I1 packet,
which contains the transport source address and port of the I1 as which contains the transport source address and port of the I1 as
observed by the relay. The relay protects the I1 packet with observed by the relay. The relay protects the I1 packet with
RELAY_HMAC as described in [I-D.ietf-hip-rfc5204-bis], except that RELAY_HMAC as described in [RFC8004], except that the parameter type
the parameter type is different (see Section 5.8). The relay changes is different (see Section 5.8). The relay changes the source and
the source and destination ports and IP addresses of the packet to destination ports and IP addresses of the packet to match the values
match the values the Responder used when registering to the relay, the Responder used when registering to the relay, i.e., the reverse
i.e., the reverse of the R2 used in the registration. The relay MUST of the R2 used in the registration. The relay MUST recalculate the
recalculate the transport checksum and forward the packet to the transport checksum and forward the packet to the Responder.
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 Responder validates the RELAY_HMAC according to [RFC8004] and
silently drops the packet if the validation fails. The Responder
[I-D.ietf-hip-rfc5204-bis] and silently drops the packet if the replies with an R1 packet to which it includes RELAY_TO and NAT
validation fails. The Responder replies with an R1 packet to which traversal mode parameters. The responder MUST include ICE-HIP-UDP in
it includes RELAY_TO and NAT traversal mode parameters. The the NAT traversal modes. The RELAY_TO parameter MUST contain the
responder MUST include ICE-HIP-UDP in the NAT traversal modes. The same information as the RELAY_FROM parameter, i.e., the Initiator's
RELAY_TO parameter MUST contain the same information as the transport address, but the type of the parameter is different. The
RELAY_FROM parameter, i.e., the Initiator's transport address, but RELAY_TO parameter is not integrity protected by the signature of the
the type of the parameter is different. The RELAY_TO parameter is R1 to allow pre-created R1 packets at the Responder.
not integrity protected by the signature of the 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 relay receives the R1 packet. The relay drops the
packet silently if the source HIT belongs to an unregistered host. packet silently if the source HIT belongs to an unregistered host.
The relay MAY verify the signature of the R1 packet and drop it if The relay MAY verify the signature of the R1 packet and drop it if
the signature is invalid. Otherwise, the relay rewrites the source the signature is invalid. Otherwise, the relay rewrites the source
address and port, and changes the destination address and port to address and port, and changes the destination address and port to
match RELAY_TO information. Finally, the relay recalculates match RELAY_TO information. Finally, the relay 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
skipping to change at page 15, line 25 skipping to change at page 16, line 23
the HIP relay, both of them employ the IP address of the relay as the the HIP relay, both of them employ the IP address of the relay as the
destination address for the packets. This address MUST NOT be used destination address for the packets. This address MUST NOT be used
as a destination for ESP traffic unless the HIP relay supports also as a destination for ESP traffic unless the HIP relay supports also
ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was
successfully negotiated and selected, the Initiator and Responder successfully negotiated and selected, the Initiator and Responder
MUST start the connectivity checks in order to attempt to obtain MUST start the connectivity checks in order to attempt to obtain
direct end-to-end connectivity through NAT devices. It is worth direct end-to-end connectivity through NAT devices. It is worth
noting that the connectivity checks MUST be completed even though no noting that the connectivity checks MUST be completed even though no
ESP_TRANSFORM would be negotiated and selected. ESP_TRANSFORM would be negotiated and selected.
The connectivity checks follow the ICE methodology [MMUSIC-ICE], but The connectivity checks MUST follow the ICE methodology [MMUSIC-ICE],
UDP encapsulated HIP control messages are used instead of ICE but UDP encapsulated HIP control messages are used instead of ICE
messages. Only normal connectivity checks can be used because messages. Only normal nomination MUST be used for the connectivity
aggressive connectivity checks are deprecated. The Initiator MUST checks, i.e., aggressive nomination MUST NOT be employed. As stated
take the role of controlling host and the Responder acts as the in the ICE specification, the basic procedure for connectivity checks
controlled host. The protocol follows standard HIP UPDATE sending has three phases: sorting the candidate pairs according their
and processing rules as defined in section 6.11 and 6.12 in priority, sending checks in the prioritized order and acknowledging
[RFC7401], but some new parameters are introduced: the checks from the peer host.
CANDIDATE_PRIORITY, MAPPED_ADDR and NOMINATE.
The Initiator MUST take the role of controlling host and the
Responder acts as the controlled host. The roles MUST persist
throughout the HIP associate lifetime (to be reused in the possibly
mobility UPDATE procedures). In the case both communicating nodes
are initiating the communications to each other using an I1 packet,
the conflict is resolved as defined in section 6.7 in [RFC7401]: the
host with the "larger" HIT changes to its Role to Responder. In such
a case, the host changing its role to Responder MUST also switch to
controlling role.
The protocol follows standard HIP UPDATE sending and processing rules
as defined in section 6.11 and 6.12 in [RFC7401], but some new
parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDR and
NOMINATE).
4.6.1. Connectivity Check Procedure 4.6.1. Connectivity Check Procedure
Figure 5 illustrates connectivity checks in a simplified scenario, Figure 5 illustrates connectivity checks in a simplified scenario,
where the Initiator and Responder have only a single candidate pair where the Initiator and Responder have only a single candidate pair
to check. Typically, NATs drop messages until both sides have sent to check. Typically, NATs drop messages until both sides have sent
messages using the same port pair. In this scenario, the Responder messages using the same port pair. In this scenario, the Responder
sends a connectivity check first but the NAT of the Initiator drops sends a connectivity check first but the NAT of the Initiator drops
it. However, the connectivity check from the Initiator reaches the it. However, the connectivity check from the Initiator reaches the
Responder because it uses the same port pair as the first message. Responder because it uses the same port pair as the first message.
It is worth noting that the message flow in this section is
idealistic, and, in practice, more messages would be dropped
especially in the beginning. For instance, connectivity tests always
start with the candidates with the highest priority, which would be
host candidates (which would not reach the recipient in this
scenario).
Initiator NAT1 NAT2 Responder Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | | | | ECHO_REQ_SIGN)) | |
| X<-----------------------------------+----------------+ | X<-----------------------------------+----------------+
| | | | | | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->| +-------------+------------------------------------+--------------->|
| | | | | | | |
| 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
| | MAPPED_ADDR)) | |
|<------------+------------------------------------+----------------+ |<------------+------------------------------------+----------------+
| | | | | | | |
| 4. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | | 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->+ |<------------+------------------------------------+----------------+
| | | | | | | |
| 5. Other connectivity checks using UPDATE over UDP | | 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | |
<-------------+------------------------------------+----------------> +-------------+------------------------------------+--------------->|
| | | | | | | |
| 6. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | | 6. Other connectivity checks using UPDATE over UDP |
|<------------+------------------------------------+---------------->
| | | |
| 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) |
+-------------+------------------------------------+--------------->| +-------------+------------------------------------+--------------->|
| | | | | | | |
| 7. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
| NOMINATE)) | | | NOMINATE)) | |
|<------------+------------------------------------+----------------+ |<------------+------------------------------------+----------------+
| | | | | | | |
| 8. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | |
+-------------+------------------------------------+--------------->+ +-------------+------------------------------------+--------------->+
| | | | | | | |
| 9. ESP data traffic over UDP | | | 10. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+ +<------------+------------------------------------+--------------->+
| | | | | | | |
Figure 5: Connectivity Checks Figure 5: Connectivity Checks
In step 1, the Responder sends a connectivity check to the Initiator In step 1, the Responder sends a connectivity check to the Initiator
that the NAT of the Initiator drops. The message includes a number that the NAT of the Initiator drops. The message includes a number
of parameters. As specified in [RFC7401]), the SEQ parameter of parameters. As specified in [RFC7401]), the SEQ parameter
includes a running sequence identifier for the connectivity check. includes a running sequence identifier for the connectivity check.
The candidate priority (denoted "CAND_PRIO" in the figure) describes The candidate priority (denoted "CAND_PRIO" in the figure) describes
the priority of the address candidate being tested. The the priority of the address candidate being tested. The
ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a
nonce that the recipient must sign and echo back as it is. nonce that the recipient must sign and echo back as it is.
In step 2, the Initiator sends a connectivity check using the same In step 2, the Initiator sends a connectivity check using the same
address pair candidate as the Responder did and the message traverses address pair candidate as in previous step and the message traverses
successfully the NAT boxes. The message includes the same parameters successfully the NAT boxes. The message includes the same parameters
as in the previous step. as in the previous step. It should be noted that the sequence
identifier is locally assigned by the Responder, so it can be
different than in the previous step.
In step 3, the Responder has successfully received the previous In step 3, the Responder has successfully received the previous
connectivity check from the Initiator and starts to build a response connectivity check from the Initiator and starts to build a response
message. Since the message from the Initiator included a SEQ, the message. Since the message from the Initiator included a SEQ, the
Responder must acknowledge it using an ACK parameter. Also, the Responder must acknowledge it using an ACK parameter. Also, the
nonce contained in the echo request must be echoed back in an nonce contained in the echo request must be echoed back in an
ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The
Responder includes also a MAPPED_ADDRESS parameter that contains the Responder includes also a MAPPED_ADDRESS parameter that contains the
transport address of the Initiator as observed by the Responder (i.e. transport address of the Initiator as observed by the Responder (i.e.
peer reflexive candidate). The Initiator should acknowledge the peer reflexive candidate). This message is successfully delivered to
message from the Responder, so the Responder also includes its own the Initiator, and upon reception the Initiator marks the candidate
SEQ in the message and its own echo request for additional security. pair as valid.
In step 4, the Initiator receives the message from the Responder and In step 4, the Responder retransmits the connectivity check sent in
builds a corresponding response that concludes connectivity checks. the first step since it was not acknowledged yet.
Since the previous message from the Responder included a new SEQ and
ECHO_REQUEST_SIGN parameters, the Initiator includes the
corresponding ACK and ECHO_RESPONSE_SIGN parameters. Before sending,
it also includes a MAPPED_ADDR parameter describing the peer
reflexive candidate.
In step 5, the Initiator and Responder test the remaining address In step 5, the Initiator responds to the previous connectivity check
candidates (if any). message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the
ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition,
it includes MAPPED_ADDR parameter that includes the peer reflexive
candidate. This response message is successfully delivered to the
Responder, and upon reception the Initiator marks the candidate pair
as valid.
In step 6, the Initiator has completed testing all address candidates In step 6, despite the two hosts have now valid address candidates,
they still test the remaining address candidates in a similar way as
in the previous steps (due to the use of normal nomination). It
should be noted that each connectivity check has an unique sequence
number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates
and nominates one address candidate to be used. It sends an UPDATE and nominates one address candidate to be used. It sends an UPDATE
message using the selected address candidates that includes a number message using the selected address candidates that includes a number
of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the
NOMINATE parameter. NOMINATE parameter.
In step 7, the Responder receives the message with NOMINATE parameter In step 8, the Responder receives the message with NOMINATE parameter
from the Initiator. It sends a response that includes the NOMINATE from the Initiator. It sends a response that includes the NOMINATE
parameter in addition to a number of other parameters. The ACK and parameter in addition to a number of other parameters. The ACK and
ECHO_RESPONSE_SIGN parameters acknowledge the SEQ and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
ECHO_REQUEST_SIGN parameters from previous message from the ECHO_REQUEST_SIGN parameters from previous message from the
Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGN Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGN
parameters in order to receive an acknowledgment from the Responder. parameters in order to receive an acknowledgment from the Responder.
In step 8, 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_SIGN 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 9, 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, the host MUST activate the
address before connectivity checks by sending an UPDATE message 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 relay drops ESP packets using the relayed address.
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
in this protocol (in contrast to ICE that employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a
particular connectivity check.
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 omitted them for
simplicity). To provide strong replay protection, for each pair of simplicity). Each connectivity check sent by a host MUST include a
address candidates, both the Initiator and Responder MUST send a send SEQ parameter and ECHO_REQUEST_SIGN parameter, and correspondingly
a nonce to each other for signing using the ECHO_REQUEST_SIGNED the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED
parameter (that then has to be echoed back by the recipient). according to the rules specified in [RFC7401].
Similarly, the SEQ parameter enforces the recipient to acknowledge a
received message. Effectively these two mechanisms combined result The host sending a connectivity check should check that the response
in a secure three way packet exchange that tests both sides for uses also the same pair of UDP ports. If the UDP ports do not match,
return routability. the host MUST drop the packet.
A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A
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.
[RFC7401] states that UPDATE packets have to include either a SEQ or [RFC7401] states that UPDATE packets have to include either a SEQ or
ACK parameter (or both). According to the RFC, each SEQ parameter ACK parameter (or both). According to the RFC, each SEQ parameter
should be acknowledged separately. In the context of NATs, this should be acknowledged separately. In the context of NATs, this
means that some of the SEQ parameters sent in connectivity checks means that some of the SEQ parameters sent in connectivity checks
will lost or arrive out of order. From the viewpoint of the will lost or arrive out of order. From the viewpoint of the
recipient, this is not a problem since the recipient will just recipient, this is not a problem since the recipient will just
"blindly" acknowledge the SEQ. However, the sender needs to be "blindly" acknowledge the SEQ. However, the sender needs to be
prepared for lost sequence identifiers and ACKs parameters that prepared for lost sequence identifiers and ACKs parameters that
arrive out of order. arrive out of order.
skipping to change at page 18, line 43 skipping to change at page 20, line 30
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode. employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity checks SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity checks 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
of tested address candidates will never produce a working address of tested address candidates will never produce a working address
pair, and thus may cause retransmissions. Upon successful nomination pair, and thus may cause retransmissions. Upon successful nomination
an address pair, a host MAY immediately stop sending such an address pair, a host MAY immediately stop sending such
retransmissions. retransmissions.
The packet flow illustrations are missing a scenario where both the ICE procedures for prioritizing candidates, eliminating redundant
Initiator and Responder send simultaneously connectivity checks to candidates and forming check lists (including pruning) MUST be
each other using the same address candidates, and the NATs at both followed as specified in [I-D.ietf-ice-rfc5245bis], with the
sides let the packets pass. From the viewpoint of NAT penetration, exception that the foundation, frozen candidates and default
this results in a bit more unnecessary packet exchanges, but both candidates are not used. From viewpoint of ICE specification, the
ends SHOULD nevertheless complete the three way connectivity check protocol specified in this document operates using Component ID of 1
process they initiated. on all candidates, and the foundation of all candidates is unique.
This specification defines only "full ICE" mode, and the "lite ICE"
is not supported. The reasoning behind for the missing features is
described in Appendix C).
The connectivity check messages MUST be paced by the value negotiated The connectivity check messages MUST be paced by the Ta value
during the base exchange as described in Section 4.4. If neither one negotiated during the base exchange as described in Section 4.4. If
of the hosts announced a minimum pacing value, a value of 500 ms MUST neither one of the hosts announced a minimum pacing value, a value of
be used. 20 ms SHOULD be used.
As defined in [RFC5770], both hosts MUST form a priority ordered Both hosts MUST form a priority ordered checklist and start to check
checklist and start to check transactions every Ta milliseconds as transactions every Ta milliseconds as long as the checks are running
long as the checks are running and there are candidate pairs whose and there are candidate pairs whose tests have not started. The
tests have not started. The retransmission timeout (RTO) for the retransmission timeout (RTO) for the connectivity check UPDATE
connectivity check UPDATE packets MUST be calculated as follows: packets MUST be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
"In-Progress" state. This is identical to the formula in "In-Progress" state. This is identical to the formula in
[I-D.ietf-ice-rfc5245bis] if there is only one checklist. [I-D.ietf-ice-rfc5245bis] when there is only one checklist. A
smaller value than 500 ms for the RTO MUST NOT be used.
Each connectivity check request packet MUST contain a Each connectivity check request packet MUST contain a
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.
If the connectivity checks failed, the hosts MUST NOT send ESP Following ICE guidelines [I-D.ietf-ice-rfc5245bis], it is RECOMMENDED
traffic to each other but MAY continue communicating using HIP to restrict total number of connectivity checks to 100 for each host
association. This can be achieved by limiting the connectivity
checks to the 100 candidate pairs with the highest priority.
4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence
number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate
in a CAND_PRIO parameter and NOMINATE parameter to signify concluding
of the connectivity checks. Since the nominated address pair has
been already tested for reachability, the controlled host should be
able to receive the message. Upon reception, the controlled host
SHOULD select the nominated address pair. The response message MUST
include a SEQ parameter with a new sequence id, acknowledgment of the
sequence is from the controlling host in an ACK parameter, a new
ECHO_REQ_SIGN parameter, ECHO_RESP_SIGNED parameter corresponding to
the ECHO_REQUEST_SIGN parameter from the controlling host and the
NOMINATE parameter. After sending this packet, the controlled host
can create IPsec security associations using the nominated address
candidate for delivering application payload to the controlling host.
Since the message from the controlled host included a new sequence id
and echo request for signature, the controlling host MUST acknowledge
this with a new UPDATE message that includes an ACK and
ECHO_RESPONSE_SIGNED parameters. After this final concluding
message, also the controlling host can create IPsec security
associations for delivering application payload to the controlled
host.
It is possible that packets are delayed by the network. Both host
MUST continue to respond to any connectivity checks despite an
address pair has been nominated.
If all the connectivity checks have failed, the hosts MUST NOT send
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 Alternatives
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 HIP relay, the explicit NAT traversal mode
negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode
does not have to be negotiated. In such a scenario, the Initiator does not have to be negotiated. In such a scenario, the Initiator
sends an I1 message over UDP and the Responder responds with an R1 sends an I1 message over UDP and the Responder responds with an R1
message without including any NAT traversal mode parameter. The rest message without including any NAT traversal mode parameter. The rest
of the base exchange follows the procedures defined in [RFC7401], of the base exchange follows the procedures defined in [RFC7401],
except that the control and data plane use UDP encapsulation. Here, except that the control and data plane use UDP encapsulation. Here,
the use of UDP for NAT traversal is agreed implicitly. This way of the use of UDP for NAT traversal is agreed implicitly. This way of
operation is still subject to NAT timeouts, and the hosts MUST employ operation is still subject to NAT timeouts, and the hosts MUST employ
NAT keepalives as defined in section Section 4.10. 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 section 4.8 in [RFC5770]. The procedure is applicable
also in the context of this specification, so it is repeated here for also in the context of this specification, so it is repeated here for
completeness. 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
skipping to change at page 21, line 42 skipping to change at page 24, line 20
any relays, at the Responder. When this happens, the procedures in any relays, at the Responder. When this happens, the procedures in
[RFC7401] are followed for the rest of the base exchange. The [RFC7401] are followed for the rest of the base exchange. The
Initiator may receive multiple R1 packets, with and without UDP Initiator may receive multiple R1 packets, with and without UDP
encapsulation, from the Responder. However, after receiving a valid encapsulation, from the Responder. However, after receiving a valid
R1 and answering it with an I2, further R1 packets that are not R1 and answering it with an I2, further R1 packets that are not
retransmits of the original R1 MUST be ignored. retransmits of the original R1 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 service, the middlebox follows rendezvous procedures in [RFC8004].
[I-D.ietf-hip-rfc5204-bis].
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
skipping to change at page 22, line 41 skipping to change at page 25, line 19
notification (see Section 5.10). 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 [I-D.ietf-hip-rfc5206-bis] define Mobility extensions for HIP [I-D.ietf-hip-rfc5206-bis] define
handover procedures without NATs. In this section, we define how two handover procedures without NATs. In this section, we define how two
hosts interact with handover procedures in scenarios involving NATs. hosts interact with handover procedures in scenarios involving NATs.
The specified extensions define only simple mobility using a pair of The specified extensions define only simple mobility using a pair of
security associations, and multihoming extensions are left to be security associations, and multihoming extensions are left to be
defined in later specifications. defined in later specifications. The procedures in this section
offer the same functionality as "ICE restart" specified in
[I-D.ietf-ice-rfc5245bis]. The example described in this section
shows only a relay server for the peer host for the sake of
simplicity, but also the mobile host may also have a relay server.
We assume that the two hosts have successfully negotiated and chosen The assumption here is that the two hosts have successfully
the ICE-HIP-UDP mode during the base exchange as defined in negotiated and chosen the ICE-HIP-UDP mode during the base exchange
Section 4.3. The Initiator of the base exchange MUST store as defined in Section 4.3. The Initiator of the base exchange MUST
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
mobile host SHOULD first send UPDATE messages to its HIP and data
relays if it has registered to such. It SHOULD wait for all of them
to respond for two minutes and then continue with the handover
procedure without information from the relays that did not respond.
As defined in section Section 4.1, a response message from a relay
includes a REG_FROM parameter that describes the server reflexive
candidate of the mobile host to be used in the candidate exchange
during the handover. Similarly, an UPDATE to a data relay is
necessary to make sure the data relay 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 HIP relay belongs to the peer
host, i.e., the peer host is a relay client for the HIP relay. Next, host, i.e., the peer host is a relay client for the HIP relay. Next,
we describe the procedure in the figure in detail. we describe the procedure in the figure in detail.
Mobile Host HIP relay Peer Host Mobile Host HIP relay Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
skipping to change at page 24, line 41 skipping to change at page 27, line 35
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, the host MUST reactivate the address before connectivity
checks by sending an UPDATE message containing PEER_PERMISSION checks by sending an UPDATE message containing PEER_PERMISSION
parameter as described in Section 4.12.1. Otherwise, the relay drops parameter as described in Section 4.12.1. Otherwise, the relay drops
ESP packets using the relayed address. 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 that they have established a host periodic keepalives to other hosts that they have established a host
associating with. If a registered host has not sent any data or associating with. Both a registered client and relay server SHOULD
control messages to its HIP or data relay for 15 seconds, it MUST send a HIP NOTIFY packets to each other every 15 seconds (the so
send a HIP NOTIFY packet to the relay. Likewise, if a host has not called Tr value in ICE) unless they have exchange some other traffic
sent any data to another host it has established a host association over the used UDP ports. Other values MAY be used, but a Tr value
in the ICE-HIP_UDP mode, it MUST send either a HIP NOTIFY packet or smaller than 15 seconds MUST NOT be used. Likewise, if a host has
an ICMPv6 echo request inside the related ESP tunnel. HIP relay not sent any data to another host it has established a host
servers MAY refrain from sending keepalives if it's known that they association in the ICE-HIP_UDP mode within 15 seconds, it MUST send
are not behind a middlebox that requires keepalives. If the base either a HIP NOTIFY packet or, alternatively, an ICMPv6 echo request
exchange or mobility handover procedure occurs during an extremely inside the related ESP tunnel. If the base exchange or mobility
slow path, a host MAY also send HIP notify packets every 15 seconds handover procedure occurs during an extremely slow path, a host MAY
to keep to path active. also send HIP notify packets every 15 seconds to keep to path active
with the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP and the related security The two-way procedure for closing a HIP and the related security
associations is defined in [RFC7401]. One hosts initiates the associations is defined in [RFC7401]. One hosts initiates the
procedure by sending a CLOSE party and the recipient confirms it with procedure by sending a CLOSE party and the recipient confirms it with
CLOSE_ACK. All packets are protected using HMACs and signatures, and CLOSE_ACK. All packets are protected using HMACs and signatures, and
the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to
protect against replay attacks. protect against replay attacks.
skipping to change at page 26, line 11 skipping to change at page 29, line 11
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 relay checks if there is
a permission with matching information (address, protocol, port and a permission with matching information (address, protocol, port and
SPI values). If there is no such permission, a new permission MUST SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
permissions 1 minute before the expiration when the permission is permissions 1 minute before the expiration when the permission is
still needed. still needed.
When a data relay receives an UPDATE from a registered client but
without a PEER_PERMISSION parameter and with a new locator set, the
relay can assume that the mobile host has changed it's location and,
thus, is not reachable in its previous location. In such an event,
the data relay SHOULD deactivate the permission 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 the base exchange and after a handover. Unless parameter both after a base exchange and after a handover procedure
activated, the data relay MUST drop all ESP packets. with another ICE-HIP-UDP capable host. Unless activated, the data
relay MUST drop all ESP packets. It is worth noting that a relay
client does not have to renew its registration upon a change of
location UPDATE, but only when the lifetime of the 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 HIP data relay accepts to relay UDP encapsulated ESP between a
registered host and its peer, the relay opens a UDP port (relayed registered host and its peer, the relay opens a UDP port (relayed
address) for this purpose as described in Section 4.1. This port can address) for this purpose as described in Section 4.1. This port can
be used for delivering also control packets because connectivity be used for delivering also control packets because connectivity
checks also cover the path through the data relay. If the data relay checks also cover the path through the data relay. If the data relay
receives a UDP encapsulated HIP control packet on that port, it MUST receives a UDP encapsulated HIP control packet on that port, it MUST
forward the packet to the registered host and add a RELAY_FROM forward the packet to the registered host and add a RELAY_FROM
skipping to change at page 33, line 31 skipping to change at page 36, line 31
| Locator | Variable | Locator lifetime in seconds | | Locator | Variable | Locator lifetime in seconds |
| Lifetime | | | | Lifetime | | |
| Transport | Variable | Transport layer port number | | Transport | Variable | Transport layer port number |
| Port | | | | Port | | |
| Transport | Variable | IANA assigned, transport layer Internet | | Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. | | | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-ice-rfc5245bis] | | | | [I-D.ietf-ice-rfc5245bis]. It is worth |
| | | noting that while the priority of a single |
| | | locator candidate is 32-bits, but an |
| | | implementation should use a 64-bit integer |
| | | to calculate the priority of a candidate |
| | | pair for the ICE priority algorithm. |
| SPI | Variable | Security Parameter Index (SPI) value that | | SPI | Variable | Security Parameter Index (SPI) value that |
| | | 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 [RFC5770], the RELAY_HMAC parameter value has the TLV
type 65520. It has the same semantics as RVS_HMAC type 65520. It has the same semantics as RVS_HMAC [RFC8004].
[I-D.ietf-hip-rfc5204-bis].
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 [I-D.ietf-hip-rfc5203-bis] values for HIP relay Registration Type [RFC8003] values for HIP relay server registration.
server registration. The value for RELAY_UDP_HIP is 2 as specified The value for RELAY_UDP_HIP is 2 as specified in [RFC5770].
in [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 HIP 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 [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
skipping to change at page 39, line 26 skipping to change at page 42, line 36
appears to all the peers, and their firewalls, that all the appears to all the peers, and their firewalls, that all the
registered hosts using the relay are at the same address. Thus, a registered hosts using the relay are at the same address. Thus, a
stateful firewall may allow packets pass from hosts that would not stateful firewall may allow packets pass from hosts that would not
normally be able to send packets to a peer behind the firewall. normally be able to send packets to a peer behind the firewall.
Therefore, a HIP data relay SHOULD NOT re-use the port numbers. If Therefore, a HIP data relay SHOULD NOT re-use the port numbers. If
port numbers need to be re-used, the relay SHOULD have a sufficiently port numbers need to be re-used, the relay SHOULD have a sufficiently
large pool of port numbers and select ports from the pool randomly to large pool of port numbers and select ports from the pool randomly to
decrease the chances of a registered host obtaining the same address decrease the chances of a registered host obtaining the same address
that a another host behind the same firewall is using. that a another host behind the same firewall is using.
6.6. Amplification attacks
A malign host may send an invalid list of candidates for its peer
that are used for targeting a victim host by flooding it with
connectivity checks. To mitigate the attack, this protocol adopts
the ICE mechanism to cap the total amount of connectivity checks as
defined in section Section 4.7.
6.7. Attacks against Connectivity Checks and Candidate Gathering
Section 13.1 in [I-D.ietf-ice-rfc5245bis] discusses about attacks
against ICE connectivity checks. HIP bases its control plane
security on Diffie-Hellman key exchange, public keys and Hashed
Message Authentication codes, meaning that the mentioned security
concerns do not apply to HIP either. The mentioned section discusses
also of man-in-the-middle replay attacks that are difficult to
prevent. The connectivity checks in this protocol are immune against
replay attacks because a connectivity request includes a random nonce
that the recipient must sign and send back as a response.
Section 13.2 in [I-D.ietf-ice-rfc5245bis] discusses attacks on server
reflexive address gathering. Similarly here, if DNS, HIP relay or
HIP data relay server has been compromised, not much can be done.
However, the case where attacker can inject fake messages (located on
a shared network segment like Wifi) does not apply here. HIP
messages are integrity and replay protected, so it is not possible
inject fake server reflexive address candidates.
Section 13.3 in [I-D.ietf-ice-rfc5245bis] discusses attacks on
relayed candidate gathering. Similarly as ICE TURN servers, data
relays require an authenticated base exchange that protects relayed
address gathering against fake requests and responses. Further,
replay attacks are not possible because the HIP base exchange (and
also 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 also updates the IANA Registry for HIP NAT traversal This document also updates the IANA Registry for HIP NAT traversal
modes [RFC5770] by assigning value for the NAT traversal mode ICE- modes [RFC5770] by assigning value for the NAT traversal mode ICE-
HIP-UDP (defined in Section 5.4). HIP-UDP (defined in Section 5.4).
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow Registration Extension [RFC8003] that allow registering with a HIP
registering with a HIP relay server for ESP relaying service: relay server for ESP relaying service: RELAY_UDP_ESP (defined in
RELAY_UDP_ESP (defined in Section 4.1; and performing server Section 4.1; and performing server reflexive candidate discovery:
reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in CANDIDATE_DISCOVERY (defined in Section 4.2).
Section 4.2).
ICE specifications discuss "Unilateral Self-Address Fixing" in
section 17 in [I-D.ietf-ice-rfc5245bis]. This protocol is based on
ICE, and thus the same considerations apply also here with one
exception: this protocol does not hide binary IP addresses from
application-level gateways.
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 40, line 34 skipping to change at page 44, line 40
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[I-D.ietf-hip-rfc5203-bis] [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
Registration Extension", draft-ietf-hip-rfc5203-bis-10 October 2016, <http://www.rfc-editor.org/info/rfc8003>.
(work in progress), January 2016.
[I-D.ietf-hip-rfc5204-bis] [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work October 2016, <http://www.rfc-editor.org/info/rfc8004>.
in progress), December 2015.
[I-D.ietf-hip-rfc5206-bis] [I-D.ietf-hip-rfc5206-bis]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-12 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-14
(work in progress), May 2016. (work in progress), October 2016.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP) Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators", Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010, RFC 5770, DOI 10.17487/RFC5770, April 2010,
<http://www.rfc-editor.org/info/rfc5770>. <http://www.rfc-editor.org/info/rfc5770>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
skipping to change at page 41, line 32 skipping to change at page 45, line 32
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Ker&#52292;nen, A., Holmberg, C., and J. Rosenberg, Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
"Interactive Connectivity Establishment (ICE): A Protocol Connectivity Establishment (ICE): A Protocol for Network
for Network Address Translator (NAT) Traversal", draft- Address Translator (NAT) Traversal", draft-ietf-ice-
ietf-ice-rfc5245bis-03 (work in progress), June 2016. rfc5245bis-05 (work in progress), October 2016.
10.2. Informative References 10.2. Informative References
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>. 2006, <http://www.rfc-editor.org/info/rfc4423>.
[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,
skipping to change at page 42, line 11 skipping to change at page 46, line 11
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 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>. <http://www.rfc-editor.org/info/rfc5766>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/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-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
skipping to change at page 43, line 11 skipping to change at page 47, line 16
relay server registration exchange to complete; this would give an relay server registration exchange to complete; this would give an
estimate on the registering host's access link's RTT. Also, the I1/ estimate on the registering host's access link's RTT. Also, the I1/
R1 exchange could be used for estimating the RTT, but since the R1 R1 exchange could be used for estimating the RTT, but since the R1
can be cached in the network, or the relaying service can increase can be cached in the network, or the relaying service can increase
the delay notably, it is not recommended. the delay notably, it is not recommended.
Appendix B. Base Exchange through a Rendezvous Server Appendix B. Base Exchange through a Rendezvous Server
When the Initiator looks up the information of the Responder from When the Initiator looks up the information of the Responder from
DNS, it's possible that it discovers a rendezvous server (RVS) record DNS, it's possible that it discovers a rendezvous server (RVS) record
[I-D.ietf-hip-rfc5204-bis]. In this case, if the Initiator uses NAT [RFC8004]. In this case, if the Initiator uses NAT traversal methods
traversal methods described in this document, it MAY use its own HIP described in this document, it MAY use its own HIP relay server to
relay server to forward HIP traffic to the rendezvous server. The forward HIP traffic to the rendezvous server. The Initiator will
Initiator will send the I1 packet using its HIP relay server, which send the I1 packet using its HIP relay server, which will then
will then forward it to the RVS server of the Responder. In this forward it to the RVS server of the Responder. In this case, the
case, the value of the protocol field in the RELAY_TO parameter MUST value of the protocol field in the RELAY_TO parameter MUST be IP
be IP since RVS does not support UDP-encapsulated base exchange since RVS does not support UDP-encapsulated base exchange packets.
packets. The Responder will send the R1 packet directly to the The Responder will send the R1 packet directly to the Initiator's HIP
Initiator's HIP relay server and the following I2 and R2 packets are relay server and the following I2 and R2 packets are also sent
also sent directly using the relay. directly using the relay.
In case the Initiator is not able to distinguish which records are In case the Initiator is not able to distinguish which records are
RVS address records and which are Responder's address records (e.g., RVS address records and which are Responder's address records (e.g.,
if the DNS server did not support HIP extensions), the Initiator if the DNS server did not support HIP extensions), the Initiator
SHOULD first try to contact the Responder directly, without using a SHOULD first try to contact the Responder directly, without using a
HIP relay server. If none of the addresses are reachable, it MAY try HIP relay server. If none of the addresses are reachable, it MAY try
them out using its own HIP relay server as described above. them out using its own HIP relay server as described above.
Appendix C. Differences to ICE
The protocol specified in this document follows the semantics of ICE
as close as possible, and most of the differences are syntactical due
to the use of a different protocol. In this section, we describe the
differences to the ICE protocol.
o ICE operates at the application layer, where as this protocol
operates between transport and network layers, thus hiding the
protocol details from the application.
o STUN protocol is not employed. Instead, this protocol reuses the
HIP control plane format in order simplify demultiplexing of
different protocols. For example, STUN binding response is
replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN
parameter and STUN binding response with a HIP UPDATE messages
containing an ECHO_RESPONSE_SIGNED parameter as defined in section
Section 4.6.
o TURN protocol is not utilized. Instead, this protocol reuses HIP
relay servers for the same purpose.
o ICMP errors may be used in ICE to signal failure. In this
protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for
credentials, this protocol uses the public key derived HIT for the
same purpose. The username fragments are "transient host
identifiers, bound to a particular session established as part of
the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In HIP, a
local public key and the derived HIT are considered long-term
identifiers, and invariant across different host associations and
different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the
same controlling role is solved using random values (co called
tie-breaker value). In this protocol, the conflict is solved by
the standard HIP base exchange procedure, where the host with the
"larger" HIT switches to Responder role, thus changing also to
controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks.
o The foundation concept is unnecessary in this protocol because
only a single UDP flow for the IPsec tunnel will be negotiated.
o Frozen candidates are omitted for the same reason as foundation
concept is excluded.
o Components are omitted for the same reason as foundation concept
is excluded.
o This protocol supports only "full ICE" where the two communicating
hosts participate actively to the connectivity checks, and the
"lite" mode is not supported. This design decision follows the
guidelines of ICE which recommends full ICE implementations.
However, it should be noted that a publicly reachable Responder
may refuse to negotiate the ICE mode as described in
Section 4.7.2. This would result in a [RFC7401] based base
exchange tunneled over UDP followed ESP traffic over the same
tunnel, without the connectivity check procedures defined in this
document (in some sense, this mode corresponds to the case where
two ICE lite implementations connect since no connectivity checks
are sent).
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
candidates are not employed here.
o The considerations on Diffserve Codepoint markings in ICE are not
applicable to HIP since Diffserve is not used in HIP.
o Unlike in ICE, the addresses are not xorred in this protocol in
order to avoid middlebox tampering.
o This protocol does not employ the ICE related address and related
port attributes (that are used for diagnostic or SIP purposes).
Appendix D. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the
extensions in this protocol extends and differs from [RFC7401] and
[I-D.ietf-hip-rfc5206-bis].
o Both control and data plane are operated on top of UDP, not
directly on IP.
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
over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has
not been designed to be used in NATted scenarios because it just
relays the first I1 packet and does not employ UDP
encapsulation.HIP relay forwards all control traffic and, hence,
is more suitable in NATted environments. Further, the data relay
concept guarantees forwarding of data plane traffic also in the
cases when the NAT penetration procedures fail.
o Registration procedures with a relay server are similar as with
rendezvous server. However, a relay has different registration
parameters than rendezvous because it offers a different service.
Also, the relay includes also a REG_FROM parameter that informs
the client about its server reflexive address. In the case of a
data relay, it includes also a RELAYED_ADDRESS containing the
relayed address for the client.
o In [RFC7401], the Initiator and Responder can start to exchange
application payload immediately after the base exchange. While
exchanging data immediately after a base exchange via a data relay
would be possible also here, we follow the ICE methodology to
establish a direct path between two hosts using connectivity
checks. This means that there will be some additional delay after
the base exchange before application payload can be transmitted.
The same applies for the UPDATE procedure as the connectivity
checks introduce some additional delay.
o In HIP without NAT traversal support, the base exchange acts as an
implicit connectivity check, and the mobility and multihoming
extensions support explicit connectivity checks. After a base
exchange or UPDATE based connectivity checks, a host can use the
associated address pair for transmitting application payload. In
this extension, we follow the ICE methodology, where one end-point
acting in the controlled role chooses the used address pair also
on behalf of the other end-point acting in controlled role, which
is different from HIP without NAT traversal support. Another
difference is that the process of choosing an address pair is
explicitly signaled using the nomination packets. The nomination
process in this protocol supports only single address pair, and
multihoming extensions are left for further study.
o The UPDATE procedure resembles the mobility extensions defined in
[I-D.ietf-hip-rfc5206-bis]. The first UPDATE message from the
mobile host is exactly the same as in the mobility extensions.
The second UPDATE message from the peer host and third from the
mobile host are different in the sense that they merely
acknowledge and conclude the reception of the candidates through
the relay. In other words, they do not yet test for connectivity
(besides reachability through the HIP relay) unlike in the
mobility extensions. The idea is that connectivity check
procedure follows the ICE specification, which is somewhat
different from the HIP mobility extensions.
o The connectivity checks as defined in the mobility extensions
[I-D.ietf-hip-rfc5206-bis] are triggered only by the peer of the
mobile host. Since successful NAT penetration requires that both
end-points test connectivity, both the mobile host and its peer
host have to test for connectivity. In addition, this protocol
validates also the UDP ports; the ports in the connectivity check
must match with the response, as required by ICE.
o In HIP mobility extensions [I-D.ietf-hip-rfc5206-bis], an outbound
locator has some associated state: UNVERIFIED mean that the
locator has not been tested for reachability, ACTIVE means that
the address has been verified for reachability and is being used
actively, and DEPRECATED means that the locator lifetime has
expired. In the subset of ICE specifications used by this
protocol, an individual address candidate has only two properties:
type and priority. Instead, the actual state in ICE is associated
with candidate pairs rather than individual addresses. The subset
of ICE specifications utilized by this protocol require the
following attributes for a candidate pair: valid bit, nominated
bit, base and the state of connectivity check. The connectivity
checks have the following states: Waiting, In-progress, Succeeded
and Failed. Handling of this state attribute requires some
additional logic when compared to the mobility extensions since
the state is associated with a local-remote address pair rather
just a remote address, and the states of the different
specification do not have an unambiguous one-to-one mappings.
o Credit-based authorization as defined in
[I-D.ietf-hip-rfc5206-bis] could be used before candidate
nomination has been concluded upon discovering working candidate
pairs. However, this may result in the use of asymmetric paths
for a short time period in the beginning of communications
(similarly as in aggressive ICE nomination). Thus, support
credit-based authorization is left for further study.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 67 change blocks. 
226 lines changed or deleted 614 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/