rfc9028.original   rfc9028.txt 
HIP Working Group A. Keranen Internet Engineering Task Force (IETF) A. Keränen
Internet-Draft J. Melen Request for Comments: 9028 J. Melén
Intended status: Experimental M. Komu, Ed. Category: Experimental M. Komu, Ed.
Expires: February 4, 2021 Ericsson ISSN: 2070-1721 Ericsson
August 3, 2020 June 2021
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-33
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 the messages instead of ICE for all NAT traversal procedures due to the
kernel-space dependencies of HIP. kernel-space dependencies of HIP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on February 4, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9028.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 3. Overview of Operation
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Description
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 10 4.1. Relay Registration
4.2. Transport Address Candidate Gathering at the Relay Client 13 4.2. Transport Address Candidate Gathering at the Relay Client
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 16 4.3. NAT Traversal Mode Negotiation
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 4.4. Connectivity Check Pacing Negotiation
4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 4.5. Base Exchange via Control Relay Server
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 4.6. Connectivity Checks
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 4.6.1. Connectivity Check Procedure
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 4.6.2. Rules for Connectivity Checks
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26 4.6.3. Rules for Concluding Connectivity Checks
4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27 4.7. NAT Traversal Optimizations
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27 4.7.1. Minimal NAT Traversal Support
4.7.2. Base Exchange without Connectivity Checks . . . . . . 27 4.7.2. Base Exchange without Connectivity Checks
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange Both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 29 Encapsulation
4.8. Sending Control Packets after the Base Exchange . . . . . 29 4.8. Sending Control Packets after the Base Exchange
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 4.9. Mobility Handover Procedure
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 4.10. NAT Keepalives
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35 4.11. Closing Procedure
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 4.12.1. Forwarding Rules and Permissions
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 4.12.2. HIP Data Relay and Relaying of Control Packets
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 4.12.3. Handling Conflicting SPI Values
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5. Packet Formats
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 5.1. HIP Control Packets
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 40 5.2. Connectivity Checks
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 40 5.3. Keepalives
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40 5.4. NAT Traversal Mode Parameter
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41 5.5. Connectivity Check Transaction Pacing Parameter
5.6. Relay and Registration Parameters . . . . . . . . . . . . 42 5.6. Relay and Registration Parameters
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 43 5.7. LOCATOR_SET Parameter
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 45 5.8. RELAY_HMAC Parameter
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 5.9. Registration Types
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 5.10. Notify Packet Types
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 5.11. ESP Data Packets
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 5.13. PEER_PERMISSION Parameter
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 5.14. HIP Connectivity Check Packets
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 5.15. NOMINATE Parameter
6. IAB Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 7. Security Considerations
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50 7.1. Privacy Considerations
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 7.2. Opportunistic Mode
6.3. Base Exchange Replay Protection for Control Relay Server 50 7.3. Base Exchange Replay Protection for Control Relay Server
6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 7.4. Demultiplexing Different HIP Associations
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 7.5. Reuse of Ports at the Data Relay Server
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 7.6. Amplification Attacks
6.7. Attacks against Connectivity Checks and Candidate 7.7. Attacks against Connectivity Checks and Candidate Gathering
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52 7.8. Cross-Protocol Attacks
6.8. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 52 8. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 9. References
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1. Normative References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 9.2. Informative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 Appendix A. Selecting a Value for Check Pacing
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 Appendix B. Differences with Respect to ICE
10.2. Informative References . . . . . . . . . . . . . . . . . 57 Appendix C. Differences to Base Exchange and UPDATE Procedures
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 59 Appendix D. Multihoming Considerations
Appendix B. Differences with respect to ICE . . . . . . . . . . 59 Appendix E. DNS Considerations
Appendix C. Differences to Base Exchange and UPDATE procedures . 62 Acknowledgments
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 64 Contributors
Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 65 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
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, NATs usually require the host traffic to pass [RFC5207]. Also, NATs usually require the host
behind a NAT to create a forwarding state in the NAT before other behind a NAT to create a forwarding state in the NAT before other
hosts outside of the NAT can contact the host behind the NAT. To hosts outside of the NAT can contact the host behind the NAT. To
overcome this problem, different methods, commonly referred to as NAT overcome this problem, different methods, commonly referred to as 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 Encapsulating Security
tunneling overhead). Another solution is specified in [RFC5770], Payload (ESP) traffic (with double tunneling overhead). Another
which will be referred to as "Legacy ICE-HIP" in this document. The solution is specified in [RFC5770], which will be referred to as
experimental Legacy ICE-HIP specification combines Interactive "Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP
Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that specification combines the Interactive Connectivity Establishment
basically ICE is responsible for NAT traversal and connectivity (ICE) protocol (originally [RFC5245]) with HIP so that basically, ICE
testing, while HIP is responsible for end-host authentication and is responsible for NAT traversal and connectivity testing, while HIP
IPsec key management. The resulting protocol uses HIP, STUN and ESP is responsible for end-host authentication and IPsec key management.
messages tunneled over a single UDP flow. The benefit of using ICE The resulting protocol uses HIP, Session Traversal Utilities for NAT
and its STUN/TURN messaging formats is that one can re-use the NAT (STUN), and ESP messages tunneled over a single UDP flow. The
traversal infrastructure already available in the Internet, such as benefit of using ICE and its STUN / Traversal Using Relays around NAT
STUN and TURN servers. Also, some middleboxes may be STUN-aware and (TURN) messaging formats is that one can reuse the NAT traversal
may be able to do something "smart" when they see STUN being used for infrastructure already available in the Internet, such as STUN and
NAT traversal. TURN servers. Also, some middleboxes may be STUN aware and may be
able to do something "smart" when they see STUN being used for NAT
traversal.
HIP poses a unique challenge to using standard ICE, due not only to HIP poses a unique challenge to using standard ICE, not only due to
kernel-space dependencies of HIP, 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, while [RFC5770] provides a
provides a technically workable path, it incurs unacceptable technically workable path, HIP incurs unacceptable performance
performance drawbacks for kernel-space implementations. Also, drawbacks for kernel-space implementations. Also, implementing and
implementing and integrating a full ICE/STUN/TURN protocol stack as integrating a full ICE/STUN/TURN protocol stack as specified in
specified in Legacy ICE-HIP results in a considerable amount of Legacy ICE-HIP results in a considerable amount of effort and code,
effort and code which could be avoided by re-using and extending HIP which could be avoided by reusing and extending HIP messages and
messages and state machines for the same purpose. Thus, this state machines for the same purpose. Thus, this document specifies
document specifies an alternative NAT traversal mode referred as an alternative NAT traversal mode referred to as "Native ICE-HIP"
"Native ICE-HIP" that employs HIP messaging format instead of STUN or that employs the HIP messaging format instead of STUN or TURN for the
TURN for the connectivity checks, keepalives and data relaying. connectivity checks, keepalives, and data relaying. Native ICE-HIP
Native ICE-HIP also specifies how mobility management works in the also specifies how mobility management works in the context of NAT
context of NAT traversal, which is missing from the Legacy ICE-HIP traversal, which is missing from the Legacy ICE-HIP specification.
specification. The native specification is also based on HIPv2, The native specification is also based on HIPv2, whereas the legacy
whereas legacy specification is based on HIPv1. The differences to specification is based on HIPv1. The differences to Legacy ICE-HIP
the Legacy ICE-HIP are further elaborated in Appendix B. are further elaborated in Appendix B.
Similarly as Legacy ICE-HIP, also this specification builds on the Similar to Legacy ICE-HIP, this specification builds on the HIP
HIP registration extensions [RFC8003] and the base exchange procedure registration extensions [RFC8003] and the base exchange procedure
[RFC7401] and its closing procedures, so the reader is recommended to [RFC7401] and its closing procedures; therefore, the reader is
get familiar with the relevant specifications. In a nutshell, the recommended to get familiar with the relevant specifications. In a
registration extensions allow a HIP Initiator (usually a "client" nutshell, the registration extensions allow a HIP Initiator (usually
host) to ask for specific services from a HIP Responder (usually a a "client" host) to ask for specific services from a HIP Responder
"server" host). The registration parameters are included in a base (usually a "server" host). The registration parameters are included
exchange, which is essentially a four-way Diffie-Hellman key exchange in a base exchange, which is essentially a four-way Diffie-Hellman
authenticated using the public keys of the end-hosts. When the hosts key exchange authenticated using the public keys of the end hosts.
negotiate support for ESP [RFC7402] during the base exchange, they When the hosts negotiate support for ESP [RFC7402] during the base
can deliver ESP protected application payload to each other. When exchange, they can deliver ESP-protected application payload to each
either of the hosts moves and changes its IP address, the two hosts other. When either of the hosts moves and changes its IP address,
re-establish connectivity using the mobility extensions [RFC8046]. the two hosts re-establish connectivity using the mobility extensions
The reader is also recommended to get familiar with the mobility [RFC8046]. The reader is also recommended to get familiar with the
extensions, but basically it is a three-way procedure, where the mobility extensions; basically, the process is a three-way procedure
mobile host first announces its new location to the peer, and then where the mobile host first announces its new location to the peer;
the peer tests for connectivity (so called return routability check), then, the peer tests for connectivity (the so-called return
for which the mobile hosts must respond in order to activate its new routability check); and then, the mobile host must respond to the
location. This specification builds on the mobility procedures, but announcement in order to activate its new location. This
modifies it to be compatible with ICE. The differences to the specification builds on the mobility procedures, but modifies them to
mobility extensions specified in Appendix C. It is worth noting that be compatible with ICE. The differences in the mobility extensions
multihoming support as specified in [RFC8047] is left for further are specified in Appendix C. It is worth noting that multihoming
study. support as specified in [RFC8047] is left for further study.
This specification builds heavily on the ICE methodology, so it is This specification builds heavily on the ICE methodology, so it is
recommended that the reader is familiar with the ICE specification recommended that the reader is familiar with the ICE specification
[RFC8445] (especially the overview). However, native ICE-HIP does [RFC8445] (especially the overview). However, Native ICE-HIP does
not implement all the features in ICE, and, hence, the different not implement all the features in ICE; hence, the different features
features of ICE are cross referenced using [RFC2119] terminology for of ICE are cross referenced using [RFC2119] terminology for clarity.
clarity. Appendix B explains the differences to ICE, and it is Appendix B explains the differences to ICE, and it is recommended
recommended that the reader would read also this section in addition that the reader read this section in addition to the ICE
to the ICE specification. specification.
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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], [I-D.ietf-hip-rfc4423-bis], [RFC8445], and [RFC5389]. The [RFC8046], [RFC9068], [RFC8445], and [RFC8489]. The following terms
following terms recur in the text: 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.
Native ICE-HIP: Native ICE-HIP:
The protocol specified in this document (Native NAT Traversal Mode The protocol specified in this document (Native NAT Traversal Mode
for HIP). for HIP).
Initiator: Initiator:
The Initiator is the host that initiates the base exchange using The host that initiates the base exchange using I1 message
I1 message [RFC7401]. [RFC7401].
Responder: Responder:
The Responder is the host that receives the I1 packet from the The host that receives the I1 packet from the Initiator [RFC7401].
Initiator [RFC7401].
Control Relay Server Control Relay Server
A registrar host that forwards any kind of HIP control plane A registrar host that forwards any kind of HIP control plane
packets between the Initiator and the Responder. This host is packets between the Initiator and the Responder. This host is
critical because it relays the locators between the Initiator and critical because it relays the locators between the Initiator and
the Responder, so that they can try to establish a direct the Responder so that they can try to establish a direct
communication path with each other. This host is used to replace communication path with each other. This host is used to replace
HIP rendezvous servers [RFC8004] for hosts operating in private HIP Rendezvous Servers [RFC8004] for hosts operating in private
address realms. In the Legacy ICE-HIP specification [RFC5770], address realms. In the Legacy ICE-HIP specification [RFC5770],
this host is denoted as "HIP Relay Server". this host is denoted as "HIP Relay Server".
Control Relay Client: Control Relay Client:
A requester host that registers to a Control Relay Server A requester host that registers to a Control Relay Server
requesting it to forward control-plane traffic (i.e. HIP control requesting it to forward control plane traffic (i.e., HIP control
messages). In the Legacy ICE-HIP specification [RFC5770], this is messages). In the Legacy ICE-HIP specification [RFC5770], this is
denoted as "HIP Relay Client". denoted as "HIP Relay Client".
Data Relay Server: Data Relay Server:
A new entity introduced in this document; a registrar host that A new entity introduced in this document; a registrar host that
forwards HIP related data plane packets, such as Encapsulating forwards HIP related data plane packets, such as Encapsulating
Security Payload (ESP) [RFC7402], between two hosts. This host Security Payload (ESP) [RFC7402], between two hosts. This host
implements similar functionality as TURN servers. implements similar functionality as TURN servers.
Data Relay Client: Data Relay Client:
A requester host that registers to a Data Relay Server requesting A requester host that registers to a Data Relay Server requesting
it to forward data-plane traffic (e.g. ESP traffic). This it to forward data plane traffic (e.g. ESP traffic). This
functionality is a new and introduced in this document. functionality is a new and introduced in this document.
Locator: Locator:
As defined in [RFC8046]: "A name that controls how the packet is As defined in [RFC8046]: "A name that controls how the packet is
routed through the network and demultiplexed by the end-host. It routed through the network and demultiplexed by the end host. It
may include a concatenation of traditional network addresses such may include a concatenation of traditional network addresses such
as an IPv6 address and end-to-end identifiers such as an ESP as an IPv6 address and end-to-end identifiers such as an ESP SPI.
Security Parameter Index (SPI). It may also include transport It may also include transport port numbers or IPv6 Flow Labels as
port numbers or IPv6 Flow Labels as demultiplexing context, or it demultiplexing context, or it 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 to exchange their locators (i.e., candidates) with each other. In
ICE, this procedure is called Candidate Exchange and it does not ICE, this procedure is called Candidate Exchange; 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 procedure occurring after a
handover. Following [RFC5770] and SDP related naming conventions handover. Following [RFC5770] and SDP-related naming conventions
[RFC3264], "HIP offer" is the the Initiator's LOCATOR_SET [RFC3264], "HIP offer" is the Initiator's LOCATOR_SET parameter in
parameter in a HIP I2 or in an UPDATE control packet. a HIP I2 or in an UPDATE 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. The HIP answer corresponds to the SDP answer
[RFC3264], but is HIP specific. Please refer also to the longer parameter [RFC3264] but is HIP specific. Please refer also to the
description of the "HIP offer" term above. longer 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
employing a Data Relay Server), two communicating HIP hosts try to employing a Data Relay Server), two communicating HIP hosts try to
"punch holes" through their NAT boxes using this mechanism. It is "punch holes" through their NAT boxes using this mechanism. It is
similar to the ICE connectivity checks, but implemented using HIP similar to the ICE connectivity checks but implemented using HIP
return routability checks. return routability checks.
Controlling host: Controlling host:
The controlling host [RFC8445] is always the Initiator in the The controlling host [RFC8445] is always the Initiator in the
context of this specification. It nominates the candidate pair to context of this specification. It nominates the candidate pair to
be used with the controlled host. be used with the controlled host.
Controlled host: Controlled host:
The controlled host [RFC8445] is always the Responder in the The controlled host [RFC8445] is always the Responder in the
context of this specification. It waits for the controlling to context of this specification. It waits for the controlling host
nominate an address candidate pair. to nominate an address candidate pair.
Checklist: Checklist:
A list of address candidate pairs that need to be tested for A list of address candidate pairs that need to be tested for
connectivity (same as in [RFC8445]). connectivity (same as in [RFC8445]).
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address (same Transport-layer port and the corresponding IPv4/v6 address (same
as in [RFC8445]). as in [RFC8445]).
Candidate: Candidate:
A transport address that is a potential point of contact for A transport address that is a potential point of contact for
receiving data (same as in [RFC8445]). receiving data (same as in [RFC8445]).
Host candidate: Host candidate:
A candidate obtained by binding to a specific port from an IP A candidate obtained by binding to a specific port from an IP
address on the host (same as in [RFC8445]). address on the host (same as in [RFC8445]).
Server reflexive candidate: Server-reflexive candidate:
A translated transport address of a host as observed by a Control A translated transport address of a host as observed by a Control
or Data Relay Server (same as in [RFC8445]). or Data Relay Server (same as in [RFC8445]).
Peer reflexive candidate: Peer-reflexive candidate:
A translated transport address of a host as observed by its peer A translated transport address of a host as observed by its peer
(same as in [RFC8445]). (same as in [RFC8445]).
Relayed candidate: Relayed candidate:
A transport address that exists on a Data Relay Server. Packets A transport address that exists on a Data Relay Server. Packets
that arrive at this address are relayed towards the Data Relay that arrive at this address are relayed towards the Data Relay
Client. The concept is the same as in [RFC8445], but a Data Relay Client. The concept is the same as in [RFC8445], but a Data Relay
Server is used instead of a TURN server. Server is used instead of a TURN server.
Permission: Permission:
In the context of Data Relay Server, permission refers to a In the context of Data Relay Server, permission refers to a
concept similar to TURN's ([RFC5766]) channels. Before a host can concept similar to TURN's [RFC8656] channels. Before a host can
use a relayed candidate to forward traffic through a Data Relay use a relayed candidate to forward traffic through a Data Relay
Server, the host must activate the relayed candidate with a Server, the host must activate the relayed candidate with a
specific peer host. specific peer host.
Base: Base:
Similarly as in [RFC8445], the base of a candidate is the local Similar to that described in [RFC8445], the base of a candidate is
source address a host uses to send packets for the associated the local source address a host uses to send packets for the
candidate. For example, the base of a server reflexive address is associated candidate. For example, the base of a server-reflexive
the local address the host used for registering itself to the address is the local address the host used for registering itself
associated Control or Data Relay Server. The base of a host to the associated Control or Data Relay Server. The base of a
candidate is equal to the host candidate itself. host candidate is equal to the host candidate itself.
3. Overview of Operation 3. Overview of Operation
+--------------+ +--------------+
| Control | | Control |
+--------+ | Relay Server | +--------+ +--------+ | Relay Server | +--------+
| Data | +----+-----+---+ | Data | | Data | +----+-----+---+ | Data |
| Relay | / \ | Relay | | Relay | / \ | Relay |
| Server | / \ | Server | | Server | / \ | Server |
+--------+ / \ +--------+ +--------+ / \ +--------+
skipping to change at page 9, line 10 skipping to change at line 387
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 a Control Relay Server at least the Responder must be registered with a Control Relay 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; connectivity with the Data Relay Server of the Responder
Responder may fail, so the Initiator may also need to register to a may fail, so the Initiator may also need to register to a Control
Cotrol and/or Data Relay Server. It is worth noting that a Control and/or Data Relay Server. It is worth noting that a Control and Data
and Data Relay does not forge the source address of a passing packet, Relay does not forge the source address of a passing packet but
but always translates the source address and source port of a packet always translates the source address and source port of a packet to
to be forwarded (to its own). be forwarded (to its own).
We assume, as a starting point, that the Initiator knows both the We assume, as a starting point, that the Initiator knows both the
Responder's Host Identity Tag (HIT) and the address(es) of the Responder's Host Identity Tag (HIT) and the address(es) of the
Responder's Control Relay Server(s) (how the Initiator learns of the Responder's Control Relay Server(s) (how the Initiator learns of the
Responder's Control Relay Server is outside of the scope of this Responder's Control Relay Server is outside of the scope of this
document, but may be through DNS or another name service). The first document, but it may be learned through DNS or another name service).
steps are for both the Initiator and Responder to register with a The first steps are for both the Initiator and Responder to register
Control Relay Server (need not be the same one) and gather a set of with a Control Relay Server (need not be the same one) and gather a
address candidates. The hosts use either Control Relay Servers or set of address candidates. The hosts use either Control Relay
Data Relay Servers for gathering the candidates. Next, the HIP base Servers or Data Relay Servers for gathering the candidates. Next,
exchange is carried out by encapsulating the HIP control packets in the HIP base exchange is carried out by encapsulating the HIP control
UDP datagrams and sending them through the Responder's Control Relay packets in UDP datagrams and sending them through the Responder's
Server. As part of the base exchange, each HIP host learns of the Control Relay Server. As part of the base exchange, each HIP host
peer's candidate addresses through the HIP offer/answer procedure learns of the peer's candidate addresses through the HIP offer/answer
embedded in the base exchange. procedure embedded in the base exchange.
Once the base exchange is completed, two HIP hosts have established a Once the base exchange is completed, two HIP hosts have established a
working communication session (for signaling) via a Control Relay working communication session (for signaling) via a Control Relay
Server, but the hosts still have to find a better path, preferably Server, but the hosts still have to find a better path, preferably
without a Data Relay Server, for the ESP data flow. For this, without a Data Relay Server, for the ESP data flow. For this,
connectivity checks are carried out until a working pair of addresses connectivity checks are carried out until a working pair of addresses
is discovered. At the end of the procedure, if successful, the hosts is discovered. At the end of the procedure, if successful, the hosts
will have established a UDP-based tunnel that traverses both NATs, will have established a UDP-based tunnel that traverses both NATs
with the data flowing directly from NAT to NAT or via a Data Relay with the data flowing directly from NAT to NAT or via a Data Relay
Server. At this point, also the HIP signaling can be sent over the Server. At this point, the HIP signaling can also be sent over the
same address/port pair, and is demultiplexed (or, in other words, same address/port pair, and is demultiplexed (or, in other words,
separated) from IPsec as described in the UDP encapsulation standard separated) from IPsec as described in the UDP encapsulation standard
for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as
needed in order keep their UDP-tunnel state active in the associated needed in order keep their UDP-tunnel state active in the associated
NAT boxes. NAT boxes.
If either one of the hosts knows that it is not behind a NAT, hosts If either one of the hosts knows that it is not behind a NAT, hosts
can negotiate during the base exchange a different mode of NAT can negotiate during the base exchange a different mode of NAT
traversal that does not use HIP connectivity checks, but only UDP traversal that does not use HIP connectivity checks, but only UDP
encapsulation of HIP and ESP. Also, it is possible for the Initiator encapsulation of HIP and ESP. Also, it is possible for the Initiator
skipping to change at page 10, line 20 skipping to change at line 445
This section describes the normative behavior of the "Native ICE-HIP" This section describes the normative behavior of the "Native ICE-HIP"
protocol extension. Most of the procedures are similar to what is protocol extension. Most of the procedures are similar to what is
defined in [RFC5770] but with different, or additional, parameter defined in [RFC5770] but with different, or additional, parameter
types and values. In addition, a new type of relaying server, Data types and values. In addition, a new type of relaying server, Data
Relay Server, is specified. Also, it should be noted that HIP Relay Server, is specified. Also, it should be noted that HIP
version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT
traversal mode. traversal mode.
4.1. Relay Registration 4.1. Relay Registration
In order for two hosts to communicate over NATted environments, they In order for two hosts to communicate over NATed environments, they
need a reliable way to exchange information. To achieve this, "HIP need a reliable way to exchange information. To achieve this, "HIP
Relay Server" is defined in [RFC5770]. It supports relaying of HIP Relay Server" is defined in [RFC5770]. It supports the relaying of
control plane traffic over UDP in NATted environments, and forwards HIP control plane traffic over UDP in NATed environments and forwards
HIP control packets between the Initiator and the Responder. In this HIP control packets between the Initiator and the Responder. In this
document, the HIP Relay Server is denoted as "Control Relay Server" document, the HIP Relay Server is denoted as "Control Relay Server"
for better alignment with the rest of the terminology. The for better alignment with the rest of the terminology. The
registration to the Control Relay Server can be achieved using registration to the Control Relay Server can be achieved using the
RELAY_UDP_HIP parameter as explained later in this section. RELAY_UDP_HIP parameter as explained later in this section.
To guarantee also data plane delivery over varying types of NAT To also guarantee data plane delivery over varying types of NAT
devices, a host MAY also register for UDP encapsulated ESP relaying devices, a host MAY also register for UDP-encapsulated ESP relaying
using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This using Registration Type RELAY_UDP_ESP (value 3). This service may be
service may be coupled with the Control Relay Server or offered coupled with the Control Relay Server or offered separately on
separately on another server. If the server supports relaying of UDP another server. If the server supports relaying of UDP-encapsulated
encapsulated ESP, the host is allowed to register for a data relaying ESP, the host is allowed to register for a data-relaying service
service using the registration extensions in Section 3.3 of using the registration extensions in Section 3.3 of [RFC8003]. If
[RFC8003]). If the server has sufficient relaying resources (free the server has sufficient relaying resources (free port numbers,
port numbers, bandwidth, etc.) available, it opens a UDP port on one bandwidth, etc.) available, it opens a UDP port on one of its
of its addresses and signals the address and port to the registering addresses and signals the address and port to the registering host
host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 using the RELAYED_ADDRESS parameter (as defined in Section 5.12 in
in this document). If the Data Relay Server would accept the data this document). If the Data Relay Server would accept the data-
relaying request but does not currently have enough resources to relaying request but does not currently have enough resources to
provide data relaying service, it MUST reject the request with provide data-relaying service, it MUST reject the request with
Failure Type "Insufficient resources" [RFC8003]. Failure Type "Insufficient resources" [RFC8003].
The registration process follows the generic registration extensions The registration process follows the generic registration extensions
defined in [RFC8003]. The HIP control plane relaying registration defined in [RFC8003]. The HIP control plane relaying registration
follows [RFC5770], but the data plane registration is different. It follows [RFC5770], but the data plane registration is different. It
is worth noting that if the HIP control and data plane relay services is worth noting that if the HIP control and data plane relay services
reside on different hosts, the client has to register separately to reside on different hosts, the client has to register separately to
each of them. In the example shown in Figure 2, the two services are each of them. In the example shown in Figure 2, the two services are
coupled on a single host. The text uses "Relay Client" and "Relay coupled on a single host. The text uses "Relay Client" and "Relay
Server" as a shorthand when the procedures apply both to control and Server" as a shorthand when the procedures apply both to control and
skipping to change at page 11, line 33 skipping to change at line 506
Figure 2: Example Registration with a HIP Relay Figure 2: Example Registration with a HIP Relay
In step 1, the Relay Client (Initiator) starts the registration In step 1, the Relay Client (Initiator) starts the registration
procedure by sending an I1 packet over UDP to the Relay Server. It procedure by sending an I1 packet over UDP to the Relay Server. It
is RECOMMENDED that the Relay Client select a random source port is RECOMMENDED that the Relay Client select a random source port
number from the ephemeral port range 49152-65535 for initiating a number from the ephemeral port range 49152-65535 for initiating a
base exchange. Alternatively, a host MAY also use a single fixed base exchange. Alternatively, a host MAY also use a single fixed
port for initiating all outgoing connections. However, the allocated port for initiating all outgoing connections. However, the allocated
port MUST be maintained until all of the corresponding HIP port MUST be maintained until all of the corresponding HIP
Associations are closed. It is RECOMMENDED that the Relay Server associations are closed. It is RECOMMENDED that the Relay Server
listen to incoming connections at UDP port 10500. If some other port listen to incoming connections at UDP port 10500. If some other port
number is used, it needs to be known by potential Relay Clients. number is used, it needs to be known by potential Relay Clients.
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 also supports the relaying of ESP
traffic over UDP, it includes also Registration type value traffic over UDP, it also includes the 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 Relay service by listing the RELAY_UDP_HIP registers for the Control Relay service by listing the RELAY_UDP_HIP
value in the request parameter. If the Relay Client requires also value in the request parameter. If the Relay Client also requires
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 a 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
worth noting that the Data Relay Client must first activate this UDP worth noting that the Data Relay Client must first activate this UDP
port by sending an UPDATE message to the Data Relay Server that port by sending an UPDATE message to the Data Relay Server that
includes a PEER_PERMISSION parameter as described in Section 4.12.1 includes a PEER_PERMISSION parameter as described in Section 4.12.1
both after base exchange and handover procedures. Also, the Data both after base exchange and handover procedures. Also, the Data
Relay Server should follow the port allocation recommendations in Relay Server should follow the port allocation recommendations in
Section 6.5. Section 7.5.
After the registration, the Relay Client sends periodically NAT After the registration, the Relay Client periodically sends NAT
keepalives to the Relay Server in order to keep the NAT bindings keepalives to the Relay Server in order to keep the NAT bindings
between the Relay Client and the relay alive. The keepalive between the Relay Client and the relay alive. The keepalive
extensions are described in Section 4.10. extensions are described in Section 4.10.
The Data Relay Client MUST maintain an active HIP association with The Data Relay Client MUST maintain an active HIP association with
the Data Relay Server as long as it requires the data relaying the Data Relay Server as long as it requires the data-relaying
service. When the HIP association is closed (or times out), or the service. When the HIP association is closed (or times out), or the
registration lifetime passes without the Data Relay Client refreshing registration lifetime passes without the Data Relay Client refreshing
the registration, the Data Relay Server MUST stop relaying packets the registration, the Data Relay Server MUST stop relaying packets
for that host and close the corresponding UDP port (unless other Data for that host and close the corresponding UDP port (unless other Data
Relay Clients are still using it). Relay Clients are still using it).
The Data Relay Server SHOULD offer a different relayed address and The Data Relay Server SHOULD offer a different relayed address and
port for each Data Relay Client because not doing so can cause port for each Data Relay Client because not doing so can cause
problems with stateful firewalls (see Section 6.5). problems with stateful firewalls (see Section 7.5).
When a Control Relay Client sends an UPDATE (e.g., due to host When a Control Relay Client sends an UPDATE (e.g., due to host
movement or to renew service registration), the Control Relay Server movement or to renew service registration), the Control Relay Server
MUST follow the general guidelines defined in [RFC8003], with the MUST follow the general guidelines defined in [RFC8003], with the
difference that all UPDATE messages are delivered on top of UDP. In difference that all UPDATE messages are delivered on top of UDP. In
addition to this, the Control Relay Server MUST include the REG_FROM addition to this, the Control Relay Server MUST include the REG_FROM
parameter in all UPDATE responses sent to the Control Relay Client. parameter in all UPDATE responses sent to the Control Relay Client.
This applies to both renewals of service registration and to host This applies to both renewals of service registration and to host
movement. It is especially important for the case of host movement, movement. It is especially important for the case of host movement,
as this is the mechanism that allows the Control Relay Client to as this is the mechanism that allows the Control Relay Client to
learn its new server reflexive address candidate. learn its new server-reflexive address candidate.
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 an 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 allocated 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 the
Relay Client MUST activate the UDP port as described in Data 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 a 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 a
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.
Please also refer to Section 6.8 for protection against cross- Please also refer to Section 7.8 for protection against cross-
protocol attacks for both Control Relay Client and Server. protocol attacks for both Control Relay Client and Server.
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).
The candidate gathering can be done at any time, but it needs to be The candidate gathering can be done at any time, but it needs to be
done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP
mode is to be used for the connectivity checks. It is RECOMMENDED mode is to be used for the connectivity checks. It is RECOMMENDED
that all three types of candidates (host, server reflexive, and that all three types of candidates (host, server reflexive, and
relayed) are gathered to maximize the probability of successful NAT relayed) are gathered to maximize the probability of successful NAT
traversal. However, if no Data Relay Server is used, and the host traversal. However, if no Data Relay Server is used, and the host
has only a single local IP address to use, the host MAY use the local has only a single local IP address to use, the host MAY use the local
address as the only host candidate and the address from the REG_FROM address as the only host candidate and the address from the REG_FROM
parameter discovered during the Control Relay Server registration as parameter discovered during the Control Relay Server registration as
a server reflexive candidate. In this case, no further candidate a server-reflexive candidate. In this case, no further candidate
gathering is needed. gathering is needed.
A Data Relay Client MAY register only a single relayed candidate that A Data Relay Client MAY register only a single relayed candidate that
it uses with multiple other peers. However, it is RECOMMENDED that a it uses with multiple other peers. However, it is RECOMMENDED that a
Data Relay Client registers a new server relayed candidate for each Data Relay Client registers a new server relayed candidate for each
of its peer for the reasons described in Section 4.12.3. The of its peers for the reasons described in Section 4.12.3. The
procedures for registering multiple relayed candidates are described procedures for registering multiple relayed candidates are described
in Section 4.1. in Section 4.1.
If a Relay Client has more than one network interface, it can If a Relay Client has more than one network interface, it can
discover additional server reflexive candidates by sending UPDATE discover additional server-reflexive candidates by sending UPDATE
messages from each of its interfaces to the Relay Server. Each such messages from each of its interfaces to the Relay Server. Each such
UPDATE message MUST include the following parameters: registration UPDATE message MUST include the following parameters: the
request (REG_REQ) parameter with Registration Type registration request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED CANDIDATE_DISCOVERY (value 4) and the ECHO_REQUEST_SIGNED parameter.
parameter. When a Control Relay Server receives an UPDATE message When a Control Relay Server receives an UPDATE message with
with registration request containing a CANDIDATE_DISCOVERY type, it registration request containing a CANDIDATE_DISCOVERY type, it MUST
MUST include a REG_FROM parameter, containing the same information as include a REG_FROM parameter, containing the same information as if
if this were a Control Relay Server registration, to the response (in this were a Control Relay Server registration, to the response (in
addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This
request type SHOULD NOT create any state at the Control Relay Server. request type SHOULD NOT create any state at the Control Relay Server.
The rules in section 5.1.1 in [RFC8445] for candidate gathering are The rules in Section 5.1.1 of [RFC8445] for candidate gathering are
followed here. A number of host candidates (loopback, anycast and followed here. A number of host candidates (loopback, anycast and
others) should be excluded as described in section 5.1.1.1 of the ICE others) should be excluded as described in the ICE specification
specification [RFC8445]. Relayed candidates SHOULD be gathered in (Section 5.1.1.1 of [RFC8445]). Relayed candidates SHOULD be
order to guarantee successful NAT traversal, and implementations gathered in order to guarantee successful NAT traversal, and
SHOULD support this functionality even if it will not be used in implementations SHOULD support this functionality even if it will not
deployments in order to enable it by software configuration update if be used in deployments in order to enable it by software
needed at some point. Similarly as explained in section 5.1.1.2 of configuration update if needed at some point. Similarly, as
the ICE specification [RFC8445], if an IPv6-only host is in a network explained in the ICE specification (Section 5.1.1.2 of [RFC8445]), if
that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it an IPv6-only host is in a network that utilizes NAT64 [RFC6146] and
may also gather IPv4 server- reflexive and/or relayed candidates from DNS64 [RFC6147] technologies, it may also gather IPv4 server-
IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also reflexive and/or relayed candidates from IPv4-only Control or Data
utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix
used by NAT64 (if any) and generate server-reflexive candidates for discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if
each IPv6-only interface, accordingly. The NAT64 server-reflexive any) and generate server-reflexive candidates for each IPv6-only
candidates are prioritized like IPv4 server-reflexive candidates. interface, accordingly. The NAT64 server-reflexive candidates are
prioritized like IPv4 server-reflexive candidates.
HIP based connectivity can be utilized by IPv4 applications using HIP-based connectivity can be utilized by IPv4 applications using
Local Scope Identifiers (LSIs) and by IPv6 based applications using Local Scope Identifiers (LSIs) and by IPv6-based applications using
HITs. The LSIs and HITs of the local virtual interfaces MUST be HITs. The LSIs and HITs of the local virtual interfaces MUST be
excluded in the candidate gathering phase as well to avoid creating excluded in the candidate gathering phase as well to avoid creating
unnecessary loopback connectivity tests. unnecessary loopback connectivity tests.
Gathering of candidates MAY also be performed by other means than Gathering of candidates MAY also be performed by other means than
described in this section. For example, the candidates could be described in this section. For example, the candidates could be
gathered as specified in Section 4.2 of [RFC5770] if STUN servers are gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
available, or if the host has just a single interface and no STUN or available, or if the host has just a single interface and no STUN or
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.1 in [RFC8445]): the RECOMMENDED values are defined in Section 5.1.2.1 of [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.
gathering stage yet.
Following the ICE specification, the local preference MUST be an Following the ICE specification, the local preference MUST be an
integer from 0 (lowest preference) to 65535 (highest preference) integer from 0 (lowest preference) to 65535 (highest preference)
inclusive. In the case the host has only a single address candidate, inclusive. In the case the host has only a single address candidate,
the value SHOULD be 65535. In the case of multiple candidates, each the value SHOULD be 65535. In the case of multiple candidates, each
local preference value MUST be unique. Dual-stack considerations for local preference value MUST be unique. Dual-stack considerations for
IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2. IPv6 also apply here as defined in Section 5.1.2.2 of [RFC8445].
Unlike with SDP used in conjunction with ICE, this protocol only Unlike with SDP used in conjunction with ICE, this protocol only
creates a single UDP flow between the two communicating hosts, so creates a single UDP flow between the two communicating hosts, so
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 of [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 (1000ms, Ta * (Num-Of-Cands)) RTO = MAX (1000 ms, 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 number of server-reflexive and relay candidates. A Of-Cands is the number of server-reflexive and relay candidates. A
smaller value than 1000 ms for the RTO MUST NOT be used. smaller value than 1000 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 new mode in the NAT_TRAVERSAL_MODE parameter in a HIP presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
base exchange means that the end-host supports NAT traversal base exchange means that the end host supports NAT traversal
extensions described in this document. As the parameter is non- extensions described in this document. As the parameter is non-
critical (as defined in Section 5.2.1 of [RFC7401]), it can be critical (as defined in Section 5.2.1 of [RFC7401]), it can be
ignored by a end-host, which means that the host is not required to ignored by an end host, which means that the 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 16, line 41 skipping to change at line 748
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))| | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+----------------------------------------------------------------->| +----------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., ENC(LOC_SET), ..)) | | 4. UDP(R2(.., ENC(LOC_SET), ..)) |
|<-----------------------------------------------------------------+ |<-----------------------------------------------------------------+
| | | |
Figure 3: Negotiation of NAT Traversal Mode Figure 3: Negotiation of NAT Traversal Mode
In step 1, the Initiator sends an I1 to the Responder. In step 2, In step 1, the Initiator sends an I1 to the Responder.
the Responder responds with an R1. As specified in [RFC5770], the
NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal In step 2, the Responder responds with an R1. As specified in
modes the Responder supports. The mode specified in this document is [RFC5770], the NAT_TRAVERSAL_MODE parameter in R1 contains a list of
ICE-HIP-UDP (value [TBD by IANA: 3]). NAT traversal modes the Responder supports. The mode specified in
this document is ICE-HIP-UDP (value 3).
In step 3, the Initiator sends an I2 that includes a In step 3, the Initiator sends an I2 that includes a
NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
Initiator from the list of modes offered by the Responder. If ICE- 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-HIP-UDP traversal mode, the packet. If the Initiator chose ICE-HIP-UDP traversal mode, the
Responder includes a LOCATOR_SET parameter in the R2 packet. With Responder includes a LOCATOR_SET parameter in the R2 packet. With
ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated
within an ENCRYPTED parameter according to the procedures in sections within an ENCRYPTED parameter according to the procedures in Sections
5.2.18 and 6.5 in [RFC7401]. The locators in R2, encoded like the 5.2.18 and 6.5 in [RFC7401]. The locators in R2, encoded like the
locators in I2, are the "ICE answer". If the NAT traversal mode locators in I2, are the "ICE answer". If the NAT traversal mode
selected by the Initiator is not supported by the Responder, the selected by the Initiator is not supported by the Responder, the
Responder SHOULD 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
skipping to change at page 18, line 15 skipping to change at line 819
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 IP 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
of the Responder. of the Responder.
Initiator Control Relay Server Responder Initiator Control Relay Server Responder
| 1. UDP(I1) | | | 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) | +--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
skipping to change at page 18, line 44 skipping to change at line 848
+--------------------------------->| 6. UDP(I2(ENC(LOC_SET), | +--------------------------------->| 6. UDP(I2(ENC(LOC_SET), |
| | RELAY_FROM, NAT_TM, TA_P))| | | RELAY_FROM, NAT_TM, TA_P))|
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(ENC(LOC_SET), | | | 7. UDP(R2(ENC(LOC_SET), |
| 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) | | 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) |
| RELAY_TO)) |<-------------------------------+ | RELAY_TO)) |<-------------------------------+
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
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 successfully registered Control Relay destination HIT belongs to a successfully registered Control Relay
Client (i.e., the host marked "Responder" in Figure 4), the Control Client (i.e., the host marked "Responder" in Figure 4), the Control
Relay Server processes the packet. Otherwise, the Control Relay Relay Server processes the packet. Otherwise, the Control Relay
Server MUST drop the packet silently. The Control Relay Server Server MUST drop the packet silently. The Control Relay Server
appends a RELAY_FROM parameter to the I1 packet, which contains the appends a RELAY_FROM parameter to the I1 packet, which contains the
transport source address and port of the I1 as observed by the transport source address and port of the I1 as observed by the
Control Relay Server. The Control Relay Server protects the I1 Control Relay Server. The Control Relay Server protects the I1
skipping to change at page 19, line 26 skipping to change at line 877
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 Section 5.8 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
Control Relay Server drops the packet silently if the source HIT Control Relay Server drops the packet silently if the source HIT
belongs to a Control Relay Client that has not successfully belongs to a Control Relay Client that has not successfully
registered. The Control Relay Server MAY verify the signature of the registered. The Control Relay Server MAY verify the signature of the
skipping to change at page 20, line 5 skipping to change at line 905
according to [RFC7401]. The Initiator MAY use the address in the according to [RFC7401]. The Initiator MAY use the address in the
RELAY_TO parameter as a local peer-reflexive candidate for this HIP RELAY_TO parameter as a local peer-reflexive candidate for this HIP
association if it is different from all known local candidates. The association if it is different from all known local candidates. The
Initiator replies with an I2 packet that uses the destination Initiator replies with an I2 packet that uses the destination
transport address of R1 as the source address and port. The I2 transport address of R1 as the source address and port. The I2
packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter
that lists all the HIP candidates (HIP offer) of the Initiator. The that lists all the HIP candidates (HIP offer) of the Initiator. The
candidates are encoded using the format defined in Section 5.7. The candidates are encoded using the format defined in Section 5.7. The
I2 packet MUST also contain a NAT traversal mode parameter that I2 packet MUST also contain a NAT traversal mode parameter that
includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its
key material generation are described in detail in sections 5.2.18 key material generation is described in detail in Sections 5.2.18 and
and 6.5 in [RFC7401]. 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 similar to that explained in step 2, and forwards the packet
the Responder. to the Responder.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC7401]. The Responder validates the RELAY_HMAC according to [RFC7401]. The Responder validates the RELAY_HMAC
according to Section 5.8 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 Hashed Message Authentication Code
with its key material generation are described in detail in sections (HMAC). The ENCRYPTED parameter along with its key material
5.2.18 and 6.5 in [RFC7401]. generation is described in detail in Sections 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 messages if they intend to use the LOCATOR_SET parameter in I2 and R2 messages if they intend to use
such servers for relaying HIP signaling immediately after the base such servers for relaying HIP signaling immediately after the base
skipping to change at page 20, line 50 skipping to change at line 951
Server throughout the lifetime of the host association that was used Server throughout the lifetime of the host association that was used
for forwarding the base exchange if the Responder includes it in the for forwarding the base exchange if the Responder includes it in the
locator parameter of the R2 message. 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 also supports 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 The connectivity checks follow the ICE methodology [ICE-NONSIP], but
[I-D.rosenberg-mmusic-ice-nonsip], but UDP encapsulated HIP control UDP-encapsulated HIP control messages are used instead of ICE
messages are used instead of ICE messages. As stated in the ICE messages. As stated in the ICE specification, the basic procedure
specification, the basic procedure for connectivity checks has three for connectivity checks has three phases: sorting the candidate pairs
phases: sorting the candidate pairs according their priority, sending according to their priority, sending checks in the prioritized order,
checks in the prioritized order and acknowledging the checks from the and acknowledging the checks from the peer host.
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 even during
mobility UPDATE procedures). In the case both communicating nodes mobility UPDATE procedures). In the case in which both communicating
are initiating the communications to each other using an I1 packet, nodes are initiating communication 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 of [RFC7401]; the
host with the "larger" HIT changes to its Role to Responder. In such host with the "larger" HIT changes its role to Responder. In such a
a case, the host changing its role to Responder MUST also switch to case, the host changing its role to Responder MUST also switch to the
controlled role. controlled role.
The protocol follows standard HIP UPDATE sending and processing rules The protocol follows standard HIP UPDATE sending and processing rules
as defined in section 6.11 and 6.12 in [RFC7401], but some new as defined in Sections 6.11 and 6.12 in [RFC7401], but some new
parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS,
NOMINATE). NOMINATE, PEER_PERMISSION, and RELAYED_ADDRESS).
4.6.1. Connectivity Check Procedure 4.6.1. Connectivity Check Procedure
Figure 5 illustrates connectivity checks in a simplified scenario, Figure 5 illustrates connectivity checks in a simplified scenario
where the Initiator and Responder have only a single candidate pair where the Initiator and Responder have only a single candidate pair
to check. Typically, NATs drop messages until both sides have sent to check. Typically, NATs drop messages until both sides have sent
messages using the same port pair. In this scenario, the Responder messages using the same port pair. In this scenario, the Responder
sends a connectivity check first but the NAT of the Initiator drops sends a connectivity check first but the NAT of the Initiator drops
it. However, the connectivity check from the Initiator reaches the it. However, the connectivity check from the Initiator reaches the
Responder because it uses the same port pair as the first message. Responder because it uses the same port pair as the first message.
It is worth noting that the message flow in this section is It is worth noting that the message flow in this section is
idealistic, and, in practice, more messages would be dropped, idealistic, and, in practice, more messages would be dropped,
especially in the beginning. For instance, connectivity tests always especially in the beginning. For instance, connectivity tests always
start with the candidates with the highest priority, which would be start with the candidates with the highest priority, which would be
skipping to change at page 22, line 43 skipping to change at line 1036
+-------------+------------------------------------+--------------->+ +-------------+------------------------------------+--------------->+
| | | | | | | |
| 10. ESP data traffic over UDP | | | 10. ESP data traffic over UDP | |
+<------------+------------------------------------+--------------->+ +<------------+------------------------------------+--------------->+
| | | | | | | |
Figure 5: Connectivity Checks Figure 5: Connectivity Checks
In step 1, the Responder sends a connectivity check to the Initiator In step 1, the Responder sends a connectivity check to the Initiator
that the NAT of the Initiator drops. The message includes a number that the NAT of the Initiator drops. The message includes a number
of parameters. As specified in [RFC7401]), the SEQ parameter of parameters. As specified in [RFC7401], the SEQ parameter includes
includes a running sequence identifier for the connectivity check. a running sequence identifier for the connectivity check. The
The candidate priority (denoted "CAND_PRIO" in the figure) describes candidate priority (denoted CAND_PRIO in the figure) describes the
the priority of the address candidate being tested. The priority of the address candidate being tested. The
ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a
nonce that the recipient must sign and echo back as it is. nonce that the recipient must sign and echo back as it is.
In step 2, the Initiator sends a connectivity check, using the same In step 2, the Initiator sends a connectivity check, using the same
address pair candidate as in the previous step, and the message address pair candidate as in the previous step, and the message
traverses successfully the NAT boxes. The message includes the same successfully traverses the NAT boxes. The message includes the same
parameters as in the previous step. It should be noted that the parameters as in the previous step. It should be noted that the
sequence identifier is locally assigned by the Initiator, so it can sequence identifier is locally assigned by the Initiator, so it can
be different than in the previous step. be different than in the previous step.
In step 3, the Responder has successfully received the previous In step 3, the Responder has successfully received the previous
connectivity check from the Initiator and starts to build a response connectivity check from the Initiator and starts to build a response
message. Since the message from the Initiator included a SEQ, the message. Since the message from the Initiator included a SEQ, the
Responder must acknowledge it using an ACK parameter. Also, the Responder must acknowledge it using an ACK parameter. Also, the
nonce contained in the echo request must be echoed back in an nonce contained in the echo request must be echoed back in an
ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The
Responder includes also a MAPPED_ADDRESS parameter (denoted Responder also includes a MAPPED_ADDRESS parameter (denoted
MAPPED_ADDR in the figure) that contains the transport address of the MAPPED_ADDR in the figure) that contains the transport address of the
Initiator as observed by the Responder (i.e. peer reflexive Initiator as observed by the Responder (i.e., peer-reflexive
candidate). This message is successfully delivered to the Initiator, candidate). This message is successfully delivered to the Initiator;
and upon reception the Initiator marks the candidate pair as valid. upon reception, the Initiator marks the candidate pair as valid.
In step 4, the Responder retransmits the connectivity check sent in In step 4, the Responder retransmits the connectivity check sent in
the first step, since it was not acknowledged yet. the first step, since it was not acknowledged yet.
In step 5, the Initiator responds to the previous connectivity check In step 5, the Initiator responds to the previous connectivity check
message from the Responder. The Initiator acknowledges the SEQ message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the parameter from the previous message using an ACK parameter and the
ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In
addition, it includes MAPPED_ADDR parameter that includes the peer addition, it includes the MAPPED_ADDR parameter that includes the
reflexive candidate. This response message is successfully delivered peer-reflexive candidate. This response message is successfully
to the Responder, and upon reception the Initiator marks the delivered to the Responder; upon reception, the Initiator marks the
candidate pair as valid. candidate pair as valid.
In step 6, despite the two hosts now having valid address candidates, In step 6, despite the two hosts now having valid address candidates,
the hosts still test the remaining address candidates in a similar the hosts still test the remaining address candidates in a similar
way as in the previous steps. It should be noted that each way as in the previous steps. It should be noted that each
connectivity check has a unique sequence number in the SEQ parameter. connectivity check has a unique sequence number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates In step 7, the Initiator has completed testing all address candidates
and nominates one address candidate to be used. It sends an UPDATE and nominates one address candidate to be used. It sends an UPDATE
message using the selected address candidates that includes a number message using the selected address candidates that includes a number
of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY, and the
NOMINATE parameter. NOMINATE parameter.
In step 8, the Responder receives the message with NOMINATE parameter In step 8, the Responder receives the message with the NOMINATE
from the Initiator. It sends a response that includes the NOMINATE parameter from the Initiator. It sends a response that includes the
parameter in addition to a number of other parameters. The ACK and NOMINATE parameter in addition to a number of other parameters. The
ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
ECHO_REQUEST_SIGNED parameters from previous message from the ECHO_REQUEST_SIGNED parameters from the previous message from the
Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED
parameters in order to receive an acknowledgment from the Responder. parameters in order to receive an acknowledgment from the Responder.
In step 9, the Initiator completes the candidate nomination process In step 9, the Initiator completes the candidate nomination process
by confirming the message reception to the Responder. In the by confirming the message reception to the Responder. In the
confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters
correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the
message sent by the Responder in the previous step. message sent by the Responder in the previous step.
In step 10, the Initiator and Responder can start sending application In step 10, the Initiator and Responder can start sending application
payload over the successfully nominated address candidates. payload over the successfully nominated address candidates.
It is worth noting that if either host has registered a relayed It is worth noting that if either host has registered a relayed
address candidate from a Data Relay Server, the host MUST activate address candidate from a Data Relay Server, the host MUST activate
the address before connectivity checks by sending an UPDATE message the address before connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1. containing the PEER_PERMISSION parameter as described in
Otherwise, the Data Relay Server drops ESP packets using the relayed Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets
address. using the relayed address.
It should be noted that in the case both Initiator and Responder both It should be noted that in the case in which both the Initiator and
advertising their own relayed address candidates, it is possible that Responder are advertising their own relayed address candidates, it is
the two hosts choose the two relayed addresses as a result of the ICE possible that the two hosts choose the two relayed addresses as a
nomination algorithm. While this is possible (and even could be result of the ICE nomination algorithm. While this is possible (and
desirable for privacy reasons), it can be unlikely due to low even could be desirable for privacy reasons), it can be unlikely due
priority assigned for the relayed address candidates. In such a to low priority assigned for the relayed address candidates. In such
event, the nominated address pair is always symmetric; the nomination an event, the nominated address pair is always symmetric; the
algorithm prevents asymmetric address pairs (i.e. each side choosing nomination algorithm prevents asymmetric address pairs (i.e., each
different pair), such as a Data Relay Client using its own Data Relay side choosing different pair) such as a Data Relay Client using its
Server to send data directly to its peer while receiving data from own Data Relay Server to send data directly to its peer while
the Data Relay Server of its peer. receiving data from the Data Relay Server of its peer.
4.6.2. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
The HITs of the two communicating hosts MUST be used as credentials The HITs of the two communicating hosts MUST be used as credentials
in this protocol (in contrast to ICE which employs username-password in this protocol (in contrast to ICE, which employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a association, and a SEQ number in an UPDATE message identifies a
particular connectivity check. particular connectivity check.
All of the connectivity check messages MUST be protected with All of the connectivity check messages MUST be protected with
HIP_HMAC and signatures (even though the illustrations in this HIP_HMAC and signatures (even though the illustrations in this
specification omit them for simplicity) according to [RFC7401]. Each specification omit them for simplicity) according to [RFC7401]. Each
connectivity check sent by a host MUST include a SEQ parameter and connectivity check sent by a host MUST include a SEQ parameter and
ECHO_REQUEST_SIGNED parameter, and correspondingly the peer MUST ECHO_REQUEST_SIGNED parameter; correspondingly, the peer MUST respond
respond to these using ACK and ECHO_RESPONSE_SIGNED according to the to these using ACK and ECHO_RESPONSE_SIGNED according to the rules
rules specified in [RFC7401]. 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] section 5.3.5 states that UPDATE packets have to include Section 5.3.5 of [RFC7401] states that UPDATE packets have to include
either a SEQ or ACK parameter (but can include both). In the either a SEQ or ACK parameter (but can include both). In the
connectivity check procedure specified in Section 4.6.1, each SEQ connectivity check procedure specified in Section 4.6.1, each SEQ
parameter should be acknowledged separately. In the context of NATs, parameter should be acknowledged separately. In the context of NATs,
this means that some of the SEQ parameters sent in connectivity this means that some of the SEQ parameters sent in connectivity
checks will be lost or arrive out of order. From the viewpoint of checks will be lost or arrive out of order. From the viewpoint of
the recipient, this is not a problem since the recipient will just the recipient, this is not a problem since the recipient will just
"blindly" acknowledge the SEQ. However, the sender needs to be "blindly" acknowledge the SEQ. However, the sender needs to be
prepared for lost sequence identifiers and ACKs parameters that prepared for lost sequence identifiers and ACK parameters that arrive
arrive out of order. 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 may thus 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 checklists (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 of that the foundation, frozen of [RFC8445], with the exception being that the foundation, frozen
candidates and default candidates are not used. From viewpoint of candidates, and default candidates are not used. From the viewpoint
the ICE specification [RFC8445], the protocol specified in this of the ICE specification [RFC8445], the protocol specified in this
document operates using Component ID of 1 on all candidates, and the document operates using a component ID of 1 on all candidates, and
foundation of all candidates is unique. This specification defines the foundation of all candidates is unique. This specification
only "full ICE" mode, and the "lite ICE" is not supported. The defines only "full ICE" mode, and the "lite ICE" is not supported.
reasoning behind the missing features is described in Appendix B. The 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
transactions every Ta milliseconds as long as the checks are running transactions every Ta milliseconds as long as the checks are running
and there are candidate pairs whose tests have not started. The and there are candidate pairs whose tests have not started. The
retransmission timeout (RTO) for the connectivity check UPDATE retransmission timeout (RTO) for the connectivity check UPDATE
packets SHOULD be calculated as follows: packets SHOULD be calculated as follows:
RTO = MAX (1000ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (1000 ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
"In-Progress" state. This is identical to the formula in [RFC8445] "In-Progress" state. This is identical to the formula in [RFC8445]
when there is only one checklist. A smaller value than 1000 ms for when there is only one checklist. A smaller value than 1000 ms for
the RTO MUST NOT be used. the RTO MUST NOT be used.
Each connectivity check request packet MUST contain a Each connectivity check request packet MUST contain a
CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority
value that would be assigned to a peer reflexive candidate if one was value that would be assigned to a peer-reflexive candidate if one was
learned from the corresponding check. An UPDATE packet that learned from the corresponding check. An UPDATE packet that
acknowledges a connectivity check request MUST be sent from the same acknowledges a connectivity check request MUST be sent from the same
address that received the check and delivered to the same address address that received the check and delivered to the same address
where the check was received from. Each acknowledgment UPDATE packet where the check was received from. Each acknowledgment UPDATE packet
MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and
IP address of the address where the connectivity check request was IP address of the address where the connectivity check request was
received from. received from.
Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict
the total number of connectivity checks to 100 for each host the total number of connectivity checks to 100 for each host
association. This can be achieved by limiting the connectivity association. This can be achieved by limiting the connectivity
checks to the 100 candidate pairs with the highest priority. checks to the 100 candidate pairs with the highest priority.
4.6.3. Rules for Concluding Connectivity Checks 4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence UPDATE message that contains a SEQ parameter (with a new sequence
number), a ECHO_REQUEST_SIGNED parameter, the priority of the number), an ECHO_REQUEST_SIGNED parameter, the priority of the
candidate in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to candidate in a CANDIDATE_PRIORITY parameter, and a NOMINATE parameter
signify conclusion of the connectivity checks. Since the nominated to signify conclusion of the connectivity checks. Since the
address pair has already been tested for reachability, the controlled nominated address pair has already been tested for reachability, the
host should be able to receive the message. Upon reception, the controlled host should be able to receive the message. Upon
controlled host SHOULD select the nominated address pair. The reception, the controlled host SHOULD select the nominated address
response message MUST include a SEQ parameter with a new sequence id, pair. The response message MUST include a SEQ parameter with a new
acknowledgment of the sequence from the controlling host in an ACK sequence identifier, acknowledgment of the sequence from the
parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED controlling host in an ACK parameter, a new ECHO_REQUEST_SIGNED
parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the parameter, an ECHO_RESPONSE_SIGNED parameter corresponding to the
controlling host and the NOMINATE parameter. After sending this ECHO_REQUEST_SIGNED parameter from the controlling host, and the
packet, the controlled host can create IPsec security associations NOMINATE parameter. After sending this packet, the controlled host
using the nominated address candidate for delivering application can create IPsec security associations using the nominated address
payload to the controlling host. Since the message from the candidate for delivering application payload to the controlling host.
controlled host included a new sequence id and echo request for Since the message from the controlled host included a new sequence
signature, the controlling host MUST acknowledge this with a new identifier echo request for the signature, the controlling host MUST
UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED acknowledge this with a new UPDATE message that includes an ACK and
parameters. After this final concluding message, the controlling ECHO_RESPONSE_SIGNED parameters. After this final concluding
host also can create IPsec security associations for delivering message, the controlling host also can create IPsec security
application payload to the controlled host. associations for delivering application payload to the controlled
host.
It is possible that packets are delayed by the network. Both hosts It is possible that packets are delayed by the network. Both hosts
MUST continue to respond to any connectivity checks despite an MUST continue to respond to any connectivity checks despite an
address pair having been nominated. address pair having been nominated.
If all the connectivity checks have failed, the hosts MUST NOT send If all the connectivity checks have failed, the hosts MUST NOT send
ESP traffic to each other but MAY continue communicating using HIP ESP traffic to each other but MAY continue communicating using HIP
packets and the locators used for the base exchange. Also, the hosts packets and the locators used for the base exchange. Also, the hosts
SHOULD notify each other about the failure with a SHOULD notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
4.7. NAT Traversal Optimizations 4.7. NAT Traversal Optimizations
4.7.1. Minimal NAT Traversal Support 4.7.1. Minimal NAT Traversal Support
If the Responder has a fixed and publicly reachable IPv4 address and If the Responder has a fixed and publicly reachable IPv4 address and
does not employ a Control Relay Server, the explicit NAT traversal does not employ a Control Relay Server, the explicit NAT traversal
mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode negotiation MAY be omitted; thus, even the UDP-ENCAPSULATION
mode does not have to be negotiated. In such a scenario, the mode does not have to be negotiated. In such a scenario, the
Initiator sends an I1 message over UDP and the Responder responds Initiator sends an I1 message over UDP and the Responder responds
with an R1 message over UDP without including any NAT traversal mode with an R1 message over UDP without including any NAT traversal mode
parameter. The rest of the base exchange follows the procedures parameter. The rest of the base exchange follows the procedures
defined in [RFC7401], except that the control and data plane use UDP defined in [RFC7401], except that the control and data plane use UDP
encapsulation. Here, the use of UDP for NAT traversal is agreed encapsulation. Here, the use of UDP for NAT traversal is agreed upon
implicitly. This way of operation is still subject to NAT timeouts, implicitly. This way of operation is still subject to NAT timeouts,
and the hosts MUST employ NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
When UDP-ENCAPSULATION mode is chosen either explicitly or When UDP-ENCAPSULATION mode is chosen either explicitly or
implicitly, the connectivity checks as defined in this document MUST implicitly, the connectivity checks as defined in this document MUST
NOT be used. When hosts lose connectivity, they MUST instead utilize NOT be used. When hosts lose connectivity, they MUST instead utilize
[RFC8046] or [RFC8047] procedures, but with the difference being that [RFC8046] or [RFC8047] procedures, but with the difference being that
UDP-based tunneling MUST be employed for the entire lifetime of the UDP-based tunneling MUST be employed for the entire lifetime of the
corresponding Host Association. corresponding HIP association.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is as defined in Legacy ICE-HIP (Section 4.8 of [RFC5770]). The
applicable also in the context of this specification, so it is procedure is also applicable in the context of this specification, so
repeated here for completeness. it is repeated here for completeness.
In certain network environments, the connectivity checks can be In certain network environments, the connectivity checks can be
omitted to reduce initial connection set-up latency because a base omitted to reduce initial connection setup latency because a base
exchange acts as an implicit connectivity test itself. For this to exchange acts as an implicit connectivity test itself. For this to
work, the Initiator MUST be able to reach the Responder by simply UDP work, the Initiator 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 encapsulated inside an ENCRYPTED parameter in R1 message parameter encapsulated inside an ENCRYPTED parameter in an R1 message
that contains a preferred address where the Responder is able to that contains a preferred address where the Responder is able to
receive UDP-encapsulated ESP and HIP packets. This locator MUST be receive UDP-encapsulated ESP and HIP packets. This locator MUST be
of type "Transport address", its Traffic type MUST be "both", and it of type "Transport address", its Traffic type MUST be "both", and it
MUST have the "Preferred bit" set (see Table 1). If there is no such MUST have the "Preferred bit" set (see Table 2). If there is no such
locator in R1, the Initiator MUST use the source address of the R1 as 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
in I2 but they MUST NOT be taken as address candidates, since in I2 but they MUST NOT be taken as address candidates, since
connectivity checks defined in this document will not be used for connectivity checks defined in this document will not be used for
connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
R2 and I2 are received and processed successfully, a security R2 and I2 are received and processed successfully, a security
association can be created and UDP-encapsulated ESP can be exchanged association can be created and UDP-encapsulated ESP can be exchanged
between the hosts after the base exchange completes according to the between the hosts after the base exchange completes according to the
rules in Section 4.4 in [RFC7401]. rules in Section 4.4 of [RFC7401].
The Control Relay Server can be used for discovering address The Control Relay Server can be used for discovering address
candidates but it is not intended to be used for relaying end-host candidates but it is not intended to be used for relaying end-host
packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet
with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent
via a Control Relay Server, the Responder SHOULD reject such I2 via a Control Relay Server, the Responder SHOULD reject such I2
packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY
packet (see Section 5.10). packet (see Section 5.10).
If there is no answer for the I2 packet sent directly to the If there is no answer for the I2 packet sent directly to the
Responder's preferred address, the Initiator MAY send another I2 via Responder's preferred address, the Initiator MAY send another I2 via
the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION
NAT traversal mode for that I2. NAT traversal mode for that I2.
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange Both with and without UDP
Encapsulation Encapsulation
It is possible to run a base exchange in parallel both with and It is possible to run a base exchange in parallel both with and
without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in without UDP encapsulation as defined in Legacy ICE-HIP (Section 4.9
[RFC5770]. The procedure is applicable also in the context of this of [RFC5770]). The procedure is also applicable in the context of
specification, so it is repeated here for completeness. this specification, so it is repeated here for completeness.
The Initiator MAY also try to simultaneously perform a base exchange The Initiator MAY also try to simultaneously perform a base exchange
with the Responder without UDP encapsulation. In such a case, the with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while encapsulation, to the Responder. The Initiator MAY wait for a while
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly, without The I1 packet without UDP encapsulation may arrive directly, without
passing any a Control Relay Server, at the Responder. When this passing a Control Relay Server, at the Responder. When this happens,
happens, the procedures in [RFC7401] are followed for the rest of the the procedures in [RFC7401] are followed for the rest of the base
base exchange. The Initiator may receive multiple R1 packets, with exchange. The Initiator may receive multiple R1 packets, with and
and without UDP encapsulation, from the Responder. However, after 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
service, the middlebox follows rendezvous procedures in [RFC8004]. service, the middlebox follows rendezvous procedures in [RFC8004].
If the Initiator receives a NAT traversal mode parameter in R1 If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter without UDP encapsulation, the Initiator MAY ignore this parameter
and send an I2 without UDP encapsulation and without any selected NAT and send an I2 without UDP encapsulation and without any selected NAT
traversal mode. When the Responder receives the I2 without UDP traversal mode. When the Responder receives the I2 without UDP
encapsulation and without NAT traversal mode, it will assume that no encapsulation and without NAT traversal mode, it will assume that no
NAT traversal mechanism is needed. The packet processing will be NAT traversal mechanism is needed. The packet processing will be
done as described in [RFC7401]. The Initiator MAY store the NAT done as described in [RFC7401]. The Initiator MAY store the NAT
traversal modes for future use, e.g., in case of a mobility or traversal modes for future use, e.g., in case of a mobility or
multihoming event that causes NAT traversal to be used during the multihoming event that causes NAT traversal to be used during the
lifetime of the HIP association. lifetime of the HIP association.
4.8. Sending Control Packets after the Base Exchange 4.8. Sending Control Packets after the Base Exchange
The same considerations of sending control packets after the base The same considerations with regard to sending control packets after
exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply the base exchange as described in Legacy ICE-HIP (Section 5.10 of
also here, so they are repeated here for completeness. [RFC5770]) also apply 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 according the rules its LOCATOR_SET parameter in the base exchange according to the rules
specified in section 4.4.2 in [RFC7401]. specified in Section 4.4.2 of [RFC7401]).
If Control Relay Client sends a packet through a Control Relay If a 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.
If the Control Relay Server is not willing or able to relay a HIP If the Control Relay Server is not willing or able to relay a HIP
packet, it MAY notify the sender of the packet with packet, it MAY notify the sender of the packet with a
MESSAGE_NOT_RELAYED error notification (see Section 5.10). MESSAGE_NOT_RELAYED error notification (see Section 5.10).
4.9. Mobility Handover Procedure 4.9. Mobility Handover Procedure
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [RFC8046] define handover procedures Mobility extensions for HIP [RFC8046] define handover procedures
without NATs. In this section, we define how two hosts interact with without NATs. In this section, we define how two hosts interact with
handover procedures in scenarios involving NATs. The specified handover procedures in scenarios involving NATs. The specified
extensions define only simple mobility using a pair of security extensions define only simple mobility using a pair of security
associations, and multihoming extensions are left to be defined in associations, and multihoming extensions are left to be defined in
skipping to change at page 31, line 7 skipping to change at line 1435
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
Prior to starting the handover procedures with all peer hosts, the Prior to starting the handover procedures with all peer hosts, the
mobile host SHOULD first send its locators in UPDATE messages to its mobile host SHOULD first send its locators in UPDATE messages to its
Control and Data Relay Servers if it has registered to such. It Control and Data Relay Servers if it has registered to such. It
SHOULD wait for all of them to respond for a configurable time, by SHOULD wait for all of them to respond for a configurable time, by
default two minutes, and then continue with the handover procedure default two minutes, and then continue with the handover procedure
without information from the Relay Server that did not respond. As without information from the Relay Server that did not respond. As
defined in Section 4.1, a response message from a Control Relay defined in Section 4.1, a response message from a Control Relay
Server includes a REG_FROM parameter that describes the server Server includes a REG_FROM parameter that describes the server-
reflexive candidate of the mobile host to be used in the candidate reflexive candidate of the mobile host to be used in the candidate
exchange during the handover. Similarly, an UPDATE to a Data Relay exchange during the handover. Similarly, an UPDATE to a Data Relay
Server is necessary to make sure the Data Relay Server can forward Server is necessary to make sure the Data Relay Server can forward
data to the correct IP address after a handoff. data to the correct IP address after a handover.
The mobility extensions for NAT traversal are illustrated in The mobility extensions for NAT traversal are illustrated in
Figure 6. The mobile host is the host that has changed its locators, Figure 6. The mobile host is the host that has changed its locators,
and the peer host is the host it has a host association with. The and the peer host is the host it has a host association with. The
mobile host may have multiple peers and it repeats the process with mobile host may have multiple peers, and it repeats the process with
all of its peers. In the figure, the Control Relay Server belongs to all of its peers. In the figure, the Control Relay Server belongs to
the peer host, i.e., the peer host is a Control Relay Client for the the peer host, i.e., the peer host is a Control Relay Client for the
Control Relay Server. Note that the figure corresponds to figure 3 Control Relay Server. Note that the figure corresponds to figure 3
in [RFC8046], but the difference is that the main UPDATE procedure is in [RFC8046], but the difference is that the main UPDATE procedure is
carried over the relay and the connectivity is tested separately. carried over the relay and the connectivity is tested separately.
Next, we describe the procedure in the figure in detail. Next, we describe the procedure of that figure in detail.
Mobile Host Control Relay Server Peer Host Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
| ENC(LOC_SET), SEQ)) | | | ENC(LOC_SET), SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | ENC(LOC_SET), SEQ, | | | ENC(LOC_SET), SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(UPDATE(ESP_INFO, SEQ, | | | 3. UDP(UPDATE(ESP_INFO, SEQ, |
skipping to change at page 32, line 35 skipping to change at line 1482
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| 7. connectivity checks over UDP | | 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 8. ESP data over UDP | | 8. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
Figure 6: HIP UPDATE procedure Figure 6: HIP UPDATE Procedure
In step 1, the mobile host has changed location and sends a location In step 1, the mobile host has changed location and sends a location
update to its peer through the Control Relay Server of the peer. It update to its peer through the Control Relay Server of the peer. It
sends an UPDATE packet with source HIT belonging to itself and sends an UPDATE packet with the source HIT belonging to itself and
destination HIT belonging to the peer host. In the packet, the destination HIT belonging to the peer host. In the packet, the
source IP address belongs to the mobile host and the destination to source IP address belongs to the mobile host and the destination to
the Control Relay Server. The packet contains an ESP_INFO parameter, the Control Relay Server. The packet contains an ESP_INFO parameter
where, in this case, the OLD SPI and NEW SPI parameters both contain where, in this case, the OLD SPI and NEW SPI parameters both contain
the pre-existing incoming SPI. The packet also contains the locators the pre-existing incoming SPI. The packet also contains the locators
of the mobile host in a LOCATOR_SET parameter, encapsulated inside an of the mobile host in a LOCATOR_SET parameter, encapsulated inside an
ENCRYPTED parameter (see sections 5.2.18 and 6.5 in [RFC7401] for ENCRYPTED parameter (see Sections 5.2.18 and 6.5 in [RFC7401] for
details on the ENCRYPTED parameter). The packet contains also a SEQ details on the ENCRYPTED parameter). The packet also contains a SEQ
number to be acknowledged by the peer. As specified in [RFC8046], number to be acknowledged by the peer. As specified in [RFC8046],
the packet may also include a HOST_ID (for middlebox inspection) and the packet may also include a HOST_ID (for middlebox inspection) and
DIFFIE_HELLMAN parameter for rekeying. DIFFIE_HELLMAN parameter for rekeying.
In step 2, the Control Relay Server receives the UPDATE packet and In step 2, the Control Relay Server receives the UPDATE packet and
forwards it to the peer host (i.e. Control Relay Client). The forwards it to the peer host (i.e., Control Relay Client). The
Control Relay Server rewrites the destination IP address and appends Control Relay Server rewrites the destination IP address and appends
a RELAY_FROM parameter to the message. a RELAY_FROM parameter to the message.
In step 3, the peer host receives the UPDATE packet, processes it and In step 3, the peer host receives the UPDATE packet, processes it,
responds with another UPDATE message. The message is destined to the and responds with another UPDATE message. The message is destined to
HIT of mobile host and to the IP address of the Control Relay Server. the HIT of the mobile host and to the IP address of the Control Relay
The message includes an ESP_INFO parameter where, in this case, the Server. The message includes an ESP_INFO parameter where, in this
OLD SPI and NEW SPI parameters both contain the pre-existing incoming case, the OLD SPI and NEW SPI parameters both contain the pre-
SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters existing incoming SPI. The peer includes a new SEQ and
to be acknowledged by the mobile host. The message acknowledges the ECHO_REQUEST_SIGNED parameter to be acknowledged by the mobile host.
SEQ parameter of the earlier message with an ACK parameter. The The message acknowledges the SEQ parameter of the earlier message
RELAY_TO parameter specifies the address of the mobile host where the with an ACK parameter. The RELAY_TO parameter specifies the address
Control Relay Server should forward the message. of the mobile host where the Control Relay Server should forward the
message.
In step 4, the Control Relay Server receives the message, rewrites In step 4, the Control Relay Server receives the message, rewrites
the destination IP address and UDP port according to the RELAY_TO the destination IP address and UDP port according to the RELAY_TO
parameter, and then forwards the modified message to the mobile host. parameter, and then forwards the modified message to the mobile host.
In step 5, the mobile host receives the UPDATE packet and processes In step 5, the mobile host receives the UPDATE packet and processes
it. The mobile host concludes the handover procedure by it. The mobile host concludes the handover procedure by
acknowledging the received SEQ parameter with an ACK parameter and acknowledging the received SEQ parameter with an ACK parameter and
the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED the ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED
parameter. The mobile host delivers the packet to the HIT of the parameter. The mobile host sends the packet to the HIT of the peer
peer and to the address of the HIP relay. The mobile host can start and to the address of the HIP relay. The mobile host can start
connectivity checks after this packet. connectivity checks after this packet.
In step 6, HIP relay receives the UPDATE packet and forwards it to In step 6, the HIP relay receives the UPDATE packet and forwards it
the peer host (i.e. Relay Client). The HIP relay rewrites the to the peer host (i.e., Relay Client). The HIP relay rewrites the
destination IP address and port, and then appends a RELAY_FROM destination IP address and port, and then appends a RELAY_FROM
parameter to the message. When the peer host receives this parameter to the message. When the peer host receives this
concluding UPDATE packet, it can initiate the connectivity checks. concluding UPDATE packet, it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according In step 7, the two hosts test for connectivity across NATs according
to procedures described in Section 4.6. The original Initiator of to procedures described in Section 4.6. The original Initiator of
the communications is the controlling and the original Responder is the communications is the controlling host and the original Responder
the controlled host. is the controlled host.
In step 8, the connectivity checks are successfully completed and the In step 8, the connectivity checks are successfully completed and the
controlling host has nominated one address pair to be used. The controlling host has nominated one address pair to be used. The
hosts set up security associations to deliver the application hosts set up security associations to deliver the application
payload. payload.
It is worth noting that the Control and Data Relay Client do not have It is worth noting that the Control and Data Relay Client do not have
to re-register for the related services after a handoff. However, if to reregister for the related services after a handover. However, if
a Data Relay Client has registered a relayed address candidate from a a Data Relay Client has registered a relayed address candidate from a
Data Relay Server, the Data Relay Client MUST reactivate the address Data Relay Server, the Data Relay Client MUST reactivate the address
before the connectivity checks by sending an UPDATE message before the connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1. containing the PEER_PERMISSION parameter as described in
Otherwise, the Data Relay Server drops ESP packets sent to the Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets
relayed address. sent to the relayed address.
In so called "double jump" or simultaneous mobility scenario both In the so-called "double jump" or simultaneous mobility scenario,
peers change their location simultaneously. In such a case, both both peers change their location simultaneously. In such a case,
peers trigger the procedure described earlier in this section at the both peers trigger the procedure described earlier in this section at
same time. In other words, both of the communicating hosts send an the same time. In other words, both of the communicating hosts send
UPDATE packet carrying locators at the same time or with some delay. an UPDATE packet carrying locators at the same time or with some
When the locators are exchanged almost simultaneously (reliably via delay. When the locators are exchanged almost simultaneously
Control Relay Servers), the two hosts can continue with connectivity (reliably via Control Relay Servers), the two hosts can continue with
checks after both have completed separately the steps in Figure 6. connectivity checks after both have completed separately the steps in
The problematic case occurs when one of the hosts (referred here as Figure 6. The problematic case occurs when one of the hosts
host "M") moves later during the connectivity checks. In such a (referred to here as host "M") moves later during the connectivity
case, host M sends a locator to the peer which is in the middle of checks. In such a case, host M sends a locator to the peer, which is
connectivity checks. Upon receiving the UPDATE message, the peer in the middle of connectivity checks. Upon receiving the UPDATE
responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in message, the peer responds with an UPDATE with ECHO_REQ_SIGN as
Figure 6. Upon receiving the valid response from host M as described described in step 3 in Figure 6. Upon receiving the valid response
in step 6, the peer host MUST restart the connectivity checks with from host M as described in step 6, the peer host MUST restart the
host M. This way, both hosts start the connectivity checks roughly connectivity checks with host M. This way, both hosts start the
in a synchronized way. It is also important that peer host does not connectivity checks roughly in a synchronized way. It is also
restart the connectivity checks until the step 6 is successfully important that the peer host does not restart the connectivity checks
completed because the UPDATE message carrying locators in step 1 until step 6 is successfully completed, because the UPDATE message
could be replayed by an attacker. carrying locators in step 1 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). HIP 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-
UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged
some other traffic over the used UDP ports. However, the Data Relay some other traffic over the used UDP ports. However, the Data Relay
Client and Data Relay Server MUST employ only HIP NOTIFY packets in Client and Data Relay Server MUST employ only HIP NOTIFY packets in
order to keep the server reflexive candidates alive. The keepalive order to keep the server-reflexive candidates alive. The keepalive
message encoding format is defined in Section 5.3. If the base message encoding format is defined in Section 5.3. If the base
exchange or mobility handover procedure occurs during an extremely exchange or mobility handover procedure occurs during an extremely
slow path, a host (with a Host Association with the peer) MAY also slow path, a host (with a HIP association with the peer) MAY also
send HIP NOTIFY packets every 15 seconds to keep the path active with send HIP NOTIFY packets every 15 seconds to keep the path active with
the recipient. the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP association and the related The two-way procedure for closing a HIP association and the related
security associations is defined in [RFC7401]. One host initiates security associations is defined in [RFC7401]. One host initiates
the procedure by sending a CLOSE message and the recipient confirms the procedure by sending a CLOSE message and the recipient confirms
it with CLOSE_ACK. All packets are protected using HMACs and it with CLOSE_ACK. All packets are protected using HMACs and
signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED signatures, and the CLOSE messages include an 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 also applies 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 Relay Server SHOULD respond directly. If CLOSE message came Control Relay Server SHOULD respond directly. If the CLOSE message
via a Control Relay Server, the host SHOULD respond using the same came via a Control Relay Server, the host SHOULD respond using the
Control Relay Server. same 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
channels, based on the Security Parameter Index (SPI) values in the channels, based on the Security Parameter Index (SPI) values in the
ESP packets. ESP packets.
Permissions are not required for HIP control packets. However, if a Permissions are not required for HIP control packets. However, if a
relayed address (as conveyed in the RELAYED_ADDRESS parameter from relayed address (as conveyed in the RELAYED_ADDRESS parameter from
the Data Relay Server) is selected to be used for data, the Control the Data Relay Server) is selected to be used for data, the Control
Relay Client MUST send an UPDATE message to the Data Relay Server Relay Client MUST send an UPDATE message to the Data Relay Server
containing a PEER_PERMISSION parameter (see Section 5.13) with the containing a PEER_PERMISSION parameter (see Section 5.13) with the
following information: the UDP port and address for the server following information: the UDP port and address for the server-
reflexive address, the UDP port and address of the peer, and the reflexive address, the UDP port and address of the peer, and the
inbound and outbound SPIs used for ESP. The packet MUST be sent to inbound and outbound SPIs used for ESP. The packet MUST be sent to
the same UDP tunnel the Client employed in the base exchange to the same UDP tunnel the Client employed in the base exchange to
contact the Server (i.e., not to the port occupied by the server contact the Server (i.e., not to the port occupied by the server-
reflexive candidate). To avoid packet dropping of ESP packets, the reflexive candidate). To avoid packet dropping of ESP packets, the
Control Relay Client SHOULD send the PEER_PERMISSION parameter before Control Relay Client SHOULD send the PEER_PERMISSION parameter before
connectivity checks both in the case of base exchange and a mobility connectivity checks both in the case of base exchange and a mobility
handover. It is worth noting that the UPDATE message includes a SEQ handover. It is worth noting that the UPDATE message includes a SEQ
parameter (as specified in [RFC7401]) that the Data Relay Server must parameter (as specified in [RFC7401]) that the Data Relay Server must
acknowledge, so that the Control Relay Client can resend the message acknowledge, so that the Control Relay Client can resend the message
with PEER_PERMISSION parameter if it gets lost. with the PEER_PERMISSION parameter if it gets lost.
When a Data Relay Server receives an UPDATE with a PEER_PERMISSION When a Data Relay Server receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data-relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the Data Relay Server checks registered. If the host was registered, the Data Relay Server checks
if there is a permission with matching information (protocol, if there is a permission with matching information (protocol,
addresses, ports and SPI values). If there is no such permission, a addresses, ports, and SPI values). If there is no such permission, a
new permission MUST be created and its lifetime MUST be set to 5 new permission MUST be created and its lifetime MUST be set to 5
minutes. If an identical permission already existed, it MUST be minutes. If an identical permission already existed, it MUST be
refreshed by setting the lifetime to 5 minutes. A Data Relay Client refreshed by setting the lifetime to 5 minutes. A Data Relay Client
SHOULD refresh permissions 1 minute before the expiration when the SHOULD refresh permissions 1 minute before the expiration when the
permission is still needed. permission is still needed.
When a Data Relay Server receives an UPDATE from a registered client When a Data Relay Server receives an UPDATE from a registered client
but without a PEER_PERMISSION parameter and with a new locator set, but without a PEER_PERMISSION parameter and with a new locator set,
the Data Relay Server can assume that the mobile host has changed its the Data Relay Server can assume that the mobile host has changed its
location and, thus, is not reachable in its previous location. In location and is thus not reachable in its previous location. In such
such an event, the Data Relay Server SHOULD deactivate the permission an event, the Data Relay Server SHOULD deactivate the permission and
and stop relaying data plane traffic to the client. stop relaying data plane traffic to the client.
The relayed address MUST be activated with the PEER_PERMISSION The relayed address MUST be activated with the PEER_PERMISSION
parameter both after a base exchange and after a handover procedure parameter both after a base exchange and after a handover procedure
with another ICE-HIP-UDP capable host. Unless activated, the Data with another ICE-HIP-UDP-capable host. Unless activated, the Data
Relay Server MUST drop all ESP packets. It is worth noting that a Relay Server MUST drop all ESP packets. It is worth noting that a
Data Relay Client does not have to renew its registration upon a Data Relay Client does not have to renew its registration upon a
change of location UPDATE, but only when the lifetime of the change of location UPDATE, but only when the lifetime of the
registration is close to end. registration is close to end.
4.12.2. HIP Data Relay and Relaying of Control Packets 4.12.2. HIP Data Relay and Relaying of Control Packets
When a Data Relay Server accepts to relay UDP encapsulated ESP When a Data Relay Server accepts to relay UDP-encapsulated ESP
between a Data Relay Client and its peer, the Data Relay Server opens between a Data Relay Client and its peer, the Data Relay Server opens
a UDP port (relayed address) for this purpose as described in a UDP port (relayed address) for this purpose as described in
Section 4.1. This port can be used for delivering also control Section 4.1. This port can be used for also delivering control
packets because connectivity checks also cover the path through the packets because connectivity checks also cover the path through the
Data Relay Server. If the Data Relay Server receives a UDP Data Relay Server. If the Data Relay Server receives a UDP-
encapsulated HIP control packet on that port, it MUST forward the encapsulated HIP control packet on that port, it MUST forward the
packet to the Data Relay Client and add a RELAY_FROM parameter to the packet to the Data Relay Client and add a RELAY_FROM parameter to the
packet as if the Data Relay Server were acting as a Control Relay packet as if the Data Relay Server were acting as a Control Relay
Server. When the Data Relay Client replies to a control packet with Server. When the Data Relay Client replies to a control packet with
a RELAY_FROM parameter via its Data Relay Server, the Data Relay a RELAY_FROM parameter via its Data Relay Server, the Data Relay
Client MUST add a RELAY_TO parameter containing the peer's address Client MUST add a RELAY_TO parameter containing the peer's address
and use the address of its Data Relay Server as the destination and use the address of its Data Relay Server as the destination
address. Further, the Data Relay Server MUST send this packet to the address. Further, the Data Relay Server MUST send this packet to the
peer's address from the relayed address. peer's address from the relayed address.
If the Data Relay Server receives a UDP packet that is not a HIP If the Data Relay Server receives a UDP packet that is not a HIP
control packet to the relayed address, it MUST check if it has a control packet to the relayed address, it MUST check if it has a
permission set for the peer the packet is arriving from (i.e., the permission set for the peer the packet is arriving from (i.e., the
sender's address and SPI value matches to an installed permission). sender's address and SPI value matches to an installed permission).
If permissions are set, the Data Relay Server MUST forward the packet If permissions are set, the Data Relay Server MUST forward the packet
to the Data Relay Client that created the permission. The Data Relay to the Data Relay Client that created the permission. The Data Relay
Server MUST also implement the similar checks for the reverse Server MUST also implement the similar checks for the reverse
direction (i.e. ESP packets from the Data Relay Client to the peer). direction (i.e., ESP packets from the Data Relay Client to the peer).
Packets without a permission MUST be dropped silently. Packets without a permission MUST be dropped silently.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
From the viewpoint of a host, its remote peers can have overlapping From the viewpoint of a host, its remote peers can have overlapping
inbound SPI numbers because the IPsec uses also the destination IP inbound SPI numbers because the IPsec also uses the destination IP
address to index the remote peer host. However, a Data Relay Server address to index the remote peer host. However, a Data Relay Server
can represent multiple remote peers, thus masquerading the actual can represent multiple remote peers, thus masquerading the actual
destination. Since a Data Relay Server may have to deal with a destination. Since a Data Relay Server may have to deal with a
multitude of Relay Clients and their peers, a Data Relay Server may multitude of Relay Clients and their peers, a Data Relay Server may
experience collisions in the SPI namespace, thus being unable forward experience collisions in the SPI namespace, thus being unable to
datagrams to the correct destination. Since the SPI space is 32 bits forward datagrams to the correct destination. Since the SPI space is
and the SPI values should be random, the probability for a 32 bits and the SPI values should be random, the probability for a
conflicting SPI value is fairly small, but could occur on a busy Data conflicting SPI value is fairly small but could occur on a busy Data
Relay Server. The two problematic cases are described in this Relay Server. The two problematic cases are described in this
section. section.
In the first scenario, the SPI collision problems occurs if two hosts In the first scenario, the SPI collision problem occurs if two hosts
have registered to the same Data Relay Server and a third host have registered to the same Data Relay Server and a third host
initiates base exchange with both of them. Here, the two Responders initiates base exchange with both of them. Here, the two Responders
(i.e. Data Relay Clients) claim the same inbound SPI number with the (i.e., Data Relay Clients) claim the same inbound SPI number with the
same Initiator (peer). However, in this case, the Data Relay Server same Initiator (peer). However, in this case, the Data Relay Server
has allocated separate UDP ports for the two Data Relay Clients has allocated separate UDP ports for the two Data Relay Clients
acting now as Responders (as recommended in Section 6.5). When the acting now as Responders (as recommended in Section 7.5). When the
third host sends an ESP packet, the Data Relay Server is able to third host sends an ESP packet, the Data Relay Server is able to
forward the packet to the correct Data Relay Client because the forward the packet to the correct Data Relay Client because the
destination UDP port is different for each of the clients. destination UDP port is different for each of the clients.
In the second scenario, an SPI collision may occur when two In the second scenario, an SPI collision may occur when two
Initiators run a base exchange to the same Responder (i.e. Data Initiators run a base exchange to the same Responder (i.e., Data
Relay Client), and both of the Initiators claim the same inbound SPI Relay Client), and both of the Initiators claim the same inbound SPI
at the Data Relay Server using PEER_PERMISSION Parameter. In this at the Data Relay Server using the PEER_PERMISSION parameter. In
case, the Data Relay Server cannot disambiguate the correct this case, the Data Relay Server cannot disambiguate the correct
destination of an ESP packet originating from the Data Relay Client destination of an ESP packet originating from the Data Relay Client
because the SPI could belong to either of the peers (and destination because the SPI could belong to either of the peers (and the
IP and UDP port belonging to the Data Relay Server are not unique destination IP and UDP port belonging to the Data Relay Server are
either). The recommended way and a contingency plan to solve this not unique either). The recommended way and a contingency plan to
issue are described below. solve this issue are described below.
The recommend way to mitigate the problem is as follows. For each The recommend way to mitigate the problem is as follows. For each
new Host Association, A Data Relay Client acting as a Responder new HIP association, a Data Relay Client acting as a Responder SHOULD
SHOULD register a new server reflexive candidate as described in register a new server-reflexive candidate as described in
Section 4.2. Similarly, the Data Relay Server SHOULD NOT re-use the Section 4.2. Similarly, the Data Relay Server SHOULD NOT reuse the
port numbers as described in Section 6.5. This way, each server port numbers as described in Section 7.5. This way, each server-
reflexive candidate for the Data Relay Client has a separate UDP port reflexive candidate for the Data Relay Client has a separate UDP port
that the Data Relay Server can use to disambiguate packet that the Data Relay Server can use to disambiguate packet
destinations in case of SPI collisions. destinations in case of SPI collisions.
When the Data Relay Client is not registering or failed to register a When the Data Relay Client is not registering or failed to register a
new relay candidate for a new peer, the Data Relay Client MUST follow new relay candidate for a new peer, the Data Relay Client MUST follow
a contingency plan as follows. Upon receiving an I2 with a colliding a contingency plan as follows. Upon receiving an I2 with a colliding
SPI, the Data Relay client acting as the Responder MUST NOT include SPI, the Data Relay Client acting as the Responder MUST NOT include
the relayed address candidate in the R2 message because the Data the relayed address candidate in the R2 message because the Data
Relay Server would not be able demultiplex the related ESP packet to Relay Server would not be able to demultiplex the related ESP packet
the correct Initiator. The same applies also the handover to the correct Initiator. The same also applies to the handover
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 an 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 all 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.
skipping to change at page 38, line 49 skipping to change at line 1782
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes | | 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HIP Header and Parameters ~ ~ HIP Header and Parameters ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of UDP-Encapsulated HIP Control Packets Figure 7: Format of UDP-Encapsulated HIP Control Packets
HIP control packets are encapsulated in UDP packets as defined in HIP control packets are encapsulated in UDP packets as defined in
Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except
that a different port number is used. Figure 7 illustrates the that a different port number is used. Figure 7 illustrates the
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC7401] with HIP header and parameters follow the conventions of [RFC7401] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
already contains a checksum. Second, the checksum definition in already contains a checksum. Second, the checksum definition in
[RFC7401] includes the IP addresses in the checksum calculation. The [RFC7401] includes the IP addresses in the checksum calculation. The
NATs 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.
UDP encapsulation of HIP packets reduces the Maximum Transfer Unit UDP encapsulation of HIP packets reduces the Maximum Transmission
(MTU) size of the control plane by 12 bytes (8-byte UDP header plus Unit (MTU) size of the control plane by 12 bytes (8-byte UDP header
4-byte zero SPI marker), and the data plane by 8 bytes. Additional plus 4-byte zero SPI marker), and the data plane by 8 bytes.
HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP,
RELAY_UDP_ESP, etc., further increase the size of certain HIP RELAY_UDP_ESP, etc., further increase the size of certain HIP
packets. In regard to MTU, the following aspects need to be packets. In regard to MTU, the following aspects need to be
considered in an implementation: considered in an implementation:
o A HIP host SHOULD implement ICMP message handling to support path * A HIP host SHOULD implement ICMP message handling to support Path
MTU discovery (PMTUD) discovery as described in [RFC1063] MTU Discovery (PMTUD) as described in [RFC1191] and [RFC8201].
[RFC8201]
o Reliance on IP fragmentation is unlikely to be a viable strategy * Reliance on IP fragmentation is unlikely to be a viable strategy
through NATs. If ICMP MTU discovery is not working, MTU related through NATs. If ICMP MTU discovery is not working, MTU-related
path black holes may occur. path black holes may occur.
o A mitigation strategy is to constrain the MTU, especially for * A mitigation strategy is to constrain the MTU, especially for
virtual interfaces, to expected safe MTU values, e.g., 1400 bytes virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
for the underlying interfaces that support 1500 bytes MTU. for the underlying interfaces that support 1500 bytes MTU.
o Further extensions to this specification may define a HIP-based * Further extensions to this specification may define a HIP-based
mechanism to find a working path MTU without unnecessary mechanism to find a working path MTU without unnecessary
constraining that size using Packetization Layer Path MTU constraining that size using Packetization Layer Path MTU
Discovery for Datagram Transports Discovery for Datagram Transports [RFC8899]. For instance, such a
[I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism mechanism could be implemented between a HIP Relay Client and HIP
could be implemented between a HIP Relay Client and HIP Relay Relay Server.
Server.
o It is worth noting that further HIP extensions can trim off 8 * It is worth noting that further HIP extensions can trim off 8
bytes in the ESP header by negotiating implicit IV support in the bytes in the ESP header by negotiating implicit initialization
ESP_TRANSFORM parameter as described in [RFC8750]. vector (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 the Notify message type field set to
NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification NAT_KEEPALIVE (16385) and with an empty Notification data field. It
data field. It is worth noting that sending of such a HIP NOTIFY is worth noting that the sending of such a HIP NOTIFY message SHOULD
message SHOULD be omitted if the host is actively (or passively) be omitted if the host is sending some other traffic (HIP or ESP) to
sending some other traffic (HIP or ESP) to the peer host over the the peer host over the related UDP tunnel during the Tr period. For
related UDP tunnel during the Tr period. For instance, the host MAY instance, the host MAY actively send ICMPv6 requests (or respond with
actively send ICMPv6 requests (or respond with an ICMPv6 response) an ICMPv6 response) inside the ESP tunnel to test the health of the
inside the ESP tunnel to test the health of the associated IPsec associated IPsec security association. Alternatively, the host MAY
security association. Alternatively, the host MAY use UPDATE packets use UPDATE packets as a substitute. A minimal UPDATE packet would
as a substitute. A minimal UPDATE packet would consist of a SEQ and consist of a SEQ and a single ECHO_REQ_SIGN parameter, and a more
ECHO_REQ_SIGN parameters, and a more complex would involve rekeying complex one would involve rekeying procedures as specified in
procedures as specified in section 6.8 in [RFC7402]. It is worth Section 6.8 of [RFC7402]. It is worth noting that a host actively
noting that a host actively sending periodic UPDATE packets to a busy sending periodic UPDATE packets to a busy server may increase the
server may increase the computational load of the server since it has computational load of the server since it has to verify HMACs and
to verify HMACs and signatures in UPDATE messages. signatures in UPDATE messages.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is defined in Legacy ICE- The format of the NAT traversal mode parameter is defined in Legacy
HIP [RFC5770] but repeated here for completeness. The format of the ICE-HIP [RFC5770] but repeated here for completeness. The format of
NAT_TRAVERSAL_MODE parameter is similar to the format of the the NAT_TRAVERSAL_MODE parameter is similar to the format of the
ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The
Native ICE-HIP extension specified in this document defines the new Native ICE-HIP extension specified in this document defines the new
NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP- NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP-
ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier
named RESERVED is reserved for future use. Future specifications may named RESERVED is reserved for future use. Future specifications may
define more traversal modes. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding | | Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 608 Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter
Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received
Mode ID defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined: Type: 608
ID name Value Length: Length in octets, excluding Type, Length, and Padding
RESERVED 0
UDP-ENCAPSULATION 1
ICE-STUN-UDP 2
ICE-HIP-UDP 3
Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter Reserved: Zero when sent, ignored when received
Mode ID: Defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined:
+===================+=======+
| ID name | Value |
+===================+=======+
| RESERVED | 0 |
+-------------------+-------+
| UDP-ENCAPSULATION | 1 |
+-------------------+-------+
| ICE-STUN-UDP | 2 |
+-------------------+-------+
| ICE-HIP-UDP | 3 |
+-------------------+-------+
Table 1: NAT Traversal
Mode IDs
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that
there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. Conversely, a recipient MUST be prepared to handle parameter. Conversely, a recipient MUST be prepared to handle
received NAT traversal mode parameters that contain more than six received NAT traversal mode parameters that contain more than six
Mode IDs by accepting the first six Mode IDs and dropping the rest. Mode IDs by accepting the first six Mode IDs and dropping the rest.
The limited number of Mode IDs sets the maximum size of the The limited number of Mode IDs sets the maximum size of the
NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order,
most preferred mode(s) first. most preferred mode(s) first.
Implementations conforming to this specification MUST implement UDP- Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes.
5.5. Connectivity Check Transaction Pacing Parameter 5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING is defined in [RFC5770], but repeated in The TRANSACTION_PACING parameter is defined in [RFC5770] but repeated
Figure 9 for completeness. It contains only the connectivity check in Figure 9 for completeness. It contains only the connectivity
pacing value, expressed in milliseconds, as a 32-bit unsigned check pacing value, expressed in milliseconds, as a 32-bit unsigned
integer. integer.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta | | Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 610 Figure 9: Format of the TRANSACTION_PACING Parameter
Length 4
Min Ta the minimum connectivity check transaction pacing
value the host would use (in milliseconds)
Figure 9: Format of the TRANSACTION_PACING Parameter Type: 610
Length: 4
Min Ta: The minimum connectivity check transaction pacing value
the host would use (in milliseconds)
5.6. Relay and Registration Parameters 5.6. Relay and Registration Parameters
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
shown in Figure 10. All parameters are identical except for the shown in Figure 10. All parameters are identical except for the
type. Of the three, only REG_FROM is covered by the signature. type. Of the three, only REG_FROM is covered by the signature.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type REG_FROM: 950
RELAY_FROM: 63998
RELAY_TO: 64002
Length 20
Port transport port number; zero when plain IP is used
Protocol IANA assigned, Internet Protocol number.
17 for UDP, 0 for plain IP
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format
Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO
Parameters Parameters
Type: REG_FROM: 950
RELAY_FROM: 63998
RELAY_TO: 64002
Length: 20
Port: Transport port number; zero when plain IP is used
Protocol: IANA-assigned, Internet Protocol number. 17 for UDP; 0
for plain IP
Reserved: Reserved for future use; zero when sent, ignored when
received
Address: An IPv6 address or an IPv4 address in "IPv4-mapped IPv6
address" format
REG_FROM contains the transport address and protocol from which the REG_FROM contains the transport address and protocol from which the
Control Relay Server sees the registration coming. RELAY_FROM Control Relay Server sees the registration coming. RELAY_FROM
contains the address from which the relayed packet was received by contains the address from which the relayed packet was received by
the Control Relay Server and the protocol that was used. RELAY_TO the Control Relay Server and the protocol that was used. RELAY_TO
contains the same information about the address to which a packet contains the same information about the address to which a packet
should be forwarded. should be forwarded.
5.7. LOCATOR_SET Parameter 5.7. LOCATOR_SET Parameter
skipping to change at page 43, line 52 skipping to change at line 2030
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | | Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: LOCATOR_SET Parameter Figure 11: LOCATOR_SET Parameter
The individual fields in the LOCATOR_SET parameter are described in The individual fields in the LOCATOR_SET parameter are described in
Table 1. Table 2.
+-----------+----------+--------------------------------------------+ +===========+==========+=========================================+
| Field | Value(s) | Purpose | | Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+ +===========+==========+=========================================+
| Type | 193 | Parameter type | | Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and | +-----------+----------+-----------------------------------------+
| | | Length fields and padding | | Length | Variable | Length in octets, excluding Type and |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for | | | | Length fields and padding |
| Type | | ESP (2), or for both (0) | +-----------+----------+-----------------------------------------+
| Locator | 2 | "Transport address" locator type | | Traffic | 0-2 | The locator for either HIP signaling |
| Type | | | | Type | | (1) or ESP (2), or for both (0) |
| Locator | 7 | Length of the fields after Locator | +-----------+----------+-----------------------------------------+
| Length | | Lifetime in 4-octet units | | Locator | 2 | "Transport address" locator type |
| Reserved | 0 | Reserved for future extensions | | Type | | |
| Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | +-----------+----------+-----------------------------------------+
| (P) bit | | Responder can use it for the rest of the | | Locator | 7 | Length of the fields after Locator |
| | | base exchange, otherwise set to zero | | Length | | Lifetime in 4-octet units |
| Locator | Variable | Locator lifetime in seconds, see Section 4 | +-----------+----------+-----------------------------------------+
| Lifetime | | in [RFC8046] | | Reserved | 0 | Reserved for future extensions |
| Transport | Variable | Transport layer port number | +-----------+----------+-----------------------------------------+
| Port | | | | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the |
| Transport | Variable | IANA assigned, transport layer Internet | | (P) bit | | Responder can use it for the rest of |
| Protocol | | Protocol number. Currently only UDP (17) | | | | the base exchange, otherwise set to |
| | | is supported. | | | | zero |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | +-----------+----------+-----------------------------------------+
| | | peer reflexive (currently unused) or 3 for | | Locator | Variable | Locator lifetime in seconds, see |
| | | relayed address | | Lifetime | | Section 4 of [RFC8046] |
| Priority | Variable | Locator's priority as described in | +-----------+----------+-----------------------------------------+
| | | [RFC8445]. It is worth noting that while | | Transport | Variable | Transport-layer port number |
| | | the priority of a single locator candidate | | Port | | |
| | | is 32-bits, but an implementation should | +-----------+----------+-----------------------------------------+
| | | use a 64-bit integer to calculate the | | Transport | Variable | IANA-assigned, transport-layer Internet |
| | | priority of a candidate pair for the ICE | | Protocol | | Protocol number. Currently, only UDP |
| | | priority algorithm. | | | | (17) is supported. |
| SPI | Variable | Security Parameter Index (SPI) value that | +-----------+----------+-----------------------------------------+
| | | the host expects to see in incoming ESP | | Kind | Variable | 0 for host, 1 for server reflexive, 2 |
| | | packets that use this locator | | | | for peer reflexive (currently unused), |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | | | or 3 for relayed address |
| | | address" format IPv4 address [RFC4291] | +-----------+----------+-----------------------------------------+
+-----------+----------+--------------------------------------------+ | Priority | Variable | Locator's priority as described in |
| | | [RFC8445]. It is worth noting that |
| | | while the priority of a single locator |
| | | candidate is 32 bits, an implementation |
| | | should a 64-bit integer to calculate |
| | | the priority of a candidate pair for |
| | | the ICE priority algorithm. |
+-----------+----------+-----------------------------------------+
| SPI | Variable | Security Parameter Index (SPI) value |
| | | that the host expects to see in |
| | | incoming ESP packets that use this |
| | | locator |
+-----------+----------+-----------------------------------------+
| Address | Variable | IPv6 address or an "IPv4-mapped IPv6 |
| | | address" format IPv4 address [RFC4291] |
+-----------+----------+-----------------------------------------+
Table 1: Fields of the LOCATOR_SET Parameter Table 2: Fields of the LOCATOR_SET Parameter
The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED
parameter. 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 of [RFC8004]. Similar to RVS_HMAC,
RVS_HMAC, also RELAY_HMAC is keyed with the HIP integrity key (HIP-lg RELAY_HMAC is also keyed with the HIP integrity key (HIP-lg or HIP-gl
or HIP-gl as specified in section 6.5 in [RFC7401]), established as specified in Section 6.5 of [RFC7401]), established during the
during the relay registration procedure as described in Section 4.1. relay registration procedure as described in Section 4.1.
5.9. Registration Types 5.9. Registration Types
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
Registration Type [RFC8003] values for Control Relay Server Registration Type [RFC8003] values for Control Relay Server
registration. The value for RELAY_UDP_HIP is 2 as specified in registration. The value for RELAY_UDP_HIP is 2 as specified in
Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is 3.
by IANA: 3]).
5.10. Notify Packet Types 5.10. Notify Packet Types
A Control/Data Relay Server and end-hosts can use NOTIFY packets to A Control/Data Relay Server and end hosts can use NOTIFY packets to
signal different error conditions. The NOTIFY packet types are the signal different error conditions. The NOTIFY packet types are the
same as in Legacy ICE-HIP [RFC5770] except for the two last ones, same as in Legacy ICE-HIP [RFC5770] except for the two last ones,
which are new. which are new.
The Notify Packet Types [RFC7401] are shown below. The Notification The Notify Packet Types [RFC7401] are shown below. The Notification
Data field for the error notifications SHOULD contain the HIP header Data field for the error notifications SHOULD contain the HIP header
of the rejected packet and SHOULD be empty for the of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value +=====================================================+=======+
------------------------------------ ----- | NOTIFICATION PARAMETER - ERROR TYPES | Value |
+=====================================================+=======+
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 | NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER | 60 |
| | |
If a Control Relay Server does not forward a base exchange packet | If a Control Relay Server does not forward a base | |
due to missing NAT traversal mode parameter, or the Initiator | exchange packet due to a missing NAT traversal mode | |
selects a NAT traversal mode that the (non-relay) Responder did | parameter, or the Initiator selects a NAT traversal | |
not expect, the Control Relay Server or the Responder may send | mode that the (non-relay) Responder did not expect, | |
back a NOTIFY error packet with this type. | the Control Relay Server or the Responder may send | |
| back a NOTIFY error packet with this type. | |
CONNECTIVITY_CHECKS_FAILED 61 +-----------------------------------------------------+-------+
| CONNECTIVITY_CHECKS_FAILED | 61 |
Used by the end-hosts to signal that NAT traversal connectivity | | |
checks failed and did not produce a working path. | Used by the end hosts to signal that NAT traversal | |
| connectivity checks failed and did not produce a | |
MESSAGE_NOT_RELAYED 62 | working path. | |
Used by a Control Relay Server to signal that is was not able or +-----------------------------------------------------+-------+
willing to relay a HIP packet. | MESSAGE_NOT_RELAYED | 62 |
| | |
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63 | Used by a Control Relay Server to signal that it | |
| was not able or willing to relay a HIP packet. | |
Used by a Data Relay Server to signal that is was not able or +-----------------------------------------------------+-------+
willing to allocate a new server reflexive candidate for the Data | SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED | 63 |
Relay Client | | |
| Used by a Data Relay Server to signal that it was | |
RVS_HMAC_PROHIBITED_WITH_RELAY 64 | not able or willing to allocate a new server- | |
| reflexive candidate for the Data Relay Client. | |
+-----------------------------------------------------+-------+
| RVS_HMAC_PROHIBITED_WITH_RELAY | 64 |
| | |
| In the unintended event that a Control Relay Server | |
| sends any HIP message with an RVS_HMAC parameter, | |
| the Control Relay Client drops the received HIP | |
| message and sends a notify message back to the | |
| Control Relay Server using this notify type. | |
+-----------------------------------------------------+-------+
In the unintended event that a Control Relay Server sends any HIP Table 3: Notify Packet Types
message with a RVS_HMAC parameter, the Control Relay Client drops
the received HIP message and sends a notify message back to the
Control Relay Server using this notify type
5.11. ESP Data Packets 5.11. ESP Data Packets
The format for ESP data packets is identical to Legacy ICE-HIP The format for ESP data packets is identical to Legacy ICE-HIP
[RFC5770]. [RFC5770].
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport [RFC3948] describes the UDP encapsulation of the IPsec ESP transport
and tunnel mode. On the wire, the HIP ESP packets do not differ from and tunnel mode. On the wire, the HIP ESP packets do not differ from
the transport mode ESP, and thus the encapsulation of the HIP ESP the transport mode ESP; thus, the encapsulation of the HIP ESP
packets is same as the UDP encapsulation transport mode ESP. packets is same as the UDP encapsulation transport mode ESP.
However, the (semantic) difference to Bound End-to-End Tunnel (BEET) However, the (semantic) difference to Bound End-to-End Tunnel (BEET)
mode ESP packets used by HIP is that IP header is not used in BEET mode ESP packets used by HIP is that the IP header is not used in
integrity protection calculation. BEET integrity protection calculation.
During the HIP base exchange, the two peers exchange parameters that During the HIP base exchange, the two peers exchange parameters that
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].
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
use of UDP relaying, and, thus, only protocol 17 is allowed. the use of UDP relaying; thus, only protocol 17 is allowed. However,
However, future documents may specify support for other protocols. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA;
RELAYED_ADDRESS: 4650
MAPPED_ADDRESS: 4660]
Length 20
Port the UDP port number
Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored
when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format
Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS
Parameters Parameters
Type: RELAYED_ADDRESS: 4650
MAPPED_ADDRESS: 4660
Length: 20
Port: The UDP port number
Protocol: IANA-assigned, Internet Protocol number (17 for UDP)
Reserved: Reserved for future use; zero when sent, ignored when
received
Address: An IPv6 address or an IPv4 address in "IPv4-mapped IPv6
address" format
5.13. PEER_PERMISSION Parameter 5.13. PEER_PERMISSION Parameter
The format of the new PEER_PERMISSION parameter is shown in The format of the new PEER_PERMISSION parameter is shown in
Figure 13. The parameter is used for setting up and refreshing Figure 13. The parameter is used for setting up and refreshing
forwarding rules and the permissions for data packets at the Data forwarding rules and the permissions for data packets at the Data
Relay Server. The parameter contains one or more sets of Port, Relay Server. The parameter contains one or more sets of Port,
Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI)
values. One set defines a rule for one peer address. values. One set defines a rule for one peer address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPort | PPort | | RPort | PPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| RAddress | | RAddress |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| PAddress | | PAddress |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI | | OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4680] Figure 13: Format of the PEER_PERMISSION Parameter
Length 48
RPort the transport layer (UDP) port at the Data Relay Server
(i.e. the port of the server reflexive candidate)
PPort the transport layer (UDP) port number of the peer
Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored
when received
RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the server reflexive candidate
PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer
OSPI the outbound SPI value the Data Relay Client is using for
the peer
ISPI the inbound SPI value the Data Relay Client is using for
the peer
Figure 13: Format of the PEER_PERMISSION Parameter Type: 4680
Length: 48
RPort: The transport-layer (UDP) port at the Data Relay Server
(i.e., the port of the server-reflexive candidate)
PPort: The transport-layer (UDP) port number of the peer
Protocol: IANA-assigned, Internet Protocol number (17 for UDP)
Reserved: Reserved for future use; zero when sent, ignored when
received
RAddress: An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6
address" format, of the server-reflexive candidate
PAddress: An IPv6 address, or an IPv4 address in "IPv4-mapped IPv6
address" format, of the peer
OSPI: The outbound SPI value the Data Relay Client is using for
the peer
ISPI: The inbound SPI value the Data Relay Client is using for
the peer
5.14. HIP Connectivity Check Packets 5.14. HIP Connectivity Check Packets
The connectivity request messages are HIP UPDATE packets containing a The connectivity request messages are HIP UPDATE packets containing a
new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE
packets contain a MAPPED_ADDRESS parameter (Figure 12). packets contain a MAPPED_ADDRESS parameter (Figure 12).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4700]
Length 4
Priority the priority of a (potential) peer reflexive candidate
Figure 14: Format of the CANDIDATE_PRIORITY Parameter Figure 14: Format of the CANDIDATE_PRIORITY Parameter
5.15. NOMINATE parameter Type: 4700
Length: 4
Priority: The priority of a (potential) peer-reflexive candidate
5.15. NOMINATE Parameter
Figure 15 shows the NOMINATE parameter that is used to conclude the Figure 15 shows the NOMINATE parameter that is used to conclude the
candidate nomination process. candidate nomination process.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4710]
Length 4
Reserved Reserved for future extension purposes
Figure 15: Format of the NOMINATE Parameter Figure 15: Format of the NOMINATE Parameter
6. Security Considerations Type: 4710
Length: 4
Reserved: Reserved for future extension purposes
6. IAB Considerations
The ICE specification [RFC8445] discusses "Unilateral Self-Address
Fixing" in Section 18. This protocol is based on ICE; thus, the same
considerations also apply here.
7. Security Considerations
Since the control plane protocol and Control Relay Server are Since the control plane protocol and Control Relay Server are
essentially the same (with some minor differences) in this document essentially the same (with some minor differences) in this document
as in Legacy ICE-HIP [RFC5770], the same security considerations (in as in Legacy ICE-HIP [RFC5770], the same security considerations (in
Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still Sections 7.1, 7.2, 7.3, and 7.4) are still valid, but are repeated
valid, but are repeated here for the sake of completeness. New here for the sake of completeness. New security considerations
security considerations related to the new Data Relay Server are related to the new Data Relay Server are discussed in Section 7.5,
discussed in Section 6.5, and considerations related to the new and considerations related to the new connectivity check protocol are
connectivity check protocol are discussed in Section 6.6 and discussed in Sections 7.6 and 7.7.
Section 6.7.
6.1. Privacy Considerations 7.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, it might be tempting exclude certain host addresses from the reasons, it might be tempting to exclude certain host addresses from
LOCATOR_SET parameter of an end-host but this is NOT RECOMMENDED. the LOCATOR_SET parameter of an end host, but this is NOT
For instance, such behavior creates non-optimal paths when the hosts RECOMMENDED. For instance, such behavior creates non-optimal paths
are located behind the same NAT. Especially, this could be when the hosts are located behind the same NAT. Especially, this
problematic with a legacy NAT that does not support routing from the could be problematic with a legacy NAT that does not support routing
private address realm back to itself through the outer address of the from the private address realm back to itself through the outer
NAT. This scenario is referred to as the hairpin problem [RFC5128]. address of the NAT. This scenario is referred to as the hairpin
With such a legacy NAT, the only option left would be to use a problem [RFC5128]. With such a legacy NAT, the only option left
relayed transport address from an Data Relay Server. would be to use a relayed transport address from a 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 also be 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 7.2. Opportunistic Mode
In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an In opportunistic HIP mode (cf. Section 4.1.8 of [RFC7401]), an
Initiator sends an I1 with without setting the destination HIT of the Initiator sends an I1 without setting the destination HIT of the
Responder (i.e. the Control Relay Client). A Control Relay Server Responder (i.e., the Control Relay Client). A Control Relay Server
SHOULD have a unique IP address per Control Relay Client when the SHOULD have a unique IP address per the Control Relay Client when the
Control Relay Server is serving more than one Control Relay Client Control Relay Server is serving more than one Control Relay Client
and supports opportunistic mode. Otherwise, the Control Relay Server and supports opportunistic mode. Otherwise, the Control Relay Server
cannot guarantee to deliver the I1 packet to the intended recipient. cannot guarantee to deliver the I1 packet to the intended recipient.
Future extensions of this document may allow opportunistic mode to be Future extensions of this document may allow opportunistic mode to be
used with non-unique IP addresses to be utilized either as a HIP- used with non-unique IP addresses to be utilized either as a HIP-
level anycast or multicast mechanism. Both of the mentioned cases level anycast or multicast mechanism. Both of the mentioned cases
would require a separate registration parameters that the Control would require separate registration parameters that the Control Relay
Relay Server proposes and the Control Client Server accepts during Server proposes and the Control Client Server accepts during
registration. registration.
6.3. Base Exchange Replay Protection for Control Relay Server 7.3. Base Exchange Replay Protection for Control Relay Server
In certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a Control attackers, can replay an earlier base exchange through a Control
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 [I-D.heer-hip-middle-auth] and drop the I2 or R2 as described in [HIP-MIDDLEBOXES] and drop the I2 or R2 packets if
packets if the corresponding ECHO_RESPONSE_M parameters are not the corresponding ECHO_RESPONSE_M parameters are not present.
present.
6.4. Demultiplexing Different HIP Associations 7.4. Demultiplexing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder uses HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
6.5. Reuse of Ports at the Data Relay Server 7.5. Reuse of Ports at the Data Relay Server
If the Data Relay Server uses the same relayed address and port (as If the Data Relay Server uses the same relayed address and port (as
conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay
Clients, it appears to all the peers, and their firewalls, that all Clients, it appears to all the peers, and their firewalls, that all
the Data Relay Clients are at the same address. Thus, a stateful the Data Relay Clients are at the same address. Thus, a stateful
firewall may allow packets pass from hosts that would not normally be firewall may allow packets to pass from hosts that would not normally
able to send packets to a peer behind the firewall. Therefore, a be able to send packets to a peer behind the firewall. Therefore, a
Data Relay Server SHOULD NOT re-use the port numbers. If port Data Relay Server SHOULD NOT reuse the port numbers. If port numbers
numbers need to be re-used, the Data Relay Server SHOULD have a need to be reused, the Data Relay Server SHOULD have a sufficiently
sufficiently large pool of port numbers and select ports from the large pool of port numbers and randomly select ports from the pool to
pool randomly to decrease the chances of a Data Relay Client decrease the chances of a Data Relay Client obtaining the same
obtaining the same address that a another host behind the same address that another host behind the same firewall is using.
firewall is using.
6.6. Amplification attacks 7.6. Amplification Attacks
A malicious host may send an invalid list of candidates to its peer A malicious host may send an invalid list of candidates to its peer
that are used for targeting a victim host by flooding it with that are used for targeting a victim host by flooding it with
connectivity checks. To mitigate the attack, this protocol adopts connectivity checks. To mitigate the attack, this protocol adopts
the ICE mechanism to cap the total amount of connectivity checks as the ICE mechanism to cap the total amount of connectivity checks as
defined in Section 4.7. defined in Section 4.7.
6.7. Attacks against Connectivity Checks and Candidate Gathering 7.7. Attacks against Connectivity Checks and Candidate Gathering
Section 19.2 in [RFC8445] describes attacks against ICE connectivity Section 19.2 of [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 also discusses 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 effectively immune against replay attacks checks in this protocol are effectively immune against replay attacks
because a connectivity request includes a random nonce that the because a connectivity request includes a random nonce that the
recipient must 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 of [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 attackers can inject fake messages
(located on a shared network segment like Wifi) does not apply here. (located on a shared network segment like Wi-Fi) 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 to inject fake server-reflexive address candidates.
Section 19.4 in [RFC8445] describes attacks on relayed candidate Section 19.4 of [RFC8445] describes attacks on relayed candidate
gathering. Similarly to ICE TURN servers, Data Relay Server require gathering. Similarly to ICE TURN servers, a Data Relay Server
an authenticated base exchange that protects relayed address requires an authenticated base exchange that protects relayed address
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.
6.8. Cross-Protocol Attacks 7.8. Cross-Protocol Attacks
Section 4.1 explains how a Control Relay Client registers for the Section 4.1 explains how a Control Relay Client registers for the
RELAY_UDP_HIP service from a Control Relay Server. However, the same RELAY_UDP_HIP service from a Control Relay Server. However, the same
server may offer also Rendezvous functionality, and, thus, a client server may also offer Rendezvous functionality; thus, a client can
can register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004]) register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004])
service from the same server. Potentially, this introduces a cross- service from the same server. Potentially, this introduces a cross-
protocol attack (or actually a "cross-message" attack) because the protocol attack (or actually a "cross-message" attack) because the
key material is the same for the Control Relay Service and Rendezvous key material is the same for the Control Relay Service and Rendezvous
HMACs. While the problem could be avoided by deriving different keys HMACs. While the problem could be avoided by deriving different keys
for the Control Relay Service, a more simple measure was chosen for the Control Relay Service, a more simple measure was chosen
because the exact attack scenario was unclear. Consequently, this because the exact attack scenario was unclear. Consequently, this
section defines a mandatory mitigation mechanism against the cross- section defines a mandatory mitigation mechanism against the cross-
protocol attack that works by preventing the simultanous use of protocol attack that works by preventing the simultaneous use of
Rendezvous and Control Relay Service in the context of a single HIP Rendezvous and Control Relay Service in the context of a single HIP
Association. Association.
The registration involves three parameters typically delivered The registration involves three parameters typically delivered
sequentally in R1 (REG_INFO parameter), I2 (REG_REQUEST) and R2 sequentially in R1 (REG_INFO parameter), I2 (REG_REQUEST), and R2
(REG_RESPONSE) messages but can also be delivered in UPDATE messages (REG_RESPONSE) messages but can also be delivered in UPDATE messages
as described in [RFC8003]. The parameters and the modifications to as described in [RFC8003]. The parameters and the modifications to
their processing are described below: their processing are described below:
1. REG_INFO: the Control Relay Server advertizes its available REG_INFO: The Control Relay Server advertises its available services
services using this parameter. RELAY_UDP_HIP and RENDEZVOUS using this parameter. RELAY_UDP_HIP and RENDEZVOUS services MAY
services MAY be included in the first advertizement for the HIP be included in the first advertisement for the HIP association,
association but subsequent ones MUST include only one of them as but subsequent ones MUST include only one of them as agreed in
agreed in earlier registrations (see steps 2 and 3). earlier registrations (see steps 2 and 3).
2. REG_REQUEST: the Control Relay Client chooses the services it REG_REQUEST: The Control Relay Client chooses the services it
requires using this parameter. If the Control Relay Server requires using this parameter. If the Control Relay Server
offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay Client
Client MUST choose only one of them in the REG_REQUEST parameter. MUST choose only one of them in the REG_REQUEST parameter. Upon
Upon choosing one of of the two, it persists throughout the choosing one of the two, it persists throughout the lifetime of
lifetime of the HIP association, and the Control Relay Client the HIP association, and the Control Relay Client MUST NOT
MUST NOT register the other remaining one in a subsequent UPDATE register the other remaining one in a subsequent UPDATE message.
message.
3. REG_RESPONSE: the Control Relay Server verifies the services REG_RESPONSE: The Control Relay Server verifies the services
requested by the Control Relay Client using this parameter. If requested by the Control Relay Client using this parameter. If
the Control Relay Server offered both RENDEZVOUS and the Control Relay Server offered both RENDEZVOUS and RELAY_UDP_HIP
RELAY_UDP_HIP service, and the Control Relay Client requested for service, and the Control Relay Client requested for both of them,
both of them, the Control Relay Client MUST offer only the Control Relay Client MUST offer only RELAY_UDP_HIP service in
RELAY_UDP_HIP service in the REG_RESPONSE parameter and include a the REG_RESPONSE parameter and include a REG_FAILED parameter in
REG_FAILED parameter in the same message, with RENDEZVOUS as the the same message, with RENDEZVOUS as the Registration Type and 9
Registration Type and [TBD by IANA: 9] as the Failure Type. as the Failure Type.
As a further measure against cross-protocol attacks, Control Relay As a further measure against cross-protocol attacks, the Control
Client MUST drop any HIP message that includes an RVS_HMAC parameter Relay Client MUST drop any HIP message that includes an RVS_HMAC
when it originates from successfully registered Control Relay Server. parameter when it originates from a successfully registered Control
Upon such an (unintended) event, the Control Relay Client MUST send a Relay Server. Upon such an (unintended) event, the Control Relay
NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Client MUST send a NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY
Message Type to the Control Relay Server. as the Notify Message Type to the Control Relay Server.
7. IANA Considerations 8. 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. The port was was registered separately and data plane traffic. The port was registered separately for
for RFC5770 to co-author Ari Keranen but should now be re-assigned [RFC5770] to coauthor Ari Keränen originally, but it has been
for IESG control. With the permission of Ari Keranen, the new reassigned for IESG control. With the permission of Ari Keränen, the
assignee is IESG and contact "chair@ietf.org". In addition, IANA is new assignee is the IESG and the contact is <chair@ietf.org>. In
requested to add a reference to this document in the entry for UDP addition, IANA has added a reference to this document in the entry
port 10500 in the Transport Protocol Port Number Registry. The for UDP port 10500 in the "Service Name and Transport Protocol Port
selection between Legacy ICE-HIP and Native ICE-HIP mode is Number Registry". The selection between Legacy ICE-HIP and Native
negotiated using NAT_TRAVERSAL_MODE parameter during the base ICE-HIP mode is negotiated using the NAT_TRAVERSAL_MODE parameter
exchange. By default, hosts listen this port for incoming UDP during the base exchange. By default, hosts listen to this port for
datagrams and can use it also for sending UDP datagrams. Other incoming UDP datagrams and can also use it for sending UDP datagrams.
emphemeral port numbers are negotiated and utilized dynamically. Other ephemeral port numbers are negotiated and utilized dynamically.
This document updates the IANA Registry for HIP Parameter Types IANA has assigned the following values in the HIP "Parameter Types"
[RFC7401] by assigning new HIP Parameter Type values for the new HIP registry [RFC7401]: 4650 for RELAYED_ADDRESS (length 20), 4660 for
Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, MAPPED_ADDRESS (length 20; defined in Section 5.12), 4680 for
defined in Section 5.12), PEER_PERMISSION (length 48, defined in PEER_PERMISSION (length 48; defined in Section 5.13), 4700 for
Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) CANDIDATE_PRIORITY (length 4; defined in Section 5.14), and 4710 for
and NOMINATE (length 4, defined in Section 5.15). NOMINATE (length 4; defined in Section 5.15).
This document updates the IANA Registry for HIP NAT traversal modes IANA has assigned the following value in the "HIP NAT Traversal
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT Modes" registry specified in Legacy ICE-HIP [RFC5770]: 3 for ICE-HIP-
traversal mode ICE-HIP-UDP (defined in Section 5.4). UDP (defined in Section 5.4).
This document updates the IANA Registry for HIP Notify Message Types: IANA has assigned the following values in the HIP "Notify Message
type field NAT_KEEPALIVE in Section 5.3, a new error type Types" registry: 16385 for NAT_KEEPALIVE in Section 5.3, 63 for
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED and SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.10, and 64
RVS_HMAC_PROHIBITED_WITH_RELAY in Section 5.10. . for RVS_HMAC_PROHIBITED_WITH_RELAY in Section 5.10.
This document defines additional registration types for the HIP IANA has assigned the following values in the "Registration Types"
Registration Extension [RFC8003] that allow registering with a Data registry for the HIP Registration Extension [RFC8003]: 3 for
Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in RELAY_UDP_ESP (defined in Section 5.9) for allowing registration with
Section 5.9, and performing server reflexive candidate discovery: a Data Relay Server for ESP-relaying service, and 4 for
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2) for performing server-
reflexive candidate discovery.
This document defines an additional Registration Failure Type as IANA has assigned one value in the "Registration Failure Types"
defined in Section 6.8. The value is [TBD by IANA: 9] and the registry as defined in Section 7.8. The value is 9, and the
Registration Failure Type is "Simultaneous Rendezvous and Control Registration Failure Type is "Simultaneous Rendezvous and Control
Relay Service usage prohibited". Relay Service usage prohibited".
ICE specification [RFC8445] discusses "Unilateral Self-Address 9. References
Fixing" in section 18. This protocol is based on ICE, and thus the
same considerations apply also here.
8. Contributors
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in
the RFC.
9. Acknowledgments
Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the
MMUSIC WG folks for the excellent work on ICE. The authors would
like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling,
Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their
contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey
M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander,
Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela,
Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani
Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to
[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, Martin Duke and Benjamin
Kaduk for reviewing this document.
This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland.
10. References 9.1. Normative References
10.1. Normative References [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
May 2017, <https://www.rfc-editor.org/info/rfc8174>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)", Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015, RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>. <https://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015,
<https://www.rfc-editor.org/info/rfc7402>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003, Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <https://www.rfc-editor.org/info/rfc8003>. October 2016, <https://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <https://www.rfc-editor.org/info/rfc8004>. October 2016, <https://www.rfc-editor.org/info/rfc8004>.
[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>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
with the Host Identity Protocol", RFC 8046, with the Host Identity Protocol", RFC 8046,
DOI 10.17487/RFC8046, February 2017, DOI 10.17487/RFC8046, February 2017,
<https://www.rfc-editor.org/info/rfc8046>. <https://www.rfc-editor.org/info/rfc8046>.
[RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host
Multihoming with the Host Identity Protocol", RFC 8047, Multihoming with the Host Identity Protocol", RFC 8047,
DOI 10.17487/RFC8047, February 2017, DOI 10.17487/RFC8047, February 2017,
<https://www.rfc-editor.org/info/rfc8047>. <https://www.rfc-editor.org/info/rfc8047>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015,
<https://www.rfc-editor.org/info/rfc7402>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[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>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
the IPv6 Prefix Used for IPv6 Address Synthesis", D., Mahy, R., and P. Matthews, "Session Traversal
RFC 7050, DOI 10.17487/RFC7050, November 2013, Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
<https://www.rfc-editor.org/info/rfc7050>. February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[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. [RFC8961] Allman, M., "Requirements for Time-Based Loss Detection",
Keranen, Ed., "Basic Host Identity Protocol (HIP) BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020,
Extensions for Traversal of Network Address Translators", <https://www.rfc-editor.org/info/rfc8961>.
RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>.
[I-D.ietf-tcpm-rto-consider] 9.2. Informative References
Allman, M., "Requirements for Time-Based Loss Detection",
draft-ietf-tcpm-rto-consider-16 (work in progress), June
2020.
10.2. Informative References [HIP-MIDDLEBOXES]
Heer, T., Hummen, R., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Work in Progress,
Internet-Draft, draft-heer-hip-middle-auth-04, 31 October
2011, <https://tools.ietf.org/html/draft-heer-hip-middle-
auth-04>.
[I-D.ietf-hip-rfc4423-bis] [ICE-NONSIP]
Moskowitz, R. and M. Komu, "Host Identity Protocol Rosenberg, J., "Guidelines for Usage of Interactive
Architecture", draft-ietf-hip-rfc4423-bis-20 (work in Connectivity Establishment (ICE) by non Session Initiation
progress), February 2019. Protocol (SIP) Protocols", Work in Progress, Internet-
Draft, draft-rosenberg-mmusic-ice-nonsip-01, 14 July 2008,
<https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-
nonsip-01>.
[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 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Firewall Traversal Issues of Host Identity Protocol (HIP) with Session Description Protocol (SDP)", RFC 3264,
Communication", RFC 5207, DOI 10.17487/RFC5207, April DOI 10.17487/RFC3264, June 2002,
2008, <https://www.rfc-editor.org/info/rfc5207>. <https://www.rfc-editor.org/info/rfc3264>.
[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 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, Stenberg, "UDP Encapsulation of IPsec ESP Packets",
March 2012, <https://www.rfc-editor.org/info/rfc6538>. RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>.
[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>.
[I-D.heer-hip-middle-auth] [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Heer, T., Hummen, R., and M. Komu, "End-Host Firewall Traversal Issues of Host Identity Protocol (HIP)
Authentication for HIP Middleboxes", draft-heer-hip- Communication", RFC 5207, DOI 10.17487/RFC5207, April
middle-auth-04 (work in progress), October 2011. 2008, <https://www.rfc-editor.org/info/rfc5207>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<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-22
(work in progress), June 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 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538,
March 2012, <https://www.rfc-editor.org/info/rfc6538>.
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J.
Rosenberg, "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT
(STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
<https://www.rfc-editor.org/info/rfc8656>.
[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>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9068] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
Architecture", RFC 9063, DOI 10.17487/RFC9068, June 2021,
<https://www.rfc-editor.org/info/rfc9068>.
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
network characteristics are known beforehand. However, if the network characteristics are known beforehand. However, if the
characteristics are not known, it is recommended that the value is characteristics are not known, it is recommended that the value is
adjusted dynamically. In this case, it is recommended that the hosts adjusted dynamically. In this case, it is recommended that the hosts
estimate the round-trip time (RTT) between them and SHOULD set the estimate the round-trip time (RTT) between them, and they SHOULD set
minimum Ta value so that at most a single connectivity check message the minimum Ta value so that at most a single connectivity check
is sent on every RTT. message 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, thus the guidelines estimating RTT can be difficult and error prone; thus, the guidelines
for choosing a Ta value in Section 4.4 MUST be followed. 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 the 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 kernel-space IPsec ESP
as their data plane: demultiplexing of incoming ESP, HIP and TURN as their data plane: demultiplexing of incoming ESP, HIP, and TURN
messages required capturing of all UDP packets destined to port 10500 messages required the capturing of all UDP packets destined to port
to the userspace (due to different, incompatible markers in ESP and 10500 to the userspace (due to different, incompatible markers in ESP
STUN), thus causing additional software complexity and an unnecessary and STUN), thus causing additional software complexity and an
latency/throughput bottleneck for the dataplane performance. It is unnecessary latency/throughput bottleneck for the dataplane
also worth noting that demultiplexing of STUN packets in the kernel performance. It is also worth noting that the demultiplexing of STUN
would incur an also a performance impact (albeit smaller than with packets in the kernel would also incur a performance impact (albeit
userspace demultiplexing), and secure verification of STUN messages smaller than with userspace demultiplexing), and secure verification
would require communication between the kernelspace STUN detector and of STUN messages would require communication between the kernel-space
HIP daemon typically residing in the userspace (thus, again STUN detector and HIP daemon typically residing in the userspace
increasing the performance overhead). (thus again increasing the performance overhead).
Legacy ICE-HIP involves also some other complexities when compared to Legacy ICE-HIP also involves some other complexities when compared to
the approach taken in this document. Relaying of ESP packets via the approach taken in this document. The relaying of ESP packets via
TURN relays was not considered that simple because TURN relays TURN relays was not considered that simple because TURN relays
require adding and removing extra TURN framing for the relayed require adding and removing extra TURN framing for the relayed
packets. Finally, the developers of the two Legacy ICE-HIP packets. Finally, the developers of the two Legacy ICE-HIP
implementations concluded that "effort needed for integrating an ICE implementations concluded that effort needed for integrating an ICE
library into a HIP implementation turned out to be quite a bit higher library into a HIP implementation turned out to be quite a bit higher
that initially estimated. Also, the amount of extra code (some 10 than initially estimated. Also, the amount of extra code (some 10
kLoC) needed for all the new parsers, state machines, etc., is quite kLoC) needed for all the new parsers, state machines, etc., was quite
high and by re-using the HIP code one should be able to do with much high and by reusing the HIP code, one should be able to do with much
less. This should result in smaller binary size, less bugs, and less. This should result in smaller binary size, less bugs, and
easier debugging.". Consequently, the HIP working group decided to easier debugging.
follow ICE methodology but reuse HIP messaging format to achieve the
same functionality as ICE, and consequently the result is this Consequently, the HIP working group decided to follow ICE methodology
document that specifies the Native ICE-HIP protocol. but reuse HIP messaging format to achieve the same functionality as
ICE; the result of that is this document, which specifies the Native
ICE-HIP protocol.
The Native ICE-HIP protocol specified in this document follows the The Native ICE-HIP protocol specified in this document follows the
semantics of ICE as close as possible, and most of the differences semantics of ICE as close as possible, and most of the differences
are syntactical due to the use of a different protocol. In this are syntactical due to the use of a different protocol. In this
section, we describe the differences to the ICE protocol. section, we describe the differences to the ICE protocol.
o ICE operates at the application layer, whereas this protocol * ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o The STUN protocol is not employed. Instead, native ICE-HIP reuses * The STUN protocol is not employed. Instead, Native ICE-HIP reuses
the HIP control plane format in order simplify demultiplexing of the HIP control plane format in order to simplify the
different protocols. For example, the STUN binding response is demultiplexing of different protocols. For example, the STUN
replaced with a HIP UPDATE message containing an binding response is replaced with a HIP UPDATE message containing
ECHO_REQUEST_SIGNED parameter and the STUN binding response with a an ECHO_REQUEST_SIGNED parameter and the STUN binding response
HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as with a HIP UPDATE message containing an ECHO_RESPONSE_SIGNED
defined in Section 4.6. It is worth noting that a drawback of not parameter as defined in Section 4.6. It is worth noting that a
employing STUN is that discovery of the address candidates drawback of not employing STUN is that discovery of the address
requires creating (using HIP base exchange) and maintaining (using candidates requires creating (using HIP base exchange) and
HIP UPDATE procedures) state at the Control Relay Client and maintaining (using HIP UPDATE procedures) state at the Control
Control Relay Server. Future extensions to this document may Relay Client and Control Relay Server. Future extensions to this
define a stateless, HIP-specific mechanism for an end-host to document may define a stateless, HIP-specific mechanism for an end
discover its address candidates. host to discover its address candidates.
o The TURN protocol is not utilized. Instead, native ICE-HIP reuses * The TURN protocol is not utilized. Instead, Native ICE-HIP reuses
Control Relay Servers for the same purpose. Control Relay Servers for the same purpose.
o ICMP errors may be used in ICE to signal failure. In Native ICE- * ICMP errors may be used in ICE to signal failure. In the Native
HIP protocol, HIP NOTIFY messages are used instead. ICE-HIP protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for * Instead of the ICE username fragment and password mechanism for
credentials, native ICE-HIP uses the HIT, derived from a public credentials, Native ICE-HIP uses the HIT, derived from a public
key, for the same purpose. The username fragments are "transient key, for the same purpose. The username fragments are "transient
host identifiers, bound to a particular session established as host identifiers, bound to a particular session established as
part of the candidate exchange" [RFC8445]. Generally in HIP, a part of the candidate exchange" [RFC8445]. Generally in HIP, a
local public key and the derived HIT are considered long-term local public key and the derived HIT are considered long-term
identifiers, and invariant across different host associations and identifiers and invariant across different host associations and
different transport-layer flows. different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the * In ICE, the conflict when two communicating endpoints take the
same controlling role is solved using random values (so called same controlling role is solved using random values (a so-called
tie-breaker value). In Native ICE-HIP protocol, the conflict is tie-breaker value). In the Native ICE-HIP protocol, the conflict
solved by the standard HIP base exchange procedure, where the host is solved by the standard HIP base exchange procedure, where the
with the "larger" HIT switches to Responder role, thus changing host with the "larger" HIT switches to the Responder role, thus
also to controlled role. also changing to the controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included * The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks. in the connectivity checks.
o The foundation concept is unnecessary in native ICE-HIP because * The foundation concept is unnecessary in Native ICE-HIP because
only a single UDP flow for the IPsec tunnel will be negotiated. only a single UDP flow for the IPsec tunnel will be negotiated.
o Frozen candidates are omitted for the same reason as foundation * Frozen candidates are omitted for the same reason the foundation
concept is excluded. concept is excluded.
o Components are omitted for the same reason as foundation concept * Components are omitted for the same reason the foundation concept
is excluded. is excluded.
o Native ICE-HIP supports only "full ICE" where the two * Native ICE-HIP supports only "full ICE" where the two
communicating hosts participate actively to the connectivity communicating hosts participate actively to the connectivity
checks, and the "lite" mode is not supported. This design checks, and the "lite" mode is not supported. This design
decision follows the guidelines of ICE which recommends full ICE decision follows the guidelines of ICE, which recommends full ICE
implementations. However, it should be noted that a publicly implementations. However, it should be noted that a publicly
reachable Responder may refuse to negotiate the ICE mode as reachable Responder may refuse to negotiate the ICE mode as
described in Section 4.7.2. This would result in a [RFC7401] described in Section 4.7.2. This would result in a HIP base
based HIP base exchange tunneled over UDP followed ESP traffic exchange (as per [RFC7401]) tunneled over UDP, followed by ESP
over the same tunnel, without the connectivity check procedures traffic over the same tunnel, without the connectivity check
defined in this document (in some sense, this mode corresponds to procedures defined in this document (in some sense, this mode
the case where two ICE lite implementations connect since no corresponds to the case where two ICE lite implementations connect
connectivity checks are sent). since no connectivity checks are sent).
o As the "ICE lite" is not adopted here and both sides are capable * As the "ICE lite" is not adopted here and both sides are capable
of ICE-HIP-UDP mode (negotiated during the base exchange), default of ICE-HIP-UDP mode (negotiated during the base exchange), default
candidates are not employed in Native ICE-HIP. candidates are not employed in Native ICE-HIP.
o If the agent is using Diffserv Codepoint markings [RFC2475] in its * If the agent is using Diffserv Codepoint markings [RFC2475] in its
media packets, it SHOULD apply those same markings to its media packets, it SHOULD apply those same markings to its
connectivity checks. connectivity checks.
o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP * Unlike in ICE, the addresses are not XORed in the Native ICE-HIP
protocol but rather encrypted to avoid middlebox tampering. protocol but rather encrypted to avoid middlebox tampering.
o Native ICE-HIP protocol does not employ the ICE related address * ICE defines Related Address and Port attributes used for
and related port attributes (that are used for diagnostic or SIP diagnostic/SIP purposes, but the Native ICE-HIP protocol does not
purposes). employ these attributes.
o Minimum RTO is 500 ms in ICE but 1000 ms in Native ICE-HIP * The minimum RTO is 500 ms in ICE but 1000 ms in the Native ICE-HIP
protocol in favor of [I-D.ietf-tcpm-rto-consider] protocol in favor of [RFC8961].
Appendix C. Differences to Base Exchange and UPDATE procedures Appendix C. Differences to Base Exchange and UPDATE Procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers on how the
extensions in this protocol extend and differ from [RFC7401] and extensions in this protocol extend and differ from [RFC7401] and
[RFC8046]. [RFC8046].
o Both control and data plane are operated on top of UDP, not * Both the control and data plane are operated on top of UDP, not
directly on IP. directly on IP.
o A minimal implementation would conform only to Section 4.7.1 or * A minimal implementation would conform only to Sections 4.7.1 or
Section 4.7.2, thus merely tunneling HIP control and data traffic 4.7.2, thus merely tunneling HIP control and data traffic over
over UDP. The drawback here is that it works only in the limited UDP. The drawback here is that it works only in the limited cases
cases where the Responder has a public address. where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has * It is worth noting that while a Rendezvous Server [RFC8004] has
not been designed to be used in NATted scenarios because it just not been designed to be used in NATed scenarios because it just
relays the first I1 packet and does not employ UDP encapsulation, relays the first I1 packet and does not employ UDP encapsulation,
the Control Relay Server forwards all control traffic and, hence, the Control Relay Server forwards all control traffic and, hence,
is more suitable in NATted environments. Further, the Data Relay is more suitable in NATed environments. Further, the Data Relay
Server guarantees forwarding of data plane traffic also in the Server guarantees forwarding of data plane traffic also in cases
cases when the NAT traversal procedures fail. where the NAT traversal procedures fail.
o Registration procedures with a Control/Data Relay Server are * Registration procedures with a Control/Data Relay Server are
similar as with rendezvous server. However, a Control/Data Relay similar as with a Rendezvous Server. However, a Control/Data
Server has different registration parameters than rendezvous Relay Server has different registration parameters than a
because it offers a different service. Also, the Control/Data Rendezvous Server because it offers a different service. Also,
Relay Server includes also a REG_FROM parameter that informs the the Control/Data Relay Server also includes a REG_FROM parameter
Control/Data Relay Client about its server reflexive address. A that informs the Control/Data Relay Client about its server-
Data Relay Server includes also a RELAYED_ADDRESS containing the reflexive address. A Data Relay Server also includes a
relayed address for the Data Relay Client. RELAYED_ADDRESS containing the relayed address for the Data Relay
Client.
o In [RFC7401], the Initiator and Responder can start to exchange * In [RFC7401], the Initiator and Responder can start to exchange
application payload immediately after the base exchange. While application payload immediately after the base exchange. While
exchanging data immediately after a base exchange via a Data exchanging data immediately after a base exchange via a Data
Control Relay would be possible also here, we follow the ICE Control Relay would also be possible here, we follow the ICE
methodology to establish a direct path between two hosts using methodology to establish a direct path between two hosts using
connectivity checks. This means that there will be some connectivity checks. This means that there will be some
additional delay after the base exchange before application additional delay after the base exchange before application
payload can be transmitted. The same applies for the UPDATE payload can be transmitted. The same applies for the UPDATE
procedure as the connectivity checks introduce some additional procedure as the connectivity checks introduce some additional
delay. delay.
o In HIP without any NAT traversal support, the base exchange acts * In HIP without any NAT traversal support, the base exchange acts
as an implicit connectivity check, and the mobility and as an implicit connectivity check, and the mobility and
multihoming extensions support explicit connectivity checks. multihoming extensions support explicit connectivity checks.
After a base exchange or UPDATE based connectivity checks, a host After a base exchange or UPDATE-based connectivity checks, a host
can use the associated address pair for transmitting application can use the associated address pair for transmitting application
payload. In this Native ICE-HIP extension, we follow the ICE payload. In this Native ICE-HIP extension, we follow the ICE
methodology, where one end-point acting in the controlled role methodology where one endpoint acting in the controlled role
chooses the used address pair also on behalf of the other end- chooses the used address pair also on behalf of the other endpoint
point acting in controlled role, which is different from HIP acting in the controlled role, which is different from HIP without
without NAT traversal support. Another difference is that the NAT traversal support. Another difference is that the process of
process of choosing an address pair is explicitly signaled using choosing an address pair is explicitly signaled using the
the nomination packets. The nomination process in this protocol nomination packets. The nomination process in this protocol
supports only single address pair, and multihoming extensions are supports only a single address pair, and multihoming extensions
left for further study. are left for further study.
o The UPDATE procedure resembles the mobility extensions defined in * The UPDATE procedure resembles the mobility extensions defined in
[RFC8046]. The first UPDATE message from the mobile host is [RFC8046]. The first UPDATE message from the mobile host is
exactly the same as in the mobility extensions. The second UPDATE exactly the same as in the mobility extensions. The second UPDATE
message from the peer host and third from the mobile host are message from the peer host and third from the mobile host are
different in the sense that they merely acknowledge and conclude different in the sense that they merely acknowledge and conclude
the reception of the candidates through the Control Relay Server. the reception of the candidates through the Control Relay Server.
In other words, they do not yet test for connectivity (besides In other words, they do not yet test for connectivity (besides
reachability through the Control Relay Server) unlike in the reachability through the Control Relay Server) unlike in the
mobility extensions. The idea is that connectivity check mobility extensions. The idea is that the connectivity check
procedure follows the ICE specification, which is somewhat procedure follows the ICE specification, which is somewhat
different from the HIP mobility extensions. different from the HIP mobility extensions.
o The connectivity checks as defined in the mobility extensions * The connectivity checks as defined in the mobility extensions
[RFC8046] are triggered only by the peer of the mobile host. [RFC8046] are triggered only by the peer of the mobile host.
Since successful NAT traversal requires that both end-points test Since successful NAT traversal requires that both endpoints test
connectivity, both the mobile host and its peer host have to test connectivity, both the mobile host and its peer host have to test
for connectivity. In addition, this protocol validates also the for connectivity. In addition, this protocol also validates the
UDP ports; the ports in the connectivity check must match with the UDP ports; the ports in the connectivity check must match with the
response, as required by ICE. response, as required by ICE.
o In HIP mobility extensions [RFC8046], an outbound locator has some * In HIP mobility extensions [RFC8046], an outbound locator has some
associated state: UNVERIFIED mean that the locator has not been associated state: UNVERIFIED means that the locator has not been
tested for reachability, ACTIVE means that the address has been tested for reachability, ACTIVE means that the address has been
verified for reachability and is being used actively, and verified for reachability and is being used actively, and
DEPRECATED means that the locator lifetime has expired. In the DEPRECATED means that the locator lifetime has expired. In the
subset of ICE specifications used by this protocol, an individual subset of ICE specifications used by this protocol, an individual
address candidate has only two properties: type and priority. address candidate has only two properties: type and priority.
Instead, the actual state in ICE is associated with candidate Instead, the actual state in ICE is associated with candidate
pairs rather than individual addresses. The subset of ICE pairs rather than individual addresses. The subset of ICE
specifications utilized by this protocol require the following specifications utilized by this protocol require the following
attributes for a candidate pair: valid bit, nominated bit, base attributes for a candidate pair: valid bit, nominated bit, base,
and the state of connectivity check. The connectivity checks have and the state of the connectivity check. The connectivity checks
the following states: Waiting, In-progress, Succeeded and Failed. have the following states: Waiting, In-progress, Succeeded, and
Failed. Handling of this state attribute requires some additional
Handling of this state attribute requires some additional logic logic when compared to the mobility extensions, since the state is
when compared to the mobility extensions since the state is associated with a local-remote address pair rather than just a
associated with a local-remote address pair rather just a remote remote address; thus, the mobility and ICE states do not have an
address, and, thus, the mobility and ICE states do not have an
unambiguous one-to-one mapping. unambiguous one-to-one mapping.
o Credit-based authorization as defined in [RFC8046] could be used * Credit-based authorization as defined in [RFC8046] could be used
before candidate nomination has been concluded upon discovering before candidate nomination has been concluded upon discovering
working candidate pairs. However, this may result in the use of working candidate pairs. However, this may result in the use of
asymmetric paths for a short time period in the beginning of asymmetric paths for a short time period in the beginning of
communications. Thus, support of credit-based authorization is communications. Thus, support of credit-based authorization is
left for further study. left for further study.
Appendix D. Multihoming Considerations Appendix D. Multihoming Considerations
This document allows a host to collect address candidates from This document allows a host to collect address candidates from
multiple interfaces, but does not support activation and the multiple interfaces but does not support activation and the
simultaneous use of multiple address candidates. While multihoming simultaneous use of multiple address candidates. While multihoming
extensions to support [RFC8047] like functionality are left for extensions to support functionality similar to that found in
further study and experimentation, we envision here some potential [RFC8047] are left for further study and experimentation, we envision
compatibility improvements to support multihoming: here some potential compatibility improvements to support
multihoming:
o Data Relay Registration: a Data Relay Client acting as an Data Relay Registration: a Data Relay Client acting as an Initiator
Initiator with another peer host should register a new server with another peer host should register a new server-reflexive
reflexive candidate for each local transport address candidate. A candidate for each local transport address candidate. A Data
Data Relay Client acting as an Responder should register a new Relay Client acting as a Responder should register a new server-
server reflexive candidate for each { local transport address reflexive candidate for each {local transport address candidate,
candidate, new peer host} pair for the reasons described in new peer host} pair for the reasons described in Section 4.12.3.
Section 4.12.3. In both cases, the Data Relay Client should In both cases, the Data Relay Client should request the additional
request the additional server reflexive candidates by sending server-reflexive candidates by sending UPDATE messages originating
UPDATE messages originating from each of the local address from each of the local address candidates as described in
candidates as described in Section 4.1. As the UPDATE messages Section 4.1. As the UPDATE messages are originating from an
are originating from an unknown location from the viewpoint of the unknown location from the viewpoint of the Data Relay Server, it
Data Relay Server, it must include also a ECHO_REQUEST_SIGNED in must also include an ECHO_REQUEST_SIGNED in the response in order
the response in order to test for return routability. to test for return routability.
o Data Relay unregistration: this follows the procedure in Section 4 Data Relay unregistration: This follows the procedure in Section 4,
but the Data Relay Client should unregister using the particular but the Data Relay Client should unregister using the particular
transport address to be unregistered. All transport address pair transport address to be unregistered. All transport address pair
registrations can be unregistered when no RELAYED_ADDRESS registrations can be unregistered when no RELAYED_ADDRESS
parameter is included. parameter is included.
o PEER_PERMISSION parameter: this needs to be extended or an PEER_PERMISSION parameter: This needs to be extended or an
additional parameter is needed to declare the specific local additional parameter is needed to declare the specific local
candidate of the Data Relay Client. Alternatively, the use of the candidate of the Data Relay Client. Alternatively, the use of the
PEER_PERMISSION could be used as a wild card to open permissions PEER_PERMISSION could be used as a wild card to open permissions
for a specific peer to all of the candidates of the Data Relay for a specific peer to all of the candidates of the Data Relay
Client. Client.
o Connectivity checks: the controlling host should be able to Connectivity checks: The controlling host should be able to nominate
nominate multiple candidates (by repeating step 7 in Figure 5 in 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. Keepalives: These should be sent for all the nominated candidate
Similarly, the Control/Data Relay Client should send keepalives pairs. Similarly, the Control/Data Relay Client should send
from its local candidates to its Control/Data Relay Server keepalives from its local candidates to its Control/Data Relay
transport addresses. Server transport addresses.
Appendix E. DNS Considerations Appendix E. DNS Considerations
This section updates [RFC5770] Appendix B which will be replaced with This section updates Appendix B of [RFC5770], which will be replaced
the mechanism described in this section. with the mechanism described in this section.
[RFC5770] did not specify how an end-host can look up another end- [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 host via DNS and initiate a UDP-based HIP base exchange with it, so
this section makes an attempt to fill this gap. this section makes an attempt to fill this gap.
[RFC8005] specifies how a HIP end-host and its Rendezvous server is [RFC8005] specifies how a HIP end host and its Rendezvous Server is
registered to DNS. Essentially, the public key of the end-host 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. stored as a HI record and its Rendezvous Server as an A or AAAA
This way, the Rendezvous Server can act as an intermediary for the record. This way, the Rendezvous Server can act as an intermediary
end-host and forward packets to it based on the DNS configuration. for the end host and forward packets to it based on the DNS
Control Relay Server offers similar functionality as Rendezvous configuration. The Control Relay Server offers similar functionality
Server, with the difference that the Control Relay Server forwards to the Rendezvous Server, with the difference being that the Control
all control messages, not just the first I1 message. 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 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], either to the HIP end host itself or a Rendezvous Server [RFC8005],
and control and data plane communication with the associated host has and control and data plane communication with the associated host has
been assumed to occur directly over IPv4 or IPv6. However, this been assumed to occur directly over IPv4 or IPv6. However, this
specification extends the records to be used for UDP-based specification extends the records to be used for UDP-based
communications. communications.
Let us consider the case of a HIP Initiator with the default policy Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this to employ UDP encapsulation and the extensions defined in this
document. The Initiator looks up the FQDN of a Responder, and document. The Initiator looks up the Fully Qualified Domain Name
retrieves its HI, A and AAAA records. Since the default policy is to (FQDN) of a Responder, and retrieves its HI, A, and AAAA records.
use UDP encapsulation, the Initiator MUST send the I1 message over Since the default policy is to use UDP encapsulation, the Initiator
UDP to destination port 10500 (either over IPv4 in the case of a A MUST send the I1 message over UDP to destination port 10500 (either
record or over IPv6 in the case of a AAAA record). It MAY send an I1 over IPv4 in the case of an A record or over IPv6 in the case of an
message both with and without UDP encapsulation in parallel. In the AAAA record). It MAY send an I1 message both with and without UDP
case the Initiator receives R1 messages both with and without UDP encapsulation in parallel. In the case in which the Initiator
encapsulation from the Responder, the Initiator SHOULD ignore the R1 receives R1 messages both with and without UDP encapsulation from the
messages without UDP encapsulation. Responder, the Initiator SHOULD ignore the R1 messages without UDP
encapsulation.
The UDP encapsulated I1 packet could be received by three different The UDP-encapsulated I1 packet could be received by four different
types of hosts: types of hosts:
1. HIP Control Relay Server: in this case the A/AAAA records refers HIP Control Relay Server: In this case, the A/AAAA records refer to
to a Control Relay Server, and it will forward the packet to the a Control Relay Server, which will forward the packet to the
corresponding Control Relay Client based on the destination HIT corresponding Control Relay Client based on the destination HIT in
in the I1 packet. the I1 packet.
2. HIP Responder supporting UDP encapsulation: in this case, the A/ HIP Responder supporting UDP encapsulation: In this case, the A/AAAA
AAAA records refers to the end-host. Assuming the destination records refer to the end host. Assuming the destination HIT
HIT belongs to the Responder, it receives and processes it belongs to the Responder, the Responder receives and processes the
according to the negotiated NAT traversal mechanism. The support I1 packet according to the negotiated NAT traversal mechanism.
for the protocol defined in this document vs [RFC5770] is The support for the protocol defined in this document, as opposed
dynamically negotiated during the base exchange. The details are to the support defined in [RFC5770], is dynamically negotiated
specified in Section 4.3. during the base exchange. The details are specified in
Section 4.3.
3. HIP Rendezvous Server: this entity is not listening to UDP port HIP Rendezvous Server: This entity is not listening to UDP port
10500, so it will drop the I1 message. 10500, so it will drop the I1 message.
4. HIP Responder not supporting UDP encapsulation: the targeted end- HIP Responder not supporting UDP encapsulation: The targeted end
host is not listening to UDP port 10500, so it will drop the I1 host is not listening to UDP port 10500, so it will drop the I1
message. message.
The A/AAAA-record MUST NOT be configured to refer to a Data Relay 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 Server unless the host in question also supports Control Relay Server
functionality. functionality.
It also worth noting that SRV records are not employed in this It is also worth noting that SRV records are not employed in this
specification. While they could be used for more flexible UDP port specification. While they could be used for more flexible UDP port
selection, they are not suitable for end-host discovery but rather selection, they are not suitable for end-host discovery but rather
would be more suitable for the discovery of HIP-specific would be more suitable for the discovery of HIP-specific
infrastructure. Further extensions to this document may define SRV infrastructure. Further extensions to this document may define SRV
records for Control and Data Relay Server discovery within a DNS records for Control and Data Relay Server discovery within a DNS
domain. domain.
Acknowledgments
Thanks to Jonathan Rosenberg, Christer Holmberg, and the rest of the
MMUSIC WG folks for the excellent work on ICE. The authors would
also like to thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling,
Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their
contributions, and Tobias Heer, Teemu Koponen, Juhana Mattila,
Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka
Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim
Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani
Hautakorpi, Tero Kauppinen, and Timo Simanainen for their comments to
[RFC5770] and this document. Thanks to Éric Vyncke, Alvaro Retana,
Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kühlewind, Spencer
Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins,
Roni Even, Alissa Cooper, Carl Wallace, Martin Duke, and Benjamin
Kaduk for reviewing this document.
This work has been partially funded by the Cyber Trust Program by
Digile/Tekes in Finland.
Contributors
Marcelo Bagnulo, Philip Matthews, and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in
that RFC.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keränen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Jan Melen
Jan Melén
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: jan.melen@ericsson.com Email: jan.melen@ericsson.com
Miika Komu (editor) Miika Komu (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: miika.komu@ericsson.com Email: miika.komu@ericsson.com
 End of changes. 346 change blocks. 
1182 lines changed or deleted 1247 lines changed or added

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