draft-ietf-hip-native-nat-traversal-31.txt   draft-ietf-hip-native-nat-traversal-32.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: Experimental M. Komu, Ed.
Expires: October 25, 2020 Ericsson Expires: January 28, 2021 Ericsson
April 23, 2020 July 27, 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-31 draft-ietf-hip-native-nat-traversal-32
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages instead of ICE for all NAT traversal procedures due to the messages instead of ICE for all NAT traversal procedures due to the
kernel-space dependencies of HIP. kernel-space dependencies of HIP.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2020. This Internet-Draft will expire on January 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . 8 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50
6.3. Base Exchange Replay Protection for Control Relay Server 50 6.3. Base Exchange Replay Protection for Control Relay Server 50
6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51
6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 6.8. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2. Informative References . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 57 10.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix B. Differences with respect to ICE . . . . . . . . . . 58 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 59
Appendix C. Differences to Base Exchange and UPDATE procedures . 60 Appendix B. Differences with respect to ICE . . . . . . . . . . 59
Appendix D. Multihoming Considerations . . . . . . . . . . . . . 62 Appendix C. Differences to Base Exchange and UPDATE procedures . 62
Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 63 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in directly on top of IPv4 or IPv6. However, many middleboxes found in
the Internet, such as NATs and firewalls, often allow only UDP or TCP the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, NATs usually require the host traffic to pass [RFC5207]. Also, NATs usually require the host
behind a NAT to create a forwarding state in the NAT before other behind a NAT to create a forwarding state in the NAT before other
hosts outside of the NAT can contact the host behind the NAT. To hosts outside of the NAT can contact the host behind the NAT. To
overcome this problem, different methods, commonly referred to as NAT overcome this problem, different methods, commonly referred to as NAT
traversal techniques, have been developed. traversal techniques, have been developed.
As one solution, the HIP experiment report [RFC6538] mentions Teredo- As one solution, the HIP experiment report [RFC6538] mentions Teredo-
based NAT traversal for HIP and related ESP traffic (with double based NAT traversal for HIP and related ESP traffic (with double
tunneling overhead). Another solution is specified in [RFC5770], tunneling overhead). Another solution is specified in [RFC5770],
which will be referred to "Legacy ICE-HIP" in this document. The which will be referred to as "Legacy ICE-HIP" in this document. The
experimental Legacy ICE-HIP specification combines Interactive experimental Legacy ICE-HIP specification combines Interactive
Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that
basically ICE is responsible for NAT traversal and connectivity basically ICE is responsible for NAT traversal and connectivity
testing, while HIP is responsible for end-host authentication and testing, while HIP is responsible for end-host authentication and
IPsec key management. The resulting protocol uses HIP, STUN and ESP IPsec key management. The resulting protocol uses HIP, STUN and ESP
messages tunneled over a single UDP flow. The benefit of using ICE messages tunneled over a single UDP flow. The benefit of using ICE
and its STUN/TURN messaging formats is that one can re-use the NAT and its STUN/TURN messaging formats is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
STUN and TURN servers. Also, some middleboxes may be STUN-aware and STUN and TURN servers. Also, some middleboxes may be STUN-aware and
may be able to do something "smart" when they see STUN being used for may be able to do something "smart" when they see STUN being used for
skipping to change at page 13, line 28 skipping to change at page 13, line 29
It can wait for its lifetime to expire or it can explicitly request It can wait for its lifetime to expire or it can explicitly request
it with zero lifetime using the UPDATE mechanism. The Data Relay it with zero lifetime using the UPDATE mechanism. The Data Relay
Client can send an REG_REQ parameter with zero lifetime to the Data Client can send an REG_REQ parameter with zero lifetime to the Data
Relay Server in order to expire all relayed candidates. To expire a Relay Server in order to expire all relayed candidates. To expire a
specific relayed candidate, the Data Relay Client MUST also include specific relayed candidate, the Data Relay Client MUST also include
RELAYED_ADDRESS parameter as sent by the server in the UPDATE RELAYED_ADDRESS parameter as sent by the server in the UPDATE
message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure
initiated by either party), the Data Relay Server MUST also expire initiated by either party), the Data Relay Server MUST also expire
all relayed candidates. all relayed candidates.
To avoid cross-protocol attacks associated with RELAY_HMAC and Please also refer to Section 6.8 for protection against cross-
RVS_HMAC, a Control Relay Server MUST NOT offer RENDEZVOUS protocol attacks for both Control Relay Client and Server.
registration service [RFC8004] to any Control Relay Client.
4.2. Transport Address Candidate Gathering at the Relay Client 4.2. Transport Address Candidate Gathering at the Relay Client
An Initiator needs to gather a set of address candidates before An Initiator needs to gather a set of address candidates before
contacting a (non-relay) Responder. The candidates are needed for contacting a (non-relay) Responder. The candidates are needed for
connectivity checks that allow two hosts to discover a direct, non- connectivity checks that allow two hosts to discover a direct, non-
relayed path for communicating with each other. One server reflexive relayed path for communicating with each other. One server reflexive
candidate can be discovered during the registration with the Control candidate can be discovered during the registration with the Control
Relay Server from the REG_FROM parameter (and another from Data Relay Relay Server from the REG_FROM parameter (and another from Data Relay
Server if one is employed). Server if one is employed).
skipping to change at page 15, line 41 skipping to change at page 15, line 44
Unlike with SDP used in conjunction with ICE, this protocol only Unlike with SDP used in conjunction with ICE, this protocol only
creates a single UDP flow between the two communicating hosts, so creates a single UDP flow between the two communicating hosts, so
only a single component exists. Hence, the component ID value MUST only a single component exists. Hence, the component ID value MUST
always be set to 1. always be set to 1.
As defined in section 14.3 in [RFC8445], the retransmission timeout As defined in section 14.3 in [RFC8445], the retransmission timeout
(RTO) for address gathering from a Control/Data Relay Server SHOULD (RTO) for address gathering from a Control/Data Relay Server SHOULD
be calculated as follows: be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Of-Cands)) RTO = MAX (1000ms, Ta * (Num-Of-Cands))
where Ta is the value used for the connectivity check pacing and Num- where Ta is the value used for the connectivity check pacing and Num-
Of-Cands is the number of server-reflexive and relay candidates. A Of-Cands is the number of server-reflexive and relay candidates. A
smaller value than 500 ms for the RTO MUST NOT be used. smaller value than 1000 ms for the RTO MUST NOT be used.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a non-critical parameter type This section describes the usage of a non-critical parameter type
called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
base exchange means that the end-host supports NAT traversal base exchange means that the end-host supports NAT traversal
extensions described in this document. As the parameter is non- extensions described in this document. As the parameter is non-
critical (as defined in Section 5.2.1 of [RFC7401]), it can be critical (as defined in Section 5.2.1 of [RFC7401]), it can be
ignored by a end-host, which means that the host is not required to ignored by a end-host, which means that the host is not required to
skipping to change at page 25, line 13 skipping to change at page 25, line 13
the case. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
queue a response by placing it in the triggered-check queue, and then queue a response by placing it in the triggered-check queue, and then
continue waiting for the candidates. A host MUST NOT select a continue waiting for the candidates. A host MUST NOT select a
candidate pair until it has verified the pair using a connectivity candidate pair until it has verified the pair using a connectivity
check as defined in Section 4.6.1. check as defined in Section 4.6.1.
[RFC7401] section 5.3.5 states that UPDATE packets have to include [RFC7401] section 5.3.5 states that UPDATE packets have to include
either a SEQ or ACK parameter (but can include both). According to either a SEQ or ACK parameter (but can include both). In the
the RFC, each SEQ parameter should be acknowledged separately. In connectivity check procedure specified in Section 4.6.1, each SEQ
the context of NATs, this means that some of the SEQ parameters sent parameter should be acknowledged separately. In the context of NATs,
in connectivity checks will be lost or arrive out of order. From the this means that some of the SEQ parameters sent in connectivity
viewpoint of the recipient, this is not a problem since the recipient checks will be lost or arrive out of order. From the viewpoint of
will just "blindly" acknowledge the SEQ. However, the sender needs the recipient, this is not a problem since the recipient will just
to be prepared for lost sequence identifiers and ACKs parameters that "blindly" acknowledge the SEQ. However, the sender needs to be
prepared for lost sequence identifiers and ACKs parameters that
arrive out of order. arrive out of order.
As specified in [RFC7401], an ACK parameter may acknowledge multiple As specified in [RFC7401], an ACK parameter may acknowledge multiple
sequence identifiers. While the examples in the previous sections do sequence identifiers. While the examples in the previous sections do
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode. employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
be sent with the same sequence identifier in the SEQ parameter. Some be sent with the same sequence identifier in the SEQ parameter. Some
tested address candidates will never produce a working address pair, tested address candidates will never produce a working address pair,
skipping to change at page 26, line 7 skipping to change at page 26, line 8
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
neither one of the hosts announced a minimum pacing value, a value of neither one of the hosts announced a minimum pacing value, a value of
50 ms MUST be used. 50 ms MUST be used.
Both hosts MUST form a priority ordered checklist and begin to check Both hosts MUST form a priority ordered checklist and begin to check
transactions every Ta milliseconds as long as the checks are running transactions every Ta milliseconds as long as the checks are running
and there are candidate pairs whose tests have not started. The and there are candidate pairs whose tests have not started. The
retransmission timeout (RTO) for the connectivity check UPDATE retransmission timeout (RTO) for the connectivity check UPDATE
packets SHOULD be calculated as follows: packets SHOULD be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (1000ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
"In-Progress" state. This is identical to the formula in [RFC8445] "In-Progress" state. This is identical to the formula in [RFC8445]
when there is only one checklist. A smaller value than 500 ms for when there is only one checklist. A smaller value than 1000 ms for
the RTO MUST NOT be used. the RTO MUST NOT be used.
Each connectivity check request packet MUST contain a Each connectivity check request packet MUST contain a
CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority
value that would be assigned to a peer reflexive candidate if one was value that would be assigned to a peer reflexive candidate if one was
learned from the corresponding check. An UPDATE packet that learned from the corresponding check. An UPDATE packet that
acknowledges a connectivity check request MUST be sent from the same acknowledges a connectivity check request MUST be sent from the same
address that received the check and delivered to the same address address that received the check and delivered to the same address
where the check was received from. Each acknowledgment UPDATE packet where the check was received from. Each acknowledgment UPDATE packet
MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and
skipping to change at page 45, line 26 skipping to change at page 45, line 26
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
A Control/Data Relay Server and end-hosts can use NOTIFY packets to A Control/Data Relay Server and end-hosts can use NOTIFY packets to
signal different error conditions. The NOTIFY packet types are the signal different error conditions. The NOTIFY packet types are the
same as in Legacy ICE-HIP [RFC5770] except for last one, which is same as in Legacy ICE-HIP [RFC5770] except for the two last ones,
new. which are new.
The Notify Packet Types [RFC7401] are shown below. The Notification The Notify Packet Types [RFC7401] are shown below. The Notification
Data field for the error notifications SHOULD contain the HIP header Data field for the error notifications SHOULD contain the HIP header
of the rejected packet and SHOULD be empty for the of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type. CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ ----- ------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
skipping to change at page 46, line 13 skipping to change at page 46, line 13
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 SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63
Used by a Data Relay Server to signal that is was not able or 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 willing to allocate a new server reflexive candidate for the Data
Relay Client Relay Client
RVS_HMAC_PROHIBITED_WITH_RELAY 64
In the unintended event that a Control Relay Server sends any HIP
message with a RVS_HMAC parameter, the Control Relay Client drops
the received HIP message and sends a notify message back to the
Control Relay Server using this notify type
5.11. ESP Data Packets 5.11. ESP Data Packets
The format for ESP data packets is identical to Legacy ICE-HIP The format for ESP data packets is identical to Legacy ICE-HIP
[RFC5770]. [RFC5770].
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport [RFC3948] describes the UDP encapsulation of the IPsec ESP transport
and tunnel mode. On the wire, the HIP ESP packets do not differ from and tunnel mode. On the wire, the HIP ESP packets do not differ from
the transport mode ESP, and thus the encapsulation of the HIP ESP the transport mode ESP, 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 52, line 32 skipping to change at page 52, line 32
HIP messages are integrity and replay protected, so it is not HIP messages are integrity and replay protected, so it is not
possible inject fake server reflexive address candidates. possible inject fake server reflexive address candidates.
Section 19.4 in [RFC8445] describes attacks on relayed candidate Section 19.4 in [RFC8445] describes attacks on relayed candidate
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.
6.8. Cross-Protocol Attacks
Section 4.1 explains how a Control Relay Client registers for the
RELAY_UDP_HIP service from a Control Relay Server. However, the same
server may offer also Rendezvous functionality, and, thus, a client
can register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004])
service from the same server. Potentially, this introduces a cross-
protocol attack (or actually a "cross-message" attack) because the
key material is the same for the Control Relay Service and Rendezvous
HMACs. While the problem could be avoided by deriving different keys
for the Control Relay Service, a more simple measure was chosen
because the exact attack scenario was unclear. Consequently, this
section defines a mandatory mitigation mechanism against the cross-
protocol attack that works by preventing the simultanous use of
Rendezvous and Control Relay Service in the context of a single HIP
Association.
The registration involves three parameters typically delivered
sequentally in R1 (REG_INFO parameter), I2 (REG_REQUEST) and R2
(REG_RESPONSE) messages but can also be delivered in UPDATE messages
as described in [RFC8003]. The parameters and the modifications to
their processing are described below:
1. REG_INFO: the Control Relay Server advertizes its available
services using this parameter. RELAY_UDP_HIP and RENDEZVOUS
services MAY be included in the first advertizement for the HIP
association but subsequent ones MUST include only one of them as
agreed in earlier registrations (see steps 2 and 3).
2. REG_REQUEST: the Control Relay Client chooses the services it
requires using this parameter. If the Control Relay Server
offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay
Client MUST choose only one of them in the REG_REQUEST parameter.
Upon choosing one of of the two, it persists throughout the
lifetime of the HIP association, and the Control Relay Client
MUST NOT register the other remaining one in a subsequent UPDATE
message.
3. REG_RESPONSE: the Control Relay Server verifies the services
requested by the Control Relay Client using this parameter. If
the Control Relay Server offered both RENDEZVOUS and
RELAY_UDP_HIP service, and the Control Relay Client requested for
both of them, the Control Relay Client MUST offer only
RELAY_UDP_HIP service in the REG_RESPONSE parameter and include a
REG_FAILED parameter in the same message, with RENDEZVOUS as the
Registration Type and [TBD by IANA: 9] as the Failure Type.
As a further measure against cross-protocol attacks, Control Relay
Client MUST drop any HIP message that includes an RVS_HMAC parameter
when it originates from successfully registered Control Relay Server.
Upon such an (unintended) event, the Control Relay Client MUST send a
NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify
Message Type to the Control Relay Server.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC8126]. This section is to be interpreted according to [RFC8126].
This document reuses the same default UDP port number 10500 as This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
plane and data plane traffic. The port was was registered separately plane and data plane traffic. The port was was registered separately
for RFC5770 to co-author Ari Keranen but should now be re-assigned for RFC5770 to co-author Ari Keranen but should now be re-assigned
for IESG control. With the permission of Ari Keranen, the new for IESG control. With the permission of Ari Keranen, the new
assignee is IESG and contact "chair@ietf.org". In addition, IANA is assignee is IESG and contact "chair@ietf.org". In addition, IANA is
skipping to change at page 53, line 13 skipping to change at page 54, line 20
Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20,
defined in Section 5.12), PEER_PERMISSION (length 48, defined in defined in Section 5.12), PEER_PERMISSION (length 48, defined in
Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14)
and NOMINATE (length 4, defined in Section 5.15). and NOMINATE (length 4, defined in Section 5.15).
This document updates the IANA Registry for HIP NAT traversal modes This document updates the IANA Registry for HIP NAT traversal modes
specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT
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, a new error type
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in Section 5.10. SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED and
RVS_HMAC_PROHIBITED_WITH_RELAY 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).
This document defines an additional Registration Failure Type as
defined in Section 6.8. The value is [TBD by IANA: 9] and the
Registration Failure Type is "Simultaneous Rendezvous and Control
Relay Service usage prohibited".
ICE specification [RFC8445] discusses "Unilateral Self-Address ICE specification [RFC8445] discusses "Unilateral Self-Address
Fixing" in section 18. 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. same considerations apply also here.
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 53, line 46 skipping to change at page 55, line 11
like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling, like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling,
Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their
contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey
M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander, M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander,
Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela,
Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani
Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to
[RFC5770] and this document. Thanks for Eric Vyncke, Alvaro Retana, [RFC5770] and this document. Thanks for Eric Vyncke, Alvaro Retana,
Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer
Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins, Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins,
Roni Even, Alissa Cooper, Carl Wallace and Benjamin Kaduk for Roni Even, Alissa Cooper, Carl Wallace, Martin Duke and Benjamin
reviewing this document. Kaduk for reviewing this document.
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 55, line 44 skipping to change at page 57, line 11
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, Ed., "Basic Host Identity Protocol (HIP) Keranen, Ed., "Basic Host Identity Protocol (HIP)
Extensions for Traversal of Network Address Translators", Extensions for Traversal of Network Address Translators",
RFC 5770, DOI 10.17487/RFC5770, April 2010, RFC 5770, DOI 10.17487/RFC5770, April 2010,
<https://www.rfc-editor.org/info/rfc5770>. <https://www.rfc-editor.org/info/rfc5770>.
[I-D.ietf-tcpm-rto-consider]
Allman, M., "Requirements for Time-Based Loss Detection",
draft-ietf-tcpm-rto-consider-16 (work in progress), June
2020.
10.2. Informative References 10.2. Informative References
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-20 (work in Architecture", draft-ietf-hip-rfc4423-bis-20 (work in
progress), February 2019. progress), February 2019.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
skipping to change at page 57, line 14 skipping to change at page 58, line 30
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
Initialization Vector (IV) for Counter-Based Ciphers in Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP)", RFC 8750, Encapsulating Security Payload (ESP)", RFC 8750,
DOI 10.17487/RFC8750, March 2020, DOI 10.17487/RFC8750, March 2020,
<https://www.rfc-editor.org/info/rfc8750>. <https://www.rfc-editor.org/info/rfc8750>.
[I-D.ietf-tsvwg-datagram-plpmtud] [I-D.ietf-tsvwg-datagram-plpmtud]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-17 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-22
(work in progress), March 2020. (work in progress), June 2020.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
skipping to change at page 60, line 36 skipping to change at page 62, line 9
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 but rather encrypted to avoid middlebox tampering. protocol but rather encrypted to avoid middlebox tampering.
o Native ICE-HIP protocol does not employ the ICE related address 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).
o Minimum RTO is 500 ms in ICE but 1000 ms in Native ICE-HIP
protocol in favor of [I-D.ietf-tcpm-rto-consider]
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].
o Both control and data plane are operated on top of UDP, not o Both control and data plane are operated on top of UDP, not
directly on IP. directly on IP.
o A minimal implementation would conform only to Section 4.7.1 or o A minimal implementation would conform only to Section 4.7.1 or
 End of changes. 21 change blocks. 
41 lines changed or deleted 117 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/