draft-ford-midcom-p2p-01.txt

Peer-to-Peer (P2P) communication across middleboxes

   Some NATs, when establishing a new UDP session, attempt to assign the
   same public port number as the corresponding private port number, if
   that port number happens to be available.  For example, if client A
   at address 10.0.0.1 initiates an outgoing UDP session with a datagram
   from port number 1234, and the NAT's public port number 1234 happens
   to be available, then the NAT uses port number 1234 at the NAT's
   public IP address as the translated endpoint address for the session.
   This behavior might be beneficial to some legacy UDP applications
   that expect to communicate only using specific UDP port numbers, but
   it is not recommended that applications 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
   new session if doing so would conflict with the goal of maintaining a
   consistent binding between public and private endpoint addresses.
   For example, suppose client A at internal port 1234 has established a
   session with external server S, and NAT A has assigned public port
   62000 to this session because port number 1234 on the NAT was not
   available at the time.  Now suppose port 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 from its same
   internal port (1234) to a different external 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 62000, this binding should be
   maintained and the new session should also use port 62000 as the
   public port corresponding to client A's port 1234.  The NAT should
   NOT assign public port 1234 to this new session just because port
   1234 has become available: that behavior would not be likely to
   benefit the application in any way since the application has already
   been operating with a translated port number, and it would break any
   attempts the application might make to establish peer-to-peer
   connections using the UDP hole punching technique.

5.4. Maintaining consistent port bindings for TCP ports

   For consistency with the behavior of UDP translation, cone NAT
   implementers should also maintain a consistent binding between
   private and public (IP address, TCP port number) pairs for TCP
   connections, in the same way as described above for UDP.  
   Maintaining TCP endpoint bindings consistently will increase
   the NAT's compatibility with P2P TCP applications that initiate
   multiple TCP connections from the same source port. 




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


5.5. Large timeout for P2P applications

   We recommend the middlebox implementers to use a minimum timeout
   of, say, 5 minutes (300 seconds) for P2P applications, i.e., 
   configure the middlebox with this idle-timeout for the port 
   bindings for the ports set aside for P2P use. Middlebox
   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 middlebox's timeout just in 
   case the keepalives are dropped in the network.

5.6. Support loopback translation

   We strongly recommend that middlebox implementers support
   loopback translation, allowing hosts behind a middlebox to
   communicate with other hosts behind the same middlebox 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 middleboxes
   preserve endpoint identities, unless the first-level NAT
   also supports loopback translation.


6. Security Considerations

   Following the recommendations in this document should not
   inherently create new security issues, for either the 
   applications or the middleboxes. Nevertheless, new security
   risks may be created if the techniques described here are
   not adhered to with sufficient care. This section describes
   security risks the applications could inadvertently create
   in attempting to support P2P communication across middleboxes,
   and implications for the security policies of P2P-friendly
   middleboxes.

6.1. IP address aliasing

   P2P applications must use appropriate authentication mechanisms
   to protect their P2P connections from accidental confusion with
   other P2P connections as well as from malicious connection
   hijacking or denial-of-service attacks. NAT-friendly P2P 



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


   applications effectively must interact with multiple distinct 
   IP address domains, but are not generally aware of the exact
   topology or administrative policies defining these address
   domains.  While attempting to establish P2P connections via
   UDP hole punching, applications send packets that may frequently
   arrive at an entirely different host than the intended one.

   For example, many consumer-level NAT devices provide DHCP
   services that are configured by default to hand out site-local
   IP addresses in a particular address range. Say, a particular
   consumer NAT device, by default, hands out IP addresses starting
   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
   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
   attempts to establish a connection by UDP hole punching with 
   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 
   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,
   these discovery packets will not reach the intended machine since 
   the two hosts are on different private networks, but they are very
   likely to reach SOME machine on these respective networks at the
   standard UDP port numbers used by this application, potentially
   causing confusion. especially if the application is also running
   on those other machines and does not properly authenticate its
   messages.

   This risk due to aliasing is therefore present even without a
   malicious attacker. If one endpoint, say host A, is actually
   malicious, then without proper authentication the attacker could
   cause host B to connect and interact in unintended ways with
   another host on its private network having the same IP address
   as the attacker's (purported) private address. Since the two
   endpoint hosts A and B presumably discovered each other through
   a public server S, and neither S nor B has any means to verify
   A's reported private address, all P2P applications must assume
   that any IP address they find to be suspect until they successfully
   establish authenticated two-way communication.

6.2. Denial-of-service attacks

   P2P applications and the public servers that support them must
   protect themselves against denial-of-service attacks, and ensure
   that they cannot be used by an attacker to mount denial-of-service
   attacks against other targets. To protect themselves, P2P 
   applications and servers must avoid taking any action requiring
   significant local processing or storage resources until



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


   authenticated two-way communication is established. To avoid being
   used as a tool for denial-of-service attacks, P2P applications and
   servers must minimize the amount and rate of traffic they send to
   any newly-discovered IP address until after authenticated two-way
   communication is established with the intended target.

   For example, P2P applications that register with a public rendezvous
   server can claim to have any private IP address, or perhaps multiple
   IP addresses. A well-connected host or group of hosts that can
   collectively attract a substantial volume of P2P connection attempts
   (e.g., by offering to serve popular content) could mount a
   denial-of-service attack on a target host C simply by including C's
   IP address in their own list of IP addresses they register with the
   rendezvous server. There is no way the rendezvous server can verify
   the IP addresses, since they could well be legitimate private
   network addresses useful to other hosts for establishing
   network-local communication. The P2P application protocol must
   therefore be designed to size- and rate-limit traffic to unverified
   IP addresses in order to avoid the potential damage such a 
   concentration effect could cause.

6.3. Man-in-the-middle attacks

   Any network device on the path between a P2P client and a
   rendezvous server can mount a variety of man-in-the-middle
   attacks by pretending to be a NAT.  For example, suppose 
   host A attempts to register with rendezvous server S, but a 
   network-snooping attacker is able to observe this registration
   request. The attacker could then flood server S with requests
   that are identical to the client's original request except with
   a modified source IP address, such as the IP address of the
   attacker itself.  If the attacker can convince the server to
   register the client using the attacker's IP address, then the
   attacker can make itself an active component on the path of all
   future traffic from the server AND other P2P hosts to the
   original client, even if the attacker was originally only able
   to snoop the path from the client to the server.

   The client cannot protect itself from this attack by
   authenticating its source IP address to the rendezvous server,
   because in order to be NAT-friendly the application MUST allow
   intervening NATs to change the source address silently.  This
   appears to be an inherent security weakness of the NAT paradigm.
   The only defense against such an attack is for the client to
   authenticate and potentially encrypt the actual content of its
   communication using appropriate higher-level identities, so that
   the interposed attacker is not able to take advantage of its
   position.  Even if all application-level communication is



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


   authenticated and encrypted, however, this attack could still be
   used as a traffic analysis tool for observing who the client is
   communicating with.

6.4. Impact on middlebox security

   Designing middleboxes to preserve endpoint identities does not
   weaken the security provided by the middlebox. For example, a 
   Port-Restricted Cone NAT is inherently no more "promiscuous" 
   than a Symmetric NAT in its policies for allowing either
   incoming or outgoing traffic to pass through the middlebox.
   As long as outgoing UDP sessions are enabled and the middlebox
   maintains consistent binding between internal and external
   UDP ports, the middlebox will filter out any incoming UDP packets
   that do not match the active sessions initiated from within the
   enclave. Filtering incoming traffic aggressively while maintaining
   consistent port bindings thus allows a middlebox to be
   "peer-to-peer friendly" without compromising the principle of
   rejecting unsolicited incoming traffic.

   Maintaining consistent port binding could arguably increase the
   predictability of traffic emerging from the middlebox, by revealing
   the relationships between different UDP sessions and hence about
   the behavior of applications running within the enclave. This
   predictability could conceivably be useful to an attacker in
   exploiting other network or application level vulnerabilities.
   If the security requirements of a particular deployment scenario
   are so critical that such subtle information channels are of
   concern, however, then the middlebox almost certainly should not be
   configured to allow unrestricted outgoing UDP traffic in the
   first place. Such a middlebox should only allow communication
   originating from specific applications at specific ports, or
   via tightly-controlled application-level gateways.  In this
   situation there is no hope of generic, transparent peer-to-peer
   connectivity across the middlebox (or transparent client/server
   connectivity for that matter); the middlebox must either
   implement appropriate application-specific behavior or disallow
   communication entirely.

7. Acknowledgments

   The authors wish to thank Henrik, Dave, and Christian Huitema
   for their valuable feedback.

8. References

8.1. Normative references




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


[BIDIR]    Peer-to-Peer Working Group, NAT/Firewall Working Committee,
           "Bidirectional