draft-ietf-hip-native-nat-traversal-24.txt   draft-ietf-hip-native-nat-traversal-25.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 2, 2018 Ericsson Expires: June 11, 2018 Ericsson
November 29, 2017 December 8, 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-24 draft-ietf-hip-native-nat-traversal-25
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 June 2, 2018. This Internet-Draft will expire on June 11, 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 5, line 40 skipping to change at page 5, line 40
Control Relay Server Control Relay Server
A registrar host that forwards any kind of HIP control plane A registrar host that forwards any kind of HIP control plane
packets between the Initiator and the Responder. This host is packets between the Initiator and the Responder. This host is
critical because it relays the locators between the Initiator and critical because it relays the locators between the Initiator and
the Responder, so that they can try to establish a direct the Responder, so that they can try to establish a direct
communication path with each other. This host is used to replace communication path with each other. This host is used to replace
HIP rendezvous servers [RFC8004] for hosts operating in private HIP rendezvous servers [RFC8004] for hosts operating in private
address realms. In the Legacy ICE-HIP specification, this host is address realms. In the Legacy ICE-HIP specification, this host is
denoted as "HIP Relay Server". denoted as "HIP Relay Server".
.
Control Relay Client: Control Relay Client:
A requester host that registers to a Control Relay Server A requester host that registers to a Control Relay Server
requesting it to forward control-plane traffic (i.e. HIP control requesting it to forward control-plane traffic (i.e. HIP control
messages). In the Legacy ICE-HIP specification, this is denoted messages). In the Legacy ICE-HIP specification, this is denoted
as "HIP Relay Client". as "HIP Relay Client".
Data Relay Server: Data Relay Server:
A registrar host that forwards HIP related data plane packets, A registrar host that forwards HIP related data plane packets,
such as Encapsulating Security Payload (ESP) [RFC7402], between such as Encapsulating Security Payload (ESP) [RFC7402], between
skipping to change at page 10, line 11 skipping to change at page 10, line 11
control plane traffic over UDP in NATted environments, and forwards control plane traffic over UDP in NATted environments, and forwards
HIP control packets between the Initiator and the Responder. In this HIP control packets between the Initiator and the Responder. In this
document, the HIP Relay Server is denoted as "Control Relay Server" document, the HIP Relay Server is denoted as "Control Relay Server"
for better alignment with the rest of the terminology. The for better alignment with the rest of the terminology. The
registration to the Control Relay Server can be achieved using registration to the Control Relay Server can be achieved using
RELAY_UDP_ESP parameter as explained later in this section. RELAY_UDP_ESP parameter as explained later in this section.
To guarantee also data plane delivery over varying types of NAT To guarantee also data plane delivery over varying types of NAT
devices, a host MAY also register for UDP encapsulated ESP relaying devices, a host MAY also register for UDP encapsulated ESP relaying
using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This
service may be coupled with the Control Relay Server server or service may be coupled with the Control Relay Server or offered
offered separately on another server. If the server supports separately on another server. If the server supports relaying of UDP
relaying of UDP encapsulated ESP, the host is allowed to register for encapsulated ESP, the host is allowed to register for a data relaying
a data relaying service using the registration extensions in service using the registration extensions in Section 3.3 of
Section 3.3 of [RFC8003]). If the server has sufficient relaying [RFC8003]). If the server has sufficient relaying resources (free
resources (free port numbers, bandwidth, etc.) available, it opens a port numbers, bandwidth, etc.) available, it opens a UDP port on one
UDP port on one of its addresses and signals the address and port to of its addresses and signals the address and port to the registering
the registering host using the RELAYED_ADDRESS parameter (as defined host using the RELAYED_ADDRESS parameter (as defined in Section 5.12
in Section 5.12 in this document). If the Data Relay Server would in this document). If the Data Relay Server would accept the data
accept the data relaying request but does not currently have enough relaying request but does not currently have enough resources to
resources to provide data relaying service, it MUST reject the provide data relaying service, it MUST reject the request with
request with Failure Type "Insufficient resources" [RFC8003]. Failure Type "Insufficient resources" [RFC8003].
A Control Relay Server MUST silently drop packets to a Control Relay A Control Relay Server MUST silently drop packets to a Control Relay
Client that has not previously registered with the HIP relay. The Client that has not previously registered with the HIP relay. The
registration process follows the generic registration extensions registration process follows the generic registration extensions
defined in [RFC8003]. The HIP control plane relaying registration defined in [RFC8003]. The HIP control plane relaying registration
follows [RFC5770], but the data plane registration is different. It follows [RFC5770], but the data plane registration is different. It
is worth noting that if the HIP control and data plane relay services is worth noting that if the HIP control and data plane relay services
reside on different hosts, the client has to register separately to reside on different hosts, the client has to register separately to
each of them. In the example shown in Figure 2, the two services are each of them. In the example shown in Figure 2, the two services are
coupled on a single host. The text uses "Relay Client" and "Relay coupled on a single host. The text uses "Relay Client" and "Relay
skipping to change at page 17, line 32 skipping to change at page 17, line 32
well with some NATs (as explained in [I-D.ietf-ice-rfc5245bis]). The well with some NATs (as explained in [I-D.ietf-ice-rfc5245bis]). The
Initiator MUST NOT propose a smaller value than what the Responder Initiator MUST NOT propose a smaller value than what the Responder
offered. If a host does not include the TRANSACTION_PACING parameter offered. If a host does not include the TRANSACTION_PACING parameter
in the base exchange, a Ta value of 50 ms MUST be used as that host's in the base exchange, a Ta value of 50 ms MUST be used as that host's
minimum value. minimum value.
4.5. Base Exchange via Control Relay Server 4.5. Base Exchange via Control Relay Server
This section describes how the Initiator and Responder perform a base This section describes how the Initiator and Responder perform a base
exchange through a Control Relay Server. Connectivity pacing exchange through a Control Relay Server. Connectivity pacing
(denoted as TA_P here) was described in Section 4.4 and is neither (denoted as TA_P here) was described in Section 4.4 and is not
repeated here. Similarly, the NAT traversal mode negotiation process repeated here. Similarly, the NAT traversal mode negotiation process
(denoted as NAT_TM in the example) was described in Section 4.3 and (denoted as NAT_TM in the example) was described in Section 4.3 and
is neither repeated here. If a Control Relay Server receives an R1 is neither repeated here. If a Control Relay Server receives an R1
or I2 packet without the NAT traversal mode parameter, it MUST drop or I2 packet without the NAT traversal mode parameter, it MUST drop
it and SHOULD send a NOTIFY error packet with type it and SHOULD send a NOTIFY error packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2.
It is RECOMMENDED that the Initiator send an I1 packet encapsulated It is RECOMMENDED that the Initiator send an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with a Respectively, the Responder MUST respond to such an I1 packet with a
skipping to change at page 19, line 21 skipping to change at page 19, line 21
RELAY_TO parameter is not integrity protected by the signature of the RELAY_TO parameter is not integrity protected by the signature of the
R1 to allow pre-created R1 packets at the Responder. R1 to allow pre-created R1 packets at the Responder.
In step 4, the Control Relay Server receives the R1 packet. The In step 4, the Control Relay Server receives the R1 packet. The
Control Relay Server drops the packet silently if the source HIT Control Relay Server drops the packet silently if the source HIT
belongs to a Control Relay Client that has not successfully belongs to a Control Relay Client that has not successfully
registered. The Control Relay Server MAY verify the signature of the registered. The Control Relay Server MAY verify the signature of the
R1 packet and drop it if the signature is invalid. Otherwise, the R1 packet and drop it if the signature is invalid. Otherwise, the
Control Relay Server rewrites the source address and port, and Control Relay Server rewrites the source address and port, and
changes the destination address and port to match RELAY_TO changes the destination address and port to match RELAY_TO
information. Finally, the Control Relay Server recalculates information. Finally, the Control Relay Server recalculates the
transport checksum and forwards the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [RFC7401]. The Initiator MAY use the address in the according to [RFC7401]. The Initiator MAY use the address in the
RELAY_TO parameter as a local peer-reflexive candidate for this HIP RELAY_TO parameter as a local peer-reflexive candidate for this HIP
association if it is different from all known local candidates. The association if it is different from all known local candidates. The
Initiator replies with an I2 packet that uses the destination Initiator replies with an I2 packet that uses the destination
transport address of R1 as the source address and port. The I2 transport address of R1 as the source address and port. The I2
packet contains a LOCATOR_SET parameter that lists all the HIP packet contains a LOCATOR_SET parameter that lists all the HIP
candidates (ICE offer) of the Initiator. The candidates are encoded candidates (ICE offer) of the Initiator. The candidates are encoded
skipping to change at page 31, line 18 skipping to change at page 31, line 18
exchange during the handover. Similarly, an UPDATE to a Data Relay exchange during the handover. Similarly, an UPDATE to a Data Relay
Server is necessary to make sure the Data Relay Server can forward Server is necessary to make sure the Data Relay Server can forward
data to the correct IP address after a handoff. data to the correct IP address 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. worth noting that the figure corresponds to Control Relay Server. Note that the figure corresponds to figure 3
figure 3 in [RFC8046], but the difference is that the main UPDATE in [RFC8046], but the difference is that the main UPDATE procedure is
procedure is carried over the relay and the connectivity is tested carried over the relay and the connectivity is tested separately.
separately. Next, we describe the procedure in the figure in detail. Next, we describe the procedure in the figure in detail.
Mobile Host Control Relay Server Peer Host Mobile Host Control Relay Server Peer Host
| 1. UDP(UPDATE(ESP_INFO, | | | 1. UDP(UPDATE(ESP_INFO, | |
| LOC_SET, SEQ)) | | | 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, SEQ, | | | 3. UDP(UPDATE(ESP_INFO, SEQ, |
skipping to change at page 57, line 8 skipping to change at page 57, line 8
o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
protocol in order to avoid middlebox tampering. protocol in order to avoid middlebox tampering.
o Native ICE-HIP protocol does not employ the ICE related address o Native ICE-HIP protocol does not employ the ICE related address
and related port attributes (that are used for diagnostic or SIP and related port attributes (that are used for diagnostic or SIP
purposes). purposes).
Appendix C. Differences to Base Exchange and UPDATE procedures Appendix C. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers how the
extensions in this protocol extends and differs 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
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.
 End of changes. 9 change blocks. 
24 lines changed or deleted 23 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/