[p2p-hackers] Official IETF behavior recommendations for NAT relevant to P2P

[Bryan Ford]

Dear p2p-hackers,

A discussion is currently taking place on the IETF BEHAVE working group 
mailing list (see http://www1.ietf.org/html.charters/behave-charter.html) 
that is highly relevant to P2P application writers.  For those of you not 
already familiar with it, this IETF working group is defining standards for 
how NATs should behave so as to better support applications including P2P 
apps.  The chair has made a "Last Call" for comments on the current draft 
document specifying NAT behavior for UDP, so this may be the last chance we 
have for a while to influence how well the next generation of NATs support 
UDP-based P2P applications.

** Address-Restricted vs Full Cone NAT **

There's one issue in particular on which I personally fear the working group 
is currently headed in the wrong direction, and over which you folks on this 
list could perhaps exert considerable influence if you're willing to take a 
little time and make your voice heard on the BEHAVE list.  The current UDP 
draft, draft-ietf-behave-nat-udp-01.txt, recommends that NATs implement 
"Endpoint address-dependent filtering behavior", otherwise known as 
"Address-Restricted Cone NAT".  In other words, once a NATted UDP application 
opens a UDP session through a NAT to some external host, giving the 
application a public (NATted) port number, the NAT only accepts and forwards 
subsequent incoming UDP packets at that public port if they come from a 
source IP address that the application has previously sent UDP packets to.  
In other words, the NAT must see outgoing UDP traffic to a remote host before 
it will accept incoming traffic from that host on the application's public 
port.  In the proposed alternative, "Endpoint-independent filtering" or "Full 
Cone NAT", the NAT forwards any incoming traffic to the correct public port 
regardless of source IP address or port number.

Address-Restricted Cone NAT is moderately "P2P-friendly" in that it at least 
allows NATted applications to "hole punch" P2P connections with the help of a 
well-known (non-NATted) rendezvous server.  Address-Restricted Cone NAT still 
does not, however, allow the application to have a full "first-class" 
Internet presence (i.e., public IP address and UDP port number) at which it 
can be contacted proactively by any other Internet-connected host.  A P2P 
application behind an Address-Restricted Cone NAT is still forever dependent 
on other public (first-class) rendezvous servers to help establish each P2P 
communication session it needs.  A P2P app behind a Full Cone NAT, in 
contrast, is a full "first-class" network citizen itself, and can even _be_ a 
public rendezvous server for other less fortunate hosts once it learns its 
own public IP address and UDP port number.  This is an important benefit to 
applications, especially P2P applications that are trying to be highly 
decentralized.

The main argument for Restricted Cone NAT, of course, is security.  Until 
recently I believed this argument myself, but after further and more careful 
analysis I have come to the conclusion that Restricted filtering provides a 
very week security benefit in comparison with the fundamental loss in 
first-class application connectivity it entails.  My current proposal on the 
BEHAVE list does NOT mandate Full Cone NAT, but it does specify that NATs 
should at least be Full Cone in their default, "out of the box" configuration 
as provided by NAT vendors, and recommends that NATs implement Restricted 
Cone NAT as an administrator-configurable security option.  The current 
proposed text reads as follows:

   REQ-7: NATs MUST implement Endpoint-Independent
          Filtering in their default configuration.
          NATs SHOULD be configurable to support
          Address-Specific Filtering or Endpoint-Specific Filtering
          at the option of the system administrator.

If you have thoughts or opinions on this topic, I would greatly appreciate 
hearing them (and having other participants hear them) on the BEHAVE list.

** Why the Security Benefit of Restricted Cone NAT is Minimal **

Restrictive filtering ostensibly has the benefit of protecting applications on 
an internal host from traffic the internal host is not expecting, i.e., from 
traffic from previously unknown external hosts or endpoints.  This behavior 
can only possibly benefit the application if the application only ever 
initiates outgoing sessions from its internal port, and is obviously a curse 
if the application ever wants to accept incoming sessions from external 
hosts.  The NAT has no way of knowing which is the case.  But suppose the 
application is one that only initiates outgoing connections (i.e., a 
"traditional client/server app"), and thus might "potentially" benefit from a 
NAT's restrictive filtering behavior.  Consider TCP and UDP separately:

        ** TCP: When a client/server app makes an outgoing TCP connection, it 
typically does a "connect()" call to the host OS's sockets API without 
bothering to bind() the socket, and the OS's TCP stack allocates a local TCP 
port exclusively for the use of that connection.  Any TCP packets the host OS 
subsequently received on that port from endpoints other than the one it 
connect()ed to will be summarily rejected with TCP RSTs by the host OS, and 
the application never even sees any hint that they ever arrived.  Even if the 
application does a bind() before its connect() in order to use a specific 
source port (e.g., a <1024 "privileged" port), it still almost always obtains 
exclusive use of that port.  An application indeed has to work really bloody 
hard to set things up so that it can accept incoming TCP connections on the 
same port it is using for an outgoing connection, using SO_REUSEADDR and 
multiple sockets.  No traditional client/server application is going to go to 
all this effort just in order to create a security hole. :)  In other words, 
for TCP, restrictive filtering in practice provides absolutely zero 
protection from the _application_: the only entity that the restrictive 
filtering even affects is the host OS's protocol stack.  Restrictive 
filtering might for example benefit a host OS with a TCP stack that is so 
broken that it fails to check the source IP address and port number on 
incoming TCP packets at all, but if the host OS is _that_ broken then it 
undoubtedly has many other problems that the NAT can't possibly guard 
against.

        ** UDP: When a client/server UDP app uses a UDP port for communication 
with just one remote host, for convenience it typically does a connect() to 
the appropriate remote UDP endpoint, so that it can just send messages with 
send() or write() without having to specify a destination address for each 
datagram, and so that it can receive messages with read() or recv() without 
having to check the source address and port number in each message received.  
In this case, the host OS effectively provides the external endpoint 
filtering functionality as for TCP, and any restrictive filtering implemented 
by the NAT again provides no security benefit at all to the application.  A 
UDP application that uses a single UDP port for communication with multiple 
remote hosts, in contrast, must generally check the source IP addresses and 
port numbers in the datagrams it receives just in order to distinguish 
between the multiple communication sessions it is involved in, and hence it 
will inherently provide its own external endpoint filtering.  It's 
conceivable that some abysmally buggy UDP applications might benefit from the 
NAT's external filtering - e.g., a UDP application that only talks to one 
external endpoint but doesn't use connect() and doesn't check the source 
endpoint on incoming datagrams - but an application that is so seriously 
broken probably has many other security vulnerabilities that can be exploited 
despite the NAT's external filtering behavior, e.g., by finding out or 
guessing the public server the application is talking to (which is easy in 
many cases such as commercial games or services where there are only a few 
well-known servers) and sending packets with spoofed source IP address and 
UDP port numbers.  Besides, many, perhaps the majority, of UDP applications 
use UDP _because_ they need P2P-style communication, and so external 
filtering by the NAT provides no practical security benefit and only causes 
interference with the application.

Another common argument for Restricted Cone NAT (Address-dependent filtering) 
is that it protects the resources on the internal network from being consumed 
forwarding bogus packets even if the eventual end application will correctly 
discard them.  This argument is also weak, however:

	** Even with more permissive Full Cone NAT (endpoint-independent filtering), 
the NAT will still in practice filter out the vast majority of bogus traffic 
that reaches it, because most of the NAT's ports are typically not in active 
use by applications behind the NAT.  The only bogus traffic a Full Cone NAT 
will let through is bogus traffic that happens to hit the _specific_ external 
port numbers that correspond to active port bindings.  These port numbers are 
assigned more-or-less randomly (i.e., unpredictably) by the NAT, and they only 
ever appear in the high, non-well-known port number space, so most of the 
Internet "background noise" caused by viruses or other attacks on well-known 
ports will never get through in any case, and purely random "port guessing" 
attacks would have to send packets to a great many NAT ports in order to get 
a few packets through.  Thus, the incremental benefit of restrictive 
filtering over Full Cone NAT with regards to general bogus Internet traffic 
is very small.

	** An attacker might deliberately send bogus packets to a bound NAT port 
known to be in use.  But if the attacker can find out which NAT port the 
application is using, then the attacker probably also knows (or can easily 
find out or guess) the address and port number of the _remote_ host that the 
application is talking to and just spoof that source IP address and port 
number in its attack packets, getting around Restricted filtering as well.  
In fact the remote host's endpoint is in practice likely to be much easier 
for the attacker to find out or guess than the application's public NAT port, 
because of the overwhelming prevalence of well-known servers and ports on the 
Internet in comparison to the randomness and relative obscurity of temporary 
NAT-assigned public ports.  So the practical benefit that Restricted 
filtering provides even against directed attacks is still minimal.

	** Finally, the goal of "protecting the resources on the internal network 
from being consumed forwarding bogus packets" is really only a consideration 
on large corporate or ISP networks with substantial internal traffic load, 
and if this minimization of resource use is a concern then the network 
administrator can certainly be expected to know how to configure the 
company's NAT to enable Restricted filtering.  As I pointed out above, under 
my proposal a NAT can use Restricted filtering and still be BEHAVE-compliant 
as long as it is the administrator (not the NAT vendor) that enables this 
firewall behavior.

	** For home NATs, in contrast, minimizing resource load on the internal 
network due to bogus traffic is completely a non-issue because the home 
network (Ethernet or 802.11 or whatever) is typically so much faster than the 
Internet uplink anyway.  In this case it's much more important that NATs 
consistently support applications well, which my proposal ensures by 
requiring that the NAT's "out of the box" configuration is 
Endpoint-independent Filtering.  Joe Clueless who buys a home NAT router 
probably doesn't have any idea what NAT actually is, but he wants his 
applications to work.

** Conclusion **

In summary, restrictive filtering in the NAT interferes with applications 
substantially and provides very little real security benefit in 
practice, considering the way application communication and NAT port 
assignment actually works.  As such, especially considering the purpose of 
the BEHAVE working group is to increase the predictability and compatibility 
of NATs with applications and not to specify standards for firewall 
functionality, it seems highly inappropriate for the WG's documents to 
recommend firewall functionality that interferes with applications while 
providing dubious security benefits.  On the contrary, I think the WG should 
at least recommend, if not mandate, that NATs provide Endpoint-Independent 
Filtering (Full Cone NAT) by default.  NAT vendors or system administrators 
that are particularly paranoid about security and perceive the security 
benefits to be worth the interference it causes with applications can still 
enable more restrictive filtering policies, but that's a firewall deployment 
issue, not a NAT functionality issue.  We need to steer clear from 
recommending firewall functionality.

Thanks very much for your attention.  Please direct followups to the BEHAVE 
working group list, "ietf-behave at list.sipfoundry.org".  Thanks!

Bryan