draft-ietf-hip-native-nat-traversal-22.txt   draft-ietf-hip-native-nat-traversal-23.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: April 26, 2018 Ericsson Expires: May 16, 2018 Ericsson
October 23, 2017 November 12, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-22 draft-ietf-hip-native-nat-traversal-23
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2018. This Internet-Draft will expire on May 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 9
4.2. Transport Address Candidate Gathering at the Relay Client 12 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 . . . . . . . . . . 16 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17
4.5. Base Exchange via Control Relay Server . . . . . . . . . 16 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 20 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 23 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 25 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26
4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 26 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 26 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27
4.7.2. Base Exchange without Connectivity Checks . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . 28 Encapsulation . . . . . . . . . . . . . . . . . . . . 29
4.8. Sending Control Packets after the Base Exchange . . . . . 28 4.8. Sending Control Packets after the Base Exchange . . . . . 29
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 29 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 32 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 32 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 34
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 32 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 32 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 33 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 34 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 35 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 35 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 36 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 39
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 39
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 36 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 39
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 37 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 40
5.6. Relay and Registration Parameters . . . . . . . . . . . . 38 5.6. Relay and Registration Parameters . . . . . . . . . . . . 41
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 39 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 42
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 41 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 44
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 41 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 44
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 41 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 44
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 42 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 45
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 42 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 45
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 43 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 46
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 44 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 47
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 45 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 48
6. Security Considerations . . . . . . . . . . . . . . . . . . . 45 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 45 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 48
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 46 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 49
6.3. Base Exchange Replay Protection for Control Relay Server 46 6.3. Base Exchange Replay Protection for Control Relay Server 49
6.4. Demultiplexing Different HIP Associations . . . . . . . . 47 6.4. Demultiplexing Different HIP Associations . . . . . . . . 50
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 47 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 50
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 47 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 50
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 47 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . 49 10.1. Normative References . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 50 10.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 51 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 54
Appendix B. Differences with respect to ICE . . . . . . . . . . 52 Appendix B. Differences with respect to ICE . . . . . . . . . . 55
Appendix C. Differences to Base Exchange and UPDATE procedures . 53 Appendix C. Differences to Base Exchange and UPDATE procedures . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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
skipping to change at page 12, line 42 skipping to change at page 12, line 42
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 both renewals of service registration but also to host
movement, where especially the latter requires the Control Relay movement, where especially the latter requires the Control Relay
Client to learn its new server reflexive address candidate. Client to learn its new server reflexive address candidate.
A Data Relay Client can request multiple relayed candidates from the
a Data Relay Server (e.g., for the reasons described in
Section 4.12.3). After the base exchange with registration, the Data
Relay Client can request additional relayed candidates similarly as
during the base exchange. The Data Relay Client sends an UPDATE
message REG_REQ parameter requesting for the RELAY_UDP_ESP service.
The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGN
parameter. The Data Relay Server MUST respond with an UPDATE message
that includes the corresponding response parameters: REG_RES, ACK and
ECHO_REQUEST_SIGN. In case the Data Relay Server admitted a new
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
include a RELAYED_ADDRESS parameter describing the relayed UDP port.
The Data Relay Server MUST also include the Server Reflexive
candidate in a REG_FROM parameter. It is worth mentioning that Data
Relay Client MUST activate the UDP port as described in
Section 4.12.1 before it can be used for any ESP relaying.
A Data Relay Client may unregister a relayed candidate in two ways.
It can wait for its lifetime to expire or it can explicitly request
it with zero lifetime using the UPDATE mechanism. The Data Relay
Client can send an REG_REQ parameter with zero lifetime to the Data
Relay Server in order to expire all relayed candidates. To expire a
specific relayed candidate, the Data Relay Client MUST also include
RELAYED_ADDRESS parameter as sent by the server in the UPDATE
message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure
initiated by either party), the Data Relay Server MUST also expire
all relayed candidates.
4.2. Transport Address Candidate Gathering at the Relay Client 4.2. Transport Address Candidate Gathering at the Relay Client
An Initiator needs to gather a set of address candidates before An Initiator needs to gather a set of address candidates before
contacting a (non-relay) Responder. The candidates are needed for contacting a (non-relay) Responder. The candidates are needed for
connectivity checks that allow two hosts to discover a direct, non- connectivity checks that allow two hosts to discover a direct, non-
relayed path for communicating with each other. One server reflexive relayed path for communicating with each other. One server reflexive
candidate can be discovered during the registration with the Control candidate can be discovered during the registration with the Control
Relay Server from the REG_FROM parameter (and another from Data Relay Relay Server from the REG_FROM parameter (and another from Data Relay
Server if one is employed). Server if one is employed).
skipping to change at page 13, line 17 skipping to change at page 13, line 45
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
be used with multiple other peers. However, it is RECOMMENDED that a
Data Relay Client registers a new server reflexive candidate for each
its peer for the reasons described in Section 4.12.3. The procedures
for registering multiple relayed candidates are described 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_SIGN CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGN
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
skipping to change at page 20, line 12 skipping to change at page 20, line 49
in the ICE specification, the basic procedure for connectivity checks in the ICE specification, the basic procedure for connectivity checks
has three phases: sorting the candidate pairs according their has three phases: sorting the candidate pairs according their
priority, sending checks in the prioritized order and acknowledging priority, sending checks in the prioritized order and acknowledging
the checks from the peer host. 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 in 6.7 in [RFC7401]:
host with the "larger" HIT changes to its Role to Responder. In such the host with the "larger" HIT changes to its Role to Responder. In
a case, the host changing its role to Responder MUST also switch to such a case, the host changing its role to Responder MUST also switch
controlling role. to controlling role.
The protocol follows standard HIP UPDATE sending and processing rules The protocol follows standard HIP UPDATE sending and processing rules
as defined in section 6.11 and 6.12 in [RFC7401], but some new as defined in section 6.11 and 6.12 in [RFC7401], but some new
parameters are introduced (CANDIDATE_PRIORITY, MAPPED_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 24, line 9 skipping to change at page 25, line 9
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 generate a response, and then continue waiting for the candidates. A
host MUST NOT select a candidate pair until it has verified the pair host MUST NOT select a candidate pair until it has verified the pair
using a connectivity check as defined in section Section 4.6.1. using a connectivity check as defined in Section 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.
skipping to change at page 26, line 39 skipping to change at page 27, line 39
mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION
mode does not have to be negotiated. In such a scenario, the mode does not have to be negotiated. In such a scenario, the
Initiator sends an I1 message over UDP and the Responder responds Initiator sends an I1 message over UDP and the Responder responds
with an R1 message over UDP without including any NAT traversal mode with an R1 message over UDP without including any NAT traversal mode
parameter. The rest of the base exchange follows the procedures parameter. The rest of the base exchange follows the procedures
defined in [RFC7401], except that the control and data plane use UDP defined in [RFC7401], except that the control and data plane use UDP
encapsulation. Here, the use of UDP for NAT traversal is agreed encapsulation. Here, the use of UDP for NAT traversal is agreed
implicitly. This way of operation is still subject to NAT timeouts, implicitly. This way of operation is still subject to NAT timeouts,
and the hosts MUST employ NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
When UDP-ENCAPSULATION mode is chosen either explicitly or
implicitly, the connectivity checks as defined in this document MUST
not be used. When hosts lose connectivity, they MUST instead utilize
[RFC8046] or [RFC8047] procedures, but with difference that UDP-based
tunneling MUST employed for the entire lifetime of the corresponding
Host Association.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is
applicable also in the context of this specification, so it is applicable also in the context of this specification, so it is
repeated here for completeness. repeated here for completeness.
In certain network environments, the connectivity checks can be In certain network environments, the connectivity checks can be
omitted to reduce initial connection set-up latency because a base omitted to reduce initial connection 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
skipping to change at page 29, line 50 skipping to change at page 30, line 50
Server. 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 UPDATE messages to its Control and Data mobile host SHOULD first send its locators in UPDATE messages to its
Relay Servers if it has registered to such. It SHOULD wait for all Control and Data Relay Servers if it has registered to such. It
of them to respond for two minutes and then continue with the SHOULD wait for all of them to respond for two minutes and then
handover procedure without information from the Relay Server that did continue with the handover procedure without information from the
not respond. As defined in section Section 4.1, a response message Relay Server that did not respond. As defined in Section 4.1, a
from a Control Relay Server includes a REG_FROM parameter that response message from a Control Relay Server includes a REG_FROM
describes the server reflexive candidate of the mobile host to be parameter that describes the server reflexive candidate of the mobile
used in the candidate exchange during the handover. Similarly, an host to be used in the candidate exchange during the handover.
UPDATE to a Data Relay Server is necessary to make sure the Data Similarly, an UPDATE to a Data Relay Server is necessary to make sure
Relay Server can forward data to the correct IP address after a the Data Relay Server can forward data to the correct IP address
handoff. after a handoff.
The mobility extensions for NAT traversal are illustrated in The mobility extensions for NAT traversal are illustrated in
Figure 6. The mobile host is the host that has changed its locators, Figure 6. The mobile host is the host that has changed its locators,
and the peer host is the host it has a host association with. The and the peer host is the host it has a host association with. The
mobile host may have multiple peers and it repeats the process with mobile host may have multiple peers and it repeats the process with
all of its peers. In the figure, the 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. Next, we describe the procedure in the figure Control Relay Server. worth noting that the figure corresponds to
in detail. figure 3 in [RFC8046], but the difference is that the main UPDATE
procedure is carried over the relay and the connectivity is tested
separately. 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)) | | | LOC_SET, SEQ)) | |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, |
| | LOC_SET, SEQ, | | | LOC_SET, SEQ, |
| | RELAY_FROM)) | | | RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(UPDATE(ESP_INFO, ACK, | | | 3. UDP(UPDATE(ESP_INFO, SEQ, |
| | ECHO_REQ_SIGN)) | | | ACK, ECHO_REQ_SIGN, |
| 4. UDP(UPDATE(ESP_INFO, ACK, |<-------------------------------+ | | RELAY_TO)) |
| ECHO_REQ_SIGN, | | | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+
| ACK, ECHO_REQ_SIGN, | |
| RELAY_TO)) | | | RELAY_TO)) | |
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
| 5. connectivity checks over UDP | | 5. UDP(UPDATE(ACK, | |
| ECHO_RESP_SIGNED)) | |
+--------------------------------->| 6. UDP(UPDATE(ACK, |
| | ECHO_RESP_SIGNED, |
| | RELAY_FROM)) |
| +------------------------------->|
| | |
| 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 6. ESP data over UDP | | 8. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
Figure 6: HIP UPDATE procedure Figure 6: HIP UPDATE procedure
In step 1, the mobile host has changed location and sends a location In step 1, the mobile host has changed location and sends a location
update to its peer through the Control Relay Server of the peer. It update to its peer through the Control Relay Server of the peer. It
sends an UPDATE packet with source HIT belonging to itself and sends an UPDATE packet with 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
skipping to change at page 31, line 24 skipping to change at page 33, line 14
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
OLD SPI and NEW SPI parameters both contain the pre-existing incoming OLD SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters
to be acknowledged by the mobile host. The message acknowledges the to be acknowledged by the mobile host. The message acknowledges the
SEQ parameter of the earlier message with an ACK parameter. After SEQ parameter of the earlier message with an ACK parameter. The
this step, the peer host can initiate the connectivity checks. RELAY_TO parameter specifies the address of the mobile host where the
Control Relay Server should forward the message.
In step 4, the Control Relay Server receives the message, rewrites In step 4, the Control Relay Server receives the message, rewrites
the destination IP address, appends an RELAY_TO parameter and the destination IP address and UDP port according to the RELAY_TO
forwards the modified message to the mobile host. When mobile host parameter, and then forwards the modified message to the mobile host.
has processed the message successfully, it can initiate the
connectivity checks.
In step 5, the two hosts test for connectivity across NATs according In step 5, the mobile host receives the UPDATE packet and processes
it. The mobile host concludes the handover procedure by
acknowledging the received SEQ parameter with an ACK parameter and
the ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED parameter.
The mobile host delivers the packet to the HIT of the peer and to the
address of the HIP relay. The mobile host can start connectivity
checks after this packet.
In step 6, HIP relay receives the UPDATE packet and forwards it to
the peer host (i.e. relay client). The HIP relay rewrites the
destination IP address and port, and then appends a RELAY_FROM
parameter to the message. When the peer host receives this
concluding UPDATE packet, it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according
to procedures described in Section 4.6. The original Initiator of to procedures described in Section 4.6. The original Initiator of
the communications is the controlling and the original Responder is the communications is the controlling and the original Responder is
the controlled host. the controlled host.
In step 6, the connectivity checks are successfully completed and the In step 8, the connectivity checks are successfully completed and the
controlling host has nominated one address pair to be used. The controlling host has nominated one address pair to be used. The
hosts set up security associations to deliver the application hosts set up security associations to deliver the application
payload. payload.
If either host has registered a relayed address candidate from a Data It is worth noting that the Control and Data Relay Client do not have
Relay Server, the host MUST reactivate the address before to re-register for the related services after a handoff. However, if
connectivity checks by sending an UPDATE message containing a Data Relay Client has registered a relayed address candidate from a
PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise, Data Relay Server, the Data Relay Client MUST reactivate the address
the Data Relay Server drops ESP packets using the relayed address. before the connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1.
Otherwise, the Data Relay Server drops ESP packets sent to the
relayed address.
In so called "double jump" or simultaneous mobility scenario both
peers change their location simultaneously. In such a case, both
peers trigger the procedure described earlier in this section at the
same time. In other words, both of the communicating hosts send an
UPDATE packet carrying locators at the same time or with some delay.
When the locators are exchanged almost simultaneously (reliably via
Control Relay Servers), the two hosts can continue with connectivity
checks after both have completed separately the steps in Figure 6.
The problematic case occurs when the one of the hosts (referred here
as host "M") moves later during the connectivity checks. In such a
case, host M sends a locator to the peer which is in the middle of
connectivity checks. Upon receiving the UPDATE message, the peer
responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in
Figure 6. Upon receiving the valid response from host M as described
in step 6, the peer host MUST restart the connectivity checks with
host M. This way, both hosts start the connectivity checks roughly
in a synchronized way. It is also important that peer host does not
restart the connectivity checks until it has received a valid "fresh"
confirmation from host M because the UPDATE message carrying locators
could be replayed by an attacker.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts MUST send
periodic keepalives to other hosts with which they have established a periodic keepalives to other hosts with which they have established a
host associating. Both a registered client and Control/Data Relay Host Association every 15 seconds (the so called Tr value in ICE).
Server SHOULD send HIP NOTIFY packets to each other every 15 seconds Other values MAY be used, but a Tr value smaller than 15 seconds MUST
(the so called Tr value in ICE) unless they have exchange some other NOT be used. Both a Control/Data Relay Client and Control/Data Relay
traffic over the used UDP ports. Other values MAY be used, but a Tr Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-
value smaller than 15 seconds MUST NOT be used. The keepalive UDP mode, SHOULD send HIP NOTIFY packets unless they have exchange
some other traffic over the used UDP ports. However, the Data Relay
Client and Data Relay Server MUST employ only HIP NOTIFY packets in
order to keep the server reflexive candidates alive. The keepalive
message encoding format is defined in Section 5.3. If the base message encoding format is defined in Section 5.3. If the base
exchange or mobility handover procedure occurs during an extremely exchange or mobility handover procedure occurs during an extremely
slow path, a host MAY also send HIP NOTIFY packet every 15 seconds to slow path, a host (with a Host Association with the peer) MAY also
keep the path active with the recipient. send HIP NOTIFY packets every 15 seconds to keep the path active with
the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP association and the related The two-way procedure for closing a HIP association and the related
security associations is defined in [RFC7401]. One host initiates security associations is defined in [RFC7401]. One host initiates
the procedure by sending a CLOSE message and the recipient confirms the procedure by sending a CLOSE message and the recipient confirms
it with CLOSE_ACK. All packets are protected using HMACs and it with CLOSE_ACK. All packets are protected using HMACs and
signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED
parameter to protect against replay attacks. parameter to protect against replay attacks.
skipping to change at page 33, line 6 skipping to change at page 35, line 34
client MUST set a permission for the peer's address. The permissions client MUST set a permission for the peer's address. The permissions
also install a forwarding rule for each direction, similar to TURN's also install a forwarding rule for each direction, similar to TURN's
channels, based on the Security Parameter Index (SPI) values in the channels, based on the Security Parameter Index (SPI) values in the
ESP packets. ESP packets.
Permissions are not required for HIP control packets. However, if a Permissions are not required for HIP control packets. However, if a
relayed address (as conveyed in the RELAYED_ADDRESS parameter from relayed address (as conveyed in the RELAYED_ADDRESS parameter from
the Data Relay Server) is selected to be used for data, the Control the Data Relay Server) is selected to be used for data, the Control
Relay Client MUST send an UPDATE message to the Data Relay Server Relay Client MUST send an UPDATE message to the Data Relay Server
containing a PEER_PERMISSION parameter (see Section 5.13) with the containing a PEER_PERMISSION parameter (see Section 5.13) with the
address of the peer, and the outbound and inbound SPI values the following information: the UDP port and address for the server
Control Relay Client is using with this particular peer. To avoid reflexive address, the UDP port and address of the peer, and the
packet dropping of ESP packets, the Control Relay Client SHOULD send inbound and outbound SPIs used for ESP. The packet MUST be sent to
the PEER_PERMISSION parameter before connectivity checks both in the the same UDP tunnel the Client employed in the base exchange to
case of base exchange and a mobility handover. It is worth noting contact the Server (i.e., not to the port occupied by the server
that the UPDATE message includes a SEQ parameter (as specified in reflexive candidate). To avoid packet dropping of ESP packets, the
[RFC7401]) that the Data Relay Server must acknowledge, so that the Control Relay Client SHOULD send the PEER_PERMISSION parameter before
Control Relay Client can resend the message with PEER_PERMISSION connectivity checks both in the case of base exchange and a mobility
parameter if it gets lost. handover. It is worth noting that the UPDATE message includes a SEQ
parameter (as specified in [RFC7401]) that the Data Relay Server must
acknowledge, so that the Control Relay Client can resend the message
with PEER_PERMISSION parameter if it gets lost.
When a Data Relay Server receives an UPDATE with a PEER_PERMISSION When a Data Relay Server receives an UPDATE with a PEER_PERMISSION
parameter, it MUST check if the sender of the UPDATE is registered parameter, it MUST check if the sender of the UPDATE is registered
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the Data Relay Server checks registered. If the host was registered, the Data Relay Server checks
if there is a permission with matching information (address, if there is a permission with matching information (protocol,
protocol, port and SPI values). If there is no such permission, a addresses, ports and SPI values). If there is no such permission, a
new permission MUST be created and its lifetime MUST be set to 5 new permission MUST be created and its lifetime MUST be set to 5
minutes. If an identical permission already existed, it MUST be minutes. If an identical permission already existed, it MUST be
refreshed by setting the lifetime to 5 minutes. A Data Relay Client refreshed by setting the lifetime to 5 minutes. A Data Relay Client
SHOULD refresh permissions 1 minute before the expiration when the SHOULD refresh permissions 1 minute before the expiration when the
permission is still needed. permission is still needed.
When a Data Relay Server receives an UPDATE from a registered client When a Data Relay Server receives an UPDATE from a registered client
but without a PEER_PERMISSION parameter and with a new locator set, but without a PEER_PERMISSION parameter and with a new locator set,
the Data Relay Server can assume that the mobile host has changed its the Data Relay Server can assume that the mobile host has changed its
location and, thus, is not reachable in its previous location. In location and, thus, is not reachable in its previous location. In
skipping to change at page 34, line 25 skipping to change at page 37, line 9
permission set for the peer the packet is arriving from (i.e., the permission set for the peer the packet is arriving from (i.e., the
sender's address and SPI value matches to an installed permission). sender's address and SPI value matches to an installed permission).
If permissions are set, the Data Relay Server MUST forward the packet If permissions are set, the Data Relay Server MUST forward the packet
to the Data Relay Client that created the permission. The Data Relay to the Data Relay Client that created the permission. The Data Relay
Server MUST also implement the similar checks for the reverse Server MUST also implement the similar checks for the reverse
direction (i.e. ESP packets from the Data Relay Client to the peer). direction (i.e. ESP packets from the Data Relay Client to the peer).
Packets without a permission MUST be dropped silently. Packets without a permission MUST be dropped silently.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
Since a Data Relay Server may have to deal with multiple Relay From the viewpoint of a host, its remote peers can have overlapping
Clients and their peers, such a Relay may experience collisions in inbound SPI numbers because the IPsec uses also the destination IP
the SPI namespace. Two problematic cases are described in this address to index the remote peer host. However, a Data Relay Server
section. can represent multiple remote peers, thus masquarading the actual
destination. Since a Data Relay Server may have to deal with a
In the first scenario, an SPI collision may occur when two Initiators multitude of Relay Clients and their peers, a Data Relay Server may
run a base exchange to the same Responder (i.e. Data Relay Client), experience collisions in the SPI namespace, thus being unable forward
and both the Initiators claim the same inbound SPI at the Data Relay datagrams to the correct destination. Since the SPI space is 32 bits
Server using PEER_PERMISSION Parameter. In this case, the Data Relay and the SPI values should be random, the probability for a
Server cannot disambiguate the correct destination of an ESP packet conflicting SPI value is fairly small, but could occur on a busy
originating from the Data Relay Client because the SPI could belong server acting as a Responder. The two problematic cases are
to either of the peers (and destination IP and UDP port belonging to described in this section.
the Data Relay Server are not unique either). The problem can be
mitigated at the Data Relay Clients (i.e. Responder). Upon
receiving an I2 with a colliding SPI, the Responder MUST NOT include
the relayed address candidate in the R2 message because the Data
Relay Server would not be able demultiplex the related ESP packet to
the correct Initiator. The same applies also the handover
procedures; the Data Relay Client MUST NOT include the relayed
address candidate when sending its new locator set in an UPDATE to
its peer if it would cause a SPI conflict with another peer. Since
the SPI space is 32 bits and the SPI values should be random, the
probability for a conflicting SPI value is fairly small. However, a
Data Relay Client with many peers MAY proactively decrease the odds
of a conflict by registering to multiple Data Relay Servers. Thus,
the described collision scenario can be avoided if the Responder
delivers a new relayed address candidate upon SPI collisions. Each
relayed address has a separate UDP port reserved to it, so collision
problem does not occur.
In the second scenario, the SPI collision problems occurs if two In the first scenario, the SPI collision problems occurs if two hosts
hosts have registered to the same Data Relay Server and a third host have registered to the same Data Relay Server and a third host
initiates base exchange with both of them. Here, the two Responders initiates base exchange with both of them. Here, the two Responders
(i.e. Data Relay Clients) claim the same inbound SPI number with the (i.e. Data Relay Clients) claim the same inbound SPI number with the
same Initiator (peer). However, in this case, the Data Relay Server same Initiator (peer). However, in this case, the Data Relay Server
has allocated separate UDP ports for the two Data Relay Clients has allocated separate UDP ports for the two Data Relay Clients
acting now as Responders (as recommended in Section 6.5). When the acting now as Responders (as recommended in Section 6.5). When the
peer sends an ESP packet, the Data Relay Server is able to forward third host sends an ESP packet, the Data Relay Server is able to
the packet to the correct Data Relay Client because the destination forward the packet to the correct Data Relay Client because the
UDP port for each of the clients. destination UDP port is different for each of the clients.
In the second scenario, an SPI collision may occur when two
Initiators run a base exchange to the same Responder (i.e. Data
Relay Client), and both of the Initiators claim the same inbound SPI
at the Data Relay Server using PEER_PERMISSION Parameter. In this
case, the Data Relay Server cannot disambiguate the correct
destination of an ESP packet originating from the Data Relay Client
because the SPI could belong to either of the peers (and destination
IP and UDP port belonging to the Data Relay Server are not unique
either). The recommended way and a contingency plan to solve this
issue are described below.
The recommend way to mitigate the problem is as follows. For each
new Host Association, A Data Relay Client acting as a Responder
SHOULD register a new server reflexive candidate as described in
Section 4.2. Similarly, the Data Relay Server SHOULD NOT re-use the
port numbers as described in Section 6.5. This way, each server
reflexive candidate for the Data Relay Client has a separate UDP port
that the Data Relay Server can use to disambiguate packet
destinations in case of SPI collisions.
When the Data Relay Client is not registering or failed to register a
new relay candidate for a new peer, the Data Relay Client MUST follow
a contingency plan as follows. Upon receiving an I2 with a colliding
SPI, the Data Relay client acting as the Responder MUST NOT include
the relayed address candidate in the R2 message because the Data
Relay Server would not be able demultiplex the related ESP packet to
the correct Initiator. The same applies also the handover
procedures; the Data Relay Client MUST NOT include the relayed
address candidate when sending its new locator set in an UPDATE to
its peer if it would cause a SPI conflict with another peer.
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP and ESP packets. All values MUST be in network byte for the HIP and ESP packets. All values MUST be in network byte
order. order.
It is worth noting that most of the parameters are shown for the sake It is worth noting that most of the parameters are shown for the sake
of completeness even though they are specified already in Legacy ICE- of completeness even though they are specified already in Legacy ICE-
HIP [RFC5770]. New parameters are explicitly described as new. HIP [RFC5770]. New parameters are explicitly described as new.
skipping to change at page 36, line 31 skipping to change at page 39, line 28
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 MAY be omitted if the host is actively (or passively) sending
other traffic to the peer host over the UDP tunnel associate with the some other traffic (HIP or ESP) to the peer host over the related UDP
host association (and IPsec security associations since the same port tunnel during the Tr period. For instance, the host MAY actively
pair is reused) 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 associations. Alternatively, the host MAY use UPDATE substitute. A minimal UPDATE packet would consist of a SEQ and
packets as a substitute. A minimal UPDATE packet would consist of a ECHO_REQ_SIGN parameters, and a more complex would involve rekeying
SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve procedures as specified in section 6.8 in [RFC7402]. It is worth
rekeying procedures as specified in section 6.8 in [RFC7402]. It is noting that a host actively sending periodic UPDATE packets to a busy
worth noting that a host actively sending periodic UPDATE packets to server may increase the computational load of the server since it has
a busy server may increase the computational load of the server since to verify HMACs and signatures in UPDATE messages.
it has 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
similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and
is shown in Figure 8. The Native ICE-HIP extension specified in this is shown in Figure 8. The Native ICE-HIP extension specified in this
document defines the new NAT traversal mode identifier for ICE-HIP- document defines the new NAT traversal mode identifier for ICE-HIP-
UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP UDP and reuses the UDP-ENCAPSULATION mode from Legacy ICE-HIP
[RFC5770]. The identifier named RESERVED is reserved for future use. [RFC5770]. The identifier named RESERVED is reserved for future use.
Future specifications may define more traversal modes. Future specifications may define more traversal modes.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 | | Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 20 skipping to change at page 44, line 20
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]. Legacy ICE-HIP [RFC5770].
5.10. Notify Packet Types 5.10. Notify Packet Types
A Control Relay Server and end-hosts can use NOTIFY packets to signal A Control/Data Relay Server and end-hosts can use NOTIFY packets to
different error conditions. The NOTIFY packet types are the same as signal different error conditions. The NOTIFY packet types are the
in Legacy ICE-HIP [RFC5770]. same as in Legacy ICE-HIP [RFC5770].
The Notify Packet Types [RFC7401] are shown below. The Notification The Notify Packet Types [RFC7401] are shown below. The Notification
Data field for the error notifications SHOULD contain the HIP header Data field for the error notifications SHOULD contain the HIP header
of the rejected packet and SHOULD be empty for the of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
If a Control Relay Server does not forward a base exchange packet If a Control Relay Server does not forward a base exchange packet
due to missing NAT traversal mode parameter, or the Initiator due to missing NAT traversal mode parameter, or the Initiator
selects a NAT traversal mode that the (non-relay) Responder did selects a NAT traversal mode that the (non-relay) Responder did
not expect, the Control Relay Server or the Responder may send not expect, the Control Relay Server or the Responder may send
back a NOTIFY error packet with this type. back a NOTIFY error packet with this type.
CONNECTIVITY_CHECKS_FAILED 61 CONNECTIVITY_CHECKS_FAILED 61
Used by the end-hosts to signal that NAT traversal connectivity Used by the end-hosts to signal that NAT traversal connectivity
checks failed and did not produce a working path. checks failed and did not produce a working path.
MESSAGE_NOT_RELAYED 62 MESSAGE_NOT_RELAYED 62
Used by a Control Relay Server to signal that is was not able or Used by a Control Relay Server to signal that is was not able or
willing to relay a HIP packet. willing to relay a HIP packet.
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63
Used by a Data Relay Server to signal that is was not able or
willing to allocate a new server reflexive candidate for the Data
Relay Client
5.11. ESP Data Packets 5.11. ESP Data Packets
The format for ESP data packets is identical to Legacy ICE-HIP The format for ESP data packets is identical to Legacy ICE-HIP
[RFC5770]. [RFC5770].
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport [RFC3948] describes the UDP encapsulation of the IPsec ESP transport
and tunnel mode. On the wire, the HIP ESP packets do not differ from and tunnel mode. On the wire, the HIP ESP packets do not differ from
the transport mode ESP, and thus the encapsulation of the HIP ESP the transport mode ESP, and thus the encapsulation of the HIP ESP
packets is same as the UDP encapsulation transport mode ESP. packets is same as the UDP encapsulation transport mode ESP.
However, the (semantic) difference to Bound End-to-End Tunnel (BEET) However, the (semantic) difference to Bound End-to-End Tunnel (BEET)
skipping to change at page 44, line 10 skipping to change at page 47, line 10
forwarding rules and the permissions for data packets at the Data forwarding rules and the permissions for data packets at the Data
Relay Server. The parameter contains one or more sets of Port, Relay Server. The parameter contains one or more sets of Port,
Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI)
values. One set defines a rule for one peer address. values. One set defines a rule for one peer address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved | | RPort | PPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | RAddress |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PAddress |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPI | | OSPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4680] Type [TBD by IANA; 4680]
Length length in octets, excluding Type and Length Length length in octets, excluding Type and Length
Port the transport layer (UDP) port number of the peer RPort the transport layer (UDP) port at the Data Relay Server
(i.e. the port of the server reflexive candidate)
PPort the transport layer (UDP) port number of the peer
Protocol IANA assigned, Internet Protocol number (17 for UDP) Protocol IANA assigned, Internet Protocol number (17 for UDP)
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address, or an IPv4 address in "IPv4-Mapped RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the server reflexive candidate
PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped
IPv6 address" format, of the peer IPv6 address" format, of the peer
OSPI the outbound SPI value the Data Relay Client is using for OSPI the outbound SPI value the Data Relay Client is using for
the peer with the Address and Port the peer
ISPI the inbound SPI value the Data Relay Client is using for ISPI the inbound SPI value the Data Relay Client is using for
the peer with the Address and Port the peer
Figure 13: Format of the PEER_PERMISSION Parameter Figure 13: Format of the PEER_PERMISSION Parameter
5.14. HIP Connectivity Check Packets 5.14. HIP Connectivity Check Packets
The connectivity request messages are HIP UPDATE packets containing a The connectivity request messages are HIP UPDATE packets containing a
new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE
packets contain a MAPPED_ADDRESS parameter (Figure 12). packets contain a MAPPED_ADDRESS parameter (Figure 12).
0 1 2 3 0 1 2 3
skipping to change at page 46, line 27 skipping to change at page 49, line 27
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 same mechanism also protects the Responder against
Denial-of-Service (DoS) attacks by allowing the Responder to initiate Denial-of-Service (DoS) attacks by allowing the Responder to initiate
new connections even if its relays would be unavailable due to a DoS new connections even if its relays would be unavailable due to a DoS
attack. attack.
6.2. Opportunistic Mode 6.2. Opportunistic Mode
A Control Relay Server should have one address per Control Relay In opportunistic HIP mode, an Initiator sends an I1 with without
Client when the Control Relay Server is serving more than one Control setting the destination HIT of the Responder (i.e. the Control Relay
Relay Client and supports opportunistic mode. Otherwise, it cannot Client). A Control Relay Server SHOULD have a unique IP address per
be guaranteed that the Control Relay Server can deliver the I1 packet Control Relay Client when the Control Relay Server is serving more
to the intended recipient. than one Control Relay Client and supports opportunistic mode.
Otherwise, the Control Relay Server cannot guarantee to deliver the
I1 packet to the intended recipient. Future extensions of this
document may allow opportunistic mode to be used with non-unique IP
addresses to be utilized either as a HIP-level anycast or multicast
mechanism. Both of the mentioned cases would require a separate
registration parameters that the Control 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 legimitate Responder has to be disconnected from the Control the legimitate Responder has to be disconnected from the Control
Relay Server. Relay Server.
skipping to change at page 47, line 39 skipping to change at page 50, line 43
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 for its peer
that are used for targeting a victim host by flooding it with that are used for targeting a victim host by flooding it with
connectivity checks. To mitigate the attack, this protocol adopts connectivity checks. To mitigate the attack, this protocol adopts
the ICE mechanism to cap the total amount of connectivity checks as the ICE mechanism to cap the total amount of connectivity checks as
defined in section Section 4.7. defined in Section 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 [I-D.ietf-ice-rfc5245bis] 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
skipping to change at page 48, line 41 skipping to change at page 51, line 45
traversal mode ICE-HIP-UDP (defined in Section 5.4) This traversal mode ICE-HIP-UDP (defined in Section 5.4) This
specification introduces a new keepalive Notify message type field specification introduces a new keepalive Notify message type field
NAT_KEEPALIVE. NAT_KEEPALIVE.
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 4.1, and performing server reflexive candidate discovery: Section 4.1, and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2).
This document specifies three new error values to be used in HIP
NOTIFY messages as described in Section 5.10:
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED,
MESSAGE_NOT_RELAYED and SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED.
ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral
Self-Address Fixing" . This protocol is based on ICE, and thus the Self-Address Fixing" . This protocol is based on ICE, and thus the
same considerations apply also here with one exception: this protocol same considerations apply also here with one exception: this protocol
does not hide binary IP addresses from application-level gateways. 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.
skipping to change at page 52, line 25 skipping to change at page 55, line 36
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 ECHO_REQUEST_SIGN replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN
parameter and the STUN binding response with a HIP UPDATE message parameter and the STUN binding response with a HIP UPDATE message
containing an ECHO_RESPONSE_SIGNED parameter as defined in section containing an ECHO_RESPONSE_SIGNED parameter as defined in
Section 4.6. Section 4.6.
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
skipping to change at page 56, line 5 skipping to change at page 59, line 12
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 (similarly as in aggressive ICE nomination). Thus,
support of credit-based authorization is left for further study. support of credit-based authorization is left for further study.
Appendix D. Multihoming Considerations
This document allows a host to collect address candidates from
multiple interfaces, but does not support activation and the
simultaneous use of multiple address candidates. While multihoming
extensions to support [RFC8047] like functionality are left for
further study and experimentation, we envision here some potential
compatibility improvements to support multihoming:
o Data Relay Registration: a Data Relay Client acting as an
Initiator with another peer host should register a new server
reflexive candidate for each local transport address candidate. A
Data Relay Client acting as an Responder should register a new
server reflexive candidate for each { local transport address
candidate, new peer host} pair for the reasons described in
Section 4.12.3. In both cases, the Data Relay Client should
request the additional server reflexive candidates by sending
UPDATE messages originating from each of the local address
candidates as described in Section 4.1. As the UPDATE messages
are originating from an unknown location from the viewpoint of the
Data Relay Server, it must include also a ECHO_REQUEST_SIGN in the
response in order to test for return routability.
o Data Relay unregistration: this follows the procedure in Section 4
but the Data Relay Client should unregister using the particular
transport address to be unregistered. All transport address pair
registrations can be unregistered when no RELAYED_ADDRESS
parameter is included.
o PEER_PERMISSION parameter: this needs to be extended or additional
parameter is needed to declare the specific local candidate of the
Data Relay Client. Alternatively, the use of the PEER_PERMISSION
could be used as a wild card to open permissions for a specific
peer to all of the candidates of the Data Relay Client.
o Connectivity checks: the controlling host should be able to
nominate multiple candidates (by repeating step 7 in Figure 5 in
Section 4.6 using the additional candidate pairs).
o Keepalives should be sent for all the nominated candidate pairs.
Similarly, the Control/Data Relay Client should send keepalives
from its local candidates to its Control/Data Relay Server
transport addresses.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 50 change blocks. 
185 lines changed or deleted 364 lines changed or added

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