draft-ietf-hip-native-nat-traversal-12.txt   draft-ietf-hip-native-nat-traversal-13.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: December 25, 2016 Ericsson Expires: January 2, 2017 Ericsson
June 23, 2016 July 1, 2016
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-12 draft-ietf-hip-native-nat-traversal-13
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 December 25, 2016. This Internet-Draft will expire on January 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7
4.2. Transport Address Candidate Gathering . . . . . . . . . . 9 4.2. Transport Address Candidate Gathering . . . . . . . . . . 10
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 10
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 11 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 12
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 15
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 15 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 15
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 18 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 18
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 19 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 19
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 19 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 19
4.7.2. Base Exchange without Connectivity Checks . . . . . . 20 4.7.2. Base Exchange without Connectivity Checks . . . . . . 20
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 21 Encapsulation . . . . . . . . . . . . . . . . . . . . 21
4.8. Sending Control Packets after the Base Exchange . . . . . 22 4.8. Sending Control Packets after the Base Exchange . . . . . 22
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 22 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 22
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 25 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 24
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 25 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 25
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 25 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 25
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 25 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 25
4.12.2. Relaying UDP Encapsulated Control and Data Packets . 26 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 26
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 27 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 26
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 28 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 28 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 27
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 29 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 28
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 29 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 28
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 29 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 29
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 30 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 30
5.6. Relay and Registration Parameters . . . . . . . . . . . . 30 5.6. Relay and Registration Parameters . . . . . . . . . . . . 30
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 31 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 31
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 33 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 33
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 33 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 33
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 34 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 34
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 34 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 34
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 35 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 35
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 35 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 46 skipping to change at page 3, line 46
The benefit of using ICE and STUN/TURN is that one can re-use the NAT The benefit of using ICE and STUN/TURN is that one can re-use the NAT
traversal infrastructure already available in the Internet, such as traversal infrastructure already available in the Internet, such as
STUN and TURN servers. Also, some middleboxes may be STUN-aware and STUN and TURN servers. Also, some middleboxes may be STUN-aware and
could be able to do something "smart" when they see STUN being used could be able to do something "smart" when they see STUN being used
for NAT traversal. However, implementing a full ICE/STUN/TURN for NAT traversal. However, implementing a full ICE/STUN/TURN
protocol stack results in a considerable amount of effort and code protocol stack results in a considerable amount of effort and code
which could be avoided by re-using and extending HIP messages and which could be avoided by re-using and extending HIP messages and
state machines for the same purpose. Thus, this document specifies state machines for the same purpose. Thus, this document specifies
an alternative NAT traversal mode that uses HIP messages instead of an alternative NAT traversal mode that uses HIP messages instead of
STUN for the connectivity checks keepalives, and data relaying. This STUN for the connectivity check keepalives and data relaying. This
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],
skipping to change at page 6, line 35 skipping to change at page 6, line 35
Figure 1: Example Network Configuration Figure 1: Example Network Configuration
In the example configuration depicted in Figure 1, both Initiator and In the example configuration depicted in Figure 1, both Initiator and
Responder are behind one or more NATs, and both private networks are Responder are behind one or more NATs, and both private networks are
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
the Responder must be registered with a HIP relay server reachable on the Responder must be registered with a HIP relay server reachable on
the public Internet, and we assume, as a starting point, that the the public Internet, and we assume, as a starting point, that the
Initiator knows both the Responder's Host Identity Tag (HIT) and the Initiator knows both the Responder's Host Identity Tag (HIT) and the
address of one of its relay servers (how the Initiator learns of the address of one of its relay servers (how the Initiator learns of the
Responder's relay server is outside of the scope of this document, Responder's relay server is outside of the scope of this document,
but may be through DNS or another name service). but may be through DNS or another name service). The Responder may
have also registered to a data relay that can forward the data plane
in case NAT penetration fails. It is worth noting that the HIP relay
and data relay functionality may be offered by two separate servers
or the same one.
The first steps are for both the Initiator and Responder to register The first steps are for both the Initiator and Responder to register
with a relay server (need not be the same one) and gather a set of with a relay server (need not be the same one) and gather a set of
address candidates. The hosts may use HIP relay servers (or even address candidates. The hosts may use HIP relay servers (or even
STUN or TURN servers) for gathering the candidates. Next, the HIP STUN or TURN servers) for gathering the candidates. Next, the HIP
base exchange is carried out by encapsulating the HIP control packets base exchange is carried out by encapsulating the HIP control packets
in UDP datagrams and sending them through the Responder's relay in UDP datagrams and sending them through the Responder's relay
server. As part of the base exchange, each HIP host learns of the server. As part of the base exchange, each HIP host learns of the
peer's candidate addresses through the HIP offer/answer procedure peer's candidate addresses through the HIP offer/answer procedure
embedded in the base exchange, which follows closely the ICE embedded in the base exchange, which follows closely the ICE
skipping to change at page 7, line 10 skipping to change at page 7, line 15
Once the base exchange is completed, two HIP hosts have established a Once the base exchange is completed, two HIP hosts have established a
working communication session (for signaling) via a HIP relay server, working communication session (for signaling) via a HIP relay server,
but the hosts still have to find a better path, preferably without a but the hosts still have to find a better path, preferably without a
HIP data relay, for the ESP data flow. For this, connectivity checks HIP data relay, for the ESP data flow. For this, connectivity checks
are carried out until a working pair of addresses is discovered. At are carried out until a working pair of addresses is discovered. At
the end of the procedure, if successful, the hosts will have the end of the procedure, if successful, the hosts will have
established a UDP-based tunnel that traverses both NATs, with the established a UDP-based tunnel that traverses both NATs, with the
data flowing directly from NAT to NAT or via a HIP data relay server. data flowing directly from NAT to NAT or via a HIP data relay server.
At this point, also the HIP signaling can be sent over the same At this point, also the HIP signaling can be sent over the same
address/port pair, and is demultiplexed from IPsec as described in address/port pair, and is demultiplexed from IPsec as described in
the UDP encapsulation standard for IPsec [RFC3948] Finally, the two the UDP encapsulation standard for IPsec [RFC3948]. Finally, the two
hosts send NAT keepalives as needed in order keep their UDP-tunnel hosts send NAT keepalives as needed in order keep their UDP-tunnel
state active in the associated NAT boxes. state active in the associated NAT boxes.
If either one of the hosts knows that it is not behind a NAT, hosts If either one of the hosts knows that it is not behind a NAT, hosts
can negotiate during the base exchange a different mode of NAT can negotiate during the base exchange a different mode of NAT
traversal that does not use HIP connectivity checks, but only UDP traversal that does not use HIP connectivity checks, but only UDP
encapsulation of HIP and ESP. Also, it is possible for the Initiator encapsulation of HIP and ESP. Also, it is possible for the Initiator
to simultaneously try a base exchange with and without UDP to simultaneously try a base exchange with and without UDP
encapsulation. If a base exchange without UDP encapsulation encapsulation. If a base exchange without UDP encapsulation
succeeds, no HIP connectivity checks or UDP encapsulation of ESP are succeeds, no HIP connectivity checks or UDP encapsulation of ESP are
skipping to change at page 10, line 31 skipping to change at page 10, line 37
requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by
IANA: 4]) from each of the interfaces to a HIP relay server. When a IANA: 4]) from each of the interfaces to a HIP relay server. When a
HIP relay server receives a registration request with HIP relay server receives a registration request with
CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter, CANDIDATE_DISCOVERY type, it MUST add a REG_FROM parameter,
containing the same information as if this was a relay registration, containing the same information as if this was a relay registration,
to the response. This request type SHOULD NOT create any state at to the response. This request type SHOULD NOT create any state at
the HIP relay server. the HIP relay server.
Gathering of candidates MAY also be performed as specified in Gathering of candidates MAY also be performed as specified in
Section 4.2 of [RFC5770] if STUN servers are available, or if the Section 4.2 of [RFC5770] if STUN servers are available, or if the
host has just a single interface and no TURN or HIP data relay host has just a single interface and no STUN or HIP data relay
servers are available. servers are available.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical (as defined in document. As the parameter is non-critical (as defined in
Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which
means that the host does not support or is not willing to use these means that the host does not support or is not willing to use these
skipping to change at page 15, line 21 skipping to change at page 15, line 21
4.6. Connectivity Checks 4.6. Connectivity Checks
When the Initiator and Responder complete the base exchange through When the Initiator and Responder complete the base exchange through
the HIP relay, both of them employ the IP address of the relay as the the HIP relay, both of them employ the IP address of the relay as the
destination address for the packets. This address MUST NOT be used destination address for the packets. This address MUST NOT be used
as a destination for ESP traffic unless the HIP relay supports also as a destination for ESP traffic unless the HIP relay supports also
ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was ESP data relaying. When NAT traversal mode with ICE-HIP-UDP was
successfully negotiated and selected, the Initiator and Responder successfully negotiated and selected, the Initiator and Responder
MUST start the connectivity checks in order to attempt to obtain MUST start the connectivity checks in order to attempt to obtain
direct end-to-end connectivity through NAT devices. direct end-to-end connectivity through NAT devices. It is worth
noting that the connectivity checks MUST be completed even though no
ESP_TRANSFORM would be negotiated and selected.
The connectivity checks follow the ICE methodology [MMUSIC-ICE], but The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
UDP encapsulated HIP control messages are used instead of ICE UDP encapsulated HIP control messages are used instead of ICE
messages. Only normal connectivity checks can be used because messages. Only normal connectivity checks can be used because
aggressive connectivity checks are deprecated. The Initiator MUST aggressive connectivity checks are deprecated. The Initiator MUST
take the role of controlling host and the Responder acts as the take the role of controlling host and the Responder acts as the
controlled host. The protocol follows standard HIP UPDATE sending controlled host. The protocol follows standard HIP UPDATE sending
and processing rules as defined in section 6.11 and 6.12 in and processing rules as defined in section 6.11 and 6.12 in
[RFC7401], but some new parameters are introduced: [RFC7401], but some new parameters are introduced:
CANDIDATE_PRIORITY, MAPPED_ADDR and NOMINATE. CANDIDATE_PRIORITY, MAPPED_ADDR and NOMINATE.
4.6.1. Connectivity Check Procedure 4.6.1. Connectivity Check Procedure
Figure 5 illustrates connectivity checks in a simplified scenario, Figure 5 illustrates connectivity checks in a simplified scenario,
where the Initiator and Responder have only a single candidate pair where the Initiator and Responder have only a single candidate pair
to check. Typically, NATs drop messages messages until both sides to check. Typically, NATs drop messages until both sides have sent
have sent messages using the same port pair. In this scenario, the messages using the same port pair. In this scenario, the Responder
Responder sends a connectivity check first but the NAT of the sends a connectivity check first but the NAT of the Initiator drops
Initiator drops it. However, the connectivity check from the it. However, the connectivity check from the Initiator reaches the
Initiator reaches the Responder because it uses the same port pair as Responder because it uses the same port pair as the first message.
the first message.
Initiator NAT1 NAT2 Responder Initiator NAT1 NAT2 Responder
| | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | |
| | ECHO_REQ_SIGN)) | | | | ECHO_REQ_SIGN)) | |
| X<-----------------------------------+----------------+ | X<-----------------------------------+----------------+
| | | | | | | |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | |
+-------------+------------------------------------+--------------->| +-------------+------------------------------------+--------------->|
| | | | | | | |
| 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | 3. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, |
skipping to change at page 18, line 16 skipping to change at page 18, line 16
Otherwise, the relay drops ESP packets using the relayed address. Otherwise, the relay drops ESP packets using the relayed address.
4.6.2. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
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 omitted them for and signatures (even though the illustrations omitted them for
simplicity). To provide strong replay protection, for each pair of simplicity). To provide strong replay protection, for each pair of
address candidates, both the Initiator and Responder MUST send a send address candidates, both the Initiator and Responder MUST send a send
a nonce to each other for signing using the ECHO_REQUEST_SIGNED a nonce to each other for signing using the ECHO_REQUEST_SIGNED
parameter (that then has to be echoed back by the recipient). parameter (that then has to be echoed back by the recipient).
Similarly, the SEQ parameter enforces the the recipient to Similarly, the SEQ parameter enforces the recipient to acknowledge a
acknowledge a received message. Effectively these two mechanisms received message. Effectively these two mechanisms combined result
combined result in a secure three way packet exchange that tests both in a secure three way packet exchange that tests both sides for
sides for return routability. return routability.
[RFC7401] states that UPDATE packets have to include either a SEQ or [RFC7401] states that UPDATE packets have to include either a SEQ or
ACK parameter (or both). According to the RFC, each SEQ parameter ACK parameter (or both). According to the RFC, each SEQ parameter
should be acknowledged separately. In the context of NATs, this should be acknowledged separately. In the context of NATs, this
means that some of the SEQ parameters sent in connectivity checks means that some of the SEQ parameters sent in connectivity checks
will lost or arrive out of order. From the viewpoint of the will lost or arrive out of order. From the viewpoint of the
recipient, this is not a problem since the the recipient will just recipient, this is not a problem since the recipient will just
"blindly" acknowledge the SEQ. However, the sender needs to be "blindly" acknowledge the SEQ. However, the sender needs to be
prepared for lost sequence identifiers and ACKs parameters that prepared for lost sequence identifiers and ACKs parameters that
arrive out of order. arrive out of order.
As specified in [RFC7401], an ACK parameter may acknowledge multiple As specified in [RFC7401], an ACK parameter may acknowledge multiple
sequence identifiers. While the examples in the previous sections do sequence identifiers. While the examples in the previous sections do
not illustrate such functionality, it is also permitted when not illustrate such functionality, it is also permitted when
employing ICE-HIP-UDP mode. employing ICE-HIP-UDP mode.
In ICE-HIP-UDP mode, a retransmission of a connectivity checks SHOULD In ICE-HIP-UDP mode, a retransmission of a connectivity checks SHOULD
skipping to change at page 22, line 38 skipping to change at page 22, line 38
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 [I-D.ietf-hip-rfc5206-bis] define
handover procedures without NATs. In this section, we define how two handover procedures without NATs. In this section, we define how two
hosts interact handover procedures in scenarios involving NATs. The hosts interact with handover procedures in scenarios involving NATs.
specified extensions define only simple mobility using a pair of The specified extensions define only simple mobility using a pair of
security associations, and multihoming extensions are left to be security associations, and multihoming extensions are left to be
defined in later specifications. defined in later specifications.
We assume that the two hosts have successfully negotiated and chosen We assume that the two hosts have successfully negotiated and chosen
the ICE-HIP-UDP mode during the base exchange as defined in the ICE-HIP-UDP mode during the base exchange as defined in
Section 4.3. The Initiator of the base exchange MUST store Section 4.3. The Initiator of the base exchange MUST store
information that it was the controlling host during the base 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.
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 HIP relay belongs to the peer all of its peers. In the figure, the HIP relay belongs to the peer
host, i.e., the peer host is a relay client for the HIP relay. It is host, i.e., the peer host is a relay client for the HIP relay. Next,
worth noting that the figure corresponds to figure 3 in Figure 6, but we describe the procedure in the figure in detail.
the difference is that the main UPDATE procedure is carried over the
relay and the connectivity is tested separately. Next, we describe
the procedure in the figure in detail.
Mobile Host HIP relay Peer Host Mobile Host HIP relay 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, ACK, |
| | ACK, ECHO_REQ_SIGN)) | | | ECHO_REQ_SIGN)) |
| 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ | 4. UDP(UPDATE(ESP_INFO, ACK, |<-------------------------------+
| ACK, ECHO_REQ_SIGN, | | | ECHO_REQ_SIGN, | |
| RELAY_TO)) | | | RELAY_TO)) | |
|<---------------------------------+ | |<---------------------------------+ |
| | | | | |
| 5. UDP(UPDATE(ACK, | | | 5. connectivity checks over UDP |
| ECHO_RESP_SIGN)) | |
+--------------------------------->| 6. UDP(UPDATE(ACK, |
| | ECHO_RESP_SIGN, |
| | RELAY_FROM)) |
| +------------------------------->|
| | |
| 7. connectivity checks over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
| 8. ESP data over UDP | | 6. ESP data over UDP |
+<----------------------------------------------------------------->+ +<----------------------------------------------------------------->+
| | | | | |
Figure 6: HIP UPDATE procedure Figure 6: HIP UPDATE procedure
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
skipping to change at page 24, line 22 skipping to change at page 24, line 12
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
SPI and NEW SPI parameters both contain the pre-existing incoming SPI and NEW SPI parameters both contain the pre-existing incoming
SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGN parameters to SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGN parameters to
be acknowledged by the mobile host. The message acknowledges the SEQ be acknowledged by the mobile host. The message acknowledges the SEQ
parameter of the earlier message with an ACK parameter. parameter of the earlier message with an ACK parameter. After this
step, the peer host can initiate the connectivity checks.
In step 4, the HIP relay receives the message, rewrites the In step 4, the HIP relay receives the message, rewrites the
destination IP address, appends an RELAY_TO parameter and forwards destination IP address, appends an RELAY_TO parameter and forwards
the modified message to the mobile host. the modified message to the mobile host. When mobile host has
processed the message successfully, it can initiate the connectivity
In step 5, the mobile host receives the UPDATE packet from the peer checks.
and processes it. It concludes the information exchange by
acknowledging the received SEQ parameter with an ACK parameter and
the ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGN parameter.
The mobile host delivers the packet to the HIT of the peer and to the
address of the HIP relay. The mobile host can start connectivity
checks after this packet.
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
destination IP address and appends a RELAY_FROM parameter to the
message. When the peer host receives this concluding UPDATE packet,
it can initiate the connectivity checks.
In step 7, the two hosts test for connectivity across NATs according In step 5, 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 6, the connectivity checks are successfully completed and the
controlling host has nominated one address pair to be used. The controlling host has nominated one address pair to be used. The
hosts set up security associations to deliver the application hosts set up security associations to deliver the application
payload. payload.
If either host has registered a relayed address candidate from a data If either host has registered a relayed address candidate from a data
relay, the host MUST reactivate the address before connectivity relay, the host MUST reactivate the address before connectivity
checks by sending an UPDATE message containing PEER_PERMISSION checks by sending an UPDATE message containing PEER_PERMISSION
parameter as described in Section 4.12.1. Otherwise, the relay drops parameter as described in Section 4.12.1. Otherwise, the relay drops
ESP packets using the relayed address. ESP packets using the relayed address.
skipping to change at page 25, line 42 skipping to change at page 25, line 20
CLOSE_ACK. All packets are protected using HMACs and signatures, and CLOSE_ACK. All packets are protected using HMACs and signatures, and
the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to
protect against replay attacks. protect against replay attacks.
The same procedure for closing HIP associations applies also here, The same procedure for closing HIP associations applies also here,
but the messaging occurs using the UDP encapsulated tunnel that the but the messaging occurs using the UDP encapsulated tunnel that the
two hosts employ. A host sending the CLOSE message SHOULD first send two hosts employ. A host sending the CLOSE message SHOULD first send
the message over a direct link. After a number of retransmissions, the message over a direct link. After a number of retransmissions,
it MUST send over a HIP relay of the recipient if one exists. The it MUST send over a HIP relay of the recipient if one exists. The
host receiving the CLOSE message directly without a relay SHOULD host receiving the CLOSE message directly without a relay SHOULD
respond directly. The the CLOSE message came via a relay, it SHOULD respond directly. The CLOSE message came via a relay, it SHOULD
respond using the same relay. respond using the same relay.
4.12. Relaying Considerations 4.12. Relaying Considerations
4.12.1. Forwarding Rules and Permissions 4.12.1. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before the data relay forwards any ESP data packets from a peer to a before the data relay forwards any ESP data packets from a peer to a
registered host (or the other direction), the client MUST set a registered host (or the other direction), the client MUST set a
permission for the peer's address. The permissions also install a permission for the peer's address. The permissions also install a
skipping to change at page 26, line 37 skipping to change at page 26, line 15
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
permissions 1 minute before the expiration when the permission is permissions 1 minute before the expiration when the permission is
still needed. still needed.
The relayed address MUST be activated with the PEER_PERMISSION The relayed address MUST be activated with the PEER_PERMISSION
parameter both after the base exchange and after a handover. Unless parameter both after the base exchange and after a handover. Unless
activated, the data relay MUST drop all ESP packets. activated, the data relay MUST drop all ESP packets.
4.12.2. Relaying UDP Encapsulated Control and Data Packets 4.12.2. HIP Data Relay and Relaying of Control Packets
When a HIP data relay accepts to relay UDP encapsulated ESP between a When a HIP data relay accepts to relay UDP encapsulated ESP between a
registered host and its peer, the relay opens a UDP port (relayed registered host and its peer, the relay opens a UDP port (relayed
address) for this purpose as described in Section 4.1. This port can address) for this purpose as described in Section 4.1. This port can
be used for delivering also control packets because connectivity be used for delivering also control packets because connectivity
checks also cover the path through the data relay. If the data relay checks also cover the path through the data relay. If the data relay
receives a UDP encapsulated HIP control packet on that port, it MUST receives a UDP encapsulated HIP control packet on that port, it MUST
forward the packet to the registered host and add a RELAY_FROM forward the packet to the registered host and add a RELAY_FROM
parameter to the packet as if the data relay was acting as a HIP parameter to the packet as if the data relay was acting as a HIP
relay server. When the registered host replies to a control packet relay server. When the registered host replies to a control packet
skipping to change at page 27, line 27 skipping to change at page 27, line 4
4.12.3. Handling Conflicting SPI Values 4.12.3. Handling Conflicting SPI Values
The inbound SPI values of the registered clients should be unique so The inbound SPI values of the registered clients should be unique so
that a data relay can properly demultiplex incoming packets from peer that a data relay can properly demultiplex incoming packets from peer
hosts to the correct registered clients. Vice versa, the inbound hosts to the correct registered clients. Vice versa, the inbound
SPIs of the peer hosts should be unique for the same reason. These SPIs of the peer hosts should be unique for the same reason. These
two cases are discussed in this section separately. two cases are discussed in this section separately.
In first case, the SPI collision problem occurs when two Initiators In first case, the SPI collision problem occurs when two Initiators
run a base exchange to the same Responder (i.e. registered host), and run a base exchange to the same Responder (i.e. registered host), and
both the Initiators claim the same inbound SPI. Upon receiving an I2 both the Initiators claim the same inbound SPI. This is not a
with a colliding SPI, the Responder MUST not include the relayed problem for Responder since the two Initiators can be distinguished
address in the R2 message because the data relay would not be able by their transport addresses. However, it is an issue for the data
demultiplex the related ESP packet to the correct Initiator. Since relay because the it cannot demultiplex packets from the Initiator to
the SPI space is 32 bits and the SPI values should be random, the the correct Responder. Thus, upon receiving an I2 with a colliding
probability for a conflicting SPI value is fairly small. However, a SPI, the Responder MUST NOT include the relayed address candidate in
registered host with many peers MAY proactively decrease the odds of the R2 message because the data relay would not be able demultiplex
a conflict by registering to multiple data relays. The described the related ESP packet to the correct Initiator. The same applies
collision scenario can be avoided if the Responder delivers a new also the handover procedure; the registered host MUST NOT include the
relayed address candidate upon SPI collisions. Each relayed address relayed address candidate when sending its new locator set in an
has a separate UDP port reserved to it, so the relay can demultiplex UPDATE to its peer if it would cause a SPI conflict with another
properly conflicting SPIs of the Initiators based on the SPI and port peer. Since the SPI space is 32 bits and the SPI values should be
number towards the correct Responder. random, the probability for a conflicting SPI value is fairly small.
However, a registered host with many peers MAY proactively decrease
the odds of a conflict by registering to multiple data relays. The
described collision scenario can be avoided if the Responder delivers
a new relayed address candidate upon SPI collisions. Each relayed
address has a separate UDP port reserved to it, so the relay can
demultiplex properly conflicting SPIs of the Initiators based on the
SPI and port number towards the correct Responder.
In the second case, the SPI collision problems occurs if two hosts In the second case, the SPI collision problems occurs if two hosts
have registered to the same data relay and a third host initiates have registered to the same data relay and a third host initiates
base exchange with both of them. In this case, the data relay has base exchange with both of them. In this case, the data relay has
allocated separate UDP ports for the two registered hosts acting now allocated separate UDP ports for the two registered hosts acting now
as Responders. When the Responders send identical SPI values in as Responders. When the Responders send identical SPI values in
their I2 messages via the relay, it can properly demultiplex it to their I2 messages via the relay, it can properly demultiplex it to
the correct Responder because the UDP ports are different. the correct Responder because the UDP ports are different.
5. Packet Formats 5. Packet Formats
skipping to change at page 29, line 21 skipping to change at page 29, line 11
The keepalives are either HIP NOTIFY packets as specified in The keepalives are either HIP NOTIFY packets as specified in
[RFC7401] or ICMPv6 packets inside the ESP tunnel. [RFC7401] or ICMPv6 packets inside the ESP tunnel.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from The format of NAT traversal mode parameter is borrowed from
[RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar
to the format of the ESP_TRANSFORM parameter in [RFC7402] and is to the format of the ESP_TRANSFORM parameter in [RFC7402] and is
shown in Figure 8. This specification defines traversal mode shown in Figure 8. This specification defines traversal mode
identifier for ICE-HIP-UDP. The identifier RESERVED is reserved for identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
future use. Future specifications may define more traversal modes. [RFC5770]. The identifier named RESERVED is reserved for future use.
Future specifications may define more traversal modes.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 | | Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 45 skipping to change at page 29, line 36
Type 608 Type 608
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
Mode ID defines the proposed or selected NAT traversal mode(s) Mode ID defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined: The following NAT traversal mode IDs are defined:
ID name Value ID name Value
RESERVED 0 RESERVED 0
UDP-ENCAPSULATION 1
ICE-HIP-UDP 3 ICE-HIP-UDP 3
Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that
there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. Conversely, a recipient MUST be prepared to handle parameter. Conversely, a recipient MUST be prepared to handle
received NAT traversal mode parameters that contain more than six received NAT traversal mode parameters that contain more than six
Mode IDs by accepting the first six Mode IDs and dropping the rest. Mode IDs by accepting the first six Mode IDs and dropping the rest.
The limited number of Mode IDs sets the maximum size of the The limited number of Mode IDs sets the maximum size of the
NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order,
most preferred mode(s) first. most preferred mode(s) first.
Implementations conforming to this specification MUST implement both
UDP-ENCAPSULATION and ICE-HIP-UDP modes.
5.5. Connectivity Check Transaction Pacing Parameter 5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING is a new parameter, and it shown in Figure 9 The TRANSACTION_PACING is a new parameter, and it shown in Figure 9
contains only the connectivity check pacing value, expressed in contains only the connectivity check pacing value, expressed in
milliseconds, as a 32-bit unsigned integer. milliseconds, as a 32-bit unsigned integer.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
skipping to change at page 40, line 13 skipping to change at page 40, line 13
the RFC. the RFC.
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for
the excellent work on ICE. In addition, the authors would like to the excellent work on ICE. In addition, the authors would like to
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian
Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka
Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom
Jani Hautakorpi for their comments to [RFC5770], which is the basis Henderson, and Jani Hautakorpi for their comments to [RFC5770], which
for this document. is the basis for this document.
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
 End of changes. 31 change blocks. 
87 lines changed or deleted 83 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/