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

Melinda Shore <> Mon, 20 September 2004 23:18 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA06152; Mon, 20 Sep 2004 19:18:13 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C9XWV-0005nv-Jh; Mon, 20 Sep 2004 19:24:44 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C9XLu-0002hr-Dc; Mon, 20 Sep 2004 19:13:46 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C9XHz-0001pk-5y; Mon, 20 Sep 2004 19:09:43 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA05347; Mon, 20 Sep 2004 19:09:40 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C9XOD-0005cW-6f; Mon, 20 Sep 2004 19:16:10 -0400
Received: from ( by with ESMTP; 20 Sep 2004 16:14:04 -0700
X-BrightmailFiltered: true
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id i8KN93wp011369; Mon, 20 Sep 2004 16:09:03 -0700 (PDT)
Received: from ([]) by (MOS 3.4.5-GR) with SMTP id AZF13022; Mon, 20 Sep 2004 16:09:06 -0700 (PDT)
Date: Mon, 20 Sep 2004 19:08:41 -0400
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v553)
To: Bob Hinden <>
From: Melinda Shore <>
In-Reply-To: <>
Message-Id: <>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit

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 
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 
that the *unavailability* of v6 NAT might hold up a transition to v6 in
some corporate environments because of their undereducated security 

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

That said, this work in the IETF is being driven by people whose 
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.  
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 
better deployed.  People who attended the IETF 60 BOF showed some 
for specifying inspection behaviors, which is pretty appalling on 
levels.  On the second point, I think there's legitimate concern that 
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 
for communicating directly with NATs, so in the interim we're doing 
STUN, however, doesn't work across certain varieties of NATs, so "good" 
behavior has to be specified.  And so it goes.


Ietf mailing list