draft-ietf-hip-native-nat-traversal-30.txt   draft-ietf-hip-native-nat-traversal-31.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 24, 2020 Ericsson Expires: October 25, 2020 Ericsson
February 21, 2020 April 23, 2020
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-30 draft-ietf-hip-native-nat-traversal-31
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 instead of ICE for all NAT traversal procedures due to its messages instead of ICE for all NAT traversal procedures due to the
kernel-space dependencies. kernel-space dependencies of HIP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 24, 2020. This Internet-Draft will expire on October 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 38 skipping to change at page 2, line 38
4.8. Sending Control Packets after the Base Exchange . . . . . 29 4.8. Sending Control Packets after the Base Exchange . . . . . 29
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 40
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 40
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41
5.6. Relay and Registration Parameters . . . . . . . . . . . . 41 5.6. Relay and Registration Parameters . . . . . . . . . . . . 42
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 43
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 45
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50
6.3. Base Exchange Replay Protection for Control Relay Server 50 6.3. Base Exchange Replay Protection for Control Relay Server 50
6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . 53 10.1. Normative References . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . 55 10.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 56 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 57
Appendix B. Differences with respect to ICE . . . . . . . . . . 57 Appendix B. Differences with respect to ICE . . . . . . . . . . 58
Appendix C. Differences to Base Exchange and UPDATE procedures . 59 Appendix C. Differences to Base Exchange and UPDATE procedures . 60
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 62 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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, NATs usually require the host
host behind a NAT to create a forwarding state in the NAT before behind a NAT to create a forwarding state in the NAT before other
other hosts outside of the NAT can contact the host behind the NAT. hosts outside of the NAT can contact the host behind the NAT. To
To overcome this problem, different methods, commonly referred to as overcome this problem, different methods, commonly referred to as NAT
NAT traversal techniques, have been developed. traversal techniques, have been developed.
As one solution, the HIP experiment report [RFC6538] mentions Teredo- As one solution, the HIP experiment report [RFC6538] mentions Teredo-
based NAT traversal for HIP and related ESP traffic (with double based NAT traversal for HIP and related ESP traffic (with double
tunneling overhead). Another solution is specified in [RFC5770], tunneling overhead). Another solution is specified in [RFC5770],
which will be referred as "Legacy ICE-HIP" in this document. The which will be referred to "Legacy ICE-HIP" in this document. The
experimental Legacy ICE-HIP specification combines Interactive experimental Legacy ICE-HIP specification combines Interactive
Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that
basically ICE is responsible for NAT traversal and connectivity basically ICE is responsible for NAT traversal and connectivity
testing, while HIP is responsible for end-host authentication and testing, while HIP is responsible for end-host authentication and
IPsec key management. The resulting protocol uses HIP, STUN and ESP IPsec key management. The resulting protocol uses HIP, STUN and ESP
messages tunneled over a single UDP flow. The benefit of using ICE messages tunneled over a single UDP flow. The benefit of using ICE
and its STUN/TURN messaging formats is that one can re-use the NAT and its STUN/TURN messaging formats 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
may be able to do something "smart" when they see STUN being used for may be able to do something "smart" when they see STUN being used for
NAT traversal. NAT traversal.
HIP poses a unique challenge to using standard ICE, due not only to HIP poses a unique challenge to using standard ICE, due not only to
its kernel-space implementation, but also due to its close kernel-space dependencies of HIP, but also due to its close
integration with kernel-space IPSec; and, that while [RFC5770] integration with kernel-space IPSec; and, that while [RFC5770]
provides a technically workable path, it incurs unacceptable provides a technically workable path, it incurs unacceptable
performance drawbacks for kernel-space implementations. Also, performance drawbacks for kernel-space implementations. Also,
implementing and integrating a full ICE/STUN/TURN protocol stack as implementing and integrating a full ICE/STUN/TURN protocol stack as
specified in Legacy ICE-HIP results in a considerable amount of specified in Legacy ICE-HIP results in a considerable amount of
effort and code which could be avoided by re-using and extending HIP effort and code which could be avoided by re-using and extending HIP
messages and state machines for the same purpose. Thus, this messages and state machines for the same purpose. Thus, this
document specifies an alternative NAT traversal mode referred as document specifies an alternative NAT traversal mode referred as
"Native ICE-HIP" that employs HIP messaging format instead of STUN or "Native ICE-HIP" that employs HIP messaging format instead of STUN or
TURN for the connectivity checks, keepalives and data relaying. TURN for the connectivity checks, keepalives and data relaying.
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document borrows terminology from [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[RFC8046], [RFC4423], [RFC8445], and [RFC5389]. The following terms [RFC8046], [I-D.ietf-hip-rfc4423-bis], [RFC8445], and [RFC5389]. The
recur in the text: following terms recur in the text:
ICE: ICE:
Interactive Connectivity Establishment (ICE) protocol as specified Interactive Connectivity Establishment (ICE) protocol as specified
in [RFC8445] in [RFC8445]
Legacy ICE-HIP: Legacy ICE-HIP:
Refers to the "Basic Host Identity Protocol (HIP) Extensions for Refers to the "Basic Host Identity Protocol (HIP) Extensions for
Traversal of Network Address Translators" as specified in Traversal of Network Address Translators" as specified in
[RFC5770]. The protocol specified in this document offers an [RFC5770]. The protocol specified in this document offers an
alternative to Legacy ICE-HIP. alternative to Legacy ICE-HIP.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
may simply be a network address." may simply be a network address."
LOCATOR_SET (written in capital letters): LOCATOR_SET (written in capital letters):
Denotes a HIP control packet parameter that bundles multiple Denotes a HIP control packet parameter that bundles multiple
locators together [RFC8046]. locators together [RFC8046].
HIP offer: HIP offer:
Before two end-hosts can establish a communication channel using Before two end-hosts can establish a communication channel using
the NAT traversal procedures defined in this document, they need the NAT traversal procedures defined in this document, they need
exchange their locators (i.e. candidates) with each other. In exchange their locators (i.e. candidates) with each other. In
ICE, this procedure is called Candidate Exchange and it does ICE, this procedure is called Candidate Exchange and it does not
specify how the candidates are exchanged but Session Description specify how the candidates are exchanged but Session Description
Protocol (SDP) "offer/answer" is mentioned as an example. In Protocol (SDP) "offer/answer" is mentioned as an example. In
contrast, the Candidate Exchange in HIP is the base exchange contrast, the Candidate Exchange in HIP is the base exchange
itself or a subsequent UPDATE prodecure occurring after a itself or a subsequent UPDATE prodecure occurring after a
handover. Following [RFC5770] and Session Description Protocol handover. Following [RFC5770] and SDP [RFC3264] naming
(SDP) [RFC3264] naming conventions, "HIP offer" is the the conventions, "HIP offer" is the the Initiator's LOCATOR_SET
Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE parameter in a HIP I2 or in an UPDATE control packet.
control packet.
HIP answer: HIP answer:
The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE
control packet. Corresponds to the SDP answer parameter control packet. Corresponds to the SDP answer parameter
[RFC3264], but is HIP specific. Please refer also to the longer [RFC3264], but is HIP specific. Please refer also to the longer
description of the "HIP offer" term above. description of the "HIP offer" term above.
HIP connectivity checks: HIP connectivity checks:
In order to obtain a direct end-to-end communication path (without In order to obtain a direct end-to-end communication path (without
skipping to change at page 8, line 51 skipping to change at page 8, line 51
+-------+ +-------+ +-------+ +-------+
| Init- | | Resp- | | Init- | | Resp- |
| iator | | onder | | iator | | onder |
+-------+ +-------+ +-------+ +-------+
Figure 1: Example Network Configuration Figure 1: Example Network Configuration
In the example configuration depicted in Figure 1, both Initiator and In the example configuration depicted in Figure 1, both Initiator and
Responder are behind one or more NATs, and both private networks are Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
at least the Responder must be registered with is own Control Relay at least the Responder must be registered with a Control Relay Server
Server reachable on the public Internet. The Responder may have also reachable on the public Internet. The Responder may have also
registered to a Data Relay Server that can forward the data plane in registered to a Data Relay Server that can forward the data plane in
case NAT traversal fails. While, strictly speaking, the Initiator case NAT traversal fails. While, strictly speaking, the Initiator
does not need a Data Relay Server, it may act in the other role with does not need a Data Relay Server, it may act in the other role with
other hosts, and connectivity with the Data Relay Server of the other hosts, and connectivity with the Data Relay Server of the
Responder may fail, so the Initiator may also need to register to a Responder may fail, so the Initiator may also need to register to a
Cotrol and/or Data Relay Server. It is worth noting that a Control Cotrol and/or Data Relay Server. It is worth noting that a Control
and Data Relay does not forge the source address of a passing packet, and Data Relay does not forge the source address of a passing packet,
but always translates the source address and source port of a packet but always translates the source address and source port of a packet
to be forwarded (to its own). to be forwarded (to its own).
skipping to change at page 11, line 45 skipping to change at page 11, line 45
In step 2, the Relay Server (Responder) lists the services that it In step 2, the Relay Server (Responder) lists the services that it
supports in the R1 packet. The support for HIP control plane over supports in the R1 packet. The support for HIP control plane over
UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP
(see Section 5.9). If the server supports also relaying of ESP (see Section 5.9). If the server supports also relaying of ESP
traffic over UDP, it includes also Registration type value traffic over UDP, it includes also Registration type value
RELAY_UDP_ESP. RELAY_UDP_ESP.
In step 3, the Relay Client selects the services for which it In step 3, the Relay Client selects the services for which it
registers and lists them in the REG_REQ parameter. The Relay Client registers and lists them in the REG_REQ parameter. The Relay Client
registers for the Control Data Relay service by listing the registers for the Control Relay service by listing the RELAY_UDP_HIP
RELAY_UDP_HIP value in the request parameter. If the Relay Client value in the request parameter. If the Relay Client requires also
requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP. ESP relaying over UDP, it lists also RELAY_UDP_ESP.
In step 4, the Relay Server concludes the registration procedure with In step 4, the Relay Server concludes the registration procedure with
an R2 packet and acknowledges the registered services in the REG_RES an R2 packet and acknowledges the registered services in the REG_RES
parameter. The Relay Server denotes unsuccessful registrations (if parameter. The Relay Server denotes unsuccessful registrations (if
any) in the REG_FAILED parameter of R2. The Relay Server also any) in the REG_FAILED parameter of R2. The Relay Server also
includes a REG_FROM parameter that contains the transport address of includes a REG_FROM parameter that contains the transport address of
the Relay Client as observed by the Relay Server (Server Reflexive the Relay Client as observed by the Relay Server (Server Reflexive
candidate). If the Relay Client registered to ESP relaying service, candidate). If the Relay Client registered to ESP relaying service,
the Relay Server includes RELAYED_ADDRESS parameter that describes the Relay Server includes RELAYED_ADDRESS parameter that describes
the UDP port allocated to the Relay Client for ESP relaying. It is the UDP port allocated to the Relay Client for ESP relaying. It is
skipping to change at page 13, line 8 skipping to change at page 13, line 8
A Data Relay Client can request multiple relayed candidates from the A Data Relay Client can request multiple relayed candidates from the
Data Relay Server (e.g., for the reasons described in Data Relay Server (e.g., for the reasons described in
Section 4.12.3). After the base exchange with registration, the Data Section 4.12.3). After the base exchange with registration, the Data
Relay Client can request additional relayed candidates similarly as Relay Client can request additional relayed candidates similarly as
during the base exchange. The Data Relay Client sends an UPDATE during the base exchange. The Data Relay Client sends an UPDATE
message REG_REQ parameter requesting for the RELAY_UDP_ESP service. message REG_REQ parameter requesting for the RELAY_UDP_ESP service.
The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED
parameter. The Data Relay Server MUST respond with an UPDATE message parameter. The Data Relay Server MUST respond with an UPDATE message
that includes the corresponding response parameters: REG_RES, ACK and that includes the corresponding response parameters: REG_RES, ACK and
ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new ECHO_REQUEST_SIGNED . In case the Data Relay Server allocated a new
relayed UDP port for the Data Relay Client, the REG_RES parameter relayed UDP port for the Data Relay Client, the REG_RES parameter
MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also
include a RELAYED_ADDRESS parameter describing the relayed UDP port. include a RELAYED_ADDRESS parameter describing the relayed UDP port.
The Data Relay Server MUST also include the Server Reflexive The Data Relay Server MUST also include the Server Reflexive
candidate in a REG_FROM parameter. It is worth mentioning that Data candidate in a REG_FROM parameter. It is worth mentioning that Data
Relay Client MUST activate the UDP port as described in Relay Client MUST activate the UDP port as described in
Section 4.12.1 before it can be used for any ESP relaying. Section 4.12.1 before it can be used for any ESP relaying.
A Data Relay Client may unregister a relayed candidate in two ways. A Data Relay Client may unregister a relayed candidate in two ways.
It can wait for its lifetime to expire or it can explicitly request It can wait for its lifetime to expire or it can explicitly request
it with zero lifetime using the UPDATE mechanism. The Data Relay it with zero lifetime using the UPDATE mechanism. The Data Relay
Client can send an REG_REQ parameter with zero lifetime to the Data Client can send an REG_REQ parameter with zero lifetime to the Data
Relay Server in order to expire all relayed candidates. To expire a Relay Server in order to expire all relayed candidates. To expire a
specific relayed candidate, the Data Relay Client MUST also include specific relayed candidate, the Data Relay Client MUST also include
RELAYED_ADDRESS parameter as sent by the server in the UPDATE RELAYED_ADDRESS parameter as sent by the server in the UPDATE
message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure
initiated by either party), the Data Relay Server MUST also expire initiated by either party), the Data Relay Server MUST also expire
all relayed candidates. all relayed candidates.
To avoid cross-protocol attacks associated with RELAY_HMAC and
RVS_HMAC, a Control Relay Server MUST NOT offer RENDEZVOUS
registration service [RFC8004] to any Control Relay Client.
4.2. Transport Address Candidate Gathering at the Relay Client 4.2. Transport Address Candidate Gathering at the Relay Client
An Initiator needs to gather a set of address candidates before An Initiator needs to gather a set of address candidates before
contacting a (non-relay) Responder. The candidates are needed for contacting a (non-relay) Responder. The candidates are needed for
connectivity checks that allow two hosts to discover a direct, non- connectivity checks that allow two hosts to discover a direct, non-
relayed path for communicating with each other. One server reflexive relayed path for communicating with each other. One server reflexive
candidate can be discovered during the registration with the Control candidate can be discovered during the registration with the Control
Relay Server from the REG_FROM parameter (and another from Data Relay Relay Server from the REG_FROM parameter (and another from Data Relay
Server if one is employed). Server if one is employed).
skipping to change at page 15, line 13 skipping to change at page 15, line 13
Data Relay Server are available. Data Relay Server are available.
Each local address candidate MUST be assigned a priority. The Each local address candidate MUST be assigned a priority. The
following recommended formula (as described in [RFC8445]) SHOULD be following recommended formula (as described in [RFC8445]) SHOULD be
used: used:
priority = (2^24)*(type preference) + (2^8)*(local preference) + priority = (2^24)*(type preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID) (2^0)*(256 - component ID)
In the formula, the type preference follows the ICE specification (as In the formula, the type preference follows the ICE specification (as
defined in section 5.1.2.2 in [RFC8445]): the RECOMMENDED values are defined in section 5.1.2.1 in [RFC8445]): the RECOMMENDED values are
126 for host candidates, 100 for server reflexive candidates, 110 for 126 for host candidates, 100 for server reflexive candidates, 110 for
peer reflexive candidates, and 0 for relayed candidates. The highest peer reflexive candidates, and 0 for relayed candidates. The highest
value is 126 (the most preferred) and lowest is 0 (last resort). For value is 126 (the most preferred) and lowest is 0 (last resort). For
all candidates of the same type, the preference type value MUST be all candidates of the same type, the preference type value MUST be
identical, and, correspondingly, the value MUST be different for identical, and, correspondingly, the value MUST be different for
different types. For peer reflexive values, the type preference different types. For peer reflexive values, the type preference
value MUST be higher than for server reflexive types. It should be value MUST be higher than for server reflexive types. It should be
noted that peer reflexive values are learned later during noted that peer reflexive values are learned later during
connectivity checks, so a host cannot employ it during candidate connectivity checks, so a host cannot employ it during candidate
gathering stage yet. gathering stage yet.
skipping to change at page 15, line 44 skipping to change at page 15, line 44
only a single component exists. Hence, the component ID value MUST only a single component exists. Hence, the component ID value MUST
always be set to 1. always be set to 1.
As defined in section 14.3 in [RFC8445], the retransmission timeout As defined in section 14.3 in [RFC8445], the retransmission timeout
(RTO) for address gathering from a Control/Data Relay Server SHOULD (RTO) for address gathering from a Control/Data Relay Server SHOULD
be calculated as follows: be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Of-Cands)) RTO = MAX (500ms, Ta * (Num-Of-Cands))
where Ta is the value used for the connectivity check pacing and Num- where Ta is the value used for the connectivity check pacing and Num-
Of-Cands is the sum of server-reflexive and relay candidates. A Of-Cands is the number of server-reflexive and relay candidates. A
smaller value than 500 ms for the RTO MUST NOT be used. smaller value than 500 ms for the RTO MUST NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a non-critical parameter type This section describes the usage of a non-critical parameter type
called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
presence of the parameter in a HIP base exchange means that the end- presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
host supports NAT traversal extensions described in this document. base exchange means that the end-host supports NAT traversal
extensions described in this document. As the parameter is non-
As the parameter is non-critical (as defined in Section 5.2.1 of critical (as defined in Section 5.2.1 of [RFC7401]), it can be
[RFC7401]), it can be ignored by a end-host, which means that the ignored by a end-host, which means that the host is not required to
host is not required to support it or may decline to use it. support it or may decline to use it.
With registration with a Control/Data Relay Server, it is usually With registration with a Control/Data Relay Server, it is usually
sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since
the Relay Server is assumed to be in public address space. Thus, the the Relay Server is assumed to be in public address space. Thus, the
Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the
preferred or only mode. The NAT traversal mode negotiation in a HIP preferred or only mode. The NAT traversal mode negotiation in a HIP
base exchange is illustrated in Figure 3. It is worth noting that base exchange is illustrated in Figure 3. It is worth noting that
the Relay Server could be located between the hosts, but is omitted the Relay Server could be located between the hosts, but is omitted
here for simplicity. here for simplicity.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
Initiator from the list of modes offered by the Responder. If ICE- Initiator from the list of modes offered by the Responder. If ICE-
HIP-UDP mode was selected, the I2 also includes the "Transport HIP-UDP mode was selected, the I2 also includes the "Transport
address" locators (as defined in Section 5.7) of the Initiator in a address" locators (as defined in Section 5.7) of the Initiator in a
LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP
mode, the LOCATOR_SET parameter MUST be encapsulated within an mode, the LOCATOR_SET parameter MUST be encapsulated within an
ENCRYPTED parameter (denoted here with ENC) according to the ENCRYPTED parameter (denoted here with ENC) according to the
procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in
I2 are the "HIP offer". I2 are the "HIP offer".
In step 4, the Responder concludes the base exchange with an R2 In step 4, the Responder concludes the base exchange with an R2
packet. If the Initiator chose ICE NAT traversal mode, the Responder packet. If the Initiator chose ICE-HIP-UDP traversal mode, the
includes a LOCATOR_SET parameter in the R2 packet. With ICE-HIP-UDP Responder includes a LOCATOR_SET parameter in the R2 packet. With
mode, the LOCATOR_SET parameter MUST be encapsulated within an ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated
ENCRYPTED parameter according to the procedures in sections 5.2.18 within an ENCRYPTED parameter according to the procedures in sections
and 6.5 in [RFC7401]. The locators in R2, encoded like the locators 5.2.18 and 6.5 in [RFC7401]. The locators in R2, encoded like the
in I2, are the "ICE answer". If the NAT traversal mode selected by locators in I2, are the "ICE answer". If the NAT traversal mode
the Initiator is not supported by the Responder, the Responder SHOULD selected by the Initiator is not supported by the Responder, the
reply with a NOTIFY packet with type Responder SHOULD reply with a NOTIFY packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
4.4. Connectivity Check Pacing Negotiation 4.4. Connectivity Check Pacing Negotiation
As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode
with connectivity checks is used, new transactions should not be with connectivity checks is used, new transactions should not be
started too fast to avoid congestion and overwhelming the NATs. For started too fast to avoid congestion and overwhelming the NATs. For
this purpose, during the base exchange, hosts can negotiate a this purpose, during the base exchange, hosts can negotiate a
transaction pacing value, Ta, using a TRANSACTION_PACING parameter in transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
R1 and I2 packets. The parameter contains the minimum time R1 and I2 packets. The parameter contains the minimum time
skipping to change at page 17, line 46 skipping to change at page 17, line 46
exchange, a Ta value of 50 ms MUST be used as that host's minimum exchange, a Ta value of 50 ms MUST be used as that host's minimum
value. value.
4.5. Base Exchange via Control Relay Server 4.5. Base Exchange via Control Relay Server
This section describes how the Initiator and Responder perform a base This section describes how the Initiator and Responder perform a base
exchange through a Control Relay Server. Connectivity pacing exchange through a Control Relay Server. Connectivity pacing
(denoted as TA_P here) was described in Section 4.4 and is not (denoted as TA_P here) was described in Section 4.4 and is not
repeated here. Similarly, the NAT traversal mode negotiation process repeated here. Similarly, the NAT traversal mode negotiation process
(denoted as NAT_TM in the example) was described in Section 4.3 and (denoted as NAT_TM in the example) was described in Section 4.3 and
is neither repeated here. If a Control Relay Server receives an R1 is also not repeated here. If a Control Relay Server receives an R1
or I2 packet without the NAT traversal mode parameter, it MUST drop or I2 packet without the NAT traversal mode parameter, it MUST drop
it and SHOULD send a NOTIFY error packet with type it and SHOULD send a NOTIFY error packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2.
It is RECOMMENDED that the Initiator send an I1 packet encapsulated It is RECOMMENDED that the Initiator send an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IP address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with a Respectively, the Responder MUST respond to such an I1 packet with a
UDP-encapsulated R1 packet, and also the rest of the communication UDP-encapsulated R1 packet, and also the rest of the communication
related to the HIP association MUST also use UDP encapsulation. related to the HIP association MUST also use UDP encapsulation.
Figure 4 illustrates a base exchange via a Control Relay Server. We Figure 4 illustrates a base exchange via a Control Relay Server. We
assume that the Responder (i.e. a Control Relay Client) has already assume that the Responder (i.e. a Control Relay Client) has already
registered to the Control Relay Server. The Initiator may have also registered to the Control Relay Server. The Initiator may have also
registered to another (or the same Control Relay Server), but the registered to another (or the same Control Relay Server), but the
base exchange will traverse always through the Control Relay Server base exchange will traverse always through the Control Relay Server
skipping to change at page 18, line 48 skipping to change at page 18, line 48
Figure 4: Base Exchange via a HIP Relay Server Figure 4: Base Exchange via a HIP Relay Server
In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via
the Control Relay Server to the Responder. In the HIP header, the the Control Relay Server to the Responder. In the HIP header, the
source HIT belongs to the Initiator and the destination HIT to the source HIT belongs to the Initiator and the destination HIT to the
Responder. The initiator sends the I1 packet from its IP address to Responder. The initiator sends the I1 packet from its IP address to
the IP address of the Control Relay Server over UDP. the IP address of the Control Relay Server over UDP.
In step 2, the Control Relay Server receives the I1 packet. If the In step 2, the Control Relay Server receives the I1 packet. If the
destination HIT belongs to a registered Responder, the Control Relay destination HIT belongs to a successfully registered Control Relay
Server processes the packet. Otherwise, the Control Relay Server Client (i.e., the host marked "Responder" in Figure 4), the Control
MUST drop the packet silently. The Control Relay Server appends a Relay Server processes the packet. Otherwise, the Control Relay
RELAY_FROM parameter to the I1 packet, which contains the transport Server MUST drop the packet silently. The Control Relay Server
source address and port of the I1 as observed by the Control Relay appends a RELAY_FROM parameter to the I1 packet, which contains the
Server. The Control Relay Server protects the I1 packet with transport source address and port of the I1 as observed by the
RELAY_HMAC as described in [RFC8004], except that the parameter type Control Relay Server. The Control Relay Server protects the I1
is different (see Section 5.8). The Control Relay Server changes the packet with RELAY_HMAC, except that the parameter type is different
as described in Section 5.8. The Control Relay Server changes the
source and destination ports and IP addresses of the packet to match source and destination ports and IP addresses of the packet to match
the values the Responder used when registering to the Control Relay the values the Responder used when registering to the Control Relay
Server, i.e., the reverse of the R2 used in the registration. The Server, i.e., the reverse of the R2 used in the registration. The
Control Relay Server MUST recalculate the transport checksum and Control Relay Server MUST recalculate the transport checksum and
forward the packet to the Responder. forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [RFC7401]. In addition, the processes it according to the rules in [RFC7401]. In addition, the
Responder validates the RELAY_HMAC according to [RFC8004] and Responder validates the RELAY_HMAC according to Section 5.8 and
silently drops the packet if the validation fails. The Responder silently drops the packet if the validation fails. The Responder
replies with an R1 packet to which it includes RELAY_TO and NAT replies with an R1 packet to which it includes RELAY_TO and NAT
traversal mode parameters. The responder MUST include ICE-HIP-UDP in traversal mode parameters. The responder MUST include ICE-HIP-UDP in
the NAT traversal modes. The RELAY_TO parameter MUST contain the the NAT traversal modes. The RELAY_TO parameter MUST contain the
same information as the RELAY_FROM parameter, i.e., the Initiator's same information as the RELAY_FROM parameter, i.e., the Initiator's
transport address, but the type of the parameter is different. The transport address, but the type of the parameter is different. The
RELAY_TO parameter is not integrity protected by the signature of the RELAY_TO parameter is not integrity protected by the signature of the
R1 to allow pre-created R1 packets at the Responder. R1 to allow pre-created R1 packets at the Responder.
In step 4, the Control Relay Server receives the R1 packet. The In step 4, the Control Relay Server receives the R1 packet. The
skipping to change at page 20, line 9 skipping to change at page 20, line 12
key material generation are described in detail in sections 5.2.18 key material generation are described in detail in sections 5.2.18
and 6.5 in [RFC7401]. and 6.5 in [RFC7401].
In step 6, the Control Relay Server receives the I2 packet. The In step 6, the Control Relay Server receives the I2 packet. The
Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
packet similarly as explained in step 2, and forwards the packet to packet similarly as explained in step 2, and forwards the packet to
the Responder. the Responder.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC7401]. The Responder validates the RELAY_HMAC according to [RFC7401]. The Responder validates the RELAY_HMAC
according to [RFC8004] and silently drops the packet if the according to Section 5.8 and silently drops the packet if the
validation fails. It replies with an R2 packet and includes a validation fails. It replies with an R2 packet and includes a
RELAY_TO parameter as explained in step 3. The R2 packet includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a
LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all
the HIP candidates (ICE answer) of the Responder. The RELAY_TO the HIP candidates (ICE answer) of the Responder. The RELAY_TO
parameter is protected by the HMAC. The ENCRYPTED parameter along parameter is protected by the HMAC. The ENCRYPTED parameter along
with its key material generation are described in detail in sections with its key material generation are described in detail in sections
5.2.18 and 6.5 in [RFC7401]. 5.2.18 and 6.5 in [RFC7401].
In step 8, the Control Relay Server processes the R2 as described in In step 8, the Control Relay Server processes the R2 as described in
step 4. The Control Relay Server forwards the packet to the step 4. The Control Relay Server forwards the packet to the
Initiator. After the Initiator has received the R2 and processed it Initiator. After the Initiator has received the R2 and processed it
successfully, the base exchange is completed. successfully, the base exchange is completed.
Hosts MUST include the address of one or more Control Relay Servers Hosts MUST include the address of one or more Control Relay Servers
(including the one that is being used for the initial signaling) in (including the one that is being used for the initial signaling) in
the LOCATOR_SET parameter in I2 and R2 if they intend to use such the LOCATOR_SET parameter in I2 and R2 messages if they intend to use
servers for relaying HIP signaling immediately after the base such servers for relaying HIP signaling immediately after the base
exchange completes. The traffic type of these addresses MUST be "HIP exchange completes. The traffic type of these addresses MUST be "HIP
signaling" and they MUST NOT be used as HIP candidates. If the signaling" (see Section 5.7) and they MUST NOT be used for the
Control Relay Server locator used for relaying the base exchange is connectivity tests described in Section 4.6. If the Control Relay
not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be Server locator used for relaying the base exchange is not included in
used after the base exchange. Instead, further HIP signaling SHOULD I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used after the base
use the same path as the data traffic. It is RECOMMENDED to use the exchange. Instead, further HIP signaling SHOULD use the same path as
same Control Relay Server throughout the lifetime of the host the data traffic. It is RECOMMENDED to use the same Control Relay
association that was used for forwarding the base exchange if the Server throughout the lifetime of the host association that was used
Responder includes it in the locator parameter of the R2 message. for forwarding the base exchange if the Responder includes it in the
locator parameter of the R2 message.
4.6. Connectivity Checks 4.6. Connectivity Checks
When the Initiator and Responder complete the base exchange through When the Initiator and Responder complete the base exchange through
the Control Relay Server, both of them employ the IP address of the the Control Relay Server, both of them employ the IP address of the
Control Relay Server as the destination address for the packets. The Control Relay Server as the destination address for the packets. The
address of the Control Relay Server MUST NOT be used as a destination address of the Control Relay Server MUST NOT be used as a destination
for data plane traffic unless the server supports also Data Relay for data plane traffic unless the server supports also Data Relay
Server functionality, and the Client has successfully registered to Server functionality, and the Client has successfully registered to
use it. When NAT traversal mode with ICE-HIP-UDP was successfully use it. When NAT traversal mode with ICE-HIP-UDP was successfully
negotiated and selected, the Initiator and Responder MUST start the negotiated and selected, the Initiator and Responder MUST start the
connectivity checks in order to attempt to obtain direct end-to-end connectivity checks in order to attempt to obtain direct end-to-end
connectivity through NAT devices. It is worth noting that the connectivity through NAT devices. It is worth noting that the
connectivity checks MUST be completed even though no ESP_TRANSFORM connectivity checks MUST be completed even though no ESP_TRANSFORM
would be negotiated and selected. would be negotiated and selected.
The connectivity checks follow the ICE methodology [MMUSIC-ICE], but The connectivity checks follow the ICE methodology
UDP encapsulated HIP control messages are used instead of ICE [I-D.rosenberg-mmusic-ice-nonsip], but UDP encapsulated HIP control
messages. As stated in the ICE specification, the basic procedure messages are used instead of ICE messages. As stated in the ICE
for connectivity checks has three phases: sorting the candidate pairs specification, the basic procedure for connectivity checks has three
according their priority, sending checks in the prioritized order and phases: sorting the candidate pairs according their priority, sending
acknowledging the checks from the peer host. checks in the prioritized order and acknowledging the checks from the
peer host.
The Initiator MUST take the role of controlling host and the The Initiator MUST take the role of controlling host and the
Responder acts as the controlled host. The roles MUST persist Responder acts as the controlled host. The roles MUST persist
throughout the HIP associate lifetime (to be reused in the possibly throughout the HIP associate lifetime (to be reused in the possibly
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
controlled role. controlled role.
skipping to change at page 24, line 41 skipping to change at page 24, line 41
the Data Relay Server of its peer. the Data Relay Server of its peer.
4.6.2. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
The HITs of the two communicating hosts MUST be used as credentials The HITs of the two communicating hosts MUST be used as credentials
in this protocol (in contrast to ICE which employs username-password in this protocol (in contrast to ICE which employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a association, and a SEQ number in an UPDATE message identifies a
particular connectivity check. particular connectivity check.
All of the connectivity check packets MUST be protected with HMACs All of the connectivity check messages MUST be protected with
and signatures (even though the illustrations in this specification HIP_HMAC and signatures (even though the illustrations in this
omit them for simplicity). Each connectivity check sent by a host specification omit them for simplicity) according to [RFC7401]. Each
MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and connectivity check sent by a host MUST include a SEQ parameter and
correspondingly the peer MUST respond to these using ACK and ECHO_REQUEST_SIGNED parameter, and correspondingly the peer MUST
ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401]. respond to these using ACK and ECHO_RESPONSE_SIGNED according to the
rules specified in [RFC7401].
The host sending a connectivity check MUST validate that the response The host sending a connectivity check MUST validate that the response
uses the same pair of UDP ports, and drop the packet if this is not uses the same pair of UDP ports, and drop the packet if this is not
the case. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
queue a response by placing it in the triggered-check queue, and then queue a response by placing it in the triggered-check queue, and then
continue waiting for the candidates. A host MUST NOT select a continue waiting for the candidates. A host MUST NOT select a
candidate pair until it has verified the pair using a connectivity candidate pair until it has verified the pair using a connectivity
check as defined in Section 4.6.1. check as defined in Section 4.6.1.
[RFC7401] states that UPDATE packets have to include either a SEQ or [RFC7401] section 5.3.5 states that UPDATE packets have to include
ACK parameter (or both). According to the RFC, each SEQ parameter either a SEQ or ACK parameter (but can include both). According to
should be acknowledged separately. In the context of NATs, this the RFC, each SEQ parameter should be acknowledged separately. In
means that some of the SEQ parameters sent in connectivity checks the context of NATs, this means that some of the SEQ parameters sent
will be lost or arrive out of order. From the viewpoint of the in connectivity checks will be lost or arrive out of order. From the
recipient, this is not a problem since the recipient will just viewpoint of the recipient, this is not a problem since the recipient
"blindly" acknowledge the SEQ. However, the sender needs to be will just "blindly" acknowledge the SEQ. However, the sender needs
prepared for lost sequence identifiers and ACKs parameters that to be 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 check SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some be sent with the same sequence identifier in the SEQ parameter. Some
tested address candidates will never produce a working address pair, tested address candidates will never produce a working address pair,
and thus may cause retransmissions. Upon successful nomination of an and thus may cause retransmissions. Upon successful nomination of an
address pair, a host SHOULD immediately stop sending such address pair, a host SHOULD immediately stop sending such
retransmissions. retransmissions.
Full ICE procedures for prioritizing candidates, eliminating Full ICE procedures for prioritizing candidates, eliminating
redundant candidates, forming check lists (including pruning) and redundant candidates, forming check lists (including pruning) and
triggered check-queues MUST be followed as specified in section 6.1 triggered check-queues MUST be followed as specified in section 6.1
[RFC8445], with the exception that the foundation, frozen candidates [RFC8445], with the exception of that the foundation, frozen
and default candidates are not used. From viewpoint of the ICE candidates and default candidates are not used. From viewpoint of
specification [RFC8445], the protocol specified in this document the ICE specification [RFC8445], the protocol specified in this
operates using Component ID of 1 on all candidates, and the document operates using Component ID of 1 on all candidates, and the
foundation of all candidates is unique. This specification defines foundation of all candidates is unique. This specification defines
only "full ICE" mode, and the "lite ICE" is not supported. The only "full ICE" mode, and the "lite ICE" is not supported. The
reasoning behind the missing features is described in Appendix B. reasoning behind the missing features is described in Appendix B.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
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
50 ms MUST be used. 50 ms MUST be used.
Both hosts MUST form a priority ordered checklist and begin to check Both hosts MUST form a priority ordered checklist and begin to check
skipping to change at page 28, line 17 skipping to change at page 28, line 17
exchange acts as an implicit connectivity test itself. For this to exchange acts as an implicit connectivity test itself. For this to
work, the Initiator MUST be able to reach the Responder by simply UDP work, the Initiator MUST be able to reach the Responder by simply UDP
encapsulating HIP and ESP packets sent to the Responder's address. encapsulating HIP and ESP packets sent to the Responder's address.
Detecting and configuring this particular scenario is prone to Detecting and configuring this particular scenario is prone to
failure unless carefully planned. failure unless carefully planned.
In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT
traversal mode as one of the supported modes in the R1 packet. If traversal mode as one of the supported modes in the R1 packet. If
the Responder has registered to a Control Relay Server in order to the Responder has registered to a Control Relay Server in order to
discover its address candidates, it MUST also include a LOCATOR_SET discover its address candidates, it MUST also include a LOCATOR_SET
parameter in R1 that contains a preferred address where the Responder parameter encapsulated inside an ENCRYPTED parameter in R1 message
is able to receive UDP-encapsulated ESP and HIP packets. This that contains a preferred address where the Responder is able to
locator MUST be of type "Transport address", its Traffic type MUST be receive UDP-encapsulated ESP and HIP packets. This locator MUST be
"both", and it MUST have the "Preferred bit" set (see Table 1). If of type "Transport address", its Traffic type MUST be "both", and it
there is no such locator in R1, the source address of R1 is used as MUST have the "Preferred bit" set (see Table 1). If there is no such
locator in R1, the Initiator MUST use the source address of the R1 as
the Responder's preferred address. the Responder's preferred address.
The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder
listed it in the supported modes and the Initiator does not wish to listed it in the supported modes and the Initiator does not wish to
use the connectivity checks defined in this document for searching use the connectivity checks defined in this document for searching
for a more optimal path. In this case, the Initiator sends the I2 for a more optimal path. In this case, the Initiator sends the I2
with UDP-ENCAPSULATION mode in the NAT traversal mode parameter with UDP-ENCAPSULATION mode in the NAT traversal mode parameter
directly to the Responder's preferred address (i.e., to the preferred directly to the Responder's preferred address (i.e., to the preferred
locator in R1 or to the address where R1 was received from if there locator in R1 or to the address where R1 was received from if there
was no preferred locator in R1). The Initiator MAY include locators was no preferred locator in R1). The Initiator MAY include locators
skipping to change at page 29, line 22 skipping to change at page 29, line 22
The Initiator MAY also try to simultaneously perform a base exchange The Initiator MAY also try to simultaneously perform a base exchange
with the Responder without UDP encapsulation. In such a case, the with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while encapsulation, to the Responder. The Initiator MAY wait for a while
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly, without The I1 packet without UDP encapsulation may arrive directly, without
passing any Control Data Relays, at the Responder. When this passing any a Control Relay Server, at the Responder. When this
happens, the procedures in [RFC7401] are followed for the rest of the happens, the procedures in [RFC7401] are followed for the rest of the
base exchange. The Initiator may receive multiple R1 packets, with base exchange. The Initiator may receive multiple R1 packets, with
and without UDP encapsulation, from the Responder. However, after and without UDP encapsulation, from the Responder. However, after
receiving a valid R1 and answering it with an I2, further R1 packets receiving a valid R1 and answering it with an I2, further R1 packets
that are not retransmissions of the R1 message received first MUST be that are not retransmissions of the R1 message received first MUST be
ignored. 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
skipping to change at page 30, line 12 skipping to change at page 30, line 12
exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply
also here, so they are repeated here for completeness. also here, so they are repeated here for completeness.
After the base exchange, the two end-hosts MAY send HIP control After the base exchange, the two end-hosts MAY send HIP control
packets directly to each other using the transport address pair packets directly to each other using the transport address pair
established for a data channel without sending the control packets established for a data channel without sending the control packets
through any Control Relay Servers . When a host does not receive through any Control Relay Servers . When a host does not receive
acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
based on local policies, a host SHOULD resend the packet through the based on local policies, a host SHOULD resend the packet through the
associated Data Relay Server of the peer (if the peer listed it in associated Data Relay Server of the peer (if the peer listed it in
its LOCATOR_SET parameter in the base exchange. its LOCATOR_SET parameter in the base exchange according the rules
specified in section 4.4.2 in [RFC7401].
If Control Relay Client sends a packet through a Control Relay If Control Relay Client sends a packet through a Control Relay
Server, the Control Relay Client MUST always utilize the RELAY_TO Server, the Control Relay Client MUST always utilize the RELAY_TO
parameter. The Control Relay Server SHOULD forward HIP control parameter. The Control Relay Server SHOULD forward HIP control
packets originating from a Control Relay Client to the address packets originating from a Control Relay Client to the address
denoted in the RELAY_TO parameter. In the other direction, the denoted in the RELAY_TO parameter. In the other direction, the
Control Relay Server SHOULD forward HIP control packets to the Control Relay Server SHOULD forward HIP control packets to the
Control Relay Clients, and MUST add a RELAY_FROM parameter to the Control Relay Clients, and MUST add a RELAY_FROM parameter to the
control packets it relays to the Control Relay Clients. control packets it relays to the Control Relay Clients.
skipping to change at page 34, line 17 skipping to change at page 34, line 17
relayed address. relayed address.
In so called "double jump" or simultaneous mobility scenario both In so called "double jump" or simultaneous mobility scenario both
peers change their location simultaneously. In such a case, both peers change their location simultaneously. In such a case, both
peers trigger the procedure described earlier in this section at the peers trigger the procedure described earlier in this section at the
same time. In other words, both of the communicating hosts send an same time. In other words, both of the communicating hosts send an
UPDATE packet carrying locators at the same time or with some delay. UPDATE packet carrying locators at the same time or with some delay.
When the locators are exchanged almost simultaneously (reliably via When the locators are exchanged almost simultaneously (reliably via
Control Relay Servers), the two hosts can continue with connectivity Control Relay Servers), the two hosts can continue with connectivity
checks after both have completed separately the steps in Figure 6. checks after both have completed separately the steps in Figure 6.
The problematic case occurs when the one of the hosts (referred here The problematic case occurs when one of the hosts (referred here as
as host "M") moves later during the connectivity checks. In such a host "M") moves later during the connectivity checks. In such a
case, host M sends a locator to the peer which is in the middle of case, host M sends a locator to the peer which is in the middle of
connectivity checks. Upon receiving the UPDATE message, the peer connectivity checks. Upon receiving the UPDATE message, the peer
responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in
Figure 6. Upon receiving the valid response from host M as described Figure 6. Upon receiving the valid response from host M as described
in step 6, the peer host MUST restart the connectivity checks with in step 6, the peer host MUST restart the connectivity checks with
host M. This way, both hosts start the connectivity checks roughly host M. This way, both hosts start the connectivity checks roughly
in a synchronized way. It is also important that peer host does not in a synchronized way. It is also important that peer host does not
restart the connectivity checks until it has received a valid "fresh" restart the connectivity checks until the step 6 is successfully
confirmation from host M because the UPDATE message carrying locators completed because the UPDATE message carrying locators in step 1
could be replayed by an attacker. could be replayed by an attacker.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts MUST send To prevent NAT states from expiring, communicating hosts MUST send
periodic keepalives to other hosts with which they have established a periodic keepalives to other hosts with which they have established a
Host Association every 15 seconds (the so called Tr value in ICE). Host Association every 15 seconds (the so called Tr value in ICE).
Other values MAY be used, but a Tr value smaller than 15 seconds MUST Other values MAY be used, but a Tr value smaller than 15 seconds MUST
NOT be used. Both a Control/Data Relay Client and Control/Data Relay NOT be used. Both a Control/Data Relay Client and Control/Data Relay
Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP- Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-
skipping to change at page 35, line 20 skipping to change at page 35, line 20
it with CLOSE_ACK. All packets are protected using HMACs and it with CLOSE_ACK. All packets are protected using HMACs and
signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED
parameter to protect against replay attacks. parameter to protect against replay attacks.
The same procedure for closing HIP associations applies also here, The same procedure for closing HIP associations applies also here,
but the messaging occurs using the UDP encapsulated tunnel that the but the messaging occurs using the UDP encapsulated tunnel that the
two hosts employ. A host sending the CLOSE message SHOULD first send two hosts employ. A host sending the CLOSE message SHOULD first send
the message over a direct link. After a number of retransmissions, the message over a direct link. After a number of retransmissions,
it MUST send over a Control Relay Server of the recipient if one it MUST send over a Control Relay Server of the recipient if one
exists. The host receiving the CLOSE message directly without a exists. The host receiving the CLOSE message directly without a
Control Data Relay SHOULD respond directly. If CLOSE message came Control Relay Server SHOULD respond directly. If CLOSE message came
via a Control Data Relay, the host SHOULD respond using the same via a Control Relay Server, the host SHOULD respond using the same
Control Data Relay. Control Relay Server.
4.12. Relaying Considerations 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions 4.12.1. Forwarding Rules and Permissions
The Data Relay Server uses a similar permission model as a TURN The Data Relay Server uses a similar permission model as a TURN
server: before the Data Relay Server forwards any ESP data packets server: before the Data Relay Server forwards any ESP data packets
from a peer to a Data Relay Client (or the other direction), the from a peer to a Data Relay Client (or the other direction), the
client MUST set a permission for the peer's address. The permissions client MUST set a permission for the peer's address. The permissions
also install a forwarding rule for each direction, similar to TURN's also install a forwarding rule for each direction, similar to TURN's
skipping to change at page 38, line 26 skipping to change at page 38, line 26
procedures; the Data Relay Client MUST NOT include the relayed procedures; the Data Relay Client MUST NOT include the relayed
address candidate when sending its new locator set in an UPDATE to address candidate when sending its new locator set in an UPDATE to
its peer if it would cause a SPI conflict with another peer. its peer if it would cause a SPI conflict with another peer.
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be in network byte for the HIP and ESP packets. All values MUST be in network byte
order. order.
It is worth noting that most of the parameters are shown for the sake It is worth noting that all of the parameters are shown for the sake
of completeness even though they are specified already in Legacy ICE- of completeness even though they are specified already in Legacy ICE-
HIP [RFC5770]. New parameters are explicitly described as new. HIP [RFC5770]. New parameters are explicitly described as new.
5.1. HIP Control Packets 5.1. HIP Control Packets
Figure 7 illustrates the packet format for UDP-encapsulated HIP. The Figure 7 illustrates the packet format for UDP-encapsulated HIP. The
format is identical to Legacy ICE-HIP [RFC5770]. format is identical to Legacy ICE-HIP [RFC5770].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 39, line 23 skipping to change at page 39, line 23
already contains a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC7401] includes the IP addresses in the checksum calculation. The [RFC7401] includes the IP addresses in the checksum calculation. The
NATs that are unaware of HIP cannot recompute the HIP checksum after NATs that are unaware of HIP cannot recompute the HIP checksum after
changing IP addresses. changing IP addresses.
A Control/Data Relay Server or a non-relay Responder SHOULD listen at A Control/Data Relay Server or a non-relay Responder SHOULD listen at
UDP port 10500 for incoming UDP-encapsulated HIP control packets. If UDP port 10500 for incoming UDP-encapsulated HIP control packets. If
some other port number is used, it needs to be known by potential some other port number is used, it needs to be known by potential
Initiators. Initiators.
It is worth noting that UDP encapsulation of HIP packets reduces the UDP encapsulation of HIP packets reduces the Maximum Transfer Unit
Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. (MTU) size of the control plane by 12 bytes (8-byte UDP header plus
4-byte zero SPI marker), and the data plane by 8 bytes. Additional
HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP,
RELAY_UDP_ESP, etc., further increase the size of certain HIP
packets. In regard to MTU, the following aspects need to be
considered in an implementation:
o A HIP host SHOULD implement ICMP message handling to support path
MTU discovery (PMTUD) discovery as described in [RFC1063]
[RFC8201]
o Reliance on IP fragmentation is unlikely to be a viable strategy
through NATs. If ICMP MTU discovery is not working, MTU related
path black holes may occur.
o A mitigation strategy is to constrain the MTU, especially for
virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
for the underlying interfaces that support 1500 bytes MTU.
o Further extensions to this specification may define a HIP-based
mechanism to find a working path MTU without unnecessary
constraining that size using Packetization Layer Path MTU
Discovery for Datagram Transports
[I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism
could be implemented between a HIP Relay Client and HIP Relay
Server.
o It is worth noting that further HIP extensions can trim off 8
bytes in the ESP header by negotiating implicit IV support in the
ESP_TRANSFORM parameter as described in [RFC8750].
5.2. Connectivity Checks 5.2. Connectivity Checks
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
5.3. Keepalives 5.3. Keepalives
The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
as specified in [RFC7401] with Notify message type field set to as specified in [RFC7401] with Notify message type field set to
skipping to change at page 40, line 7 skipping to change at page 40, line 35
security association. Alternatively, the host MAY use UPDATE packets security association. Alternatively, the host MAY use UPDATE packets
as a substitute. A minimal UPDATE packet would consist of a SEQ and as a substitute. A minimal UPDATE packet would consist of a SEQ and
ECHO_REQ_SIGN parameters, and a more complex would involve rekeying ECHO_REQ_SIGN parameters, and a more complex would involve rekeying
procedures as specified in section 6.8 in [RFC7402]. It is worth procedures as specified in section 6.8 in [RFC7402]. It is worth
noting that a host actively sending periodic UPDATE packets to a busy noting that a host actively sending periodic UPDATE packets to a busy
server may increase the computational load of the server since it has server may increase the computational load of the server since it has
to verify HMACs and signatures in UPDATE messages. to verify HMACs and signatures in UPDATE messages.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from Legacy The format of NAT traversal mode parameter is defined in Legacy ICE-
ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is HIP [RFC5770] but repeated here for completeness. The format of the
similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and NAT_TRAVERSAL_MODE parameter is similar to the format of the
is shown in Figure 8. The Native ICE-HIP extension specified in this ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The
document defines the new NAT traversal mode identifier for ICE-HIP- Native ICE-HIP extension specified in this document defines the new
UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP-
[RFC5770]. The identifier named RESERVED is reserved for future use. ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier
Future specifications may define more traversal modes. named RESERVED is reserved for future use. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 47 skipping to change at page 44, line 50
| | | priority algorithm. | | | | priority algorithm. |
| SPI | Variable | Security Parameter Index (SPI) value that | | SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP | | | | the host expects to see in incoming ESP |
| | | packets that use this locator | | | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 1: Fields of the LOCATOR_SET Parameter Table 1: Fields of the LOCATOR_SET Parameter
The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED
parameter.
5.8. RELAY_HMAC Parameter 5.8. RELAY_HMAC Parameter
As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
value has the TLV type 65520. It has the same semantics as RVS_HMAC value has the TLV type 65520. It has the same semantics as RVS_HMAC
as specified in section 4.2.1 in [RFC8004]. Similarly as with as specified in section 4.2.1 in [RFC8004]. Similarly as with
RVS_HMAC, also RELAY_HMAC is keyed with the HIP integrity key (HIP-lg RVS_HMAC, also RELAY_HMAC is keyed with the HIP integrity key (HIP-lg
or HIP-gl as specified in section 6.5 in [RFC7401]), established or HIP-gl as specified in section 6.5 in [RFC7401]), established
during the relay registration procedure as described in Section 4.1. during the relay registration procedure as described in Section 4.1.
5.9. Registration Types 5.9. Registration Types
skipping to change at page 46, line 31 skipping to change at page 46, line 36
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations (SAs) enable them to define a pair of IPsec ESP security associations (SAs)
as described in [RFC7402]. When two peers perform a UDP-encapsulated as described in [RFC7402]. When two peers perform a UDP-encapsulated
base exchange, they MUST define a pair of IPsec SAs that produces base exchange, they MUST define a pair of IPsec SAs that produces
UDP-encapsulated ESP data traffic. UDP-encapsulated ESP data traffic.
The management of encryption/authentication protocols and SPIs is The management of encryption/authentication protocols and SPIs is
defined in [RFC7402]. The UDP encapsulation format and processing of defined in [RFC7402]. The UDP encapsulation format and processing of
HIP ESP traffic is described in Section 6.1 of [RFC7402]. HIP ESP traffic is described in Section 6.1 of [RFC7402].
It is worth noting that UDP encapsulation of ESP reduces the MTU size
of data plane by 8 bytes.
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
While the type values are new, the format of the RELAYED_ADDRESS and While the type values are new, the format of the RELAYED_ADDRESS and
MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM,
RELAY_FROM and RELAY_TO parameters. This document specifies only the RELAY_FROM and RELAY_TO parameters. This document specifies only the
use of UDP relaying, and, thus, only protocol 17 is allowed. use of UDP relaying, and, thus, only protocol 17 is allowed.
However, future documents may specify support for other protocols. However, future documents may specify support for other protocols.
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
skipping to change at page 50, line 13 skipping to change at page 50, line 13
Section 6.7. Section 6.7.
6.1. Privacy Considerations 6.1. Privacy Considerations
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
locators to each other. For example, tracking the physical location locators to each other. For example, tracking the physical location
of a multihoming end-host may become easier if it reveals all of a multihoming end-host may become easier if it reveals all
locators to its peer during a base exchange. Also, revealing host locators to its peer during a base exchange. Also, revealing host
addresses exposes information about the local topology that may not addresses exposes information about the local topology that may not
be allowed in all corporate environments. For these two local policy be allowed in all corporate environments. For these two local policy
reasons, an end-host MAY exclude certain host addresses from its reasons, it might be tempting exclude certain host addresses from the
LOCATOR_SET parameter, but this requires further experimentation. LOCATOR_SET parameter of an end-host but this is NOT RECOMMENDED.
However, such behavior creates non-optimal paths when the hosts are For instance, such behavior creates non-optimal paths when the hosts
located behind the same NAT. Especially, this could be problematic are located behind the same NAT. Especially, this could be
with a legacy NAT that does not support routing from the private problematic with a legacy NAT that does not support routing from the
address realm back to itself through the outer address of the NAT. private address realm back to itself through the outer address of the
This scenario is referred to as the hairpin problem [RFC5128]. With NAT. This scenario is referred to as the hairpin problem [RFC5128].
such a legacy NAT, the only option left would be to use a relayed With such a legacy NAT, the only option left would be to use a
transport address from an Control Relay Server server. relayed transport address from an Data Relay Server.
The use of Control and Data Relay Servers can be also useful for The use of Control and Data Relay Servers can be also useful for
privacy purposes. For example, a privacy concerned Responder may privacy purposes. For example, a privacy concerned Responder may
reveal only its Control Relay Server and Relayed candidates to reveal only its Control Relay Server and Relayed candidates to
Initiators. This partially protects the Responder against Denial-of- Initiators. This partially protects the Responder against Denial-of-
Service (DoS) attacks by allowing the Responder to initiate new Service (DoS) attacks by allowing the Responder to initiate new
connections even if its relays would be unavailable due to a DoS connections even if its relays would be unavailable due to a DoS
attack. attack.
6.2. Opportunistic Mode 6.2. Opportunistic Mode
skipping to change at page 51, line 12 skipping to change at page 51, line 12
Relay Server by masquerading as the original Initiator and Responder. Relay Server by masquerading as the original Initiator and Responder.
The attack does not require the attacker(s) to compromise the private The attack does not require the attacker(s) to compromise the private
key(s) of the attacked host(s). However, for this attack to succeed, key(s) of the attacked host(s). However, for this attack to succeed,
the legitimate Responder has to be disconnected from the Control the legitimate Responder has to be disconnected from the Control
Relay Server. Relay Server.
The Control Relay Server can protect itself against replay attacks by The Control Relay Server can protect itself against replay attacks by
becoming involved in the base exchange by introducing nonces that the becoming involved in the base exchange by introducing nonces that the
end-hosts (Initiator and Responder) are required to sign. One way to end-hosts (Initiator and Responder) are required to sign. One way to
do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets
as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the as described in [I-D.heer-hip-middle-auth] and drop the I2 or R2
corresponding ECHO_RESPONSE_M parameters are not present. packets if the corresponding ECHO_RESPONSE_M parameters are not
present.
6.4. Demultiplexing Different HIP Associations 6.4. Demultiplexing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
skipping to change at page 52, line 13 skipping to change at page 52, line 13
defined in Section 4.7. defined in Section 4.7.
6.7. Attacks against Connectivity Checks and Candidate Gathering 6.7. Attacks against Connectivity Checks and Candidate Gathering
Section 19.2 in [RFC8445] describes attacks against ICE connectivity Section 19.2 in [RFC8445] describes attacks against ICE connectivity
checks. HIP bases its control plane security on Diffie-Hellman key checks. HIP bases its control plane security on Diffie-Hellman key
exchange, public keys and Hashed Message Authentication codes, exchange, public keys and Hashed Message Authentication codes,
meaning that the mentioned security concerns do not apply to HIP meaning that the mentioned security concerns do not apply to HIP
either. The mentioned section discusses also of man-in-the-middle either. The mentioned section discusses also of man-in-the-middle
replay attacks that are difficult to prevent. The connectivity replay attacks that are difficult to prevent. The connectivity
checks in this protocol are immune against replay attacks because a checks in this protocol are effectively immune against replay attacks
connectivity request includes a random nonce that the recipient must because a connectivity request includes a random nonce that the
sign and send back as a response. recipient must sign and send back as a response.
Section 19.3 in [RFC8445] describes attacks on server reflexive Section 19.3 in [RFC8445] describes attacks on server reflexive
address gathering. Similarly here, if the DNS, a Control Relay address gathering. Similarly here, if the DNS, a Control Relay
Server or a Data Relay Server has been compromised, not much can be Server or a Data Relay Server has been compromised, not much can be
done. However, the case where attacker can inject fake messages done. However, the case where attacker can inject fake messages
(located on a shared network segment like Wifi) does not apply here. (located on a shared network segment like Wifi) does not apply here.
HIP messages are integrity and replay protected, so it is not HIP messages are integrity and replay protected, so it is not
possible inject fake server reflexive address candidates. possible inject fake server reflexive address candidates.
Section 19.4 in [RFC8445] describes attacks on relayed candidate Section 19.4 in [RFC8445] describes attacks on relayed candidate
skipping to change at page 52, line 38 skipping to change at page 52, line 38
gathering against fake requests and responses. Further, replay gathering against fake requests and responses. Further, replay
attacks are not possible because the HIP base exchange (and also attacks are not possible because the HIP base exchange (and also
UPDATE procedure) is protected against replay attacks. UPDATE procedure) is protected against replay attacks.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC8126]. This section is to be interpreted according to [RFC8126].
This document reuses the same default UDP port number 10500 as This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
plane and data plane traffic. IANA is requested to add a reference plane and data plane traffic. The port was was registered separately
to this document in the entry for UDP port 10500 in the Transport for RFC5770 to co-author Ari Keranen but should now be re-assigned
Protocol Port Number Registry. The selection between Legacy ICE-HIP for IESG control. With the permission of Ari Keranen, the new
and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE assignee is IESG and contact "chair@ietf.org". In addition, IANA is
parameter during the base exchange. By default, hosts listen this requested to add a reference to this document in the entry for UDP
port for incoming UDP datagrams and can use it also for sending UDP port 10500 in the Transport Protocol Port Number Registry. The
datagrams. Other emphemeral port numbers are negotiated and utilized selection between Legacy ICE-HIP and Native ICE-HIP mode is
dynamically. negotiated using NAT_TRAVERSAL_MODE parameter during the base
exchange. By default, hosts listen this port for incoming UDP
datagrams and can use it also for sending UDP datagrams. Other
emphemeral port numbers are negotiated and utilized dynamically.
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC7401] by assigning new HIP Parameter Type values for the new HIP [RFC7401] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20,
defined in Section 5.12), PEER_PERMISSION (length 48, defined in defined in Section 5.12), PEER_PERMISSION (length 48, defined in
Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14)
and NOMINATE (length 4, defined in Section 5.15). and NOMINATE (length 4, defined in Section 5.15).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
skipping to change at page 53, line 32 skipping to change at page 53, line 35
8. Contributors 8. Contributors
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in contributed to [RFC5770]. This document leans heavily on the work in
the RFC. the RFC.
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the
MMUSIC WG folks for the excellent work on ICE. In addition, the MMUSIC WG folks for the excellent work on ICE. The authors would
authors would like to thank Andrei Gurtov, Simon Schuetz, Martin like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling,
Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their
their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey
Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander,
Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela,
Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed and Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani
Jani Hautakorpi for their comments to [RFC5770], which is the basis Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to
for this document. [RFC5770] and this document. Thanks for Eric Vyncke, Alvaro Retana,
Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer
Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins,
Roni Even, Alissa Cooper, Carl Wallace and Benjamin Kaduk for
reviewing this document.
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 55, line 11 skipping to change at page 55, line 20
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
10.2. Informative References [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <https://www.rfc-editor.org/info/rfc8005>.
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, DOI 10.17487/RFC1063,
July 1988, <https://www.rfc-editor.org/info/rfc1063>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP) Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators", Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010, RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>. <https://www.rfc-editor.org/info/rfc5770>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 10.2. Informative References
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <https://www.rfc-editor.org/info/rfc4423>. [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-20 (work in
progress), February 2019.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, DOI 10.17487/RFC5207, April Communication", RFC 5207, DOI 10.17487/RFC5207, April
2008, <https://www.rfc-editor.org/info/rfc5207>. 2008, <https://www.rfc-editor.org/info/rfc5207>.
[I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <https://www.rfc-editor.org/info/rfc6538>. March 2012, <https://www.rfc-editor.org/info/rfc6538>.
[MMUSIC-ICE]
Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", Work in Progress, July 2008.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <https://www.rfc-editor.org/info/rfc5128>. 2008, <https://www.rfc-editor.org/info/rfc5128>.
[HIP-MIDDLE] [I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Hummen, R., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Work in Progress, Authentication for HIP Middleboxes", draft-heer-hip-
February 2009. middle-auth-04 (work in progress), October 2011.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP)", RFC 8750,
DOI 10.17487/RFC8750, March 2020,
<https://www.rfc-editor.org/info/rfc8750>.
[I-D.ietf-tsvwg-datagram-plpmtud]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-17
(work in progress), March 2020.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
Appendix A. Selecting a Value for Check Pacing Appendix A. Selecting a Value for Check Pacing
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
skipping to change at page 57, line 19 skipping to change at page 58, line 8
estimate the round-trip time (RTT) between them and SHOULD set the estimate the round-trip time (RTT) between them and SHOULD set the
minimum Ta value so that at most a single connectivity check message minimum Ta value so that at most a single connectivity check message
is sent on every RTT. is sent on every RTT.
One way to estimate the RTT is to use the time that it takes for the One way to estimate the RTT is to use the time that it takes for the
Control Relay Server registration exchange to complete; this would Control Relay Server registration exchange to complete; this would
give an estimate on the registering host's access link's RTT. Also, give an estimate on the registering host's access link's RTT. Also,
the I1/R1 exchange could be used for estimating the RTT, but since the 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 the R1 can be cached in the network, or the relaying service can
increase the delay notably, this is not recommended. In general, increase the delay notably, this is not recommended. In general,
estimating RTT can be difficult and error prone; further estimating RTT can be difficult and error prone, thus the guidelines
experimentation is required for reliable RTT estimation. for choosing a Ta value in Section 4.4 MUST be followed.
Appendix B. Differences with respect to ICE Appendix B. Differences with respect to ICE
Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The
benefits of such as an approach include the reuse of STUN/TURN benefits of such as an approach include the reuse of STUN/TURN
infrastructure and possibly the reuse of existing software libraries, infrastructure and possibly the reuse of existing software libraries,
but there are also drawbacks with the approach. For example, ICE is but there are also drawbacks with the approach. For example, ICE is
meant for application-layer protocols, whereas HIP operates at layer meant for application-layer protocols, whereas HIP operates at layer
3.5 between transport and network layers. This is particularly 3.5 between transport and network layers. This is particularly
problematic because the implementations employ kernelspace IPsec ESP problematic because the implementations employ kernelspace IPsec ESP
skipping to change at page 63, line 5 skipping to change at page 63, line 41
o Connectivity checks: the controlling host should be able to o Connectivity checks: the controlling host should be able to
nominate multiple candidates (by repeating step 7 in Figure 5 in nominate multiple candidates (by repeating step 7 in Figure 5 in
Section 4.6 using the additional candidate pairs). Section 4.6 using the additional candidate pairs).
o Keepalives should be sent for all the nominated candidate pairs. o Keepalives should be sent for all the nominated candidate pairs.
Similarly, the Control/Data Relay Client should send keepalives Similarly, the Control/Data Relay Client should send keepalives
from its local candidates to its Control/Data Relay Server from its local candidates to its Control/Data Relay Server
transport addresses. transport addresses.
Appendix E. DNS Considerations
This section updates [RFC5770] Appendix B which will be replaced with
the mechanism described in this section.
[RFC5770] did not specify how an end-host can look up another end-
host via DNS and initiate an UDP-based HIP base exchange with it, so
this section makes an attempt to fill this gap.
[RFC8005] specifies how a HIP end-host and its Rendezvous server is
registered to DNS. Essentially, the public key of the end-host is
stored as HI record and its Rendezvous Server as A or AAAA record.
This way, the Rendezvous Server can act as an intermediary for the
end-host and forward packets to it based on the DNS configuration.
Control Relay Server offers similar functionality as Rendezvous
Server, with the difference that the Control Relay Server forwards
all control messages, not just the first I1 message.
Prior to this document, the A and AAAA records in the DNS refer
either to the HIP end-host itself or a Rendezvous Server [RFC8005],
and control and data plane communication with the associated host has
been assumed to occur directly over IPv4 or IPv6. However, this
specification extends the records to be used for UDP-based
communications.
Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this
document. The Initiator looks up the FQDN of a Responder, and
retrieves its HI, A and AAAA records. Since the default policy is to
use UDP encapsulation, the Initiator MUST send the I1 message over
UDP to destination port 10500 (either over IPv4 in the case of a A
record or over IPv6 in the case of a AAAA record). It MAY send an I1
message both with and without UDP encapsulation in parallel. In the
case the Initiator receives R1 messages both with and without UDP
encapsulation from the Responder, the Initiator SHOULD ignore the R1
messages without UDP encapsulation.
The UDP encapsulated I1 packet could be received by three different
types of hosts:
1. HIP Control Relay Server: in this case the A/AAAA records refers
to a Control Relay Server, and it will forward the packet to the
corresponding Control Relay Client based on the destination HIT
in the I1 packet.
2. HIP Responder supporting UDP encapsulation: in this case, the A/
AAAA records refers to the end-host. Assuming the destination
HIT belongs to the Responder, it receives and processes it
according to the negotiated NAT traversal mechanism. The support
for the protocol defined in this document vs [RFC5770] is
dynamically negotiated during the base exchange. The details are
specified in Section 4.3.
3. HIP Rendezvous Server: this entity is not listening to UDP port
10500, so it will drop the I1 message.
4. HIP Responder not supporting UDP encapsulation: the targeted end-
host is not listening to UDP port 10500, so it will drop the I1
message.
The A/AAAA-record MUST NOT be configured to refer to a Data Relay
Server unless the host in question supports also Control Relay Server
functionality.
It also worth noting that SRV records are not employed in this
specification. While they could be used for more flexible UDP port
selection, they are not suitable for end-host discovery but rather
would be more suitable for the discovery of HIP-specific
infrastructure. Further extensions to this document may define SRV
records for Control and Data Relay Server discovery within a DNS
domain.
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. 59 change blocks. 
190 lines changed or deleted 338 lines changed or added

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