Subject: Re: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P

From: Marc Manthey <[email-masked]>
Date: Mon, 20 Jun 2005 01:05:31 -0700 (PDT)

So, to make a long story short, NAT traversal is a hard problem,  
and it's
made especially hard by address-restricted NATs.
If I could count on
full-cone NAT behavior, my life as a programmer would be easier
IMHO, unless the draft absolutely
forbids non-full cone behavior, vendors that value security (as a
principle or as marketing hype) will continue to developing non-full
cone NATs.
Unfortunately I agree, but this can be said about any of the NAT
variables.  Each has its own pros/cons, and the problem as a  
developer
isn't dealing with misconfigured or broken NATs, it's dealing with  
the
wide variety of differently-configured NATS.  Reading through your  
IETF
charter, I see:

"Given the current near-universal deployment of NATs (Network Address
Translators) in the public Internet, **the lack of standards for NAT
behavior has given rise to a crisis**."
[emphasis added]

I'm not sure if this statement is referring to standards in terms  
of NAT
*implementation* or NAT *deployment*, and there's a very big  
difference.

[suresh] Indeed.

morning  all,

i found  some  stuff that might be  interesting

http://files.dns-sd.org/draft-cheshire-nat-pmp.txt

This document describes a protocol for automating the process of
 creating Network Address Translation (NAT) port mappings.

If you are concerned with standardizing the implementation of  
NATs, but
do nothing to standardize the deployment of NATs, you won't have done
much to mitigate the current crisis.  Indeed, it seems rather  
academic
to completely define anything but the lowest-common denominator,  
because
as a developer, that's all that matters.

amen:-)

At the moment, the lowest common denominator is punching holes  
through
address-restricted NATS, maintaining said holes with high-frequency
keepalives, and avoiding fragmentation using very small MTUs.

So long as you allow this configuration, I'm forced to develop  
towards
it, and anything less restrictive or easier might as well not exist.
[suresh] I agree with all your comments. Ideally, if the demand for  
initial
deployment was simply bi-diectional NATs, P2P application  
deployment would have
been a cake walk by now. Bi-Directional NATs would make the port  
bindings
Bi-diectional and would exhibit Full Cone NAT behavior for both TCP  
& UDP
applications.

Unfortunately, the predominant use-case of NATs during early  
deployment was
client-server apps and people were concerned mainly about hosts  
running the
client apps from behind NAT. P2P apps were not as prevalent.  
Security was a big
concern.

i found out that this called  spoofing  could  be eliminated with a  
simple proxy.

Bi-directionality requirement is not a UDP only rquirement for P2P  
apps.

exactly

The issue of security with Traditional NATs (which includes NAPT)  
is one of
illusion and can be really shattered only when app developers (both
client-server and P2P application developers) come forward and  
indicate that
their apps work just as well behind a bi-directioanl NAT as behind a
Traditional NAT. So long as there are applications that depend upon  
Address
restricted Cone NAT behavior, it gives the NAT vendors an  
opportunity to say
things like, my NAT (a traditional NAT) can provide better DOS  
protection than
the competetion's (which may be Bi-Directional NAT).

Granted, I'd welcome a better definition of "high frequency  
keepalives"
and "small MTUs".  But I'd welcome even more an absence of
address-restricted NATs.

Personally, I believe NATs are not firewalls, and shouldn't be in the
business of blocking traffic with the goal of enhancing security.
Firewalls are much more capable in this respect, and have much less
"collateral damage".
agree

But so long as NAT vendors are encouraged to market NATs as poor- 
man's
firewalls (ie, so long as the IETF does nothing to counter this  
trend),
I need to build with that in mind.

[suresh] I agree NATs are not firewalls. The blocking provided by the
Iraditional NATs was adequate for a number of deployments. I donot  
have a
problem with that.

cheers,
suresh
-david

cusoon  marc
--
" The reasonable man adapts himself to the  world
    the unreasonable one persists in   trying  to adapt the  world   
to himself.
   Therefore  all  progress  depends on the
     unreasonable man. -- George Bernard Shaw"

http://brain.let.de                                       cuseeme:// 
cuseeme.dyndns.tv

Attachment:
smime.p7s