< draft-nikander-hip-path-00.txt   draft-nikander-hip-path-01.txt >
HIP P. Nikander HIP P. Nikander
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: August 18, 2005 H. Tschofenig Expires: September 7, 2006 H. Tschofenig
Siemens Siemens
X. Fu
Univ. Goettingen
T. Henderson T. Henderson
The Boeing Company The Boeing Company
L. Eggert
NEC
J. Laganier J. Laganier
SUN DoCoMo Euro-Labs
February 14, 2005 March 6, 2006
Preferred Alternatives for Tunnelling HIP (PATH) Preferred Alternatives for Tunnelling HIP (PATH)
draft-nikander-hip-path-00.txt draft-nikander-hip-path-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other groups may also distribute working documents as Internet-
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 August 18, 2005. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
With the extensions defined in this document Host Identity Protocol With the extensions defined in this document Host Identity Protocol
(HIP) can traverse legacy Network Address Translators (NATs) and (HIP) can traverse legacy Network Address Translators (NATs) and
certain Firewalls. The extension will be useful as part of the base certain firewalls. The extension will be useful as part of the base
exchange and with the HIP Registration Extension. By using a exchange and with the HIP Registration Extension. By using a
rendezvous server an additional entity inside the network is rendezvous server an additional entity inside the network is
utilized, which not only allows but also supports more restrictive utilized, which not only allows but also supports more restrictive
NATs to be traversed. NATs to be traversed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Encapsulation of HIP . . . . . . . . . . . . . . . . . 6 3.1. UDP Encapsulation of HIP . . . . . . . . . . . . . . . . . 6
3.2 UDP-REA parameter . . . . . . . . . . . . . . . . . . . . 6 3.2. UDP-REA parameter . . . . . . . . . . . . . . . . . . . . 6
3.3 S-UDP-REA parameter . . . . . . . . . . . . . . . . . . . 8 3.3. S-UDP-REA parameter . . . . . . . . . . . . . . . . . . . 7
4. Message Handling Rules . . . . . . . . . . . . . . . . . . . 10 4. Message Handling Rules . . . . . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 HIP Initiator behind a NAT . . . . . . . . . . . . . . . . 11 5.1. HIP Initiator behind a NAT . . . . . . . . . . . . . . . . 11
5.2 PATH Server Registration and Keep Alive . . . . . . . . . 11 5.2. PATH Server Registration and Keep Alive . . . . . . . . . 11
5.3 Message flow for data receiver behind a NAT . . . . . . . 13 5.3. Message flow for data receiver behind a NAT . . . . . . . 12
5.4 Mobility and multihoming message flow . . . . . . . . . . 16 5.4. Mobility and multihoming message flow . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . 18 6. New Requirements for IPsec . . . . . . . . . . . . . . . . . . 17
6.1 Third Party Bombing . . . . . . . . . . . . . . . . . . . 18 6.1. Association with server inside/outside NAT . . . . . . . . 17
6.2 Black hole . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Mobility Scenarios . . . . . . . . . . . . . . . . . . . . 17
6.3 Man-in-the-middle attack . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 7.1. Third Party Bombing . . . . . . . . . . . . . . . . . . . 18
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.2. Black hole . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 22 7.3. Man-in-the-middle attack . . . . . . . . . . . . . . . . . 19
8.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.3 Brittleness Introduced by PATH . . . . . . . . . . . . . . 23 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 22
8.4 Requirements for a Long Term Solution . . . . . . . . . . 24 9.1. Problem Definition . . . . . . . . . . . . . . 22
8.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22
8.6 In Closing . . . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Brittleness Introduced by PATH . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9.4. Requirements for a Long Term Solution . . . . . . . . . . 24
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6. In Closing . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1 Normative References . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11.2 Informative References . . . . . . . . . . . . . . . . . 29 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
This document defines extensions and allows the Host Identity This document defines extensions and allows the Host Identity
Protocol (HIP) to be used in an environment where legacy NATs or Protocol (HIP) to be used in an environment where legacy NATs or
Firewalls are presents. To support this functionality it is Firewalls are present. To support this functionality it is necessary
necessary to provide to provide
o UDP encapsulation for HIP signaling messages o UDP encapsulation for HIP signaling messages
o UDP encapsulation for IPsec traffic o UDP encapsulation for IPsec traffic
The problems of IPsec protected traffic and also the problems for a
signaling protocol (namely IKEv1) traversing a NA[P]T are well The problems of allowing IPsec protected traffic and the
described in [5]. A proposal for UDP encapsulation of IPsec corresponding signaling protocol (IKEv1) to traverse a NA(P)T are
well described in [5]. A proposal for UDP encapsulation of IPsec
protected traffic is described in [6]. It is possible to design an protected traffic is described in [6]. It is possible to design an
optimized version of it for usage with HIP. This aspect is, however, optimized version of it for usage with HIP. This aspect is, however,
outside the scope of this document. outside the scope of this document.
This document tries to accomplish the following goals: This document tries to accomplish the following goals:
o Make HIP work through legacy NATs (and possibly through some o Make HIP work through legacy NATs (and possibly through some
firewalls) firewalls)
o Make HIP hosts reachable behind NATs o Make HIP hosts reachable behind NATs
By using a rendezvous server an additional entity inside the network HIP signaling consists of (for static and bootstrapping) base
is introduced which interacts with the HIP message exchange. The exchange [1], which establish a HIP association state, and (in
interaction of HIP with the rendezvous server is described in [1]. particullar for mobilility and multi-homing scenarios) an Update
This allows a complete NAT/Firewall traversal to be accomplished. packet containing a LOCATOR parameter [2] which allows a HIP host to
Two approaches are possible with respect to this rendezvous server notify a peer about alternate locator(s) at which it is reachable. A
concept. third party in the network infrastructure, the rendezvous server
(RVS) is typically used to allow a HIP initiator to learn a
responder's (present) locator before initializing HIP base exchange.
The interaction of HIP hosts with the rendezvous server is described
in [3]. Currently, two possible ESP transport formats are being
defined for carrying HIP user data, namely the standard ESP [7] and
the BEET mode [8].
o First, it is possible to combine a HIP rendezvous server (i.e., This document builds on the RVS concept to allow HIP signaling and
PATH server) and a STUN server [7], TURN server [8] or NSIS NATFW ESP-mode data traffic to successfully traverse legacy NA(P)Ts (and if
[9] node. The client obviously needs to support the clide part of necessary, firewalls). There are two possible approaches to achieve
the protocol as well. The STUN, TURN or NSIS NATFW protocol is this:
used to allow the PATH client to learn the public IP address (and
port number) created at the NAT.
o Second, the HIP registration protocol can integrate a NAT
detection check. NAT-T support is provided by IKEv2 [10] and the
corresponding extensions have been designed for IKEv1 (see [5] and
[11]).
This document uses the later approach to avoid the integration of o First, it is possible to combine a HIP rendezvous server and a
another protocol and additional message exchanges but does not STUN server [9], TURN server [10] or NSIS NATFW [11] node. Here,
rule-out the former approach. An integration with STUN and TURN the STUN, TURN or NSIS NATFW protocol is used to allow the PATH
would not add more security to the protocol exchange. To support NAT client to learn the public IP address (and port number) created at
detection a new parameter UDP-REA is introduced. the NAT. The client obviously needs to support the client part of
the protocol as well.
To also allow the client to inform the server about its public IP o Alternatively, the HIP registration protocol can be extended to
integrate a NAT detection check. This ensembles NAT traversal
support in IKEv2 [12] and corresponding extensions for IKEv1 (see
[5] and [13]).
This document employs the latter approach to avoid the complexity of
integrating another protocol and additional message exchanges, while
still taking some advantages of the former approach. In contrast, an
integration with STUN or TURN may not bring better security features
in the protocol exchange.
In the proposed approach, a new parameter UDP-REA (UDP encapsulated
REAddress packet) is introduced to support NAT detection. When a HIP
message needs to be sent from a host to RVS (for registration
messages) or another HIP (HIP signaling and data traffic), with a
UDP-REA it is now possible to detect the existence of NATs and thus
retrieve or create only the preferred IP address and port number,
instead of the private address and port number for the host. Thus,
this approach is called "Preferred Alternatives for Tunnelling HIP",
or PATH.
To allow the client to inform the PATH server about its public IP
address and port in a secure fashion (where this is possible and address and port in a secure fashion (where this is possible and
appropriate) another parameter has been defined S-UDP-REA, a secure appropriate), another parameter is also introduced: S-UDP-REA, a
version of the UDP-REA parameter. Using this parameter a secure secure version of the UDP-REA parameter. By using this parameter a
traversal of legacy NATs is supported, for example by interworking secure traversal of legacy NATs is supported. The S-UDP-REA
with NSIS or MIDCOM. Both, MIDCOM and the NSIS NATFW NSLP provide parameter information can be obtained for example by interacting with
better security properties. The interaction with these protocols is NSIS or MIDCOM. This provides better security properties, however
outside the scope of this document. the details of interaction with NSIS or MIDCOM are outside the scope
of this document.
Please note that this document tries to accomplish a different goal Please note that the goal of this document is different from that of
than [12] where middleboxes (such as NATs and firewalls) are assumed [14], where middleboxes (such as NATs and firewalls) are assumed to
to be HIP-aware and participate in the HIP message exchange. As a be HIP-aware and participate in the HIP message exchange. As a
consequence, the security properties of these protocols are different result, the security properties of these protocols are different as
as well. well.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2]. document are to be interpreted as described in [4].
When interaction with a rendezvous server might be possible then we For an interaction between a HIP host with a rendezvous server, two
denote these entities as the PATH client and the PATH server communicating entities are also denoted as PATH client and PATH
traversing some type of legacy NAT. A PATH client is a HIP-aware server in this document. The PATH server always resides on the same
device which supports the extensions defined in this document in entity as the rendezvous server. A PATH client is a HIP-aware device
addition to the HIP Registration Extension [13]. The PATH client which supports the extensions defined in this document in addition to
might be located behind a legacy NAT and initiates the protocol the HIP Registration Extension [15]. The PATH client might be
exchange with the PATH server. The PATH server interacts with the located behind a legacy NAT and initiates the protocol exchange with
client in the way specified in this document. the PATH server. The PATH server interacts with the client in the
way specified in this document.
Different types of NATs (e.g., full cone, restricted NAT) are Different types of NATs (e.g., full cone, restricted NAT) are being
deployed today and [7] assigns these NAT boxes to certain categories deployed today. [9] assigns these NAT boxes to certain categories
based on their data traffic forwarding or blocking behavior. The based on their data traffic forwarding or blocking behaviors. The
existence of different NAT types has an impact on the protocol. existence of different NAT types has an impact on the protocol.
3. Protocol Extensions 3. Protocol Extensions
This section explains the necessary protocol extensions to support This section explains the necessary protocol extensions to support
the above-mentioned functionality. the above-mentioned functionality.
3.1 UDP Encapsulation of HIP 3.1. UDP Encapsulation of HIP
In order to deal with NA[P]Ts, it is necessary that the HIP signaling In order to deal with NA(P)Ts, it is necessary that the HIP signaling
messages are UDP encapsulated and moreover the source port and the messages are UDP encapsulated. Moreover, the source port and the
destination port MUST NOT be expected at a fixed port number. This destination port MUST NOT be expected at a fixed port number. This
aspect of NAT traversal is known from IPsec/IKE and also reflected in aspect of NAT traversal is known from IPsec/IKE and also reflected in
the design of IKEv2. the design of IKEv2.
It is a policy issue whether to enable UDP encapsulation immediately It is a policy issue whether to enable UDP encapsulation immediately
when the first HIP base message is sent (i.e., the I1 message). when the first HIP base message is sent (i.e., the I1 message).
For IPv4, the packet format is shown in Appendix E of [3]. The same For IPv4, the packet format is shown in Appendix E of [1]. The same
specification states that UDP encapsulation is forbidden for IPv6 but specification states that UDP encapsulation is forbidden for IPv6 but
might still be necessary particuarly particularly for IPv4-IPv6 might still be necessary, particularly for IPv4-IPv6 transition.
transition.
3.2 UDP-REA parameter 3.2. UDP-REA parameter
This section defines the UDP-REA parameter which will be used in the This section defines the UDP-REA parameter which will be used in the
traversal of legacy NATs. traversal of legacy NATs.
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 Lifetime | | Address Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ HASH ~ ~ HASH ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Padding ~ ~ Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 bytes): Type (2 bytes):
This parameter has the value of TBD. This parameter has the value of TBD.
Length (2 bytes) Length (2 bytes)
Represents the length in octets, Represents the length in octets,
excluding Type and Length fields. excluding Type, Length and Padding.
Address Lifetime (4 bytes): Address Lifetime (2 bytes):
This field represents the address lifetime, in seconds. This field represents the address lifetime, in seconds.
HASH (variable): HASH (variable):
This field of variable length contains the hash of This field of variable length contains the hash of
IP address and port information. IP address and port information.
Padding (variable): Padding (variable):
Padding information following the HASH value Padding information following the HASH value
The HASH is calculated as follows: The HASH is calculated as follows:
HASH = PRF(RANDOM | Source IP | Destination IP | Source Port | HASH = PRF(RANDOM | Source IP | Destination IP | Source Port |
Destination Port) Destination Port)
using the negotiated hash algorithm (denoted as PRF) as part of the Where, PRF is a hash algorithm negotiated through HIP_TRANSFORM (see
HIP_TRANSFORM payload (see Section 6.2.8 of [3]). The hashed data is Section 5.2.7 of [1]); the IP address is 4 octets for an IPv4 address
in the network byte-order. The IP address is 4 octets for an IPv4 and 16 octets for an IPv6 address; the port numbers are encoded in
address and 16 octets for an IPv6 address. The port number is network byte-order. A RANDOM value is included to prevent pre-
encoded as a 2 octet number in network byte-order. computation attacks. The puzzle mechanism could be used for this
purpose.
The necessary padding length depends on the selected hash algorithm.
It MUST be ensured that the total length (including padding) of the
UDP-REA parameter is 11 + Length - (Length + 3) % 8.
The RANDOM value is used to prevent precomputation attacks. The The UDP-REA parameter is zero-padded to 8 bytes. The length field
puzzle mechanism could be used for this purpose. contains the length of the payload without padding.
3.3 S-UDP-REA parameter 3.3. S-UDP-REA parameter
This section defines the S-UDP-REA parameter, a secure UDP-REA This section defines the S-UDP-REA parameter, the secure version of
parameter version. An end host might be able to retrieve address the UDP-REA parameter. An end host might be able to retrieve address
information securely using some protocols, such as MIDCOM or the NSIS information securely using some protocols, such as MIDCOM or the NSIS
NATFW NSLP. These protocols enable the PATH client to create and NATFW NSLP. These protocols enable the PATH client to create and
retrieve a NAT binding in a secure fashion. This information is then retrieve a NAT binding in a secure fashion. This information is then
communicated from the PATH client to the PATH server experiencing communicated from the PATH client to the PATH server experiencing
integrity protection. Furthermore, this extension might also be used integrity protection, thus it is called secured UDP-REA (S-UDP-REA).
when a stateful packet filtering firewall is known to be along the Furthermore, when there is a stateful packet filter firewall along
path which requires UDP encapsulation in order to perform properly. the path, S-UDP-REA may be used to allow UDP encapsulation. UDP-REA
UDP-REA Section 3.2 would not be able to detect or act accordingly in Section 3.2 would not be able to detect or act accordingly in such a
such a situation. situation.
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 Lifetime |T| | Address Lifetime | Reserved |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Address ~ ~ Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Address ~ ~ Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Padding ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 bytes): Type (2 bytes):
This parameter has the value of TBD. This parameter has the value of TBD.
Length (2 bytes) Length (2 bytes)
Represents the length in octets, Represents the length in octets,
excluding Type and Length fields. excluding Type, Length and Padding.
Address Lifetime (4 bytes): Address Lifetime (2 bytes):
This field represents the address lifetime, in seconds. This field represents the address lifetime, in seconds.
Type (T) Flag (1 bit): Type (T) Flag (1 bit):
If this bit is set to 1 then the value in the Address If this bit is set to 1 then the values in the Address
field is an IPv6 address otherwise an IPv4 address. fields are IPv6 addresses otherwise a IPv4 addresses.
Source Port (2 bytes): Source Port (2 bytes):
This field contains the source port. This field contains the source port.
Destination Port (2 bytes): Destination Port (2 bytes):
This field contains the destination port. This field contains the destination port.
Source Address (4 or 16 bytes): Source Address (4 or 16 bytes):
This field contains either an IPv4 or an IPv6 address. This field contains either an IPv4 or an IPv6 address.
Destination Address (4 or 16 bytes): Destination Address (4 or 16 bytes):
This field contains either an IPv4 or an IPv6 address. This field contains either an IPv4 or an IPv6 address.
Padding (variable):
Padding information following the HASH value.
4. Message Handling Rules 4. Message Handling Rules
The PATH client attaches the UDP-REA payload to indicate support for The PATH client attaches the UDP-REA payload to indicate support for
legacy NAT traversal. Thereby it creates a hash value over the legacy NAT traversal. Thereby it generates a hash value over the
source IP address, source port, destination IP and destination port source IP address, source port, destination IP and destination port
from the IP header of the HIP packet. When the HIP message traverse from the IP header of the HIP message. When the HIP message
a NAT along the path between the client and the server, the IP header traverses a NAT along the path between the client and the server, its
will be modified. When the server receives the HIP message, it will IP header will be modified. When the server receives the HIP
compare the hash value carried in the HASH field of the UDP-REA message, it will compare the hash value carried in the HASH field of
parameter and the value computed on the IP address header the UDP-REA parameter and the value computed on the IP address header
information. If the two values do not match then the server is information. If the two values do not match, then the server
assured that someone along the path modified the IP header (and determines that someone along the path modified the IP header (and
hopefully a NAT and not an adversary). The server will then use the hopefully it is a NAT but not an adversary). The server will then
information in the IP header to return a response to the client. If use the information in the IP header to return a response to the
the two values are equal then it is assumed that no NAT is located client. If the two values are equal then it is assumed that no NAT
along the path and UDP encapsulation might not be necessary. is located along the path and UDP encapsulation is not necessary.
If a PATH client is able to obtain S-UDP-REA related information, the
S-UDP-REA parameter in an integrity protected fashion instead of the
plain UDP-REA should be used. This offers better security and
additional capability of traversing firewalls.
This section provides further information on the message handling. This section provides further information on the message handling.
o Checksum and length field are provided in the UDP header and might o Checksum and length field are provided in the UDP header and might
not need to be repeated in the HIP header. not need to be repeated in the HIP header.
o HIP version determined by the destination port used when sending
the I1 packet o HIP version (either normal or secured) is determined by the used
destination port when sending the I1 packet.
o The digital signature and the keyed message digest is computed o The digital signature and the keyed message digest is computed
over the original payload. First, a "normal" HIP packet is over the original payload. First, a "normal" HIP packet is
constructed, then the the HMAC and the digital signatures are constructed, then the HMAC and the digital signatures are
computed. Afterwards the the HIP packet is encapsulated into the computed. Afterwards the HIP packet is encapsulated into the UDP
UDP format. format.
o Short timeout (e.g., 200ms) after first packet and therefore o Short timeout (e.g., 200ms) after first packet and therefore
encourage NAT-less operation. encourage NAT-less operation.
o If preferred source address is in RFC 1918 address space then send
I1 over IP and I1 over UDP a few milliseconds apart. o If preferred source address is in RFC 1918 address space, then I1
is UDP encapsulated.
5. Examples 5. Examples
5.1 HIP Initiator behind a NAT 5.1. HIP Initiator behind a NAT
This figure shows the usage of the UDP-REA parameter by the Initiator This figure shows the usage of the UDP-REA parameter by the Initiator
and the Responder to detect the presence of a NAT along the path. In and the Responder to detect the presence of a NAT along the path. In
this case the HIP Initiator is behind a NAT. In this example, the this example, we assume the HIP Initiator is behind a NAT and the HIP
HIP Initiator is behind a NAT and we assume the HIP Initiator Initiator initially starts with UDP encapsulation.
immediately starts with UDP encapsulation.
Private Public Private Public
Addressing Addressing Network Network
HIP Realm Network Address Realm HIP HIP Network Address HIP
Initiator Translator Responder Initiator Translator Responder
| | | | | |
| I1: Trigger exchange | I1: Trigger exchange | | I1: Trigger exchange | I1: Trigger exchange |
| over UDP | over UDP | | over UDP | over UDP |
| --------------------------> | --------------------------> | | --------------------------> | --------------------------> |
| | | | | |
| R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) |
| HIP Transform}SIG | HIP Transform}SIG | | HIP Transform}SIG | HIP Transform}SIG |
| UDP-REA(R) | UDP-REA(R) | | UDP-REA(R) | UDP-REA(R) |
| <-------------------------- | <-------------------------- | | <-------------------------- | <-------------------------- |
| | | | | |
| I2: {Solution,DH(I), | I2: {Solution,DH(I), | | I2: {Solution,DH(I), | I2: {Solution,DH(I), |
| HIP Transform | HIP Transform | | HIP Transform | HIP Transform |
| {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG |
| UDP-REA(I) | UDP-REA(I) | | UDP-REA(I) | UDP-REA(I) |
| --------------------------> | --------------------------> | | --------------------------> | --------------------------> |
| | | | | |
| R2: {HMAC}SIG | R2: {HMAC}SIG | | R2: {HMAC}SIG | R2: {HMAC}SIG |
| <-------------------------- | <-------------------------- | | <-------------------------- | <-------------------------- |
| | | | | |
Figure 3: HIP Initiation behind a NAT Message Flow Figure 3: HIP Initiation behind a NAT: Message Flow
5.2 PATH Server Registration and Keep Alive 5.2. PATH Server Registration and Keep Alive
This section illustrates the message exchange for a PATH client This section illustrates the message exchange for a PATH client
registering with a PATH server, as introduced with [13]. After the registering with a PATH server, as introduced with [15]. After the
protocol exchange is finalized both peers will be mutually protocol exchange is finalized, both peers are mutually authenticated
authenticated and authorized each other and a security association and authorized by each other and a security association for HIP has
for HIP has been established. been established.
When the PATH client starts to interact with the PATH server the When the PATH client starts to interact with the PATH server, the
client might not be aware of the presence of the legacy NAT along the client can detect the presence of the legacy NAT along the path, by
path. The I1 registration messages will most likely be dropped by including UDP-REA parameter in the registration messages and making
the NA[P]T. After some retransmissions the PATH client will switch the computation in the client and server.
to an UDP encapsulated registration protocol exchange.
Figure 4 shows such a message exchange. Figure 4 shows such a message exchange.
PATH Network Address PATH Private Public
Client Translator Server Network Network
| | | PATH Network Address PATH
| I1: Trigger exchange | | Client Translator Server
| over IP | | | | |
| --------------------------> | ...I1 dropped | | | |
| | | | I1: Trigger exchange | I1: Trigger exchange |
| ..retransmissions.. | | | over UDP | over UDP |
| --------------------------> | ...I1 dropped | | --------------------------> | --------------------------> |
| | | | | |
| I1: Trigger exchange | I1: Trigger exchange | | R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) |
| over UDP | over UDP | | HIP Transform}SIG | HIP Transform}SIG |
| --------------------------> | --------------------------> | | UDP_REA(R), REG_INFO | UDP_REA(R), REG_INFO |
| | | | <-------------------------- | <-------------------------- |
| R1: {Puzzle,DH(R),HI(R) | R1: {Puzzle,DH(R),HI(R) | | | |
| HIP Transform}SIG | HIP Transform}SIG | | I2: {Solution,DH(I), | I2: {Solution,DH(I), |
| <-------------------------- | <-------------------------- | | HIP Transform | HIP Transform |
| | | | {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG |
| I2: {Solution,DH(I), | I2: {Solution,DH(I), | | UDP_REA(I), REG_REQ | UDP_REA(I), REG_REQ |
| HIP Transform | HIP Transform | | --------------------------> | --------------------------> |
| {H(I)},CERT(I)}SIG | {H(I)},CERT(I)}SIG | | | |
| --------------------------> | --------------------------> | | R2: {HMAC}SIG, REG_RESP | R2: {HMAC}SIG, REG_RESP |
| | | | <-------------------------- | <-------------------------- |
| R2: {HMAC}SIG | R2: {HMAC}SIG | | | |
| <-------------------------- | <-------------------------- | | | |
| | |
| | |
Figure 4: Registration Protocol Message Flow Figure 4: Registration Protocol Message Flow
Additional payloads defined with the HIP Registration Extension are: Here, the HIP Registration messages are extended to not only carry
REG_INFO (carried in the R1 message), REQ_REQ (carried in the I2 REG_INFO (in the R1 message), REG_REQ (in the I2 message), REG_RESP
message) and REQ_RESP (carried in the R2 message). These payloads (in the R2 message) and HIP_SIGNATURE, but also contain UDP_REQ for
are not shown in the above message exchange. the detection of NATs and behaving properly.
Note that this protocol exchange implicitly indicates that the PATH Note that this protocol exchange implicitly indicates that the PATH
client will use the source IP address of the I1 and I2 messages as client will use the source IP address of the I1 and I2 messages as
the preferred address. The PATH server will use the source IP the preferred address when it needs to send out packets. The PATH
address of the incoming packet as the preferred address even though server will use the source IP address of the incoming packet as the
it was not authenticated (i.e., integrity protected). The HIP preferred address even though it was not authenticated (i.e.,
middlebox registration protocol exchange already ensures that this integrity protected). This extended HIP registration protocol, which
address is authorized via a return routability test. comprises a 4-way message exchange including a return routability
test, ensures that the PATH server can reach the PATH client and that
the message has not been crafted by an off-path adversary.
5.3 Message flow for data receiver behind a NAT 5.3. Message flow for data receiver behind a NAT
This section shows a message flow where one HIP node acting as the This section shows two approaches for a message flow where one HIP
data receiver is behind a NAT. The registration with the PATH server node acting as the data receiver is behind a NAT. The registration
is not shown in the figure. Figure 5 only shows the HIP base with the PATH server is not shown in the figure. Figure 5 only shows
exchange between the HIP Initiator and the HIP Responder interacting the HIP base exchange between the HIP Initiator and the HIP Responder
with the PATH server. Figure 5 shows such a protocol exchange taken interacting with the PATH server. Figure 5 shows such a protocol
from [4]. exchange taken from [2].
Figure 5 shows that the HIP base exchange between the HIP Initiator Figure 5 shows that the HIP base exchange between the HIP Initiator
and the PATH server does not use UDP encapsulation. UDP and the PATH server does not use UDP encapsulation. UDP
encapsulation for HIP signaling messages and for the IPsec data encapsulation for HIP signaling messages and for the IPsec data
traffic is only enabled between the PATH server and the HIP Responder traffic is only enabled between the PATH server and the HIP Responder
which is enabled with this extension to the HIP registration which is enabled with this extension to the HIP registration
protocol. Note that IPsec data traffic will traverse the PATH server protocol. Note that IPsec data traffic will traverse the PATH server
to experience UDP encapsulation. The main advantage of this approach to experience UDP encapsulation. The main advantage of this approach
is two-fold: (1) the HIP Initiator does not need to support the is two-fold: (1) the HIP Initiator does not need to support the
extension defined in this document and (2) traversal of more extension defined in this document and (2) traversal of more
restrictive NATs can be supported when the PATH server also changes restrictive NATs can be supported when the PATH server also changes
IP address information IP address information.
Public Private
Network Network
HIP PATH Network Address HIP HIP PATH Network Address HIP
Initiator Server Translator Responder Initiator Server Translator Responder
| | | | | | | |
| I1 over IP | | | | I1 over IP | | |
| ----------------> | I1 over UDP | I1 over UDP | | ----------------> | I1 over UDP | I1 over UDP |
| | ----------------> | ----------------> | | | ----------------> | ----------------> |
| | | | | | | |
| | R1 over UDP | R1 over UDP | | | R1 over UDP | R1 over UDP |
| R1 over IP | with UDP-REA | with UDP-REA | | R1 over IP | with UDP-REA | with UDP-REA |
| without UDP-REA | <---------------- | <---------------- | | without UDP-REA | <---------------- | <---------------- |
skipping to change at page 14, line 35 skipping to change at page 14, line 38
| IPsec ESP | IPsec ESP | IPsec ESP | | IPsec ESP | IPsec ESP | IPsec ESP |
| <===============> | over UDP | over UDP | | <===============> | over UDP | over UDP |
| | <================ | ================> | | | <================ | ================> |
| | | | | | | |
| | | | | | | |
Legend: Legend:
-->: HIP signaling messages -->: HIP signaling messages
==>: Data traffic ==>: Data traffic
Figure 5: Establishing contact (1/3) Figure 5: Establishing contact (1/3)
Figure 6 modifies the message flow described in Figure 5 whereby R2 Figure 6 modifies the message flow described in Figure 5 whereby R2
is already sent from the HIP Responder to the HIP Initiator directly. is already sent from the HIP Responder to the HIP Initiator directly.
The responder thereby creates the necessary NAT binding at the NAT to The responder thereby creates the necessary NAT binding at the NAT to
potentially allow IPsec protected traffic from the initiator towards potentially allow IPsec protected traffic from the initiator towards
the responder to traverse the NAT. IPsec protected data traffic is the responder to traverse the NAT. IPsec protected data traffic is
sent only directly between the HIP Initiator and the HIP Responder. sent only directly between the HIP Initiator and the HIP Responder.
Public Private
Network Network
HIP PATH Network Address HIP HIP PATH Network Address HIP
Initiator Server Translator Responder Initiator Server Translator Responder
| | | | | | | |
| I1 over IP | | | | I1 over IP | | |
| ----------------> | I1 over UDP | I1 over UDP | | ----------------> | I1 over UDP | I1 over UDP |
| | ----------------> | ----------------> | | | ----------------> | ----------------> |
| | | | | | | |
| | R1 over UDP | R1 over UDP | | | R1 over UDP | R1 over UDP |
| R1 over IP | with UDP-REA | with UDP-REA | | R1 over IP | with UDP-REA | with UDP-REA |
| with UDP-REA | <---------------- | <---------------- | | with UDP-REA | <---------------- | <---------------- |
skipping to change at page 15, line 31 skipping to change at page 15, line 33
| | | | | | | |
| R2 over UDP | R2 over UDP | R2 over UDP | | R2 over UDP | R2 over UDP | R2 over UDP |
| <------------------------------------ | <---------------- | | <------------------------------------ | <---------------- |
| | | | | | | |
| IPsec ESP | IPsec ESP | IPsec ESP | | IPsec ESP | IPsec ESP | IPsec ESP |
| over UDP | over UDP | over UDP | | over UDP | over UDP | over UDP |
| <==================================== | ================> | | <==================================== | ================> |
| | | | | | | |
| | | | | | | |
Figure 6: Establishing contact (2/3) Legend:
-->: HIP signaling messages
Figure 7 extends Figure 6 further by allowing I2 to be sent directly ==>: Data traffic
to the HIP Responder. This is only possible if the NAT forwards
packets with a different source IP address and source port than the
packets seen from the PATH server towards the HIP Responder.
HIP PATH Network Address HIP
Initiator Server Translator Responder
| | | |
| I1 over IP | | |
| ----------------> | I1 over UDP | I1 over UDP |
| | ----------------> | ----------------> |
| | | |
| | R1 over UDP | R1 over UDP |
| R1 over IP | with UDP-REA | with UDP-REA |
| with UDP-REA | <---------------- | <---------------- |
| <---------------- | | |
| | | |
| I2 over UDP | I2 over UDP | I2 over UDP |
| with UDP-REA | with UDP-REA | with UDP-REA |
| ------------------------------------> | ----------------> |
| | | |
| R2 over UDP | R2 over UDP | R2 over UDP |
| with UDP-REA | with UDP-REA | with UDP-REA |
| <------------------------------------ | <---------------- |
| | | |
| IPsec ESP | IPsec ESP | IPsec ESP |
| over UDP | over UDP | over UDP |
| <==================================== | ================> |
| | | |
| | | |
Figure 7: Establishing contact (3/3) Figure 6: Establishing contact (2/3)
FOR DISCUSSION: It needs to be decided which approach is the best one Sending the IPsec protected data traffic via the PATH server is
and if there are multiple preferred ways how we useful if a NAT is very restrictive. This method also addresses
(a) can detect which approach is applicable and privacy and denial of service issues as raised in the rendezvous
(b) what protocol extensions are required. server discussion. As symmetrical NATs are rare and an additional
The answer most likely depends on the types of NATs we are willing to proxy host should be avoided, the second approach is recommended as
support. For example, sending the IPsec protected data traffic via the default method. The selection of the approach is a policy
the PATH server is useful if a NAT is very restrictive but, as a decision.
default approach, probably not the best choice -- except if the PATH
server is along the path anyway (see discussion about discovery
exchange in the HIP registration protocol). Finally, the message
flows need to add info about the information conveyed to the end
hosts about the public IP address and port of it respective peer.
5.4 Mobility and multihoming message flow 5.4. Mobility and multihoming message flow
After the PATH client has registered itself to the PATH server, as After the PATH client has registered itself to the PATH server, as
described in Figure 4, the PATH client might roam within a network or described in Figure 4, the PATH client might roam within a network or
roam outside a network. Whenever the PATH client obtains a new IP roam outside a network. Whenever the PATH client obtains a new IP
address (either due to mobility, IP address reconfiguration or address (either due to mobility, IP address reconfiguration or
switching of interfaces) a REA message will be sent towards the PATH switching of interfaces), a UPDATE (containing UDP-REA) message will
server to update the stored IP address information. Note that the be sent towards the PATH server to update the stored IP address
initial registration procedure might be executed without a NAT along information. Note that the initial registration procedure might be
the path. Hence, the messages are carried over IP and do not require executed without a NAT along the path. Hence, the messages may be
UDP encapsulation. When the PATH client roams to a new network UDP carried over IP and do not require UDP encapsulation. When the PATH
encapsulation might be required due to the presence of a NAT. Hence, client roams to a new network, UDP encapsulation should be used to
it is required to have the capability to enable UDP encapsulation for detect the presence of a NAT. Hence, it is required to have the
the HIP exchange (and for the IPsec protected data traffic) not only capability to enable UDP encapsulation for the HIP base exchange (and
during the initial protocol exchange. for the IPsec protected data traffic) in addition to the registration
messages.
Figure 8 shows such a protocol exchange which is taken from [4]. Figure 7 shows such a protocol exchange which ensembles the work in
[2] but applies it in the PATH/RVS registration. Note UPP_REA is
used for NAT traversal.
Private Public
Network Network
PATH Network Address PATH PATH Network Address PATH
Client Translator Server Client Translator Server
| | | | | |
| UPDATE(REA, SEQ) | | | UPDATE(UDP_REA(S), SEQ) | UPDATE(UDP_REA(S), SEQ) |
| over IP | |
| --------------------------> | ...UPDATE/REA dropped |
| | |
| ..retransmissions.. | |
| --------------------------> | ...UPDATE/REA dropped |
| | |
| UPDATE(REA, SEQ) | UPDATE(REA, SEQ) |
| over UDP | over UDP | | over UDP | over UDP |
| --------------------------> | --------------------------> | | --------------------------> | --------------------------> |
| | | | | |
| UPDATE(SPI, SEQ, | UPDATE(SPI, SEQ, | | UPDATE(UDP_REA(C), SPI, SEQ,| UPDATE(UDP_REA(C), SPI, SEQ,|
| ACK, ECHO_REQUEST) | ACK, ECHO_REQUEST) | | ACK, ECHO_REQUEST) | ACK, ECHO_REQUEST) |
| <-------------------------- | <-------------------------- | | <-------------------------- | <-------------------------- |
| | | | | |
| UPDATE(ACK, ECHO_RESPONSE) | UPDATE(ACK, ECHO_RESPONSE) | | UPDATE(ACK, ECHO_RESPONSE) | UPDATE(ACK, ECHO_RESPONSE) |
| --------------------------> | --------------------------> | | --------------------------> | --------------------------> |
| | | | | |
| | | | | |
Figure 8: Mobility Message Flow Figure 7: Mobility Message Flow
6. Security Considerations Further issues with mobility and multihoming are being investigated
and will be detailed in next versions of the document.
6. New Requirements for IPsec
The text in this section focuses on Dynamic UDP Encapsulation for
IPsec. By dynamic UDP encapsulation we mean UDP encapsulation per
security association. Before describing the approach we describe
some of the scenarios where dynamic UDP encapsulation is needed.
6.1. Association with server inside/outside NAT
The association of a client with a server outside NAT should have UDP
encapsulation on while an association with a server within the same
NAT should normal HIP association without any UDP encapsulation.
This identification is done during base exchange. Dynamic UDP
encapsulation based on security association could achieve this.
Figure 8 shows difference in association between different servers.
Private Public
Network Network
PATH PATH Network Address PATH
Server Client Translator Server
| | | |
| HIP association | HIP association | |
| No UDP encapsulation | UDP encapsulated | |
|<-----------------------| ------------------------------------>|
| | | |
Figure 8: Dynamic NAT Associations
6.2. Mobility Scenarios
If a HIP client moves from behind the NAT to outside it then it would
not need any more UDP encapsulation as it can have an HIP association
without any UDP encapsulation. So when the client moves out of NAT
it should reset all the NAT variables that are in security
associations.
To achieve dynamic UDP encapsulation for Legacy NAT traversal we need
to define it per Security Association basis. The SA would contain an
indicator which would indicate whether or not the particular HIP
association needs UDP encapsulation or not. By default this
indicator would be off. During base exchange if NAT is detected on
the way then this indicator should be turned on. The UDP
encapsulation in the kernel should also be based on this variable.
7. Security Considerations
Currently this text in this section focuses on the attacks between Currently this text in this section focuses on the attacks between
the PATH client and the PATH server since they differ from the the PATH client and the PATH server since they differ from the
description of threats provided in the past about NAT traversal for description of threats provided in the past about NAT traversal for
mobility protocols. The latter one have been investigated in context mobility protocols. The latter one have been investigated in context
of IKE, IKEv2 and various other protocols and will be summarized in a of IKE, IKEv2 and various other protocols and will be summarized in a
future version of the document. future version of the document.
Attacks on the interaction between the PATH client and the PATH Attacks on the interaction between the PATH client and the PATH
server can be classified as denial of service and might be launched server can be classified as denial of service and might be launched
skipping to change at page 18, line 41 skipping to change at page 18, line 41
procedure might, however, be part of the HIP Registration protocol. procedure might, however, be part of the HIP Registration protocol.
A detailed discussion about the security properties of the HIP A detailed discussion about the security properties of the HIP
registration protocol is outside the scope of this document. Even registration protocol is outside the scope of this document. Even
though the base HIP registration protocol is outside the scope of though the base HIP registration protocol is outside the scope of
this document some of its security properties are highly relevant and this document some of its security properties are highly relevant and
applicable for this discussion. This document extends the applicable for this discussion. This document extends the
capabilities of the registration protocol that might raise security capabilities of the registration protocol that might raise security
concerns. This section mostly focuses on the security properties of concerns. This section mostly focuses on the security properties of
the UDP-REA parameter and it's semantic. the UDP-REA parameter and it's semantic.
6.1 Third Party Bombing 7.1. Third Party Bombing
Threat: Threat:
Third party bombing is also of concern when legacy NAT traversal Third party bombing is also of concern when legacy NAT traversal
mechanisms are in place. These attacks have been discovered in mechanisms are in place. These attacks have been discovered in
the context of Mobile IP and a threat description can be found in the context of Mobile IP and a threat description can be found in
[14]. The main problem described in [14] is caused by the missing [16]. The main problem described in [16] is caused by the missing
integrity protection of the IP address communicated from the PATH integrity protection of the IP address communicated from the PATH
client to the PATH server. The PATH client cannot protect the IP client to the PATH server. The PATH client cannot protect the IP
address (without relying on additional protocol) since a NA[P]T is address (without relying on additional protocol) since a NA(P)T is
supposed to change the header's IP address (source, possibly supposed to change the header's IP address (source, possibly
destination IP address and transport protocol identifiers). destination IP address and transport protocol identifiers).
Instead of using the protected IP address inside the signaling Instead of using the protected IP address inside the signaling
message the PATH server is supposed to use IP header information. message the PATH server is supposed to use IP header information.
An adversary might provide change the IP header address to point An adversary might provide change the IP header address to point
to the intended target. Data sent to the PATH server will be send to the intended target. Data sent to the PATH server will be send
to the target rather than to the true IP address of the client. to the target rather than to the true IP address of the client.
Countermeasures: Countermeasures:
To prevent third party bombing, the address provided by the PATH To prevent third party bombing, the address provided by the PATH
client via the IP header needs to be verified using a client via the IP header needs to be verified using a return-
return-routability check. This check might either be provided as routability check. This check might either be provided as part of
part of the base exchange (which involves two roundtrips) or as the base exchange (which involves two roundtrips) or as part of
part of the REA message exchange which also provides mechanisms to the REA message exchange which also provides mechanisms to execute
execute such a test. This return-routability test MUST be such a test. This return-routability test MUST be performed in
performed in order to ensure that this and other attacks can be order to ensure that this and other attacks can be thwarted. A
thwarted. A third party entity cannot respond to any of these HIP third party entity cannot respond to any of these HIP messages due
messages due to the cryptographic properties of the HIP base to the cryptographic properties of the HIP base protocol and the
protocol and the multi-homing and mobility extensions. multi-homing and mobility extensions.
6.2 Black hole 7.2. Black hole
Threat: Threat:
This attack again exploits the ability for an adversary to act as This attack again exploits the ability for an adversary to act as
a NAT and to modify the IP address information in the header. a NAT and to modify the IP address information in the header.
This information will then be used by the PATH server to sent This information will then be used by the PATH server to sent
traffic towards the indicated address. If this address is not traffic towards the indicated address. If this address is not
used by any entity (and particularly by the legitimate PATH used by any entity (and particularly by the legitimate PATH
client) then the traffic will be dropped. This attack is a denial client) then the traffic will be dropped. This attack is a denial
of service attack. of service attack.
skipping to change at page 19, line 34 skipping to change at page 19, line 35
Threat: Threat:
This attack again exploits the ability for an adversary to act as This attack again exploits the ability for an adversary to act as
a NAT and to modify the IP address information in the header. a NAT and to modify the IP address information in the header.
This information will then be used by the PATH server to sent This information will then be used by the PATH server to sent
traffic towards the indicated address. If this address is not traffic towards the indicated address. If this address is not
used by any entity (and particularly by the legitimate PATH used by any entity (and particularly by the legitimate PATH
client) then the traffic will be dropped. This attack is a denial client) then the traffic will be dropped. This attack is a denial
of service attack. of service attack.
Countermeasures: Countermeasures:
This threat can be avoided using the same counter measures as This threat can be avoided using the same counter measures as
third party bombing. third party bombing.
6.3 Man-in-the-middle attack 7.3. Man-in-the-middle attack
Threat: Threat:
This attack again requires the adversary to modify the IP header This attack again requires the adversary to modify the IP header
of the HIP registration protocol messages exchanged between the of the HIP registration protocol messages exchanged between the
PATH server and the PATH client. Instead of pointing to a black PATH server and the PATH client. Instead of pointing to a black
hole or to a third party the adversary provides his address. This hole or to a third party the adversary provides his address. This
allows the adversary to eavesdrop the data traffic. However, in allows the adversary to eavesdrop the data traffic. However, in
order to launch the attack, the adversary must have already been order to launch the attack, the adversary must have already been
able to observe packets from the PATH client to the PATH server. able to observe packets from the PATH client to the PATH server.
skipping to change at page 20, line 27 skipping to change at page 20, line 31
client roams and uses the HIP registration protocol or the REA client roams and uses the HIP registration protocol or the REA
message to update state at the PATH server the adversary needs to message to update state at the PATH server the adversary needs to
be located somewhere along the path where it can observe this be located somewhere along the path where it can observe this
exchange and to modify it. As a consequence, this attack is not exchange and to modify it. As a consequence, this attack is not
particular useful for the adversary. particular useful for the adversary.
The S-UDP-REA parameter does not suffer from the same threats as the The S-UDP-REA parameter does not suffer from the same threats as the
UDP-REA parameter since it aims to provide a secure mechanism for the UDP-REA parameter since it aims to provide a secure mechanism for the
PATH server and the PATH client to communicate addressing PATH server and the PATH client to communicate addressing
information. Still, the PATH server might want to authorize the information. Still, the PATH server might want to authorize the
parameters provided by the PATH client by either executing a parameters provided by the PATH client by either executing a return-
return-routability check or by using other techniques (e.g., routability check or by using other techniques (e.g., authorization
authorization certificates) to ensure that the PATH client is indeed certificates) to ensure that the PATH client is indeed reachable at
reachable at the indicated addresses. A malicious PATH client might the indicated addresses. A malicious PATH client might add wrong
add wrong addressing information to redirect traffic to a black hole addressing information to redirect traffic to a black hole or a third
or a third party. This threat has a different degree than the party. This threat has a different degree than the previously
previously discussed threats in the sense that the PATH server will discussed threats in the sense that the PATH server will most likely
most likely know the identity of the PATH client, if we assume that know the identity of the PATH client, if we assume that only
only authenticated and authorized clients are allowed to use the PATH authenticated and authorized clients are allowed to use the PATH
server. If the PATH server is able to detect the malicious behavior server. If the PATH server is able to detect the malicious behavior
it can act accordingly. it can act accordingly.
Finally, it is necessary to add a remark on the usage of NAT/Firewall Finally, it is necessary to add a remark on the usage of NAT/Firewall
signaling protocols in relationship with the S-UDP-REA parameter signaling protocols in relationship with the S-UDP-REA parameter
usage. If the PATH client uses these protocols in an insecure or usage. If the PATH client uses these protocols in an insecure or
inadequate way then the envisioned security of the S-UDP-REA inadequate way then the envisioned security of the S-UDP-REA
parameter is seriously affected. A discussion of the security parameter is seriously affected. A discussion of the security
properties of various NAT/Firewall signaling protocols is outside the properties of various NAT/Firewall signaling protocols is outside the
scope of the document (in the same way as these protocols are outside scope of the document (in the same way as these protocols are outside
the scope of this document). the scope of this document).
7. IANA Considerations 8. IANA Considerations
This document extends the HIP registration protocol by defining a new This document extends the HIP registration protocol by defining a new
parameter (the UDP-REA and the S-UDP-REA parameter). These parameter (the UDP-REA and the S-UDP-REA parameter). These
parameters need IANA registration: parameters need IANA registration:
TBD: TBD:
Changes to the PATH protocol are made through a standards track Changes to the PATH protocol are made through a standards track
revision of this specification. This document does not create new revision of this specification. This document does not create new
IANA registries. IANA registries.
8. IAB Considerations 9. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing", The IAB has studied the problem of "Unilateral Self Address Fixing
which is the general process by which a client attempts to determine (UNSAF)", which is the general process by which a client attempts to
its address in another realm on the other side of a NAT through a determine its address in another realm on the other side of a NAT
collaborative protocol reflection mechanism (RFC 3424 [15]). PATH is through a collaborative protocol reflection mechanism (RFC 3424
an example of a protocol that performs this type of function. The [17]). PATH is an example of a protocol that performs this type of
IAB has mandated that any protocols developed for this purpose function. The IAB has mandated that any protocols developed for this
document a specific set of considerations. This section meets those purpose document a specific set of considerations. This section
requirements. meets those requirements.
The text in this section heavily borrows from [7]. The text in this section heavily borrows from [9].
8.1 Problem Definition 9.1. Problem Definition
From RFC 3424 [15], any UNSAF proposal must provide: From RFC 3424 [17], any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes generalized to solve other problems; this is why "short term fixes
usually aren't". usually aren't".
The specific problem being solved by PATH is to provide a means for a The specific problem being solved by PATH is to provide a means for a
PATH client to detect the presence of one or more NATs between it and PATH client to detect the presence of one or more NATs between it and
a PATH server. The purpose of such detection is to determine the a PATH server. The purpose of such detection is to determine the
need for UDP encapsulation by the PATH server (i.e., rendezvous need for UDP encapsulation by the PATH server (i.e., rendezvous
server). server).
PATH affect both UDP encapsulation of data traffic (which is IPsec PATH affect both UDP encapsulation of data traffic (which is IPsec
protected) and HIP signaling messages. protected) and HIP signaling messages.
8.2 Exit Strategy 9.2. Exit Strategy
From [15], any UNSAF proposal must provide: From [17], any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed. as the appropriate technology is deployed.
PATH comes with its own built in exit strategy. This strategy is the PATH comes with its own built in exit strategy. This strategy is the
detection operation that is performed as a precursor to the actual detection operation that is performed as a precursor to the actual
UNSAF address-fixing operation. The discovery operation, described UNSAF address-fixing operation. The discovery operation, described
in Section 3.2, attempts to discover the existence of, and type of, in Section 3.2, attempts to discover the existence of, and type of,
any NATS between the client and the PATH server. PATH does not aim any NATS between the client and the PATH server. PATH does not aim
to detect the type of NAT (due to known deficiencies) and the to detect the type of NAT (due to known deficiencies) and the
discovery of the existence of NAT is itself quite robust. As NATs discovery of the existence of NAT is itself quite robust. As NATs
are phased out through the deployment of IPv6, the discovery are phased out through the deployment of IPv6, the discovery
operation will return immediately with the result that there is no operation will return immediately with the result that there is no
NAT, and no further operations are required. Indeed, the discovery NAT, and no further operations are required. Indeed, the discovery
operation itself can be used to help motivate deployment of IPv6; if operation itself can be used to help motivate deployment of IPv6; if
a user detects a NAT between themselves and the public Internet, they a user detects a NAT between themselves and the public Internet, they
can call up their access provider and complain about it. can call up their access provider and complain about it.
PATH can also help to facilitate the introduction of MICOM or NSIS. PATH can also help to facilitate the introduction of MIDCOM or NSIS.
As MIDCOM or NSIS-capable NATs are deployed, HIP end hosts will, As MIDCOM or NSIS-capable NATs are deployed, HIP end hosts will,
instead of using UDP-REA, first allocate an address binding using instead of using UDP-REA, first allocate an address binding using
MIDCOM or NSIS and use S-UDP-REA. However, it is a well-known MIDCOM or NSIS and use S-UDP-REA. However, it is a well-known
limitation of MIDCOM that it only works when the agent knows the limitation of MIDCOM that it only works when the agent knows the
middleboxes through which its traffic will flow. This issue is fixed middleboxes through which its traffic will flow. This issue is fixed
with the path-coupled approach followed in NSIS. Once bindings have with the path-coupled approach followed in NSIS. Once bindings have
been allocated from those middleboxes, a PATH detection procedure can been allocated from those middleboxes, a PATH detection procedure can
validate that there are no additional middleboxes on the path from validate that there are no additional middleboxes on the path from
the PATH server to the PATH client. If this is the case, the HIP end the PATH server to the PATH client. If this is the case, the HIP end
host can continue operation using the address bindings allocated from host can continue operation using the address bindings allocated from
MIDCOM or NSIS. If it is not the case, PATH provides a mechanism for MIDCOM or NSIS. If it is not the case, PATH provides a mechanism for
self-address fixing through the remaining MIDCOM or NSIS-unaware self-address fixing through the remaining MIDCOM or NSIS-unaware
middleboxes. Thus, PATH provides a way to help transition to full middleboxes. Thus, PATH provides a way to help transition to full
MIDCOM or NSIS-aware networks. MIDCOM or NSIS-aware networks.
8.3 Brittleness Introduced by PATH 9.3. Brittleness Introduced by PATH
From [15], any UNSAF proposal must provide: From [17], any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
PATH introduces brittleness into the system in several ways: PATH has its own limitations in several ways:
[EDITOR's NOTE: Depending on the signaling flow and the [EDITOR's NOTE: Depending on the signaling flow and the
involvement of the PATH server some behavior is assumed by NATs. involvement of the PATH server some behavior is assumed by NATs.
There could be other types of NATs that are deployed that would There could be other types of NATs that are deployed that would
not work well with some of the proposed signaling message flows. not work well with some of the proposed signaling message flows.
For some of the message flows the binding acquisition usage of For some of the message flows the binding acquisition usage of
PATH does not work for all NAT types. It will work for any PATH does not work for all NAT types. It will work for any
application for full cone NATs only. For restricted cone and port application running across full cone NATs only. For restricted
restricted cone NAT, it may work for some cases. For symmetric cone and port restricted cone NAT, it may work for some cases.
NATs, the binding acquisition will not yield a usable address (in For symmetric NATs, the binding acquisition will not yield a
case that not all the signaling messages and the entire data usable address (in case that not all the signaling messages and
traffic is routed through the PATH server). The tight dependency the entire data traffic is routed through the PATH server). The
on the specific type of NAT makes the protocol brittle.] tight dependency on the specific type of NAT may limit the
protocol application scenarios.]
PATH assumes that the server exists on the public Internet. If PATH assumes that the server exists on the public Internet. If
the server is located in another private address realm, the HIP the server is located in another private address realm, the HIP
end host may or may not be able to use the established state at end host may or may not be able to use the established state at
the PATH server. This heavily depends on the protocol interaction the PATH server. This heavily depends on the protocol interaction
between the other HIP end host and possibly other PATH servers between the other HIP end host and possibly other PATH servers
than are cascaded. than are cascaded.
The bindings allocated from the NAT need to be continuously The bindings allocated from the NAT need to be continuously
refreshed. Since the timeouts for these bindings is refreshed. Since the timeouts for these bindings is
implementation specific, the refresh interval cannot easily be implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to determined. When the binding is not being actively used to
receive traffic, but to wait for an incoming message, the binding receive traffic, but to wait for an incoming message, the binding
refresh will needlessly consume network bandwidth. refresh will needlessly consume network bandwidth.
The use of the PATH server as an additional network element The use of the PATH server as an additional network element
introduces another point of potential security attack. These introduces another point of potential security attack. These
attacks are largely prevented by the security measures provided attacks are largely prevented by the security measures provided
the HIP registration protocol, but not entirely. the HIP registration protocol, but not entirely.
The use of the PATH server as an additional network element The use of the PATH server as an additional network element
introduces another point of failure. If the client cannot locate introduces another point of failure. If the client cannot locate
a PATH server, or if the server should be unavailable due to a PATH server, or if the server should be unavailable due to
failure, no interaction can be performed. failure, no interaction can be performed.
The use of PATH to enable UDP encapsulation for IPsec protected The use of PATH to enable UDP encapsulation for IPsec protected
data traffic and for HIP messages introduces an additional data traffic and for HIP messages introduces an additional
bandwidth consumption which might be problematic in certain bandwidth consumption which might be problematic in certain
wireless networks. The modified packet forwarding through the wireless networks. The modified packet forwarding through the
PATH server, which might be necessary to ensure traversal of PATH server, which might be necessary to ensure traversal of
certain NAT types, might represent a non-optimal route and may certain NAT types, might represent a non-optimal route and may
increase latency for some applications (depending on the location increase latency for some applications (depending on the location
of the PATH server). of the PATH server).
8.4 Requirements for a Long Term Solution 9.4. Requirements for a Long Term Solution
From [15], any UNSAF proposal must provide: From [17], any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions - Identify requirements for longer term, sound technical solutions -
contribute to the process of finding the right longer term contribute to the process of finding the right longer term
solution. solution.
Our experience with PATH has led to the following requirements for a Our experience with PATH has led to the following requirements for a
long term solution to the NAT problem: long term solution to the NAT problem:
Requests for bindings and control of other resources in a NAT need Requests for bindings and control of other resources in a NAT need
to be explicit. Much of the brittleness in PATH derives from its to be explicit. Much of the brittleness in PATH derives from its
skipping to change at page 25, line 12 skipping to change at page 25, line 26
purpose. Third-party controls are best handled using the MIDCOM purpose. Third-party controls are best handled using the MIDCOM
framework. framework.
Control needs to be limited. Users will need to communicate Control needs to be limited. Users will need to communicate
through NATs which are outside of their administrative control. through NATs which are outside of their administrative control.
In order for providers to be willing to deploy NATs which can be In order for providers to be willing to deploy NATs which can be
controlled by users in different domains, the scope of such controlled by users in different domains, the scope of such
controls needs to be extremely limited - typically, allocating a controls needs to be extremely limited - typically, allocating a
binding to reach the address where the control packets are coming binding to reach the address where the control packets are coming
from. from.
Simplicity is paramount. The control protocol will need to be Simplicity is paramount. The control protocol will need to be
implement in very simple clients. The servers will need to implement in very simple clients. The servers will need to
support extremely high loads. The protocol will need to be support extremely high loads. The protocol will need to be
extremely robust, being the precursor to a host of application extremely robust, being the precursor to a host of application
protocols. As such, simplicity is key. protocols. As such, simplicity is key.
8.5 Issues with Existing NAPT Boxes 9.5. Issues with Existing NAPT Boxes
From [15], any UNSAF proposal must provide: From [17], any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing, deployed NA(P)Ts and experience reports.
Several of the practical issues with PATH involve future proofing - Several of the practical issues with PATH involve future proofing -
breaking the protocol when new NAT types get deployed. Fortunately, breaking the protocol when new NAT types get deployed. Fortunately,
this is not an issue at the current time, since most of the deployed this is not an issue at the current time, since most of the deployed
NATs are of the types assumed by PATH. The primary usage PATH has NATs are of the types assumed by PATH. The primary usage PATH has
been found in the area of VoIP, to facilitate allocation of addresses been found in the area of VoIP, to facilitate allocation of addresses
for receiving RTP [12] traffic. In that application, the periodic for receiving RTP [12] traffic. In that application, the periodic
keepalives are provided by the RTP traffic itself. However, several keepalives are provided by the RTP traffic itself. However, several
practical problems arise for RTP. First, RTP assumes that RTCP practical problems arise for RTP. First, RTP assumes that RTCP
traffic is on a port one higher than the RTP traffic. This pairing traffic is on a port one higher than the RTP traffic. This pairing
skipping to change at page 25, line 50 skipping to change at page 26, line 17
For VoIP, silence suppression can cause a gap in the transmission of For VoIP, silence suppression can cause a gap in the transmission of
RTP packets. This could result in the loss of a binding in the RTP packets. This could result in the loss of a binding in the
middle of a call, if that silence period exceeds the binding timeout. middle of a call, if that silence period exceeds the binding timeout.
This can be mitigated by sending occasional silence packets to keep This can be mitigated by sending occasional silence packets to keep
the binding alive. However, the result is additional brittleness; the binding alive. However, the result is additional brittleness;
proper operation depends on the silence suppression algorithm in use, proper operation depends on the silence suppression algorithm in use,
the usage of a comfort noise codec, the duration of the silence the usage of a comfort noise codec, the duration of the silence
period, and the binding lifetime in the NAT. period, and the binding lifetime in the NAT.
8.6 In Closing 9.6. In Closing
Some of the limitations of PATH are not design flaws. Due to the Some of the limitations of PATH are not design flaws. Due to the
properties of HIP, PATH is fairly secure and robust form of legacy properties of HIP, PATH is fairly secure and robust form of legacy
NAT traversal compared to other approach such as STUN. Some NAT traversal compared to other approach such as STUN. Some
limitations are, however, related to the lack of standardized limitations are, however, related to the lack of standardized
behaviors and controls in NATs. The result of this lack of behaviors and controls in NATs. The result of this lack of
standardization has been a proliferation of devices whose behavior is standardization has been a proliferation of devices whose behavior is
highly unpredictable, extremely variable, and uncontrollable. PATH highly unpredictable, extremely variable, and uncontrollable. PATH
does the best it can in such a hostile environment. Ultimately, the does the best it can in such a hostile environment. Ultimately, the
solution is to make the environment less hostile, and to introduce solution is to make the environment less hostile, and to introduce
controls and standardized behaviors into NAT. However, until such controls and standardized behaviors into NAT. However, until such
time as that happens, PATH provides a good short term solution given time as that happens, PATH provides a good short term solution given
the terrible conditions under which it is forced to operate. PATH the terrible conditions under which it is forced to operate. PATH
also offers a long-term solution if NATs are NSIS or MIDCOM aware. also offers a long-term solution if NATs are NSIS or MIDCOM aware.
The main benefit is increased secure and a less brittle protocol The main benefit is increased secure and a less brittle protocol
operation since the NAT (or even firewalls) can be controlled and operation since the NAT (or even firewalls) can be controlled and
should then behave according to respective middlebox signaling should then behave according to respective middlebox signaling
protocol. Ultimately, NAT boxes might be HIP aware. protocol. Ultimately, NAT boxes might be HIP aware.
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Julien Laganier, Aarthi Nagarajan and The authors would like to thank Aarthi Nagarajan, Abhinav Pathak, and
Murugaraj Shanmugam for their feedback on this document. Murugaraj Shanmugam for their helpful feedbacks on this document.
10. Open Issues The authors would like to specially thank Lars Eggert for his
contribution to previous versions of the draft.
This document is a first attempt in defining HIP NAT/Firewall 11. Open Issues
traversal extensions. The document raises some questions with regard
to the usage of the PATH server and the later flow of data packets.
The document still lacks a number of details which would benefit from
hands-on experience.
11. References Open issues can be found here:
http://www.tschofenig.com:8080/hip-nat/
11.1 Normative References 12. References
[1] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 12.1. Normative References
Rendezvous Extensions", Internet-Draft draft-ietf-hip-rvs-00,
October 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05
Levels", March 1997. (work in progress), March 2006.
[3] Moskowitz, R., "Host Identity Protocol", [2] Nikander, P., "End-Host Mobility and Multihoming with the Host
Internet-Draft draft-ietf-hip-base-01, October 2004. Identity Protocol", draft-ietf-hip-mm-03 (work in progress),
March 2006.
[4] Nikander, P., "End-Host Mobility and Multi-Homing with Host [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Identity Protocol", Internet-Draft draft-ietf-hip-mm-00, October Rendezvous Extension", draft-ietf-hip-rvs-04 (work in progress),
2004. October 2005.
11.2 Informative References [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
12.2. Informative References
[5] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [5] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
[6] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. [6] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948,
January 2005. January 2005.
[7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
Simple Traversal of User Datagram Protocol (UDP) Through December 2005.
Network Address Translators (NATs)", RFC 3489, March 2003.
[8] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [8] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET)
Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. mode for ESP", draft-nikander-esp-beet-mode-05 (work in
progress), February 2006.
[9] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol [9] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
(NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October - Simple Traversal of User Datagram Protocol (UDP) Through
2004. Network Address Translators (NATs)", RFC 3489, March 2003.
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [10] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[11] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", [11] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
Internet-Draft draft-ietf-ipsec-nat-t-ike-08, February 2004. (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
February 2006.
[12] Tschofenig, H., Nagarajan, A., Torvinen, V. and J. Ylitalo, [12] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
"NAT and Firewall Traversal for HIP", RFC 4306, December 2005.
Internet-Draft draft-tschofenig-hiprg-natfw-traversal-01.txt,
February 2005.
[13] Laganier, J., Koponen, T. and L. Eggert, "A Middlebox [13] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
Registration Protocol for HIP", "Negotiation of NAT-Traversal in the IKE", RFC 3947,
Internet-Draft draft-koponen-hip-registration-00.txt, February January 2005.
2005.
[14] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", [14] Tschofenig, H. and M. Shanmugam, "Traversing HIP-aware NATs and
Internet-Draft draft-dupont-mipv6-3bombing-01, January 2005. Firewalls: Problem Statement and Requirements",
draft-tschofenig-hiprg-hip-natfw-traversal-03 (work in
progress), October 2005.
[15] Daigle, L. and IAB, "IAB Considerations for UNilateral [15] Laganier, J., "Host Identity Protocol (HIP) Registration
Self-Address Fixing (UNSAF) Across Network Address Extension", draft-ietf-hip-registration-01 (work in progress),
Translation", RFC 3424, November 2002. December 2005.
[16] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, [16] Dupont, F., "A note about 3rd party bombing in Mobile IPv6",
"Negotiation of NAT-Traversal in the IKE", RFC 3947, January draft-dupont-mipv6-3bombing-03 (work in progress),
2005. December 2005.
[17] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002.
Authors' Addresses Authors' Addresses
Pekka Nikander Pekka Nikander
Ericsson Research Nomadic Lab Ericsson Research Nomadic Lab
Hirsalantie 11 Hirsalantie 11
Turku FIN FIN-02420 JORVAS Turku FIN FIN-02420 JORVAS
Finland Finland
Phone: +358 9 299 1 Phone: +358 9 299 1
skipping to change at page 30, line 41 skipping to change at page 31, line 25
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Xiaoming Fu
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Thomas R. Henderson Thomas R. Henderson
The Boeing Company The Boeing Company
P.O. Box 3707 P.O. Box 3707
Seattle, WA Seattle, WA
USA USA
Email: thomas.r.henderson@boeing.com Email: thomas.r.henderson@boeing.com
Lars Eggert
NEC Network Laboratories
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 43
Email: lars.eggert@netlab.nec.de
Julien Laganier Julien Laganier
Sun Labs (Sun Microsystems) and LIP (CNRS/INRIA/ENSL/UCBL) DoCoMo Communications Laboratories Europe GmbH
180, Avenue de l'Europe DoCoMo Communications Laboratories Europe GmbH
Saint Ismier CEDEX 38334 Munich 80687
France Germany
Phone: +33 476 188 815 Phone: +49 89 56824 231
Email: ju@sun.com Email: julien.ietf@laposte.net
URI: http://research.sun.com URI: http://www.docomolab-euro.com/
Intellectual Property Statement Intellectual Property Statement
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 32, line 41 skipping to change at page 33, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 141 change blocks. 
419 lines changed or deleted 490 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/