draft-ietf-hip-native-nat-traversal-26.txt   draft-ietf-hip-native-nat-traversal-27.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: June 23, 2018 Ericsson Expires: June 23, 2018 Ericsson
December 20, 2017 December 20, 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-26 draft-ietf-hip-native-nat-traversal-27
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 14, line 15 skipping to change at page 14, line 15
If a Relay Client has more than one network interface, it can If a Relay Client has more than one network interface, it can
discover additional server reflexive candidates by sending UPDATE discover additional server reflexive candidates by sending UPDATE
messages from each of its interfaces to the Relay Server. Each such messages from each of its interfaces to the Relay Server. Each such
UPDATE message MUST include the following parameters: registration UPDATE message MUST include the following parameters: registration
request (REG_REQ) parameter with Registration Type request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED
parameter. When a Control Relay Server receives an UPDATE message parameter. When a Control Relay Server receives an UPDATE message
with registration request containing a CANDIDATE_DISCOVERY type, it with registration request containing a CANDIDATE_DISCOVERY type, it
MUST include a REG_FROM parameter, containing the same information as MUST include a REG_FROM parameter, containing the same information as
if this were a Control Relay Server registration, to the response (in if this were a Control Relay Server registration, to the response (in
addition to the mandatory ECHO_RESPONSE_SIGNED paramater). This addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This
request type SHOULD NOT create any state at the Control Relay Server. request type SHOULD NOT create any state at the Control Relay Server.
ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are
followed here. A number of host candidates (loopback, anycast and followed here. A number of host candidates (loopback, anycast and
others) should be excluded as described in the ICE specification others) should be excluded as described in the ICE specification
[I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in [I-D.ietf-ice-rfc5245bis]. Relayed candidates SHOULD be gathered in
order to guarantee successful NAT traversal, and implementations order to guarantee successful NAT traversal, and implementations
SHOULD support this functionality even if it will not be used in SHOULD support this functionality even if it will not be used in
deployments in order to enable it by software configuration update if deployments in order to enable it by software configuration update if
needed at some point. A host SHOULD employ only a single server for needed at some point. A host SHOULD employ only a single server for
skipping to change at page 44, line 16 skipping to change at page 44, line 16
As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
value has the TLV type 65520. It has the same semantics as RVS_HMAC value has the TLV type 65520. It has the same semantics as RVS_HMAC
[RFC8004]. [RFC8004].
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]. The value for RELAY_UDP_ESP is (value [TBD
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]. 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
skipping to change at page 49, line 47 skipping to change at page 49, line 47
registration parameters that the Control Relay Server proposes and registration parameters that the Control Relay Server proposes and
the Control Client Server accepts during registration. 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 legitimate Responder has to be disconnected from the Control
Relay Server. Relay Server.
The Control Relay Server can protect itself against replay attacks by The Control Relay Server can protect itself against replay attacks by
becoming involved in the base exchange by introducing nonces that the becoming involved in the base exchange by introducing nonces that the
end-hosts (Initiator and Responder) are required to sign. One way to end-hosts (Initiator and Responder) are required to sign. One way to
do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets
as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the
corresponding ECHO_RESPONSE_M parameters are not present. corresponding ECHO_RESPONSE_M parameters are not present.
6.4. Demultiplexing Different HIP Associations 6.4. Demultiplexing Different HIP Associations
skipping to change at page 52, line 15 skipping to change at page 52, line 15
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.
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the
the excellent work on ICE. In addition, the authors would like to MMUSIC WG folks for the excellent work on ICE. In addition, the
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, authors would like to thank Andrei Gurtov, Simon Schuetz, Martin
Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila,
Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka
Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim
Henderson, Alex Elsayed and Jani Hautakorpi for their comments to Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed and
[RFC5770], which is the basis for this document. Jani Hautakorpi for their comments to [RFC5770], which is the basis
for 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,
 End of changes. 5 change blocks. 
13 lines changed or deleted 15 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/