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

[David Barrett]

Saikat Guha wrote:
>>From: David Barrett [mailto:dbarrett at quinthar.com]
>>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.

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.

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.

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".

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.

-david