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

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Sep 2004 08:38:28 +0300 (EEST)

[[ Resending the comment to [email-masked] as
[email-masked] illegitimately *) automatically
rejects the posts by non-subscribers.

*) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
]]

On Fri, 17 Sep 2004, The IESG wrote:
> A new IETF working group has been proposed in the Transport Area.  The IESG has 
> not made any determination as yet. The following description was submitted, 
> and is provided for informational purposes only. Please send your comments to 
> the IESG mailing list ([email-masked]) by September 24.

I do not think it's useful to spend too much energy in trying to 
figure how NATs work (or do not work).

Further, even though the draft charter talks about IPv6 and eventual
deployment, it seems to be ignoring the fact that if you use an IPv6
transition mechanism which is specifically designed to traverse NATs
(see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on
the 'reading list']), you don't have these problems.

And if you are able to use a transition mechanism which is not tied to
the IP versions supported by your ISP own, the barrier for IPv6
deployment should be significantly reduced.

Therefore the issue seems to boil down to whether the NAT traversal
mechanism described in draft-huitema-v6ops-teredo-xx is sufficient to
traverse the NATs, and whether the support for something like Teredo
is expected to be sufficiently commonplace to depend on it.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Sep 2004 14:03:40 +0200

I think the real point is that it's quite unrealistic at this
stage in the history of NAT to imagine that we can make the mess
(which was inevitable anyway) any better by codifying the
least-bad form of NAT behaviour. The NAT codes are shipped, burnt
into lots of devices, and the IETF can't do much about it.
So I think this would be wasted effort.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Sep 2004 14:28:44 +0200

> So I think this would be wasted effort.

My take (which is obviously biased) is that the number of NAT devices 2 
years from now is likely to be significantly larger than the number of NAT 
devices currently deployed.

And - here I am making a real leap of faith - if the IETF recommendations 
for NAT devices make manufacturers who listen to them create NAT devices 
that make their customers more happy, then many of these new NAT devices 
may  be conformant to IETF recommendations.

If we're really, really lucky - and reasonably fast - we could make the 
experience of people using the Internet better - "make the Internet work 
better" for those users.
And that's what the IETF is supposed to do, isn't it?

(Note - I sympathize with Pekka's touching faith in Teredo as the Big 
Solution.... I hope he's right. So the NAT recommendations may in that case 
boil down to a single sentence:

"Don't break Teredo"

If that's the case.... it's worth saying.)

                 Harald

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Sep 2004 14:38:51 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Harald" == Harald Tveit Alvestrand <[email-masked]> writes:
    Harald> My take (which is obviously biased) is that the number of
    Harald> NAT devices 2 years from now is likely to be significantly
    Harald> larger than the number of NAT devices currently deployed.

  Yes, I agree.
  And multiple layers too. And at higher speed points in the network.

    Harald> And - here I am making a real leap of faith - if the IETF
    Harald> recommendations for NAT devices make manufacturers who
    Harald> listen to them create NAT devices that make their customers
    Harald> more happy, then many of these new NAT devices may be
    Harald> conformant to IETF recommendations.

  Do we really want customers of NAT devices to be happy?
  
    Harald> (Note - I sympathize with Pekka's touching faith in Teredo
    Harald> as the Big Solution.... I hope he's right. So the NAT
    Harald> recommendations may in that case boil down to a single
    Harald> sentence:

    Harald> "Don't break Teredo"

    Harald> If that's the case.... it's worth saying.)

  I don't think we need a working group to say this.
  I think that the IAB could write a document much easier that said
that.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Sep 2004 15:31:09 -0400

inline.

>   Do we really want customers of NAT devices to be happy?

I think we want to enable an Internet that works and serves the needs of 
its users. We are still going to be seeing IPv4 on the network for a 
while still, and I believe it is worth our time to make sure that new 
applications can more easily be built for that network.

During the BoF session, there were folks from many of the major vendors 
of such devices, and those folks said that they felt that the IETF 
recommendations on NAT behavior stood a good chance of being implemented.

>   I think that the IAB could write a document much easier that said

I think the work to be done is far more complicated than just saying 
"don't break teredo". There is a lot of variability in NAT treatment of 
fundamental IP protocols - UDP, TCP, etc. Nailing down these 
variabilities can make applications more robust, more secure, and easier 
to design and deploy - a goal I think we all share.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Sep 2004 21:38:41 +0200

>   Do we really want customers of NAT devices to be happy?

Given that I'm one of them, and will continue to be one until the IPv4 
Internet fades to where I can ignore it.... yes.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Sep 2004 15:09:33 -0700

Harald,

>may  be conformant to IETF recommendations.

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

This is the IETF and if there is a constituency for working on this then I 
think it should happen.  However, I hope no one will be surprised in 2-3 
years that nothing much has changed.

Bob

---

From: Melinda Shore <[email-masked]>
Date: Mon, 20 Sep 2004 19:08:41 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Sep 2004 21:03:04 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I agree with Melinda.

I would very much like to be able to let the desk clerk at the hotel
know that I won't be paying for their "Internet" service, because it
wasn't RFCxxxx compliant. (I now wish that someone did get the trademark
on that word, and would deny it to locations that offer only NATwork service)

That's the only value I see in this situation.
For the the vendors that have a clue, and will likely be involved in
this process, they are likely already compliant. For those that aren't
compliant, they won't be there. That's tough for them.

- --

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Sep 2004 22:24:51 -0400

--On Monday, 20 September, 2004 21:38 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Given that I'm one of them, and will continue to be one until
> the IPv4 Internet fades to where I can ignore it.... yes.

Harald, let me make an observation that I made a few weeks ago
that that, to my astonishment, actually made Latif happy.

In your case, this is just a guess, but you are probably behind
a NAT for two reasons (Melinda's observation about increasing
corporate policies might well be a third).  One is the perceived
shortage of IPv4 space.  Whether that perception is real, or is
a marketing mechanism by ISPs who would prefer to sell you
something more expensive, or is just a delusion is irrelevant
for this purpose.  The point is that you are behind a NAT, in
part, because no one has given you enough IPv4 space.

The second is that, if I'm a vendor of cheap "cable/ DSL
routers", I've got to love NATs.  My device gets one address
from the ISP.  Every single clueless customer of the device has
the same address space, the same netmask, etc.  It is a customer
support dream because no one calls up and asks unique questions
about address ranges, funny masks, trick routing between
addresses on both sides of the router, and so on.  Until and
unless we have arrangements for IPv6 that use public address
space but

	* can be built into cheap products,  and
	
	* don't impose any greater customer support costs on
	those vendors, or the ISPs whose customers patronize
	them, then the current devices do, 

I think it is safe to predict that IPv6 will not reduce the NAT
frequency for SOHO situations one bit.

I hate that conclusion but I fear it is realistic.  To a certain
extent, we are _causing_ NATs, especially in IPv6 environments.
Now, is it worthwhile, given that, to allocate resources into
this proposed WG or should the resources be put into tidying up
the edges of IPv6 configuration?  I don't know, but I strongly
suspect that the people who are likely to do the work are
different.  And, if they are, this is probably a good idea,
however distasteful some of us find it.

     john

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Sep 2004 00:25:05 -0400

inline.

> on that word, and would deny it to locations that offer only NATwork service)

Well, I suspect the hotel clerk won't understand and certainly won't 
care what an RFC is. But, their service provider does, and I'm more 
hopeful that the RFP's and RFI's they produce and send to their vendors 
includes a statement that their NATs need to be RFCxxxx compliant, 
because it increases the ability of their networks to support 
applications that are ultimately driving demand for those networks.

> compliant, they won't be there. That's tough for them.

Actually, it's surprisingly more complicated than one might think to 
determine what the "right" thing is, in terms of NAT behavior and 
treatment of basic protocols such as UDP. Even clueful vendors appear to 
  have differing treatments even within the same product families [1]. 
For some of these behaviors, such as the UDP binding timeout interval, 
there is value in trying to shepherd everyone to arrive at a common 
minimal value (as in, the binding timeout MUST be greater than X). For 
that example, it's not an issue of clueful or clueless implementations, 
but rather, getting folks at a consistent value. That is exactly what 
standards are for.

Thanks,
Jonathan R.

[1] 
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-01.txt

---

From: Pekka Savola <[email-masked]>
Date: Tue, 21 Sep 2004 13:55:10 +0300 (EEST)

(Removed Cc: iesg)

> Internet fades to where I can ignore it.... yes.

The point is not whether the users behind an IPv4 NAT are happy or 
not.

The point is which kind of applications you can reasonably expect to 
deploy behind an IPv4 NAT, and be happy.

I agree with Harald that v4 NATs are going to be here a decade from 
now.  But that's irrelevant, if those people using the NAT only use 
simple client-server applications.

What matters is the peer-to-peer, etc. applications which typically 
require solutions like STUN, TURN, Teredo, etc.

My argument is that we can simplify the architecture significantly if 
we can assume that v4 NAT can be treversed using one particular 
mechanism (e.g., Teredo), and all the applications which have a more 
complex model than just client-server are just recommended to use IPv6 
instead.

If we can provide a reasonably working IPv6 connectivity solution(s),
we wouldn't have to try to figure out how to make NATs behave better,
how to build robust applications to work with these nicely or badly
behaving NATs, etc.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Sep 2004 13:02:03 +0200

> simple client-server applications.

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.

                        Harald

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Sep 2004 12:40:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> I agree with Harald that v4 NATs are going to be here a decade
    >> from now.  But that's irrelevant, if those people using the NAT
    >> only use simple client-server applications.

    Harald> Well.... my house was behind 2 levels of NAT until last
    Harald> week.  Once i got rid of one level (the one I don't
    Harald> control), some of my operational problems with keeping SSH
    Harald> sessions up simply went away.  And SSH is a client-server
    Harald> protocol.

  So, you were happier with less NAT. 
  See, I knew that making you happier behind the NAT was the wrong solution.

- --

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 20:35:00 +0300 (EEST)

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

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 23 Sep 2004 12:05:27 -0600 (MDT)

> From: Pekka Savola <[email-masked]>
> To: Harald Tveit Alvestrand <[email-masked]>

> state for all the protocols, including TCP, and that state must be

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    [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Sep 2004 15:16:49 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Vernon" == Vernon Schryver <[email-masked]> writes:
    Vernon> Perhaps more NAT RFCs would help; they couldn't hurt much.
    Vernon> They'd be a lot of work and would certainly be ignored by
    Vernon> many people who consider themselves designers.  I can't
    Vernon> personally get enthused about telling people things that are
    Vernon> obvious and that will be ignored, like much of what would go
    Vernon> in new NAT RFCs.

  They would help yes.
  They do have multiple costs: most people time.
  As you say.

  I can not agree more with what you said.
  The only value I can see to them is as a stick.

  Given RFC3022, RFC2663, RFC3235, etc. do we really need more carrots?

  Since I don't anticipate being able to book an RFC1812 compliant hotel
room anytime, I'm not sure that I see the point in expending more
energy.

- --

---

From: Leif Johansson <[email-masked]>
Date: Sat, 25 Sep 2004 11:21:12 +0200

> kill ssh sessions after an hour or two whether the ssh sessions had

I have one that shot down my ssh sessions after 5 minutes of aparent
inactivity - "Hey this tcp session hasn't seen any pr0n in 5 minutes.
It must be a stalled http. Let's kill it!" This is a *major* supplier
of soho equipment. Moreover it was clear from the support-forum that
this was a concious choice. The question is what effect a BCP from the
BEHAVE-wg would have. Personally I am an optimist.
	
	Cheers Leif