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?

Comments

Ryan said…
I was hoping I was going to retire before I had to worry about IPv6. But being that I'm 29, I suppose that's a fairly significant false hope. Sigh...

Good points that I didn't know though. I obviously have a lot to learn with IPv6!
Anonymous said…
End to end connectivity isns't "inherently at odds with security"...IPv6 can be filtered, ACL'd, tagged...I just finished a CCIE bootcamp. We covered v6 in greater depth than I ever had before. There really isn't anything that you can do to v4 that you can't do to v6. If my users were running dual stack, they wouldn't even notice the difference for internal services. Take a deep breath, for God's sake.
Anonymous said…
What's IPv6? (joking. Then again...)
Anonymous said…
Great points overall. Can you expand on this point:

"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?
Anonymous said…
"IPSec mandatory in IPv6" means IPSec must offer IPSec, not that it be enabled.

I think you mean:
"IPSec mandatory in IPv6" means *IPv6* must offer IPSec, not that it be enabled.
Brian Best said…
In my opinion, there have been many misconceptions about IPv6. One example, IPv6 will make multi-homing easier and more efficient. This is false as this is an ISP issue and IPv6 doesn't address the routing table pollution problems that arise from entities that desire or need to have multiple links to the Internet. LISP is a more effective and interesting solution to this problem. The address space is touted and, I suppose, is probably the most plausible of the arguments. You can't argue that 128 bits of address space affords more space for networks and end hosts than 32 bits. However, a large chuck is immediately wasted by embedding the MAC address with the eui-64 format. Not sure I understand the logic there. As you emphasize, the security issues remain and are not magically solved by IPv6's IPv6ness :-)

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
Unknown said…
(OK, this is all just my personal opinion, I don't speak for my employers or clients, etc.)

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
Clif said…
I don't think the complexity Kundra mentions is in relation to the protocol itself, but rather the specific reliance we now have on NAT. They do little more than forcefully extend a layer two protocol into layer three. Which means the only real security you're provided with is address obscurity.. It also means that true end-to-end layer two communication is impossible and your layer three is bound to TCP/UDP or tunneling through them. v4 originated as an end-to-end protocol, but petered out due to address limitations, not because of security.

'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.
hugh said…
I agree with you this time.
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.
Anonymous said…
Dynamic NAT provides security only as a byproduct of creating connection state tables. Stateful firewalls are mature enough at this point that stateful firewalls + global addresses should not be a problem.
Anonymous said…
Actually as much of an abomination as NAT is, and how it shouldn't be relied upon as a security measure it does work well to help clearly delineate internal IP address space from external address space.
frydog said…
"Great points overall. Can you expand on this point:

"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
frydog said…
Richard,

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?
Unknown said…
I want to add that if someone came to me and said that, as part of the IPv6 redesign, IETF and friends fixed a bunch of security problems in IPv4, oh and here's the big long list, then yeah, I would be on-board 100%.
Anonymous said…
NAT is a pain and I will be glad to see it die a painful death. End-to-end communication is how the internet was supposed to work. Real security can still be handled by filters and firewalls at all sorts of levels. Hiding behind a NAT does remove your direct address, but doesn't make you more secure. On the contrary, it mostly makes many people complacent because they think (wrongly) that they can't be attacked easily.
Anonymous said…
1. IPSec is required by spec for each IPv6 stack, but only DES is required for the crypto piece. US Gov and DoD IPv6 requires FIPS140-2 approved AES crypto.

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)
Anonymous said…
These deadlines are completely unrealistic, and forcing these deadlines will be an operations and security disaster, especially for agencies which must support more than one operating system. Not to mention that we won't get the funding to do it right.

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
The biggest push will not be from mobile devices consuming ipv4 space, but from demand from ISPs to allocate IP addresses to their customers' home lines (DSL) and to enable new customers run their web apps (with shared hosting going out of favor, everybody wants his virtual machine and few ip addresses for TLS).

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.
Anonymous said…
I tend to agree with the Ubiquitous Mr. Lovegroove that only pioneers in the next 5 years will do IPv6. So how many of us with experience in the US Federal Government think that this is the natural home of pioneers?
Bitwiper said…
NAT is not a pain (if it's a pain for you, get a public IP range, IPV6 once IPv4 runs out). Small routers featuring NAT (actually PAT or Masquerading) effectively disable inbound connections, thereby protecting zillions of SOHO PC's from being compromised via network attacks, hence doing the Internet as a whole a favor.

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.
Anonymous said…
"only pioneers in next 5 years will do IPv6."

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.
Anonymous said…
Pushing NAT as a security feature is a joke. It happens to be kinda secure as long as port forwarding isn't enabled, and as long as the vulnerability isn't client-side. In practice, most people will get IPv6 connectivity by plugging in the "modem" they get from their ISP, the "modem" will be a stateful firewall/router/switch/AP, and it won't forward inbound connections by default--the security situation will be exactly the same as it is now.
Anonymous said…
There's no doubt IPv4 has been successful... we've clearly used it long enough.

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?

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics