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

Vernon Schryver <> Thu, 23 September 2004 18:21 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA06969; Thu, 23 Sep 2004 14:21:21 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CAYKQ-0006FP-6W; Thu, 23 Sep 2004 14:28:27 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CAY5c-0008Sc-9o; Thu, 23 Sep 2004 14:13:08 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CAXyi-00071x-5A for; Thu, 23 Sep 2004 14:06:00 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA05745 for <>; Thu, 23 Sep 2004 14:05:58 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CAY5X-0005tl-FU for; Thu, 23 Sep 2004 14:13:04 -0400
Received: (from vjs@localhost) by (8.13.1/8.13.1) id i8NI5RAx082574 for env-from <vjs>; Thu, 23 Sep 2004 12:05:27 -0600 (MDT)
Date: Thu, 23 Sep 2004 12:05:27 -0600
From: Vernon Schryver <>
Message-Id: <>
References: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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: 21c69d3cfc2dd19218717dbe1d974352

> From: Pekka Savola <>
> To: Harald Tveit Alvestrand <>

> > Well.... my house was behind 2 levels of NAT until last week.
> > Once i got rid of one level (the one I don't control), some of my 
> > operational problems with keeping SSH sessions up simply went away.
> > And SSH is a client-server protocol.
> > 
> > Don't underestimate the capability of badly implemented and/or configured 
> > NATs to make things go boom in the night.
> FWIW, I don't think this is something that can be fixed whatever
> guidance the IETF would give.  NATs will always need to keep some
> state for all the protocols, including TCP, and that state must be
> removed after a timeout.

Who said anything about necessary state and reasonable timeouts?  I've
seen more than one brand of consumer-grade box with NAT features that
could not be turned off, and that even in their most permissive settings
kill ssh sessions after an hour or two whether the ssh sessions had
been active or not.

Then there are notions of "DMZs," "game playing mode," and "VPN
support." What you might guess from feature-list bullet items
probably sound reasonable, but you'd probably guess wrong about
what the bullet items really mean in products delivered to users.

Harald misstated his injunction.  You should never underestimate the
capabilities of people to build things that make you say "no one would
do that!" and then defend their braindamage as valuable features.

Perhaps more NAT RFCs would help; they couldn't hurt much.  They'd be
a lot of work and would certainly be ignored by many people who consider
themselves designers.  I can't personally get enthused about telling
people things that are obvious and that will be ignored, like much of
what would go in new NAT RFCs.

Vernon Schryver

Ietf mailing list