< draft-ford-midcom-p2p-02.txt   draft-ford-midcom-p2p-03.txt >
Internet Draft B. Ford Internet Draft B. Ford
Document: draft-ford-midcom-p2p-02.txt M.I.T. Document: draft-ford-midcom-p2p-03.txt M.I.T.
Expires: September 25, 2004 P. Srisuresh Expires: December 12, 2004 P. Srisuresh
Caymas Systems Caymas Systems
D. Kegel D. Kegel
kegel.com kegel.com
March 2004 June 2004
Peer-to-Peer(P2P) communication across Network Address Translators(NAT) Peer-to-Peer(P2P) communication
across Network Address Translators(NATs)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet- Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference 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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Distribution of this document is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo documents the methods used by the current peer-to-peer This memo documents the methods used by the current TCP/UDP based
(P2P) applications to communicate in the presence of network peer-to-peer (P2P) applications to communicate in the presence of
address translators (NAT). In addition, the memo suggests network address translators (NATs). In addition, the memo
guidelines to application designers and NAT implementers on the suggests guidelines to application designers and NAT implementers
measures they could take to enable immediate, wide deployment of on the measures they could take to enable immediate, wide
P2P applications with or without requiring the use of special deployment of P2P applications with or without requiring the use
proxy, relay or midcom protocols. of special proxy, relay or midcom protocols.
Table of Contents Table of Contents
1. Introduction ................................................. 1. Introduction .................................................
2. Terminology .................................................. 2. Terminology ..................................................
3. Techniques for P2P communication across NAT devices .......... 3. Techniques used by NAT-friendly P2P applications .............
3.1. Relaying ............................................... 3.1. Relaying ................................................
3.2. Connection reversal .................................... 3.2. Connection reversal .....................................
3.3. UDP Hole Punching ...................................... 3.3. UDP Hole Punching .......................................
3.3.1. Peers behind different NATs .................... 3.3.1. Peers behind different NATs ......................
3.3.2. Peers behind the same NAT ...................... 3.3.2. Peers behind the same NAT ........................
3.3.3. Peers separated by multiple NATs ............... 3.3.3. Peers separated by multiple NATs .................
3.3.4. Consistent port bindings ....................... 3.3.4. Assumption of P2P-friendly NAT devices enroute ...
3.4. UDP Port number prediction ............................. 3.4. Simultaneous TCP Open ...................................
3.5. Simultaneous TCP open .................................. 3.5. UDP port number prediction ..............................
4. Application design guidelines ................................ 3.6. TCP port number prediction ..............................
4. NAT-friendly P2P application design guidelines ...............
4.1. What works with P2P NAT devices ......................... 4.1. What works with P2P NAT devices .........................
4.2. Applications behind the same NAT ........................ 4.2. Peers behind the same NAT ...............................
4.3. Peer discovery .......................................... 4.3. Peer discovery ..........................................
4.4. TCP applications using sockets API ...................... 4.4. Use of midcom protocol ..................................
4.5. Use of midcom protocol .................................. 5. P2P-friendly NAT design guidelines ...........................
5. NAT design guidelines ........................................
5.1. Deprecate the use of symmetric NATs ..................... 5.1. Deprecate the use of symmetric NATs .....................
5.2. Add incremental Cone-NAT support to symmetric NAT devices 5.2. Add incremental Cone-NAT support to symmetric NATs ......
5.3. Support Address and port bindings ....................... 5.3. Simultaneous TCP Open support in Cone NATs ..............
5.3.1. Preserving Port Numbers ......................... 5.4. Port preservation is not important ......................
5.3.2. Support TCP port bindings ....................... 5.5. Large timeout for P2P applications ......................
5.4. Large timeout for P2P applications ...................... 5.6. Support loopback translation ............................
5.5. Support loopback translation ............................ 5.7. Support midcom protocol .................................
5.6. Support midcom protocol .................................
6. Security considerations ...................................... 6. Security considerations ......................................
6.1. IP address aliasing .....................................
6.2. Denial-of-service attacks ...............................
6.3. Man-in-the-middle attacks ...............................
6.4. Impact on NAT device security ...........................
7. Acknowledgments ..............................................
8. Informative References ........................................
1. Introduction 1. Introduction
Present-day Internet has seen ubiquitous deployment of network Present-day Internet has seen ubiquitous deployment of network
address translators (NAT), driven primarily by the ongoing depletion address translators (NATs). There are a variety of NAT devices in
of the IPv4 address space. There are a variety of NAT devices in use. The asymmetric addressing and connectivity regimes established
use. Readers are urged to refer [NAT-TERM] to learn of NAT varieties by the NAT devices has created unique problems for peer-to-peer
and their definition. Of the various NAT devices, traditional NAT (P2P) applications and protocols, such as teleconferencing and
[TRAD-NAT] is the most common type of NAT device. The asymmetric multiplayer on-line gaming. These issues are likely to persist even
addressing and connectivity regimes established by the NAT devices into the IPv6 world, where a NAT is used as an IPv4 compatibility
has created unique problems for peer-to-peer (P2P) applications and mechanism [NAT-PT].
protocols, such as teleconferencing and multiplayer on-line gaming.
These issues are likely to persist even into the IPv6 world, where
NAT is often used as an IPv4 compatibility mechanism [NAT-PT], and
firewalls will still be commonplace even after NAT is no longer
required.
Currently deployed NAT devices are designed primarily around the Currently deployed NAT devices are designed primarily around the
client/server paradigm, in which relatively anonymous client machines client/server paradigm, in which relatively anonymous client machines
inside a private network initiate connections to public servers with inside a private network initiate connections to public servers with
stable IP addresses and DNS names. NAT devices enroute provide stable IP addresses and DNS names. NAT devices encountered enroute
dynamic address assignment. The anonymity and inaccessibility of provide dynamic address assignment for the client machines. The
the internal hosts behind a NAT device is not a problem for client anonymity and inaccessibility of the internal hosts behind a NAT
software such as web browsers, which only need to initiate outgoing device is not a problem for applications such as web browsers, which
connections. This inaccessibility is sometimes seen as a privacy only need to initiate outgoing connections. This inaccessibility is
benefit. sometimes seen as a privacy benefit.
In the peer-to-peer paradigm, however, Internet hosts that would In the peer-to-peer paradigm, however, Internet hosts that would
normally be considered "clients" need to establish communication normally be considered "clients" need to establish communication
sessions directly with each other. The initiator and the responder sessions directly with each other. The initiator and the responder
might lie behind different NAT devices with neither endpoint might lie behind different NAT devices with neither endpoint
having a permanent IP address or other form of public network having a permanent IP address or other form of public network
presence. A common on-line gaming architecture, for example, presence. A common on-line gaming architecture, for example,
is for the participating application hosts to contact a well-known is for the participating application hosts to contact a well-known
server for initialization and administration purposes. Subsequent server for initialization and administration purposes. Subsequent
to this, the hosts establish direct connections with each other to this, the hosts establish direct connections with each other
for fast and efficient propagation of updates during game play. for fast and efficient propagation of updates during game play.
Similarly, a file sharing application might contact a well-known Similarly, a file sharing application might contact a well-known
server for resource discovery or searching, but establish direct server for resource discovery or searching, but establish direct
connections with peer hosts for data transfer. NAT devices create connections with peer hosts for data transfer. NAT devices create
problems for peer-to-peer connections because hosts behind a problems for peer-to-peer connections because hosts behind a
NAT device normally have no permanently visible public ports on the NAT device normally have no permanently visible public ports on the
Internet to which incoming TCP or UDP connections from other peers Internet to which incoming TCP or UDP connections from other peers
can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue, can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue,
but does not offer any general solutions. but does not offer any general solutions.
In this document we address the P2P/NAT problem in two ways. In this document, we address the P2P/NAT problem in two ways.
First, we summarize known methods by which P2P applications can First, we summarize the currently known methods by which P2P
work around the presence of NAT devices. Second, we provide a set applications work around the presence of NAT devices. Second, we
of application design guidelines based on these practices to make offer a set of application design guidelines based on these
P2P applications operate more robustly over currently-deployed practices to make P2P applications operate more robustly over
NAT devices. Further, we provide design guidelines for future currently-deployed NAT devices. Further, we suggest design
NAT device implementers to allow them to support P2P applications guidelines for NAT implementers so as to make the NAT device more
more effectively. Our focus is to enable immediate and wide P2P application friendly. The objective is to enable immediate and
deployment of P2P applications requiring to traverse NAT devices. wide deployment of P2P applications requiring to traverse NAT
devices.
2. Terminology 2. Terminology
Readers are urged to refer [NAT-TERM] for information on NAT Readers are urged to refer [NAT-TERM] for information on NAT
taxonomy and terminology. Traditional NAT is the most common type taxonomy and terminology. Traditional NAT is the most common type
of NAT device deployed. Readers may refer [NAT-TRAD] for detailed of NAT device deployed. Readers may refer [NAT-TRAD] for detailed
information on traditional NAT. Traditional NAT has two main information on traditional NAT. Traditional NAT has two main
varieties - Basic NAT and Network Address/Port Translator (NAPT). varieties - Basic NAT and Network Address/Port Translator (NAPT).
NAPT is by far the most commonly deployed NAT device. NAPT allows NAPT is by far the most commonly deployed NAT device. NAPT allows
skipping to change at page 4, line 15 skipping to change at page 4, line 17
simultaneously. When an internal host opens an outgoing TCP or UDP simultaneously. When an internal host opens an outgoing TCP or UDP
session through a NAPT, the NAPT assigns the session a public IP session through a NAPT, the NAPT assigns the session a public IP
address and port number so that subsequent response packets from address and port number so that subsequent response packets from
the external endpoint can be received by the NAPT, translated, and the external endpoint can be received by the NAPT, translated, and
forwarded to the internal host. The effect is that the NAPT forwarded to the internal host. The effect is that the NAPT
establishes a NAT session to translate the (private IP address, establishes a NAT session to translate the (private IP address,
private port number) tuple to (public IP address, public port private port number) tuple to (public IP address, public port
number) tuple and vice versa for the duration of the session. An number) tuple and vice versa for the duration of the session. An
issue of relevance to P2P applications is how the NAT behaves when issue of relevance to P2P applications is how the NAT behaves when
an internal host initiates multiple simultaneous sessions from a an internal host initiates multiple simultaneous sessions from a
single (private IP, private port) pair to multiple distinct single (private IP, private port) endpoint to multiple distinct
endpoints on the external network. endpoints on the external network.
Additional terms that further classify NAPT implementation are Additional terms that further classify NAPT implementation are
defined in more recent work [STUN] and are summarized below. defined in more recent work [STUN] and are summarized below.
Cone NAT Cone NAT
The fundamental property of Cone NAT is that it reuses port The fundamental property of Cone NAT is that it reuses port
port binding between a (private IP, private port) tuple and a binding assigned to a private host endpoint (identified by
(public IP, public port) tuple for multiple sessions an the combination of private IP address and protocol specific
application may initiate from the same private IP address and port number) for all sessions initiated by the private host
port number. from the same endpoint, while the port binding is alive. Cone
NAT creates port binding between a (private IP, private port)
tuple and a (public IP, public port) tuple for translation
purposes.
For example, suppose Client A in the diagram below initiates two For example, suppose Client A in figure 1 initiates two
simultaneous outgoing sessions through a cone NAT, from the same simultaneous outgoing sessions through a cone NAT, from the same
internal endpoint (10.0.0.1:1234) to two different internal endpoint (10.0.0.1:1234) to two different external
external servers, S1 and S2. The cone NAT assigns just one public servers, S1 and S2. The cone NAT assigns just one public endpoint
endpoint tuple, 155.99.25.11:62000, to both of these sessions, 155.99.25.11:62000 to both these sessions, ensuring that the
ensuring that the "identity" of the client's port is maintained "identity" of the client's endpoint is maintained across address
across address translation. Since Basic-NAT devices do not modify translation. Since Basic-NAT devices do not modify port numbers
port numbers as packets traverse the device, Basic-NAT device as packets traverse the device, Basic-NAT device can be viewed
can be viewed as a degenerate form of Cone NAT. as a degenerate form of Cone NAT.
Server S1 Server S2 Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235 18.181.0.31:1235 138.76.29.7:1235
| | | |
| | | |
+----------------------+----------------------+ +----------------------+----------------------+
| |
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 | | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
| 155.99.25.11:62000 | | | 155.99.25.11:62000 | | 155.99.25.11:62000 | | | 155.99.25.11:62000 |
skipping to change at page 5, line 33 skipping to change at page 5, line 33
| 18.181.0.31:1235 | | | 138.76.29.7:1235 | | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
| 10.0.0.1:1234 | | | 10.0.0.1:1234 | | 10.0.0.1:1234 | | | 10.0.0.1:1234 |
| |
Client A Client A
10.0.0.1:1234 10.0.0.1:1234
Figure 1: Cone NAT - Reuse of port binding for multiple sessions Figure 1: Cone NAT - Reuse of port binding for multiple sessions
Symmetric NAT Symmetric NAT
A symmetric NAT, in contrast, does not use port bindings. A symmetric NAT, in contrast, does not use port bindings.
Instead, it assigns a new public port to each new session. A Symmetric NAT assigns a new public port to each new session
For example, suppose Client A initiates two outgoing sessions traversing the NAT device. For example, suppose Client A in
from the same port as above, one with S1 and one with S2. A figure 2 initiates two outgoing sessions from the same endpoint,
symmetric NAT might allocate the public endpoint one with S1 and another with S2. The same client endpoint is
155.99.25.11:62000 to session 1, and then allocate a different connecting to the two external servers S1 and S2. When the first
public endpoint 155.99.25.11:62001, when the application session to server S1 traverses the symmetric NAT, the symmetric
initiates session 2. The NAT is able to differentiate NAT assigns port 62000 to translate the client end-point. When
between the two sessions for translation purposes because the the second session from the same client end-point to server S2
external endpoints involved in the sessions (those of S1 traverses the symmetric NAT, the symmetric NAT will assign a
and S2) differ, even as the endpoint identity of the client different port 62001 to translate the same client end-point. As
application is lost across the address translation boundary. a result, server S1 sees the client endpoint as
155.99.25.11:62000, whereas server S2 sees the same client
endpoint differently as 155.99.25.11:62001. The symmetric NAT,
however, is able to differentiate between the two sessions for
translation purposes because the external endpoints involved in
the two sessions (those of S1 and S2) differ, even as the
endpoint identity of the client application is lost across the
address translation boundary.
Server S1 Server S2 Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235 18.181.0.31:1235 138.76.29.7:1235
| | | |
| | | |
+----------------------+----------------------+ +----------------------+----------------------+
| |
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 | | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
| 155.99.25.11:62000 | | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | | 155.99.25.11:62001 |
skipping to change at page 6, line 33 skipping to change at page 6, line 33
| 18.181.0.31:1235 | | | 138.76.29.7:1235 | | 18.181.0.31:1235 | | | 138.76.29.7:1235 |
| 10.0.0.1:1234 | | | 10.0.0.1:1234 | | 10.0.0.1:1234 | | | 10.0.0.1:1234 |
| |
Client A Client A
10.0.0.1:1234 10.0.0.1:1234
Figure 2: Symmetric NAT - Port binding not in use for sessions Figure 2: Symmetric NAT - Port binding not in use for sessions
Cone NAT is further classified according to how liberally the NAT Cone NAT is further classified according to how liberally the NAT
accepts incoming traffic directed to an already-established (public accepts incoming traffic directed to an already-established (public
IP, public port) pair. This classification generally applies only IP, public port) tuple. The following Cone NAT variations are
to UDP traffic, since NATs and firewalls reject incoming TCP defined in [STUN], but restated here for additional explanation.
connection attempts unconditionally unless specifically configured This classification generally applies only to UDP traffic, since
to do otherwise. The following Cone NAT variations are defined in NATs reject incoming TCP connection attempts unconditionally
[STUN], but restated here for additional explanation. unless specifically configured to do otherwise.
Full Cone NAT Full Cone NAT
Subsequent to establishing port binding at the start of an Subsequent to establishing port binding at the start of an
outgoing session, a full cone NAT will accept incoming traffic outgoing session, a full cone NAT will accept incoming traffic
to the corresponding public port from ANY external endpoint on to the corresponding public port from ANY external endpoint on
the public network. Full cone NAT is also sometimes referred the public network. Full cone NAT is also sometimes referred
as "promiscuous" NAT. as "promiscuous" NAT.
Address Restricted Cone NAT Address-restricted Cone NAT
Subsequent to establishing port binding at the start of an Subsequent to establishing port binding at the start of an
outgoing session, Address Restricted Cone NAT will accept outgoing session, Address-restricted Cone NAT will accept
incoming traffic to the corresponding public port from only incoming traffic to the corresponding public port from only
those external endpoints whose IP address match the address those external endpoints whose IP address match the address
of a node to which the internal host has previously sent one of a node to which the internal host has previously sent one
or more outgoing packets. or more outgoing packets.
Port Restricted Cone NAT Port-restricted Cone NAT
Subsequent to establishing port binding at the start of an Subsequent to establishing port binding at the start of an
outgoing session, Port Restricted Cone NAT will accept outgoing session, Port-restricted Cone NAT will accept
incoming traffic to the corresponding public port from only incoming traffic to the corresponding public port from only
those external endpoints to which the internal host has those external endpoints to which the internal host has
previously sent one or more outgoing packets. Port Restricted previously sent one or more outgoing packets. Port-restricted
Cone NAT is the true-to-spirit implementation of NAPT, as Cone NAT is the true-to-spirit implementation of NAPT, as
defined. Port Restricted Cone NAT provides internal nodes the defined.
same level of protection against unsolicited incoming traffic
as does a symmetric NAT, while maintaining a private port's Port-restricted Cone NAT provides internal nodes the same
identity across multiple sessions. level of protection against unsolicited incoming UDP traffic
as does a symmetric NAT. This is because Port-restricted Cone
NAT and Symmetric NAT have one thing in common. They both
maintain granular NAT-sessions. I.e., every single 5-tuple UDP
session permitted for traversal by the NAT is maintained within
the NAT as a NAT-session. As a result, incoming packet traffic
is limited to only those sessions for which the NAT is aware of
an outgoing NAT-session.
This is not the case with Address-restricted Cone NAT and Full
Cone NAT. NAT sessions maintained by Address-restricted Cone
NAT and Full Cone NAT are less granular. The NAT-sessions
maintained by an Address-restricted Cone NAT, for example, use
wildcard match on the external UDP port. The NAT-sessions
maintained by a Full Cone NAT, for example, use wildcard match
on the external address as well as the external UDP port. As a
result, the NAT will permit new UDP sessions initiated from an
external endpoint to the public port bound to the private
endpoint, even as the private endpoint did not originate an
outgoing session to the external endpoint. Address-restricted
Cone NAT as well as Full Cone NAT will permit traversal of the
new incoming session traffic.
Finally, we define the following new terms for classifying Finally, we define the following new terms for classifying
P2P-relevant behavior across middleboxes. Readers are urged to P2P-relevant behavior across middleboxes. Readers are urged to
refer [MIDCOM-FW] for information on middlebox terms and refer [MIDCOM-FW] for information on middlebox terms and
communication framework. communication framework.
P2P-Application P2P-Application
P2P-application as used in this document is an application in P2P-application as used in this document is an application in
which each P2P participant registers with a public which each P2P participant registers with a public
registration server, and subsequently uses either its registration server, and subsequently uses either its
private endpoint, or public endpoint, or both, to establish private endpoint, or public endpoint, or both, to establish
peering sessions. peering sessions.
P2P-Middlebox NAT-friendly P2P application
A P2P-Middlebox is middlebox that permits the traversal of NAT-friendly P2P application is a P2P application that is
P2P applications. designed to work effectively even as peering nodes are
located in multiple distinct IP address realms, connected
P2P-firewall by one or more NATs.
A P2P-firewall is a P2P-Middlebox that provides firewall
functionality but performs no address translation.
P2P-NAT P2P-friendly NAT
A P2P-NAT is a P2P-Middlebox that provides NAT functionality. P2P-friendly NAT is a NAT device that permits the traversal
of P2P application traffic across itself. A key requirement
for a P2P-friendly NAT is the ability to maintain endpoint
identity of a P2P application host when the P2P application
is initiated. All variations of Cone NAT are good examples
of P2P-friendly NAT devices. Symmetric NAT is a good example
of a NAT device that is not P2P friendly.
Loopback translation / Hairpin translation Loopback translation / Hairpin translation
When a host in the private domain of a NAT device attempts to When a host in the private domain of a NAT device attempts to
connect with another host behind the same NAT device using connect with another host behind the same NAT device using
the public address of the host, the NAT device performs the the public address of the host, the NAT device performs the
equivalent of a "Twice-nat" translation on the packet as equivalent of a "Twice-nat" translation on the packet as
follows. The originating host's private endpoint is translated follows. The originating host's private endpoint is translated
into its assigned public endpoint, and the target host's public into its assigned public endpoint, and the target host's public
endpoint is translated into its private endpoint, before endpoint is translated into its private endpoint, before
the packet is forwarded to the target host. We refer the above the packet is forwarded to the target host. We refer the above
translation performed by a NAT device as "Loopback translation". translation performed by a NAT device as "Loopback translation".
This is also referred sometimes as "Hairpin translation". This is also referred sometimes as "Hairpin translation".
3. Techniques for P2P Communication across NAT devices 3. Techniques used by NAT-friendly P2P applications
This section reviews in detail the currently known techniques for This section reviews in detail the currently known techniques for
implementing peer-to-peer communication over existing NAT devices, implementing peer-to-peer communication over existing NAT devices,
from the perspective of the application or protocol designer. The from the perspective of the application or protocol designer. The
readers will note that the applications assume an Address/Port readers will note that the applications assume an
Restricted Cone NAT in majority of the cases below. Address/Port-restricted Cone NAT in majority of the cases below.
3.1. Relaying 3.1. Relaying
The most reliable, but least efficient, method of implementing peer- The most reliable, but least efficient method of implementing peer-
to-peer communication in the presence of a NAT device is to make the to-peer communication in the presence of a NAT device is to make the
peer-to-peer communication look to the network like client/server peer-to-peer communication look to the network like client/server
communication through relaying. For example, suppose two client communication through relaying. For example, suppose two client
hosts, A and B, have each initiated TCP or UDP connections with a hosts A and B, in figure 3, have each initiated TCP or UDP
well-known server S having a permanent IP address. The clients connections to a well-known server S, which has a permanent IP
reside on separate private networks, however, and their respective address. The clients reside on separate private networks, and
NAT devices prevent either client from directly initiating a their respective NAT devices prevent either client from directly
connection to the other. initiating a connection to the other.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
+----------------------------+----------------------------+ +----------------------------+----------------------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | |
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
| 155.99.25.11 | | 138.76.29.7 | | 155.99.25.11 | | 138.76.29.7 |
| | | | | | | |
| Address/Port | | Address/port | | Symmetric or | | Symmetric or |
| Restricted | | Restricted | | Cone NAT A | | Cone NAT B |
| Cone-NAT A | | Cone-NAT B |
+--------------+ +--------------+ +--------------+ +--------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| | | |
| | | |
Client A Client B Client A Client B
10.0.0.1:1234 10.1.1.3:1234 10.0.0.1:1234 10.1.1.3:1234
Figure 3: Use Client-Server session for Indirect-P2P communication Figure 3: Use of Client-Server sessions & relay server to emulate P2P
Instead of attempting a direct connection, the two clients can simply Instead of attempting a direct connection, the two clients can simply
use the server S to relay messages between them. For example, to use the server S to relay messages between them. For example, to
send a message to client B, client A simply sends the message to send a message to client B, client A simply sends the message to
server S along its already-established client/server connection, and server S along its already-established client/server connection, and
server S then sends the message on to client B using its existing server S then sends the message on to client B using its existing
client/server connection with B. client/server connection with B.
This method has the advantage that it will always work as long as This method has the advantage that it will always work as long as
both clients have connectivity to the server. Its obvious both clients have connectivity to the server. The enroute NAT device
disadvantages are that it consumes the server's processing power and is not assumed to be P2P friendly. Its obvious disadvantages are that
network bandwidth, and communication latency between the peering it consumes the server's processing power and network bandwidth, and
clients is likely to be increased even if the server is well- communication latency between the peering clients is likely to be
connected. The TURN protocol [TURN] defines a method of implementing increased even if the server is well-connected. The TURN protocol
relaying in a relatively secure fashion. [TURN] defines a method of implementing relaying in a relatively
secure fashion.
3.2. Connection reversal 3.2. Connection reversal
The following connection reversal technique for a direct P2P The following connection reversal technique for a direct P2P
communication works only when one of the clients (i.e., peers) is communication works only when one of the clients (i.e., peers) is
behind a NAT device. For example, suppose client A is behind a NAT behind a NAT device. For example, suppose client A is behind a NAT
but client B has a globally routable IP address, as in figure 4. but client B has a globally routable IP address, as in figure 4.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
skipping to change at page 10, line 23 skipping to change at page 10, line 23
| | | |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | | | ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 138.76.29.7:1234 | | 155.99.25.11:62000 | | | | 138.76.29.7:1234 | | 155.99.25.11:62000 | |
| | 155.99.25.11:62000 | v 138.76.29.7:31000 v | | | 155.99.25.11:62000 | v 138.76.29.7:31000 v |
| | | |
+--------------+ | +--------------+ |
| 155.99.25.11 | | | 155.99.25.11 | |
| | | | | |
| Address/Port | | | Address/Port | |
| Restricted | | | Restricted | |
| Cone-NAT A | | | Cone NAT A | |
+--------------+ | +--------------+ |
| | | |
| ^ Relay-Req Session(A-S) ^ | | ^ Relay-Req Session(A-S) ^ |
| | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | |
| | 10.0.0.1:1234 | | | | 10.0.0.1:1234 | |
| | | |
| ^ P2P Session (A-B) ^ | | ^ P2P Session (A-B) ^ |
| | 138.76.29.7:1234 | | | | 138.76.29.7:1234 | |
| | 10.0.0.1:1234 | | | | 10.0.0.1:1234 | |
| | | |
skipping to change at page 11, line 21 skipping to change at page 11, line 21
outgoing connections are allowed. outgoing connections are allowed.
After attempting and failing to establish a direct connection to A, After attempting and failing to establish a direct connection to A,
client B can use server S to relay a request to client A to initiate client B can use server S to relay a request to client A to initiate
a "reversed" connection to client B. Client A, upon receiving this a "reversed" connection to client B. Client A, upon receiving this
relayed request through S, opens a TCP connection to client B at B's relayed request through S, opens a TCP connection to client B at B's
public IP address and port number. NAT A allows the connection to public IP address and port number. NAT A allows the connection to
proceed because it is originating inside the firewall, and client B proceed because it is originating inside the firewall, and client B
can receive the connection because it is not behind a NAT device. can receive the connection because it is not behind a NAT device.
A variety of current peer-to-peer systems implement this technique. A variety of current peer-to-peer applications implement this
Its main limitation, of course, is that it only works as long as only technique. Its main limitation, of course, is that it only works so
one of the communicating peers is behind a NAT: in the increasingly long as only one of the communicating peers is behind a NAT and the
common case where both peers are behind NATs, the method fails. NAT is P2P-friendly, such as a Cone NAT. In the increasingly common
Because connection reversal is not a general solution to the problem, case where both peers can be behind NATs, the method fails. Because
it is NOT recommended as a primary strategy. Applications may choose connection reversal is not a general solution to the problem, it is
to attempt connection reversal, but should be able to fall back NOT recommended as a primary strategy. NAT-friendly P2P
automatically on another mechanism such as relaying if neither a applications may choose to attempt connection reversal, but should
"forward" nor a "reverse" connection can be established. be able to fall back automatically to another mechanism such as
relaying if neither a "forward" nor a "reverse" connection can be
established.
3.3. UDP hole punching 3.3. UDP hole punching
The third technique, and the one of primary interest in this The "UDP hole punching" technique is the most popular and effective
document, is widely known as "UDP Hole Punching." UDP hole punching of all the techniques described thus far. UDP hole punching
relies on the properties of common firewalls and cone NATs to allow relies on the properties of common firewalls and cone NATs to allow
appropriately designed peer-to-peer applications to "punch holes" appropriately designed peer-to-peer applications to "punch holes"
through the NAT device and establish direct connectivity with each through the NAT device and establish direct connectivity with each
other, even when both communicating hosts may lie behind NAT devices. other, even when both communicating hosts lie behind NAT devices.
This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT- This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-
PROT], and has been informally described elsewhere on the Internet PROT], described in [KEGEL], and used in some recent protocols
[KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name [TEREDO, ICE]. This technique has been used primarily with UDP
implies, unfortunately, this technique works reliably only with UDP. applications, but not as reliably with TCP applications. Readers
may refer Section 3.4 for details on "Simultaneous TCP open", also
known sometimes as "TCP hole punching".
We will consider two specific scenarios, and how applications can be We will consider two specific scenarios, and how applications can be
designed to handle both of them gracefully. In the first situation, designed to handle both of them gracefully. In the first situation,
representing the common case, two clients desiring direct peer-to- representing the common case, two clients desiring direct peer-to-
peer communication reside behind two different NATs. In the second, peer communication reside behind two different NATs. In the second,
the two clients actually reside behind the same NAT, but do not the two clients actually reside behind the same NAT, but do not
necessarily know that they do. necessarily know that they do.
3.3.1. Peers behind different NATs 3.3.1. Peers behind different NATs
Suppose clients A and B both have private IP addresses and lie behind Suppose clients A and B both have private IP addresses and lie behind
different network address translators. The peer-to-peer application different network address translators as in figure 5. The
running on clients A and B and on server S each use UDP port 1234. A peer-to-peer application running on clients A and B and on server S
and B have each initiated UDP communication sessions with server S, each use UDP port 1234. A and B have each initiated UDP communication
causing NAT A to assign its own public UDP port 62000 for A's session sessions with server S, causing NAT A to assign its own public UDP
with S, and causing NAT B to assign its port 31000 to B's session port 62000 for A's session with S, and causing NAT B to assign its
with S, respectively. port 31000 to B's session with S, respectively.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
+----------------------------+----------------------------+ +----------------------------+----------------------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | |
| | | |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 138.76.29.7:31000 | | 155.99.25.11:62000 | | | | 138.76.29.7:31000 | | 155.99.25.11:62000 | |
| | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | |
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
| 155.99.25.11 | | 138.76.29.7 | | 155.99.25.11 | | 138.76.29.7 |
| | | | | | | |
| Address/Port | | Address/port | | Address/Port | | Address/port |
| Restricted | | Restricted | | Restricted | | Restricted |
| Cone-NAT A | | Cone-NAT B | | Cone NAT A | | Cone NAT B |
+--------------+ +--------------+ +--------------+ +--------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| | | |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ | | ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 138.76.29.7:31000 | | 155.99.25.11:62000 | | | | 138.76.29.7:31000 | | 155.99.25.11:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| | | |
skipping to change at page 13, line 6 skipping to change at page 13, line 10
Figure 5: Coordinate simultaneous outgoing sessions for Direct-P2P Figure 5: Coordinate simultaneous outgoing sessions for Direct-P2P
Now suppose that client A wants to establish a UDP communication Now suppose that client A wants to establish a UDP communication
session directly with client B. If A simply starts sending UDP session directly with client B. If A simply starts sending UDP
messages to B's public address, 138.76.29.7:31000, then NAT B will messages to B's public address, 138.76.29.7:31000, then NAT B will
typically discard these incoming messages (unless it is a full cone typically discard these incoming messages (unless it is a full cone
NAT), because the source address and port number does not match those NAT), because the source address and port number does not match those
of S, with which the original outgoing session was established. of S, with which the original outgoing session was established.
Similarly, if B simply starts sending UDP messages to A's public Similarly, if B simply starts sending UDP messages to A's public
address, then NAT A will typically discard these messages. address and port number, then NAT A will typically discard these
messages.
Suppose A starts sending UDP messages to B's public address, however, Suppose A starts sending UDP messages to B's public address, however,
and simultaneously relays a request through server S to B, asking B and simultaneously relays a request through server S to B, asking B
to start sending UDP messages to A's public address. A's outgoing to start sending UDP messages to A's public address. A's outgoing
messages directed to B's public address (138.76.29.7:31000) cause NAT messages directed to B's public address (138.76.29.7:31000) cause NAT
A to open up a new communication session between A's private address A to open up a new communication session between A's private address
and B's public address. At the same time, B's messages to A's public and B's public address. At the same time, B's messages to A's public
address (155.99.25.11:62000) cause NAT B to open up a new address (155.99.25.11:62000) cause NAT B to open up a new
communication session between B's private address and A's public communication session between B's private address and A's public
address. Once the new UDP sessions have been opened up in each address. Once the new UDP sessions have been opened up in each
direction, client A and B can communicate with each other directly direction, client A and B can communicate with each other directly
without further burden on the "introduction" server S. without further burden on the "introduction" server S.
The UDP hole punching technique has several useful properties. Once The UDP hole punching technique has several useful properties. Once
a direct peer-to-peer UDP connection has been established between two a direct peer-to-peer UDP connection has been established between two
clients behind NAT devices, either party on that connection can in clients behind NAT devices, either party on that connection can in
turn take over the role of "introducer" and help the other party turn take over the role of "introducer" and help the other party
establish peer-to-peer connections with additional peers, minimizing establish peer-to-peer connections with additional peers, minimizing
the load on the initial introduction server S. The application does the load on the initial introduction server S. The application does
not need to attempt to detect the kind of NAT device it is behind, not need to attempt to detect the kind of NAT device it is behind,
if any [STUN], since the procedure above will establish peer-to-peer if any [STUN], since the procedure above will establish peer-to-peer
communication channels equally well if either or both clients do not communication channels equally well if either or both clients do not
happen to be behind a NAT device. The hole punching technique happen to be behind a NAT device. The UDP hole punching technique
even works automatically with multiple NATs, where one or both even works automatically with multiple NATs, where one or both
clients are removed from the public Internet via two or more levels clients are removed from the public Internet via two or more levels
of address translation. of address translation.
3.3.2. Peers behind the same NAT 3.3.2. Peers behind the same NAT
Now consider the scenario in which the two clients (probably Now consider the scenario in which the two clients (probably
unknowingly) happen to reside behind the same NAT, and are therefore unknowingly) happen to reside behind the same NAT, and are therefore
located in the same private IP address space. Client A has located in the same private IP address space, as in figure 6.
established a UDP session with server S, to which the common NAT has Client A has established a UDP session with server S, to which the
assigned public port number 62000. Client B has similarly common NAT has assigned public port number 62000. Client B has
established a session with S, to which the NAT has assigned public similarly established a session with S, to which the NAT has
port number 62001. assigned public port number 62001.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
^ Relay-Req Session(A-S) ^ | ^ Relay-Req Session(B-S) ^ ^ Relay-Req Session(A-S) ^ | ^ Relay-Req Session(B-S) ^
| 18.181.0.31:1234 | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | 18.181.0.31:1234 |
| 155.99.25.11:62000 | | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | | 155.99.25.11:62001 |
| |
+--------------+ +--------------+
| 155.99.25.11 | | 155.99.25.11 |
| | | |
| Address/Port | | Address/Port |
| Restricted | | Restricted |
| Cone-NAT | | Cone NAT |
+--------------+ +--------------+
| |
+-----------------------------+----------------------------+ +-----------------------------+----------------------------+
| | | |
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| | | |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1 (B-A)^ | | ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1 (B-A)^ |
skipping to change at page 15, line 35 skipping to change at page 15, line 35
addresses. It is important that these packets be authenticated in addresses. It is important that these packets be authenticated in
some way, however, since in the case of different NATs it is entirely some way, however, since in the case of different NATs it is entirely
possible for A's messages directed at B's private address to reach possible for A's messages directed at B's private address to reach
some other, unrelated node on A's private network, or vice versa. some other, unrelated node on A's private network, or vice versa.
3.3.3. Peers separated by multiple NATs 3.3.3. Peers separated by multiple NATs
In some topologies involving multiple NAT devices, it is not In some topologies involving multiple NAT devices, it is not
possible for two clients to establish an "optimal" P2P route between possible for two clients to establish an "optimal" P2P route between
them without specific knowledge of the topology. Consider for them without specific knowledge of the topology. Consider for
example the following situation. example the situation, depicted in figure 7.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
^ Relay-Req Session(A-S) ^ | ^ Relay-Req Session(B-S) ^ ^ Relay-Req Session(A-S) ^ | ^ Relay-Req Session(B-S) ^
| 18.181.0.31:1234 | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | 18.181.0.31:1234 |
| 155.99.25.11:62000 | | | 155.99.25.11:62001 | | 155.99.25.11:62000 | | | 155.99.25.11:62001 |
| |
+--------------+ +--------------+
| 155.99.25.11 | | 155.99.25.11 |
| | | |
| Address/Port | | Address/Port |
| Restricted | | Restricted |
| Cone-NAT X | | Cone NAT X |
| (Supporting | | (Supporting |
| Loopback | | Loopback |
| Translation) | | Translation) |
+--------------+ +--------------+
| |
+----------------------------+----------------------------+ +----------------------------+----------------------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | | | | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
skipping to change at page 17, line 34 skipping to change at page 17, line 34
addresses, because server S only sees the "global" public addresses addresses, because server S only sees the "global" public addresses
of the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if A of the clients, 155.99.25.11:62000 and 155.99.25.11:62001. Even if A
and B had some way to learn these addresses, there is still no and B had some way to learn these addresses, there is still no
guarantee that they would be usable because the address assignments guarantee that they would be usable because the address assignments
in the ISP's private addressing realm might conflict with unrelated in the ISP's private addressing realm might conflict with unrelated
address assignments in the clients' private realms. The clients address assignments in the clients' private realms. The clients
therefore have no choice but to use their global public addresses as therefore have no choice but to use their global public addresses as
seen by S for their P2P communication, and rely on NAT X to provide seen by S for their P2P communication, and rely on NAT X to provide
loopback translation. loopback translation.
3.3.4. Consistent port bindings 3.3.4. Assumption of P2P-friendly NAT devices enroute
The hole punching technique has one caveat in that it works only if The UDP hole punching technique has a caveat in that it works only
the traversing NAT is cone NAT. That is because Cone NAT reuses if the traversing NAT is a P2P-friendly NAT, such as a Cone NAT.
port bindings. When a symmetric NAT is enroute, it is impossible When a symmetric NAT is encountered enroute, P2P application is
for a P2P application to reuse an already-established translation unable to reuse an already-established translation endpoint for
endpoint for communication with different external destinations. communication with different external destinations and the
Since Cone NATs are the most widespread, the UDP hole punching technique would fail. However, Cone NATs are widely deployed in
technique is fairly broadly applicable; nevertheless a substantial the Internet. That makes the UDP hole punching technique broadly
fraction of deployed NATs are symmetric NATs and do not support applicable; nevertheless a substantial fraction of deployed NATs
the hole punching technique. are symmetric NATs and do not support the UDP hole punching
technique.
3.4. UDP port number prediction 3.4. Simultaneous TCP Open
A variant of the UDP hole punching technique discussed above exists Simultaneous TCP open (also known sometimes as TCP hole punching)
that allows peer-to-peer UDP sessions to be created in the presence technique is used in some cases to establish direct peer-to-peer
of some symmetric NATs. This method is sometimes called the "N+1" TCP connections between a pair of nodes that are both behind
P2P-friendly NAT devices that implement Cone NAT behavior on
their TCP traffic. Most TCP sessions start with one endpoint
sending a SYN packet, to which the other party responds with a
SYN-ACK packet. It is permissible, however, for two endpoints to
start a TCP session by simultaneously sending each other SYN
packets, to which each party subsequently responds with a
separate ACK. This procedure is referred as "simultaneous TCP
Open" technique. However, "Simultaneous TCP Open" is not
implemented correctly on many systems, including NAT devices.
If a NAT device receives a TCP SYN packet from outside the private
network attempting to initiate an incoming TCP connection, the
NAT device will normally reject the connection attempt by either
dropping the SYN packet or sending back a TCP RST (connection reset)
packet. In the case of SYN timeout or connection reset, the P2P
endpoint will continue to resend a SYN packet, until the peer did
the same from its end.
When a SYN packet arrives with source and destination addresses and
port numbers that correspond to a TCP session that the NAT device
believes is already active, then the NAT device will allow the
packet to pass through. In particular, if the NAT device has just
recently seen and transmitted an outgoing SYN packet with the same
addresses and port numbers, then it will consider the session
active and allow the incoming SYN through. If clients A and B can
each initiate an outgoing TCP connection with the other client
timed so that each client's outgoing SYN passes through its local
NAT device before either SYN reaches the opposite NAT device,
then a working peer-to-peer TCP connection will result.
In reality, this technique may not work reliably with many Cone
NAT devices for the following reason(s). If either client's SYN
packet arrive at the opposite NAT device too quickly (before the
peer had a chance to send the SYN packet), then the remote NAT
device may reject the SYN with a RST packet. This could cause
the local NAT device in turn to close the new NAT-session
immediately or initiate end-of-session timeout (refer section
2.6 of [NAT-TERM]) so as to close the NAT-session at the end of
the timeout. As each client continues SYN retransmission
attempts, the remote NAT device might not let the SYNs through
because either the NAT-session is closed or the NAT session is
in end-of-session timeout state and would not let the SYN
packets through. Either way, TCP connection is not established.
Hence, this technique is mentioned here only for historical
reasons.
3.5. UDP port number prediction
A variant of the UDP hole punching technique exists that allows
peer-to-peer UDP sessions to be created in the presence of some
symmetric NATs. This method is sometimes called the "N+1"
technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. technique [BIDIR] and is explored in detail by Takeda [SYM-STUN].
The method works by analyzing the behavior of the NAT and attempting The method works by analyzing the behavior of the NAT and attempting
to predict the public port numbers it will assign to future sessions. to predict the public port numbers it will assign to future sessions.
Consider again the situation in which two clients, A and B, each Consider again the situation in which two clients, A and B, each
behind a separate NAT, have each established UDP connections with a behind a separate NAT, have each established UDP connections with a
permanently addressable server S: permanently addressable server S, as depicted in figure 8.
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
+----------------------------+----------------------------+ +----------------------------+----------------------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | |
| | | |
skipping to change at page 19, line 8 skipping to change at page 20, line 12
A-S and B-S sessions were initiated, then a working bi-directional A-S and B-S sessions were initiated, then a working bi-directional
communication channel between A and B should result. A's messages communication channel between A and B should result. A's messages
to B cause NAT A to open up a new session, to which NAT A will to B cause NAT A to open up a new session, to which NAT A will
(hopefully) assign public port number 62001, because 62001 is next (hopefully) assign public port number 62001, because 62001 is next
in sequence after the port number 62000 it previously assigned to in sequence after the port number 62000 it previously assigned to
the session between A and S. Similarly, B's messages to A will the session between A and S. Similarly, B's messages to A will
cause NAT B to open a new session, to which it will (hopefully) cause NAT B to open a new session, to which it will (hopefully)
assign port number 31001. If both clients have correctly guessed assign port number 31001. If both clients have correctly guessed
the port numbers each NAT assigns to the new sessions, then a the port numbers each NAT assigns to the new sessions, then a
bi-directional UDP communication channel will have been bi-directional UDP communication channel will have been
established as shown below. established as shown in figure 9..
Server S Server S
18.181.0.31:1234 18.181.0.31:1234
| |
| |
+----------------------------+----------------------------+ +----------------------------+----------------------------+
| | | |
| ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ | | ^ Relay-Req Session(A-S) ^ ^ Relay-Req Session(B-S) ^ |
| | 18.181.0.31:1234 | | 18.181.0.31:1234 | | | | 18.181.0.31:1234 | | 18.181.0.31:1234 | |
| | 155.99.25.11:62000 | | 138.76.29.7:31000 | | | | 155.99.25.11:62000 | | 138.76.29.7:31000 | |
skipping to change at page 21, line 12 skipping to change at page 22, line 12
Since in practice a P2P application implementing this trick would Since in practice a P2P application implementing this trick would
still need to work if the NATs are cone NATs, or if one is a cone NAT still need to work if the NATs are cone NATs, or if one is a cone NAT
and the other is a symmetric NAT, the application would need to and the other is a symmetric NAT, the application would need to
detect beforehand what kind of NAT is involved on either end [STUN] detect beforehand what kind of NAT is involved on either end [STUN]
and modify its behavior accordingly, increasing the complexity of the and modify its behavior accordingly, increasing the complexity of the
algorithm and the general brittleness of the network. Finally, port algorithm and the general brittleness of the network. Finally, port
number prediction has no chance of working if either client is behind number prediction has no chance of working if either client is behind
two or more levels of NAT and the NAT(s) closest to the client are two or more levels of NAT and the NAT(s) closest to the client are
symmetric. For all of these reasons, it is NOT recommended that new symmetric. For all of these reasons, it is NOT recommended that new
applications implement this trick; it is mentioned here for applications implement this trick. This technique is mentioned here
historical and informational purposes. only for historical and informational purposes.
3.5. Simultaneous TCP open
There is a method that can be used in some cases to establish direct 3.6. TCP port number prediction
peer-to-peer TCP connections between a pair of nodes that are both
behind existing NAT devices. Most TCP sessions start with one
endpoint sending a SYN packet, to which the other party responds with
a SYN-ACK packet. It is possible and legal, however, for two
endpoints to start a TCP session by simultaneously sending each other
SYN packets, to which each party subsequently responds with a
separate ACK. This procedure is known as a "simultaneous open."
If a NAT device receives a TCP SYN packet from outside the private This is a variant of the "Simultaneous TCP open" technique that
network attempting to initiate an incoming TCP connection, the allows peer-to-peer TCP sessions to be created in the presence of
NAT device will normally reject the connection attempt by either some symmetric NATs.
dropping the SYN packet or sending back a TCP RST (connection reset)
packet. If, however, the SYN packet arrives with source and
destination addresses and port numbers that correspond to a TCP
session that the NAT device believes is already active, then the
NAT device will allow the packet to pass through. In particular, if
the NAT device has just recently seen and transmitted an outgoing SYN
packet with the same addresses and port numbers, then it will
consider the session active and allow the incoming SYN through. If
clients A and B can each correctly predict the public port number
that its respective NAT device will assign the next outgoing TCP
connection, and if each client initiates an outgoing TCP connection
with the other client timed so that each client's outgoing SYN passes
through its local NAT device before either SYN reaches the opposite
NAT device, then a working peer-to-peer TCP connection will result.
Unfortunately, this trick may be even more fragile and timing- Unfortunately, this trick may be even more fragile and timing-
sensitive than the UDP port number prediction trick described above. sensitive than the UDP port number prediction trick described
First, unless both NAT devices implement Cone NAT behavior on their earlier. First, even as both NAT devices implement Cone NAT
TCP traffic, all the same things can go wrong with each side's behavior on the TCP traffic, all the same things can go wrong
attempt to predict the public port numbers that the respective NATs with each side's attempt to predict the public port numbers
will assign to the new sessions. In addition, if either client's that the respective NATs will assign to the new sessions can
SYN arrives at the opposite NAT device too quickly, then the remote happen with TCP port prediction as well. In addition, if either
NAT device may reject the SYN with a RST packet, causing the local client's SYN arrives at the opposite NAT device too quickly, then
NAT device in turn to close the new session and make future SYN the remote NAT device may reject the SYN with a RST packet,
retransmission attempts using the same port numbers futile. Finally, causing the local NAT device in turn to close the new session
even though support for simultaneous open is technically a mandatory and make future SYN retransmission attempts using the same port
part of the TCP specification [TCP], it is not implemented correctly numbers futile. For this reason, this trick is mentioned here
in some common operating systems. For this reason, this trick is only for historical reasons. It is NOT recommended for use by
mentioned here only for historical reasons. It is NOT recommended applications.
for use by applications. Applications that require efficient, direct
peer-to-peer communication over existing NATs should use UDP.
4. Application design guidelines 4. NAT-friendly P2P application design guidelines
4.1. What works with P2P NAT devices 4.1. What works with P2P NAT devices
Since UDP hole punching is the most efficient existing method of Since UDP hole punching is the most efficient existing method of
establishing direct peer-to-peer communication between two nodes establishing direct peer-to-peer communication between two nodes
that are both behind NATs, and it works with a wide variety of that are both behind NATs, and it works with a wide variety of
existing NATs, it is recommended that applications use this existing NATs, it is recommended that applications use this
technique if efficient peer-to-peer communication is required, technique if efficient peer-to-peer communication is required,
but be prepared to fall back on simple relaying when direct but be prepared to fall back on simple relaying when direct
communication cannot be established. communication cannot be established.
4.2. Peers behind the same NAT 4.2. Peers behind the same NAT
In practice there may be a fairly large number of users who In practice there may be a fairly large number of users who
have not two IP addresses, but three or more. In these cases, have not two IP addresses, but three or more. In these cases,
it is hard or impossible to tell which addresses to send to it is hard or impossible to tell which addresses to send to
the registration server. The applications should send all its the registration server. The applications should send all its
addresses, in such a case. addresses, in such a case.
4.3. Peer discovery 4.3. Peer discovery
Applications sending packets to several addresses to discover Applications sending packets to several addresses to discover
which one is best to use for a given peer may become a which one is best to use for a given peer may become a
significant source of 'space junk' littering the net, as the significant source of 'space junk' littering the net, as the
peer may have chosen to use routable addresses improperly as peer may have chosen to use routable addresses improperly as
an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD). an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD).
Thus applications should exercise caution when sending the Thus applications should exercise caution when sending the
speculative hello packets. speculative hello packets.
4.4. TCP applications using sockets API
The socket API, used widely by application developers, is designed
with client-server applications in mind. In its native form, only
a single socket can bind to a TCP or UDP port. An application is
not allowed to have multiple sockets binding to the same port
(TCP or UDP) to initiate simultaneous sessions with multiple
external nodes (or) use one socket to listen on the port and the
other sockets to initiate outgoing sessions.
The above single-socket-to-port bind restriction is not a problem
however with UDP, because UDP is a datagram based protocol. UDP P2P
application designers could use a single socket to send as well as
receive datagrams from multiple peers using recvfrom() and sendto()
calls.
This is not the case with TCP. With TCP, each incoming and outgoing 4.4. Use of midcom protocol
connection is to be associated with a separate socket. In many of
the Operating Systems (OS), sockets API addresses this problem with
SO_REUSEADDR option on the socket or a OS specific SetReuseAddress
call. Readers using the UNIX OS may refer [STEVENS] for additional
details on socket options. Readers should also refer OS specific
documentation for the API details. In summary, it is possible for a
P2P application to use multiple sockets to reuse a TCP port. Say,
open two TCP stream sockets bound to the same port, do a listen()
on one and a connect() from the other.
4.5. Use of midcom protocol If the applications know the NAT devices they would be traversing
and these NAT devices implement the midcom protocol ([MIDCOM]),
applications could use the midcom protocol to ease their way
through the NAT devices.
If the applications know the NAT devices they would be traversing For example, If midcom protocol is supported on the NAT devices
and these NAT devices implement the midcom protocol ([MIDCOM]), enroute, a midcom client for a P2P application might exercise
applications could use the midcom protocol to ease their way through control over port binding (or address binding) parameters such as
the NAT devices. lifetime, maxidletime, and directionality so the applications can
both connect to external peers as well as receive connections
from external peers. Midcom client for a P2P application, for
instance, might set directionality of the corresponding TCP or
UDP port binding(s) to be bi-directional within the NAT device.
A bi-directional TCP/UDP port binding will allow inbound as well
as outbound TCP/UDP sessions through the NAT device. This could
in turn, eliminate a substantial amount of external server
intervention for setting up the peer-to-peer communication
across hosts behind the NAT devices. When the application no
longer needs the binding, the application could simply
dismantle the binding, also using the midcom protocol.
For example, P2P applications require that NAT devices preserve TCP based P2P applications can benefit particularly from the use
endpoint port bindings. If midcom is supported on the NAT devices, of midcom protocol, as the existing "Simultaneous TCP Open"
P2P applications can exercise control over port binding (or address technique is not highly reliable.
binding) parameters such as lifetime, maxidletime, and
directionality so the applications can both connect to external
peers as well as receive connections from external peers; and do
not need to send periodic keep-alives to keep the port binding
alive. When the application no longer needs the binding, the
application could simply dismantle the binding, also using the
midcom protocol.
5. NAT Design Guidelines 5. P2P-friendly NAT design guidelines
This section discusses considerations in the design of network This section discusses considerations in the design of network
address translators, as they affect peer-to-peer applications. address translators, as they affect peer-to-peer applications.
The primary and most important recommendation for NAT designers
is that they maintain address or port bindings in the NAT
implementations. When a node on the private network initiates
connection to a new external destination, using the same source
IP address and TCP/UDP port as an existing translated TCP/UDP
session, the NAT should ensure that the new TCP/UDP session
reuses the address/port binding of the existing session.
5.1. Deprecate the use of symmetric NATs 5.1. Deprecate the use of symmetric NATs
Symmetric NATs gained popularity with client-server applications Symmetric NATs gained popularity with client-server applications
such as web browsers, which only need to initiate outgoing such as web browsers, which only need to initiate outgoing
connections. However, in the recent times, P2P applications such connections. However, in the recent times, P2P applications such
as Instant messaging and audio conferencing have been in wide as Instant messaging and audio conferencing have been in wide
use. Symmetric NATs do not support the concept of retaining use. Symmetric NATs do not support port binding and are not
endpoint identity and are not suitable for P2P applications. suitable for P2P applications. For this reason, a NAT will be
Deprecating symmetric NATs is recommended in order to support more P2P-friendly if it deprecated the use of symmetric NAT
P2P applications. function.
A P2P-NAT must implement Cone NAT behavior, allowing A P2P-friendly NAT must implement Cone NAT behavior, allowing
applications to establish robust P2P connectivity using the applications to establish robust P2P connectivity using the
UDP hole punching technique. Ideally, a P2P-NAT should also TCP/UDP hole punching techniques. Ideally, a P2P-friendly NAT
allow applications to make P2P connections via both TCP and should allow applications to make P2P connections via both
UDP. TCP and UDP.
5.2. Add incremental Cone NAT support to Symmetric NAT devices 5.2. Add incremental Cone NAT support to Symmetric NATs
One way for a symmetric NAT device to extend support to P2P One way for a symmetric NAT device to extend support to P2P
applications would be to divide its assignable port applications would be to divide its assignable port
namespace, reserving a portion of its ports for one-to-one namespace, reserving a portion of its ports for one-to-one
sessions and a different set of ports for one-to-many sessions and a different set of ports for one-to-many
sessions. sessions.
Further, a NAT device may be explicitly configured with Further, a NAT device may be explicitly configured with
applications and hosts that need the P2P feature, so the applications and hosts that need the P2P feature, so the
NAT device can auto magically assign a P2P port from the NAT device can auto-magically assign a P2P port from the
right port block. right port block.
5.3. Support Address and port bindings 5.3. Simultaneous TCP Open support in Cone NATs
The primary and most important recommendation of this document for A Cone NAT will be more P2P friendly if the Cone NAT maintained
NAT designers is that they maintain address and/or port port bindings for TCP endpoints in addition to port bindings for
bindings in their NAT implementations. When a node on the UDP endpoints. TCP port bindings on a Cone NAT will increase the
private network initiates connection to a new external NAT's ability to support TCP based P2P application deployment.
destination, using the same source IP address and TCP/UDP port as
an existing translated TCP/UDP session, the NAT should ensure
that the new TCP/UDP session reuses the address/port binding
of the existing session.
5.3.1. Preserving port numbers Further, a NAT device will be more P2P friendly for TCP
applications, if the NAT device implemented end-of-session
timeout for TCP NAT-sessions (refer section 2.6 of [NAT-TERM])
and supported "Simultaneous TCP Open" (refer section 3.4).
Supporting "Simultaneous TCP Open" on a Cone NAT will allow TCP
based P2P applications to reliably establish P2P connections
even as they traverse the NAT.
Some NATs, when establishing a new UDP session, attempt to assign the 5.4. Port preservation is not important
same public port number as the corresponding private port number, if
that port number happens to be available. For example, if client A Some NATs, when establishing a new TCP or UDP session, attempt to
at address 10.0.0.1 initiates an outgoing UDP session with a datagram assign the same public port number as the corresponding private port
from port number 1234, and the NAT's public port number 1234 happens number, if that port number happens to be available. For example, if
to be available, then the NAT uses port number 1234 at the NAT's client A at address 10.0.0.1 initiates an outgoing UDP session with
public IP address as the translated endpoint address for the session. a datagram from port number 1234, and the NAT's public port number
This behavior might be beneficial to some legacy UDP applications 1234 happens to be available, then the NAT uses port number 1234 at
that expect to communicate only using specific UDP port numbers, but the NAT's public IP address as the translated endpoint address for
it is not recommended that applications depend on this behavior since the session.
it is only possible for a NAT to preserve the port number if at most
one node on the internal network is using that port number. This behavior might be beneficial to some legacy TCP/UDP
applications that expect to communicate only using specific TCP/UDP
port numbers. However, applications needing to traverse NAT devices
might not want to depend on this behavior since it is only possible
for a NAT to preserve the port number if at most one node on the
internal network is using that port number.
In addition, a NAT should NOT try to preserve the port number in a In addition, a NAT should NOT try to preserve the port number in a
new session if doing so would conflict with an existing port new session if doing so would conflict with an existing port
binding. For example, suppose client A at internal port 1234 has binding. For example, suppose client A at internal port 1234 has
established a session with external server S, and NAT A has created established a session with external server S, and NAT A has created
a port binding to public port 62000, because public port number a port binding to public port 62000, because public port number
1234 on the NAT was not available at the time. Now, suppose port 1234 on the NAT was not available at the time. Now, suppose port
number 1234 on the NAT subsequently becomes available, and while the number 1234 on the NAT subsequently becomes available, and while the
session between A and S is still active, client A initiates a new session between A and S is still active, client A initiates a new
session from the same internal port (1234) to a different external session from the same internal port (1234) to a different external
node B. In this case, because a port binding has already been node B. In this case, because a port binding has already been
established between client A's port 1234 and the NAT's public port established between client A's port 1234 and the NAT's public port
62000, this binding should be preserved and the new session should 62000, this binding should be preserved and the new session should
reuse the port binding (to port 62000). The NAT should not assign reuse the port binding (to port 62000). The NAT should not assign
public port 1234 to this new session just because port 1234 has public port 1234 to this new session just because port 1234 has
become available. Such a behavior would not be likely to benefit the become available. Such a behavior would not be likely to benefit the
application in any way since the application has already been application in any way since the application has already been
operating with a translated port number, and it would break any operating with a translated port number, and it would break any
attempts the application might make to establish peer-to-peer attempts the application might make to establish peer-to-peer
connections using the UDP hole punching technique. connections.
5.3.2. Support TCP port bindings
Cone NAT implementers should maintain port bindings for TCP 5.5. Large timeout for P2P applications
sessions just as with UDP sessions. TCP port bindings on a
Cone NAT will increase the NAT's ability to support P2P TCP
application deployment.
5.4. Large timeout for P2P applications A P2P-friendly NAT device might be configured with a large
idle-timeout in the order of 5 minutes (300 seconds) or more
for P2P applications. The idle-timeout is in reference to the
port bindings and NAT-sessions maintained by the NAT device
for P2P applications. NAT implementers are often tempted to
use a shorter idle timeout, as they are accustomed to doing
for non-P2P applications. But, short timeouts are problematic
for P2P applications. Consider a P2P application that involved
16 peers. With short idle timeouts, the applications might
flood the network with keepalive packets every 10 seconds to
avoid NAT timeouts. This is so because an application might
send keepalives 5 times as often as the NAT device's timeout
just in case the keepalives are dropped in the network.
We recommend the NAT device implementers to use a minimum timeout 5.6. Support loopback translation
of, say, 5 minutes (300 seconds) for P2P applications, i.e.,
configure the NAT device with this idle-timeout for the port
bindings for the ports set aside for P2P use. NAT device
implementers are often tempted to use a shorter one, as they are
accustomed to doing currently. But, short timeouts are
problematic. Consider a P2P application that involved 16 peers.
They will flood the network with keepalive packets every 10
seconds to avoid NAT timeouts. This is so because one might
send them 5 times as often as the NAT device's timeout just in
case the keepalives are dropped in the network.
5.5. Support loopback translation A NAT will be more P2P-friendly if it supported loopback
translation. Loopback translation support would allow hosts
behind a p2p-friendly NAT to communicate with other hosts behind
the same NAT device through their public, possibly translated
endpoints. Support for loopback translation might be particularly
useful in the case of large-capacity NATs deployed as the first
level of a multi-level NAT scenario. As described in section
3.3.3, hosts behind the same first-level NAT but different
second-level NATs do not have a way to communicate with each
other by TCP/UDP hole punching, even if all the NAT devices
preserve endpoint identities, unless the first-level NAT also
supports loopback translation.
We strongly recommend that NAT implementers support 5.7. Support midcom protocol
loopback translation, allowing hosts behind a NAT device to
communicate with other hosts behind the same NAT device through
their public, possibly translated endpoints. Support for
loopback translation is particularly important in the case
of large-capacity NATs that are likely to be deployed as the
first level of a multi-level NAT scenario. As described in
section 3.3.3, hosts behind the same first-level NAT but
different second-level NATs have no way to communicate with
each other by UDP hole punching, even if all the NAT devices
preserve endpoint identities, unless the first-level NAT
also supports loopback translation.
5.6. Support midcom protocol A NAT will be more P2P-friendly if it supported midcom protocol,
because midcom protocol places the control of NAT resources in
the hands of the midcom client rather than the NAT device itself.
The midcom client will utilize the application level knowledge to
control NAT resources so as to permit the applications through the
NAT device. A P2P application end-point may optionally play the
role of midcom client for itself. Midcom client for a P2P
application, for instance, might set the corresponding TCP or UDP
port binding(s) bi-directional within the P2P-friendly NAT device.
A bi-directional TCP/UDP port binding will allow inbound as well
as outbound TCP/UDP sessions through the NAT device.
We recommend that NAT implementers support midcom protocol,
the details of which are currently in specification stage.
Readers may refer the midcom working group [MIDCOM] to monitor Readers may refer the midcom working group [MIDCOM] to monitor
the status of protocol specification. Support for midcom the status of Midcom protocol specification.
protocol in NAT devices will provide substantial additional
flexibility for the P2P applications to control NAT
resources effectively. Readers may refer section 4.5 on how
P2P applications can benefit from NAT devices supporting
midcom protocol.
6. Security Considerations 6. Security considerations
Following the recommendations in this document should not The guidelines outlined in this document do not inherently
inherently create new security issues, for either the create new security issues, for either the NAT-friendly P2P
applications or the NAT devices. Nevertheless, new security applications or the P2P-friendly NAT devices. Nevertheless,
risks may be created if the techniques described here are new security risks may be likely if the techniques described
not adhered to with sufficient care. This section describes are not adhered to with sufficient care. This section describes
security risks the applications could inadvertently create security risks the applications could inadvertently create in
in attempting to support P2P communication across NAT devices, attempting to support P2P communication across NAT devices.
and implications for the security policies of P2P-friendly Also described are implications for the security policies of
NAT devices. P2P-friendly NAT devices.
6.1. IP address aliasing 6.1. IP address aliasing
P2P applications must use appropriate authentication mechanisms NAT-friendly P2P applications must use appropriate authentication
to protect their P2P connections from accidental confusion with mechanisms to protect their P2P connections from accidental
other P2P connections as well as from malicious connection confusion with other P2P connections as well as from malicious
hijacking or denial-of-service attacks. NAT-friendly P2P connection hijacking or denial-of-service attacks. NAT-friendly
applications effectively must interact with multiple distinct P2P applications effectively must interact with multiple distinct
IP address domains, but are not generally aware of the exact IP address domains, but are not generally aware of the exact
topology or administrative policies defining these address topology or administrative policies defining these address
domains. While attempting to establish P2P connections via domains. While attempting to establish P2P connections via
UDP hole punching, applications send packets that may frequently TCP/UDP hole punching, applications send packets that may
arrive at an entirely different host than the intended one. frequently arrive at an entirely different host than the
intended one.
For example, many consumer-level NAT devices provide DHCP For example, many consumer-level NAT devices provide DHCP
services that are configured by default to hand out site-local services that are configured by default to hand out site-local
IP addresses in a particular address range. Say, a particular IP addresses in a particular address range. Say, a particular
consumer NAT device, by default, hands out IP addresses starting consumer NAT device, by default, hands out IP addresses starting
with 192.168.1.100. Most private home networks using that NAT with 192.168.1.100. Most private home networks using that NAT
device will have a host with that IP address, and many of these device will have a host with that IP address, and many of these
networks will probably have a host at address 192.168.1.101 as networks will probably have a host at address 192.168.1.101 as
well. If host A at address 192.168.1.101 on one private network well. If host A at address 192.168.1.101 on one private network
attempts to establish a connection by UDP hole punching with attempts to establish a connection by UDP hole punching with
host B at 192.168.1.100 on a different private network, then as host B at 192.168.1.100 on a different private network, then as
part of this process host A will send discovery packets to part of this process host A will send discovery packets to
address 192.168.1.100 on its local network, and host B will send address 192.168.1.100 on its local network, and host B will send
discovery packets to address 192.168.1.101 on its network. Clearly, discovery packets to address 192.168.1.101 on its network. Clearly,
these discovery packets will not reach the intended machine since these discovery packets will not reach the intended machine since
the two hosts are on different private networks, but they are very the two hosts are on different private networks, but they are very
likely to reach SOME machine on these respective networks at the likely to reach SOME machine on these respective networks at the
standard UDP port numbers used by this application, potentially standard UDP port numbers used by this application, potentially
causing confusion. especially if the application is also running causing confusion, especially if the application is also running
on those other machines and does not properly authenticate its on those other machines and does not properly authenticate its
messages. messages.
This risk due to aliasing is therefore present even without a This risk due to aliasing is therefore present even without a
malicious attacker. If one endpoint, say host A, is actually malicious attacker. If one endpoint, say host A, is actually
malicious, then without proper authentication the attacker could malicious, then without proper authentication the attacker could
cause host B to connect and interact in unintended ways with cause host B to connect and interact in unintended ways with
another host on its private network having the same IP address another host on its private network having the same IP address
as the attacker's (purported) private address. Since the two as the attacker's (purported) private address. Since the two
endpoint hosts A and B presumably discovered each other through endpoint hosts A and B presumably discovered each other through
skipping to change at page 29, line 4 skipping to change at page 29, line 25
The only defense against such an attack is for the client to The only defense against such an attack is for the client to
authenticate and potentially encrypt the actual content of its authenticate and potentially encrypt the actual content of its
communication using appropriate higher-level identities, so that communication using appropriate higher-level identities, so that
the interposed attacker is not able to take advantage of its the interposed attacker is not able to take advantage of its
position. Even if all application-level communication is position. Even if all application-level communication is
authenticated and encrypted, however, this attack could still be authenticated and encrypted, however, this attack could still be
used as a traffic analysis tool for observing who the client is used as a traffic analysis tool for observing who the client is
communicating with. communicating with.
6.4. Impact on NAT device security 6.4. Impact on NAT device security
Designing NAT devices to preserve endpoint identities does not Designing NAT devices to preserve endpoint identities does not
weaken the security provided by the NAT device. For example, a weaken the security provided by the NAT device. For example, a
Port-Restricted Cone NAT is inherently no more "promiscuous" Port-restricted Cone NAT is inherently no more "promiscuous"
than a Symmetric NAT in its policies for allowing either than a Symmetric NAT in its policies for allowing either
incoming or outgoing traffic to pass through the NAT device. incoming or outgoing traffic to pass through the NAT device.
As long as outgoing UDP sessions are enabled and the NAT device As long as outgoing TCP/UDP sessions are enabled and the NAT
maintains consistent binding between internal and external device maintains consistent binding between internal and external
UDP ports, the NAT device will filter out any incoming UDP packets TCP/UDP ports, the NAT device will filter out any incoming TCP/UDP
that do not match the active sessions initiated from within the packets that do not match the active sessions initiated from
enclave. Filtering incoming traffic aggressively while maintaining within the enclave. Filtering incoming traffic aggressively while
consistent port bindings thus allows a NAT device to be maintaining consistent port bindings thus allows a NAT device to
"peer-to-peer friendly" without compromising the principle of be P2P friendly without compromising the principle of rejecting
rejecting unsolicited incoming traffic. unsolicited incoming traffic.
Maintaining consistent port binding could arguably increase the Maintaining consistent port binding could arguably increase the
predictability of traffic emerging from the NAT device, by revealing predictability of traffic emerging from the NAT device, by revealing
the relationships between different UDP sessions and hence about the relationships between different UDP sessions and hence about
the behavior of applications running within the enclave. This the behavior of applications running within the enclave. This
predictability could conceivably be useful to an attacker in predictability could conceivably be useful to an attacker in
exploiting other network or application level vulnerabilities. exploiting other network or application level vulnerabilities.
If the security requirements of a particular deployment scenario If the security requirements of a particular deployment scenario
are so critical that such subtle information channels are of are so critical that such subtle information channels are of
concern, however, then the NAT device almost certainly should not be concern, however, then the NAT device almost certainly should not be
configured to allow unrestricted outgoing UDP traffic in the configured to allow unrestricted outgoing TCP/UDP traffic in the
first place. Such a NAT device should only allow communication first place. Such a NAT device should only allow communication
originating from specific applications at specific ports, or originating from specific applications at specific ports, or
via tightly-controlled application-level gateways. In this via tightly-controlled application-level gateways. In this
situation there is no hope of generic, transparent peer-to-peer situation there is no hope of generic, transparent peer-to-peer
connectivity across the NAT device (or transparent client/server connectivity across the NAT device (or transparent client/server
connectivity for that matter); the NAT device must either connectivity for that matter); the NAT device must either
implement appropriate application-specific behavior or disallow implement appropriate application-specific behavior or disallow
communication entirely. communication entirely.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Henrik, Dave, and Christian Huitema The authors wish to thank Henrik, Dave, and Christian Huitema
for their valuable feedback. for their valuable feedback.
8. References 8. Informative References
[NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
[NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy,
skipping to change at page 30, line 25 skipping to change at page 30, line 46
January 2001. January 2001.
[NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
[MIDCOM-FW]P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and [MIDCOM-FW]P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, August 2002.
[STEVENS] W. Richard Stevens, "UNIX Network Programming, Volume 1,
Second Edition: Networking APIs: Sockets and XTI",
Prentice Hall, 1998.
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, [BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee,
"Bidirectional Peer-to-Peer Communication with Interposing "Bidirectional Peer-to-Peer Communication with Interposing
Firewalls and NATs", August 2001. Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/ http://www.peer-to-peerwg.org/tech/nat/
[KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999. [KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.
http://www.alumni.caltech.edu/~dank/peer-nat.html http://www.alumni.caltech.edu/~dank/peer-nat.html
[TCP] "Transmission Control Protocol", RFC 793, September 1981. [TCP] "Transmission Control Protocol", RFC 793, September 1981.
[MIDCOM] Middlebox Communication (midcom) working group, [MIDCOM] Middlebox Communication (midcom) working group,
http://www.ietf.org/html.charters/midcom-charter.html http://www.ietf.org/html.charters/midcom-charter.html
[TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema, [TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema,
"Traversal Using Relay NAT (TURN)", "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (Work In Progress), draft-rosenberg-midcom-turn-01 (Work In Progress),
 End of changes. 102 change blocks. 
396 lines changed or deleted 461 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/