draft-ietf-hip-native-nat-traversal-17.txt   draft-ietf-hip-native-nat-traversal-18.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: August 19, 2017 Ericsson Expires: September 14, 2017 Ericsson
February 15, 2017 March 13, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-17 draft-ietf-hip-native-nat-traversal-18
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 August 19, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 20 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 20
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 22 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 22
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 23 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 23
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 23 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 23
4.7.2. Base Exchange without Connectivity Checks . . . . . . 23 4.7.2. Base Exchange without Connectivity Checks . . . . . . 23
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 24 Encapsulation . . . . . . . . . . . . . . . . . . . . 24
4.8. Sending Control Packets after the Base Exchange . . . . . 25 4.8. Sending Control Packets after the Base Exchange . . . . . 25
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 29 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 31 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 31
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34
skipping to change at page 3, line 20 skipping to change at page 3, line 20
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 43 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 45
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 47 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 47
Appendix B. Base Exchange through a Rendezvous Server . . . . . 48 Appendix B. Base Exchange through a Rendezvous Server . . . . . 48
Appendix C. Differences to ICE . . . . . . . . . . . . . . . . . 48 Appendix C. Differences with respect to ICE . . . . . . . . . . 48
Appendix D. Differences to Base Exchange and UPDATE procedures . 50 Appendix D. Differences to Base Exchange and UPDATE procedures . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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.
HIP experiment report [RFC6538] mentions that Teredo based NAT The HIP experiment report [RFC6538] mentions that Teredo based NAT
traversal for HIP and related ESP traffic (with double tunneling traversal for HIP and related ESP traffic (with double tunneling
overhead). Two HIP specific NAT traversal techniques for HIP are overhead). Two HIP specific NAT traversal techniques for HIP are
specified in [RFC5770]. One of them uses only UDP encapsulation, specified in [RFC5770]. One of them uses only UDP encapsulation,
while the other uses also the Interactive Connectivity Establishment while the other uses also the Interactive Connectivity Establishment
(ICE) [I-D.ietf-ice-rfc5245bis] protocol, which in turn uses Session (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 may be able to do something "smart" when they see STUN being used for
for NAT traversal. However, implementing a full ICE/STUN/TURN NAT traversal. However, implementing a full ICE/STUN/TURN protocol
protocol stack results in a considerable amount of effort and code stack results in a considerable amount of effort and code which could
which could be avoided by re-using and extending HIP messages and be avoided by re-using and extending HIP messages and state machines
state machines for the same purpose. Thus, this document specifies for the same purpose. Thus, this document specifies an alternative
an alternative NAT traversal mode that uses HIP messages instead of NAT traversal mode that uses HIP messages instead of STUN for the
STUN for the connectivity check keepalives and data relaying. This connectivity check keepalives and data relaying. This document also
document also specifies how mobility management works in the context specifies how mobility management works in the context of NAT
of NAT traversal, which was missing from [RFC5770]. traversal, which was missing from [RFC5770].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The
following terms recur in the text: following terms recur in the text:
skipping to change at page 10, line 10 skipping to change at page 10, line 10
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 When a registered client sends an UPDATE (e.g., due to host movement
or the renew service registration), the relay server MUST follow the or to renew service registration), the relay server MUST follow the
general guidelines defined in [RFC8003], with the difference that all general guidelines defined in [RFC8003], with the difference that all
UPDATE messages are delivered on top of UDP. In addition to this, UPDATE messages are delivered on top of UDP. In addition to this,
the relay server MUST include the REG_FROM parameter in all UPDATE the relay server MUST include the REG_FROM parameter in all UPDATE
responses sent to the client. This applies both renewals of service responses sent to the client. This applies both renewals of service
registration but also to host movement, where especially the latter registration but also to host movement, where especially the latter
requires the client to learn its new server reflexive address requires the client to learn its new server reflexive address
candidate. candidate.
4.2. Transport Address Candidate Gathering 4.2. Transport Address Candidate Gathering
skipping to change at page 10, line 46 skipping to change at page 10, line 46
parameter discovered during the relay registration as a server parameter discovered during the relay registration as a server
reflexive candidate. In this case, no further candidate gathering is reflexive candidate. In this case, no further candidate gathering is
needed. 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 were 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 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 in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host
candidates (loopback, anycast and others) should excluded as candidates (loopback, anycast and others) should excluded as
described in section 4.1.1.1 of the ICE document. Relayed candidates described in section 4.1.1.1 of the ICE specification
SHOULD be gathered in order to guarantee successful NAT traversal. [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in
It is RECOMMENDED for implementations to support this functionality order to guarantee successful NAT traversal. It is RECOMMENDED for
even if it will not be used in deployments in order to enable it by implementations to support this functionality even if it will not be
software configuration update if needed at some point. A host SHOULD used in deployments in order to enable it by software configuration
employ only a relay server for gathering the candidates for a single update if needed at some point. A host SHOULD employ only a relay
HIP association; either a one server providing both HIP and data server for gathering the candidates for a single HIP association;
relay functionality, or one HIP relay server and another one for data either a one server providing both HIP and data relay functionality,
relaying if the functionality is offered by another server. When the or one HIP relay server and another one for data relaying if the
relay service is split between two hosts, the server reflexive functionality is offered by another server. When the relay service
candidate from the HIP relay SHOULD be used instead of the one is split between two hosts, the server reflexive candidate from the
provided by the data relay. If a relayed candidate is identical to a HIP relay SHOULD be used instead of the one provided by the data
host candidate, the relayed candidate must be discarded. NAT64 relay. If a relayed candidate is identical to a host candidate, the
considerations in section 4.1.1.2 in the ICE document apply as well. relayed candidate must be discarded. NAT64 considerations in section
4.1.1.2 of [I-D.ietf-ice-rfc5245bis] apply as well.
HIP based connectivity can be utilized by IPv4 applications using HIP based connectivity can be utilized by IPv4 applications using
LSIs and by IPv6 based applications using HITs. The LSIs and HITs of LSIs and by IPv6 based applications using HITs. The LSIs and HITs of
the local virtual interfaces MUST be excluded in the candidate the local virtual interfaces MUST be excluded in the candidate
gathering phase as well to avoid creating unnecessary loopback gathering phase as well to avoid creating unnecessary loopback
connectivity tests. connectivity tests.
Gathering of candidates MAY also be performed as specified in Gathering of candidates MAY also be performed 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
skipping to change at page 12, line 30 skipping to change at page 12, line 31
server, it would be 1). A smaller value than 500 ms for the RTO MUST server, it would be 1). A smaller value than 500 ms for the RTO MUST
NOT be used. NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical (as defined in document. As the parameter is non-critical (as defined in
Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which
means that the host does not support or is not willing to use these means that the host is not required to support it or may decline to
extensions. use it.
With registration with a HIP relay, it is usually sufficient to use With registration with a HIP relay, it is usually sufficient to use
the UDP-ENCAPSULATION mode of NAT traversal since the relay is the UDP-ENCAPSULATION mode of NAT traversal since the relay is
assumed to be in public address space. Thus, the relay SHOULD assumed to be in public address space. Thus, the relay SHOULD
propose the UDP-ENCAPSULATION mode as the preferred or only mode. propose the UDP-ENCAPSULATION mode as the preferred or only mode.
The NAT traversal mode negotiation in a HIP base exchange is The NAT traversal mode negotiation in a HIP base exchange is
illustrated in Figure 3. It is worth noting that the HIP relay could illustrated in Figure 3. It is worth noting that the HIP relay could
be located between the hosts, but omitted here for simplicity. be located between the hosts, but is omitted here for simplicity.
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+--------------------------------------------------------------->| +--------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) |
|<---------------------------------------------------------------+ |<---------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) |
+--------------------------------------------------------------->| +--------------------------------------------------------------->|
skipping to change at page 14, line 6 skipping to change at page 14, line 6
As explained in [RFC5770], when a NAT traversal mode with As explained in [RFC5770], when a NAT traversal mode with
connectivity checks is used, new transactions should not be started connectivity checks is used, new transactions should not be started
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 of the two offered values.
The minimum Ta value SHOULD be configurable, and if no value is The minimum Ta value SHOULD be configurable, and if no value is
configured, a value of 50 ms MUST be used. Guidelines for selecting configured, a value of 50 ms MUST be used. Guidelines for selecting
a Ta value are given in Appendix A. Hosts SHOULD NOT use values a Ta value are given in Appendix A. Hosts SHOULD NOT use values
smaller than 5 ms for the minimum Ta, since such values may not work smaller than 5 ms for the minimum Ta, since such values may not work
well with some NATs, as explained in [I-D.ietf-ice-rfc5245bis]. The well with some NATs, as explained in [I-D.ietf-ice-rfc5245bis]. The
Initiator MUST NOT propose a smaller value than what the Responder Initiator MUST NOT propose a smaller value than what the Responder
offered. If a host does not include the TRANSACTION_PACING parameter offered. If a host does not include the TRANSACTION_PACING parameter
in the base exchange, a Ta value of 50 ms MUST be used as that host's in the base exchange, a Ta value of 50 ms MUST be used as that host's
minimum value. minimum value.
skipping to change at page 17, line 44 skipping to change at page 17, line 44
throughout the HIP associate lifetime (to be reused in the possibly throughout the HIP associate lifetime (to be reused in the possibly
mobility UPDATE procedures). In the case both communicating nodes mobility UPDATE procedures). In the case both communicating nodes
are initiating the communications to each other using an I1 packet, are initiating the communications to each other using an I1 packet,
the conflict is resolved as defined in section 6.7 in [RFC7401]: the 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 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 a case, the host changing its role to Responder MUST also switch to
controlling role. controlling role.
The protocol follows standard HIP UPDATE sending and processing rules The protocol follows standard HIP UPDATE sending and processing rules
as defined in section 6.11 and 6.12 in [RFC7401], but some new as defined in section 6.11 and 6.12 in [RFC7401], but some new
parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDR and parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and
NOMINATE). 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 It is worth noting that the message flow in this section is
idealistic, and, in practice, more messages would be dropped idealistic, and, in practice, more messages would be dropped,
especially in the beginning. For instance, connectivity tests always especially in the beginning. For instance, connectivity tests always
start with the candidates with the highest priority, which would be start with the candidates with the highest priority, which would be
host candidates (which would not reach the recipient in this host candidates (which would not reach the recipient in this
scenario). 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<-----------------------------------+----------------+
| | | | | | | |
skipping to change at page 19, line 14 skipping to change at page 19, line 14
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 in previous step and the message traverses address pair candidate as in the previous step, and the message
successfully the NAT boxes. The message includes the same parameters traverses successfully the NAT boxes. The message includes the same
as in the previous step. It should be noted that the sequence parameters as in the previous step. It should be noted that the
identifier is locally assigned by the Responder, so it can be sequence identifier is locally assigned by the Responder, so it can
different than in the previous step. 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 (denoted
transport address of the Initiator as observed by the Responder (i.e. MAPPED_ADDR in the figure) that contains the transport address of the
peer reflexive candidate). This message is successfully delivered to Initiator as observed by the Responder (i.e. peer reflexive
the Initiator, and upon reception the Initiator marks the candidate candidate). This message is successfully delivered to the Initiator,
pair as valid. and upon reception the Initiator marks the candidate pair as valid.
In step 4, the Responder retransmits the connectivity check sent in In step 4, the Responder retransmits the connectivity check sent in
the first step since it was not acknowledged yet. the first step since it was not acknowledged yet.
In step 5, the Initiator responds to the previous connectivity check In step 5, the Initiator responds to the previous connectivity check
message from the Responder. The Initiator acknowledges the SEQ message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the parameter from the previous message using ACK parameter and the
ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition, ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition,
it includes MAPPED_ADDR parameter that includes the peer reflexive it includes MAPPED_ADDR parameter that includes the peer reflexive
candidate. This response message is successfully delivered to the candidate. This response message is successfully delivered to the
Responder, and upon reception the Initiator marks the candidate pair Responder, and upon reception the Initiator marks the candidate pair
as valid. as valid.
In step 6, despite the two hosts have now valid address candidates, In step 6, despite the two hosts now having valid address candidates,
they still test the remaining address candidates in a similar way as the hosts still test the remaining address candidates in a similar
in the previous steps (due to the use of normal nomination). It way as in the previous steps (due to the use of normal nomination).
should be noted that each connectivity check has an unique sequence It should be noted that each connectivity check has an unique
number in the SEQ parameter. sequence number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates 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 8, 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
skipping to change at page 21, line 12 skipping to change at page 21, line 12
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A generate a response, and then continue waiting for the candidates. A
host MUST NOT select a candidate pair until it has verified the pair host MUST NOT select a candidate pair until it has verified the pair
using a connectivity check as defined in section Section 4.6.1. using a connectivity check as defined in section Section 4.6.1.
[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 be 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.
As specified in [RFC7401], an ACK parameter may acknowledge multiple As specified in [RFC7401], an ACK parameter may acknowledge multiple
sequence identifiers. While the examples in the previous sections do sequence identifiers. While the examples in the previous sections do
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode. 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 check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some be sent with the same sequence identifier in the SEQ parameter. Some
of tested address candidates will never produce a working address tested address candidates will never produce a working address pair,
pair, and thus may cause retransmissions. Upon successful nomination and thus may cause retransmissions. Upon successful nomination an
an address pair, a host MAY immediately stop sending such address pair, a host MAY immediately stop sending such
retransmissions. retransmissions.
ICE procedures for prioritizing candidates, eliminating redundant ICE procedures for prioritizing candidates, eliminating redundant
candidates and forming check lists (including pruning) MUST be candidates and forming check lists (including pruning) MUST be
followed as specified in [I-D.ietf-ice-rfc5245bis], with the followed as specified in [I-D.ietf-ice-rfc5245bis], with the
exception that the foundation, frozen candidates and default exception that the foundation, frozen candidates and default
candidates are not used. From viewpoint of ICE specification, the candidates are not used. From viewpoint of the ICE specification
protocol specified in this document operates using Component ID of 1 [I-D.ietf-ice-rfc5245bis], the protocol specified in this document
on all candidates, and the foundation of all candidates is unique. operates using Component ID of 1 on all candidates, and the
This specification defines only "full ICE" mode, and the "lite ICE" foundation of all candidates is unique. This specification defines
is not supported. The reasoning behind for the missing features is only "full ICE" mode, and the "lite ICE" is not supported. The
described in Appendix C). reasoning behind for the missing features is described in Appendix C.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
neither one of the hosts announced a minimum pacing value, a value of neither one of the hosts announced a minimum pacing value, a value of
20 ms SHOULD be used. 20 ms SHOULD be used.
Both hosts MUST form a priority ordered checklist and start to check Both hosts MUST form a priority ordered checklist and start to check
transactions every Ta milliseconds as long as the checks are running transactions every Ta milliseconds as long as the checks are running
and there are candidate pairs whose tests have not started. The and there are candidate pairs whose tests have not started. The
retransmission timeout (RTO) for the connectivity check UPDATE retransmission timeout (RTO) for the connectivity check UPDATE
skipping to change at page 22, line 26 skipping to change at page 22, line 26
value that would be assigned to a peer reflexive candidate if one was value that would be assigned to a peer reflexive candidate if one was
learned from the corresponding check. An UPDATE packet that learned from the corresponding check. An UPDATE packet that
acknowledges a connectivity check request MUST be sent from the same acknowledges a connectivity check request MUST be sent from the same
address that received the check and delivered to the same address address that received the check and delivered to the same address
where the check was received from. Each acknowledgment UPDATE packet where the check was received from. Each acknowledgment UPDATE packet
MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and
IP address of the address where the connectivity check request was IP address of the address where the connectivity check request was
received from. received from.
Following ICE guidelines [I-D.ietf-ice-rfc5245bis], it is RECOMMENDED Following ICE guidelines [I-D.ietf-ice-rfc5245bis], it is RECOMMENDED
to restrict total number of connectivity checks to 100 for each host to restrict the total number of connectivity checks to 100 for each
association. This can be achieved by limiting the connectivity host association. This can be achieved by limiting the connectivity
checks to the 100 candidate pairs with the highest priority. checks to the 100 candidate pairs with the highest priority.
4.6.3. Rules for Concluding Connectivity Checks 4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence UPDATE message that contains a SEQ parameter (with new sequence
number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate
in a CAND_PRIO parameter and NOMINATE parameter to signify concluding in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify
of the connectivity checks. Since the nominated address pair has conclusion of the connectivity checks. Since the nominated address
been already tested for reachability, the controlled host should be pair has already been tested for reachability, the controlled host
able to receive the message. Upon reception, the controlled host should be able to receive the message. Upon reception, the
SHOULD select the nominated address pair. The response message MUST controlled host SHOULD select the nominated address pair. The
include a SEQ parameter with a new sequence id, acknowledgment of the response message MUST include a SEQ parameter with a new sequence id,
sequence is from the controlling host in an ACK parameter, a new acknowledgment of the sequence from the controlling host in an ACK
ECHO_REQ_SIGN parameter, ECHO_RESP_SIGNED parameter corresponding to parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED
the ECHO_REQUEST_SIGN parameter from the controlling host and the parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the
NOMINATE parameter. After sending this packet, the controlled host controlling host and the NOMINATE parameter. After sending this
can create IPsec security associations using the nominated address packet, the controlled host can create IPsec security associations
candidate for delivering application payload to the controlling host. using the nominated address candidate for delivering application
Since the message from the controlled host included a new sequence id payload to the controlling host. Since the message from the
and echo request for signature, the controlling host MUST acknowledge controlled host included a new sequence id and echo request for
this with a new UPDATE message that includes an ACK and signature, the controlling host MUST acknowledge this with a new
ECHO_RESPONSE_SIGNED parameters. After this final concluding UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED
message, also the controlling host can create IPsec security parameters. After this final concluding message, the controlling
associations for delivering application payload to the controlled host also can create IPsec security associations for delivering
host. application payload to the controlled host.
It is possible that packets are delayed by the network. Both host It is possible that packets are delayed by the network. Both hosts
MUST continue to respond to any connectivity checks despite an MUST continue to respond to any connectivity checks despite an
address pair has been nominated. address pair having been nominated.
If all the connectivity checks have failed, the hosts MUST NOT send If all the connectivity checks have failed, the hosts MUST NOT send
ESP traffic to each other but MAY continue communicating using HIP ESP traffic to each other but MAY continue communicating using HIP
packets and the locators used for the base exchange. Also, the hosts packets and the locators used for the base exchange. Also, the hosts
SHOULD notify each other about the failure with a SHOULD notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
4.7. NAT Traversal Alternatives 4.7. NAT Traversal 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 over UDP without including any NAT traversal mode parameter.
of the base exchange follows the procedures defined in [RFC7401], The rest of the base exchange follows the procedures defined in
except that the control and data plane use UDP encapsulation. Here, [RFC7401], except that the control and data plane use UDP
the use of UDP for NAT traversal is agreed implicitly. This way of encapsulation. Here, the use of UDP for NAT traversal is agreed
operation is still subject to NAT timeouts, and the hosts MUST employ implicitly. This way of operation is still subject to NAT timeouts,
NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in section 4.8 in [RFC5770]. The procedure is applicable as defined in 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 25, line 15 skipping to change at page 25, line 15
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly, without The I1 packet without UDP encapsulation may arrive directly, without
any relays, at the Responder. When this happens, the procedures in 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. retransmissions of the original R1 message MUST be ignored.
The I1 packet without UDP encapsulation may also arrive at a HIP- The I1 packet without UDP encapsulation may also arrive at a HIP-
capable middlebox. When the middlebox is a HIP rendezvous server and capable middlebox. When the middlebox is a HIP rendezvous server and
the Responder has successfully registered with the rendezvous the Responder has successfully registered with the rendezvous
service, the middlebox follows rendezvous procedures in [RFC8004]. service, the middlebox follows rendezvous procedures in [RFC8004].
If the Initiator receives a NAT traversal mode parameter in R1 If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter without UDP encapsulation, the Initiator MAY ignore this parameter
and send an I2 without UDP encapsulation and without any selected NAT and send an I2 without UDP encapsulation and without any selected NAT
traversal mode. When the Responder receives the I2 without UDP traversal mode. When the Responder receives the I2 without UDP
skipping to change at page 27, line 42 skipping to change at page 27, line 42
belonging to the peer host. In the packet, the source IP address belonging to the peer host. In the packet, the source IP address
belongs to the mobile host and the destination to the HIP relay. The belongs to the mobile host and the destination to the HIP relay. The
packet contains an ESP_INFO parameter, where, in this case, the OLD packet contains an ESP_INFO parameter, where, in this case, the OLD
SPI and NEW SPI parameters both contain the pre-existing incoming SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The packet also contains the locators of the mobile host in a SPI. The packet also contains the locators of the mobile host in a
LOCATOR_SET parameter. The packet contains also a SEQ number to be LOCATOR_SET parameter. The packet contains also a SEQ number to be
acknowledged by the peer. As specified in [RFC8046], the packet may acknowledged by the peer. As specified in [RFC8046], the packet may
also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN
parameter for rekeying. parameter for rekeying.
In step 2, HIP relay receives the UPDATE packet and forwards it to In step 2, the HIP relay receives the UPDATE packet and forwards it
the peer host (i.e. relay client). The HIP relay rewrites the to the peer host (i.e. relay client). The HIP relay rewrites the
destination IP address and appends a RELAY_FROM parameter to the destination IP address and appends a RELAY_FROM parameter to the
message. message.
In step 3, the peer host receives the UPDATE packet, processes it and In step 3, the peer host receives the UPDATE packet, processes it and
responds with another UPDATE message. The message is destined to the responds with another UPDATE message. The message is destined to the
HIT of mobile host and to the IP address of the HIP relay. The HIT of mobile host and to the IP address of the HIP relay. The
message includes an ESP_INFO parameter where, in this case, the OLD message includes an ESP_INFO parameter where, in this case, the OLD
SPI and NEW SPI parameters both contain the pre-existing incoming SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGN parameters to SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters
be acknowledged by the mobile host. The message acknowledges the SEQ to be acknowledged by the mobile host. The message acknowledges the
parameter of the earlier message with an ACK parameter. After this SEQ parameter of the earlier message with an ACK parameter. After
step, the peer host can initiate the connectivity checks. this step, the peer host can initiate the connectivity checks.
In step 4, the HIP relay receives the message, rewrites the In step 4, the HIP relay receives the message, rewrites the
destination IP address, appends an RELAY_TO parameter and forwards destination IP address, appends an RELAY_TO parameter and forwards
the modified message to the mobile host. When mobile host has the modified message to the mobile host. When mobile host has
processed the message successfully, it can initiate the connectivity processed the message successfully, it can initiate the connectivity
checks. checks.
In step 5, the two hosts test for connectivity across NATs according In step 5, the two hosts test for connectivity across NATs according
to procedures described in Section 4.6. The original Initiator of to procedures described in Section 4.6. The original Initiator of
the communications is the controlling and the original Responder is the communications is the controlling and the original Responder is
skipping to change at page 28, line 34 skipping to change at page 28, line 34
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 with which they have established a
associating with. Both a registered client and relay server SHOULD host associating. Both a registered client and relay server SHOULD
send a HIP NOTIFY packets to each other every 15 seconds (the so send HIP NOTIFY packets to each other every 15 seconds (the so called
called Tr value in ICE) unless they have exchange some other traffic Tr value in ICE) unless they have exchange some other traffic over
over the used UDP ports. Other values MAY be used, but a Tr value the used UDP ports. Other values MAY be used, but a Tr value smaller
smaller than 15 seconds MUST NOT be used. Likewise, if a host has than 15 seconds MUST NOT be used. Likewise, if a host has not sent
not sent any data to another host it has established a host any data to another host it has established a host association in the
association in the ICE-HIP_UDP mode within 15 seconds, it MUST send ICE-HIP_UDP mode within 15 seconds, it MUST send either a HIP NOTIFY
either a HIP NOTIFY packet or, alternatively, an ICMPv6 echo request packet or, alternatively, an ICMPv6 echo request inside the related
inside the related ESP tunnel. If the base exchange or mobility ESP tunnel. If the base exchange or mobility handover procedure
handover procedure occurs during an extremely slow path, a host MAY occurs during an extremely slow path, a host MAY also send HIP NOTIFY
also send HIP notify packets every 15 seconds to keep to path active packet every 15 seconds to keep the path active with the recipient.
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 association and the related
associations is defined in [RFC7401]. One hosts initiates the security associations is defined in [RFC7401]. One host initiates
procedure by sending a CLOSE party and the recipient confirms it with the procedure by sending a CLOSE message and the recipient confirms
CLOSE_ACK. All packets are protected using HMACs and signatures, and it with CLOSE_ACK. All packets are protected using HMACs and
the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED
protect against replay attacks. parameter to protect against replay attacks.
The same procedure for closing HIP associations applies also here, The same procedure for closing HIP associations applies also here,
but the messaging occurs using the UDP encapsulated tunnel that the but the messaging occurs using the UDP encapsulated tunnel that the
two hosts employ. A host sending the CLOSE message SHOULD first send two hosts employ. A host sending the CLOSE message SHOULD first send
the message over a direct link. After a number of retransmissions, the message over a direct link. After a number of retransmissions,
it MUST send over a HIP relay of the recipient if one exists. The it MUST send over a HIP relay of the recipient if one exists. The
host receiving the CLOSE message directly without a relay SHOULD host receiving the CLOSE message directly without a relay SHOULD
respond directly. The CLOSE message came via a relay, it SHOULD respond directly. If CLOSE message came via a relay, the host SHOULD
respond using the same relay. respond using the same relay.
4.12. Relaying Considerations 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions 4.12.1. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before the data relay forwards any ESP data packets from a peer to a before the data relay forwards any ESP data packets from a peer to a
registered host (or the other direction), the client MUST set a registered host (or the other direction), the client MUST set a
permission for the peer's address. The permissions also install a permission for the peer's address. The permissions also install a
skipping to change at page 30, line 13 skipping to change at page 30, line 9
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 When a data relay receives an UPDATE from a registered client but
without a PEER_PERMISSION parameter and with a new locator set, the 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, relay can assume that the mobile host has changed its location and,
thus, is not reachable in its previous location. In such an event, thus, is not reachable in its previous location. In such an event,
the data relay SHOULD deactivate the permission and stop relaying the data relay SHOULD deactivate the permission and stop relaying
data plane traffic to the client. data plane traffic to the client.
The relayed address MUST be activated with the PEER_PERMISSION The relayed address MUST be activated with the PEER_PERMISSION
parameter both after a base exchange and after a handover procedure parameter both after a base exchange and after a handover procedure
with another ICE-HIP-UDP capable host. Unless activated, the data with another ICE-HIP-UDP capable host. Unless activated, the data
relay MUST drop all ESP packets. It is worth noting that a relay relay MUST drop all ESP packets. It is worth noting that a relay
client does not have to renew its registration upon a change of client does not have to renew its registration upon a change of
location UPDATE, but only when the lifetime of the registration is location UPDATE, but only when the lifetime of the registration is
skipping to change at page 30, line 35 skipping to change at page 30, line 31
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
parameter to the packet as if the data relay was acting as a HIP parameter to the packet as if the data relay were acting as a HIP
relay server. When the registered host replies to a control packet relay server. When the registered host replies to a control packet
with a RELAY_FROM parameter via its relay, the registered host MUST with a RELAY_FROM parameter via its relay, the registered host MUST
add a RELAY_TO parameter containing the peer's address and use the add a RELAY_TO parameter containing the peer's address and use the
address of its data relay as the destination address. Further, the address of its data relay as the destination address. Further, the
data relay MUST send this packet to the peer's address from the data relay MUST send this packet to the peer's address from the
relayed address. relayed address.
If the data relay receives a UDP packet that is not a HIP control If the data relay receives a UDP packet that is not a HIP control
packet to the relayed address, it MUST check if it has a permission packet to the relayed address, it MUST check if it has a permission
set for the peer the packet is arriving from (i.e., the sender's set for the peer the packet is arriving from (i.e., the sender's
skipping to change at page 31, line 9 skipping to change at page 31, line 9
permissions are set, the data relay MUST forward the packet to the permissions are set, the data relay MUST forward the packet to the
registered host that created the permission. The data relay MUST registered host that created the permission. The data relay MUST
also implement the similar checks for the reverse direction (i.e. also implement the similar checks for the reverse direction (i.e.
ESP packets from the registered host to the peer). Packets without a ESP packets from the registered host to the peer). Packets without a
permission MUST be dropped silently. permission MUST be dropped silently.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
The inbound SPI values of the registered clients should be unique so The inbound SPI values of the registered clients should be unique so
that a data relay can properly demultiplex incoming packets from peer that a data relay can properly demultiplex incoming packets from peer
hosts to the correct registered clients. Vice versa, the inbound hosts to the correct registered clients. Likewise, the inbound SPIs
SPIs of the peer hosts should be unique for the same reason. These of the peer hosts should be unique for the same reason. These two
two cases are discussed in this section separately. cases are discussed in this section separately.
In first case, the SPI collision problem occurs when two Initiators In first case, the SPI collision problem occurs when two Initiators
run a base exchange to the same Responder (i.e. registered host), and run a base exchange to the same Responder (i.e. registered host), and
both the Initiators claim the same inbound SPI. This is not a both the Initiators claim the same inbound SPI. This is not a
problem for Responder since the two Initiators can be distinguished problem for Responder since the two Initiators can be distinguished
by their transport addresses. However, it is an issue for the data by their transport addresses. However, it is an issue for the data
relay because the it cannot demultiplex packets from the Initiator to relay because the it cannot demultiplex packets from the Initiator to
the correct Responder. Thus, upon receiving an I2 with a colliding the correct Responder. Thus, upon receiving an I2 with a colliding
SPI, the Responder MUST NOT include the relayed address candidate in SPI, the Responder MUST NOT include the relayed address candidate in
the R2 message because the data relay would not be able demultiplex the R2 message because the data relay would not be able demultiplex
skipping to change at page 31, line 41 skipping to change at page 31, line 41
a new relayed address candidate upon SPI collisions. Each relayed a new relayed address candidate upon SPI collisions. Each relayed
address has a separate UDP port reserved to it, so the relay can address has a separate UDP port reserved to it, so the relay can
demultiplex properly conflicting SPIs of the Initiators based on the demultiplex properly conflicting SPIs of the Initiators based on the
SPI and port number towards the correct Responder. SPI and port number towards the correct Responder.
In the second case, the SPI collision problems occurs if two hosts In the second case, the SPI collision problems occurs if two hosts
have registered to the same data relay and a third host initiates have registered to the same data relay and a third host initiates
base exchange with both of them. In this case, the data relay has base exchange with both of them. In this case, the data relay has
allocated separate UDP ports for the two registered hosts acting now allocated separate UDP ports for the two registered hosts acting now
as Responders. When the Responders send identical SPI values in as Responders. When the Responders send identical SPI values in
their I2 messages via the relay, it can properly demultiplex it to their I2 messages via the relay, the relay can properly deliver the
the correct Responder because the UDP ports are different. message to the correct Responder because the UDP ports are different.
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be in network byte for the HIP and ESP packets. All values MUST be in network byte
order. order.
It is worth noting that most of the parameters are shown for It is worth noting that most of the parameters are shown for the sake
completeness sake even though they are specified already in of completeness even though they are specified already in [RFC5770].
[RFC5770]. New parameters are explicitly described as new. New parameters are explicitly described as new.
5.1. HIP Control Packets 5.1. HIP Control Packets
Figure 7 illustrates the packet format for UDP-encapsulated HIP. The Figure 7 illustrates the packet format for UDP-encapsulated HIP. The
format is identical to [RFC5770]. format is identical to [RFC5770].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
skipping to change at page 32, line 27 skipping to change at page 32, line 27
| 32 bits of zeroes | | 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of UDP-Encapsulated HIP Control Packets Figure 7: Format of UDP-Encapsulated HIP Control Packets
HIP control packets are encapsulated in UDP packets as defined in HIP control packets are encapsulated in UDP packets as defined in
Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except
different port number is used. Figure 7 illustrates the that a different port number is used. Figure 7 illustrates the
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC7401] with HIP header and parameters follow the conventions of [RFC7401] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
already contains a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC7401] includes the IP addresses in the checksum calculation. The [RFC7401] includes the IP addresses in the checksum calculation. The
NATs unaware of HIP cannot recompute the HIP checksum after changing NATs that are unaware of HIP cannot recompute the HIP checksum after
IP addresses. changing IP addresses.
A HIP relay server or a Responder without a relay SHOULD listen at A HIP relay server or a Responder without a relay SHOULD listen at
UDP port 10500 for incoming UDP-encapsulated HIP control packets. If UDP port 10500 for incoming UDP-encapsulated HIP control packets. If
some other port number is used, it needs to be known by potential some other port number is used, it needs to be known by potential
Initiators. Initiators.
5.2. Connectivity Checks 5.2. Connectivity Checks
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
skipping to change at page 33, line 15 skipping to change at page 33, line 15
5.3. Keepalives 5.3. Keepalives
The keepalives are either HIP NOTIFY packets as specified in The keepalives are either HIP NOTIFY packets as specified in
[RFC7401] or ICMPv6 packets inside the ESP tunnel. [RFC7401] or ICMPv6 packets inside the ESP tunnel.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from The format of NAT traversal mode parameter is borrowed from
[RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar
to the format of the ESP_TRANSFORM parameter in [RFC7402] and is to the format of the ESP_TRANSFORM parameter in [RFC7402] and is
shown in Figure 8. This specification defines traversal mode shown in Figure 8. This specification defines the traversal mode
identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
[RFC5770]. The identifier named RESERVED is reserved for future use. [RFC5770]. The identifier named RESERVED is reserved for future use.
Future specifications may define more traversal modes. Future specifications may define more traversal modes.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 | | Reserved | Mode ID #1 |
skipping to change at page 34, line 27 skipping to change at page 34, line 27
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta | | Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 610 Type 610
Length 4 Length 4
Min Ta the minimum connectivity check transaction pacing Min Ta the minimum connectivity check transaction pacing
value the host would use value the host would use (in milliseconds)
Figure 9: Format of the TRANSACTION_PACING Parameter Figure 9: Format of the TRANSACTION_PACING Parameter
5.6. Relay and Registration Parameters 5.6. Relay and Registration Parameters
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
shown in Figure 10. All parameters are identical except for the shown in Figure 10. All parameters are identical except for the
type. REG_FROM is the only parameter covered with the signature. type. REG_FROM is the only parameter covered with the signature.
0 1 2 3 0 1 2 3
skipping to change at page 36, line 38 skipping to change at page 36, line 38
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | | Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: LOC_SET Parameter Figure 11: LOCATOR_SET Parameter
The individual fields in the LOCATOR_SET parameter are described in The individual fields in the LOCATOR_SET parameter are described in
Table 1. Table 1.
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose | | Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type | | Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and | | Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding | | | | Length fields and padding |
skipping to change at page 41, line 47 skipping to change at page 41, line 47
Type [TBD by IANA; 4710] Type [TBD by IANA; 4710]
Length 4 Length 4
Reserved Reserved for future extension purposes Reserved Reserved for future extension purposes
Figure 15: Format of the NOMINATE Parameter Figure 15: Format of the NOMINATE Parameter
6. Security Considerations 6. Security Considerations
The security considerations are the same as in [RFC5770], but are The security considerations are the same as in [RFC5770], but are
repeated here for completeness sake. repeated here for the sake of completeness.
6.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in plain text format in favor of inspection at HIP- The locators are in plain text format in favor of inspection at HIP-
aware middleboxes in the future. The current document does not aware middleboxes in the future. The current document does not
specify encrypted versions of LOCATOR_SETs, even though it could be specify encrypted versions of LOCATOR_SETs, even though it could be
beneficial for privacy reasons to avoid disclosing them to beneficial for privacy reasons to avoid disclosing them to
middleboxes. middleboxes.
It is also possible that end-users may not want to reveal all It is also possible that end-users may not want to reveal all
skipping to change at page 43, line 38 skipping to change at page 43, line 38
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 6.6. Amplification attacks
A malign host may send an invalid list of candidates for its peer A malicious host may send an invalid list of candidates for its peer
that are used for targeting a victim host by flooding it with that are used for targeting a victim host by flooding it with
connectivity checks. To mitigate the attack, this protocol adopts connectivity checks. To mitigate the attack, this protocol adopts
the ICE mechanism to cap the total amount of connectivity checks as the ICE mechanism to cap the total amount of connectivity checks as
defined in section Section 4.7. defined in section Section 4.7.
6.7. Attacks against Connectivity Checks and Candidate Gathering 6.7. Attacks against Connectivity Checks and Candidate Gathering
Section 13.1 in [I-D.ietf-ice-rfc5245bis] discusses about attacks Section 13.1 in [I-D.ietf-ice-rfc5245bis] discusses about attacks
against ICE connectivity checks. HIP bases its control plane against ICE connectivity checks. HIP bases its control plane
security on Diffie-Hellman key exchange, public keys and Hashed security on Diffie-Hellman key exchange, public keys and Hashed
Message Authentication codes, meaning that the mentioned security Message Authentication codes, meaning that the mentioned security
concerns do not apply to HIP either. The mentioned section discusses concerns do not apply to HIP either. The mentioned section discusses
also of man-in-the-middle replay attacks that are difficult to also of man-in-the-middle replay attacks that are difficult to
prevent. The connectivity checks in this protocol are immune against prevent. The connectivity checks in this protocol are immune against
replay attacks because a connectivity request includes a random nonce replay attacks because a connectivity request includes a random nonce
that the recipient must sign and send back as a response. that the recipient must sign and send back as a response.
Section 13.2 in [I-D.ietf-ice-rfc5245bis] discusses attacks on server Section 13.2 in [I-D.ietf-ice-rfc5245bis] discusses attacks on server
reflexive address gathering. Similarly here, if DNS, HIP relay or reflexive address gathering. Similarly here, if the DNS, a HIP relay
HIP data relay server has been compromised, not much can be done. or a HIP data relay server has been compromised, not much can be
However, the case where attacker can inject fake messages (located on done. However, the case where attacker can inject fake messages
a shared network segment like Wifi) does not apply here. HIP (located on a shared network segment like Wifi) does not apply here.
messages are integrity and replay protected, so it is not possible HIP messages are integrity and replay protected, so it is not
inject fake server reflexive address candidates. possible inject fake server reflexive address candidates.
Section 13.3 in [I-D.ietf-ice-rfc5245bis] discusses attacks on Section 13.3 in [I-D.ietf-ice-rfc5245bis] discusses attacks on
relayed candidate gathering. Similarly as ICE TURN servers, data relayed candidate gathering. Similarly to ICE TURN servers, data
relays require an authenticated base exchange that protects relayed relays require an authenticated base exchange that protects relayed
address gathering against fake requests and responses. Further, address gathering against fake requests and responses. Further,
replay attacks are not possible because the HIP base exchange (and replay attacks are not possible because the HIP base exchange (and
also UPDATE procedure) is protected against replay attacks. 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
skipping to change at page 47, line 47 skipping to change at page 47, line 47
Selecting a suitable value for the connectivity check transaction Selecting a suitable value for the connectivity check transaction
pacing is essential for the performance of connectivity check-based pacing is essential for the performance of connectivity check-based
NAT traversal. The value should not be so small that the checks NAT traversal. The value should not be so small that the checks
cause network congestion or overwhelm the NATs. On the other hand, a cause network congestion or overwhelm the NATs. On the other hand, a
pacing value that is too high makes the checks last for a long time, pacing value that is too high makes the checks last for a long time,
thus increasing the connection setup delay. thus increasing the connection setup delay.
The Ta value may be configured by the user in environments where the The Ta value may be configured by the user in environments where the
network characteristics are known beforehand. However, if the network characteristics are known beforehand. However, if the
characteristics are not known, it is recommended that the value is characteristics are not known, it is recommended that the value is
adjusted dynamically. In this case, it's recommended that the hosts adjusted dynamically. In this case, it is recommended that the hosts
estimate the round-trip time (RTT) between them and set the minimum estimate the round-trip time (RTT) between them and set the minimum
Ta value so that only two connectivity check messages are sent on Ta value so that only two connectivity check messages are sent on
every RTT. every RTT.
One way to estimate the RTT is to use the time it takes for the HIP One way to estimate the RTT is to use the time that it takes for the
relay server registration exchange to complete; this would give an HIP relay server registration exchange to complete; this would give
estimate on the registering host's access link's RTT. Also, the I1/ an estimate on the registering host's access link's RTT. Also, the
R1 exchange could be used for estimating the RTT, but since the R1 I1/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, this 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 is possible that it discovers a rendezvous server (RVS)
[RFC8004]. In this case, if the Initiator uses NAT traversal methods record [RFC8004]. In this case, if the Initiator uses NAT traversal
described in this document, it MAY use its own HIP relay server to methods described in this document, it MAY use its own HIP relay
forward HIP traffic to the rendezvous server. The Initiator will server to forward HIP traffic to the rendezvous server. The
send the I1 packet using its HIP relay server, which will then Initiator will send the I1 packet using its HIP relay server, which
forward it to the RVS server of the Responder. In this case, the will then forward it to the RVS server of the Responder. In this
value of the protocol field in the RELAY_TO parameter MUST be IP case, the value of the protocol field in the RELAY_TO parameter MUST
since RVS does not support UDP-encapsulated base exchange packets. be IP since RVS does not support UDP-encapsulated base exchange
The Responder will send the R1 packet directly to the Initiator's HIP packets. The Responder will send the R1 packet directly to the
relay server and the following I2 and R2 packets are also sent Initiator's HIP relay server and the following I2 and R2 packets are
directly using the relay. also sent 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 Appendix C. Differences with respect to ICE
The protocol specified in this document follows the semantics of ICE The protocol specified in this document follows the semantics of ICE
as close as possible, and most of the differences are syntactical due 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 to the use of a different protocol. In this section, we describe the
differences to the ICE protocol. differences to the ICE protocol.
o ICE operates at the application layer, where as this protocol o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o STUN protocol is not employed. Instead, this protocol reuses the o The STUN protocol is not employed. Instead, this protocol reuses
HIP control plane format in order simplify demultiplexing of the HIP control plane format in order simplify demultiplexing of
different protocols. For example, STUN binding response is different protocols. For example, the STUN binding response is
replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN
parameter and STUN binding response with a HIP UPDATE messages parameter and the STUN binding response with a HIP UPDATE message
containing an ECHO_RESPONSE_SIGNED parameter as defined in section containing an ECHO_RESPONSE_SIGNED parameter as defined in section
Section 4.6. Section 4.6.
o TURN protocol is not utilized. Instead, this protocol reuses HIP o The TURN protocol is not utilized. Instead, this protocol reuses
relay servers for the same purpose. HIP relay servers for the same purpose.
o ICMP errors may be used in ICE to signal failure. In this o ICMP errors may be used in ICE to signal failure. In this
protocol, HIP NOTIFY messages are used instead. protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for o Instead of the ICE username fragment and password mechanism for
credentials, this protocol uses the public key derived HIT for the credentials, this protocol uses the HIT, derived from a public
same purpose. The username fragments are "transient host key, for the same purpose. The username fragments are "transient
identifiers, bound to a particular session established as part of host identifiers, bound to a particular session established as
the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In HIP, a part of the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In
local public key and the derived HIT are considered long-term HIP, a local public key and the derived HIT are considered long-
identifiers, and invariant across different host associations and term identifiers, and invariant across different host associations
different transport-layer flows. and different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the o In ICE, the conflict when two communicating end-points take the
same controlling role is solved using random values (so called same controlling role is solved using random values (so called
tie-breaker value). In this protocol, the conflict is solved by tie-breaker value). In this protocol, the conflict is solved by
the standard HIP base exchange procedure, where the host with the the standard HIP base exchange procedure, where the host with the
"larger" HIT switches to Responder role, thus changing also to "larger" HIT switches to Responder role, thus changing also to
controlled role. controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks. in the connectivity checks.
skipping to change at page 49, line 45 skipping to change at page 49, line 45
o Components are omitted for the same reason as foundation concept o Components are omitted for the same reason as foundation concept
is excluded. is excluded.
o This protocol supports only "full ICE" where the two communicating o This protocol supports only "full ICE" where the two communicating
hosts participate actively to the connectivity checks, and the hosts participate actively to the connectivity checks, and the
"lite" mode is not supported. This design decision follows the "lite" mode is not supported. This design decision follows the
guidelines of ICE which recommends full ICE implementations. guidelines of ICE which recommends full ICE implementations.
However, it should be noted that a publicly reachable Responder However, it should be noted that a publicly reachable Responder
may refuse to negotiate the ICE mode as described in may refuse to negotiate the ICE mode as described in
Section 4.7.2. This would result in a [RFC7401] based base Section 4.7.2. This would result in a [RFC7401] based HIP base
exchange tunneled over UDP followed ESP traffic over the same exchange tunneled over UDP followed ESP traffic over the same
tunnel, without the connectivity check procedures defined in this tunnel, without the connectivity check procedures defined in this
document (in some sense, this mode corresponds to the case where document (in some sense, this mode corresponds to the case where
two ICE lite implementations connect since no connectivity checks two ICE lite implementations connect since no connectivity checks
are sent). are sent).
o As the "ICE lite" is not adopted here and both sides are capable o As the "ICE lite" is not adopted here and both sides are capable
of ICE-HIP-HIP mode (negotiated during the base exchange), default of ICE-HIP-HIP mode (negotiated during the base exchange), default
candidates are not employed here. candidates are not employed here.
o The considerations on Diffserve Codepoint markings in ICE are not o The considerations on Diffserv Codepoint markings in ICE are not
applicable to HIP since Diffserve is not used in HIP. applicable to HIP since Diffserv is not used in HIP.
o Unlike in ICE, the addresses are not xorred in this protocol in o Unlike in ICE, the addresses are not XOR-ed in this protocol in
order to avoid middlebox tampering. order to avoid middlebox tampering.
o This protocol does not employ the ICE related address and related o This protocol does not employ the ICE related address and related
port attributes (that are used for diagnostic or SIP purposes). port attributes (that are used for diagnostic or SIP purposes).
Appendix D. Differences to Base Exchange and UPDATE procedures Appendix D. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers how the
extensions in this protocol extends and differs from [RFC7401] and extensions in this protocol extends and differs from [RFC7401] and
[RFC8046]. [RFC8046].
skipping to change at page 50, line 34 skipping to change at page 50, line 34
o Both control and data plane are operated on top of UDP, not o Both control and data plane are operated on top of UDP, not
directly on IP. directly on IP.
o A minimal implementation would conform only to Section 4.7.1 or o A minimal implementation would conform only to Section 4.7.1 or
Section 4.7.2, thus merely tunneling HIP control and data traffic Section 4.7.2, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address. cases where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has o It is worth noting that while a rendezvous server [RFC8004] has
not been designed to be used in NATted scenarios because it just not been designed to be used in NATted scenarios because it just
relays the first I1 packet and does not employ UDP relays the first I1 packet and does not employ UDP encapsulation,
encapsulation.HIP relay forwards all control traffic and, hence, the HIP relay forwards all control traffic and, hence, is more
is more suitable in NATted environments. Further, the data relay suitable in NATted environments. Further, the data relay concept
concept guarantees forwarding of data plane traffic also in the guarantees forwarding of data plane traffic also in the cases when
cases when the NAT penetration procedures fail. the NAT penetration procedures fail.
o Registration procedures with a relay server are similar as with o Registration procedures with a relay server are similar as with
rendezvous server. However, a relay has different registration rendezvous server. However, a relay has different registration
parameters than rendezvous because it offers a different service. parameters than rendezvous because it offers a different service.
Also, the relay includes also a REG_FROM parameter that informs Also, the relay includes also a REG_FROM parameter that informs
the client about its server reflexive address. In the case of a the client about its server reflexive address. In the case of a
data relay, it includes also a RELAYED_ADDRESS containing the data relay, it includes also a RELAYED_ADDRESS containing the
relayed address for the client. relayed address for the client.
o In [RFC7401], the Initiator and Responder can start to exchange o In [RFC7401], the Initiator and Responder can start to exchange
skipping to change at page 52, line 11 skipping to change at page 52, line 11
address candidate has only two properties: type and priority. address candidate has only two properties: type and priority.
Instead, the actual state in ICE is associated with candidate Instead, the actual state in ICE is associated with candidate
pairs rather than individual addresses. The subset of ICE pairs rather than individual addresses. The subset of ICE
specifications utilized by this protocol require the following specifications utilized by this protocol require the following
attributes for a candidate pair: valid bit, nominated bit, base attributes for a candidate pair: valid bit, nominated bit, base
and the state of connectivity check. The connectivity checks have and the state of connectivity check. The connectivity checks have
the following states: Waiting, In-progress, Succeeded and Failed. the following states: Waiting, In-progress, Succeeded and Failed.
Handling of this state attribute requires some additional logic Handling of this state attribute requires some additional logic
when compared to the mobility extensions since the state is when compared to the mobility extensions since the state is
associated with a local-remote address pair rather just a remote associated with a local-remote address pair rather just a remote
address, and the states of the different specification do not have address, and, thus, the mobility and ICE states do not have an
an unambiguous one-to-one mappings. unambiguous one-to-one mapping.
o Credit-based authorization as defined in [RFC8046] could be used o Credit-based authorization as defined in [RFC8046] could be used
before candidate nomination has been concluded upon discovering before candidate nomination has been concluded upon discovering
working candidate pairs. However, this may result in the use of working candidate pairs. However, this may result in the use of
asymmetric paths for a short time period in the beginning of asymmetric paths for a short time period in the beginning of
communications (similarly as in aggressive ICE nomination). Thus, communications (similarly as in aggressive ICE nomination). Thus,
support credit-based authorization is left for further study. support of 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. 63 change blocks. 
191 lines changed or deleted 191 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/