ietf
[Top] [All Lists]

Re: NAT Not Needed To Make Renumbering Easy

2009-11-09 17:42:23

In message 
<a123a5d60911080822g3797e480h4bd9b01d8f3f2266(_at_)mail(_dot_)gmail(_dot_)com>, 
Phill
ip Hallam-Baker writes:
We are so not in charge.

Support for IPSEC is a requirement to describe an implementation as
IPv6. That is all, it does not mean anyone has to use it, or that they
will use it.


There are two typical modes of deployment for IPSEC, the first is as a
lousy remote access protocol where the lack of NAT support makes it
far more effort than other solutions. SSL and SSH remote access just
works, IPSEC VPN may or may not work depending on the phase of the
moon. The third party clients are terrible, the built in support in
the O/S is unusable because it does not have the tweaks necessary to
get through the firewall. So we do not really have a standard for
IPSEC remote access.

The other mode for IPSEC is not really an Internet application, it is
creating a virtual network by joining together a bunch of routers at
local sites. Here the NAT issue is moot because the objective is to
create a single network with a consistent IP address space. The fact
that this is usually NAT space is not really relevant unless you are
attempting to create an industry wide network. Have fun with that.

What IPSEC has never got close to achieving is providing an Internet
security solution in which packets are secure at the transport layer
by default. The obvious reason for this is that IPSEC is not connected
to a pervasively deployed PKI for authenticating the end points. There
is no commercial infrastructure to support this today, and I doubt
that there will be one for some time. NAT is relevant to this scenario
only insofar as it will be aa fait acompli long before any PKI is
established that might support pervasive IPSEC.

And lest folk think I am picking on them here, the reason I raise
problems is because I want to see them fixed, not just to carp. I want
to deploy DNSSEC because I think that it is the most appropriate PKI
to support packet level security.


I use NAT for a very simple reason: I do not want my machines to be on
the Internet by default. I only want my printers to be accessed by
machines in my network. I only want the security system, the home
automation system, the daleks, the lab, the coffee maker to be
accessible from the network. I do not want Mr Coffee talking to
strange computers, he has little common sense.

Well give your printers a ULA addressand don't advertise the prefix.
You don't need NAT to provide this seperation.
 
Now I would like my network to have a greater geographic extent than
just my house. But there is still a very clear distinction between
machines that I own, that I am responsible for, that I want to connect
to my network core and all the rest of the stuff on the Internet.

Some computers, the desktops and laptops, I do want to have greater
access, but there are only eight of them in total, that is a small
fraction of my network.

The ability to give these devices and IP address THAT WILL NOT ROUTE
is very valuable to me as a security control. It is not a perfect
control, but I have many, many layers to my defense in depth and I
want all of them.

We are not in charge of the Internet, but I am in charge of my
network, and my policy is to use NAT.

In a commercial environment, policy is everything. You do not get
security from security technology, you get it from the security
practices that the technology supports.

Changing a security policy in a commercial environment is a very
expensive affair. People are going to demand NAT66 (and cisco is going
to support it) because it is cheaper to deploy NAT66 than change the
policy.

But even then, we are getting way ahead of ourselves. In the real
world every network is going to have IPv4 devices on it for decades. I
have a 36" plotter upstairs that is ten years old. I am not paying $3K
to upgrade it just for the sake of IPv6.

And your boxes will talk to it over IPv4  even if you don't have a
external IPv4 connection.
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf