< draft-ietf-hip-nat-traversal-00.txt   draft-ietf-hip-nat-traversal-01.txt >
HIP Working Group V. Schmitt HIP Working Group M. Komu, Ed.
Internet-Draft NEC Internet-Draft HIIT
Expires: May 25, 2007 A. Pathak Intended status: Standards Track S. Schuetz
IIT Kanpur Expires: September 6, 2007 M. Stiemerling
M. Komu
HIIT
L. Eggert
M. Stiemerling
NEC NEC
November 21, 2006 L. Eggert
Nokia
A. Pathak
IIT Kanpur
March 5, 2007
HIP Extensions for the Traversal of Network Address Translators HIP Extensions for the Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-00 draft-ietf-hip-nat-traversal-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies extensions to Host Identity Protocol (HIP) to This document specifies extensions to Host Identity Protocol (HIP) to
support traversal of Network Address Translator (NAT) middleboxes. support traversal of Network Address Translator (NAT) middleboxes.
The traversal mechanism tunnels HIP control and data traffic over UDP The traversal mechanism tunnels HIP control and data traffic over UDP
and enables HIP initiators which MAY be behind NATs to contact HIP and enables HIP initiators which MAY be behind NATs to contact HIP
responders which MAY be behind another NAT. responders which MAY be behind another NAT.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4
3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 4 3. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 5 3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 6
3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 5 3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 6
3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 6 3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 7
3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 7 3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 8
3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 7 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 8
3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 7 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 8
3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 8 3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 10
3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 8 3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 10
3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 9 3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 11
3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 12 3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 13
3.3.3. Use of the Rendezvous Service when only the 3.3.3. Use of the Rendezvous Service when only the
Initiator Is Behind NAT . . . . . . . . . . . . . . . 14 Initiator is Behind NAT . . . . . . . . . . . . . . . 15
3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 15 3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 17
3.4.1. Rendezvous Client Registration From Behind NAT . . . . 15 3.4.1. Rendezvous Client Registration From Behind NAT . . . . 17
3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 17 3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 18
3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 19 3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 20
3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 21 3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 22
3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 21 3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 22
3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 23 3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 25
3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 25 3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 26
3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 26 3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 27
3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 27 3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 29
3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 27 3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4. Security Considerations . . . . . . . . . . . . . . . . . . . 30
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 4.1. A Difference to RFC3948 . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. Rendezvous and Responder Privacy . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Document Revision History . . . . . . . . . . . . . . 31 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Appendix A. Document Revision History . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) describes a new communication The Host Identity Protocol (HIP) describes a new communication
mechanism for Internet hosts [RFC4423]. It introduces a new mechanism for Internet hosts [RFC4423]. It introduces a new
namespace and protocol layer between the network and transport layers namespace and protocol layer between the network and transport layers
that decouples the identifier and locator roles to support e.g. that decouples the identifier and locator roles to support e.g.
mobility and multihoming in the Internet architecture. mobility and multihoming in the Internet architecture.
The HIP protocol [I-D.ietf-hip-base] cannot operate across Network The HIP protocol [I-D.ietf-hip-base] cannot operate across Network
Address Translator (NAT) middleboxes, as described in Address Translator (NAT) middleboxes, as described in
[I-D.irtf-hiprg-nat]. Several different flavors of NATs exist [I-D.irtf-hiprg-nat]. This document specifies how HIP can traverse
[RFC2663]. This document describes HIP extensions for the traversal through legacy NAT middleboxes that are not aware of HIP or ESP. The
of both Network Address Translator (NAT) and Network Address and Port mechanisms defined in this document do not assume that the NAT
Translator (NAPT) middleboxes. It generally uses the term NAT to middleboxes are reconfigured, as long as they allow UDP traffic.
refer to both types of middleboxes, unless it needs to distinguish
between the two types. The use of HIP in NAT traversal has also some additional benefits
provided by the new namespace. First, it is possible to address
hosts behind a single NAT middlebox in a relatively simple way. The
NAT middlebox translates the locators, but the Host Identifiers and
ESP SPIs remain the same. Second, multiple services can share the
same transport layer port number behind a single NAT. There is no
multiplexing issue as long as these services have different Host
Identifiers.
Several different flavors of NATs exist [RFC2663]. This document
describes HIP extensions for the traversal of both Network Address
Translator (NAT) and Network Address and Port Translator (NAPT)
middleboxes. It generally uses the term NAT to refer to both types
of middleboxes, unless it needs to distinguish between the two types.
Three basic cases exist for NAT traversal. In the first case, only Three basic cases exist for NAT traversal. In the first case, only
the initiator of a HIP base exchange is located behind a NAT. In the the initiator of a HIP base exchange is located behind a NAT. In the
second case, only the responder of a HIP base exchange is located second case, only the responder of a HIP base exchange is located
behind a NAT. The respective peer host is assumed to be in the behind a NAT. The respective peer host is assumed to be located at a
public Internet in both cases. In the third case, both parties are publicly reachable address in both cases. In the third case, both
located behind (different) NATs. This document describes extensions parties are located behind (different) NATs. This document describes
for the first case in Section 3.3, for the second case in Section 3.4 extensions for the first case in Section 3.3, for the second case in
and in Section 3.5 for the third case. Section 3.4 and in Section 3.5 for the third case.
The mechanisms described here also cover use of rendezvous server The mechanisms described here also cover use of rendezvous server
from NATted environments. The use rendezvous server MUST be used from NATted environments. The rendezvous server MUST be used when
when the responder is behind a NAT and the rendezvous MUST be located the responder is behind a NAT because otherwise successful NAT
in a public network. Chaining of NAT enabled rendezvous servers is traversal cannot be guaranteed. The rendezvous server MUST be
not possible, altough there may be other kind of rendezvous servers located in a publicly addressable location. Cascading of multiple
on the path. The limitation of the described rendezvous mechanisms NAT enabled rendezvous servers is not possible, although there may be
is that it requires NAT boxes supporting both endpoint independent other kind of rendezvous servers on the path. The NAT middleboxes
mapping [I-D.srisuresh-behave-p2p-state]. MUST support address independent mapping in the case where both hosts
are behind NAT devices. Otherwise, some other external relaying
mechanism MUST be used. Endpoint independent filtering is not
required in any of the cases. The NAT categories are defined in
[I-D.srisuresh-behave-p2p-state].
The mechanisms described in this document are based on encapsulating The mechanisms described in this document are based on encapsulating
both the control and data traffic in UDP in order to traverse NAT(s). both the control and data traffic in UDP in order to traverse NAT(s).
The data traffic is assumed to be ESP. Other types of data traffic The data traffic is assumed to be ESP. Other types of data traffic
are out of scope. are out of scope for this document. The responder listens at a fixed
UDP port number for incoming HIP control packets. The port number
can be manually configured to the NAT to allow passing incoming
traffic directly to the host behind the NAT (port forwarding). The
benefit of such a configuration is that it does not require any
rendezvous server for the host behind the NAT. Although this
document does not prevent such configurations, it is out of scope
because of two drawbacks. First, it allows only a single responder
behind the NAT box. Second, manual configuration through several NAT
devices may be difficult or administratively prohibited.
The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm], The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm],
allow HIP hosts to change network location during the lifetime of a allow HIP hosts to change network location during the lifetime of a
HIP association. Consequently, hosts need to start using the HIP association. Consequently, hosts need to start using the
proposed NAT traversal mechanisms after a mobility event relocates proposed NAT traversal mechanisms after a mobility event relocates
one or both peers behind a NAT. They may also stop using the one or both peers behind a NAT. They may also stop using the
proposed mechanisms if they both relocate to the public Internet. proposed mechanisms if they both move to publicly addressable
locations.
Finally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in [RFC2119].
[RFC2119].
2. Detecting NATs 2. Detecting NATs
In order to know whether to use the NAT traversal mechanisms, HIP In order to know whether to use the NAT traversal mechanisms, HIP
hosts need to detect presence of NAT middleboxes between them. This hosts need to detect the presence and type of NAT middleboxes along
document does not describe any NAT detection mechanism but rather the path to their peer hosts. This document does not describe any
assumes the NAT is detected using some external mechanism. Hence, no new NAT detection mechanism but rather assumes that the NAT is
special HIP parameters are required in HIP control messages to detect detected using some external mechanism. Hence, no special HIP
NATs. The NAT detection MUST occur prior to base exchange, or after parameters are required in HIP control messages to detect NATs. The
node movement, prior to sending UPDATE messages. NAT detection MUST occur prior to a base exchange, after node
movement and prior to sending UPDATE messages.
For example, STUN [RFC3489] offers a generic mechanism using which a For example, STUN [RFC3489] offers a generic mechanism for detecting
host behind NAT can detect the presence of NAT and type of NAT both the presence and type of a NAT. In STUN, the host contacts a
present. In STUN, the host contacts a STUN server which is located STUN server that is always located at a publicly reachable address.
always in public network and the STUN server replies back letting the The STUN server replies back and provides information on the NAT
host know whether the host is behind NAT or in public network. STUN presence and type.
can be used to detect NATs in all but one case where both of the host
are behind the same NAT. This is commonly referred as the Hairpin
translation [I-D.srisuresh-behave-p2p-state] . The hairpin
translation poses an unnecessary overhead in terms of UDP processing
of packets and routing of packets through the NAT despite the hosts
being located within the same network.
As a solution to the hairpin problem, an implementation MAY choose A limitation of STUN is that it cannot detect whether the responder
first to send I1 packets without UDP encapsulation and wait for the is behind the same NAT as the initiator. This can lead to an
response for an implementation specific time. If the initiator does unoptimal route through the public address of the NAT, especially in
not get a reply from the responder, it then can start retransmitting combination the rendezvous extensions that are described later in
I1 packets UDP encapsulated. This approach solves the hairpin this document. In the worst case, the NAT may not be able to forward
problem, but incurs extra latency for the HIP connection. the traffic unless it supports "hairpin translation" as described in
[I-D.srisuresh-behave-p2p-state].
3. HIP Across NATs To guarantee connectivity behind the same NAT, the initiator MUST
detect the hairpin support of the NAT as described in
[I-D.ietf-behave-nat-behavior-discovery]. If the NAT supports
hairpinning, the initiator uses the UDP encapsulation procedures
described in the following sections. If the NAT does not support
hairpinning, the initiator SHOULD broadcast a single I1 packet
without UDP encapsulation to the local network. The responder MUST
process the I1 according to [I-D.ietf-hip-base]. However, the
initiator MUST continue with the UDP encapsulation mechanisms
described in the following sections because the responder may
actually be located in a different network.
HIP based communications between two hosts consists effectively of HIP-aware NATs are not in the scope of this document. In the future,
HIP control traffic and ESP encrypted data traffic. Before ESP data it may be possible to use some other protocol that is launched in
traffic can be sent, the hosts send HIP control messages to negotiate parallel with e.g. STUN to detect the presence of HIP aware NATs.
algorithms and exchange keys. After this, the hosts can start When the path between the initiator and responder consists of HIP
sending encrypted ESP data traffic. aware NATs, the extensions defined in this document SHOULD NOT be
used.
The HIP based communications defined in [I-D.ietf-hip-base] works 3. HIP Across NATs
well in public networks. However, this does not work with some
legacy NATs which just drop HIP control traffic and ESP data traffic. The HIP base exchange as defined in [I-D.ietf-hip-base] works well in
As a solution for this, we propose UDP encapsulation of control and public networks. However, this does not work with some legacy NATs
data traffic using a specific scheme described in this document. The that are not able to multiplex HIP or ESP traffic. As a result, such
NATs just drop HIP control traffic and/or ESP data traffic. As a
solution for this, we propose UDP encapsulation of control and data
traffic using a specific scheme described in this document. The
scheme also allows hosts behind NATs to act as servers. scheme also allows hosts behind NATs to act as servers.
[RFC3948] describes UDP encapsulation of IPsec ESP transport and [RFC3948] describes UDP encapsulation of transport and tunnel mode
tunnel mode. This document only describes the changes required for ESP packets. This document describes a similar mechanism for BEET
UDP encapsulation of BEET mode [I-D.nikander-esp-beet-mode]. mode ESP packets [I-D.nikander-esp-beet-mode].
3.1. Packet Formats 3.1. Packet Formats
This section defines the UDP-encapsulation packet format for HIP base This section defines the UDP-encapsulation packet format for HIP base
exchange and control traffic, IPsec ESP BEET-mode traffic and NAT exchange and control traffic, IPsec ESP BEET-mode traffic and NAT
keep-alive. keep-alive.
3.1.1. Control Traffic 3.1.1. Control Traffic
0 1 2 3 0 1 2 3
skipping to change at page 5, line 38 skipping to change at page 6, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for UDP-encapsulated HIP control traffic. Figure 1: Format for UDP-encapsulated HIP control traffic.
Figure 1 shows how HIP control packets are encapsulated within UDP. Figure 1 shows how HIP control packets are encapsulated within UDP.
A minimal UDP packet carries a complete HIP packet in its payload. A minimal UDP packet carries a complete HIP packet in its payload.
Contents of the UDP source and destination ports are described below. Contents of the UDP source and destination ports are described below.
The UDP length and checksum field MUST be computed as described in The UDP length and checksum field MUST be computed as described in
[RFC0768]. The HIP header and parameter follow the conventions [RFC0768]. The HIP header and parameter follow the conventions
[I-D.ietf-hip-base] with the exception that the HIP header checksum [I-D.ietf-hip-base] with the exception that the HIP header checksum
MUST be zero. The HIP headers checksum is not used because it is MUST be zero. The HIP headers checksum is zero for two reasons.
redundant and requires the use of inner addresses (extra complexity First, the UDP header contains already a checksum. Second, the
for UDP-NAT transformations). checksum definition in [I-D.ietf-hip-base] includes the IP addresses
in the checksum calculation which is not applicable on HIP unaware
NAT devices.
3.1.2. Control Channel Keep-Alives 3.1.2. Control Channel Keep-Alives
The keep-alive for control channel are basically UDP encapsulated The keep-alive for control channel are basically UDP encapsulated
UPDATE packets [I-D.ietf-hip-base]. The UPDATE packets MAY contain NOTIFY packets [I-D.ietf-hip-base]. The NOTIFY packets MAY contain
HIP parameters. The NAT traversal mechanisms encapsulate these HIP parameters. The NAT traversal mechanisms encapsulate these
UPDATE packets within the payload of UDP packets. NOTIFY packets within the payload of UDP packets.
3.1.3. Data Traffic 3.1.3. Data Traffic
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ESP Header ~ ~ ESP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic. Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic.
Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated
within UDP. Again, a minimal UDP packet carries the ESP packet in within UDP. Again, a minimal UDP packet carries the ESP packet in
its payload. Contents of the UDP source and destination ports are its payload. The contents of the UDP source and destination ports
described in later sections. The UDP length and checksum field MUST are described in later sections. The UDP length and checksum field
be computed as described in [RFC0768]. MUST be computed as described in [RFC0768].
3.1.4. FROM_NAT Parameter 3.1.4. FROM_NAT Parameter
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | Padding | | UDP Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ] Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ]
Length 18 Length 18
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. Address An IPv6 address or an IPv4 address in IPv4-in-IPv6
UDP Port A UDP port number format.
UDP Port A UDP port number
Figure 3: Format for FROM_NAT Parameter Figure 3: Format for the FROM_NAT Parameter
Figure 3 shows FROM_NAT parameter. The use of this parameter is Figure 3 shows FROM_NAT parameter. The use of this parameter is
described in later sections. described in the following sections.
3.1.5. VIA_RVS_NAT Parameter 3.1.5. VIA_RVS_NAT Parameter
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
skipping to change at page 7, line 25 skipping to change at page 8, line 25
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | Padding | | UDP Port | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ] Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ]
Length 16 Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address
UDP Port A UDP port UDP Port A UDP port
Figure 4: Format for VIA_RVS_NAT Parameter Figure 4: Format for the VIA_RVS_NAT Parameter
Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for
diagnostic purposes, similarly as VIA_RVS parameter in diagnostic purposes, similarly as VIA_RVS parameter in
[I-D.ietf-hip-rvs]. The exact use of this parameter is described in [I-D.ietf-hip-rvs]. The exact use of this parameter is described in
later sections. later sections.
3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP 3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP
[RFC3948] describes UDP encapsulation of IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. This section describes the changes required for UDP tunnel mode. This section describes the UDP encapsulation of the
encapsulation of BEET mode. BEET mode.
3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP 3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP
In BEET IPsec mode, any present transport-layer checksums in the During the HIP base exchange, the two peers exchange parameters that
payload data are consequently based on the HITs. The packet MUST enable them to define a pair of IPsec ESP security associations
then undergo BEET-mode ESP cryptographic processing as defined in (SAs), as described in [I-D.ietf-hip-esp]. When two peers perform a
Section 5.3 of [I-D.nikander-esp-beet-mode]. UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs
that result in UDP-encapsulated BEET-mode ESP data traffic.
The resulting BEET-mode packet is then UDP encapsulated. For this The management of encryption and authentication protocols and
security parameter indices (SPIs) is defined in [I-D.ietf-hip-esp].
Additional SA parameters, such as IP addresses and UDP ports, MUST be
defined according to this section. Two SAs MUST be defined on each
host for one HIP association; one for outgoing data and another one
for incoming data.
The BEET mode provides limited tunnel mode semantics without the
regular tunnel mode overhead. [I-D.nikander-esp-beet-mode] In the
BEET mode, transport-layer checksums in the payload data are based on
the HITs. The packet MUST then undergo BEET-mode ESP cryptographic
processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode].
Next, the resulting BEET-mode packet is UDP encapsulated. For this
purpose, a UDP header MUST be inserted between the IP and ESP header. purpose, a UDP header MUST be inserted between the IP and ESP header.
The source and destination ports are filled in as defined in later The source and destination ports are filled in. The UDP checksum
sections. The UDP checksum MUST be calculated based on an IP header MUST be calculated based on the outer addresses (locators) of the
that contains the outer addresses of the SA. The other fields of the IPsec security association. The other fields of the UDP header are
UDP header are computed as described in [RFC0768]. computed as described in [RFC0768].
The resulting UDP packet MUST then undergo BEET IP header processing The resulting UDP packet MUST then undergo BEET IP header processing
as defined in Section 5.4 of [I-D.nikander-esp-beet-mode]. as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].
Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a
TCP packet. TCP packet.
ORIGINAL TCP PACKET: ORIGINAL TCP PACKET:
+------------------------------------------+ +------------------------------------------+
| inner IPv6 hdr | ext hdrs | | | | inner IPv6 hdr | ext hdrs | | |
skipping to change at page 8, line 46 skipping to change at page 10, line 17
An incoming UDP-encapsulated IPsec BEET-mode ESP packet is An incoming UDP-encapsulated IPsec BEET-mode ESP packet is
decapsulated as follows. First, if the UDP checksum is invalid, then decapsulated as follows. First, if the UDP checksum is invalid, then
the packet MUST be dropped. Then, the packet MUST be verified as the packet MUST be dropped. Then, the packet MUST be verified as
defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data
contained in the payload of the UDP packet MUST be decrypted as contained in the payload of the UDP packet MUST be decrypted as
described in [I-D.nikander-esp-beet-mode]. described in [I-D.nikander-esp-beet-mode].
The NAT traversal methods described in this section are based on The NAT traversal methods described in this section are based on
connection reversal and UDP hole punching similar to connection reversal and UDP hole punching similar to
[I-D.ietf-behave-nat-udp]. However, the methods in this section are [I-D.ietf-behave-nat-udp]. However, the methods in this section are
adapted for HIP purposes, especially the rendezvous server in mind. adapted for HIP purposes, especially with the rendezvous server in
mind.
3.3. Initiator Behind NAT 3.3. Initiator Behind NAT
This section discusses mechanisms to reach a HIP responder located in This section discusses mechanisms to reach a HIP responder located in
publicly addressable network by a HIP initiator that is located publicly addressable network by a HIP initiator that is located
behind a NAT. The case where the responder is using a rendezvous behind a NAT. The section describes also the case where the
service is also described. responder is using a rendezvous service.
Table 1 lists some short-hand notations used in this section. For Table 1 lists some short-hand notations used in this section. For
simplicity, the ports mangled by NAT are presented as example port simplicity, the ports mangled by NAT are presented as example port
numbers (11111 and 22222) instead of symbolic ones. In the examples, numbers (11111, 22222, etc) instead of symbolic ones. In the
we assume that the NAT(s) timeout after I1-R1 exchange for examples, we assume that the NAT(s) timeout after the I1-R1 exchange
illustration purposes, hence there are different port numbers for over UDP because of e.g large RTT or high puzzle difficulty. In such
I2-R2 exchange. a case, the NAT drops the related UDP port state and port numbers
change for the I2-R2 exchange.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Notation | Explanation | | Notation | Explanation |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| HIT-I | Initiator's HIT | | HIT-I | Initiator's HIT |
| HIT-R | Responder's HIT | | HIT-R | Responder's HIT |
| IP-I | Initiator's IP address | | IP-I | Initiator's IP address |
| IP-R | Responder's IP address | | IP-R | Responder's IP address |
| IP-RVS | IP address of the responder's rendezvous | | IP-RVS | IP address of the responder's rendezvous |
| | server | | | server |
skipping to change at page 9, line 40 skipping to change at page 11, line 16
| | received by the rendezvous server during the | | | received by the rendezvous server during the |
| | registration | | | registration |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 1: Notations Used in This Section Table 1: Notations Used in This Section
3.3.1. NAT Traversal of HIP Control Traffic 3.3.1. NAT Traversal of HIP Control Traffic
This section describes the details of enabling NAT traversal for HIP This section describes the details of enabling NAT traversal for HIP
control traffic for the base exchange [I-D.ietf-hip-base] through UDP control traffic for the base exchange [I-D.ietf-hip-base] through UDP
encapsulation for the case when initiator of the association is encapsulation for the case when the initiator of the association is
located behind a NAT and responder is located in publicly addressable located behind a NAT and the responder is located in a publicly
network. UDP-encapsulated HIP control traffic MUST use the packet addressable network. UDP-encapsulated HIP control traffic MUST use
formats described in Section 3.1. When sending UDP-encapsulated HIP the packet formats described in Section 3.1. When sending UDP-
control traffic, a HIP implementation MUST zero the HIP header encapsulated HIP control traffic, a HIP implementation MUST zero the
checksum before calculating the UDP checksum. The receiver MUST only HIP header checksum before calculating the UDP checksum. The
verify the correctness of the UDP checksum and MUST NOT verify the receiver MUST only verify the correctness of the UDP checksum and
checksum of the HIP header. MUST NOT verify the checksum of the HIP header.
The initiator of a UDP-encapsulated HIP base exchange MUST use the The initiator of a UDP-encapsulated HIP base exchange MUST use the
UDP destination port 50500 for all control packets it sends. It is UDP destination port 50500 for all control packets it sends. It is
RECOMMENDED to use 50500 as the source port as well, but an RECOMMENDED to use 50500 as the source port as well, but an
implementation MAY use a (randomly selected) unoccupied source port. implementation MAY use a (randomly selected) unoccupied source port.
If it uses a random source port, it MUST listen for and accept If it uses a random source port, it MUST listen for and accept
arriving HIP control/ESP Data packets on this port until the arriving HIP control/ESP Data packets on this port until the
corresponding HIP association is torn down. The random source port corresponding HIP association is torn down. The random source port
is RECOMMENDED to be in the range of the dynamic and private ports is RECOMMENDED to be in the range of the dynamic and private ports
(49152-65535). Using a random source port instead of a fixed one (49152-65535). Using a random source port, instead of a fixed one,
makes it possible to have multiple clients behind a NAT middlebox enables to have multiple clients behind a NAT middlebox that supports
that does only address translation but no port translation. This is only address translation but no port translation. This is referred
referred to as port overloading in [I-D.ietf-behave-nat-udp]. to as port overloading in [I-D.ietf-behave-nat-udp].
The responder of a UDP-encapsulated HIP base exchange MUST use 50500 The responder of a UDP-encapsulated HIP base exchange MUST use 50500
as the source port for all UDP-encapsulated control packets it sends. as the source port for all UDP-encapsulated control packets it sends.
The source address for all the packets that the responder sends MUST The source address for all the packets that the responder sends MUST
be the same as the IP address on which responder receives packets be the same as the IP address on which responder receives packets
from initiator. The responder MUST NOT respond to any arriving UDP- from initiator. The responder MUST respond to any arriving UDP-
encapsulated control message with an decapsulated reply. HIP encapsulated control message using UDP encapsulation as well. Hosts
implementations that implement the NAT traversal mechanisms MUST MUST process UDP-encapsulated base exchange messages equivalently to
process UDP-encapsulated base exchange messages equivalently to non-encapsulated messages, i.e., according to [I-D.ietf-hip-base].
decapsulated messages, i.e., according to [I-D.ietf-hip-base].
The remainder of this section clarifies this process through an The remainder of this section clarifies this process through an
example which is illustrated in Figure 6. It shows an initiator with example which is illustrated in Figure 6. It shows an initiator with
the private IP address I behind a NAT. The NAT has the public IP the private address IP-I behind a NAT. The NAT has the public IP
address as NAT. The responder is located in the public Internet at address as NAT. The responder is in a publicly addressable location
the IP address R. IP-R.
+---+ +---+ +---+ +---+ +---+ +---+
| |----(1)--->| |---------------(2)-------------->| | | |----(1)--->| |---------------(2)-------------->| |
| | | N | | | | | | N | | |
| |<---(4)----| A |<--------------(3)---------------| | | |<---(4)----| A |<--------------(3)---------------| |
| I | | T | | R | | I | | T | | R |
| |----(5)--->| - |---------------(6)-------------->| | | |----(5)--->| - |---------------(6)-------------->| |
| | | I | | | | | | I | | |
| |<---(8)----| |<--------------(7)---------------| | | |<---(8)----| |<--------------(7)---------------| |
+---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 10, line 50 skipping to change at page 12, line 25
1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R) 2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R)
3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I) 3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I)
4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R) 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R)
7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I) 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I)
8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator
behind a NAT, responder on the public Internet). behind a NAT, responder in a publicly addressable location).
Before beginning the base exchange, the initiator detects that it is Before beginning the base exchange, the initiator detects that it is
behind a NAT. The initiator starts the base exchange by sending a behind a NAT through some external mechanism, e.g. STUN. The
UDP-encapsulated I1 packet to the responder. According to the rules initiator starts the base exchange by sending a UDP-encapsulated I1
specified above, the source IP address of this I1 packet is IP-I and packet to the responder. According to the rules specified above, the
its source UDP port is 50500. It is addressed to IP-R on port 50500. source IP address of this I1 packet is IP-I and its source UDP port
The NAT in Figure 6 forwards the I1 but substitutes the source is 50500. It is addressed to IP-R on port 50500. The NAT in
address IP-I with its own public address IP-NAT-I and the source UDP Figure 6 forwards the I1 but substitutes the source address IP-I with
port 50500 with 11111. its own public address IP-NAT-I and the source UDP port 50500 with
11111.
When the responder in Figure 6 receives the UDP-encapsulated I1 When the responder in Figure 6 receives the UDP-encapsulated I1
packet on UDP port 50500, it processes it according to packet on UDP port 50500, it decapsulates the packet and processes
[I-D.ietf-hip-base]. The responder replies back with an R1 using the the decapsulated packet according to [I-D.ietf-hip-base]. The
addresses and port information of I1. Thus, the R1 packet is responder replies back with a UDP-encapsulated R1 using the addresses
destined to the source IP address and UDP port of the I1, i.e., IP and port information of I1. Thus, the R1 packet is destined to the
address IP-NAT-I and port 11111. The NAT receives the I1 and source IP address and UDP port of the I1, i.e., IP address IP-NAT-I
substitutes the destination of this packet with the initiator address and port 11111. The NAT receives the I1 and substitutes the
(IP-I) and port information (50500). destination of this packet with the initiator address (IP-I) and port
information (50500).
The initiator receives a UDP-encapsulated R1 packet from the The initiator receives a UDP-encapsulated R1 packet from the
responder and processes it according to [I-D.ietf-hip-base]. When it responder, decapsulates and processes it according to
responds with a UDP-encapsulated I2 packet, it uses the same IP [I-D.ietf-hip-base]. When it responds with a UDP-encapsulated I2
source and destination addresses and UDP source and destination ports packet, it uses the same IP source and destination addresses and UDP
that it used for sending the corresponding I1 packet, i.e., the source and destination ports that it used for sending the
packet is addressed from IP-I port 50500 to IP-R port 50500. The NAT corresponding I1 packet, i.e., the packet is addressed from IP-I port
again substitutes the source information. To illustrate timeout, the 50500 to IP-R port 50500. The NAT again substitutes the source
NAT chooses a different source port (22222) for the I2 than for the information. For illustration purposes, the NAT state times out and
I1 (11111) in this case. it chooses a different source port (22222) for the I2 than for the I1
(11111).
When a responder receives a UDP-encapsulated I2 packet destined to When a responder receives a UDP-encapsulated I2 packet destined to
UDP port 50500, it MUST use the UDP source port contained in this UDP port 50500, it MUST use the UDP source port contained in this
packet for further HIP communications with the initiator. It then packet for further HIP communications with the initiator. It then
processes the I2 packet according to [I-D.ietf-hip-base]. When it processes the I2 packet according to [I-D.ietf-hip-base]. When it
responds with an R2 message, it UDP-encapsulates the message, using responds with an R2 message, it UDP-encapsulates the message, using
the UDP source port of the I2 packet as the destination UDP port, and the UDP source port of the I2 packet as the destination UDP port, and
sends it to the source IP address of the I2 packet, i.e., it sends sends it to the source IP address of the I2 packet, i.e., it sends
the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT
again replaces the destination information in the R2 with IP-I port again replaces the destination information in the R2 with IP-I port
50500 50500
Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT
state to persist. This means that the NAT uses the same port for the state to persist. This means that the NAT uses the same port for the
I1-R1 exchange to translate as the I2-R2 exchange. However, an I1-R1 exchange to translate as the I2-R2 exchange. However, the host
implementation MUST handle even the case where the NAT state times MUST handle even the case where the NAT state times out between the
out between the two exchanges and the I1 and I2 arrive from different two exchanges and the I1 and I2 arrive from different UDP source
UDP source ports and/or IP addresses, as shown in Figure 6. ports and/or IP addresses, as illustrated in Figure 6.
3.3.2. NAT Traversal of HIP Data Traffic 3.3.2. NAT Traversal of HIP Data Traffic
This section describes the details of enabling NAT traversal of HIP This section describes the details of enabling NAT traversal of HIP
data traffic. As described in Section 3, HIP data traffic is carried data traffic. As described in Section 3, HIP data traffic is carried
in UDP-encapsulated IPsec BEET-mode ESP packets. in UDP-encapsulated IPsec BEET-mode ESP packets.
3.3.2.1. IPsec BEET-Mode Security Associations 3.3.2.1. IPsec BEET-Mode Security Associations
During the HIP base exchange, the two peers exchange parameters that
enable them to define a pair of IPsec ESP security associations
(SAs), as described in [I-D.ietf-hip-esp]. As mentioned in
Section 3.3.1, when two peers perform a UDP-encapsulated base
exchange, they MUST define a pair of IPsec SAs that result in UDP-
encapsulated BEET-mode ESP data traffic.
The management of encryption and authentication protocols and of
security parameter indices (SPIs) occurs as defined in
[I-D.ietf-hip-esp]. Additional SA parameters, such as IP addresses
and UDP ports, MUST be defined according to the following
specification. Two SAs MUST be defined on each host for one HIP
association; one for outgoing data and another one for incoming data.
The initiator MUST use UDP destination port 50500 for all UDP- The initiator MUST use UDP destination port 50500 for all UDP-
encapsulated ESP packets it sends. It MAY also use port 50500 as encapsulated ESP packets it sends. It MAY also use port 50500 as
source port or it MAY use a random source port. If it uses a random source port or it MAY use a random source port. If it uses a random
source port, it MUST listen for and accept arriving UDP-encapsulated source port, it MUST listen for and accept arriving UDP-encapsulated
ESP packets on this port until the corresponding HIP association is ESP packets on this port until the corresponding HIP association is
torn down. torn down.
The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST
use 50500 as the source port for all UDP-encapsulated ESP packets it use 50500 as the source port for all UDP-encapsulated ESP packets it
sends. The destination port is the port from which the responder is sends. The destination port is the port from which the responder is
receiving UDP encapsulated ESP data from the initiator. receiving UDP encapsulated ESP data from the initiator.
Both initiator and responder of a HIP association that uses the NAT Both the initiator and the responder of a HIP association MUST define
traversal mechanism as described in this draft MUST define BEET mode BEET mode with UDP encapsulation as the IPsec mode for the SA after a
with UDP encapsulation as IPsec mode for SA after a successful base successful base exchange. The inner source address MUST be the local
exchange. The inner source address MUST be local HIT used during HIT used during base exchange and the inner destination address MUST
base exchange and inner destination address MUST be HIT of the be the HIT of the peer. The other parts of the SA are described in
respective peer. The other parts of the SA are described in
individual sections. individual sections.
3.3.2.1.1. Security Associations at the Initiator 3.3.2.1.1. Security Associations at the Initiator
The initiator of a UDP-encapsulated base exchange defines its The initiator of a UDP-encapsulated base exchange defines its
outbound SA as shown in Table 2 outbound SA as shown in Table 2
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted |
| Outer dst | Same peer IP address to which base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Same port number as chosen for I2 packet in base | | Outer dst | The peer IP address to which base exchange packets |
| address | were transmitted |
| UDP src port | The port number as chosen for I2 packet in base |
| | exchange | | | exchange |
| UDP dst port | Port 50500 | | UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 2: Outbound SA at initiator Table 2: Outbound SA at initiator
The initiator of a UDP-encapsulated base exchange defines its inbound The initiator of a UDP-encapsulated base exchange defines its inbound
SA as shown in Table 3 SA as shown in Table 3
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same peer IP address to which base exchange | | Outer src | The peer IP address to which base exchange packets |
| address | packets were transmitted | | address | were transmitted |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Port 50500 | | UDP src port | Port 50500 |
| UDP dst port | Initiator MUST use the UDP source port it uses in | | UDP dst port | Initiator MUST use the UDP source port it uses in |
| | the outbound SA here | | | the outbound SA here |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 3: Inbound SA at initiator Table 3: Inbound SA at initiator
3.3.2.1.2. Security Associations at the Responder 3.3.2.1.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 4. outbound SA shown in Table 4.
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Field | Value | | Field | Value |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| Outer dst | Peer IP address of the I2 packet received during | | Outer dst | Peer IP address of the I2 packet received during |
| address | the base exchange | | address | the base exchange |
| UDP src | Port 50500 | | UDP src | Port 50500 |
| port | | | port | |
| UDP dst | Source UDP port of the I2 packet received from the | | UDP dst | Source UDP port of the I2 packet received from the |
| port | initiator during base exchange | | port | initiator during base exchange |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 4: Outbound SA at Responder Table 4: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 5 its inbound SA as shown in Table 5
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Field | Value | | Field | Value |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Outer src | Source IP address of the I2 packet received from | | Outer src | Source IP address of the I2 packet received from |
| address | the initiator during base exchange | | address | the initiator during base exchange |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src | Source UDP port of the I2 packet received from the | | UDP src | Source UDP port of the I2 packet received from the |
| port | initiator during base exchange | | port | initiator during base exchange |
| UDP dst | Port 50500 | | UDP dst | Port 50500 |
| port | | | port | |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 5: Inbound SA at responder Table 5: Inbound SA at responder
3.3.3. Use of the Rendezvous Service when only the Initiator Is Behind 3.3.3. Use of the Rendezvous Service when only the Initiator is Behind
NAT NAT
The rendezvous extensions for HIP without NAT traversal have been The rendezvous extensions for HIP without NAT traversal have been
defined in [rvs]. This section addresses only the scenario where a defined in [I-D.ietf-hip-rvs]. This section addresses only the
NATted HIP node uses rendezvous service to contact another HIP node scenario where a NATted HIP node uses the rendezvous service to
in a publicly addressable network. Figure 7 illustrates the contact another HIP node in a publicly addressable network. Figure 7
mechanism described in this section. illustrates the mechanism described in this section.
A rendezvous server MUST listen on UDP port number 50500 for incoming A rendezvous server MUST listen on UDP port 50500 for incoming UDP
UDP encapsulated I1 packets. However, in this specific case with encapsulated I1 packets. However, in this specific case with only
only initiator behind NAT, the rendezvous server MUST not relay the the initiator behind NAT, the rendezvous server MUST NOT relay the I1
I1 packets at all because the UDP hole punching does not work. packets. Instead, the rendezvous server replies to the initiator
Instead, the rendezvous server replies to the initiator with a NOTIFY with a NOTIFY message that includes the responder's locator in a
message that includes the responder's locator in VIA_RVS parameter. VIA_RVS parameter. The rendezvous server can differentiate this
scenario from the others because the I1 arrives UDP encapsulated, but
the responder has registered without UDP encapsulation.
Upon receiving the NOTIFY with the locators of the responder through Upon receiving the NOTIFY with the locators of the responder through
the NAT, the initiator MUST send an I1 to the responder. However, it the NAT, the initiator MUST send an I1 to the responder. However, it
MUST continue retransmissions using the RVS location. This is MUST continue retransmissions using the RVS location. This is
mandatory because NOTIFY messages are not protected with signatures mandatory because NOTIFY messages are not protected with signatures
and can be forged by a rogue host. and can be forged by a rogue host.
When the initiator receives an R1 through the NAT, the responder When the initiator receives an R1 through the NAT, the responder
verifies the integrity of the packet and replies with an I2. The verifies the integrity of the packet and replies with an I2. The
responder should be aware that the I2 may arrive from a different responder should be aware that the I2 may arrive from a different
skipping to change at page 15, line 23 skipping to change at page 16, line 37
| |<---(8)----| - |<--------------(7)---------------| | | |<---(8)----| - |<--------------(7)---------------| |
| | | T | | | | | | T | | |
| |----(9)--->| |---------------(10)------------->| | | |----(9)--->| |---------------(10)------------->| |
| | | | | | | | | | | |
| |<---(11)---| |<--------------(12)--------------| | | |<---(11)---| |<--------------(12)--------------| |
+---+ +---+ +---+ +---+ +---+ +---+
1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R)) NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))
4. IP(IP-RVS, IP-I) UDP(50500, 50500) 4. IP(IP-RVS, IP-I) UDP(50500, 50500)
NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R)) NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))
5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R) 5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R) 6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R)
7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I) 7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I)
8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I) 8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R) 10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R)
11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I) 11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I)
12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS
skipping to change at page 15, line 47 skipping to change at page 17, line 14
3.4. Responder Behind NAT 3.4. Responder Behind NAT
This section discusses mechanisms to reach a HIP responder that is This section discusses mechanisms to reach a HIP responder that is
located behind a NAT. This section assumes that the initiator is located behind a NAT. This section assumes that the initiator is
located on publicly addressable network. The initiator contacts the located on publicly addressable network. The initiator contacts the
responder through an RVS server. responder through an RVS server.
3.4.1. Rendezvous Client Registration From Behind NAT 3.4.1. Rendezvous Client Registration From Behind NAT
The rendezvous client registration [rvs] describes the case when The rendezvous client registration [I-D.ietf-hip-rvs] describes the
rendezvous client is present in publicly addressable network. This case when rendezvous client is present in publicly addressable
section defines an extension to the rendezvous client registration network. This section defines an extension to the rendezvous client
for the case when the rendezvous client has detected that it is registration for the case when the rendezvous client has detected
behind a NAT. The process in the NAT case is identical to the case that it is behind a NAT. The process in the NAT case is identical to
without NAT, except that UDP encapsulation is used. The registration the case without NAT, except that UDP encapsulation is used. The
is illustrated in Figure 8. registration is illustrated in Figure 8.
A node behind a NAT MUST first register to the RVS when it is going A node behind a NAT MUST first register to the RVS when it is going
to act as a responder for some other nodes. The node (i.e. to act as a responder for some other nodes. The node (i.e.
rendezvous client) performs a base exchange with the RVS over UDP as rendezvous client) performs a base exchange with the RVS over UDP as
described in Section 3.3 by sending I1 UDP encapsulated and 50500 as described in Section 3.3 by sending I1 UDP encapsulated and 50500 as
destination port number. RVS sends REG_INFO parameter in R1 to which destination port number. RVS sends REG_INFO parameter in R1 to which
rendezvous client replies with REG_REQ in I2. Both I1 and R1 are rendezvous client replies with REG_REQ paramter in I2. Both I1 and
sent using UDP. If RVS grants service to the rendezvous client, it R1 are sent using UDP-encapsulation. If RVS grants service to the
MUST store the source IP address and source port number of the I2 UDP rendezvous client, it MUST store the source IP address and source
packet that it had received from the rendezvous client during base port number of the I2 UDP packet that it had received from the
exchange. The source IP address belongs to the NAT and the source rendezvous client during base exchange. The source IP address
port number is the NAT mangled port. RVS then replies with REG_RESP belongs to the NAT and the source port number is the NAT mangled
in R2 over UDP. If the registration process results in a successful port. RVS then replies with REG_RESP in R2 over UDP. If the
REG_RESP, the rendezvous client MUST send NAT keepalives registration process results in a successful REG_RESP, the rendezvous
(Section 3.1.2) to keep the mapping in the NAT with the RVS open. client MUST send NAT keepalives (Section 3.1.2) to keep the mapping
The NAT keepalives sent from rendezvous client to the RVS MUST have in the NAT with the RVS open. The NAT keepalives sent from
the same source port as the I2 packet. rendezvous client to the RVS MUST have the same source port as the I2
packet.
When the RVS receives an I1 packet from a HIP node to be relayed to When the RVS receives an I1 packet from a HIP node to be relayed to
the successfully registered rendezvous client behind NAT, RVS MUST the successfully registered rendezvous client behind NAT, RVS MUST
relay the I1 over UDP with the destination port as the one stored relay the I1 over UDP with the destination port as the one stored
during registration. The RVS also zeroes the HIP header checksum of during registration. The RVS also zeroes the HIP header checksum of
the I1. This process is explained in Section 3.4.2. the I1. This process is explained in Section 3.4.2.
+---+ +---+ +---+ +---+ +---+ +---+
| |----(1)--->| |---------------(2)-------------->| | | |----(1)--->| |---------------(2)-------------->| |
| | | N | | | | | | N | | |
skipping to change at page 17, line 47 skipping to change at page 18, line 47
exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for
the case when the HIP initiator is on publicly addressable network the case when the HIP initiator is on publicly addressable network
and the HIP responder is behind NAT. The process is illustrated in and the HIP responder is behind NAT. The process is illustrated in
Figure 9. Figure 9.
Before the HIP base exchange starts, the responder of the HIP base Before the HIP base exchange starts, the responder of the HIP base
exchange MUST have completed a successful rendezvous client exchange MUST have completed a successful rendezvous client
registration using the scheme defined in Section 3.4.1. registration using the scheme defined in Section 3.4.1.
The initiator of the HIP base exchange sends a plain I1 packet The initiator of the HIP base exchange sends a plain I1 packet
(without UDP encapsulation) to the RVS as described in [rvs]. The (without UDP encapsulation) to the RVS as described in
RVS relays the inbound I1 packet to the registered rendezvous client. [I-D.ietf-hip-rvs]. In this case, the rendezvous server detects that
In this case, the incoming I1 is not UDP encapsulated, but the the I1 is not UDP encapsulated, but the rendezvous client has
rendezvous client has registered using UDP. registered using UDP encapsulation.
To relay the I1 packet, RVS SHOULD zero the HIP header checksum from To relay the I1 packet, RVS MUST zero the HIP header checksum from
the I1 packet. RVS must add a FROM parameter, as described in [rvs], the I1 packet. RVS MUST add a FROM parameter, as described in
which contains the IP address of HIP initiator. The FROM parameter [I-D.ietf-hip-rvs], which contains the IP address of HIP initiator.
is integrity protected by a RVS_HMAC as described in [rvs]. RVS The FROM parameter is integrity protected by a RVS_HMAC parameter as
replaces the destination IP address in the IP header of the packet described in [I-D.ietf-hip-rvs]. RVS replaces the destination IP
with IP that it had stored during the rendezvous client registration address in the IP header of the packet with IP that it had stored
(which is the IP address of the outermost NAT behind which rendezvous during the rendezvous client registration (which is the IP address of
client is located). It MUST then encapsulate the I1 packet within the outermost NAT behind which rendezvous client is located). It
UDP. The source port in the UDP header MUST be 50500 and the MUST then encapsulate the I1 packet within UDP. The source port in
destination port MUST be the same as the source port number (44444) the UDP header MUST be 50500 and the destination port MUST be the
of the I2 packet which it had stored during the registration process. same as the source port number (44444) of the I2 packet which it had
RVS then recomputes the IP header checksum and sends the packet. stored during the registration process. RVS then recomputes the IP
header checksum and sends the packet.
+-------+ +-------+
| | | |
+----->| RVS +-----+ +----+ +----->| RVS +-----+ +----+
+---+ | | | | | | +---+ +---+ | | | | | | +---+
| |---(1)---+ +-------+ +----(2)--->| |---(3)--->| | | |---(1)---+ +-------+ +----(2)--->| |---(3)--->| |
| | | N | | | | | | N | | |
| |<------------------(5)--------------------| A |<--(4)----| | | |<------------------(5)--------------------| A |<--(4)----| |
| I | | T | | R | | I | | T | | R |
| |-------------------(6)------------------->| - |---(7)--->| | | |-------------------(6)------------------->| - |---(7)--->| |
| | | R | | | | | | R | | |
| |<------------------(9)--------------------| |<--(8)----| | | |<------------------(9)--------------------| |<--(8)----| |
+---+ +----+ +---+ +---+ +----+ +---+
1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R) 1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R)
2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
3. IP(IP-RVS, IP-R) UDP(50500, 50500) 3. IP(IP-RVS, IP-R) UDP(50500, 50500)
I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC) I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
4. IP(IP-R, IP-I) 4. IP(IP-R, IP-I)
UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
5. IP(IP-NAT-R, IP-I) 5. IP(IP-NAT-R, IP-I)
UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500) UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)
6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R) 6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R)
7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R) 7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I) 8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I) 9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I)
Figure 9: UDP-encapsulated HIP base exchange (initiator on public Figure 9: UDP-encapsulated HIP base exchange (initiator on public
Internet, responder behind a NAT). Internet, responder behind a NAT).
The relayed I1 packet travels from RVS to the NAT. The NAT changes The relayed I1 packet travels from RVS to the NAT. The NAT changes
the destination IP address of the UDP encapsulated I1 packet, and the the destination IP address of the UDP encapsulated I1 packet, and the
destination port number in the UDP header. The responder accepts the destination port number in the UDP header. The responder accepts the
packet from the RVS and processes it according to [rvs]. The packet from the RVS and processes it according to [I-D.ietf-hip-rvs].
resulting R1 must be encapsulated within UDP. The responder MAY The resulting R1 must be encapsulated within UDP. The responder MAY
append a VIA_RVS_NAT parameter to the message, which contains the IP append a VIA_RVS_NAT parameter to the message, which contains the IP
address of the rendezvous and the port the rendezvous used for address of the rendezvous and the port the rendezvous server used for
relaying the R1. The RECOMMENDED source port is 50500 and the relaying the I1. The RECOMMENDED source port is 50500 and the
destination port number MUST be 50500. The destination address in destination port number MUST be 50500. The destination address in
the IP header MUST be the same as the one specified in the FROM the IP header MUST be the same as the one specified in the FROM
parameter of the relayed I1 packet. parameter of the relayed I1 packet.
The initiator MUST listen on port 50500 and it receives the UDP The initiator MUST listen on port 50500 and it receives the UDP
encapsulated R1. After verifying the HIP packet, it concludes that encapsulated R1. After verifying the HIP packet, it concludes that
the responder is behind a NAT because the packet was UDP the responder is behind a NAT because the packet was UDP
encapsulated. The initiator processes the R1 control packet encapsulated. The initiator processes the R1 control packet
according to [I-D.ietf-hip-base] and replies using I2 that is UDP according to [I-D.ietf-hip-base] and replies using I2 that is UDP
encapsulated. The addresses and ports are derived from the received encapsulated. The addresses and ports are derived from the received
R1. R1.
The NAT translates and forwards the UDP encapsulated I2 packet to the The NAT translates and forwards the UDP encapsulated I2 packet to the
responder. The resulting R2 packet is also UDP encapsulated using responder. The resulting R2 packet is also UDP encapsulated using
the address and port information from the received I2 packet. the address and port information from the received I2 packet.
3.4.3. NAT Traversal of HIP Data Traffic 3.4.3. NAT Traversal of HIP Data Traffic
After a successful base exchange, both of the HIP nodes have all the After a successful base exchange, both of the HIP nodes have
parameters with them needed to establish UDP BEET mode Security communicated all the necessary information to establish UDP-
Association. The following section describe inbound and outbound encapsulated BEET mode Security Associations. The following section
security associations at initiator and responder. describes inbound and outbound security associations at initiator and
responder.
3.4.3.1. Security Associations at the Initiator 3.4.3.1. Security Associations at the Initiator
The initiator of a base exchange defines its outbound SA as shown in The initiator of a base exchange defines its outbound SA as shown in
Table 6 Table 6
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| Outer dst | Same peer IP address from which R2 packet was | | Outer dst | The peer IP address from which R2 packet was |
| address | received during base exchange | | address | received during base exchange |
| UDP src port | Port 50500 | | UDP src port | Port 50500 |
| UDP dst port | Source port of incoming R2 packet during base | | UDP dst port | Source port of incoming R2 packet during base |
| | exchange | | | exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 6: Outbound SA at initiator Table 6: Outbound SA at initiator
The initiator of a base exchange defines its inbound SA as shown in The initiator of a base exchange defines its inbound SA as shown in
Table 7 Table 7
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same peer IP address from which R2 packet was | | Outer src | The peer IP address from which R2 packet was |
| address | received during base exchange | | address | received during base exchange |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Source port of incoming R2 packet during base | | UDP src port | Source port of incoming R2 packet during base |
| | exchange | | | exchange |
| UDP dst port | Port 50500 | | UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 7: Inbound SA at initiator Table 7: Inbound SA at initiator
3.4.3.2. Security Associations at the Responder 3.4.3.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 8. outbound SA shown in Table 8.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| Outer dst | Same peer IP as that used during base exchange | | Outer dst | The peer IP as that used during base exchange |
| address | | | address | |
| UDP src port | Same as source port chosen during base exchange | | UDP src port | The as source port chosen during base exchange |
| UDP dst port | Port 50500 | | UDP dst port | Port 50500 |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 8: Outbound SA at Responder Table 8: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 9 its inbound SA as shown in Table 9
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Source peer IP address as used in base exchange | | Outer src | Source peer IP address as used in base exchange |
| address | | | address | |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Port 50500 | | UDP src port | Port 50500 |
| UDP dst port | Same as source port chosen during base exchange | | UDP dst port | The as source port chosen during base exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 9: Inbound SA at responder Table 9: Inbound SA at responder
3.5. Both Hosts Behind NAT 3.5. Both Hosts Behind NAT
This section describes the details of enabling NAT traversal for HIP This section describes the details of enabling NAT traversal for HIP
control and ESP data traffic, such as the base exchange control and ESP data traffic, such as the base exchange
[I-D.ietf-hip-base], through UDP encapsulation, for the case when the [I-D.ietf-hip-base], through UDP encapsulation, for the case when the
HIP initiator and the HIP responder are both behind two separate HIP initiator and the HIP responder are both behind two separate
NATs. The described mechanism applies also when the hosts are behind NATs. The limitation of this approach is that the NAT middlebox MUST
the same NAT but may result in inefficient routing paths, unless the
countermeasures described in section Section 2 are followed. The
limitation of this approach is that it requires that the NAT boxes
support endpoint independent mapping support endpoint independent mapping
[I-D.srisuresh-behave-p2p-state]. [I-D.srisuresh-behave-p2p-state].
The registration and rendezvous relay are handled similarly as The registration and rendezvous relay are handled similarly as
described in Section 3.3.3 and Section 3.4.1. Now that both hosts described in Section 3.3.3 and Section 3.4.1. Now that both hosts
are behind NATs, both the initiator (Section 3.3) and responder are behind NATs, both the initiator (Section 3.3) and responder
(Section 3.4) mechanisms are combined here. (Section 3.4) mechanisms are combined here. There is one exception
though; the initiator does not retransmit an I1 but rather a NOTIFY
message.
3.5.1. NAT Traversal of HIP Control Traffic 3.5.1. NAT Traversal of HIP Control Traffic
This section describes traversal mechanism for HIP control traffic in Before an initiator can start the base exchange, the responder MUST
the situation when both the initiator and the responder are behind have completed a successful rendezvous client registration with its
NATs. Both hosts MUST first detect using external mechanism that RVS using the mechanism described in Section 3.4.1. The initiator of
they are located behind NAT. The RVS MUST be located on publicly the HIP base exchange starts the base exchange by sending a UDP
addressable network. Before initiator begins the base exchange, the encapsulated I1 packet to RVS. The UDP packet MUST have destination
responder MUST have completed a successful rendezvous client port number 50500 and the initiator is RECOMMENDED to use 50500 as
registration with the RVS using the mechanism described in source port number. RVS MUST listen on UDP port 50500. RVS MUST
Section 3.4.1. accept the packet as described in Section 3.3.3. As there has been a
successful rendezvous client registration between the responder and
Initiator of the HIP base exchange starts the base exchange by the RVS as described in Section 3.4.1, the RVS knows the port number
sending an UDP encapsulated I1 packet to RVS. The UDP packet MUST to be used to communicate with the responder through the NAT. RVS
have destination port number 50500 and initiator is RECOMMENDED to MUST add a FROM_NAT parameter to the I1 packet. The FROM_NAT
use 50500 as source port number. RVS MUST listen on UDP port 50500. parameter contains the source address of the I1 packet, which is
RVS MUST accept the packet as described in Section 3.3.3. As there effectively the address of the outermost NAT of the initiator. The
has been a successful rendezvous client registration between the RVS copies the source port of the UDP encapsulated I1 packet into the
responder and the RVS as described in Section 3.4.1, the RVS knows port number field of the FROM_NAT parameter. The FROM_NAT parameter
the port number which it can use to communicate with the responder is integrity protected by an RVS_HMAC as described in
through the NAT. RVS MUST add a FROM_NAT parameter to the I1 packet. [I-D.ietf-hip-rvs]. It MUST replace the destination IP address of
The FROM_NAT parameter contains the source address of the I1 packet, the I1 packet by the one it had stored earlier during rendezvous
which is effectively the address of the outermost NAT of the client registration. It MUST replace source IP address of I1 packet
initiator. The RVS copies the source port of the UDP encapsulated I1 with its own address. UDP source port of the relayed I1 packet MUST
packet into the port number field of the FROM_NAT parameter. The be 50500 and destination port MUST be the same as one it had stored
FROM_NAT parameter is integrity protected by an RVS_HMAC as described
in [rvs]. It MUST replace the destination IP address of the I1
packet by the one it had stored earlier during rendezvous client
registration. It MUST replace source IP address of I1 packet with
its own address. UDP source port of the relayed I1 packet MUST be
50500 and destination port MUST be the same as one it had stored
during the client rendezvous registration. It MUST recompute the IP during the client rendezvous registration. It MUST recompute the IP
header checksum. header checksum.
In this case, in which the I1 was UDP encapsulated and the rendezvous Upon receiving the VIA_RVS_NAT parameter, the initiator sends NOTIFY
client is also behind a NAT, the rendezvous server sends two packets. message without any contents to the responder, which responder MUST
First, it MUST relay the I1 packet to the responder (rendezvous ignore. This punches a hole to the NAT of the initiator.
client) using UDP. Second, it MUST send the locator and port (as
observed by the rendezvous) of the responder in a VIA_RVS_NAT
parameter in a NOTIFY packet to the inititiator. However, this will
actually launch two parallel base exchanges. In the first case, the
initiator receives the NOTIFY message, and acts on it as described in
section Section 3.3.3, i.e., it sends an I1 directly to the address
in the VIA_RVS_NAT parameter and continues to retransmit packet
through the RVS. In the second case, the responder will receive the
I1 relayed by the rendezvous. The responder acts as described in
section Section 3.4.2 by replying with an R1.
This scheme launches two parallel exchanges, one of which is phased The responder receives the I1 relayed by the RVS. The responder acts
later than the other. Although this kind of operation is not usually as described in Section 3.4.2 by replying with an R1. The R1 punches
very desirable, it is essential to guarantee successful NAT hole a hole to the responder's NAT for the initiator. The R1 makes it to
punching. The base exchange has been designed to handle simultaneous the initiator because the initiator already punched a hole in its own
base exchanges and the race between the two parallel base exchange NAT with the empty NOTIFY message for the responder.
eventually terminates after initiator is in established state.
The initiator and responder complete the rest of the base exchange
with I2 and R2. The NAT state may timeout in case the R1 cookie was
relatively large or in case the RTT is large. For this reason, the
initiator MUST refresh the state of the NATs by resending empty
NOTIFY messages until it receives an R2.
+---+ +----+ +-------+ +----+ +---+ +---+ +----+ +-------+ +----+ +---+
| |--(1)-->| |---(2)-->+ | | | | | | +--(1)-->| +---(2)-->+ | | | | |
| | | | | RVS R | | | | | | | | | | RVS-R | | | | |
| | | |<--(3a)--+ |---(3b)---->| | | | | | | |<--(3a)--+ +---(3b)---->| | | |
| | | N | +-------+ | N | | | | | | | +-------+ | | | |
| |<-(4a)--| A | | A |--(4b)->| | | |<-(4a)--+ N | | N +--(4b)->| |
| I | | T | | T | | R | | | | A | | A | | |
| |--(5a)->| - | | - |<-(5b)--| | | I +--(5a)->| T | | T |<-(5b)--+ R |
| | | I |<-(6b)------------------(6a)->| R | | | | | | - |<-(6b)------------------(6a)->| - | | |
| |<-(7b)--+ I | | R +--(7a)->| |
| | | | | | | | | | | | | | | |
.................................................................... | +--(8)-->| +--------------(9)------------>| +--(10)->| |
| | | | | | | |
| |<-(13)--+ |<-------------(12)------------+ |<-(11)--+ |
+---+ +----+ +----+ +---+ +---+ +----+ +----+ +---+
1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R) 1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R) 2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111) 3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444) 3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC) I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC)
4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500) 4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500)
NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444) NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
4b. IP(IP-RVS, IP-R) UDP(50500, 50500) 4b. IP(IP-RVS, IP-R) UDP(50500, 50500)
I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC) I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC)
5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I1(HIT-I, HIT-R) 5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) NOTIFY(HIT-I, HIT-R)
5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111) 5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111)
R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) I1(HIT-I, HIT-R) 6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) NOTIFY(HIT-I, HIT-R)
6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111) 6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111)
R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
7a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 50500) NOTIFY(HIT-I, HIT-R)
7b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 50500)
R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
8-10. I2(HIT-I, HIT-R), details similarly as in the cases before
11-13 R2(HIT-R, HIT-I), details similarly as in the cases before
Figure 10: UDP-encapsulated HIP base exchange (initiator and Figure 10: UDP-encapsulated HIP base exchange (initiator and
responder behind a NAT, RVS on public IP). responder behind a NAT, RVS on public IP).
The UDP hole punching is applicable only in the case when the NAT
devices on the path support address independent mapping
[I-D.srisuresh-behave-p2p-state]. After the initiator has received a
VIA_RVS_NAT parameter and has been in I1_SENT state for a policy
specific period, the initiator MAY transition to E-FAILED state.
Alternatively, it is RECOMMENED to switch to an external relay based
protocol mechanism.
3.5.2. NAT Traversal of HIP Data Traffic 3.5.2. NAT Traversal of HIP Data Traffic
After a successful base exchange, both the HIP nodes have all the After a successful base exchange, both the HIP nodes have all the
parameters with them to establish UDP BEET mode Security Association. parameters with them to establish UDP BEET mode Security Association.
The following section describes inbound and outbound security The following section describes inbound and outbound security
associations at initiator and responder. associations at initiator and responder.
3.5.2.1. Security Associations at the Initiator 3.5.2.1. Security Associations at the Initiator
The initiator of a base exchange defines its outbound SA as shown in The initiator of a base exchange defines its outbound SA as shown in
skipping to change at page 24, line 4 skipping to change at page 25, line 20
After a successful base exchange, both the HIP nodes have all the After a successful base exchange, both the HIP nodes have all the
parameters with them to establish UDP BEET mode Security Association. parameters with them to establish UDP BEET mode Security Association.
The following section describes inbound and outbound security The following section describes inbound and outbound security
associations at initiator and responder. associations at initiator and responder.
3.5.2.1. Security Associations at the Initiator 3.5.2.1. Security Associations at the Initiator
The initiator of a base exchange defines its outbound SA as shown in The initiator of a base exchange defines its outbound SA as shown in
Table 10 Table 10
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| Outer dst | Same peer IP address from which R2 packet was | | Outer dst | The peer IP address from which R2 packet was |
| address | received during base exchange | | address | received during base exchange |
| UDP src port | Same as the port number chosen to send I2 during | | UDP src port | The as the port number chosen to send I2 during |
| | base exchange | | | base exchange |
| UDP dst port | Source port of incoming R2 packet during base | | UDP dst port | Source port of incoming R2 packet during base |
| | exchange | | | exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 10: Outbound SA at initiator Table 10: Outbound SA at initiator
The initiator of a base exchange defines its inbound SA as shown in The initiator of a base exchange defines its inbound SA as shown in
Table 11 Table 11
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same peer IP address from which R2 packet was | | Outer src | The peer IP address from which R2 packet was |
| address | received during base exchange | | address | received during base exchange |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Source port of incoming R2 packet during base | | UDP src port | Source port of incoming R2 packet during base |
| | exchange | | | exchange |
| UDP dst port | Same as the port number chosen to send I2 during | | UDP dst port | The as the port number chosen to send I2 during |
| | base exchange | | | base exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 11: Inbound SA at initiator Table 11: Inbound SA at initiator
3.5.2.2. Security Associations at the Responder 3.5.2.2. Security Associations at the Responder
The responder of a UDP-encapsulated base exchange defines its The responder of a UDP-encapsulated base exchange defines its
outbound SA shown in Table 12. outbound SA shown in Table 12.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Same local IP address from which the base exchange | | Outer src | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| Outer dst | Same peer IP as that used during base exchange | | Outer dst | The peer IP as that used during base exchange |
| address | | | address | |
| UDP src port | Same as source port chosen send R2 during base | | UDP src port | The as source port chosen send R2 during base |
| | exchange |
| UDP dst port | The as source port number of I2 packet during base |
| | exchange | | | exchange |
| UDP dst port | Same as source port number of I2 packet during |
| | base exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 12: Outbound SA at Responder Table 12: Outbound SA at Responder
Similarly, the responder of a UDP-encapsulated base exchange defines Similarly, the responder of a UDP-encapsulated base exchange defines
its inbound SA as shown in Table 13 its inbound SA as shown in Table 13
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Field | Value | | Field | Value |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Outer src | Source peer IP address as used in base exchange | | Outer src | Source peer IP address as used in base exchange |
| address | | | address | |
| Outer dst | Same local IP address from which the base exchange | | Outer dst | The local IP address from which the base exchange |
| address | packets were transmitted | | address | packets were transmitted |
| UDP src port | Same as source Port received from I2 during base | | UDP src port | The as source Port received from I2 during base |
| | exchange | | | exchange |
| UDP dst port | Same as source port used to send R2 during base | | UDP dst port | The as source port used to send R2 during base |
| | exchange | | | exchange |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 13: Inbound SA at responder Table 13: Inbound SA at responder
3.6. NAT Keep-Alives 3.6. NAT Keep-Alives
Typically, NATs cache an established binding and time it out if they Typically, NATs cache an established binding and time it out if they
have not used it to relay traffic for a given period of time. This have not used it to relay traffic for a given period of time. This
timeout is different for different NAT implementations. The BEHAVE timeout is different for different NAT implementations. The BEHAVE
working group is discussing recommendations for standardized timeout working group is discussing recommendations for standardized timeout
values. To prevent NAT bindings that support the traversal of UDP- values. To prevent NAT bindings that support the traversal of UDP-
encapsulated HIP traffic from timing out during times when there is encapsulated HIP traffic from timing out during times when there is
no control or data traffic, HIP hosts SHOULD send periodic keep-alive no control or data traffic, HIP hosts SHOULD send periodic keep-alive
messages. messages.
Typically, only outgoing traffic acts refreshes the NAT port state Typically, only outgoing traffic refreshes the NAT port state for
for security reasons. Consequently, both hosts SHOULD send periodic security reasons. Consequently, both hosts SHOULD send periodic
keep-alives for the UDP channel of all their established HIP keep-alives for the UDP channel of all their established HIP
associations if the channel has been idle for a specific period of associations if the channel has been idle for a specific period of
time. time.
For the UDP channel, keep-alives MUST be UDP-encapsulated HIP UPDATE For the UDP channel, keep-alives MUST be UDP-encapsulated HIP NOTIFY
packets as defined in Section 3.1.2. The packets MUST use the same packets as defined in Section 3.1.2. The packets MUST use the same
source and destination ports and IP addresses as the corresponding source and destination ports and IP addresses as the corresponding
UDP tunnel. The default keep-alive interval for control channels UDP tunnel. The default keep-alive interval for control channels
MUST be 20 seconds. The responder of the HIP association should just SHOULD be 20 seconds. The peer host of the HIP association MUST
discard the keep-alives. discard the keep-alives.
3.7. HIP Mobility 3.7. HIP Mobility
After a successful base exchange, either host can change its network After a successful base exchange, a mobile node can change its
location using the mechanisms defined in [I-D.ietf-hip-mm]. This network location using the mechanisms defined in [I-D.ietf-hip-mm].
section describes such mobility mechanisms in the presence of NATs. This section describes such mobility mechanisms in the presence of
However, double jump scenario, where both hosts move simultaneously, NATs. However, the double jump scenario, where both peers move
is excluded. simultaneously, is excluded.
The mobile node can change its location as described in Table 14. The mobile node can change its location as described in Table 14.
+----+---------------------------+----------------------------------+ +----+---------------------------+----------------------------------+
| No | From network | To network | | No | From network | To network |
+----+---------------------------+----------------------------------+ +----+---------------------------+----------------------------------+
| 1 | Behind NAT | Publicly Addressable Network | | 1 | Behind NAT | Publicly Addressable Network |
| 2 | Publicly Addressable | Behind NAT | | 2 | Publicly Addressable | Behind NAT |
| | Network | | | | Network | |
| 3 | Behind NAT-A | Stays behind NAT-A, but | | 3 | Behind NAT-A | Stays behind NAT-A, but |
skipping to change at page 26, line 31 skipping to change at page 28, line 4
| 3 | Behind NAT-A | Stays behind NAT-A, but | | 3 | Behind NAT-A | Stays behind NAT-A, but |
| | | different IP | | | | different IP |
| 4 | Behind NAT-A | Behind NAT-B | | 4 | Behind NAT-A | Behind NAT-B |
| 5 | Publicly Addressable | Publicly Addressable Network | | 5 | Publicly Addressable | Publicly Addressable Network |
| | Network | | | | Network | |
+----+---------------------------+----------------------------------+ +----+---------------------------+----------------------------------+
Table 14: End host mobility scenarios Table 14: End host mobility scenarios
The corresponding peer node can be located as follows Table 15 The corresponding peer node can be located as follows Table 15
+----+------------------------------------------+ +----+------------------------------------------+
| No | Peer Node network | | No | Peer Node network |
+----+------------------------------------------+ +----+------------------------------------------+
| A | Publicly Addressable Network With RVS | | A | Publicly Addressable Network With RVS |
| B | Publicly Addressable Network Without RVS | | B | Publicly Addressable Network Without RVS |
| C | Behind NAT With RVS | | C | Behind NAT With RVS |
| D | Behind NAT Without RVS | | D | Behind NAT Without RVS |
+----+------------------------------------------+ +----+------------------------------------------+
Table 15: Peer host Network Scenarios Table 15: Peer host Network Scenarios
The NAT traversal mechanisms may not work when the corresponding node The NAT traversal mechanisms may not work when the corresponding node
is behind a NAT without RVS (case D), except when the mobile node is behind a NAT without RVS (case D), except when the mobile node
stays behind the same cone NAT (case 3D). stays behind the same cone NAT (case 3D).
When a host changes its location, it SHOULD detect the presence of When a mobile node changes its location, it SHOULD detect the
NATs along the new paths to its peers using some external mechanism presence of NATs along the new paths to its corresponding nodes using
before sending any UPDATE messages. Alternatively, it MAY use some some external mechanism before sending any UPDATE messages. If no
heuristics to conclude that it is behind a NAT rather than incur the NAT was detected in such a case, it SHOULD send an UPDATE to its
latency of running NAT detection first. corresponding nodes without UDP encapsulation.
The mobile node MUST send the UPDATE packet through the corresponding The mobile node MUST send the UPDATE packet through the corresponding
node's RVS if it has one, in addition to sending it to the node's RVS if it uses one, in addition to sending it to the
corresponding node directly. The mobile node encapsulates the UPDATE corresponding node directly. The mobile node encapsulates the UPDATE
packet within UDP only when it is behind a NAT. The corresponding packet within UDP only when it is behind a NAT. The corresponding
node MUST reply using UDP when the packet was encapsulated within node MUST reply using UDP when the packet was encapsulated within
UDP, or without UDP when the UDP header was not present in the UPDATE UDP, or without UDP when the UDP header was not present in the UPDATE
packet. packet.
The rendezvous server UPDATE relaying process is similar to I1. The The rendezvous server relays the UPDATE similarly to I1. The
rendezvous server MUST add FROM parameter when it gets a UPDATE rendezvous server MUST add FROM parameter when it gets an UPDATE
packet without UDP encapsulation, or a FROM_NAT parameter when the packet without UDP encapsulation, or a FROM_NAT parameter when the
UPDATE packet it receives is UDP encapsulated and MUST protect the UPDATE packet it receives is UDP encapsulated and MUST in both cases
packet with HMACs. Upon replying to the UPDATE, the corresponding protect the packet with a HMAC parameter. Upon replying to the
node MUST add a VIA_RVS (or VIA_RVS_NAT) parameter to the reply. UPDATE, the corresponding node MUST add a VIA_RVS (or VIA_RVS_NAT)
parameter to the reply.
When the UDP encapsulation for NAT traversal is used, private IP The mobile node MUST leave out the NATted locators from the LOCATOR
addresses should be filtered out from the LOCATOR parameter in the parameter. This MUST be done before applying HMAC and SIGNATURE to
HIP control packets. Exposing private addresses may impose privacy an R1, I2 or UPDATE packet. Thus, the LOCATOR parameter consists
related problems. only of the type and length fields when the mobile node has only
NATted addresses. When the mobile node has e.g. a single IPv6
address and one NATted address, the LOCATOR parameter consists of
single locator. The UDP header along with its port number conveys
the NATted locator to the peer.
3.8. HIP Multihoming 3.8. HIP Multihoming
Multiple security associations can exists between the same hosts. Multiple security associations can exists between the same hosts.
They may be connected through several paths, some of which may They may be connected through several paths, some of which may
include a NAT and others may not. Implementations that support include a NAT and others may not. Implementations that support
multihoming MUST support concurrent HIP associations between the same multihoming MUST support concurrent HIP associations between the same
host pair in a way that allows some of them to use UDP encapsulation host pair in a way that allows some of them to use UDP encapsulation
while others use basic HIP. Implementations MAY distinguish HIP while others are not UDP encapsulated.
associations based on the SPI instead of a HIT pair for this purpose.
3.9. Firewall Traversal 3.9. Firewall Traversal
When the initiator or the responder of a HIP association is behind a When the initiator or the responder of a HIP association is behind a
firewall, additional issues arise. firewall, additional issues arise.
When the initiator is behind a firewall, the NAT traversal mechanisms When the initiator is behind a firewall, the NAT traversal mechanisms
described in Section 3 depend on the ability to initiate described in Section 3 depend on the ability to initiate
communication via UDP to destination port 50500 from arbitrary source communication via UDP to destination port 50500 from arbitrary source
ports and to receive UDP response traffic from that port to the ports and to receive UDP response traffic from that port to the
skipping to change at page 28, line 26 skipping to change at page 30, line 7
The NAT traversal mechanisms described in Section 3 require that the The NAT traversal mechanisms described in Section 3 require that the
firewall - stateful or not - allow inbound UDP traffic to port 50500 firewall - stateful or not - allow inbound UDP traffic to port 50500
and allow outbound UDP traffic to arbitrary UDP ports. If necessary and allow outbound UDP traffic to arbitrary UDP ports. If necessary
for firewall traversal, ports reserved for IKE MAY be used for for firewall traversal, ports reserved for IKE MAY be used for
initiating new connections, but the implementation MUST be able to initiating new connections, but the implementation MUST be able to
listen for UDP packets from port 50500. listen for UDP packets from port 50500.
4. Security Considerations 4. Security Considerations
4.1. A Difference to RFC3948
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation of standard IP tunnel mode when two hosts behind encapsulation of standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same responder in the public Internet. The communication to the same responder in the public Internet. The
responder cannot distinguish between the two hosts, because security responder cannot distinguish between the two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of IPsec BEET This issue does not exist with the UDP encapsulation of IPsec BEET
mode as described in Section 3, because the responder use the HITs to mode as described in Section 3, because the responder use the HITs to
distinguish between different communication instances. distinguish between different communication instances.
4.2. Rendezvous and Responder Privacy
The rendezvous usage in this draft has been designed to follow the The rendezvous usage in this draft has been designed to follow the
design of the RVS draft [I-D.ietf-hip-rvs] and only I1 relayed. RVS specification [I-D.ietf-hip-rvs] when the NAT supports end-point
However, as NAT networking presents some additional challenges, it is independent filtering. However, as NAT networking presents some
not possible two follow the RVS design exactly. Particularly, the additional challenges, it is not possible to follow the RVS design
mechanisms described in Figure 7 and Section 3.5.1 require that the exactly. Particularly, the mechanisms described in Figure 7 and
rendezvous server replies back to the initiator with a message which Section 3.5.1 require that the rendezvous server replies back to the
includes the address and port of the responder NAT. Another design initiator with a message which includes the address and port of the
choice would have been to relay also the R1 (and I2 in case of both responder NAT. Another design choice would have been to relay also
hosts behind NAT) through the rendezvous server to delay the exposure the R1 (and I2 in case of both hosts behind NAT) through the
of the responder NAT address and port related information for rendezvous server to delay the exposure of the responder NAT address
additional DoS protection. However, this choice was not selected to and port related information for additional DoS protection. However,
reduce round trip time. As a consequence, the renzvous client must this choice was not selected to reduce round trip time. As a
be accept the risk of lowered privacy protection when it registers to consequence, the rendezvous client must accept the risk of lowered
the RVS over UDP as defined in section Figure 8. privacy protection when it registers to the RVS over UDP as defined
in Figure 8.
5. IANA Considerations 5. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
This draft currently uses a UDP port in the "Dynamic and/or Private This draft currently uses a UDP port in the "Dynamic and/or Private
Port" range, i.e., 50500. Upon publication of this document, IANA is Port" range, i.e., 50500. Upon publication of this document, IANA is
requested to register two UDP ports and the RFC editor is requested requested to register a UDP port and the RFC editor is requested to
to change all occurrences of port 50500 to the port IANA has change all occurrences of port 50500 to the port IANA has registered.
registered.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Tobias Heer, Teemu Koponen, Juhana The authors would like to thank Vivien Schmitt for his contributions
Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, to previous versions of this draft. In addition, the authors would
Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen and Jukka Ylitalo like to thank Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M.
for their comments on this document. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka
Nikander, Lauri Silvennoinen, Jukka Ylitalo, Andrei Gurtov and Juha
Heinanen for their comments on this document.
[I-D.nikander-hip-path] presented some initial ideas for NAT [I-D.nikander-hip-path] presented some initial ideas for NAT
traversal of HIP communication. This document describes traversal of HIP communication. This document describes
significantly different mechanisms that, among other differences, use significantly different mechanisms that, among other differences, use
external NAT discovery and do not require encapsulation servers. external NAT discovery and do not require encapsulation servers.
Lars Eggert and Martin Stiemerling are partly funded by Ambient Simon Schuetz and Martin Stiemerling are partly funded by Ambient
Networks, a research project supported by the European Commission Networks, a research project supported by the European Commission
under its Sixth Framework Program. The views and conclusions under its Sixth Framework Program. The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission. project or the European Commission.
Miika Komu is working for InfraHIP research group at Helsinki Miika Komu is working for InfraHIP research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project is Institute for Information Technology (HIIT). The InfraHIP project is
funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and
Ericsson. Ericsson.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-05 (work in progress), March 2006. draft-ietf-hip-base-06 (work in progress), June 2006.
[I-D.ietf-hip-esp] [I-D.ietf-hip-esp]
Jokela, P., "Using ESP transport format with HIP", Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-02 (work in progress), March 2006. draft-ietf-hip-esp-04 (work in progress), October 2006.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-03 (work in Host Identity Protocol", draft-ietf-hip-mm-04 (work in
progress), March 2006. progress), June 2006.
[I-D.ietf-hip-rvs] [I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-04 (work in Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
progress), October 2005. progress), June 2006.
[I-D.nikander-esp-beet-mode] [I-D.nikander-esp-beet-mode]
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-05 (BEET) mode for ESP", draft-nikander-esp-beet-mode-06
(work in progress), February 2006. (work in progress), August 2006.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension".
7.2. Informative References 7.2. Informative References
[I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-00
(work in progress), February 2007.
[I-D.ietf-behave-nat-udp] [I-D.ietf-behave-nat-udp]
Audet, F. and C. Jennings, "NAT Behavioral Requirements Audet, F. and C. Jennings, "NAT Behavioral Requirements
for Unicast UDP", draft-ietf-behave-nat-udp-07 (work in for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in
progress), June 2006. progress), October 2006.
[I-D.irtf-hiprg-nat] [I-D.irtf-hiprg-nat]
Stiemerling, M., "NAT and Firewall Traversal Issues of Stiemerling, M., "NAT and Firewall Traversal Issues of
Host Identity Protocol (HIP) Communication", Host Identity Protocol (HIP) Communication",
draft-irtf-hiprg-nat-02 (work in progress), May 2006. draft-irtf-hiprg-nat-03 (work in progress), June 2006.
[I-D.nikander-hip-path] [I-D.nikander-hip-path]
Nikander, P., "Preferred Alternatives for Tunnelling HIP Nikander, P., "Preferred Alternatives for Tunnelling HIP
(PATH)", draft-nikander-hip-path-01 (work in progress), (PATH)", draft-nikander-hip-path-01 (work in progress),
March 2006. March 2006.
[I-D.srisuresh-behave-p2p-state] [I-D.srisuresh-behave-p2p-state]
Srisuresh, P., "State of Peer-to-Peer(P2P) Communication Srisuresh, P., "State of Peer-to-Peer(P2P) Communication
Across Network Address Translators(NATs)", Across Network Address Translators(NATs)",
draft-srisuresh-behave-p2p-state-03 (work in progress), draft-srisuresh-behave-p2p-state-04 (work in progress),
June 2006. September 2006.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
skipping to change at page 31, line 32 skipping to change at page 33, line 22
RFC 3948, January 2005. RFC 3948, January 2005.
Appendix A. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| schmitt-00 | Initial version. | | schmitt-00 | Initial version. |
| ietf-00 | Officially adopted as WG item. Solved issues | | ietf-00 | Officially adopted as WG item. Solved issues |
| | 1-9,11,12 | | | 1-9,11,12 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Authors' Addresses Authors' Addresses
Vivien Schmitt Miika Komu (editor)
NEC Network Laboratories
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 0
Fax: +49 6221 90511 55
Email: schmitt@netlab.nec.de
URI: http://www.netlab.nec.de/
Abhinav Pathak
IIT Kanpur
B204, Hall - 1, IIT Kanpur
Kanpur 208016
India
Phone: +91 9336 20 1002
Email: abhinav.pathak@hiit.fi
URI: http://www.iitk.ac.in/
Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Tammasaarenkatu 3 Tammasaarenkatu 3
Helsinki Helsinki
Finland Finland
Phone: +358503841531 Phone: +358503841531
Fax: +35896949768 Fax: +35896949768
Email: miika@iki.fi Email: miika@iki.fi
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Lars Eggert Simon Schuetz
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 90511 43 Phone: +49 6221 4342 165
Fax: +49 6221 90511 55 Fax: +49 6221 4342 155
Email: lars.eggert@netlab.nec.de Email: simon.schuetz@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Martin Stiemerling Martin Stiemerling
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 90511 13 Phone: +49 6221 4342 113
Fax: +49 6221 90511 55 Fax: +49 6221 4342 155
Email: stiemerling@netlab.nec.de Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Lars Eggert
Nokia Research Center
P.O. Box 407
Nokia Group 00045
Finland
Phone: +358 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Abhinav Pathak
IIT Kanpur
B204, Hall - 1, IIT Kanpur
Kanpur 208016
India
Phone: +91 9336 20 1002
Email: abhinav.pathak@hiit.fi
URI: http://www.iitk.ac.in/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 33, line 47 skipping to change at page 35, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 146 change blocks. 
476 lines changed or deleted 539 lines changed or added

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