draft-ford-midcom-p2p-01.txt

Peer-to-Peer (P2P) communication across middleboxes

Internet Draft                                                   B. Ford
Document: draft-ford-midcom-p2p-01.txt                            M.I.T.
Expires: April 27, 2004                                     P. Srisuresh
                                                          Caymas Systems
                                                                D. Kegel
                                                               kegel.com
                                                            October 2003


              Peer-to-Peer (P2P) communication across middleboxes


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.  Internet-Drafts are working documents of
   the Internet Engineering Task Force (IETF), its areas, and its
   working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


Abstract

   This memo documents the methods used by the current peer-to-peer
   (P2P) applications to communicate in the presence of middleboxes
   such as firewalls and network address translators (NAT). In
   addition, the memo suggests guidelines to application designers
   and middlebox implementers on the measures they could take to
   enable immediate, wide deployment of P2P applications with or
   without requiring the use of special proxy, relay or midcom
   protocols.  




Ford, Srisuresh & Kegel                                         [Page 1]

Internet-Draft     P2P applications across middleboxes      October 2003



Table of Contents

   1.  Introduction .................................................
   2.  Terminology ..................................................
   3.  Techniques for P2P communication over middleboxes ............
       3.1.  Relaying ...............................................
       3.2.  Connection reversal ....................................
       3.3.  UDP Hole Punching ......................................
             3.3.1.  Peers behind different NATs ..................
             3.3.2.  Peers behind the same NAT ....................
             3.3.3.  Peers separated by multiple NATs ...............
             3.3.4.  Consistent port bindings .......................
       3.4.  UDP Port number prediction .............................
       3.5.  Simultaneous TCP open ..................................
   4.  Application design guidelines ................................
       4.1. What works with P2P middleboxes .........................
       4.2. Applications behind the same NAT ........................
       4.3. Peer discovery ..........................................
       4.4. TCP P2P applications ....................................
       4.5. Use of midcom protocol ..................................
   5.  NAT design guidelines ........................................
       5.1. Deprecate the use of symmetric NATs .....................
       5.2. Add incremental Cone-NAT support to symmetric NAT devices
       5.3. Maintaining consistent port bindings for UDP ports .....
             5.3.1.  Preserving Port Numbers ........................
       5.4. Maintaining consistent port bindings for TCP ports .....
       5.5. Large timeout for P2P applications ......................
   6.  Security considerations ......................................


1. Introduction

   Present-day Internet has seen ubiquitous deployment of
   "middleboxes" such as network address translators(NAT), driven
   primarily by the ongoing depletion of the IPv4 address space.  The
   asymmetric addressing and connectivity regimes established by these
   middleboxes, however, have created unique problems for peer-to-peer
   (P2P) applications and  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 middleboxes are designed primarily around the
   client/server paradigm, in which relatively anonymous client machines
   actively initiate connections to well-connected servers having stable
   IP addresses and DNS names.  Most middleboxes implement an asymmetric



Ford, Srisuresh & Kegel                                         [Page 2]

Internet-Draft     P2P applications across middleboxes      October 2003


   communication model in which hosts on the private internal network
   can initiate outgoing connections to hosts on the public network, but
   external hosts cannot initiate connections to internal hosts except
   as specifically configured by the middlebox's administrator. In the
   common case of NAPT, a client on the internal network does not have
   a unique IP address on the public Internet, but instead must share
   a single public IP address, managed by the NAPT, with other hosts
   on the same private network.  The anonymity and inaccessibility of
   the internal hosts behind a middlebox is not a problem for client
   software such as web browsers, which only need to initiate outgoing
   connections. This inaccessibility is sometimes seen as a privacy
   benefit.

   In the peer-to-peer paradigm, however, Internet hosts that would
   normally be considered "clients" need to establish communication
   sessions directly with each other. The initiator and the responder
   might lie behind different middleboxes with neither endpoint 
   having any permanent IP address or other form of public network
   presence. A common on-line gaming architecture, for example,
   is for the participating application hosts to contact a well-known
   server for initialization and administration purposes. Subsequent
   to this, the hosts establish direct connections with each other
   for fast and efficient propagation of updates during game play. 
   Similarly, a file sharing application might contact a well-known
   server for resource discovery or searching, but establish direct
   connections with peer hosts for data transfer. Middleboxes create
   problems for peer-to-peer connections because hosts behind a
   middlebox normally have no permanently usable public ports on the
   Internet to which incoming TCP or UDP connections from other peers
   can be directed.  RFC 3235 [NAT-APPL] briefly addresses this issue,
   but does not offer any general solutions.

   In this document we address the P2P/middlebox problem in two ways.
   First, we summarize known methods by which P2P applications can
   work around the presence of middleboxes. Second, we provide a set
   of application design guidelines based on these practices to make
   P2P applications operate more robustly over currently-deployed
   middleboxes. Further, we provide design guidelines for future
   middleboxes to allow them to support P2P applications more
   effectively. Our focus is to enable immediate and wide deployment
   of P2P applications requiring to traverse middleboxes.

2. Terminology

In this section we first summarize some middlebox terms. We focus here
on the two kinds of middleboxes that commonly cause problems for P2P
applications.




Ford, Srisuresh & Kegel                                         [Page 3]

Internet-Draft     P2P applications across middleboxes      October 2003


   Firewall
      A firewall restricts communication between a private internal
      network and the public Internet, typically by dropping packets
      that are deemed unauthorized.  A firewall examines but does
      not modify the IP address and TCP/UDP port information in
      packets crossing the boundary.

   Network Address Translator (NAT)
      A network address translator not only examines but also modifies
      the header information in packets flowing across the boundary,
      allowing many hosts behind the NAT to share the use of a smaller
      number of public IP addresses (often one).

   Network address translators in turn have two main varieties:

   Basic NAT
      A Basic NAT maps an internal host's private IP address to a
      public IP address without changing the TCP/UDP port
      numbers in packets crossing the boundary.  Basic NAT is generally
      only useful when the NAT has a pool of public IP addresses from
      which to make address bindings on behalf of internal hosts.

   Network Address/Port Translator (NAPT)
      By far the most common, a Network Address/Port Translator examines
      and modifies both the IP address and the TCP/UDP port number
      fields of packets crossing the boundary, allowing multiple
      internal hosts to share a single public IP address simultaneously.

   Refer to [NAT-TRAD] and [NAT-TERM] for more general information on
   NAT taxonomy and terminology. Additional terms that further classify
   NAPT are defined in more recent work [STUN]. When an internal host
   opens an outgoing TCP or UDP session through a network address/port
   translator, the NAPT assigns the session a public IP address and
   port number so that subsequent response packets from the external
   endpoint can be received by the NAPT, translated, and forwarded
   to the internal host. The effect is that the NAPT establishes a 
   port binding between (private IP address, private port number) and
   (public IP address, public port number). The port binding
   defines the address translation the NAPT will perform for the
   duration of the session.  An issue of relevance to P2P
   applications is how the NAT behaves when an internal host initiates
   multiple simultaneous sessions from a single (private IP, private
   port) pair to multiple distinct endpoints on the external network.

   Cone NAT
      After establishing a port binding between a (private IP, private
      port) tuple and a (public IP, public port) tuple, a cone NAT will 
      re-use this port binding for subsequent sessions the



Ford, Srisuresh & Kegel                                         [Page 4]

Internet-Draft     P2P applications across middleboxes      October 2003


      application may initiate from the same private IP address and
      port number, for as long as at least one session using the port
      binding remains active.

      For example, suppose Client A in the diagram below initiates two
      simultaneous outgoing sessions through a cone NAT, from the same
      internal endpoint (10.0.0.1:1234) to two different
      external servers, S1 and S2.  The cone NAT assigns just one public
      endpoint tuple, 155.99.25.11:62000, to both of these sessions,
      ensuring that the "identity" of the client's port is maintained
      across address translation. Since Basic NATs and firewalls do 
      not modify port numbers as packets flow across
      the middlebox, these types of middleboxes can be viewed as a
      degenerate form of Cone NAT.



           Server S1                                     Server S2
        18.181.0.31:1235                              138.76.29.7:1235
               |                                             |
               |                                             |
               +----------------------+----------------------+
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          v 155.99.25.11:62000 v      |      v 155.99.25.11:62000 v
                                      |
                                   Cone NAT
                                 155.99.25.11
                                      |
          ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
          |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
          v   10.0.0.1:1234    v      |      v   10.0.0.1:1234    v
                                      |
                                   Client A
                                10.0.0.1:1234















Ford, Srisuresh & Kegel                                         [Page 5]

Internet-Draft     P2P applications across middleboxes      October 2003