Kundra IPv6 Memo
I've written a few posts on IPv6 here. I read the short Transition to IPv6 Memo (.pdf) written by Federal CTO Vivek Kundra. I'd like to comment on two of the assumptions he makes in that memo:
The Federal government must transition to IPv6 in order to...
1. Reduce complexity and increase transparency of Internet services by eliminating the architectural need to rely on Network Address Translation (NAT) technologies;
2. Enable ubiquitous security services for end-to-end network communications that will serve as the foundation for securing future Federal IT systems;
I find the first point laughable. Anyone who has even obliquely worked with IPv6 knows that adopting the protocol will massively increase complexity, whether IPv6 is used natively or especially if it's used in a conjunction with IPv4. Take a few minutes to look at all the extra addresses an IPv6-enabled system provides to see what I mean. Complexity and unfamiliarity with configuring IPv6 will introduce exposures that intruders will exploit. IPv6 stacks are likely to possess vulnerabilities that intruders will also attack. Finally, did you know that many networks will keep NAT even with IPv6? The "abolish NAT" argument is just false.
The second point represents what I think is a a fundamental misunderstanding concerning IPv6. I've written about this before too, but the point is simple: IPv6 is not inherently more secure than IPv4. You can introduce the same level of "security" in IPv4 as you can with IPv6. In fact, IPv6 is in many ways less secure than IPv4; check out all the auto-configuration protocols included with IPv6. Anyone who thinks making "IPSec mandatory in IPv6" means IPSec must be enabled isn't paying attention. "IPSec mandatory in IPv6" means IPv6 must offer IPSec, not that it be enabled [RMB: fixed error, thank you!]. Since you can run IPv4 with IPSec now, there's no advantage to IPv6 in this regard.
I'd also like to comment on the two major directives in the memo:
In order to facilitate timely and effective IPv6 adoption, agencies shall:
1. Upgrade public/external facing servers and services (e.g. web, email, DNS, ISP services, etc) to operationally use native IPv6 by the end of FY 2012;
2. Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014;
There's also a footnote for the first point:
To ensure interoperability, it is expected that agencies will also continue running IPv4 into the foreseeable future.
I think the first point means Federal servers will offer IPv4 and IPv6 services. I think they mean dual-stack will be allowed. I think the "native" comment means that Federal servers are not allowed to run only IPv4 but be accessible via an IPv6 gateway.
The second point is probably similar, meaning clients will have IPv6 addresses and speak directly to other IPv6 hosts without requiring gateways. That is going to be a security nightmare since the goal of IPv6 is to restore "end to end connectivity," which is inherently at odds with security.
What's your take on this IPv6 issue?
Tweet
The Federal government must transition to IPv6 in order to...
1. Reduce complexity and increase transparency of Internet services by eliminating the architectural need to rely on Network Address Translation (NAT) technologies;
2. Enable ubiquitous security services for end-to-end network communications that will serve as the foundation for securing future Federal IT systems;
I find the first point laughable. Anyone who has even obliquely worked with IPv6 knows that adopting the protocol will massively increase complexity, whether IPv6 is used natively or especially if it's used in a conjunction with IPv4. Take a few minutes to look at all the extra addresses an IPv6-enabled system provides to see what I mean. Complexity and unfamiliarity with configuring IPv6 will introduce exposures that intruders will exploit. IPv6 stacks are likely to possess vulnerabilities that intruders will also attack. Finally, did you know that many networks will keep NAT even with IPv6? The "abolish NAT" argument is just false.
The second point represents what I think is a a fundamental misunderstanding concerning IPv6. I've written about this before too, but the point is simple: IPv6 is not inherently more secure than IPv4. You can introduce the same level of "security" in IPv4 as you can with IPv6. In fact, IPv6 is in many ways less secure than IPv4; check out all the auto-configuration protocols included with IPv6. Anyone who thinks making "IPSec mandatory in IPv6" means IPSec must be enabled isn't paying attention. "IPSec mandatory in IPv6" means IPv6 must offer IPSec, not that it be enabled [RMB: fixed error, thank you!]. Since you can run IPv4 with IPSec now, there's no advantage to IPv6 in this regard.
I'd also like to comment on the two major directives in the memo:
In order to facilitate timely and effective IPv6 adoption, agencies shall:
1. Upgrade public/external facing servers and services (e.g. web, email, DNS, ISP services, etc) to operationally use native IPv6 by the end of FY 2012;
2. Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014;
There's also a footnote for the first point:
To ensure interoperability, it is expected that agencies will also continue running IPv4 into the foreseeable future.
I think the first point means Federal servers will offer IPv4 and IPv6 services. I think they mean dual-stack will be allowed. I think the "native" comment means that Federal servers are not allowed to run only IPv4 but be accessible via an IPv6 gateway.
The second point is probably similar, meaning clients will have IPv6 addresses and speak directly to other IPv6 hosts without requiring gateways. That is going to be a security nightmare since the goal of IPv6 is to restore "end to end connectivity," which is inherently at odds with security.
What's your take on this IPv6 issue?
Tweet
Comments
Good points that I didn't know though. I obviously have a lot to learn with IPv6!
"did you know that many networks will keep NAT even with IPv6?"
I don't think IETF is even close to a NAT 6to6 standard--are there any router vendors even supporting this feature today?
I think you mean:
"IPSec mandatory in IPv6" means *IPv6* must offer IPSec, not that it be enabled.
One interesting issue is DOS amplification potential on P2P links. This is a byproduct of the large address space and IPv6s addressing scheme. The unique traffic forwarding rules for point-to-point (p2p) links open the door to a special case of DOS attacks.On a p2p interface routers do not perform layer 2 address resolution, a process which would enable them to determine if an IP address within the subnet of that p2p link is active. Routers operate under the assumption that there is only one physical host that can be reached out of a p2p interface even if the IP subnet configured for that link supports more than two (one for each end of the link) IP host addresses. A packet sent by mistake, or maliciously, to an IP address that belongs to the subnet of a p2p link - an address that is however not assigned to the two ends of the link - will bounce between the two routers until its TTL expires, opening the door for an amplification mechanism which can be used to attack the routers. Upon receiving the packet, neither router checks whether the destinations really exists on the link. Both routers will simply put the packet back on the link with a decreased TTL.
Then there is the auto-configuration aspects and nastiness. I find IPv6 to operate much like IPX is this manner. I am sure the IPv6 purists will cry heresy with that statement. :-)
Just some additional food for thought. Good post and thanks for bring this memo to our attention.
Regards,
Brian
Richard,
I don't think IPv6's stateless autoconfiguration features necessarily increase the attack surfaces of my LANs. In my view they reduce my attack surface because I don't need DHCP servers or relays. (I'm already running IGPs, so I don't consider IPv6 router advertisements to be any more of an exposure than the existing OSPF/RIP broadcasts in my networks.) If I'm worried about bad guys plugging into my network, then I should deploy some kind of port- or network-level access control, whether that's something simple like MAC-based authorizations or complicated like 802.1X or IPSEC.
Regarding NAT, too many infosec people view NAT as a security tool instead of the horrible, horrible hack that it actually is. I remain unconvinced that the administrative overhead associated with maintaining public/private network numbering schemes, split DNS, etc. contributes to ones safety online, if only on the principle of complexity being the enemy of stability and security.
That said, you make a very good point about IPv6 stacks not being mature. All the tunneling protocols being automatically configured on my Windows boxes make me nervous, too. Unfortunately, until there's a financial incentive for bad guys to mount attacks over the IPv6 Internet, I don't think we'll find any significant vulnerabilities in IPv6 as a protocol or in its various implementations.
Another thing a lot of people seem to ignore about IPv6 is its spectral efficiency. If you just consider the header length differences, IPv4 can carry more data per MTU than IPv6, which becomes significant over high-cost/low-bandwidth links such as satellite. I'd like nothing more than to switch to IPv6, but when I look at how much I pay a month for connectivity and compare that with the actual data rates after the physical, network, transport, and session layers have taken their cut of the bandwidth, I just can't justify operating IPv6 - tt's too wasteful. If I was running GigE everywhere and could do 9000-byte frames and have RTTs well under 1000 ms, then yeah, IPv6 is great, but in the networks that I support, I have to use every single bps I can wring out of my existing link budgets.
Best wishes,
Matthew
'The second point is probably similar, meaning clients will have IPv6 addresses and speak directly to other IPv6 hosts without requiring gateways.'
There's some confusion here about what end-to-end really means. Ultimately, it's the same concept in IPv4; one host directly communicating within the same layer with another. Routers can and do exist between the two. You still have direct communications if two hosts are within the same subnet, as in v4.
There seems to be this common misconception I hear over and over in the IT realm. NATs and firewalls are very different beasts with very different purposes.
Those who pushing ipv6s implementation always take up the following points:
-no need for complex NAT
-address pool is so huge portscanning won't be a problem
There will be NAT with ipv6 too. NAT protects against a lot of attacks even tho people keep saying that what a hack it is. Every joe user who have no understanding of what ip address is but his laptop is on a natted network at work or at home enjoys more protection against scanning, auto exploitation etc even tho most of the threats coming from reverse connector tools. It just works tm.
And about the address tool is too big to scan, then you just enum the ips by dns or scan small ranges from 1 ip you know.
But all is besides the point because ipv6 still an experimental thing what no1 really needs yet.
I have many dual stack bsd servers with websites and I hardly get any visitors from v6. Only a couple of them per year who either want to test his ipv6 tunnel or it's just some scanner or crawler.
"did you know that many networks will keep NAT even with IPv6?"
I don't think IETF is even close to a NAT 6to6 standard--are there any router vendors even supporting this feature today?"
There is no NAT standard for IPv6, it has been rescinded, to my knowledge, by the IETF
I agree with your position on the reduction of complexity (or lack there of). IPv6 will have to co-exist in most networks (larger networks) for quite sometime.
I also agree that IPSec in v6 is really no different than that in v4, with the exception that it was built in from the start and not an afterthought.
What should be taken from this memo is that there is now a target date for implementation within the federal government which has been needed. Now vendors can plan to implement IPv6 and feel comfortable that they will be able to recoup their return on investment. Yes, I recognize that the federal government is not the only client that buys equipment in the US. But with the federal government migrating there is additional incentive beyond the force of IPv4 address depletion.
OK so now, I have mentioned the depletion of IPv4 addresses. What does IPv6 get us? Well for one, larger address pool. With that larger address pool the opportunity to systematically arrange the IPv6 prefixes globally such that the internet routing tables can efficiently aggregate.
Some people say "so what" to the number of addresses that IPv6 gives us....what can we really do with all the addresses that we could not do with Natting IPv4 addresses? IPv6 will be able to bring back the end to end connectivity paradigm that the internet (DARPAnet) was built on. Yes there are problems with this too (e.g. security). But with this ability now new technologies can be built, systems or equipment tracked based upon the paridigm. Think of it this way....when electricity was first delivered to houses and replaced candles or oil lamps. During that time, the uses for electricity that we take for granted today were never conceived. IPv6 gives the internet developers new undeveloped ground to explore.
Thoughs?
2. TCP & UDP are fundamentally unchanged - all flaws of IPv4 TCP & UDP are the same. Only diff between UDP/TCP on v6 is that checksum is required on UDPv6, it was optional on UDPv4.
3. End-to-end allows for host-to-host comms - firewalls, packet filters, IPS, etc are still allowed to be in the middle but stuff like NAT isn't need, no need to deal with not enough address space. NAT never was, nor is a security thingy!
So talking about security holes and IPv6 not being needed, well 15-20 years ago we didn't know all that much about IPv4 flaws. Stuff that was "possible" in theory has happened. Stuff like the Kaminisky bug was theory to DJB but he still dealt with then back in the day rather than wait. So while we may theorize about certain vulnerabilities, we're carrying much of the "trash" forward into IPv6 at layer 4 and higher. The only thing that is new is the layer 3 stuff and interaction between layer 2 & 3, no ARP but use of multicast. There is no testing lab like the real production Internet, so even if things were tested for 25 years - there would still be flaws found. DREN has been using v6 for some time now, but many of the organizations on DREN won't go v6 because they don't want to take the risk. How many organizations waited to make the switch from IPX to IPv4, I remember many a network that carried IPX, IPv4, and Apple/Ethertalk because it was necessary - we've dealt with multi-protocols networks in the past and we'll do so again.
Thomas (former DoD agency IPv6 transition manager & WAN program mgr)
Read this and weep on the current state of affairs in IPv6:
http://arstechnica.com/business/news/2010/09/there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly.ars
There is a steady IPv4 space exhaustion rate and when we hit it, cost of IPv4 address will go up as regional address registries will deny allocation requests and attempt to retrieve semi-used space. However, for foreseeable future, IPv6 only hosts will not exist. Progressive enterprises might want to start using dual-stack approach with private ipv4 and routable ipv6 and over the course of 5-10 years replace ipv4 only appliances with something dual-stacked.
My point is, only pioneers in next 5 years will do IPv6.
Just run netstat -an on a windows box and ask the user about their patchlevel and password habits (in multi-PC environments personal firewalls will not be blocking SMB traffic). Don't forget to check their printers and NAS devices etc. The majority of IP-enabled devices simply does not need end-to-end connectivity on the internet. I personally do not run a webserver on my smartphone.
W.r.t. Internet ideologies: SMTP was designed to allow anyone to mail to anyone. The result is mostly spam.
Furthermore, IMO many people tend to overestimate firewalls; blocking egress traffic to 6667/tcp doesn't suffice these days. For example, egress traffic to port 80/tcp may be used both by legitimate (http but also WebDAV) and malicious (example: MS KB 2264107) applications. Standard firewalls cannot inspect encrypted traffic, and applications such as Skype and TeamViewer easily bypass NAT and most masquerading firewalls. Last but not least most firewalls are hard to configure; while perhaps you are an expert, most people are not.
Give me a break. Everyone running the iphone iOS 4 is a pioneer then, since it natively supports ipv6. Not to mention Vista, Win7, debian, redhat, and OS X do ipv6 by default too.
But the opposite choice of v6 isn't between staying with v4 and keeping where we're at, the opposite of adopting v6 in the long haul is breakage...
<100 days till we run out of v4 addresses, and long term we'll have citizens with v6 only addresses.
Do we really want to allow Agencies to ignore customers on v6?