Subject: RE: NATs as firewalls

From: <[email-masked]>
Date: Mon, 5 Mar 2007 08:48:57 -0000

> > 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". 
> 
> Are you aware of RFC 4084 "Terminology for Describing 
> Internet Connectivity"?

I was not aware of it until now but I think that it targets a different
audience, namely ISPs who offer services and people who discuss ISP
services. I wonder how many ISPs are even aware of this RFC.

In any case, RFC 1009 is targetted at vendors and implementors of
gateways. I believe that we not only need to sort out the tangle of
terminology and concepts surrounding NAT, IPv4, firewalls, IPv6 and
security, but also provide some clear guidance to developers of gateway
hardware and software. The shift to IPv6 and winding down of IPv4
address allocations provides the opportunity to do this. As the news of
IPv4 wind-down spreads, people will be hungry for more information and
the story that IPv6 is better because it has more addresses just isn't
good enough.

IPv6 is also a technology refresh, i.e. it forces vendors to reimplement
their boxes. It forces people to buy new systems. If the only thing that
they get is a new protocol with wider addresses, then they will see this
as a generally negative experience and wonder why people with more money
couldn't just buy IPv4 addresses from those with less. Let them eat NAT!

But, if there are clear guidelines for IPv6 gateways that focus on
enabling functionality then people will see a value in upgrading. An
explicit firewall service is a value. No NAT thus enabling more
peer-to-peer applications is a value. There could be more to it as well.

For instance, if we accept the model that the majority of Internet hosts
will communicate with the core via stateful gateways, then there is the
possibility of a standard way for an application to communicate with its
local stateful gateway in order to change the state, rather than
implementing things like STUN (Simple Traversal of UDP through NAT).
That too, would be a value for the buyer of a standard Internet gateway.

--Michael Dillon

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 5 Mar 2007 09:15:47 -0800

> From: [email-masked] [mailto:[email-masked]] 

> IPv6 is also a technology refresh, i.e. it forces vendors to 
> reimplement their boxes. It forces people to buy new systems. 
> If the only thing that they get is a new protocol with wider 
> addresses, then they will see this as a generally negative 
> experience and wonder why people with more money couldn't 
> just buy IPv4 addresses from those with less. Let them eat NAT!

Quite, the bigger address space does not necessarily drive adoption in the way we would wish. PopulataXQg

--=======14860132=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======14860132=--

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 5 Mar 2007 09:15:47 -0800

> just buy IPv4 addresses from those with less. Let them eat NAT!

Quite, the bigger address space does not necessarily drive adoption in the way we would wish. Population pressure in Europe continued to bid up the value of land there even after the discovery of the New World. 

Even though there was no shortage of space in the New World (if you were prepared to push aside the indigenous population) it was three centuries before the infrastructure there made the land equally attractive.

> But, if there are clear guidelines for IPv6 gateways that 
> focus on enabling functionality then people will see a value 
> in upgrading. An explicit firewall service is a value. No NAT 
> thus enabling more peer-to-peer applications is a value. 
> There could be more to it as well.

You conflate an implementation with a requirement.

Enabling peer-to-peer applications, in particular video conferencing is the value. ANY means of enabling the benefit works.

The chief challenge however is how to open up the network to inbound TCP requests without creating a security melt-down. Eliminating NAT does not by itself eliminate the network issue. Once you start to look at ways of managing the network security issue the question of addresses becomes moot.

> For instance, if we accept the model that the majority of 
> Internet hosts will communicate with the core via stateful 
> gateways, then there is the possibility of a standard way for 
> an application to communicate with its local stateful gateway 
> in order to change the state, rather than implementing things 
> like STUN (Simple Traversal of UDP through NAT).

This is the model that I prefer. It allows me to meet a set of security objectives that is considerably more restrictive than anything on the market today yet also make use of video conferencing and other peer to peer configurations practical.

One of the keys here is to step back from administering hosts and instead look at ways to configure the network.

ion pressure in Europe continued to bid up the value of land there even after the discovery of the New World. 

Even though there was no shortage of space in the New World (if you were prepared to push aside the indigenous population) it was three centuries before the infrastructure there made the land equally attractive.

> But, if there are clear guidelines for IPv6 gateways that 
> focus on enabling functionality then people will see a value 
> in upgrading. An explicit firewall service is a value. No NAT 
> thus enabling more peer-to-peer applications is a value. 
> There could be more to it as well.

You conflate an implementation with a requirement.

Enabling peer-to-peer applications, in particular video conferencing is the value. ANY means of enabling the benefit works.

The chief challenge however is how to open up the network to inbound TCP requests without creating a security melt-down. Eliminating NAT does not by itself eliminate the network issue. Once you start to look at ways of managing the network security issue the question of addresses becomes moot.

> For instance, if we accept the model that the majority of 
> Internet hosts will communicate with the core via stateful 
> gateways, then there is the possibility of a standard way for 
> an application to communicate with its local stateful gateway 
> in order to change the state, rather than implementing things 
> like STUN (Simple Traversal of UDP through NAT).

This is the model that I prefer. It allows me to meet a set of security objectives that is considerably more restrictive than anything on the market today yet also make use of video conferencing and other peer to peer configurations practical.

One of the keys here is to step back from administering hosts and instead look at ways to configure the network.

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 11:05:08 -0000

> How do we establish the political coalition necessary to act? 

1. Form a political coalition.
2. Get an existing coalition such as MAAWG to take on the work.
3. Get the USISPA to take on the work http://www.usispa.org/
4. Get the USIIA to take on the work http://www.usiia.org/
5. Get the USISPA, USIIA and MAAWG to join forces and take on the work.

Choose one...

> There is clearly additional discussion necessary within the 
> IETF community to achieve a measure of consensus. I agree 
> that the IETF list is not the place for that.

Yep.

> We need more than just consensus in the IETF though. We need 
> to convince the ISPs to act who in turn must persuade the 
> vendors of SOHO routers. 

Writing the spec of a SOHO gateway could be done in the IETF because it
is primarily a technical document. It is analogous to work the IETF has
done before.

--Michael Dillon

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 17:18:27 -0000

> 	(i) there is every reason to expect a run on remaining
> 	addresses at some point, whether induced by "public
> 	coverage", "larcenous providers", ISP or RIR anxieties,
> 	or something else. 

In other words HIGH PUBLIC PROFILE. Interestingly, this roughly
coincides with increased public concern over network abuse, reevaluation
of homeland security activities, and the timeframe in which IPv6
services could reasonably be introduced. The time is ripe for the work,
even if it does ultimately fail as some suggest. Nevertheless, an IETF
WG discussion of what should be in the SOHO gateway is likely to lead to
products on the market.

> 	(ii) it is reasonable to expect that by the time such a
> 	stampede gets serious (or somewhat before that), the
> 	RIRs and possibly ICANN will try to change policies to
> 	damp it.  

This has just begun with someone making a proposal in APNIC
http://www.apnic.net/docs/policy/discussions/prop-046-v001.txt

> As I have also suggested earlier, a different way of figuring
> out when we have run out of IPv4 space is not to look at when
> the last address block is allocated but at when the perception
> or claim of scarcity begins to justify bad behavior (in pricing,
> protocol design, etc.).  By that criterion, we ran out several
> years ago and can stop having that particular part of the
> discussion.

I am of the opinion that there will be no hysteria, no market pricing,
just a move towards IPv6 because over the past few years, all Service
Providers have been upgrading to v6 capable devices, and enterprises
have also, at a somewhat slower pace, been shifting towards v6 capable
OSes. They haven't been USING IPv6, but a lot of the capital costs
necessary have already been invested.

> When it does come -- when a lot of
> people reach that conclusion -- it is reasonable to predict a
> catastrophic change in allocation requests and presumably in
> allocations.  Once that occurs, the projections based on models
> of past behavior are trash and IPv4 space will be in very bad
> trouble... probably in a matter of months and not years.

That day will never come because IPv4 addresses can never be in such
short supply. There is fat in the system, outside the RIRs' view and
control. The hoarding behavior happened years ago, before the telecom
collapse. One can always use NAT tricks (double NAT) in some areas,
"borrow" DOD and other address space such as a nice /8 that was recently
allocated exclusively for use in a Japanese cable network. The net is
diverse enough that many people won't care if DoD machines or Japanese
consumers can't reach them. This is an unmeasured and unstudied area.

I still believe that the time is right for an IETF WG to define SOHO
gateway requirements for IPv6 networks because IPv4 wind-down will cause
more people to take a serious look at how and why to deploy IPv6. One
single good idea in a SOHO gateway document could be enough to tip the
scales and make a business case for IPv6 services.

--Michael Dillon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 10:26:50 -0800

The idea that the US is not affected by IPv4 address space exhaustion is a canard. The US runs out of addresses the same day as everywhere else.

US organizations are certainly over-represented in the list of organizations holding underutilized IPv4 address blocks. But the fact that MIT has net 18/8 has no effect on Comcast. If MIT did decide to renumber its nets and then sell of some or all of its excess allocation it would presumably either return the excess allocation to IANA or auction it off on EBay. Either way it is hard to see how this would give a US company any advantage over non-US companies.

> -----Original Message-----
> From: JFC Morfin [mailto:[email-masked]] 

[Comments from banned poster deleted]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 17:07:16 -0800

Wildcards are not permitted in the new Extended Validation certificates. 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 7:59 PM
> To: Hallam-Baker, Phillip; [email-masked]
> Cc: Jeffrey Hutzelman
> Subject: RE: NATs as firewalls
> 
> 
> 
> On Wednesday, March 07, 2007 04:23:20 PM -0800 "Hallam-Baker, 
> Phillip" 
> <[email-masked]> wrote:
> 
> > We do need to revise the architecture description. Using IP 
> addresses 
> > as implicit signalling
> 
> You keep using that word.  I do not think it means what you 
> think it means.
> 
> 
> > Another instance that hit me today is the fact that existing SSL 
> > implementations use the server IPv4 address to select which server 
> > certificate to present to a client.
> 
> No; existing SSL server implementations assume that only one 
> certificate is relevant for any given transport endpoint.  
> Which, for the vast majority of uses, would not be that big a 
> deal except that a certain vendor which dominates the 
> well-known-CA market(*) sees a revenue opportunity in 
> wildcard certificates, much as ISP's see a revenue 
> opportunity in residential customers who need multiple 
> non-NAT'd addresses.
> 
> (*) To be fair, pretty much _every_ vendor does this.
> 
> -- Jeff
>

---

From: <[email-masked]>
Date: Thu, 8 Mar 2007 10:58:44 -0000

> IPv6 is not inevitable, the issue is how to make it so. 

Yes, and I believe that the way to make it so is to define the standard
for connecting to the IPv6 Internet. That standard should NOT be to
connect a computer via dialup modem or to connect a computer via its USB
port. Instead, it should be to install an IPv6 Internet gateway with a
standard set of gateway functions, and then connect the computer to
that. Some gateways may indeed use dialup to get to the Internet. Some
gateways may indeed allow computers to attach via USB. But the gateway
is an essential intermediary.

I'm not concerned with technical experts who know how to install and
IPv6 stack on their Windows NT laptop with built-in modem and dial
directly to the IPv6 Internet. Those people are small in number and
likely to be able to deal with the technical issues.

This SOHO gateway standard is aimed at making it easy for non-technical
consumers to connect to the IPv6 Internet without understanding how it
all works. A gateway must provide a smorgasbord of features for managing
the connection such as an in-out firewall. It must be manageable in a
secure way by the ISP providing IPv6 connectivity so that people with
technical knowledge can keep it running in good order without requiring
the consumer to unplug it and take it in for service. The overall goal
is to specify a smorgasbord of features that can be used to defend
against and mitigate most of the effect of known Internet abuse vectors.
This may end up being nothin more than a list of existing firewall
features, but in the process of discussion, there is the possibility of
coming up with something better.

--Michael Dillon

---

From: <[email-masked]>
Date: Thu, 8 Mar 2007 11:32:20 -0000

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

I also have a DSL router/switch which I bought and manage myself and I
would still like to be able to do this in future with IPv6. Either by
buying a non-SOHO gateway or by reflashing a SOHO gateway so that I can
manage it myself.

The idea of an IETF standard for the capabilities of a SOHO IPv6 gateway
does not imply any business model. In fact, it makes it easier to buy
your own box when they all comply to the standard. You can still use the
ISP's management services if there is a standard which defines what they
are and how they function. As for managed versus unmanaged access
connections, that is a bit of a red herring. Today you think that you
have an unmanaged DSL connection but in reality, the ISP has an abuse
desk and internal systems which are necessary to manage network abuse
issues. You are paying for that. If the ISP could automate that work by
having an automated system directly manage your Internet gateway device,
then your service would probably be cheaper.

>  I believe it would contravene the regulatory 
> rules if you 
> forced to buy the ISP's box.

As it should. An IETF standard will remove a barrier to buying your own
gateway device because they will all be compatible.

--Michael Dillon