[p2p-hackers] Official IETF behavior recommendations for NAT
relevant to P2P
larytet.8753341 at bloglines.com
larytet.8753341 at bloglines.com
Wed May 18 21:07:56 UTC 2005
dear Bryan, feel free to forward this email to IETF.
best regrads, Arkady
----------------------------------------------
hi,
i am a principle
developer
of Rodi project http://larytet.sourceforge.net/btRat.shtml
i fully support
opinion expressed in this email http://zgp.org/pipermail/p2p-hackers/2005-May/002611.html
i think that it's a right thing to do to let (by default) packets from
any peer in the outside world to go through "hole" in NAT in case of UDP.
Arkady
--- Peer-to-peer development." <p2p-hackers at zgp.org wrote:
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