Re: NAT Not Needed To Make Renumbering Easy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.


On Sat, Nov 7, 2009 at 9:30 PM, Christian Vogt
<christian.vogt@xxxxxxxxxxxx> wrote:
>
> On Nov 7, 2009, Masataka Ohta wrote:
>
>> I'm not talking about the amount of value to be offset but the
>> location of transport checksum.
>>
>> The location of transport checksum can be known only by traversing
>> all the extension headers from the beginning of a (unfragmented)
>> packet.
>>
>> So, the second and latter fragments of the packet may or may not
>> contain transport checksum to be offset, which means IPv6 NAT must
>> first reassemble fragmentation.
>
> Why would an IPv6 NAT need to find the checksum if the checksum does
> not need to be changed anyway?
>
>> IPv6 specification requires IPSEC, which means outer most IPv6 must
>> also support IPSEC.
>
> Sure, no one is arguing with this.  My point was that, while IPv6 NAT
> does interfere with some modes of IPsec, there are other IPsec modes
> that are not affected by IPv6 NAT.  Makes sense?
>
> - Christian
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]