draft-ietf-hip-native-nat-traversal-16.txt   draft-ietf-hip-native-nat-traversal-17.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: August 8, 2017 Ericsson Expires: August 19, 2017 Ericsson
February 4, 2017 February 15, 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-16 draft-ietf-hip-native-nat-traversal-17
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 August 8, 2017. This Internet-Draft will expire on August 19, 2017.
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 4, line 17 skipping to change at page 4, line 17
document also specifies how mobility management works in the context document also specifies how mobility management works in the context
of NAT traversal, which was missing from [RFC5770]. of NAT traversal, which was missing from [RFC5770].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [RFC5770], [RFC7401], This document borrows terminology from [RFC5770], [RFC7401],
[I-D.ietf-hip-rfc5206-bis], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC8046], [RFC4423], [I-D.ietf-ice-rfc5245bis], and [RFC5389]. The
[RFC5389]. The following terms recur in the text: following terms recur in the text:
HIP relay server: HIP relay server:
A host that forwards any kind of HIP control packets between the A host that forwards any kind of HIP control packets between the
Initiator and the Responder. Initiator and the Responder.
HIP data relay: HIP data relay:
A host that forwards HIP data packets, such as Encapsulating A host that forwards HIP data packets, such as Encapsulating
Security Payload (ESP) [RFC7402], between two hosts. Security Payload (ESP) [RFC7402], between two hosts.
Registered host: Registered host:
A host that has registered for a relaying service with a HIP data A host that has registered for a relaying service with a HIP data
relay. relay.
Locator: Locator:
As defined in [I-D.ietf-hip-rfc5206-bis]: "A name that controls As defined in [RFC8046]: "A name that controls how the packet is
how the packet is routed through the network and demultiplexed by routed through the network and demultiplexed by the end-host. It
the end-host. It may include a concatenation of traditional may include a concatenation of traditional network addresses such
network addresses such as an IPv6 address and end-to-end as an IPv6 address and end-to-end identifiers such as an ESP SPI.
identifiers such as an ESP SPI. It may also include transport It may also include transport port numbers or IPv6 Flow Labels as
port numbers or IPv6 Flow Labels as demultiplexing context, or it demultiplexing context, or it may simply be a network address."
may simply be a network address."
LOCATOR_SET (written in capital letters): LOCATOR_SET (written in capital letters):
Denotes a HIP control packet parameter that bundles multiple Denotes a HIP control packet parameter that bundles multiple
locators together. locators together.
ICE offer: ICE offer:
The Initiator's LOCATOR_SET parameter in a HIP I2 control packet. The Initiator's LOCATOR_SET parameter in a HIP I2 control packet.
Corresponds to the ICE offer parameter, but is HIP specific. Corresponds to the ICE offer parameter, but is HIP specific.
ICE answer: ICE answer:
skipping to change at page 24, line 29 skipping to change at page 24, line 29
was no preferred locator in R1). The Initiator MAY include locators was no preferred locator in R1). The Initiator MAY include locators
in I2 but they MUST NOT be taken as address candidates, since in I2 but they MUST NOT be taken as address candidates, since
connectivity checks defined in this document will not be used for connectivity checks defined in this document will not be used for
connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
R2 and I2 are received and processed successfully, a security R2 and I2 are received and processed successfully, a security
association can be created and UDP-encapsulated ESP can be exchanged association can be created and UDP-encapsulated ESP can be exchanged
between the hosts after the base exchange completes. However, the between the hosts after the base exchange completes. However, the
Responder SHOULD NOT send any ESP to the Initiator's address before Responder SHOULD NOT send any ESP to the Initiator's address before
it has received data from the Initiator, as specified in Sections it has received data from the Initiator, as specified in Sections
4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of 4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of
[I-D.ietf-hip-rfc5206-bis]. [RFC8046].
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected
MUST NOT be sent via a relay, the Responder SHOULD reject such I2 MUST NOT be sent via a relay, the Responder SHOULD reject such I2
packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY
packet (see Section 5.10). packet (see Section 5.10).
If there is no answer for the I2 packet sent directly to the If there is no answer for the I2 packet sent directly to the
Responder's preferred address, the Initiator MAY send another I2 via Responder's preferred address, the Initiator MAY send another I2 via
the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT
traversal mode for that I2. traversal mode for that I2.
skipping to change at page 26, line 14 skipping to change at page 26, line 14
RELAY_FROM parameter to the control packets it relays to the RELAY_FROM parameter to the control packets it relays to the
registered hosts. registered hosts.
If the HIP relay server is not willing or able to relay a HIP packet, If the HIP relay server is not willing or able to relay a HIP packet,
it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error
notification (see Section 5.10). notification (see Section 5.10).
4.9. Mobility Handover Procedure 4.9. Mobility Handover Procedure
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [I-D.ietf-hip-rfc5206-bis] define Mobility extensions for HIP [RFC8046] define handover procedures
handover procedures without NATs. In this section, we define how two without NATs. In this section, we define how two hosts interact with
hosts interact with handover procedures in scenarios involving NATs. handover procedures in scenarios involving NATs. The specified
The specified extensions define only simple mobility using a pair of extensions define only simple mobility using a pair of security
security associations, and multihoming extensions are left to be associations, and multihoming extensions are left to be defined in
defined in later specifications. The procedures in this section later specifications. The procedures in this section offer the same
offer the same functionality as "ICE restart" specified in functionality as "ICE restart" specified in
[I-D.ietf-ice-rfc5245bis]. The example described in this section [I-D.ietf-ice-rfc5245bis]. The example described in this section
shows only a relay server for the peer host for the sake of shows only a relay server for the peer host for the sake of
simplicity, but also the mobile host may also have a relay server. simplicity, but also the mobile host may also have a relay server.
The assumption here is that the two hosts have successfully The assumption here is that the two hosts have successfully
negotiated and chosen the ICE-HIP-UDP mode during the base exchange negotiated and chosen the ICE-HIP-UDP mode during the base exchange
as defined in Section 4.3. The Initiator of the base exchange MUST as defined in Section 4.3. The Initiator of the base exchange MUST
store information that it was the controlling host during the base store information that it was the controlling host during the base
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
skipping to change at page 27, line 38 skipping to change at page 27, line 38
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 HIP relay of the peer. It sends an update to its peer through the HIP relay of the peer. It sends an
UPDATE packet with source HIT belonging to itself and destination HIT UPDATE packet with source HIT belonging to itself and destination HIT
belonging to the peer host. In the packet, the source IP address belonging to the peer host. In the packet, the source IP address
belongs to the mobile host and the destination to the HIP relay. The belongs to the mobile host and the destination to the HIP relay. The
packet contains an ESP_INFO parameter, where, in this case, the OLD packet contains an ESP_INFO parameter, where, in this case, the OLD
SPI and NEW SPI parameters both contain the pre-existing incoming SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The packet also contains the locators of the mobile host in a SPI. The packet also contains the locators of the mobile host in a
LOCATOR_SET parameter. The packet contains also a SEQ number to be LOCATOR_SET parameter. The packet contains also a SEQ number to be
acknowledged by the peer. As specified in acknowledged by the peer. As specified in [RFC8046], the packet may
[I-D.ietf-hip-rfc5206-bis], the packet may also include a HOST_ID also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN
(for middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying. parameter for rekeying.
In step 2, HIP relay receives the UPDATE packet and forwards it to In step 2, HIP relay receives the UPDATE packet and forwards it to
the peer host (i.e. relay client). The HIP relay rewrites the the peer host (i.e. relay client). The HIP relay rewrites the
destination IP address and appends a RELAY_FROM parameter to the destination IP address and appends a RELAY_FROM parameter to the
message. 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 HIP relay. The HIT of mobile host and to the IP address of the HIP relay. The
message includes an ESP_INFO parameter where, in this case, the OLD message includes an ESP_INFO parameter where, in this case, the OLD
skipping to change at page 45, line 48 skipping to change at page 45, line 48
<http://www.rfc-editor.org/info/rfc7401>. <http://www.rfc-editor.org/info/rfc7401>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003, Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>. October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
October 2016, <http://www.rfc-editor.org/info/rfc8004>. October 2016, <http://www.rfc-editor.org/info/rfc8004>.
[I-D.ietf-hip-rfc5206-bis] [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with with the Host Identity Protocol", RFC 8046,
the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-14 DOI 10.17487/RFC8046, February 2017,
(work in progress), October 2016. <http://www.rfc-editor.org/info/rfc8046>.
[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,
<http://www.rfc-editor.org/info/rfc5770>. <http://www.rfc-editor.org/info/rfc5770>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
skipping to change at page 50, line 22 skipping to change at page 50, line 22
o Unlike in ICE, the addresses are not xorred in this protocol in o Unlike in ICE, the addresses are not xorred in this protocol in
order to avoid middlebox tampering. order to avoid middlebox tampering.
o This protocol does not employ the ICE related address and related o This protocol does not employ the ICE related address and related
port attributes (that are used for diagnostic or SIP purposes). port attributes (that are used for diagnostic or SIP purposes).
Appendix D. Differences to Base Exchange and UPDATE procedures Appendix D. 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 extends and differs from [RFC7401] and extensions in this protocol extends and differs from [RFC7401] and
[I-D.ietf-hip-rfc5206-bis]. [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
Section 4.7.2, thus merely tunneling HIP control and data traffic Section 4.7.2, thus merely tunneling HIP control and data traffic
over UDP. The drawback here is that it works only in the limited over UDP. The drawback here is that it works only in the limited
cases where the Responder has a public address. cases where the Responder has a public address.
o It is worth noting that while a rendezvous server [RFC8004] has o It is worth noting that while a rendezvous server [RFC8004] has
skipping to change at page 51, line 24 skipping to change at page 51, line 24
this extension, we follow the ICE methodology, where one end-point this extension, we follow the ICE methodology, where one end-point
acting in the controlled role chooses the used address pair also acting in the controlled role chooses the used address pair also
on behalf of the other end-point acting in controlled role, which on behalf of the other end-point acting in controlled role, which
is different from HIP without NAT traversal support. Another is different from HIP without NAT traversal support. Another
difference is that the process of choosing an address pair is difference is that the process of choosing an address pair is
explicitly signaled using the nomination packets. The nomination explicitly signaled using the nomination packets. The nomination
process in this protocol supports only single address pair, and process in this protocol supports only single address pair, and
multihoming extensions are left for further study. multihoming extensions are left for further study.
o The UPDATE procedure resembles the mobility extensions defined in o The UPDATE procedure resembles the mobility extensions defined in
[I-D.ietf-hip-rfc5206-bis]. The first UPDATE message from the [RFC8046]. The first UPDATE message from the mobile host is
mobile host is exactly the same as in the mobility extensions. exactly the same as in the mobility extensions. The second UPDATE
The second UPDATE message from the peer host and third from the message from the peer host and third from the mobile host are
mobile host are different in the sense that they merely different in the sense that they merely acknowledge and conclude
acknowledge and conclude the reception of the candidates through the reception of the candidates through the relay. In other
the relay. In other words, they do not yet test for connectivity words, they do not yet test for connectivity (besides reachability
(besides reachability through the HIP relay) unlike in the through the HIP relay) unlike in the mobility extensions. The
mobility extensions. The idea is that connectivity check idea is that connectivity check procedure follows the ICE
procedure follows the ICE specification, which is somewhat specification, which is somewhat different from the HIP mobility
different from the HIP mobility extensions. extensions.
o The connectivity checks as defined in the mobility extensions o The connectivity checks as defined in the mobility extensions
[I-D.ietf-hip-rfc5206-bis] are triggered only by the peer of the [RFC8046] are triggered only by the peer of the mobile host.
mobile host. Since successful NAT penetration requires that both Since successful NAT penetration requires that both end-points
end-points test connectivity, both the mobile host and its peer test connectivity, both the mobile host and its peer host have to
host have to test for connectivity. In addition, this protocol test for connectivity. In addition, this protocol validates also
validates also the UDP ports; the ports in the connectivity check the UDP ports; the ports in the connectivity check must match with
must match with the response, as required by ICE. the response, as required by ICE.
o In HIP mobility extensions [I-D.ietf-hip-rfc5206-bis], an outbound o In HIP mobility extensions [RFC8046], an outbound locator has some
locator has some associated state: UNVERIFIED mean that the associated state: UNVERIFIED mean that the locator has not been
locator has not been tested for reachability, ACTIVE means that tested for reachability, ACTIVE means that the address has been
the address has been verified for reachability and is being used verified for reachability and is being used actively, and
actively, and DEPRECATED means that the locator lifetime has DEPRECATED means that the locator lifetime has expired. In the
expired. In the subset of ICE specifications used by this subset of ICE specifications used by this protocol, an individual
protocol, an individual address candidate has only two properties: address candidate has only two properties: type and priority.
type and priority. Instead, the actual state in ICE is associated Instead, the actual state in ICE is associated with candidate
with candidate pairs rather than individual addresses. The subset pairs rather than individual addresses. The subset of ICE
of ICE specifications utilized by this protocol require the specifications utilized by this protocol require the following
following attributes for a candidate pair: valid bit, nominated attributes for a candidate pair: valid bit, nominated bit, base
bit, base and the state of connectivity check. The connectivity and the state of connectivity check. The connectivity checks have
checks have the following states: Waiting, In-progress, Succeeded the following states: Waiting, In-progress, Succeeded and Failed.
and Failed. Handling of this state attribute requires some Handling of this state attribute requires some additional logic
additional logic when compared to the mobility extensions since when compared to the mobility extensions since the state is
the state is associated with a local-remote address pair rather associated with a local-remote address pair rather just a remote
just a remote address, and the states of the different address, and the states of the different specification do not have
specification do not have an unambiguous one-to-one mappings. an unambiguous one-to-one mappings.
o Credit-based authorization as defined in o Credit-based authorization as defined in [RFC8046] could be used
[I-D.ietf-hip-rfc5206-bis] could be used before candidate before candidate nomination has been concluded upon discovering
nomination has been concluded upon discovering working candidate working candidate pairs. However, this may result in the use of
pairs. However, this may result in the use of asymmetric paths asymmetric paths for a short time period in the beginning of
for a short time period in the beginning of communications communications (similarly as in aggressive ICE nomination). Thus,
(similarly as in aggressive ICE nomination). Thus, support support credit-based authorization is left for further study.
credit-based authorization is left for further study.
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. 14 change blocks. 
70 lines changed or deleted 68 lines changed or added

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