In message <a123a5d60911080822g3797e480h4bd9b01d8f3f2266@xxxxxxxxxxxxxx>, 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@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf