[p2p-hackers] Official IETF behavior recommendations for
NATrelevant to P2P
Warren Gallagher
wgallagher at gridironsoftware.com
Fri May 20 01:33:18 UTC 2005
Bryan,
I agree with your assessment. I would further argue that NATs are not
security devices, they are address translators. Security is the job of the
firewall. As long as firewalls do not restrict a sysadmin's ability to
control the behaviour then everything is good.
Thanks for the good work
Warren Gallagher
Chief Software Architect, Gridiron Software
-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org] On
Behalf Of Bryan Ford
Sent: May 18, 2005 2:59 PM
To: p2p-hackers at zgp.org
Subject: [p2p-hackers] Official IETF behavior recommendations for
NATrelevant to P2P
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
_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
More information about the P2p-hackers
mailing list