Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

On Monday, September 20, 2004, at 06:09 PM, Bob Hinden wrote:
> I think this ship has left port a long time ago and the likelihood 
> that the IETF can now effect enough change to make it possible to 
> write new applications that work consistently in the presence of NATs 
> is very low.   The installed base is much to large and NAT is showing 
> up in devices being built by people who don't pay too much attention 
> to the IETF.  The same folks who do not build in IPv6, who break path 
> MTU discovery, who strip out TCP options, etc.  Now we expect them to 
> build "good" NATs...

I'm ambivalent about it for some of the reasons you mention, plus 
others.
I think it's important to understand that NAT really is going to be with
us for the foreseeable future.  It's fairly common now to have corporate
security auditors require the use of NAT as a security device.  That's
a big fat training and cultural problem, and I don't see how the IETF
would be able to change it.  I don't think that it's completely 
unthinkable
that the *unavailability* of v6 NAT might hold up a transition to v6 in
some corporate environments because of their undereducated security 
auditors.

The other thing that's important to understand is that there are often
big changes between firmware releases for many consumer NAT products, 
and
that NAT vendors tend not to see making those changes as a terrificly 
huge
deal.  I don't think I agree with your concerns about lack of interest 
in
implementation.

That said, this work in the IETF is being driven by people whose 
protocols
break when they have a NAT in the path.  I have some concerns about
underinvolvement by people who build NATs for a living, but I think that
it's important to at least get some requirements laid out so that it's
clear what NAT manufacturers could be doing if they were interested.  
And
I think they are interested - they're hearing complaints from their
customers.  My biggest concerns are about 1) scope creep, and 2) a bunch
of workarounds being cobbled together and interfering with getting 
something
better deployed.  People who attended the IETF 60 BOF showed some 
enthusiasm
for specifying inspection behaviors, which is pretty appalling on 
several
levels.  On the second point, I think there's legitimate concern that 
this
is part of a process of developing a big jumble of duct tape and baling
wire.  Part of the problem here is that there's not yet a deployed 
solution
for communicating directly with NATs, so in the interim we're doing 
STUN.
STUN, however, doesn't work across certain varieties of NATs, so "good" 
NAT
behavior has to be specified.  And so it goes.

Melinda

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf