Subject: Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Jun 2003 09:59:15 -0700

Not at all.

If you want to address denial of service issues you need protocol
enforcement points.

The INTERnet is a bidging architecture between networks. Lets put asside the
dogma and build the infrastucture the users need.

 -----Original Message-----
From: 	Keith Moore
Sent:	Wed Jun 18 09:47:42 2003
To:	Hallam-Baker, Phillip
Cc:	[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject:	Re: myth of the great transition (was US Defense Department
forma lly adopts IPv6)

> I really wish that the IETF
> had designed a decent NAT box spec

that's an oxymoron.  the basic premis of NAT is fundamnetally broken.

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 13:05:28 -0400

> If you want to address denial of service issues you need protocol

NAT is a denial of service attack, not a means of policy enforcement.

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 10:42:38 -0700

> NAT is a denial of service attack, not a means of policy enforcement.

I don't think this is really accurate.

The difference between denial of service and policy enforcement
is primarily a question of authorization. Since the people who
install NAT generally own the networks in question, characterizing
NAT as a DoS attack doesn't really seem right.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
           Web Log: http://www.rtfm.com/movabletype

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 13:44:24 -0400

> NAT as a DoS attack doesn't really seem right.

people who run virus-laden programs are doing so because they want the
advertised functionality of that program, not because they want to infect
their systems or spread the virus.   people who use Microsoft mail readers do
so because they want to read mail, not because they want to expose their
systems to attack.

similarly, people who install NAT usually don't realize how much this
costs them in lost functionality and reliability.

perhaps DoS isn't quite the right term, but it's not far off.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Jun 2003 14:14:17 -0400

> NAT as a DoS attack doesn't really seem right.

Well, yeah, but ...  NAT is far too crude in its policy
capabilities to be able to credibly claim that it's a policy
enforcement device.  That's why we have all these ghastly
work-arounds - effectively they're for the purposes of
refining the policy semantics.  I think this may be one of
those cases where it's neither a furniture polish nor a
dessert topping.

I'm not sure that labelling it a "DoS attack" is
particularly helpful, though.

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 11:31:00 -0700

Keith Moore <[email-masked]> writes:

> > Really? You have evidence of this?
> 
> the evidence I have is from reading vendor advertisements for NAT boxes,
> and from talking to people who run networks that use NAT.  it's not 
> a random sample, perhaps not a statistically significant one, but it's
> been enough to convince me personally that the delusion is widespread.
You can perhaps understand why I wouldn't consider this a particularly
convincing line of argument.

> > I don't either, but my intuition is that you're wrong.  Once you have
> > decided to have a firewall in place (which you may think is evil, but
> > I consider pretty much a necessary evil), I suspect that most people
> > suffer almost not at all from having a NAT.
> 
> depends on what you mean by "firewall"  (which these days is a pretty
> vague term).  but there are several primary effects of NAT - one being
> that addresses are not maintained end-to-end, another being that NATs
> cause address-to-host bindings to be ephemeral when they would otherwise
> not be, and another being that (for NAPTs anyway) attempts to initiate
> traffic across the NAPT are blocked in one direction.  there is rarely
> a significant benefit in a firewall doing the first two of these.  a good
> firewall has the capability to block traffic in either direction, or not, on a
> case-by-case basis, and can be adjusted according to the needs of its users. 
Yes, but these are philosophical objections.

What applications that people want to run--and the IT managers would
want to enable--are actually inhibited by NAT? It seems to me that
most of the applications inconvenienced by NAT are ones that IT
managers would want to screen off anyway.
        
-Ekr

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 18 Jun 2003 20:41:33 +0200

> If you want to address denial of service issues you need protocol

Protocol enforcement points have so far failed to scale (today called 
border routers). What you need is to fix a much wider problem.

- - kurtis -

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 14:42:39 -0400

> > the evidence I have is from reading vendor advertisements for NAT
> > boxes, and from talking to people who run networks that use NAT. 
> > it's not a random sample, perhaps not a statistically significant
> > one, but it's been enough to convince me personally that the
> > delusion is widespread.
>

of course.  but you can perhaps understand why I don't consider your 
intiution to the contrary convincing either?

> want to enable--are actually inhibited by NAT? 

depends on the people.  the people I work with want to run large-scale
distributed computing problems.  other people want to use SIP to support
internet telephony or for some other purpose.  others want to use
IPsec...  yes there are workarounds for many of these, but they have to
be invented on a case-by-case basis, and often they're expensive.

---

From: S Woodside <[email-masked]>
Date: Wed, 18 Jun 2003 14:34:42 -0400

> If you want to address denial of service issues you need protocol

This sounds like you are equating a NAT box with a firewall, which 
seems to be common.

I would like to know:
- Is a NAT box a protocol enforcement point?
- is it an EFFECTIVE protocol enforcement point?
- is a NAT a firewall? (many people seem to think it is ...)
- is a firewall a protocol enforcement point? (yes)
- does a protocol enforcement point, have to include a NAT?
- does an EFFECTIVE one have to include a NAT?
- is it even EASIER to enforce protocol issues with a NAT as opposed to 
other means?

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 14:05:38 -0400

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 10:59:32 -0700

> so because they want to read mail, not because they want to expose their
Yes, I totally agree with that. What's your point?

> perhaps DoS isn't quite the right term, but it's not far off.
I'm not sold.

-Ekr

                http://www.rtfm.com/

---

From: S Woodside <[email-masked]>
Date: Wed, 18 Jun 2003 15:01:39 -0400

>> Once you have
>> I consider pretty much a necessary evil)

If by firewall, you mean "a box that can perform policy enforcement" 
then I don't think that many people in the IETF would think that's an 
evil thing. The problem is more that the general public seems to 
conflate firewall and NAT. Perhaps a new word is needed for "a box that 
can perform policy enforcement".

simon

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jun 2003 12:02:00 -0700 (PDT)

> suffer almost not at all from having a NAT.

I think Keith's point is that most people don't
realize what voodoo their box is doing until
something doesn't work. And then it just doesn't
work because it doesn't work. It's an attack of
engineering cynicism.

	     Mike

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 12:11:12 -0700

> intiution to the contrary convincing either?

Yes, but I'm not the one calling widely sold and deployed network
devices "Denial of service attacks". 

> be invented on a case-by-case basis, and often they're expensive.
I don't know enough about how you're doing your distributing computing
to have an opinion, but as for the other two... In my experience,
IT managers are pretty unhappy punching holes in their firewalls
for incoming SIP and IPsec, whether they run NAT or not. I'm
not sure that NAT is much of an impediment in these cases.

The bottom line here is what economists call "revealed preference".
People buy NATs and install them. I suppose it's possible that all
those people are stupid and the marginal utility of a NAT box is
actually negative, but that seems like a claim that would require some
pretty strong evidence.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 15:33:29 -0400

> devices "Denial of service attacks". 

Just for comparison against Phil's use of the term.  It's not how I
normally describe them (though I'm not exactly glowing in my praise...)

> for incoming SIP and IPsec, whether they run NAT or not.

In my experience, IT managers are generally pretty unhappy changing
anything to support their users.  People who actually use the computers
or the network are regarded as a nuisance.

> The bottom line here is what economists call "revealed preference".

Maybe "revealed ignorance" would be a better term.  Though I prefer
"unintended consequence".

Keith

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Jun 2003 15:37:46 -0400

> managers would want to screen off anyway.

Not really.  For example, ftp as originally defined doesn't
work through NATs, and no standard VoIP or multimedia
conferencing protocol works through NAT.  

What I think is a huge problem that people tend to be pretty
hand-wavy about is that many of the mechanisms that are
introduced to help complex applications work through NATs
introduce new security exposures, whether it's the
"pseudo-NAT attack" described by Dupont and that we've run
into with STUN, or external relays allowing internal users
to run unauthorized servers, or stateful inspection/rewrite
forcing application users not to use encryption or integrity
protection, or ...  NAT has a surprisingly wide ripple
effect that's almost completely negative.

Melinda

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 18 Jun 2003 14:45:23 -0500

on 6/18/2003 1:31 PM Eric Rescorla wrote:

> want to enable--are actually inhibited by NAT? It seems to me that most
> of the applications inconvenienced by NAT are ones that IT managers
> would want to screen off anyway.

Oracle and H.323 have both been historically problematic, and are both
reasonable applications. Home users also suffer a lot with perfectly
innocent services like games. Ignoring the rifle-shot arguments, requiring
an application to be rebuilt or that a middlebox learn to ~emulate an
active end-point are both miserable choices, and generally unnecessary.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Tomson Eric \(Yahoo.fr\)" <[email-masked]>
Date: Thu, 19 Jun 2003 00:28:09 +0200

First of all, for the purists : I apologize for this simplified explanation
of what firewalls are. I guess we could start a very long thread about
firewalls and NATs, but the idea is to give a (somewhat) short answer (maybe
over-simplified) to some short questions asked by Simon Woodside (see
bottom).
-------------

There is not ONE firewall. A firewall is not a product, it's more like a
concept. The idea of a firewall is to build a protecting wall between an
external (public) network and an internal (private) network, by granting or
denying incoming/outgoing packets based on specified/configured
rules/policies. In the real world, there are different kinds of firewalls.

Compared to the OSI or TCP/IP layers, firewalls can work at different
layers.

There are mainly :
1.packet filters (analyze the IP packet and identify the IP addresses and
port numbers, then apply a set of rules),
2.circuit level gateways (work mainly at session layer, by identifying flows
of data and established connections),
3.application level gateways or proxies (application specific : http, ftp,
telnet,... with possible extended features, like caching possibilities,
logging of user activity,...), and
4.stateful inspection firewalls (more recent, combinations of types 1. 2.
and 3., more performant than 1. and 2., less complex than 3.).

A simple router, using access lists based on the IP addresses, analyzing
each packet one by one, is a basic firewall of type 1.
A more advanced device, able to identify "conversations", "sessions", is a
bit more advanced firewall of type 2.
A complex software, configured to analyze the addresses, the port numbers,
the protocols in use, possibly the contents of the applications data, is a
very complex firewall of type 3.

A basic router (not a firewall) will "transparently" interconnect different
networks, maintain routing tables, and advertise those tables to its
neighbors.
A NAT will "mask" the internal addresses, only maintain its own private
translation table, and not transmit it to any other device.

A Network Address Translator will usually translate "n" public, official IP
addresses into "n" private, internal IP addresses and keep the current port
numbers unchanged.
A Network Address and Port Translator will usually translate ONE public,
official IP address into SEVERAL private, internal IP addresses by
translating the external port numbers to correspond to the different
internal combinations of <network address + port> (external packets will
only transport ONE IP address - the public, official one).

Pure NATs will only translate network addresses. PATs and NAPTs will
translate port numbers, too. In no case will any of them translate the
protocols - that would prevent clients and servers from understanding each
other (a web client with a telnet server, etc.).

NATs will mask the internal addresses from outside view, but won't use
policies, control the traffic, perform authentication, or prevent spoofing :
NATs ARE NOT FIREWALLS!!!

On the other hand, circuit level gateways and application level gateways
transparently perform address translation!!! The addresses of the internal,
private network are masked from outside view!
Packet filters and stateful inspection firewalls don't translate IP
addresses and port numbers.

So, in short :
1/ a NAT is not equal to a firewall, it's not a firewall! Some firewalls DO
perform Network Address Translation, but NATs DO NOT perform firewalling!
2/ the main, primary purpose of a NAT is to use a limited set of public
(external) IP addresses and make them correspond to a wider range of private
(internal) IP addresses, in order to make savings, either in terms of IPv4
addresses, or because it's simply cheaper than buying several public IPv4
addresses. Now, the fact that masking the internal addresses to the external
world - so that internal hosts can initiate traffic to the outside, but no
external host can initiate traffic to the inside - brings some basic
security, is an interesting corollary, but not the primary objective of a
NAT.

Hope this helps. And sorry again for the purists. ;)

E.T.
ICT Consultant and Trainer.
Member of IEEE, IPv6 Task Force, ISOC, PIR.

=>-----Original Message-----
=>From: [email-masked] [mailto:[email-masked]] On 
=>Behalf Of S Woodside
=>
(...)
=>
=>This sounds like you are equating a NAT box with a firewall, which 
=>seems to be common.
=>
=>I would like to know:
=>- Is a NAT box a protocol enforcement point?
=>- is it an EFFECTIVE protocol enforcement point?
=>- is a NAT a firewall? (many people seem to think it is ...)
=>- is a firewall a protocol enforcement point? (yes)
=>- does a protocol enforcement point, have to include a NAT?
=>- does an EFFECTIVE one have to include a NAT?
=>- is it even EASIER to enforce protocol issues with a NAT as 
=>opposed to 
=>other means?
=>
=>simon
(...)

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 16:04:06 -0700

> or the network are regarded as a nuisance.
Exactly. So, why do you it's NATs that are the cause of users
not getting the things they want, as opposed to the usual IT
manager behavior.

> "unintended consequence".
Huh? The IT managers could not use NAT if they wanted. What
evidence do you have that they consider them a bad tradeoff?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 16:06:08 -0700

> conferencing protocol works through NAT.  
None of these things worked real well through firewalls either,
which is sort of my point.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 19:04:10 -0400

> > anything to support their users.  People who actually use the
> > computers or the network are regarded as a nuisance.
>

good point.  maybe the very reason that IT managers like NATs is that
they make the users' lives more difficult, and they provide job security
for IT managers who have to sort out NAT problems just so that things
can work at all.  but from the ones I've talked to, some combination of
ignorance, brainwashing, and stupidity seems more likely.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 16:18:59 -0700

> ignorance, brainwashing, and stupidity seems more likely.

One of the things I've always find endearing about IETFers is their
utter confidence that whenever the world disagrees with them about the
value of some technical approach, it must be because everyone else in
the world is stupid.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jun 2003 19:20:35 -0400

> value of some technical approach, it must be because everyone else in

hey, not everyone else is an IT manager :)

investing in nat boxes is a lot like investing in lottery tickets.
but for some reason both sell well...

---

From: George Michaelson <[email-masked]>
Date: Thu, 19 Jun 2003 10:33:00 +1000

Just because I *have* a NAT box to use at home doesn't mean I *like* NAT.

I expect to find deployment of IPv6 at home challenging, in part because I've
already spent my 'five-year-plan' funds on networks for home. 

Its the same road-trap digital TV is caught in: people do not rush out and buy
even small communications/technology investments as throw-away devices. TV sets
last for 5-10 years. Hi-Fi sets last even longer. $5 low-fi radios last almost
forever, sliding down the hierarchy from the living room, to the kitchen, to the
garage. 

I expect my Nat box to last another two or three years. I do not expect the
vendor to be able to ship an IPv6 ready image for this box. Therefore I will
have to convince the 'house funding committee' to let me replace this box before
its real end-of-life window. That is hard, set against the cost of painting the
house, or urgent repairs to the steps, or replacing the VHS recorder by a DVD
player.

If a massive volume of IPv6 ready NAT or other boxes arrived on the market right
now, I do not think the take-up would be explosive. The early adopters might buy
in but it would require the *default* configuration to new players to be fully
V6 enabled, and even then the rollover time in the home segment would be
measured in years.

NAT is irrelevant to this IPv6 deployment thing. its neither an obstruction nor
a benefit. The business cycle and non-financial motivations about spending and
lifestyle are just as relevant, if not more so.

If my home network supplier let me have multiple IPv4 DHCP addresses that
were routable behind the cable box, I would probably still keep this NAT box,
even if I did turn off NAT. 

I still have my recordplayer connected to my Hi-Fi even if I don't play records
much.

 cheers

-George

---

From: [email-masked]
Date: Wed, 18 Jun 2003 23:44:51 -0400

> which is sort of my point.

There's a *crucial* distinction here:

If it doesn't work through a firewall, it's because the firewall is doing
what you ASKED it to do - block certain classes of connections.

If it doesn't work through a NAT, it's because the NAT is FAILING to do what
you asked it to do - allow transparent connections from boxes behind the NAT.

Unless of course you're deploying NAT for some reason *OTHER* than
transparent connections?  Are you trying to get your money's worth because
you paid for the extra-deluxe "works most of the time but breaks some apps"
version?

Or is the only reason you have NAT at all because you bought some vendor's
"connection appliance in a box" that proceeded to NAT you regardless of your
desires?

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 21:30:35 -0700

> you paid for the extra-deluxe "works most of the time but breaks some apps"
This seems to me like a false dichotomy. If I were deploying a NAT 
(which I didn't) there would be certain things I would care about
and others I didn't. If I'm already firewalling off these services,
why should I care if NAT blocks them?

> "connection appliance in a box" that proceeded to NAT you regardless of your
Why is it so hard for people here to believe that customers might
actually know what they want, even if you don't happen to think
it's a good idea?

-Ekr

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 00:55:49 -0400

On Wednesday, June 18, 2003, at 06:28  PM, Tomson Eric ((Yahoo.fr)) 
wrote:

> Now, the fact that masking the internal addresses to the external

Is this just security through obscurity, or something better?

simon

---

From: [email-masked]
Date: Thu, 19 Jun 2003 00:56:42 -0400

> why should I care if NAT blocks them?

So it's OK for NAT to break any application that *you* don't want to
let through *your* firewall anyhow.

What's wrong with this picture?  Well.. Sure, if you currently only allow
3 ports through your firewall anyhow, and those 3 applications happen to
be NAT-tolerant, it's probably no impact on YOUR site.

Of course, if you *ever* encounter an application that your site wants to
allow through the firewall, but you discover that you STILL can't deploy it
because NAT breaks it, you'll be wanting some mayonnaise to make that crow
sandwich go down more easily.

You're missing the point that when a firewall breaks things, it's doing
its job.  When a NAT breaks things, it's failing to do its job.

Now let's say a firewall is a pair of suspenders, and a NAT is a belt.  This
makes your position:

"I don't care that my belt unzips my trousers every time I go through a
revolving door, because I'm never in a situation where failure of my
suspenders would be an embarassment".

As Randy Bush says: "I invite my competitors to design their networks this way".

> actually know what they want, even if you don't happen to think

Tell you what - you round up all the big domains that actually have a clue
about what they want, and who understand the distinction between a firewall and
a NAT (even if they are in the same box), and I'll round up all the users who
are scratching their heads because they have a cablemodem or an ADSL modem
(either ISP-provided or off the shelf at Walmart) that is an all-in-one modem/
router/firewall/NAT, and some stuff Just Does Not Work.

And unfortunately, a lot of the Just Does Not Work stuff are applications
like H.323 and VOIP that Joe Sixpack actually *might* be interested in.

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jun 2003 22:19:12 -0700

> let through *your* firewall anyhow.
Yes, it's ok for *my* NAT to do so.

> its job.  When a NAT breaks things, it's failing to do its job.
Obviously, I disagree.

> suspenders would be an embarassment".
You've got it absolutely backwards. The fact that the NAT breaks applications
that I don't want to run anyway is a FEATURE, not a bug.

> like H.323 and VOIP that Joe Sixpack actually *might* be interested in.

Ah, the eternal lament of the technocrat who can't understand why the
customers don't want what he knows is so obviously good for them. 

If this were actually a real problem, I'd expect that someone would
be making good money offering service which didn't have this 
problem. Strangely, however, people still seem to buy these products
of which you so obviously disapprove. I guess they don't think the
downside is so terrible.

-Ekr

---

From: James Seng <[email-masked]>
Date: Thu, 19 Jun 2003 13:30:28 +0800

Why should the users be limited to what IT managers decide is good or bad?

Internet is build on dumb network, smart terminal. End-users are suppose 
to be able to put up their own services, not just running some apps. 
This has been the Internet principles and have serves us well so far.

(The telcos model, OTOH, is the inverse, assuming smart network and very 
very dumb terminal.)

-James Seng

---

From: [email-masked]
Date: Thu, 19 Jun 2003 01:31:00 -0400

> that I don't want to run anyway is a FEATURE, not a bug.

And the fact that NAT breaks things that you DO want to run is a <?>

> customers don't want what he knows is so obviously good for them. 

No, the lament of a technocrat who can't deploy things that customers DO want
because NAT breaks them.

Find a user.  See if they'd be interested in video or voice over IP.  Watch
them say "ooh... that sounds cool".  Then tell them it would be unreliable
and you could only use it to talk to other users some of the time, because
a lot of users are on these things called NATs, and watch enthusiasm wane.

---

From: [email-masked]
Date: Thu, 19 Jun 2003 01:34:28 -0400

> Is this just security through obscurity, or something better?

Security through obscurity.  See Bellovin's paper on enumerating through a NAT.

Steven M. Bellovin, "A Technique for Counting NATted Hosts. Proc. Second
Internet Measurement Workshop, November 2002.

http://www.research.att.com/~smb/papers/fnat.pdf  (or fnat.ps if you prefer)

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 19 Jun 2003 00:57:03 -0500

>> None of these things worked real well through firewalls either, which
>> is sort of my point.

> If it doesn't work through a firewall, it's because the firewall is
> doing what you ASKED it to do - block certain classes of connections.
>
> If it doesn't work through a NAT, it's because the NAT is FAILING to do
> what you asked it to do - allow transparent connections from boxes
> behind the NAT.

Exactly. I can tell a firewall to get out of the way (stupid as that may
be in some cases) and the application protocols will function as designed
and expected. I cannot tell a NAT to do that, but instead must first
educate the vendor about the protocol that's being blocked, wait for them
to do their market research and/or prioritize the application among their
Great List of Applications They Have Broken, and then maybe one day get a
patch that actually spoofs the protocol well enough for it to work with a
middlebox in the way. There are some (very few) exceptions to the latter
routine, but that's the usual dance.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 19 Jun 2003 03:46:40 -0400

>a lot of users are on these things called NATs, and watch enthusiasm wane.

Find innovative company that finds a way to make VOIP work across NAT 
boxes. Watch them collect lots of customers (example: www.vonage.com).

The NAT working group produced a number of documents. Some explained the 
limitations, while one explained to application writers how to live in the 
real world that includes NATs. Read RFC 3235.

A $50 NAPT box (using terminology from the NAT WG's terminology RFC) 
provides sufficient firewalling and purposeful interruption of applications 
for the typical DSL or cable modem user. It runs somewhere OTHER than on 
the user's computer, so when a virus gets in and tries to disable the 
user's firewall software, less damage is done.

If you have users who want/need services that you can't manage to make 
function over NAT, then buy those folks a higher grade of access. The 
reality of the marketplace is broadband connections generally have 
inexpensive NAPT/router boxes. That's been driven by the economics of the 
service model. In great measure the service agreement with broadband 
vendors also stipulates users are not permitted to run servers. If you 
don't like the model, buy service elsewhere.

Sadly, the IETF seems to find ways to generate immense amounts of heat over 
NAT, while sticking its collective head in the sand with regards to 
activity in the marketplace. If the organization wishes to retain ANY 
relevance, it will have to find a way to deal with reality.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 19 Jun 2003 03:57:40 -0400

>Security through obscurity.  See Bellovin's paper on enumerating through a 

Maybe YOU should read it, and explain how this is useful for attacking the 
hosts behind a NAPT box. The technique described in this paper uses 
variations in the IPid field as evidence of more than one host generating 
packets. Fine. So you plunk a box just upstream of the NAT box, and now you 
can determine how many ACTIVE hosts are talking to sites outside the NAPT box.

Since NAPT uses stateful inspection to operate, it only permits packets in 
to the private network in response to outbound packets. Sitting directly 
upstream of the NAPT box, you could try spoofing reply packets. This would 
work equally well for any stateful-inspection firewall.

So what is really at risk, described in Steve's paper? It is possible to 
determine if NAPT is in use, if the NAPT implementation is insufficiently 
careful in its handling of the IPid field (and likely most do allow 
analysis of this sort). In essence, Steve's paper provides useful 
information for improving NAPT implementations if anyone is worried about 
having upstreams learn of the presence of a NAPT box.

I reject your contention of NAPT as "security through obscurity."

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 06:07:44 -0400

> real world that includes NATs. Read RFC 3235.

nope, RFC 3235 doesn't explain how to make your applications work in the
presence of NATs.  it essentially says: there are lots of things you can't do
in the presence of NATs, so don't do them.  never mind that they make the 
network dysfunctional, the document is written as if this is somehow a
feature.

> for the typical DSL or cable modem user. 

and kills that user's ability to run valuable applications.  in fact, the NAT
is not a firewall at all.  it isn't implementing any policy specified by the
user.  what it's doing is imposing some arbitrary restrictions on the user's
network that may or may not serve the user's interests at all.  it's snake
oil.

> It runs somewhere OTHER than on 

well, the user's computer gets infected anyway.   the NAT is left unharmed,
but I don't consider this a feature.
 
> activity in the marketplace.

the NAT vendors are the irresponsible ones.  they create a mess out of the
network and then expect IETF to clean it up, then claim that IETF is in denial
for not doing so.  and of course IETF has tried to do so, more than once,
and failed.  not for lack of effort, but because it's simply not possible to
fix NATs.

maybe you are the one who needs to get his head out of a dark place.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 07:30:19 -0400

> actually know what they want, even if you don't happen to think

Going back a message or two, the firewall problem is more
tractible than the NAT problem but you're right, it's
similar in some of its impediments.

Anyway, I do think that people know what they want, but from
talking with the denizens of, say, comp.security.firewalls
there's a lot of confusion about the technology, what it
accomplishes, and what problems it introduces.

My take on it is that users and network administrators
really - I mean *really* - don't want universal reachability
anymore.  They want to be reachable by the people they want
to be reachable by and nobody else, and that's technology
that we don't know how to provide.  In the absence of better
technology they're relying on firewalls and NATs.  I think
there's a gross mismatch between the economic model
underlying IP and the ones underlying how networking is
practiced today, and that the resulting problems are
inevitable.  I'm pretty sure that standing around cursing
the darkness isn't a useful response.

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 06:51:16 -0700

James Seng <[email-masked]> writes:

> Internet is build on dumb network, smart terminal. End-users are
> suppose to be able to put up their own services, not just running some
> apps. This has been the Internet principles and have serves us well so
> far.
No large production network can run this way. The end machines are 
simply too vulnerable. Without firewally and service restriction,
you'll have your entire network compromised very quickly.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 06:59:56 -0700

> And the fact that NAT breaks things that you DO want to run is a <?>
I'm not convinced that this is happening... if it is,
why isn't there a market reaction.

> a lot of users are on these things called NATs, and watch enthusiasm wane.

Given that there are workarounds for these, I find this explanation
pretty unlikely. More likely is that people's revealed preference
is that they don't actually want this stuff.
                                   
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 07:03:00 -0700

> and failed.  not for lack of effort, but because it's simply not possible to
This is more hyperbole. How have NATs created a mess out of the network?
Yes, I understand that they've made the network environment more 
complicated which makes life hard on protocols designers. So what?
If the customers are getting what they want, that seems to me that it
can hardly be characterized as a "mess". And you have yet to establish
that they're not getting what they want.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 10:10:50 -0400

> that they're not getting what they want.

certainly the users I deal with are not getting what they want.
others seem to be reporting similar experiences.

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 10:40:13 -0400

> Then why don't they switch providers.

variety of reasons: often the provider is not the problem, it's the local
network admins, and the users aren't free to go elsewhere.  some of the time
when the provider is the problem, there are no alternatives.  until recently
the only way I could get even one static IP address for my home was through a
special deal with a friend of mine who had a small ISP, and the best bandwidth
I could get was 128kbps.  none of the other local providers would sell me one.

> Revealed preference suggests that they *are* getting what they want, no
> matter how much complaining.

so if you can't come up with a rational explanation for something, just
pretend that the market is wise and cite it as an unimpeachable authority.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 10:48:08 -0400

> that they're not getting what they want.

NAT (and, to a less extent, firewalls) are definitely
interfering with the deployment of some new services,
including VoIP and multimedia conferencing, of course, but
large-scale distributed scientific computing is a problem as
well.

I'm highly uncomfortable with your argument.  I don't think
that the IETF should be architecturally fundamentalist (that
is to say, it's not that I think that we need to roll over
and play dead for every popular bad idea that's out there,
but that I think we should learn to be smart about where and
when to compromise) but I really take exception to the
notion that as long as users are happy there's really no
problem.  As I said before, the workarounds that are being
used to help facilitate application traversal of NATs are
definitely introducing new security problems that wouldn't
exist if the NAT weren't there.  There are other problems
around robustness and routing.  I think this is a bad thing,
myself.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jun 2003 08:14:08 -0700 (PDT)

> managers would want to screen off anyway.

Uh, have you paid no attention to voice? It
qualifies on both counts. We get complaints from
customers each and every day... the ones that are
lucky enough to figure out that NAT is why their
IP phone doesn't work that is.

	 Mike

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 07:39:56 -0700

> others seem to be reporting similar experiences.

Then why don't they switch providers. Revealed preference suggests
that they *are* getting what they want, no matter how much
complaining.

-Ekr

---

From: Richard Welty <[email-masked]>
Date: Thu, 19 Jun 2003 12:14:47 -0400 (EDT)

> why isn't there a market reaction.

such maybe building. i have a client who for budgetary reasons are using an
inexpensive Ameritech DSL line. because of their location, they have
extremely limited broadband options.

Ameritech only gives them a /29, with no option for additional IPs
available. a third party vendor also requires IPSec for an application they
need, and the third party only supports pre-shared keys.

the needed three legged firewall, bridging two interfaces and using NAT on
the third one, is rather more complicated than i wanted to deploy for a
budget-constrained customer. neither i nor my client feel that there was a
much of a win here, but there weren't any other options, either.

i'll wager that increasing use of IPSec will start to create pressure. just
a hunch. but my customer can't create meaningful pressure when the phone
company is involved; it takes thousands of small customers screaming to get
an RBOC to take notice, maybe more. it could be a few years...
 
> is that they don't actually want this stuff.

all too often, for small customers, the workarounds are expensive or unknown
to them. in the particular case i cited above, my customer would have spent
a lot less money on my time if they could have simply gotten a /27 from
Ameritech and dispensed with port NAT entirely, and they and i both know
that this was the preferred option.

richard
--
Richard Welty                                         [email-masked]
Averill Park Networking                                         518-573-7592
              Unix, Linux, IP Network Engineering, Security

---

From: Richard Welty <[email-masked]>
Date: Thu, 19 Jun 2003 12:33:59 -0400 (EDT)

> that they *are* getting what they want, no matter how much

in many places, the choice of broadband providers is quite poor. see my
earlier posting about my client for whom Ameritech DSL was the only
affordable choice, and we just barely made it work for their application.

richard

---

From: "Neil Carpenter" <[email-masked]>
Date: Thu, 19 Jun 2003 13:00:47 -0400

> affordable choice, and we just barely made it work for their
application.

This seems like a specious argument.  The client had chosen, as you
indicate, to scrimp on their broadband provider to save money.  You also
indicate that other providers were available.

The nature of picking any product is cost vs. benefit.  In this case,
the customer chose to favor cost and, thus, received less benefit.

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 10:07:45 -0700

> I could get was 128kbps.  none of the other local providers would sell me one.
Doesn't the fact that there's not enough demand for this product
to make it available suggest anything to you?

> pretend that the market is wise and cite it as an unimpeachable authority.

I do have a rational explanation: the customers don't actually care
at all about your fundamentalist commitment to end-to-end connectivity.

So, on the one hand, we have the actual behavior of millions of people.
On the other hand we have Keith Moore's opinion about what they ought
to prefer. I don't have any trouble figuring out which one I believe.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 10:10:13 -0700

> IP phone doesn't work that is.

As I said, these would be screened off by corporate firewalls in most
cases anyway.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 10:16:00 -0700

Melinda Shore <[email-masked]> writes:
> As I said before, the workarounds that are being
No doubt it's a bad thing. Very few technical solutions are unalloyed
goods. I think of these sorts of things as sort of the networking
equipment of drug side effects--an undesirable side effect of things
that are otherwise desirable. Now, reasonable people can disagree as
to the relative importance of the good and bad effects, but absent
evidence to the contrary, I generally assume that people are able
to make those choices for themselves.

I'm not sure what you mean by routing above. Are you suggesting there's
some negative externality in that NAT makes the routing infrastructure
more complicated? If so, what is it?

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jun 2003 10:17:51 -0700 (PDT)

> As I said, these would be screened off by corporate firewalls in most

That there are also issues with firewalls is
entirely beside the point. And firewall traversal
using a VPN is a trivial and deployed solution to
the firewall traversal problem. And is often a
good one, modulo inflated packet size for RTP
streams which generate small packets.

Thus the point stands: NAT's are right now a
serious problem for the deployment of voice. By
real customers who have real desires for
deployment. Your handwaving here is not borne out
in the reality of our business or anybody else's
who's involved with voice. And frankly your
uninformed dismissive tone here is rather
unbecoming for those of us who've had to actually
deal with this issue for years.

	  Mike

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 13:21:47 -0400

> > until recently the only way I could get even one
> > static IP address for my home was through a special deal with a
> > friend of mine who had a small ISP, and the best bandwidth I could
> > get was 128kbps.  none of the other local providers would sell me
> > one.
>

does the fact that there was enough demand for the product that it
eventually became available suggest anything to you?

> > so if you can't come up with a rational explanation for something,
> > just pretend that the market is wise and cite it as an unimpeachable
> > authority.
> 

true, customers don't care about e2e.  they do, however, care about
running apps that won't work when e2e is broken.

> So, on the one hand, we have the actual behavior of millions of

no, we have your biased interpretation of that behavior, as observed
from a great distance, through a dirty lens. 

Keith

---

From: Richard Welty <[email-masked]>
Date: Thu, 19 Jun 2003 13:27:51 -0400 (EDT)

On Thu, 19 Jun 2003 13:00:47 -0400 Neil Carpenter <[email-masked]> wrote:

> > in many places, the choice of broadband providers is quite poor. see
> > my earlier posting about my client for whom Ameritech DSL was the
> > only affordable choice, and we just barely made it work for their
> > application.

> the customer chose to favor cost and, thus, received less benefit.

well, they'd dumped Covad for abysmal service. anyone else was so pricy
that the project would not go forward at all; the monthly recurring cost
was simply a budget buster.

it's not a matter of scrimping so much as a matter of whether the project
is even feasible under the budgetary constraints. port NAT enables some
folks to run lots of computers behind small subnets, sure, but it also has
the side effect of disabling or nearly disabling lots of other
technologies. the folks who have the hardest problems are the ones with the
least cash. telling someone with a small budget that they can solve their
problem with an application of more money (to get a better provider) isn't
advice that goes down so well.

richard

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 13:43:30 -0400

Exactly. A NAPT  (not a NA(!P)T ......) is in fact a perfectly good 
firewall* for the home user. So all this argumentation that a "NAPT is 
not a firewall" is bunk.

* where firewall = a device that protect my internal net from external 
threats

simon

On Thursday, June 19, 2003, at 03:46  AM, Daniel Senie wrote:

> provides sufficient firewalling and purposeful interruption of 
> applications for the typical DSL or cable modem user. It runs 
> somewhere OTHER than on the user's computer, so when a virus gets in 
> and tries to disable the user's firewall software, less damage is > done.
>

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 13:45:53 -0400

Keith, I don't get this argument. A NAPT is a firewall by your own 
definition "I believe the primary purpose of firewalls should be to 
protect the network, not the hosts, from abusive or unauthorized 
usage." It's implementing a very simple policy, protect me from the 
outside world.

simon

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 10:53:07 -0700

> eventually became available suggest anything to you?
Yeah, that there's a subset who cares. They got it. The market is
working. Why are you complaining?

> running apps that won't work when e2e is broken.
Apparently not, or they wold switch.

> from a great distance, through a dirty lens. 
Huh? Are you claiming that people don't 
(1) Buy NATs
(2) Use them?

Of course they do. 

I'm not sure why you're accusing me of bias, Keith. Frankly, I hate
NAT. It makes my life as a protocol designer miserable and I don't use
it myself. I just don't fool myself that my preferences represent
those of people at large.

-Ekr

---

From: [email-masked]
Date: Thu, 19 Jun 2003 10:35:01 -0700 (PDT)

> which is sort of my point.

This certainly has not been my experience. All of my equipment is behind a
firewall, but I have two sets of IP address - a small set of carefully hoarded
global addresses and a much larger set of NATed addresses.

Whenever I add something (which it seems is often) I first try it with a NATted
address. If that doesn't work I am forced to switch it to a global address.

All too often (VoIP phone, video conferencing, file sharing, etc.) I am
forced to switch to a global address before things work properly.

The firewall, on the other hand, has only been a problem once, and that was
because of an unfortunate lack of flexibility in its handling of a fairly
unusual setup involving FTP. A patch readily solved the problem.

NAT being an issue hasn't escaped the notice of vendors. My VoIP phone's
documentation discussed NAT problems at some length, but the proposed
solution -- use a specific NAT product that has been gimmicked to work
correctly -- isn't always a viable option.

				Ned

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 10:54:10 -0700

Michael Thomas <[email-masked]> writes:

> the firewall traversal problem.
And you can use similar solutions to traverse NATs, albeit
with slightly similar technology.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 13:54:05 -0400

> usage." 

only if the policy that the user wants is exactly what the NAPT
provides.  it's unrealistic to assume that most NAPT users do not want
to run any apps that accept externally-originated traffic, ever.  it's
also unrealistic to assume that most threats to the networks are from
outside the network, or that any kind of perimeter security will protect
a network of significant size from attack.

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 13:59:23 -0400

> working.

the market is dysfunctional.  it doesn't always fail to deliver what is
needed, but it often does. 

> Apparently not, or they wold switch.

they would switch if they had alternatives available.  but people like
you keep claiming that alternatives aren't needed because the market has
spoken.

> Huh? Are you claiming that people don't 

nope.  I'm claiming that your explanation of why they don't do something
else is unsupportable.

> those of people at large.

nor do I fool myself about such things.  but I'm capable of seeing how
much NAT impairs the ability of the Internet to support apps, and some
of those apps seem attractive enough that I believe people would eagerly
adopt them - if NATs weren't preventing them from achieving critical
mass.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 11:12:03 -0700

> needed, but it often does. 
That's your claim. I don't buy it.

> you keep claiming that alternatives aren't needed because the market has
Nonsense. I'd love to see an alternative. Obviously, NATS have costs
and a solution that reduced those costs would be better. What alternative,
exactly, are you offering?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 11:32:59 -0700

Keith Moore <[email-masked]> writes:

> > > they would switch if they had alternatives available.  but people
> > > like you keep claiming that alternatives aren't needed because the
> > > market has spoken.
> >
> > and a solution that reduced those costs would be better. What
> > alternative, exactly, are you offering?
> 
> 6to4 is one.  and before Christian wrote his shipworm/teredo proposal I
> had my own proposal to tunnel v6 over v4+NAT.   there's also my draft
> describing my best effort to produce a mechanism that would allow v4
> apps to tolerate NATs and still have general connectivity.  (I tried,
> but it turns out that it's far easier to support 6to4 and/or teredo)
> 
> so it's not like I haven't actually been working on solving the problem.
I didn't say you haven't been. So, my question at this point is:

(1) If these solutions aren't available, why not?
(2) If they are available and people don't want them, why not?

Rather than complaining about NAT, it seems like we would be better
served assuming that people have reasons for making the choices
they have and trying to accomodate those.

Anyway, I've said all I have to say about this topic. I'll
let other people on this thread have the last word if they 
like.

-Ekr

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 19 Jun 2003 13:29:23 -0500

> needed, but it often does. 

I wouldn't say that this market is dysfunctional, more that markets aren't
always self-deterministic (regulations and laws are another form of this),
and that the market is as functional as can be expected considering the
restrictions that folks usually work under. Folks can't always get a range
of addresses from their provider, or can't get a routable block of private
addresses, or don't want to depend on a single provider, or whatever. I
mean, I certainly wouldn't be using a NAT on my home network if I had kept
the multiple Class C blocks I used to have, so really the problem is that
the market isn't offering the full range of appropriate choices. People
have chosen something that mostly works (or have been lied to), rather
than chosing the best option (which is not available).

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 14:59:19 -0400

> Yes, I agree, that NAPTs have tons of side effects, and that's a bad 
> thing. But, for the average home user on DSL, they have purchased 
> millions upon millions of these things. It's a tiny little network and
> they have full control over all the hosts. So for them, the NAPT 
> firewalling function is very useful. 

the firewall without the NAT would be even more useful.

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 15:11:38 -0400

> (2) If they are available and people don't want them, why not?

it may be too early, and lots of people are still misinformed.

> they have and trying to accomodate those.

the two are not mutually exclusive.   and though I do assume that people
have reasons for making they choices they make, why should I assume
either that the people have much of a choice, or that the reasons that
the people give are valid, in the presence of ample evidence to the
contrary?

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 15:20:27 -0400

> more complicated? If so, what is it?

If you're multihomed and your route changes, your address
changes.  (Yes, this happens).

I am profoundly weirded out by reading an IAB member argue
that something that's got broad market acceptance is
tautologically okay.  I agree that there's a real problem
here that NAT is trying to solve, but I certainly wouldn't
treat it as a given that NAT is the best, or even a good,
solution.  

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 15:27:16 -0400

> usage." It's implementing a very simple policy, protect me from the 

NAT has problematically constrained policy capabilities.

Melinda

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 14:19:49 -0400

Yes, I agree, that NAPTs have tons of side effects, and that's a bad 
thing. But, for the average home user on DSL, they have purchased 
millions upon millions of these things. It's a tiny little network and 
they have full control over all the hosts. So for them, the NAPT 
firewalling function is very useful. (and the network vs. hosts 
distinction doesn't make sense, does it?)

simon

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 14:23:13 -0400

Keith

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 13:52:57 -0400

On Thursday, June 19, 2003, at 01:34  AM, [email-masked] wrote:

> http://www.research.att.com/~smb/papers/fnat.pdf

This paper has nothing to do with security. it's just counting hosts.

simon

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 13:35:08 -0700

I said I was done with this discussion, but I think Melinda
deserves a response here.

> changes.  (Yes, this happens).
Agreed.

> treat it as a given that NAT is the best, or even a good,
I can understand how this would bother you, and I think
part of the problem is that I haven't been writing as clearly
as I could have. A series of e-mail replies isn't a good
way to elucidate your position.

Here's what I mean to be arguing:

(1) There are some set of problems that users have or
    believe they have.

(2) NAT solves at least some of those problems, at some
    cost (say Cn), both financial and operational and
    that solution has benefit Bn.

(3) The fact that a large number of people have chosen
    to use NAT is a strong argument that B>C. (Here's
    where the invocation of revealed preference comes in).

(4) It may well be the case that some other solution S
    would have some other costs Cs and benefit Bs such
    that (Bs - Cs) > (Bn - Cn). It may be that S doesn't
    exist yet, in which case it would be good for us
    to design and build it.

(5) It's also possible that at some time in the future
    Cn will exceed Bn, in which case I would expect people
    to stop using NAT and (probably) demand something else.

(6) The argument that I thought I heard people (though not
    you) making is that Cn > Bn. I don't think that this
    is likely to be the case. In that sense, I think
    NAT is OK. I think that if we believe this, it will likely
    lead to us designing a long series of S'es that are
    inferior to NAT (in the sense that users do not
    prefer them because (Bs - Cs) < (Bn - Cn). That's a waste
    of time.

Does this seem like a weird position for an IAB member to take?
I don't think so. 

There certainly are cases where it's appropriate for the IETF to say
that something users want to do is not OK. Most of those cases are
ones where their behavior has negative external effects on everyone
else. I don't think a strong argument has been made that this is
such a case.

-Ekr

---

From: John Stracke <[email-masked]>
Date: Thu, 19 Jun 2003 16:51:39 -0400

>    to stop using NAT and (probably) demand something else.
I think this is the point of contention: Keith asserts that Cn exceeds 
Bn if you consider long-term costs; your invocation of revealed 
preferences is based on the market, which tends to be short-term.  Cn<Bn 
if all you run is client-server apps; but NAT locks you in to using just 
those apps, which means that Cn has a hidden component that isn't 
visible to most consumers.

-- 
/=============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centive.com                    |
|Centive           |My opinions are my own.                   |
|=============================================================|
|Beware of wizards, for you are crunchy and good with ketchup.|
\=============================================================/

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 17:00:56 -0400

>     where the invocation of revealed preference comes in).

There's ample evidence that many users aren't aware of the costs of
using NAT, or especially, weren't aware of those costs before they
started using NAT - so their choices were poorly informed.   So no, it's
not reasonable to conclude that decisions to use NATs are justified by
realistic cost-benefit estimations of doing so.

There's also ample evidence that many users are not free to make this
choice, or that the costs of not using NAT are artificially inflated.

Note also that cost optimization by individual users (even if
well-informed) does not necessarily produce a cost-optimized result for
the overall community.

>     you) making is that Cn > Bn. 

I think it would be more realistic to say that the cost of using NAT
for everything (that is, of not providing any e2e connectivity) is
greater than the benefit of using NAT for everything.  e.g. If you run a
home network, you can often configure your NAT to accept external
traffic on some ports and pass it to a single designated host.  (you
might argue that the fact that this option is popular indicates a
revealed preference among users to not NAT everything.)  But while this
works in corner cases,  it doesn't scale.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 17:12:19 -0400

> Does this seem like a weird position for an IAB member to take?

I think economics provides useful tools for talking about
and evaluating this stuff, too, but I think it's pretty
evident that you can optimize for anything you like and get
different results.  I question whether it's in this
organization's charter to privilege the individual user over
the good of the network.  If you choose to put yourself
behind a NAT that's possibly good for you (although I think
it's bad for you over the longer term) and always bad for
the people who want to reach you.

> else. I don't think a strong argument has been made that this is

That last sentence left me speechless, for which I suppose
some number of people are now in your debt.

Melinda

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 17:23:34 -0400

> NAT has problematically constrained policy capabilities.

Does that mean that a NAT is a workable firewall but introduces 
undesirable side effects? Is it (or could it be) possible to make an 
equally workable firewall, at a low price, that doesn't introduce to 
constrained policy capabilities?

simon

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Jun 2003 17:33:51 -0400

> undesirable side effects? 

No, it means that NAT is inherently incapable of
enforcing policy decisions at a granularity that's useful.

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 14:42:25 -0700

> the people who want to reach you.
Well, my view, as I think I expressed on P-S, is that the
"good of the network" is some function of the individual
goods of the people on it, so I don't think of these as two
separate things, really. Obviously, one could take a less
utilitarian view.

> some number of people are now in your debt.
Heh.

I think we're talking differently about externalities, which,
as you say, is always a problem with this sort of utility
analysis. Realistically, there are three kinds of utility
effects of someone choosing to install a NAT:

(1) The effect on them personally.
(2) The effect on other people who might potentially correspond
    with them (a rather small set).
(3) The effect on the network as a whole, or to speak more
    precisely, the effect on a large set of people who
    have no relationship with the individual in question.

When I said "no strong argument" I was thinking about class (3), not
class (2), which I agree there is a much stronger argument to be had
about. I don't know of a strong argument for (3).

It's pretty clear that we have a mandate to deal with effects of type
(3). So, for instance, we go to a lot of effort to block things like
congestion collapse and DoS amplification, which impinge on all sorts
of innocent people. On the other hand, we mostly keep our hands out of
type (1), though not entirely. If people want to use RTP to listen to
Britney Spears, it doesn't harm anyone but themselves and we don't
care about that at all. 

Class (2) is trickier to know what to do, since on the one hand we
wouldn't try to force people to avail themselves of new services. On
the other, to the extent to which NAT encourages people not to make
themselves available, that does decrease welfare. As you say, these
costs are difficult to account for, and I had forgotten to account
for them. 

Assuming for the moment that those costs exceed the benefits, then we
would be in quite a difficult situation, since we've just described a
classic market failure where negative externalities aren't built into
price. But the problem isn't that people are stupid but rather that
they're rational. Getting them to do the efficient thing in such
situations is generally not easy.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 14:45:39 -0700

> realistic cost-benefit estimations of doing so.
NATs have been around for quite a while. This might have been 
a convincing argument 5 years ago, but I don't find it very 
convincing now, particularly in view of the fact that some
people who clearly understand the cost/benefits choose to use them.

> well-informed) does not necessarily produce a cost-optimized result for
Of course. But then you have to describe the negative externality.
See my response to Melinda for more on this.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 17:55:06 -0400

> people who clearly understand the cost/benefits choose to use them.

NATs have been around for awhile but not everyone has been using them 
for 5 years.  Some of those who thought NATs were a good idea are now 
looking for alternatives.  For other people, NATs work just fine for 
their current needs, and this has never been disputed.

> Of course. But then you have to describe the negative externality.

plenty of examples have already been given.

Keith

---

From: James Seng <[email-masked]>
Date: Fri, 20 Jun 2003 09:23:35 +0800

The question: smart terminal or smart network?

I believe in smart terminal. Nothing there suggest you should not run 
your firewall or any other filtering software on your end-terminal.

End-machine are vulnerable? Then fixed the end-machine. It isnt rocket 
science.

-James Seng

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jun 2003 21:19:19 -0700 (PDT)

> Does this seem like a weird position for an IAB member to take?

The problem here is that your cost functions are
averages when what is far more interesting are the
trends. Voice is one trend and it pretty
fundamentally challenges one of the base
assumptions of NAT: private-client/public-server.
But instead of realizing that NAT is
architecturally incapable of dealing with private
servers and switching back to the model that does
accommodate that model fine, we're being driven as
a community to do both with the ensuing insanity
of two broken models being forced to cohabitate,
all the while neither meeting the actual
requirements.

So just saying that NAT is here get used to it is,
architecturally, not helpful. The split of effort
is to put it mildly a huge drain on engineering
talent, but more importantly the net is becoming
more and more incomprehensible because of it, both
intellectually as well as operationally. That
strikes me as a profound architectural issue, one
that should scare anybody who cares about the net.

So yes, to my mind saying "get used to it" is a
weird position because it discounts the problems
of the status quo and doesn't really express any
vision for what the architecture *ought* to be, or
drive us in a direction which will make that
determination possible. What NAT's are telling us
is that there are requirements that aren't being
met with the current Internet. But that's really
the only thing they should be telling us because
we already know that NAT's fail miserably on other
requirements.  We want an architecture that meets
all of the requirements, not a hodgepodge of half
solutions which fall over in the first stiff
breeze.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 19 Jun 2003 23:40:37 -0500

Thus spake "James Seng" <[email-masked]>
> End-machine are vulnerable? Then fixed the end-machine. It isnt rocket

Perhaps it _is_ rocket science, since I have yet to see an OS and suite of
applications which are capable of meeting modern productivity needs while
providing even rudimentary security.  Surely if it were simple, someone
would be selling it and get rich...

Humans are lazy and cheap.  It is significantly easier, not to mention more
effective, to manage a single firewall accessible by a handful of highly
trained security experts than it is to ensure the security of thousands,
possibly tens of thousands, of hosts that are managed by users who are
neither skilled at nor interested in evaluating and compensating for
application security flaws.

End to end is good, and dumb networks are good.  But at the edge (by that I
refer to all non-transit AS's) it's more cost effective to create a strong
perimeter and give up on anything inside that perimeter.  Perhaps it's not
the strongest solution in the end, but the people paying the bill rarely
care.

Of course, we all know the oft-quoted figure that 80% of electronic crime is
committed by insiders.  I'm pretty sure this is a direct effect of the above
trend, but corporate types seem to feel punishing insiders after the fact is
good enough, and prevention only applies to strangers.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jun 2003 21:51:35 -0700

> solutions which fall over in the first stiff
I can agree with most of this, but I don't think that it's
incompatible with "get used to it". Look at it this way: I'm used to
the fact that I'm bald, even though I don't like it. At some point
there may be something I can do about that and at that point I would
do it. In the meantime, I wear a hat.

-Ekr

---

From: "manojd" <[email-masked]>
Date: Fri, 20 Jun 2003 13:47:35 +0530

Since the issue is stable end-points, could something like this be a patch
for v4 NATs?

a) Applications running behind NAT are constrained to have only 8-bit
effective port numbers. Means no more than 256 ports.

b) If there are no more than 256 devices hiding behind NAT, NAT could
allocate a stable 8-bit per-device number for each device.

c) Externally visible port number used by an application on some device is
composed of its stable 8-bit number known to NAT, plus 8-bit port number it
locally allocates.

Device & app config is more complex. And the idea of "well known port
numbers" for certain protocols goes for a toss. But at least the apps work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Keith
Moore
Sent: Thursday, June 19, 2003 10:52 PM
To: EKR
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: myth of the great transition (was US Defense Department
forma lly adopts IPv6)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Jun 2003 08:08:30 -0400

> Since the issue is stable end-points, could something like this be a patch

since you have to change NATs, apps, and DNS to make this work, you might as
well just use IPv6 - and the changes for v6 are already in the pipeline.

---

From: [email-masked]
Date: Fri, 20 Jun 2003 10:33:41 -0400

> Since the issue is stable end-points, could something like this be a patch

No.

> composed of its stable 8-bit number known to NAT, plus 8-bit port number it

As you note below, this totally breaks the idea of "well known ports".

> numbers" for certain protocols goes for a toss. But at least the apps work.

Hmm... 21, 23, 25, 80, etc etc etc.  This is even worse than the usual
"you have to pick exactly one destination machine and hand-tunnel it to
the server" solution.

I suppose if you had absolutely NO intent to have inbound connections,
you could make it work.

---

From: [email-masked]
Date: Fri, 20 Jun 2003 15:24:03 -0400

On Thu, 19 Jun 2003 03:57:40 EDT, Daniel Senie <[email-masked]>  said:

> can determine how many ACTIVE hosts are talking to sites outside the NAPT box

*sigh*. OK. You're correct.  *BY ITSELF*, there's not much of an attack
vector here.  On the other hand, every hacker who has graduated from the
ranks of the ankle-biting script kiddies knows that target recon is something
that you want to do if feasible.

Information leakage makes it a lot easier....

Let's pretend you're a hacker.  You've found a box that you suspect is a NAT.
What's the FIRST thing you want to know? Yep - verify that it IS a NAT.  And lo
and behold, if you can enumerate more than one host behind it, it's probably a
NAT.

What's the second thing you probably want to know?  What techniques are likely
to work, of course.  And your choice of attack tools will quite likely be
swayed dramatically if you suspect there's only 3-4 boxes behind the NAT
because the NAT is a front end for a SOHO or similar, or if there's only 3-4
boxes because there's a DMZ behind it, or if you suspect there's hundreds back
there.

And all sorts of info leaks out in the oddest ways.  For instance, I save the
rfc822 headers from my mail.  So far in June, I've caught 38,836 Received:
lines from off-campus hosts, with 12,211 unique sources.  Of these, 2,597, from
409 different sources, contain an IP address literal from 1918 space.  Those
often give (a) a target IP inside the 1918 space and (b) the clue (dependent on
the MTA) that perhaps the site doesn't have care/clue enough to get PTR records
set up....

---

From: Dean Anderson <[email-masked]>
Date: Fri, 20 Jun 2003 19:44:47 -0400 (EDT)

Hackers first crack the exposed host. Then they see if it has multiple
interfaces. The local ARP cache will tell them the RFC1918 addresses if it
is a NAT.

The "NAT" just clusters several machines together in one machine.

Whether there are multiple machines behind a NAT is of little consequence.
Those machines that have exploitable ports available are still
exploitable. A good example is HTTP buffer overflows. A number of NATs
will happily forward the overflow attacks right through to the web server,
which is still exploited. SIP phones are similarly exploitable.

And how many NATs will forward external packets addressed to RFC1918 space
between both interfaces?  A lot used to. The limited access depended on
the assertion that RFC1918 packets couldn't be transmitted beyond the
external interface due to routing configuration. This assertion cannot be
guaranteed.  Change that routing, and there is frequently complete
transparancy.  But the fact that it doesn't usually work has caused many
people to make the false assumption that it can't ever work, and wrongly
conclude that NAT is an access control device when it isn't.

		--Dean

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Jun 2003 22:01:17 +0200

On donderdag, jun 19, 2003, at 23:42 Europe/Amsterdam, Eric Rescorla 
wrote:

> Realistically, there are three kinds of utility

> about. I don't know of a strong argument for (3).

Vendors are forced to expend considerable engineering effort to support 
NAT users. I think this qualifies as a class 3 effect.

It would be interesting to see how much of the IETF's resources are 
used up by NAT issues. It must be a significant amount if a simple 
announcement about the advancement of IPv6 deployment turns into a 
discussion about the exact level of NAT's evilness.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jun 2003 18:26:20 -0400

> used up by NAT issues. 

Probably not as much as needed, actually.  

Be that as it may, let's do some arithmetic: I would guess
that the really huge equipment vendors probably have about
50 FTEs each working on NAT workarounds (not NAT
implementation per se - just NAT workarounds).  Caveat: I
don't have any real numbers, this is just an estimate based
on what I've encountered in talking to people/companies
about NAT.  These workarounds include things like stateful
inspection/rewrite, relaying and encapsulation protocols,
etc., plus the associated coding, QA, standardization work,
and documentation, and includes everything from workarounds
for voice to workarounds for IPSec.  If you average about
$200,000 per employee per year (including salary, benefits,
office space, parking, telecom costs, etc.) that comes to
$10,000,000/year per really big company.  That sounds like a
lot of money to me.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Jun 2003 01:19:29 -0400

> Probably not as much as needed, actually.  

any amount is too much IMHO.