Subject: RE: NATs as firewalls

From: <[email-masked]>
Date: Fri, 2 Mar 2007 15:19:35 -0000

> (2) NATs provide a huge advantage for customer support
> organizations of ISPs supporting such lower-end (in terms of
> financial returns, at least) connections.  With a standardized
> NAT setup, the setups of all of their customers are pretty much
> the same, including the address ranges used by default.  This
> permits much easier (and cheaper) user support than trying to
> debug LAN-specific routing tables, arrangements to support both
> a LAN and the router providing the the interface between that
> LAN and the WAN in a very small address range, and so on.

In this discussion, the term "NAT" is being used as a catchall for
various different things, even if we ignore the discussion about NAT-PT
for v4-v6 interworking. The customer support advantage comes not from
the network address translation on the box, but from the firewall
side-effects of port address translation (PAT). Until we separate these
three things in our speech, how can we ask anyone to implement an IPv6
firewall that does not do either address translation or address/port
translation unless specifically configured?

Also, I don't believe that the identical address range is that
important, especially not in comparison to an IPv6 world in which every
subscriber will have an identical prefix length (/48) in their Internet
gateway.

> I continue to believe that, until and unless we come up with
> models that can satisfy the underlying problems that NATs
> address in the above two cases and implementations of those
> models in mass-market hardware, NATs are here to stay, even if
> we manage to move to IPv6 for other reasons.  And, conversely,
> the perceived difficulties with NATs will be sufficiently
> overcome by the above issues to prevent those difficulties from
> being a major motivator for IPv6, at least for most of the
> fraction of the ISP customer base who cannot qualify for PI
> space.

No real disagreement here but I do see a way forward. First, clarify the
terminology. Second publish a pair of RFCs rather like 1009 entitled
"Requirements for Consumer Internet Gateways" and "Requirements for
Enterprise Internet Gateways". These documents would describe how an
Internet gateway should function in its default configuration so as not
to interfere with IPv6 applications but still maintain a certain level
of security. It would also describe how the configuration will be
changed and introduce clear terminology to describe differing levels of
security (firewall-type intervention in the free flow of traffic). The
goal of this section is to structure the management interface in such a
way that non-technical consumers can understand what they are doing, why
to change the settings and how to change the settings. The RFCs should
specify the specifics of the user-interface paraphernalia. It might be
implemented with buttons on the box, a GUI on an LCD on the box, a GUI
app on a PC, a telnettable CLI, a webserver on the box, or an XML
interface that can be controlled by an ISP service management system.
The primary differences between the Consumer and Enterprise requirements
will be that Consumer gateways are expected to be managed from the ISP
side whereas Enterprise gateways are only managed from the customer
side. Because of this, a consumer gateway will have additional features
geared towards the needs of an ISP who must manage hundreds of thousands
of such devices. 

What do the O&M area directors think of a working group with this goal?

--Michael Dillon

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Mar 2007 20:05:38 +0100

Michael,

On 2007-03-02 16:19, [email-masked] wrote:
...
> Enterprise Internet Gateways". 

Are you aware of RFC 4084 "Terminology for Describing Internet Connectivity"?

It is a rather different take on the same problem.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Mar 2007 16:39:50 -0500

--On Sunday, 04 March, 2007 20:05 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> No real disagreement here but I do see a way forward. First,
>> clarify the terminology. Second publish a pair of RFCs rather
>> like 1009 entitled "Requirements for Consumer Internet
>> Gateways" and "Requirements for Enterprise Internet
>> Gateways". 
> 

But it really doesn't address the gateway hardware and software
itself, but only what is provided to the customer boundary.  If
an IT/ networking person for a moderately small network can't
walk into the local computer vendor and buy a boundary router
and/or firewall that will support IPv4 and IPv6 without NATs or
similarly-hostile addressing tricks or transformations, then
nothing we do helps very much.  And, having just taken another
look at draft-ietf-v6ops-nap-06.txt, while it is clearly a step
(or several) in the right direction, I don't see it moving me
much closer to that walk into the local computer store, much
less the ability to take it with the circa USD 50 - USD 100 in
my hands that will buy a competent IPv4 Router-NAT-Firewall
today.

It also ignores one issue that 4084 does address: many of the
ISPs supplying services who serve what you describe as the
"small private network" market have discovered a significant
revenue opportunity in restricting most customers to two or
fewer public   addresses.  Simply crossing that threshold into
availability of even a small number of relatively stable public
addresses is often the excuse for pricing differences that may
approach an order of magnitude.  Sometimes that difference is
justified by claims about service quality that the customer
cannot measure or unbundle, sometimes by lifting of
prohibitions, and sometimes by address scarcity but the reality
is that, having discovered this revenue opportunity, there is
reason to believe that ISPs would be unlikely to let go of it
even if there were no scarcity argument available.

Incidentally, in my experience, those "small private" networks
somewhat more than ten hosts if the real entry threshold for the
"medium/large" ones is "sufficient resources to acquire
addressing independence" (section 5.1 of v6ops-nap-06).  If that
is really the criterion, and "addressing independence" implies
PI address space, the number of networks in the range between
what is usually thought of as the "residential" or "SOHO"
category and the PI threshold is 
quite large, growing, and includes many medium-sized enterprises
and networks.

Please remember that, unlike some of the other contributors to
this set of threads, I strongly dislike NATs, believe we should
be migrating to IPv6 much more quickly than we have been, and
that continued fussing by the IETF about IPv6 details and
options has become part of the deployment problem.  But I also
think that we are most likely to make progress on these problems
by being as clear-headed and objective about them as possible.
That includes understanding that having the IPv4 network
environment persist into this century --no matter how horrible
the kludges are that are required to support it-- is building it
own inertia against wide or rapid IPv6 deployment as people
discover economic advantages and build operational practices
around those kludges.  Those advantages and practices may be
harder to overcome than the technology barriers (real or
imagined) themselves.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Mar 2007 11:44:06 +0100

John,

(after also reading Michael's response)

I don't disagree. I think there is scope for writing a list of
desirable properties for SOHO routers in the light of these
various inputs. I'm less certain it can be done for enterprise
boundary routers. But it would be a tricky and contentious job
in both cases. Even draft-ietf-v6ops-nap took many moons
and several major editing passes, and it only starts the work.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Mar 2007 07:36:22 -0500

> and several major editing passes, and it only starts the work.

Agreed.  And I don't think I'm going to volunteer this month.

    john

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 6 Mar 2007 15:46:50 -0800

While I agree with Brian that the enterprise draft will be difficult, I also believe the SOHO one will be virtually impossible to get agreement over. The issue is that most ISP's don't yet get the point that the device needs to be dual managed, because they are still in the mindset that there are just a couple of devices behind each customer nat at most and very little change to the configuration over time. 

FWIW: nat has not slowed the consumption of IPv4 addresses enough to be the panacea people keep hoping for. It is clear that most network managers are going to do squat until there is a crisis to force action. That will occur sometime after 2010 when they need more than they already have and find that the lease price per IPv4 address per day has been moving up from its current averages of $1/day or $5/day depending on contract length (a price service providers seem to have no trouble collecting while the addresses are still Free from IANA). For those who wonder about the date see: tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf

Tony

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 2:44 AM
> To: John C Klensin
> Cc: [email-masked]
> Subject: Re: NATs as firewalls
> 
> John,
>

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 6 Mar 2007 15:46:50 -0800

Tony

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Mar 2007 09:09:06 -0500

(off list)

--On Tuesday, 06 March, 2007 15:46 -0800 Tony Hain
<[email-masked]> wrote:

> While I agree with Brian that the enterprise draft will be
> difficult, I also believe the SOHO one will be virtually
> impossible to get agreement over.

I agree, although I think we might disagree a bit about the
reasons.  On the other hand, I also think that a serious IETF
(or other) effort to try to define such a thing would have
value, even if it only produced an info document about why the
problem is hard and what the issues are before failing and
collapsing.

> The issue is that most ISP's
> don't yet get the point that the device needs to be dual
> managed, because they are still in the mindset that there are
> just a couple of devices behind each customer nat at most and
> very little change to the configuration over time. 

Hmm.  Unless the economics of ISPs who deliver services to
residences and SOHO setups have changed _very_ significantly
since I was last deeply immersed in those very confidential
numbers, no one is doing any real remote management regardless
of what Phillip considers appropriate or necessary.   One could
imagine ISPs able to download new images that were the same for
everyone, but the margins just aren't there for anything other
than the "everyone gets the same boundary config and you can put
whatever you like behind it" or "if you fuss with this, it is
your problem" arrangements that are prevalent today.

My guess is that the economics would support a device that
combined a cable modem or DSL box with some significant inbound
and outbound firewall capabilities, including the ability to do
some rate-limiting, reasonable control over ICMP as well as TCP
and UDP and probably some real-time protocol.  I'd expect that
box to be delivered to the customer either fully locked up or
configured at setup time with any new configuration requiring
payment of a separate fee.    If I were designing one of these,
I think I'd put a couple of flash memory slots in it (SD or
whatever one prefers) that could be used to reimage or reprogram
the box or give the customer more control.   They wouldn't do
anything that could not, in principle, be done over the net but
the idea of sending the customer off to _pay_ for an unlocking
function or some other set of functions and then receiving a key
would, I think, be a lot more plausibly marketable than paying
for something that appears to be less tangible.

And that is the answer to Phillip's concern about what to do
about old hardware too.  Just as Verizon sent me a letter last
week that said that I'd better have a plan about getting rid of
any analog-capable mobile phones I might still have, the ISPs,
if backed by either judicial or government pressures (which I
believe to be necessary to accomplish anything) could easily put
out a note that says "a reasonable level of protection for the
network from you is now necessary.  That can be done in two
ways.  One is to upgrade your box, which will also give you the
capability of obtaining fewer restrictions.  The other is that
we do it centrally, which will give you a very restricted
environment (but not so restricted as to have impact on the
typical residential user), and we will charge you a fee for it."

> FWIW: nat has not slowed the consumption of IPv4 addresses
> enough to be the panacea people keep hoping for. It is clear
> that most network managers are going to do squat until there
> is a crisis to force action. That will occur sometime after
> 2010 when they need more than they already have and find that
> the lease price per IPv4 address per day has been moving up
> from its current averages of $1/day or $5/day depending on
> contract length (a price service providers seem to have no
> trouble collecting while the addresses are still Free from
> IANA). For those who wonder about the date see:
> tndh.net/~tony/ietf/IPV4-pool-combined-view.pdf

Agreed, but we have had this discussion before.  And I am in
strong agreement that the perception of crisis --either of the
type you identify here or of a serious threat of regulation or
litigation as above-- is the only thing that is likely to create
actual motion.  If nothing else, the margins are just too small
to do anything "because it is good" if it drives up costs even
to the extent of a few training courses for support staff.
There will need to be something, almost certainly external, that
can be blamed as a reason for introducing disruption, forcing
new hardware, or increasing costs (probably all three in
practice).  But, if we can predict something happening, under
any scenario about cause, the time for the IETF to get started
on its part of the job is "soon" or even "now", not after the
crisis occurs and everyone starts running off in their own
directions because no one has pointed the way.

      john

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 07 Mar 2007 19:38:12 +0000

> for something that appears to be less tangible.
Also this appears to be tied to the US business model where the ISP 
supplies you with the box and you don't get to change it (or even own it).
For example in the UK we are already down the path of selling such a DSL 
+ NAT/fireewall + router box (I have one here) but the ISP just sells me 
the DSL connection.  Depending on which ISP I choose they may sell or 
rent me a specialized box (e.g. BT which has estra telephone 
capabilities) or just sell/rent me a standard off the shelf 
modem/router.  The ISP managing the box would be a non-starter in most 
cases here.  I believe it would contravene the regulatory rules if you 
forced to buy the ISP's box.

/Elwyn

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Mar 2007 11:55:40 -0800

> supplies you with the box and you don't get to change it (or even  

Do they do that in the US? I'm not aware of it...

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 07 Mar 2007 20:14:15 +0000

> Do they do that in the US? I'm not aware of it...
Maybe I am just thinking of the modem.

/Elwyn