draft-ietf-hip-native-nat-traversal-28.txt   draft-ietf-hip-native-nat-traversal-29.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track M. Komu, Ed. Intended status: Standards Track M. Komu, Ed.
Expires: September 6, 2018 Ericsson Expires: August 22, 2020 Ericsson
March 5, 2018 February 19, 2020
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-28 draft-ietf-hip-native-nat-traversal-29
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages instead of ICE for all NAT traversal procedures due to its
kernel-space dependencies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on August 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 10
4.2. Transport Address Candidate Gathering at the Relay Client 13 4.2. Transport Address Candidate Gathering at the Relay Client 13
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 15
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17
4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26
4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27
4.7.2. Base Exchange without Connectivity Checks . . . . . . 27 4.7.2. Base Exchange without Connectivity Checks . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . 29
4.8. Sending Control Packets after the Base Exchange . . . . . 29 4.8. Sending Control Packets after the Base Exchange . . . . . 29
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 34 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 39 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 40 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41
5.6. Relay and Registration Parameters . . . . . . . . . . . . 41 5.6. Relay and Registration Parameters . . . . . . . . . . . . 41
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49
skipping to change at page 2, line 51 skipping to change at page 3, line 4
5.6. Relay and Registration Parameters . . . . . . . . . . . . 41 5.6. Relay and Registration Parameters . . . . . . . . . . . . 41
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 49 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50
6.3. Base Exchange Replay Protection for Control Relay Server 50 6.3. Base Exchange Replay Protection for Control Relay Server 50
6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 51 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. Normative References . . . . . . . . . . . . . . . . . . 53 10.1. Normative References . . . . . . . . . . . . . . . . . . 53
10.2. Informative References . . . . . . . . . . . . . . . . . 55 10.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 56 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 56
Appendix B. Differences with respect to ICE . . . . . . . . . . 56 Appendix B. Differences with respect to ICE . . . . . . . . . . 57
Appendix C. Differences to Base Exchange and UPDATE procedures . 58 Appendix C. Differences to Base Exchange and UPDATE procedures . 59
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 60 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in directly on top of IPv4 or IPv6. However, many middleboxes found in
the Internet, such as NATs and firewalls, often allow only UDP or TCP the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, especially NATs usually require the traffic to pass [RFC5207]. Also, especially NATs usually require the
host behind a NAT to create a forwarding state in the NAT before host behind a NAT to create a forwarding state in the NAT before
other hosts outside of the NAT can contact the host behind the NAT. other hosts outside of the NAT can contact the host behind the NAT.
To overcome this problem, different methods, commonly referred to as To overcome this problem, different methods, commonly referred to as
NAT traversal techniques, have been developed. NAT traversal techniques, have been developed.
As one solution, the HIP experiment report [RFC6538] mentions that As one solution, the HIP experiment report [RFC6538] mentions Teredo-
Teredo based NAT traversal for HIP and related ESP traffic (with based NAT traversal for HIP and related ESP traffic (with double
double tunneling overhead). Another solution is specified in tunneling overhead). Another solution is specified in [RFC5770],
[RFC5770], which will be referred as "Legacy ICE-HIP" in this which will be referred as "Legacy ICE-HIP" in this document. The
document. The experimental Legacy ICE-HIP specification combines experimental Legacy ICE-HIP specification combines Interactive
Interactive Connectivity Establishment (ICE) protocol Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that
[I-D.ietf-ice-rfc5245bis] with HIP, so that basically ICE is basically ICE is responsible for NAT traversal and connectivity
responsible of NAT traversal and connectivity testing, while HIP is testing, while HIP is responsible for end-host authentication and
responsible of end-host authentication and IPsec key management. The IPsec key management. The resulting protocol uses HIP, STUN and ESP
resulting protocol uses HIP, STUN and ESP messages tunneled over a messages tunneled over a single UDP flow. The benefit of using ICE
single UDP flow. The benefit of using ICE and its STUN/TURN and its STUN/TURN messaging formats is that one can re-use the NAT
messaging formats is that one can re-use the NAT traversal traversal infrastructure already available in the Internet, such as
infrastructure already available in the Internet, such as STUN and STUN and TURN servers. Also, some middleboxes may be STUN-aware and
TURN servers. Also, some middleboxes may be STUN-aware and may be may be able to do something "smart" when they see STUN being used for
able to do something "smart" when they see STUN being used for NAT NAT traversal.
traversal.
Implementing a full ICE/STUN/TURN protocol stack as specified in HIP poses a unique challenge to using standard ICE, due not only to
Legacy ICE-HIP results in a considerable amount of effort and code its kernel-space implementation, but also due to its close
which could be avoided by re-using and extending HIP messages and integration with kernel-space IPSec; and, that while [RFC5770]
state machines for the same purpose. Thus, this document specifies provides a technically workable path, it incurs unacceptable
an alternative NAT traversal mode referred as "Native ICE-HIP" that performance drawbacks for kernel-space implementations. Also,
employs HIP messaging format instead of STUN or TURN for the implementing and integrating a full ICE/STUN/TURN protocol stack as
connectivity checks, keepalives and data relaying. Native ICE-HIP specified in Legacy ICE-HIP results in a considerable amount of
also specifies how mobility management works in the context of NAT effort and code which could be avoided by re-using and extending HIP
traversal, which is missing from the Legacy ICE-HIP specification. messages and state machines for the same purpose. Thus, this
The native specification is also based on HIPv2, whereas legacy document specifies an alternative NAT traversal mode referred as
specification is based on HIPv1. "Native ICE-HIP" that employs HIP messaging format instead of STUN or
TURN for the connectivity checks, keepalives and data relaying.
Native ICE-HIP also specifies how mobility management works in the
context of NAT traversal, which is missing from the Legacy ICE-HIP
specification. The native specification is also based on HIPv2,
whereas legacy specification is based on HIPv1. The differences to
the Legacy ICE-HIP are further elaborated in Appendix B.
Similarly as Legacy ICE-HIP, also this specification builds on the Similarly as Legacy ICE-HIP, also this specification builds on the
HIP registration extensions [RFC8003] and the base exchange procedure HIP registration extensions [RFC8003] and the base exchange procedure
[RFC7401] and its closing procedures, so the reader is recommended to [RFC7401] and its closing procedures, so the reader is recommended to
get familiar with the relevant specifications. In a nutshell, the get familiar with the relevant specifications. In a nutshell, the
registration extensions allow a HIP Initiator (usually a "client" registration extensions allow a HIP Initiator (usually a "client"
host) to ask for specific services from a HIP Responder (usually a host) to ask for specific services from a HIP Responder (usually a
"server" host). The registration parameters are included in a base "server" host). The registration parameters are included in a base
exchange, which is essentially a four-way Diffie-Hellman key exchange exchange, which is essentially a four-way Diffie-Hellman key exchange
authenticated using the public keys of the end-hosts. When the hosts authenticated using the public keys of the end-hosts. When the hosts
skipping to change at page 4, line 43 skipping to change at page 4, line 49
the peer tests for connectivity (so called return routability check), the peer tests for connectivity (so called return routability check),
for which the mobile hosts must respond in order to activate its new for which the mobile hosts must respond in order to activate its new
location. This specification builds on the mobility procedures, but location. This specification builds on the mobility procedures, but
modifies it to be compatible with ICE. The differences to the modifies it to be compatible with ICE. The differences to the
mobility extensions specified in Appendix C. It is worth noting that mobility extensions specified in Appendix C. It is worth noting that
multihoming support as specified in [RFC8047] is left for further multihoming support as specified in [RFC8047] is left for further
study. 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
[I-D.ietf-ice-rfc5245bis] (especially the overview). However, native [RFC8445] (especially the overview). However, native ICE-HIP does
ICE-HIP does not implement all the features in ICE, and, hence, the not implement all the features in ICE, and, hence, the different
different features of ICE are cross referenced using [RFC2119] features of ICE are cross referenced using [RFC2119] terminology for
terminology for clarity. Appendix B explains the differences to ICE, clarity. Appendix B explains the differences to ICE, and it is
and it is recommended that the reader would read also this section in recommended that the reader would read also this section in addition
addition to the ICE specification. to the ICE 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document borrows terminology from [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The [RFC8046], [RFC4423], [RFC8445], and [RFC5389]. 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 [I-D.ietf-ice-rfc5245bis] 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 Initiator is the host that initiates the base exchange using
I1 message. I1 message [RFC7401].
Responder: Responder:
The Responder is the host that receives the I1 packet from the The Responder is the host that receives the I1 packet from the
Initiator. 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, this host is address realms. In the Legacy ICE-HIP specification [RFC5770],
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, this is denoted messages). In the Legacy ICE-HIP specification [RFC5770], this is
as "HIP Relay Client". denoted as "HIP Relay Client".
Data Relay Server: Data Relay Server:
A registrar host that forwards HIP related data plane packets, A new entity introduced in this document; a registrar host that
such as Encapsulating Security Payload (ESP) [RFC7402], between forwards HIP related data plane packets, such as Encapsulating
two hosts. This host implements similar functionality as TURN Security Payload (ESP) [RFC7402], between two hosts. This host
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). it to forward data-plane traffic (e.g. ESP traffic). This
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
Security Parameter Index (SPI). It may also include transport Security Parameter Index (SPI). It may also include transport
port numbers or IPv6 Flow Labels as demultiplexing context, or it port numbers or IPv6 Flow Labels as 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. locators together [RFC8046].
ICE offer: HIP offer:
The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. Before two end-hosts can establish a communication channel using
Corresponds to the ICE offer parameter, but is HIP specific. the NAT traversal procedures defined in this document, they need
exchange their locators (i.e. candidates) with each other. In
ICE, this procedure is called Candidate Exchange and it does
specify how the candidates are exchanged but Session Description
Protocol (SDP) "offer/answer" is mentioned as an example. In
contrast, the Candidate Exchange in HIP is the base exchange
itself or a subsequent UPDATE prodecure occurring after a
handover. Following [RFC5770] and Session Description Protocol
(SDP) [RFC3264] naming conventions, "HIP offer" is the the
Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE
control packet.
ICE answer: HIP answer:
The Responder's LOCATOR_SET parameter in a HIP R2 control packet. The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE
Corresponds to the ICE answer parameter, but is HIP specific. control packet. Corresponds to the SDP answer parameter
[RFC3264], but is HIP specific. Please refer also to the 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 is the Initiator. It nominates the candidate The controlling host [RFC8445] is always the Initiator in the
pair to be used with the controlled host. context of this specification. It nominates the candidate pair to
be used with the controlled host.
Controlled host: Controlled host:
The controlled host is the Responder. It waits for the The controlled host [RFC8445] is always the Responder in the
controlling to nominate an address candidate pair. context of this specification. It waits for the controlling to
nominate an address candidate pair.
Checklist: Checklist:
A list of address candidate pairs that need to be tested for A list of address candidate pairs that need to be tested for
connectivity. connectivity (same as in [RFC8445]).
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address. Transport layer port and the corresponding IPv4/v6 address (same
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. 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. 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. 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]).
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. Client. The concept is the same as in [RFC8445], but a Data Relay
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 channels. Before a host can use a concept similar to TURN's ([RFC5766]) channels. Before a host can
relayed candidate to forward traffic through a Data Relay Server, use a relayed candidate to forward traffic through a Data Relay
the host must activate the relayed candidate with a specific peer Server, the host must activate the relayed candidate with a
host. specific peer host.
Base: Base:
The base of a candidate is the local source address a host uses to Similarly as in [RFC8445], the base of a candidate is the local
send packets for the associated candidate. For example, the base source address a host uses to send packets for the associated
of a server reflexive address is the local address the host used candidate. For example, the base of a server reflexive address is
for registering itself to the associated Control or Data Relay the local address the host used for registering itself to the
Server. The base of a host candidate is equal to the host associated Control or Data Relay Server. The base of a host
candidate itself. 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 8, line 31 skipping to change at page 8, line 51
+-------+ +-------+ +-------+ +-------+
| Init- | | Resp- | | Init- | | Resp- |
| iator | | onder | | iator | | onder |
+-------+ +-------+ +-------+ +-------+
Figure 1: Example Network Configuration Figure 1: Example Network Configuration
In the example configuration depicted in Figure 1, both Initiator and In the example configuration depicted in Figure 1, both Initiator and
Responder are behind one or more NATs, and both private networks are Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
at least the Responder must be registered with a Control Relay Server at least the Responder must be registered with is own Control Relay
reachable on the public Internet. The Responder may have also Server 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 any Relay Servers, it may act in the other role with does not need a Data Relay Server, it may act in the other role with
other hosts, and connectivity with the Data Relay Server of the other hosts, and connectivity with the Data Relay Server of the
Responder may fail, so the Initiator may also need to register to a Responder may fail, so the Initiator may also need to register to a
Cotrol and/or Data Relay Server. It is worth noting that a Control Cotrol and/or Data Relay Server. It is worth noting that a Control
and Data Relay does not forge the source address of a passing packet, and Data Relay does not forge the source address of a passing packet,
but always translates the source address and source port of a packet but always translates the source address and source port of a packet
to be forwarded (to its own). to be forwarded (to its own).
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
skipping to change at page 9, line 19 skipping to change at page 9, line 39
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, also the HIP signaling can be sent over the
same address/port pair, and is demultiplexed from IPsec as described same address/port pair, and is demultiplexed (or, in other words,
in the UDP encapsulation standard for IPsec [RFC3948]. Finally, the separated) from IPsec as described in the UDP encapsulation standard
two hosts send NAT keepalives as needed in order keep their UDP- for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as
tunnel state active in the associated NAT boxes. needed in order keep their UDP-tunnel state active in the associated
NAT boxes.
If either one of the hosts knows that it is not behind a NAT, hosts If either one of the hosts knows that it is not behind a NAT, hosts
can negotiate during the base exchange a different mode of NAT can negotiate during the base exchange a different mode of NAT
traversal that does not use HIP connectivity checks, but only UDP traversal that does not use HIP connectivity checks, but only UDP
encapsulation of HIP and ESP. Also, it is possible for the Initiator encapsulation of HIP and ESP. Also, it is possible for the Initiator
to simultaneously try a base exchange with and without UDP to simultaneously try a base exchange with and without UDP
encapsulation. If a base exchange without UDP encapsulation encapsulation. If a base exchange without UDP encapsulation
succeeds, no HIP connectivity checks or UDP encapsulation of ESP are succeeds, no HIP connectivity checks or UDP encapsulation of ESP are
needed. needed.
4. Protocol Description 4. Protocol Description
This section describes the normative behavior of the "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] instead of HIPv1 is expected to be used with this version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT
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 NATted 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 relaying of HIP
control plane traffic over UDP in NATted environments, and forwards control plane traffic over UDP in NATted 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
RELAY_UDP_ESP 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 guarantee also data plane delivery over varying types of NAT
devices, a host MAY also register for UDP encapsulated ESP relaying devices, a host MAY also register for UDP encapsulated ESP relaying
using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This
service may be coupled with the Control Relay Server or offered service may be coupled with the Control Relay Server or offered
separately on another server. If the server supports relaying of UDP separately on another server. If the server supports relaying of UDP
encapsulated ESP, the host is allowed to register for a data relaying encapsulated ESP, the host is allowed to register for a data relaying
service using the registration extensions in Section 3.3 of service using the registration extensions in Section 3.3 of
[RFC8003]). If the server has sufficient relaying resources (free [RFC8003]). If the server has sufficient relaying resources (free
port numbers, bandwidth, etc.) available, it opens a UDP port on one port numbers, bandwidth, etc.) available, it opens a UDP port on one
of its addresses and signals the address and port to the registering of its addresses and signals the address and port to the registering
host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 host using the RELAYED_ADDRESS parameter (as defined in Section 5.12
in this document). If the Data Relay Server would accept the data in 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].
A Control Relay Server MUST silently drop packets to a Control Relay The registration process follows the generic registration extensions
Client that has not previously registered with the HIP relay. 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
data cases. data cases.
Control/Data Control/Data Control/Data Control/Data
skipping to change at page 11, line 25 skipping to change at page 11, line 27
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, |
| [RELAYED_ADDRESS])) | | [RELAYED_ADDRESS])) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
Figure 2: Example Registration with a HIP Relay Figure 2: Example Registration with a HIP Relay
In step 1, the Relay Client (Initiator) starts the registration In step 1, the Relay Client (Initiator) starts the registration
procedure by sending an I1 packet over UDP to the Relay Server. It procedure by sending an I1 packet over UDP to the Relay Server. It
is RECOMMENDED that the Relay Client select a random port number from is RECOMMENDED that the Relay Client select a random source port
the ephemeral port range 49152-65535 for initiating a base exchange. number from the ephemeral port range 49152-65535 for initiating a
Alternatively, a host MAY also use a single fixed port for initiating base exchange. Alternatively, a host MAY also use a single fixed
all outgoing connections. However, the allocated port MUST be port for initiating all outgoing connections. However, the allocated
maintained until all of the corresponding HIP Associations are port MUST be maintained until all of the corresponding HIP
closed. It is RECOMMENDED that the Relay Server listen to incoming Associations are closed. It is RECOMMENDED that the Relay Server
connections at UDP port 10500. If some other port number is used, it listen to incoming connections at UDP port 10500. If some other port
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 supports also relaying of ESP
traffic over UDP, it includes also Registration type value traffic over UDP, it includes also Registration type value
RELAY_UDP_ESP. RELAY_UDP_ESP.
In step 3, the Relay Client selects the services for which it In step 3, the Relay Client selects the services for which it
registers and lists them in the REG_REQ parameter. The Relay Client registers and lists them in the REG_REQ parameter. The Relay Client
skipping to change at page 12, line 29 skipping to change at page 12, line 32
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 this can cause problems with port for each Data Relay Client because not doing so can cause
stateful firewalls (see Section 6.5). problems with stateful firewalls (see Section 6.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 both renewals of service registration but also to host This applies to both renewals of service registration and to host
movement, where especially the latter requires the Control Relay movement. It is especially important for the case of host movement,
Client to learn its new server reflexive address candidate. as this is the mechanism that allows the Control Relay Client to
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 a ECHO_REQUEST_SIGNED
parameter. The Data Relay Server MUST respond with an UPDATE message parameter. The Data Relay Server MUST respond with an UPDATE message
that includes the corresponding response parameters: REG_RES, ACK and that includes the corresponding response parameters: REG_RES, ACK and
ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new
relayed UDP port for the Data Relay Client, the REG_RES parameter relayed UDP port for the Data Relay Client, the REG_RES parameter
MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also
include a RELAYED_ADDRESS parameter describing the relayed UDP port. include a RELAYED_ADDRESS parameter describing the relayed UDP port.
The Data Relay Server MUST also include the Server Reflexive The Data Relay Server MUST also include the Server Reflexive
candidate in a REG_FROM parameter. It is worth mentioning that Data candidate in a REG_FROM parameter. It is worth mentioning that Data
Relay Client MUST activate the UDP port as described in Relay Client MUST activate the UDP port as described in
skipping to change at page 13, line 45 skipping to change at page 13, line 50
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 to A Data Relay Client MAY register only a single relayed candidate that
be used 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 reflexive 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 peer 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: registration
request (REG_REQ) parameter with Registration Type request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED
parameter. When a Control Relay Server receives an UPDATE message parameter. When a Control Relay Server receives an UPDATE message
with registration request containing a CANDIDATE_DISCOVERY type, it with registration request containing a CANDIDATE_DISCOVERY type, it
MUST include a REG_FROM parameter, containing the same information as MUST include a REG_FROM parameter, containing the same information as
if this were a Control Relay Server registration, to the response (in if 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.
ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are The rules in section 5.1.1 in [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 the ICE specification others) should be excluded as described in section 5.1.1.1 of the ICE
[I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in specification [RFC8445]. Relayed candidates SHOULD be gathered in
order to guarantee successful NAT traversal, and implementations order to guarantee successful NAT traversal, and implementations
SHOULD support this functionality even if it will not be used in SHOULD support this functionality even if it will not be used in
deployments in order to enable it by software configuration update if deployments in order to enable it by software configuration update if
needed at some point. A host SHOULD employ only a single server for needed at some point. Similarly as explained in section 5.1.1.2 of
gathering the candidates for a single HIP association; either one the ICE specification [RFC8445], if an IPv6-only host is in a network
server providing both Control and Data Relay Server functionality, or that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it
one Control Relay Server and also Data Relay Server if the may also gather IPv4 server- reflexive and/or relayed candidates from
functionality is offered by another server. When the relay service IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also
is split between two hosts, the server reflexive candidate from the utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix
Control Relay Server SHOULD be used instead of the one provided by used by NAT64 (if any) and generate server-reflexive candidates for
the Data Relay Server. If a relayed candidate is identical to a host each IPv6-only interface, accordingly. The NAT64 server-reflexive
candidate, the relayed candidate must be discarded. NAT64 candidates are prioritized like IPv4 server-reflexive candidates.
considerations in [I-D.ietf-ice-rfc5245bis] apply as well.
HIP based connectivity can be utilized by IPv4 applications using HIP based connectivity can be utilized by IPv4 applications using
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 following recommended formula (as described in [RFC8445]) SHOULD be
[I-D.ietf-ice-rfc5245bis]) 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, type preference follows the ICE specification In the formula, the type preference follows the ICE specification (as
guidelines: the RECOMMENDED values are 126 for host candidates, 100 defined in section 5.1.2.2 in [RFC8445]): the RECOMMENDED values are
for server reflexive candidates, 110 for peer reflexive candidates, 126 for host candidates, 100 for server reflexive candidates, 110 for
and 0 for relayed candidates. The highest value is 126 (the most peer reflexive candidates, and 0 for relayed candidates. The highest
preferred) and lowest is 0 (last resort). For all candidates of the value is 126 (the most preferred) and lowest is 0 (last resort). For
same type, the preference type value MUST be identical, and, all candidates of the same type, the preference type value MUST be
correspondingly, the value MUST be different for different types. identical, and, correspondingly, the value MUST be different for
For peer reflexive values, the type preference value MUST be higher different types. For peer reflexive values, the type preference
than for server reflexive types. It should be noted that peer value MUST be higher than for server reflexive types. It should be
reflexive values are learned later during connectivity checks, so a noted that peer reflexive values are learned later during
host cannot employ it during candidate gathering stage yet. connectivity checks, so a host cannot employ it during candidate
gathering stage yet.
Following the ICE specification, the local preference MUST be an Following the ICE specification, the local preference MUST be an
integer from 0 (lowest preference) to 65535 (highest preference) integer from 0 (lowest preference) to 65535 (highest preference)
inclusive. In the case the host has only a single address candidate, inclusive. In the case the host has only a single address candidate,
the value SHOULD be 65535. In the case of multiple candidates, each the value SHOULD be 65535. In the case of multiple candidates, each
local preference value MUST be unique. Dual-stack considerations for local preference value MUST be unique. Dual-stack considerations for
IPv6 in ICE apply also here. IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2.
Unlike ICE, this protocol only creates a single UDP flow between the Unlike with SDP used in conjunction with ICE, this protocol only
two communicating hosts, so only a single component exists. Hence, creates a single UDP flow between the two communicating hosts, so
the component ID value MUST always be set to 1. only a single component exists. Hence, the component ID value MUST
always be set to 1.
As defined in ICE , the retransmission timeout (RTO) for address As defined in section 14.3 in [RFC8445], the retransmission timeout
gathering from a Control/Data Relay Server SHOULD be calculated as (RTO) for address gathering from a Control/Data Relay Server SHOULD
follows: be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Of-Pairs)) RTO = MAX (500ms, Ta * (Num-Of-Cands))
where Ta is the value used for the connectivity check pacing and Num- where Ta is the value used for the connectivity check pacing and Num-
Of-Pairs is number of pairs of candidates with Control and Data Relay Of-Cands is the sum of server-reflexive and relay candidates. A
Servers (e.g. in the case of a single server, it would be 1). A
smaller value than 500 ms for the RTO MUST NOT be used. smaller value than 500 ms for the RTO MUST NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a non-critical parameter type
type. The presence of the parameter in a HIP base exchange means called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
that the end-host supports NAT traversal extensions described in this presence of the parameter in a HIP base exchange means that the end-
document. As the parameter is non-critical (as defined in host supports NAT traversal extensions described in this document.
Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which
means that the host is not required to support it or may decline to As the parameter is non-critical (as defined in Section 5.2.1 of
use it. [RFC7401]), it can be ignored by a end-host, which means that the
host is not required to 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.
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+--------------------------------------------------------------->| +----------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) |
|<---------------------------------------------------------------+ |<-----------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), LOC_SET, ..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+--------------------------------------------------------------->| +----------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., 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. In step 2,
the Responder responds with an R1. As specified in [RFC5770], the the Responder responds with an R1. As specified in [RFC5770], the
NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal
modes the Responder supports. The mode specified in this document is modes the Responder supports. The mode specified in this document is
ICE-HIP-UDP (value [TBD by IANA: 3]). ICE-HIP-UDP (value [TBD by IANA: 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 LOC_SET). The locators in I2 are LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP
the "ICE offer". mode, the LOCATOR_SET parameter MUST be encapsulated within an
ENCRYPTED parameter (denoted here with ENC) according to the
procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in
I2 are the "HIP offer".
In step 4, the Responder concludes the base exchange with an R2 In step 4, the Responder concludes the base exchange with an R2
packet. If the Initiator chose ICE NAT traversal mode, the Responder packet. If the Initiator chose ICE NAT traversal mode, the Responder
includes a LOCATOR_SET parameter in the R2 packet. The locators in includes a LOCATOR_SET parameter in the R2 packet. With ICE-HIP-UDP
R2, encoded like the locators in I2, are the "ICE answer". If the mode, the LOCATOR_SET parameter MUST be encapsulated within an
NAT traversal mode selected by the Initiator is not supported by the ENCRYPTED parameter according to the procedures in sections 5.2.18
Responder, the Responder SHOULD reply with a NOTIFY packet with type and 6.5 in [RFC7401]. The locators in R2, encoded like the locators
in I2, are the "ICE answer". If the NAT traversal mode selected by
the Initiator is not supported by the Responder, the Responder SHOULD
reply with a NOTIFY packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
4.4. Connectivity Check Pacing Negotiation 4.4. Connectivity Check Pacing Negotiation
As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode
with connectivity checks is used, new transactions should not be with connectivity checks is used, new transactions should not be
started too fast to avoid congestion and overwhelming the NATs. For started too fast to avoid congestion and overwhelming the NATs. For
this purpose, during the base exchange, hosts can negotiate a this purpose, during the base exchange, hosts can negotiate a
transaction pacing value, Ta, using a TRANSACTION_PACING parameter in transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
R1 and I2 packets. The parameter contains the minimum time R1 and I2 packets. The parameter contains the minimum time
(expressed in milliseconds) the host would wait between two NAT (expressed in milliseconds) the host would wait between two NAT
traversal transactions, such as starting a new connectivity check or traversal transactions, such as starting a new connectivity check or
retrying a previous check. The value that is used by both of the retrying a previous check. The value that is used by both of the
hosts is the higher of the two offered values. hosts is the higher of the two offered values.
The minimum Ta value SHOULD be configurable, and if no value is The minimum Ta value SHOULD be configurable, and if no value is
configured, a value of 50 ms MUST be used. Guidelines for selecting configured, a value of 50 ms MUST be used. Guidelines for selecting
a Ta value are given in Appendix A. Hosts SHOULD NOT use values a Ta value are given in Appendix A. Hosts MUST NOT use values
smaller than 5 ms for the minimum Ta, since such values may not work smaller than 5 ms for the minimum Ta, since such values may not work
well with some NATs (as explained in [I-D.ietf-ice-rfc5245bis]). The well with some NATs (as explained in [RFC8445]). The Initiator MUST
Initiator MUST NOT propose a smaller value than what the Responder NOT propose a smaller value than what the Responder offered. If a
offered. If a host does not include the TRANSACTION_PACING parameter host does not include the TRANSACTION_PACING parameter in the base
in the base exchange, a Ta value of 50 ms MUST be used as that host's exchange, a Ta value of 50 ms MUST be used as that host's minimum
minimum value. value.
4.5. Base Exchange via Control Relay Server 4.5. Base Exchange via Control Relay Server
This section describes how the Initiator and Responder perform a base This section describes how the Initiator and Responder perform a base
exchange through a Control Relay Server. Connectivity pacing exchange through a Control Relay Server. Connectivity pacing
(denoted as TA_P here) was described in Section 4.4 and is not (denoted as TA_P here) was described in Section 4.4 and is not
repeated here. Similarly, the NAT traversal mode negotiation process repeated here. Similarly, the NAT traversal mode negotiation process
(denoted as NAT_TM in the example) was described in Section 4.3 and (denoted as NAT_TM in the example) was described in Section 4.3 and
is neither repeated here. If a Control Relay Server receives an R1 is neither repeated here. If a Control Relay Server receives an R1
or I2 packet without the NAT traversal mode parameter, it MUST drop or I2 packet without the NAT traversal mode parameter, it MUST drop
skipping to change at page 18, line 16 skipping to change at page 18, line 27
| 1. UDP(I1) | | | 1. UDP(I1) | |
+--------------------------------->| 2. UDP(I1(RELAY_FROM)) | +--------------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TM, | | | 3. UDP(R1(RELAY_TO, NAT_TM, |
| | TA_P)) | | | TA_P)) |
| 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+
| TA_P)) | | | TA_P)) | |
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
| 5. UDP(I2(LOC_SET, NAT_TM, | | | 5. UDP(I2(ENC(LOC_SET)), | |
| TA_P)) | | | NAT_TM, TA_P)) | |
+--------------------------------->| 6. UDP(I2(LOC_SET, RELAY_FROM, | +--------------------------------->| 6. UDP(I2(ENC(LOC_SET), |
| | NAT_TM, TA_P)) | | | RELAY_FROM, NAT_TM, TA_P))|
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(LOC_SET, RELAY_TO)) | | | 7. UDP(R2(ENC(LOC_SET), |
| 8. UDP(R2(LOC_SET, RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(ENC(LOC_SET), | 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.
skipping to change at page 19, line 30 skipping to change at page 19, line 42
changes the destination address and port to match RELAY_TO changes the destination address and port to match RELAY_TO
information. Finally, the Control Relay Server recalculates the information. Finally, the Control Relay Server recalculates the
transport checksum and forwards the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [RFC7401]. The Initiator MAY use the address in the according to [RFC7401]. The Initiator MAY use the address in the
RELAY_TO parameter as a local peer-reflexive candidate for this HIP RELAY_TO parameter as a local peer-reflexive candidate for this HIP
association if it is different from all known local candidates. The association if it is different from all known local candidates. The
Initiator replies with an I2 packet that uses the destination Initiator replies with an I2 packet that uses the destination
transport address of R1 as the source address and port. The I2 transport address of R1 as the source address and port. The I2
packet contains a LOCATOR_SET parameter that lists all the HIP packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter
candidates (ICE offer) of the Initiator. The candidates are encoded that lists all the HIP candidates (HIP offer) of the Initiator. The
using the format defined in Section 5.7. The I2 packet MUST also candidates are encoded using the format defined in Section 5.7. The
contain a NAT traversal mode parameter that includes ICE-HIP-UDP I2 packet MUST also contain a NAT traversal mode parameter that
mode. includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its
key material generation are described in detail in sections 5.2.18
and 6.5 in [RFC7401].
In step 6, the Control Relay Server receives the I2 packet. The In step 6, the Control Relay Server receives the I2 packet. The
Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
packet similarly as explained in step 2, and forwards the packet to packet similarly as explained in step 2, and forwards the packet to
the Responder. the Responder.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC7401]. It replies with an R2 packet and includes a according to [RFC7401]. The Responder validates the RELAY_HMAC
according to [RFC8004] and silently drops the packet if the
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 that lists all the HIP candidates (ICE answer) LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all
of the Responder. The RELAY_TO parameter is protected by the HMAC. the HIP candidates (ICE answer) of the Responder. The RELAY_TO
parameter is protected by the HMAC. The ENCRYPTED parameter along
with its key material generation are 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 if they intend to use such the LOCATOR_SET parameter in I2 and R2 if they intend to use such
servers for relaying HIP signaling immediately after the base servers for relaying HIP signaling immediately after the base
skipping to change at page 20, line 23 skipping to change at page 20, line 41
used after the base exchange. Instead, further HIP signaling SHOULD used after the base exchange. Instead, further HIP signaling SHOULD
use the same path as the data traffic. It is RECOMMENDED to use the use the same path as the data traffic. It is RECOMMENDED to use the
same Control Relay Server throughout the lifetime of the host same Control Relay Server throughout the lifetime of the host
association that was used for forwarding the base exchange if the association that was used for forwarding the base exchange if the
Responder includes it in the locator parameter of the R2 message. Responder includes it in the locator parameter of the R2 message.
4.6. Connectivity Checks 4.6. Connectivity Checks
When the Initiator and Responder complete the base exchange through When the Initiator and Responder complete the base exchange through
the Control Relay Server, both of them employ the IP address of the the Control Relay Server, both of them employ the IP address of the
Control Relay Server as the destination address for the packets. Control Relay Server as the destination address for the packets. The
This address MUST NOT be used as a destination for ESP traffic (i.e., address of the Control Relay Server MUST NOT be used as a destination
the corresponding Control Relay Client cannot advertise it to its for data plane traffic unless the server supports also Data Relay
peer) unless the server supports also Data Relay Server Server functionality, and the Client has successfully registered to
functionality, for which the client has successfully registered to. use it. When NAT traversal mode with ICE-HIP-UDP was successfully
When NAT traversal mode with ICE-HIP-UDP was successfully negotiated negotiated and selected, the Initiator and Responder MUST start the
and selected, the Initiator and Responder MUST start the connectivity connectivity checks in order to attempt to obtain direct end-to-end
checks in order to attempt to obtain direct end-to-end connectivity connectivity through NAT devices. It is worth noting that the
through NAT devices. It is worth noting that the connectivity checks connectivity checks MUST be completed even though no ESP_TRANSFORM
MUST be completed even though no ESP_TRANSFORM would be negotiated would be negotiated and selected.
and selected.
The connectivity checks follow the ICE methodology [MMUSIC-ICE], but The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
UDP encapsulated HIP control messages are used instead of ICE UDP encapsulated HIP control messages are used instead of ICE
messages. Only normal nomination MUST be used for the connectivity messages. As stated in the ICE specification, the basic procedure
checks, i.e., aggressive nomination MUST NOT be employed. As stated for connectivity checks has three phases: sorting the candidate pairs
in the ICE specification, the basic procedure for connectivity checks according their priority, sending checks in the prioritized order and
has three phases: sorting the candidate pairs according their acknowledging the checks from the peer host.
priority, sending checks in the prioritized order and acknowledging
the checks from the peer host.
The Initiator MUST take the role of controlling host and the The Initiator MUST take the role of controlling host and the
Responder acts as the controlled host. The roles MUST persist Responder acts as the controlled host. The roles MUST persist
throughout the HIP associate lifetime (to be reused in the possibly throughout the HIP associate lifetime (to be reused in the possibly
mobility UPDATE procedures). In the case both communicating nodes mobility UPDATE procedures). In the case both communicating nodes
are initiating the communications to each other using an I1 packet, are initiating the communications to each other using an I1 packet,
the conflict is resolved as defined in section 6.7 in [RFC7401]: the the conflict is resolved as defined in section 6.7 in [RFC7401]: the
host with the "larger" HIT changes to its Role to Responder. In such host with the "larger" HIT changes to its Role to Responder. In such
a case, the host changing its role to Responder MUST also switch to a case, the host changing its role to Responder MUST also switch to
controlling 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 section 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 and
NOMINATE). NOMINATE).
4.6.1. Connectivity Check Procedure 4.6.1. Connectivity Check Procedure
Figure 5 illustrates connectivity checks in a simplified scenario, Figure 5 illustrates connectivity checks in a simplified scenario,
where the Initiator and Responder have only a single candidate pair where the Initiator and Responder have only a single candidate pair
skipping to change at page 23, line 6 skipping to change at page 23, line 6
includes a running sequence identifier for the connectivity check. includes a running sequence identifier for the connectivity check.
The candidate priority (denoted "CAND_PRIO" in the figure) describes The candidate priority (denoted "CAND_PRIO" in the figure) describes
the priority of the address candidate being tested. The the priority of the address candidate being tested. The
ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a
nonce that the recipient must sign and echo back as it is. nonce that the recipient must sign and echo back as it is.
In step 2, the Initiator sends a connectivity check, using the same In step 2, the Initiator sends a connectivity check, using the same
address pair candidate as in 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 traverses successfully 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 Responder, 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 includes also 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
skipping to change at page 23, line 35 skipping to change at page 23, line 35
message from the Responder. The Initiator acknowledges the SEQ message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the parameter from the previous message using ACK parameter and the
ECHO_REQUEST_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 MAPPED_ADDR parameter that includes the peer
reflexive candidate. This response message is successfully delivered reflexive candidate. This response message is successfully delivered
to the Responder, and upon reception the Initiator marks the to the Responder, and 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 (due to the use of normal nomination). way as in the previous steps. It should be noted that each
It should be noted that each connectivity check has a unique sequence connectivity check has a unique sequence number in the SEQ parameter.
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 NOMINATE parameter
from the Initiator. It sends a response that includes the NOMINATE from the Initiator. It sends a response that includes the NOMINATE
parameter in addition to a number of other parameters. The ACK and parameter in addition to a number of other parameters. The ACK and
skipping to change at page 25, line 7 skipping to change at page 25, line 7
MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and
correspondingly the peer MUST respond to these using ACK and correspondingly the peer MUST respond to these using ACK and
ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401]. ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401].
The host sending a connectivity check MUST validate that the response The host sending a connectivity check MUST validate that the response
uses the same pair of UDP ports, and drop the packet if this is not uses the same pair of UDP ports, and drop the packet if this is not
the case. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A queue a response by placing it in the triggered-check queue, and then
host MUST NOT select a candidate pair until it has verified the pair continue waiting for the candidates. A host MUST NOT select a
using a connectivity check as defined in Section 4.6.1. candidate pair until it has verified the pair using a connectivity
check as defined in Section 4.6.1.
[RFC7401] states that UPDATE packets have to include either a SEQ or [RFC7401] states that UPDATE packets have to include either a SEQ or
ACK parameter (or both). According to the RFC, each SEQ parameter ACK parameter (or both). According to the RFC, each SEQ parameter
should be acknowledged separately. In the context of NATs, this should be acknowledged separately. In the context of NATs, this
means that some of the SEQ parameters sent in connectivity checks means that some of the SEQ parameters sent in connectivity checks
will be lost or arrive out of order. From the viewpoint of the will be lost or arrive out of order. From the viewpoint of the
recipient, this is not a problem since the recipient will just recipient, this is not a problem since the recipient will just
"blindly" acknowledge the SEQ. However, the sender needs to be "blindly" acknowledge the SEQ. However, the sender needs to be
prepared for lost sequence identifiers and ACKs parameters that prepared for lost sequence identifiers and ACKs parameters that
arrive out of order. arrive out of order.
As specified in [RFC7401], an ACK parameter may acknowledge multiple As specified in [RFC7401], an ACK parameter may acknowledge multiple
sequence identifiers. While the examples in the previous sections do sequence identifiers. While the examples in the previous sections do
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode. employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some be sent with the same sequence identifier in the SEQ parameter. Some
tested address candidates will never produce a working address pair, tested address candidates will never produce a working address pair,
and thus may cause retransmissions. Upon successful nomination an and thus may cause retransmissions. Upon successful nomination of an
address pair, a host MAY immediately stop sending such address pair, a host SHOULD immediately stop sending such
retransmissions. retransmissions.
ICE procedures for prioritizing candidates, eliminating redundant Full ICE procedures for prioritizing candidates, eliminating
candidates and forming check lists (including pruning) must be redundant candidates, forming check lists (including pruning) and
followed (as specified in [I-D.ietf-ice-rfc5245bis]), with the triggered check-queues MUST be followed as specified in section 6.1
exception that the foundation, frozen candidates and default [RFC8445], with the exception that the foundation, frozen candidates
candidates are not used. From viewpoint of the ICE specification and default candidates are not used. From viewpoint of the ICE
[I-D.ietf-ice-rfc5245bis], the protocol specified in this document specification [RFC8445], the protocol specified in this document
operates using Component ID of 1 on all candidates, and the operates using Component ID of 1 on all candidates, and the
foundation of all candidates is unique. This specification defines foundation of all candidates is unique. This specification defines
only "full ICE" mode, and the "lite ICE" is not supported. The only "full ICE" mode, and the "lite ICE" is not supported. The
reasoning behind the missing features is described in Appendix B. reasoning behind the missing features is described in Appendix B.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
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 SHOULD 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 (500ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
"In-Progress" state. This is identical to the formula in "In-Progress" state. This is identical to the formula in [RFC8445]
[I-D.ietf-ice-rfc5245bis] when there is only one checklist. A when there is only one checklist. A smaller value than 500 ms for
smaller value than 500 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 [I-D.ietf-ice-rfc5245bis], it is Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict
RECOMMENDED to restrict the total number of connectivity checks to the total number of connectivity checks to 100 for each host
100 for each host association. This can be achieved by limiting the association. This can be achieved by limiting the connectivity
connectivity checks to the 100 candidate pairs with the highest checks to the 100 candidate pairs with the highest priority.
priority.
4.6.3. Rules for Concluding Connectivity Checks 4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence UPDATE message that contains a SEQ parameter (with new sequence
number), a ECHO_REQUEST_SIGNED parameter, the priority of the number), a 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 NOMINATE parameter to
skipping to change at page 28, line 15 skipping to change at page 28, line 15
In certain network environments, the connectivity checks can be In certain network environments, the connectivity checks can be
omitted to reduce initial connection set-up latency because a base omitted to reduce initial connection set-up latency because a base
exchange acts as an implicit connectivity test itself. For this to exchange acts as an implicit connectivity test itself. For this to
work, the Initiator MUST be able to reach the Responder by simply UDP work, the Initiator MUST be able to reach the Responder by simply UDP
encapsulating HIP and ESP packets sent to the Responder's address. encapsulating HIP and ESP packets sent to the Responder's address.
Detecting and configuring this particular scenario is prone to Detecting and configuring this particular scenario is prone to
failure unless carefully planned. failure unless carefully planned.
In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT
traversal mode as one of the supported modes in the R1 packet. If traversal mode as one of the supported modes in the R1 packet. If
the Responder has registered to a Control Relay Server, it MUST also the Responder has registered to a Control Relay Server in order to
include a LOCATOR_SET parameter in R1 that contains a preferred discover its address candidates, it MUST also include a LOCATOR_SET
address where the Responder is able to receive UDP-encapsulated ESP parameter in R1 that contains a preferred address where the Responder
and HIP packets. This locator MUST be of type "Transport address", is able to receive UDP-encapsulated ESP and HIP packets. This
its Traffic type MUST be "both", and it MUST have the "Preferred bit" locator MUST be of type "Transport address", its Traffic type MUST be
set (see Table 1). If there is no such locator in R1, the source "both", and it MUST have the "Preferred bit" set (see Table 1). If
address of R1 is used as the Responder's preferred address. there is no such locator in R1, the source address of R1 is used as
the Responder's preferred address.
The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder
listed it in the supported modes and the Initiator does not wish to listed it in the supported modes and the Initiator does not wish to
use the connectivity checks defined in this document for searching use the connectivity checks defined in this document for searching
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. However, the between the hosts after the base exchange completes according to the
Responder SHOULD NOT send any ESP to the Initiator's address before rules in Section 4.4 in [RFC7401].
it has received data from the Initiator, as specified in Sections
4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of
[RFC8046].
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected The Control Relay Server can be used for discovering address
MUST NOT be sent via a Control Relay Server, the Responder SHOULD candidates but it is not intended to be used for relaying end-host
reject such I2 packets and reply with a packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent
Section 5.10). via a Control Relay Server, the Responder SHOULD reject such I2
packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY
packet (see Section 5.10).
If there is no answer for the I2 packet sent directly to the If there is no answer for the I2 packet sent directly to the
Responder's preferred address, the Initiator MAY send another I2 via Responder's preferred address, the Initiator MAY send another I2 via
the 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
skipping to change at page 29, line 27 skipping to change at page 29, line 27
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly, without The I1 packet without UDP encapsulation may arrive directly, without
passing any Control Data Relays, at the Responder. When this passing any Control Data Relays, at the Responder. When this
happens, the procedures in [RFC7401] are followed for the rest of the happens, the procedures in [RFC7401] are followed for the rest of the
base exchange. The Initiator may receive multiple R1 packets, with base exchange. The Initiator may receive multiple R1 packets, with
and without UDP encapsulation, from the Responder. However, after and without UDP encapsulation, from the Responder. However, after
receiving a valid R1 and answering it with an I2, further R1 packets receiving a valid R1 and answering it with an I2, further R1 packets
that are not retransmissions of the original R1 message 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
skipping to change at page 30, line 36 skipping to change at page 30, line 36
4.9. Mobility Handover Procedure 4.9. Mobility Handover Procedure
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [RFC8046] define handover procedures Mobility extensions for HIP [RFC8046] define handover procedures
without NATs. In this section, we define how two hosts interact with without NATs. In this section, we define how two hosts interact with
handover procedures in scenarios involving NATs. The specified handover procedures in scenarios involving NATs. The specified
extensions define only simple mobility using a pair of security extensions define only simple mobility using a pair of security
associations, and multihoming extensions are left to be defined in associations, and multihoming extensions are left to be defined in
later specifications. The procedures in this section offer the same later specifications. The procedures in this section offer the same
functionality as "ICE restart" specified in functionality as "ICE restart" specified in [RFC8445]. The example
[I-D.ietf-ice-rfc5245bis]. The example described in this section described in this section shows only a Control Relay Server for the
shows only a Control Relay Server for the peer host for the sake of peer host for the sake of simplicity, but the mobile host may also
simplicity, but the mobile host may also have a Control Relay Server. have a Control Relay Server.
The assumption here is that the two hosts have successfully The assumption here is that the two hosts have successfully
negotiated and chosen the ICE-HIP-UDP mode during the base exchange negotiated and chosen the ICE-HIP-UDP mode during the base exchange
as defined in Section 4.3. The Initiator of the base exchange MUST as defined in Section 4.3. The Initiator of the base exchange MUST
store information that it was the controlling host during the base store information that it was the controlling host during the base
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
Prior to starting the handover procedures with all peer hosts, the Prior to starting the handover procedures with all peer hosts, the
mobile host SHOULD first send its locators in UPDATE messages to its mobile host SHOULD first send its locators in UPDATE messages to its
skipping to change at page 32, line 7 skipping to change at page 32, line 7
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 in the 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, | |
| LOC_SET, SEQ)) | | | ENC(LOC_SET), SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | LOC_SET, SEQ, | | | ENC(LOC_SET), SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(UPDATE(ESP_INFO, SEQ, | | | 3. UDP(UPDATE(ESP_INFO, SEQ, |
| | ACK, ECHO_REQ_SIGN, | | | ACK, ECHO_REQ_SIGN, |
| | RELAY_TO)) | | | RELAY_TO)) |
| 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+
| ACK, ECHO_REQ_SIGN, | | | ACK, ECHO_REQ_SIGN, | |
| RELAY_TO)) | | | RELAY_TO)) | |
|<---------------------------------+ | |<---------------------------------+ |
skipping to change at page 32, line 45 skipping to change at page 32, line 45
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 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. The packet contains of the mobile host in a LOCATOR_SET parameter, encapsulated inside an
also a SEQ number to be acknowledged by the peer. As specified in ENCRYPTED parameter (see sections 5.2.18 and 6.5 in [RFC7401] for
[RFC8046], the packet may also include a HOST_ID (for middlebox details on the ENCRYPTED parameter). The packet contains also a SEQ
inspection) and DIFFIE_HELLMAN parameter for rekeying. number to be acknowledged by the peer. As specified in [RFC8046],
the packet may also include a HOST_ID (for middlebox inspection) and
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 and
responds with another UPDATE message. The message is destined to the responds with another UPDATE message. The message is destined to the
HIT of mobile host and to the IP address of the Control Relay Server. HIT of mobile host and to the IP address of the Control Relay Server.
The message includes an ESP_INFO parameter where, in this case, the The message includes an ESP_INFO parameter where, in this case, the
skipping to change at page 39, line 30 skipping to change at page 39, line 37
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
5.3. Keepalives 5.3. Keepalives
The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
as specified in [RFC7401] with Notify message type field set to as specified in [RFC7401] with Notify message type field set to
NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification
data field. It is worth noting that sending of such a HIP NOTIFY data field. It is worth noting that sending of such a HIP NOTIFY
message MAY be omitted if the host is actively (or passively) sending message SHOULD be omitted if the host is actively (or passively)
some other traffic (HIP or ESP) to the peer host over the related UDP sending some other traffic (HIP or ESP) to the peer host over the
tunnel during the Tr period. For instance, the host MAY actively related UDP tunnel during the Tr period. For instance, the host MAY
send ICMPv6 requests (or respond with an ICMPv6 response) inside the actively send ICMPv6 requests (or respond with an ICMPv6 response)
ESP tunnel to test the health of the associated IPsec security inside the ESP tunnel to test the health of the associated IPsec
association. Alternatively, the host MAY use UPDATE packets as a security association. Alternatively, the host MAY use UPDATE packets
substitute. A minimal UPDATE packet would consist of a SEQ and as a substitute. A minimal UPDATE packet would consist of a SEQ and
ECHO_REQ_SIGN parameters, and a more complex would involve rekeying ECHO_REQ_SIGN parameters, and a more complex would involve rekeying
procedures as specified in section 6.8 in [RFC7402]. It is worth procedures as specified in section 6.8 in [RFC7402]. It is worth
noting that a host actively sending periodic UPDATE packets to a busy noting that a host actively sending periodic UPDATE packets to a busy
server may increase the computational load of the server since it has server may increase the computational load of the server since it has
to verify HMACs and signatures in UPDATE messages. to verify HMACs and signatures in UPDATE messages.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from Legacy The format of NAT traversal mode parameter is borrowed from Legacy
ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is ICE-HIP [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is
skipping to change at page 41, line 26 skipping to change at page 41, line 34
Length 4 Length 4
Min Ta the minimum connectivity check transaction pacing Min Ta the minimum connectivity check transaction pacing
value the host would use (in milliseconds) value the host would use (in milliseconds)
Figure 9: Format of the TRANSACTION_PACING Parameter Figure 9: Format of the TRANSACTION_PACING Parameter
5.6. Relay and Registration Parameters 5.6. Relay and Registration Parameters
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
shown in Figure 10. All parameters are identical except for the shown in Figure 10. All parameters are identical except for the
type. REG_FROM is the only parameter covered with the signature. type. 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 |
skipping to change at page 44, line 21 skipping to change at page 44, line 21
| Traffic | 0-2 | Is the locator for HIP signaling (1), for | | Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) | | Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type | | Locator | 2 | "Transport address" locator type |
| Type | | | | Type | | |
| Locator | 7 | Length of the fields after Locator | | Locator | 7 | Length of the fields after Locator |
| Length | | Lifetime in 4-octet units | | Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions | | Reserved | 0 | Reserved for future extensions |
| Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | | 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 | | (P) bit | | Responder can use it for the rest of the |
| | | base exchange, otherwise set to zero | | | | base exchange, otherwise set to zero |
| Locator | Variable | Locator lifetime in seconds | | Locator | Variable | Locator lifetime in seconds, see Section 4 |
| Lifetime | | | | Lifetime | | in [RFC8046] |
| Transport | Variable | Transport layer port number | | Transport | Variable | Transport layer port number |
| Port | | | | Port | | |
| Transport | Variable | IANA assigned, transport layer Internet | | Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. | | | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive (currently unused) or 3 for |
| | | relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-ice-rfc5245bis]. It is worth | | | | [RFC8445]. It is worth noting that while |
| | | noting that while the priority of a single | | | | the priority of a single locator candidate |
| | | locator candidate is 32-bits, but an | | | | is 32-bits, but an implementation should |
| | | implementation should use a 64-bit integer | | | | use a 64-bit integer to calculate the |
| | | to calculate the priority of a candidate | | | | priority of a candidate pair for the ICE |
| | | pair for the ICE priority algorithm. | | | | priority algorithm. |
| SPI | Variable | Security Parameter Index (SPI) value that | | SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP | | | | the host expects to see in incoming ESP |
| | | packets that use this locator | | | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 1: Fields of the LOCATOR_SET Parameter Table 1: Fields of the LOCATOR_SET Parameter
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
[RFC8004]. as specified in section 4.2.1 in [RFC8004]. Similarly as with
RVS_HMAC, also RELAY_HMAC is is keyed with the HIP integrity key
(HIP-lg or HIP-gl as specified in section 6.5 in [RFC7401]),
established during the 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 (value [TBD
by IANA: 3]). by IANA: 3]).
5.10. Notify Packet Types 5.10. Notify Packet Types
skipping to change at page 49, line 40 skipping to change at page 49, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4710] Type [TBD by IANA; 4710]
Length 4 Length 4
Reserved Reserved for future extension purposes Reserved Reserved for future extension purposes
Figure 15: Format of the NOMINATE Parameter Figure 15: Format of the NOMINATE Parameter
6. Security Considerations 6. Security Considerations
The security considerations are the same as in Legacy ICE-HIP Since the control plane protocol and Control Relay Server are
[RFC5770], but are repeated here for the sake of completeness. essentially the same (with some minor differences) in this document
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
valid, but are repeated here for the sake of completeness. New
security considerations related to the new Data Relay Server are
discussed in Section 6.5, and considerations related to the new
connectivity check protocol are discussed in Section 6.6 and
Section 6.7.
6.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in plain text format in favor of inspection at HIP-
aware middleboxes in the future. The current document does not
specify encrypted versions of LOCATOR_SETs, even though it could be
beneficial for privacy reasons to avoid disclosing them to
middleboxes.
It is also possible that end-users may not want to reveal all It is also possible that end-users may not want to reveal all
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 reasons, an be allowed in all corporate environments. For these two local policy
end-host may exclude certain host addresses from its LOCATOR_SET reasons, an end-host MAY exclude certain host addresses from its
parameter. However, such behavior creates non-optimal paths when the LOCATOR_SET parameter, but this requires further experimentation.
hosts are located behind the same NAT. Especially, this could be However, such behavior creates non-optimal paths when the hosts are
problematic with a legacy NAT that does not support routing from the located behind the same NAT. Especially, this could be problematic
private address realm back to itself through the outer address of the with a legacy NAT that does not support routing from the private
NAT. This scenario is referred to as the hairpin problem [RFC5128]. address realm back to itself through the outer address of the NAT.
With such a legacy NAT, the only option left would be to use a This scenario is referred to as the hairpin problem [RFC5128]. With
relayed transport address from a TURN server. such a legacy NAT, the only option left would be to use a relayed
transport address from an Control Relay Server server.
The use of Control and Data Relay Servers can be also useful for The use of Control and Data Relay Servers can be also useful for
privacy purposes. For example, a privacy concerned Responder may privacy purposes. For example, a privacy concerned Responder may
reveal only its Control Relay Server and Relayed candidates to reveal only its Control Relay Server and Relayed candidates to
Initiators. This same mechanism also protects the Responder against Initiators. This partially protects the Responder against Denial-of-
Denial-of-Service (DoS) attacks by allowing the Responder to initiate Service (DoS) attacks by allowing the Responder to initiate new
new connections even if its relays would be unavailable due to a DoS connections even if its relays would be unavailable due to a DoS
attack. attack.
6.2. Opportunistic Mode 6.2. Opportunistic Mode
In opportunistic HIP mode, an Initiator sends an I1 with without In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an
setting the destination HIT of the Responder (i.e. the Control Relay Initiator sends an I1 with without setting the destination HIT of the
Client). A Control Relay Server SHOULD have a unique IP address per Responder (i.e. the Control Relay Client). A Control Relay Server
Control Relay Client when the Control Relay Server is serving more SHOULD have a unique IP address per Control Relay Client when the
than one Control Relay Client and supports opportunistic mode. Control Relay Server is serving more than one Control Relay Client
Otherwise, the Control Relay Server cannot guarantee to deliver the and supports opportunistic mode. Otherwise, the Control Relay Server
I1 packet to the intended recipient. Future extensions of this cannot guarantee to deliver the I1 packet to the intended recipient.
document may allow opportunistic mode to be used with non-unique IP Future extensions of this document may allow opportunistic mode to be
addresses to be utilized either as a HIP-level anycast or multicast used with non-unique IP addresses to be utilized either as a HIP-
mechanism. Both of the mentioned cases would require a separate level anycast or multicast mechanism. Both of the mentioned cases
registration parameters that the Control Relay Server proposes and would require a separate registration parameters that the Control
the Control Client Server accepts during registration. Relay Server proposes and the Control Client Server accepts during
registration.
6.3. Base Exchange Replay Protection for Control Relay Server 6.3. Base Exchange Replay Protection for Control Relay Server
In certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a 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.
skipping to change at page 51, line 39 skipping to change at page 51, line 45
able to send packets to a peer behind the firewall. Therefore, a 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 re-use the port numbers. If port
numbers need to be re-used, the Data Relay Server SHOULD have a numbers need to be re-used, the Data Relay Server SHOULD have a
sufficiently large pool of port numbers and select ports from the sufficiently large pool of port numbers and select ports from the
pool randomly to decrease the chances of a Data Relay Client pool randomly to decrease the chances of a Data Relay Client
obtaining the same address that a another host behind the same obtaining the same address that a another host behind the same
firewall is using. firewall is using.
6.6. Amplification attacks 6.6. Amplification attacks
A malicious host may send an invalid list of candidates for its peer A malicious host may send an invalid list of candidates 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 6.7. Attacks against Connectivity Checks and Candidate Gathering
[I-D.ietf-ice-rfc5245bis] describes attacks against ICE connectivity Section 19.2 in [RFC8445] describes attacks against ICE connectivity
checks. HIP bases its control plane security on Diffie-Hellman key checks. HIP bases its control plane security on Diffie-Hellman key
exchange, public keys and Hashed Message Authentication codes, exchange, public keys and Hashed Message Authentication codes,
meaning that the mentioned security concerns do not apply to HIP meaning that the mentioned security concerns do not apply to HIP
either. The mentioned section discusses also of man-in-the-middle either. The mentioned section discusses also of man-in-the-middle
replay attacks that are difficult to prevent. The connectivity replay attacks that are difficult to prevent. The connectivity
checks in this protocol are immune against replay attacks because a checks in this protocol are immune against replay attacks because a
connectivity request includes a random nonce that the recipient must connectivity request includes a random nonce that the recipient must
sign and send back as a response. sign and send back as a response.
[I-D.ietf-ice-rfc5245bis] describes attacks on server reflexive Section 19.3 in [RFC8445] describes attacks on server reflexive
address gathering. Similarly here, if the DNS, a Control Relay address gathering. Similarly here, if the DNS, a Control Relay
Server or a Data Relay Server has been compromised, not much can be Server or a Data Relay Server has been compromised, not much can be
done. However, the case where attacker can inject fake messages done. However, the case where attacker can inject fake messages
(located on a shared network segment like Wifi) does not apply here. (located on a shared network segment like Wifi) does not apply here.
HIP messages are integrity and replay protected, so it is not HIP messages are integrity and replay protected, so it is not
possible inject fake server reflexive address candidates. possible inject fake server reflexive address candidates.
[I-D.ietf-ice-rfc5245bis] describes attacks on relayed candidate Section 19.4 in [RFC8445] describes attacks on relayed candidate
gathering. Similarly to ICE TURN servers, Data Relay Server require gathering. Similarly to ICE TURN servers, Data Relay Server require
an authenticated base exchange that protects relayed address 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.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC8126]. This section is to be interpreted according to [RFC8126].
skipping to change at page 52, line 50 skipping to change at page 53, line 11
defined in Section 5.12), PEER_PERMISSION (length 48, defined in defined in Section 5.12), PEER_PERMISSION (length 48, defined in
Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14)
and NOMINATE (length 4, defined in Section 5.15). and NOMINATE (length 4, defined in Section 5.15).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
traversal mode ICE-HIP-UDP (defined in Section 5.4). traversal mode ICE-HIP-UDP (defined in Section 5.4).
This document updates the IANA Registry for HIP Notify Message Types: This document updates the IANA Registry for HIP Notify Message Types:
type field NAT_KEEPALIVE in Section 5.3 and a new error type type field NAT_KEEPALIVE in Section 5.3 and a new error type
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.9. SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.10.
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC8003] that allow registering with a Data Registration Extension [RFC8003] that allow registering with a Data
Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in
Section 5.9, and performing server reflexive candidate discovery: Section 5.9, and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2).
ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral ICE specification [RFC8445] discusses "Unilateral Self-Address
Self-Address Fixing" . This protocol is based on ICE, and thus the Fixing" in section 18. This protocol is based on ICE, and thus the
same considerations apply also here with one exception: this protocol same considerations apply also here.
does not hide binary IP addresses from application-level gateways.
8. Contributors 8. Contributors
Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have
contributed to [RFC5770]. This document leans heavily on the work in contributed to [RFC5770]. This document leans heavily on the work in
the RFC. the RFC.
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the
skipping to change at page 53, line 44 skipping to change at page 53, line 51
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[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>.
[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>.
[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, <https://www.rfc- DOI 10.17487/RFC8046, February 2017,
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, <https://www.rfc- DOI 10.17487/RFC8047, February 2017,
editor.org/info/rfc8047>. <https://www.rfc-editor.org/info/rfc8047>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, <https://www.rfc- DOI 10.17487/RFC5389, October 2008,
editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 7402, the Host Identity Protocol (HIP)", RFC 7402,
DOI 10.17487/RFC7402, April 2015, <https://www.rfc- DOI 10.17487/RFC7402, April 2015,
editor.org/info/rfc7402>. <https://www.rfc-editor.org/info/rfc7402>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 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>.
[I-D.ietf-ice-rfc5245bis] [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
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", draft-ietf-ice- Address Translator (NAT) Traversal", RFC 8445,
rfc5245bis-15 (work in progress), November 2017. DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
10.2. Informative References 10.2. Informative References
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP) Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators", Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010, RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>. <https://www.rfc-editor.org/info/rfc5770>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
skipping to change at page 56, line 5 skipping to change at page 56, line 34
[HIP-MIDDLE] [HIP-MIDDLE]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Work in Progress, Authentication for HIP Middleboxes", Work in Progress,
February 2009. February 2009.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
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
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
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 set the minimum estimate the round-trip time (RTT) between them and SHOULD set the
Ta value so that only two connectivity check messages are sent on minimum Ta value so that at most a single connectivity check message
every RTT. is sent on every RTT.
One way to estimate the RTT is to use the time that it takes for the One way to estimate the RTT is to use the time that it takes for the
Control Relay Server registration exchange to complete; this would Control Relay Server registration exchange to complete; this would
give an estimate on the registering host's access link's RTT. Also, give an estimate on the registering host's access link's RTT. Also,
the I1/R1 exchange could be used for estimating the RTT, but since the I1/R1 exchange could be used for estimating the RTT, but since
the R1 can be cached in the network, or the relaying service can the R1 can be cached in the network, or the relaying service can
increase the delay notably, this is not recommended. increase the delay notably, this is not recommended. In general,
estimating RTT can be difficult and error prone; further
experimentation is required for reliable RTT estimation.
Appendix B. Differences with respect to ICE Appendix B. Differences with respect to ICE
Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The
benefits of such as an approach include the reuse of STUN/TURN benefits of such as an approach include the reuse of STUN/TURN
infrastructure and possibly the reuse of existing software libraries, infrastructure and possibly the reuse of existing software libraries,
but there are also drawbacks with the approach. For example, ICE is but there are also drawbacks with the approach. For example, ICE is
meant for application-layer protocols, whereas HIP operates at layer meant for application-layer protocols, whereas HIP operates at layer
3.5 between transport and network layers. This is particularly 3.5 between transport and network layers. This is particularly
problematic because the implementations employ IPsec ESP as their problematic because the implementations employ kernelspace IPsec ESP
data plane: demultiplexing of incoming ESP, HIP and TURN messages as their data plane: demultiplexing of incoming ESP, HIP and TURN
required capturing of all UDP packets destined to port 10500 to the messages required capturing of all UDP packets destined to port 10500
userspace, thus causing additional software complexity and an to the userspace (due to different, incompatible markers in ESP and
unnecessary latency/throughput bottleneck for the dataplane STUN), thus causing additional software complexity and an unnecessary
performance. Also, relaying of ESP packets via TURN relays was not latency/throughput bottleneck for the dataplane performance. It is
considered that simple because TURN relays require adding and also worth noting that demultiplexing of STUN packets in the kernel
removing extra TURN framing for the relayed packets. Finally, the would incur an also a performance impact (albeit smaller than with
developers of the two Legacy ICE-HIP implementations concluded that userspace demultiplexing), and secure verification of STUN messages
"effort needed for integrating an ICE library into a HIP would require communication between the kernelspace STUN detector and
implementation turned out to be quite a bit higher that initially HIP daemon typically residing in the userspace (thus, again
estimated. Also, the amount of extra code (some 10 kLoC) needed for increasing the performance overhead).
all the new parsers, state machines, etc., is quite high and by re-
using the HIP code one should be able to do with much less. This Legacy ICE-HIP involves also some other complexities when compared to
should result in smaller binary size, less bugs, and easier the approach taken in this document. Relaying of ESP packets via
debugging.". Consequently, the HIP working group decided to follow TURN relays was not considered that simple because TURN relays
ICE methodology but reuse HIP messaging format to achieve the same require adding and removing extra TURN framing for the relayed
functionality as ICE, and consequently the result is this document packets. Finally, the developers of the two Legacy ICE-HIP
that specifies the Native ICE-HIP protocol. implementations concluded that "effort needed for integrating an ICE
library into a HIP implementation turned out to be quite a bit higher
that initially estimated. Also, the amount of extra code (some 10
kLoC) needed for all the new parsers, state machines, etc., is quite
high and by re-using the HIP code one should be able to do with much
less. This should result in smaller binary size, less bugs, and
easier debugging.". Consequently, the HIP working group decided to
follow ICE methodology but reuse HIP messaging format to achieve the
same functionality as ICE, and consequently the result is this
document that 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 o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o The STUN protocol is not employed. Instead, native ICE-HIP reuses o The STUN protocol is not employed. Instead, native ICE-HIP reuses
the HIP control plane format in order simplify demultiplexing of the HIP control plane format in order simplify demultiplexing of
different protocols. For example, the STUN binding response is different protocols. For example, the STUN binding response is
replaced with a HIP UPDATE message containing an replaced with a HIP UPDATE message containing an
ECHO_REQUEST_SIGNED parameter and the STUN binding response with a ECHO_REQUEST_SIGNED parameter and the STUN binding response with a
HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as
defined in Section 4.6. defined in Section 4.6. It is worth noting that a drawback of not
employing STUN is that discovery of the address candidates
requires creating (using HIP base exchange) and maintaining (using
HIP UPDATE procedures) state at the Control Relay Client and
Control Relay Server. Future extensions to this document may
define a stateless, HIP-specific mechanism for an end-host to
discover its address candidates.
o The TURN protocol is not utilized. Instead, native ICE-HIP reuses o 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- o ICMP errors may be used in ICE to signal failure. In Native ICE-
HIP protocol, HIP NOTIFY messages are used instead. HIP protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for o Instead of the ICE username fragment and password mechanism for
credentials, 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" [I-D.ietf-ice-rfc5245bis]. part of the candidate exchange" [RFC8445]. Generally in HIP, a
Generally in HIP, a local public key and the derived HIT are local public key and the derived HIT are considered long-term
considered long-term identifiers, and invariant across different identifiers, and invariant across different host associations and
host associations and different transport-layer flows. different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the o In ICE, the conflict when two communicating end-points take the
same controlling role is solved using random values (so called same controlling role is solved using random values (so called
tie-breaker value). In Native ICE-HIP protocol, the conflict is tie-breaker value). In Native ICE-HIP protocol, the conflict is
solved by the standard HIP base exchange procedure, where the host solved by the standard HIP base exchange procedure, where the host
with the "larger" HIT switches to Responder role, thus changing with the "larger" HIT switches to Responder role, thus changing
also to controlled role. also to controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks. in the connectivity checks.
skipping to change at page 58, line 33 skipping to change at page 59, line 41
o As the "ICE lite" is not adopted here and both sides are capable o As the "ICE lite" is not adopted here and both sides are capable
of ICE-HIP-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 o If the agent is using Diffserv Codepoint markings [RFC2475] in its
media packets, it SHOULD apply those same markings to its media packets, it SHOULD apply those same markings to its
connectivity checks. connectivity checks.
o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
protocol in order to avoid middlebox tampering. protocol but rather encrypted to avoid middlebox tampering.
o Native ICE-HIP protocol does not employ the ICE related address o Native ICE-HIP protocol does not employ the ICE related address
and related port attributes (that are used for diagnostic or SIP and related port attributes (that are used for diagnostic or SIP
purposes). purposes).
Appendix C. Differences to Base Exchange and UPDATE procedures Appendix C. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers how the
extensions in this protocol extend and differ from [RFC7401] and extensions in this protocol extend and differ from [RFC7401] and
[RFC8046]. [RFC8046].
skipping to change at page 60, line 42 skipping to change at page 61, line 50
Handling of this state attribute requires some additional logic Handling of this state attribute requires some additional logic
when compared to the mobility extensions since the state is when compared to the mobility extensions since the state is
associated with a local-remote address pair rather just a remote associated with a local-remote address pair rather just a remote
address, and, 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 o Credit-based authorization as defined in [RFC8046] could be used
before candidate nomination has been concluded upon discovering before candidate nomination has been concluded upon discovering
working candidate pairs. However, this may result in the use of working candidate pairs. However, this may result in the use of
asymmetric paths for a short time period in the beginning of asymmetric paths for a short time period in the beginning of
communications (similarly as in aggressive ICE nomination). Thus, communications. Thus, support of credit-based authorization is
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 [RFC8047] like functionality are left for
further study and experimentation, we envision here some potential further study and experimentation, we envision here some potential
compatibility improvements to support multihoming: compatibility improvements to support multihoming:
 End of changes. 126 change blocks. 
383 lines changed or deleted 487 lines changed or added

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