draft-ietf-hip-native-nat-traversal-23.txt   draft-ietf-hip-native-nat-traversal-24.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: May 16, 2018 Ericsson Expires: June 2, 2018 Ericsson
November 12, 2017 November 29, 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-23 draft-ietf-hip-native-nat-traversal-24
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 May 16, 2018. This Internet-Draft will expire on June 2, 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 39 skipping to change at page 5, line 39
Initiator. Initiator.
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,
skipping to change at page 9, line 48 skipping to change at page 9, line 48
defined in [RFC5770] but with different, or additional, parameter defined in [RFC5770] but with different, or additional, parameter
types and values. In addition, a new type of relaying server, Data types and values. In addition, a new type of relaying server, Data
Relay Server, is specified. Also, it should be noted that HIP Relay Server, is specified. Also, it should be noted that HIP
version 2 [RFC7401] (instead of [RFC5201] used in [RFC5770]) is version 2 [RFC7401] (instead of [RFC5201] used in [RFC5770]) is
expected to be used with this NAT traversal mode. expected to be used with this NAT traversal mode.
4.1. Relay Registration 4.1. Relay Registration
In order for two hosts to communicate over NATted environments, they In order for two hosts to communicate over NATted environments, they
need a reliable way to exchange information. To achieve this, "HIP need a reliable way to exchange information. To achieve this, "HIP
relay server" is defined in [RFC5770]. It supports relaying of HIP Relay Server" is defined in [RFC5770]. It supports relaying of HIP
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 server or
offered separately on another server. If the server supports offered separately on another server. If the server supports
relaying of UDP encapsulated ESP, the host is allowed to register for relaying of UDP encapsulated ESP, the host is allowed to register for
skipping to change at page 12, line 43 skipping to change at page 12, line 43
movement or to renew service registration), the Control Relay Server movement or to renew service registration), the Control Relay Server
MUST follow the general guidelines defined in [RFC8003], with the MUST follow the general guidelines defined in [RFC8003], with the
difference that all UPDATE messages are delivered on top of UDP. In difference that all UPDATE messages are delivered on top of UDP. In
addition to this, the Control Relay Server MUST include the REG_FROM addition to this, the Control Relay Server MUST include the REG_FROM
parameter in all UPDATE responses sent to the Control Relay Client. parameter in all UPDATE responses sent to the Control Relay Client.
This applies both renewals of service registration but also to host This applies both renewals of service registration but also to host
movement, where especially the latter requires the Control Relay movement, where especially the latter requires the Control Relay
Client to learn its new server reflexive address candidate. Client to learn its new server reflexive address candidate.
A Data Relay Client can request multiple relayed candidates from the A Data Relay Client can request multiple relayed candidates from the
a Data Relay Server (e.g., for the reasons described in Data Relay Server (e.g., for the reasons described in
Section 4.12.3). After the base exchange with registration, the Data Section 4.12.3). After the base exchange with registration, the Data
Relay Client can request additional relayed candidates similarly as Relay Client can request additional relayed candidates similarly as
during the base exchange. The Data Relay Client sends an UPDATE during the base exchange. The Data Relay Client sends an UPDATE
message REG_REQ parameter requesting for the RELAY_UDP_ESP service. message REG_REQ parameter requesting for the RELAY_UDP_ESP service.
The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGN The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED
parameter. The Data Relay Server MUST respond with an UPDATE message parameter. The Data Relay Server MUST respond with an UPDATE message
that includes the corresponding response parameters: REG_RES, ACK and that includes the corresponding response parameters: REG_RES, ACK and
ECHO_REQUEST_SIGN. In case the Data Relay Server admitted a new ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new
relayed UDP port for the Data Relay Client, the REG_RES parameter relayed UDP port for the Data Relay Client, the REG_RES parameter
MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also
include a RELAYED_ADDRESS parameter describing the relayed UDP port. include a RELAYED_ADDRESS parameter describing the relayed UDP port.
The Data Relay Server MUST also include the Server Reflexive The Data Relay Server MUST also include the Server Reflexive
candidate in a REG_FROM parameter. It is worth mentioning that Data candidate in a REG_FROM parameter. It is worth mentioning that Data
Relay Client MUST activate the UDP port as described in Relay Client MUST activate the UDP port as described in
Section 4.12.1 before it can be used for any ESP relaying. Section 4.12.1 before it can be used for any ESP relaying.
A Data Relay Client may unregister a relayed candidate in two ways. A Data Relay Client may unregister a relayed candidate in two ways.
It can wait for its lifetime to expire or it can explicitly request It can wait for its lifetime to expire or it can explicitly request
skipping to change at page 14, line 10 skipping to change at page 14, line 10
Data Relay Client registers a new server reflexive candidate for each Data Relay Client registers a new server reflexive candidate for each
its peer for the reasons described in Section 4.12.3. The procedures its peer for the reasons described in Section 4.12.3. The procedures
for registering multiple relayed candidates are described in for registering multiple relayed candidates are described in
Section 4.1. Section 4.1.
If a Relay Client has more than one network interface, it can If a Relay Client has more than one network interface, it can
discover additional server reflexive candidates by sending UPDATE discover additional server reflexive candidates by sending UPDATE
messages from each of its interfaces to the Relay Server. Each such messages from each of its interfaces to the Relay Server. Each such
UPDATE message MUST include the following parameters: registration UPDATE message MUST include the following parameters: registration
request (REG_REQ) parameter with Registration Type request (REG_REQ) parameter with Registration Type
CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGN CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_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 paramater). 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
gathering the candidates for a single HIP association; either a one gathering the candidates for a single HIP association; either one
server providing both Control and Data Relay Server functionality, or server providing both Control and Data Relay Server functionality, or
one Control Relay Server and also Data Relay Server if the one Control Relay Server and also Data Relay Server if the
functionality is offered by another server. When the relay service functionality is offered by another server. When the relay service
is split between two hosts, the server reflexive candidate from the is split between two hosts, the server reflexive candidate from the
Control Relay Server SHOULD be used instead of the one provided by Control Relay Server SHOULD be used instead of the one provided by
the Data Relay Server. If a relayed candidate is identical to a host the Data Relay Server. If a relayed candidate is identical to a host
candidate, the relayed candidate must be discarded. NAT64 candidate, the relayed candidate must be discarded. NAT64
considerations in [I-D.ietf-ice-rfc5245bis] apply as well. considerations in [I-D.ietf-ice-rfc5245bis] apply as well.
HIP based connectivity can be utilized by IPv4 applications using HIP based connectivity can be utilized by IPv4 applications using
skipping to change at page 23, line 14 skipping to change at page 23, line 14
traverses successfully the NAT boxes. The message includes the same traverses successfully the NAT boxes. The message includes the same
parameters as in the previous step. It should be noted that the parameters as in the previous step. It should be noted that the
sequence identifier is locally assigned by the Responder, so it can sequence identifier is locally assigned by the Responder, so it can
be different than in the previous step. be different than in the previous step.
In step 3, the Responder has successfully received the previous In step 3, the Responder has successfully received the previous
connectivity check from the Initiator and starts to build a response connectivity check from the Initiator and starts to build a response
message. Since the message from the Initiator included a SEQ, the message. Since the message from the Initiator included a SEQ, the
Responder must acknowledge it using an ACK parameter. Also, the Responder must acknowledge it using an ACK parameter. Also, the
nonce contained in the echo request must be echoed back in an nonce contained in the echo request must be echoed back in an
ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The
Responder includes also a MAPPED_ADDRESS parameter (denoted Responder includes also a MAPPED_ADDRESS parameter (denoted
MAPPED_ADDR in the figure) that contains the transport address of the MAPPED_ADDR in the figure) that contains the transport address of the
Initiator as observed by the Responder (i.e. peer reflexive Initiator as observed by the Responder (i.e. peer reflexive
candidate). This message is successfully delivered to the Initiator, candidate). This message is successfully delivered to the Initiator,
and upon reception the Initiator marks the candidate pair as valid. and upon reception the Initiator marks the candidate pair as valid.
In step 4, the Responder retransmits the connectivity check sent in In step 4, the Responder retransmits the connectivity check sent in
the first step, since it was not acknowledged yet. the first step, since it was not acknowledged yet.
In step 5, the Initiator responds to the previous connectivity check In step 5, the Initiator responds to the previous connectivity check
message from the Responder. The Initiator acknowledges the SEQ message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the parameter from the previous message using ACK parameter and the
ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition, ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In
it includes MAPPED_ADDR parameter that includes the peer reflexive addition, it includes MAPPED_ADDR parameter that includes the peer
candidate. This response message is successfully delivered to the reflexive candidate. This response message is successfully delivered
Responder, and upon reception the Initiator marks the candidate pair to the Responder, and upon reception the Initiator marks the
as valid. candidate pair as valid.
In step 6, despite the two hosts now having valid address candidates, In step 6, despite the two hosts now having valid address candidates,
the hosts still test the remaining address candidates in a similar the hosts still test the remaining address candidates in a similar
way as in the previous steps (due to the use of normal nomination). way as in the previous steps (due to the use of normal nomination).
It should be noted that each connectivity check has a unique sequence It should be noted that each connectivity check has a unique sequence
number in the SEQ parameter. number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates In step 7, the Initiator has completed testing all address candidates
and nominates one address candidate to be used. It sends an UPDATE and nominates one address candidate to be used. It sends an UPDATE
message using the selected address candidates that includes a number message using the selected address candidates that includes a number
of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the
NOMINATE parameter. NOMINATE parameter.
In step 8, the Responder receives the message with NOMINATE parameter In step 8, the Responder receives the message with NOMINATE parameter
from the Initiator. It sends a response that includes the NOMINATE from the Initiator. It sends a response that includes the NOMINATE
parameter in addition to a number of other parameters. The ACK and parameter in addition to a number of other parameters. The ACK and
ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
ECHO_REQUEST_SIGN parameters from previous message from the ECHO_REQUEST_SIGNED parameters from previous message from the
Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGN Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED
parameters in order to receive an acknowledgment from the Responder. parameters in order to receive an acknowledgment from the Responder.
In step 9, the Initiator completes the candidate nomination process In step 9, the Initiator completes the candidate nomination process
by confirming the message reception to the Responder. In the by confirming the message reception to the Responder. In the
confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters
correspond to the SEQ and ECHO_REQUEST_SIGN parameters in the message correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the
sent by the Responder in the previous step. message sent by the Responder in the previous step.
In step 10, the Initiator and Responder can start sending application In step 10, the Initiator and Responder can start sending application
payload over the successfully nominated address candidates. payload over the successfully nominated address candidates.
It is worth noting that if either host has registered a relayed It is worth noting that if either host has registered a relayed
address candidate from a Data Relay Server, the host MUST activate address candidate from a Data Relay Server, the host MUST activate
the address before connectivity checks by sending an UPDATE message the address before connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1. containing PEER_PERMISSION parameter as described in Section 4.12.1.
Otherwise, the Data Relay Server drops ESP packets using the relayed Otherwise, the Data Relay Server drops ESP packets using the relayed
address. address.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
The HITs of the two communicating hosts MUST be used as credentials The HITs of the two communicating hosts MUST be used as credentials
in this protocol (in contrast to ICE which employs username-password in this protocol (in contrast to ICE which employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a association, and a SEQ number in an UPDATE message identifies a
particular connectivity check. particular connectivity check.
All of the connectivity check packets MUST be protected with HMACs All of the connectivity check packets MUST be protected with HMACs
and signatures (even though the illustrations in this specification and signatures (even though the illustrations in this specification
omit them for simplicity). Each connectivity check sent by a host omit them for simplicity). Each connectivity check sent by a host
MUST include a SEQ parameter and ECHO_REQUEST_SIGN parameter, and MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and
correspondingly the peer MUST respond to these using ACK and correspondingly the peer MUST respond to these using ACK and
ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401]. ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401].
The host sending a connectivity check MUST validate that the response The host sending a connectivity check MUST validate that the response
uses the same pair of UDP ports, and drop the packet if this is not uses the same pair of UDP ports, and drop the packet if this is not
the case. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A generate a response, and then continue waiting for the candidates. A
skipping to change at page 26, line 40 skipping to change at page 26, line 40
connectivity checks to the 100 candidate pairs with the highest connectivity checks to the 100 candidate pairs with the highest
priority. priority.
4.6.3. Rules for Concluding Connectivity Checks 4.6.3. Rules for Concluding Connectivity Checks
The controlling agent may find multiple working candidate pairs. To The controlling agent may find multiple working candidate pairs. To
conclude the connectivity checks, it SHOULD nominate the pair with conclude the connectivity checks, it SHOULD nominate the pair with
the highest priority. The controlling agent MUST nominate a the highest priority. The controlling agent MUST nominate a
candidate pair essentially by repeating a connectivity check using an candidate pair essentially by repeating a connectivity check using an
UPDATE message that contains a SEQ parameter (with new sequence UPDATE message that contains a SEQ parameter (with new sequence
number), a ECHO_REQUEST_SIGN parameter, the priority of the candidate number), a ECHO_REQUEST_SIGNED parameter, the priority of the
in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify candidate in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to
conclusion of the connectivity checks. Since the nominated address signify conclusion of the connectivity checks. Since the nominated
pair has already been tested for reachability, the controlled host address pair has already been tested for reachability, the controlled
should be able to receive the message. Upon reception, the host should be able to receive the message. Upon reception, the
controlled host SHOULD select the nominated address pair. The controlled host SHOULD select the nominated address pair. The
response message MUST include a SEQ parameter with a new sequence id, response message MUST include a SEQ parameter with a new sequence id,
acknowledgment of the sequence from the controlling host in an ACK acknowledgment of the sequence from the controlling host in an ACK
parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED
parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the
controlling host and the NOMINATE parameter. After sending this controlling host and the NOMINATE parameter. After sending this
packet, the controlled host can create IPsec security associations packet, the controlled host can create IPsec security associations
using the nominated address candidate for delivering application using the nominated address candidate for delivering application
payload to the controlling host. Since the message from the payload to the controlling host. Since the message from the
controlled host included a new sequence id and echo request for controlled host included a new sequence id and echo request for
skipping to change at page 27, line 42 skipping to change at page 27, line 42
with an R1 message over UDP without including any NAT traversal mode with an R1 message over UDP without including any NAT traversal mode
parameter. The rest of the base exchange follows the procedures parameter. The rest of the base exchange follows the procedures
defined in [RFC7401], except that the control and data plane use UDP defined in [RFC7401], except that the control and data plane use UDP
encapsulation. Here, the use of UDP for NAT traversal is agreed encapsulation. Here, the use of UDP for NAT traversal is agreed
implicitly. This way of operation is still subject to NAT timeouts, implicitly. This way of operation is still subject to NAT timeouts,
and the hosts MUST employ NAT keepalives as defined in Section 4.10. and the hosts MUST employ NAT keepalives as defined in Section 4.10.
When UDP-ENCAPSULATION mode is chosen either explicitly or When UDP-ENCAPSULATION mode is chosen either explicitly or
implicitly, the connectivity checks as defined in this document MUST implicitly, the connectivity checks as defined in this document MUST
not be used. When hosts lose connectivity, they MUST instead utilize not be used. When hosts lose connectivity, they MUST instead utilize
[RFC8046] or [RFC8047] procedures, but with difference that UDP-based [RFC8046] or [RFC8047] procedures, but with the difference being that
tunneling MUST employed for the entire lifetime of the corresponding UDP-based tunneling MUST be employed for the entire lifetime of the
Host Association. corresponding Host Association.
4.7.2. Base Exchange without Connectivity Checks 4.7.2. Base Exchange without Connectivity Checks
It is possible to run a base exchange without any connectivity checks It is possible to run a base exchange without any connectivity checks
as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is
applicable also in the context of this specification, so it is applicable also in the context of this specification, so it is
repeated here for completeness. repeated here for completeness.
In certain network environments, the connectivity checks can be In certain network environments, the connectivity checks can be
omitted to reduce initial connection set-up latency because a base omitted to reduce initial connection set-up latency because a base
skipping to change at page 30, line 39 skipping to change at page 30, line 39
A host may move after base exchange and connectivity checks. A host may move after base exchange and connectivity checks.
Mobility extensions for HIP [RFC8046] define handover procedures Mobility extensions for HIP [RFC8046] define handover procedures
without NATs. In this section, we define how two hosts interact with without NATs. In this section, we define how two hosts interact with
handover procedures in scenarios involving NATs. The specified handover procedures in scenarios involving NATs. The specified
extensions define only simple mobility using a pair of security extensions define only simple mobility using a pair of security
associations, and multihoming extensions are left to be defined in associations, and multihoming extensions are left to be defined in
later specifications. The procedures in this section offer the same later specifications. The procedures in this section 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 Control Relay Server for the peer host for the sake of shows only a Control Relay Server for the peer host for the sake of
simplicity, but also the mobile host may also have a Control Relay simplicity, but the mobile host may also have a Control Relay Server.
Server.
The assumption here is that the two hosts have successfully The assumption here is that the two hosts have successfully
negotiated and chosen the ICE-HIP-UDP mode during the base exchange negotiated and chosen the ICE-HIP-UDP mode during the base exchange
as defined in Section 4.3. The Initiator of the base exchange MUST as defined in Section 4.3. The Initiator of the base exchange MUST
store information that it was the controlling host during the base store information that it was the controlling host during the base
exchange. Similarly, the Responder MUST store information that it exchange. Similarly, the Responder MUST store information that it
was the controlled host during the base exchange. was the controlled host during the base exchange.
Prior to starting the handover procedures with all peer hosts, the Prior to starting the handover procedures with all peer hosts, the
mobile host SHOULD first send its locators in UPDATE messages to its mobile host SHOULD first send its locators in UPDATE messages to its
Control and Data Relay Servers if it has registered to such. It Control and Data Relay Servers if it has registered to such. It
SHOULD wait for all of them to respond for two minutes and then SHOULD wait for all of them to respond for a configurable time, by
continue with the handover procedure without information from the default two minutes, and then continue with the handover procedure
Relay Server that did not respond. As defined in Section 4.1, a without information from the Relay Server that did not respond. As
response message from a Control Relay Server includes a REG_FROM defined in Section 4.1, a response message from a Control Relay
parameter that describes the server reflexive candidate of the mobile Server includes a REG_FROM parameter that describes the server
host to be used in the candidate exchange during the handover. reflexive candidate of the mobile host to be used in the candidate
Similarly, an UPDATE to a Data Relay Server is necessary to make sure exchange during the handover. Similarly, an UPDATE to a Data Relay
the Data Relay Server can forward data to the correct IP address Server is necessary to make sure the Data Relay Server can forward
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. worth noting that the figure corresponds to
figure 3 in [RFC8046], but the difference is that the main UPDATE figure 3 in [RFC8046], but the difference is that the main UPDATE
procedure is carried over the relay and the connectivity is tested procedure is carried over the relay and the connectivity is tested
skipping to change at page 33, line 25 skipping to change at page 33, line 25
RELAY_TO parameter specifies the address of the mobile host where the RELAY_TO parameter specifies the address of the mobile host where the
Control Relay Server should forward the message. Control Relay Server should forward the message.
In step 4, the Control Relay Server receives the message, rewrites In step 4, the Control Relay Server receives the message, rewrites
the destination IP address and UDP port according to the RELAY_TO the destination IP address and UDP port according to the RELAY_TO
parameter, and then forwards the modified message to the mobile host. parameter, and then forwards the modified message to the mobile host.
In step 5, the mobile host receives the UPDATE packet and processes In step 5, the mobile host receives the UPDATE packet and processes
it. The mobile host concludes the handover procedure by it. The mobile host concludes the handover procedure by
acknowledging the received SEQ parameter with an ACK parameter and acknowledging the received SEQ parameter with an ACK parameter and
the ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED parameter. the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED
The mobile host delivers the packet to the HIT of the peer and to the parameter. The mobile host delivers the packet to the HIT of the
address of the HIP relay. The mobile host can start connectivity peer and to the address of the HIP relay. The mobile host can start
checks after this packet. connectivity checks after this packet.
In step 6, HIP relay receives the UPDATE packet and forwards it to In step 6, HIP relay receives the UPDATE packet and forwards it to
the peer host (i.e. relay client). The HIP relay rewrites the the peer host (i.e. Relay Client). The HIP relay rewrites the
destination IP address and port, and then appends a RELAY_FROM destination IP address and port, and then appends a RELAY_FROM
parameter to the message. When the peer host receives this parameter to the message. When the peer host receives this
concluding UPDATE packet, it can initiate the connectivity checks. concluding UPDATE packet, it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according In step 7, the two hosts test for connectivity across NATs according
to procedures described in Section 4.6. The original Initiator of to procedures described in Section 4.6. The original Initiator of
the communications is the controlling and the original Responder is the communications is the controlling and the original Responder is
the controlled host. the controlled host.
In step 8, the connectivity checks are successfully completed and the In step 8, the connectivity checks are successfully completed and the
skipping to change at page 34, line 37 skipping to change at page 34, line 37
could be replayed by an attacker. could be replayed by an attacker.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts MUST send To prevent NAT states from expiring, communicating hosts MUST send
periodic keepalives to other hosts with which they have established a periodic keepalives to other hosts with which they have established a
Host Association every 15 seconds (the so called Tr value in ICE). Host Association every 15 seconds (the so called Tr value in ICE).
Other values MAY be used, but a Tr value smaller than 15 seconds MUST Other values MAY be used, but a Tr value smaller than 15 seconds MUST
NOT be used. Both a Control/Data Relay Client and Control/Data Relay NOT be used. Both a Control/Data Relay Client and Control/Data Relay
Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP- Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-
UDP mode, SHOULD send HIP NOTIFY packets unless they have exchange UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged
some other traffic over the used UDP ports. However, the Data Relay some other traffic over the used UDP ports. However, the Data Relay
Client and Data Relay Server MUST employ only HIP NOTIFY packets in Client and Data Relay Server MUST employ only HIP NOTIFY packets in
order to keep the server reflexive candidates alive. The keepalive order to keep the server reflexive candidates alive. The keepalive
message encoding format is defined in Section 5.3. If the base message encoding format is defined in Section 5.3. If the base
exchange or mobility handover procedure occurs during an extremely exchange or mobility handover procedure occurs during an extremely
slow path, a host (with a Host Association with the peer) MAY also slow path, a host (with a Host Association with the peer) MAY also
send HIP NOTIFY packets every 15 seconds to keep the path active with send HIP NOTIFY packets every 15 seconds to keep the path active with
the recipient. the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
skipping to change at page 37, line 12 skipping to change at page 37, line 12
to the Data Relay Client that created the permission. The Data Relay to the Data Relay Client that created the permission. The Data Relay
Server MUST also implement the similar checks for the reverse Server MUST also implement the similar checks for the reverse
direction (i.e. ESP packets from the Data Relay Client to the peer). direction (i.e. ESP packets from the Data Relay Client to the peer).
Packets without a permission MUST be dropped silently. Packets without a permission MUST be dropped silently.
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
From the viewpoint of a host, its remote peers can have overlapping From the viewpoint of a host, its remote peers can have overlapping
inbound SPI numbers because the IPsec uses also the destination IP inbound SPI numbers because the IPsec uses also the destination IP
address to index the remote peer host. However, a Data Relay Server address to index the remote peer host. However, a Data Relay Server
can represent multiple remote peers, thus masquarading the actual can represent multiple remote peers, thus masquerading the actual
destination. Since a Data Relay Server may have to deal with a destination. Since a Data Relay Server may have to deal with a
multitude of Relay Clients and their peers, a Data Relay Server may multitude of Relay Clients and their peers, a Data Relay Server may
experience collisions in the SPI namespace, thus being unable forward experience collisions in the SPI namespace, thus being unable forward
datagrams to the correct destination. Since the SPI space is 32 bits datagrams to the correct destination. Since the SPI space is 32 bits
and the SPI values should be random, the probability for a and the SPI values should be random, the probability for a
conflicting SPI value is fairly small, but could occur on a busy conflicting SPI value is fairly small, but could occur on a busy Data
server acting as a Responder. The two problematic cases are Relay Server. The two problematic cases are described in this
described in this section. section.
In the first scenario, the SPI collision problems occurs if two hosts In the first scenario, the SPI collision problems occurs if two hosts
have registered to the same Data Relay Server and a third host have registered to the same Data Relay Server and a third host
initiates base exchange with both of them. Here, the two Responders initiates base exchange with both of them. Here, the two Responders
(i.e. Data Relay Clients) claim the same inbound SPI number with the (i.e. Data Relay Clients) claim the same inbound SPI number with the
same Initiator (peer). However, in this case, the Data Relay Server same Initiator (peer). However, in this case, the Data Relay Server
has allocated separate UDP ports for the two Data Relay Clients has allocated separate UDP ports for the two Data Relay Clients
acting now as Responders (as recommended in Section 6.5). When the acting now as Responders (as recommended in Section 6.5). When the
third host sends an ESP packet, the Data Relay Server is able to third host sends an ESP packet, the Data Relay Server is able to
forward the packet to the correct Data Relay Client because the forward the packet to the correct Data Relay Client because the
skipping to change at page 51, line 45 skipping to change at page 51, line 45
traversal mode ICE-HIP-UDP (defined in Section 5.4) This traversal mode ICE-HIP-UDP (defined in Section 5.4) This
specification introduces a new keepalive Notify message type field specification introduces a new keepalive Notify message type field
NAT_KEEPALIVE. NAT_KEEPALIVE.
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC8003] that allow registering with a Data Registration Extension [RFC8003] that allow registering with a Data
Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in
Section 4.1, and performing server reflexive candidate discovery: Section 4.1, and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2).
This document specifies three new error values to be used in HIP This document specifies new error values to be used in HIP NOTIFY
NOTIFY messages as described in Section 5.10: messages as described in Section 5.10:
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED, NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED,
MESSAGE_NOT_RELAYED and SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED. MESSAGE_NOT_RELAYED and SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED.
ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral ICE specification [I-D.ietf-ice-rfc5245bis] discusses "Unilateral
Self-Address Fixing" . This protocol is based on ICE, and thus the Self-Address Fixing" . This protocol is based on ICE, and thus the
same considerations apply also here with one exception: this protocol same considerations apply also here with one exception: this protocol
does not hide binary IP addresses from application-level gateways. does not hide binary IP addresses from application-level gateways.
8. Contributors 8. Contributors
skipping to change at page 55, line 34 skipping to change at page 55, line 34
are syntactical due to the use of a different protocol. In this are syntactical due to the use of a different protocol. In this
section, we describe the differences to the ICE protocol. section, we describe the differences to the ICE protocol.
o ICE operates at the application layer, whereas this protocol o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
o The STUN protocol is not employed. Instead, native ICE-HIP reuses o The STUN protocol is not employed. Instead, native ICE-HIP reuses
the HIP control plane format in order simplify demultiplexing of the HIP control plane format in order simplify demultiplexing of
different protocols. For example, the STUN binding response is different protocols. For example, the STUN binding response is
replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGN replaced with a HIP UPDATE message containing an
parameter and the STUN binding response with a HIP UPDATE message ECHO_REQUEST_SIGNED parameter and the STUN binding response with a
containing an ECHO_RESPONSE_SIGNED parameter as defined in HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as
Section 4.6. defined in Section 4.6.
o The TURN protocol is not utilized. Instead, native ICE-HIP reuses o The TURN protocol is not utilized. Instead, native ICE-HIP reuses
Control Relay Servers for the same purpose. Control Relay Servers for the same purpose.
o ICMP errors may be used in ICE to signal failure. In Native ICE- o ICMP errors may be used in ICE to signal failure. In Native ICE-
HIP protocol, HIP NOTIFY messages are used instead. HIP protocol, HIP NOTIFY messages are used instead.
o Instead of the ICE username fragment and password mechanism for o Instead of the ICE username fragment and password mechanism for
credentials, native ICE-HIP uses the HIT, derived from a public credentials, native ICE-HIP uses the HIT, derived from a public
key, for the same purpose. The username fragments are "transient key, for the same purpose. The username fragments are "transient
skipping to change at page 59, line 32 skipping to change at page 59, line 32
Initiator with another peer host should register a new server Initiator with another peer host should register a new server
reflexive candidate for each local transport address candidate. A reflexive candidate for each local transport address candidate. A
Data Relay Client acting as an Responder should register a new Data Relay Client acting as an Responder should register a new
server reflexive candidate for each { local transport address server reflexive candidate for each { local transport address
candidate, new peer host} pair for the reasons described in candidate, new peer host} pair for the reasons described in
Section 4.12.3. In both cases, the Data Relay Client should Section 4.12.3. In both cases, the Data Relay Client should
request the additional server reflexive candidates by sending request the additional server reflexive candidates by sending
UPDATE messages originating from each of the local address UPDATE messages originating from each of the local address
candidates as described in Section 4.1. As the UPDATE messages candidates as described in Section 4.1. As the UPDATE messages
are originating from an unknown location from the viewpoint of the are originating from an unknown location from the viewpoint of the
Data Relay Server, it must include also a ECHO_REQUEST_SIGN in the Data Relay Server, it must include also a ECHO_REQUEST_SIGNED in
response in order to test for return routability. the response in order to test for return routability.
o Data Relay unregistration: this follows the procedure in Section 4 o Data Relay unregistration: this follows the procedure in Section 4
but the Data Relay Client should unregister using the particular but the Data Relay Client should unregister using the particular
transport address to be unregistered. All transport address pair transport address to be unregistered. All transport address pair
registrations can be unregistered when no RELAYED_ADDRESS registrations can be unregistered when no RELAYED_ADDRESS
parameter is included. parameter is included.
o PEER_PERMISSION parameter: this needs to be extended or additional o PEER_PERMISSION parameter: this needs to be extended or an
parameter is needed to declare the specific local candidate of the additional parameter is needed to declare the specific local
Data Relay Client. Alternatively, the use of the PEER_PERMISSION candidate of the Data Relay Client. Alternatively, the use of the
could be used as a wild card to open permissions for a specific PEER_PERMISSION could be used as a wild card to open permissions
peer to all of the candidates of the Data Relay Client. for a specific peer to all of the candidates of the Data Relay
Client.
o Connectivity checks: the controlling host should be able to o Connectivity checks: the controlling host should be able to
nominate multiple candidates (by repeating step 7 in Figure 5 in nominate multiple candidates (by repeating step 7 in Figure 5 in
Section 4.6 using the additional candidate pairs). Section 4.6 using the additional candidate pairs).
o Keepalives should be sent for all the nominated candidate pairs. o Keepalives should be sent for all the nominated candidate pairs.
Similarly, the Control/Data Relay Client should send keepalives Similarly, the Control/Data Relay Client should send keepalives
from its local candidates to its Control/Data Relay Server from its local candidates to its Control/Data Relay Server
transport addresses. transport addresses.
 End of changes. 30 change blocks. 
66 lines changed or deleted 66 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/