Arbor Networks: Security to the Core

Over the last 3 months a number of community organizations have conducted various Eat Your Own Dogfood (EYOD) experiments in order to gain operational experience with IPv6. These organizations included NANOG, APRICOT/APNIC, IETF and ARIN, with many others planned. While some of the technical details regarding network setup and mechanisms employed varied from group to group, there was an alignment in objectives. The primary goal of these experiences wasn’t necessarily demonstrative, but rather, to provide educational and documentation opportunities for folks involved with both the design and infrastructure operations related to IPv6.

At the ARIN meeting this week in Denver, and at the Rocky Mountain IPv6 Task Force (RMv6TF) meeting today I presented some of the output of these experiments (thanks to Randy Bush for working with me here, as he contributed the initial slide deck and much information), and I figured I’d share some background information, some of my thoughts, and results here. The information shared is by no means meant to be complete or exhaustive, but I do hope it’ll provide some information and references for folks interested in IPv6 deployment. A much more useful reference for these and related experiments and activities is available on the IPv4/IPv6 Operational Information Collection Wiki, which I strongly encourage you to visit.

Recall that IPv4 address space exhaustion is imminent, with free pool exhaustion predictions, predictions which gratuitously assume current allocation curves and the absence of last chance “land grabs”, mind you, from the Regional Internet Registries (RIRs) to occur around mid-2012 – only ~1100 days away. This fast approaching IPv4 free pool exhaustion, coupled with the fact that a native IPv4 host can’t speak to a native IPv6 host because of bits on the wire incompatibilities in the two protocols, lends itself to some interesting challenges ahead.

In case that wasn’t clear, I’ll repeat — IPv4 and IPv6 are NOT “bits on the wire” compatible. To further complicate the issue, no standards-based mechanism currently exists to enable translation between the two protocols. If you’re wondering about that Network Address Translation – Protocol Translation (NAT-PT) thing, well, it exists but has been moved to Historic status by the IETF, for 20+ reasons, as outlined in RFC 4966 – “Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status”.

Now, you may be thinking the IETF has lost it’s mind, or what’s the transition mechanism? Or you may recall that NAT itself isn’t an Internet Standard, in the IETF sense of the word. That is, NAT’s an RFC but only an Informational RFC, not an Internet Standard. I could publish an Informational RFC on how to make raisin cookies, but that doesn’t make it an Internet Standard. I’ll spare you any more details, but will provide a pointer to RFC 2026 – The Internet Standard’s Process, and also encourage you to RFC 4966, as the IETF’s not completely lost it’s mind – I think :-). Among the 20+ reasons outlined for moving NAT-PT to Historic status, many of these have something to do with the end to end argument. In short, transparency and unmolested end to end connectivity are one of the characteristics that’s contributed considerably to the success of the Internet – NAT and NAT-PT compromise this, something the IETF frowns upon.

What is the IETF’s idea of a transition mechanism, and what has it been for the last decade? Dual-stack. That is, hosts that wish to transition to IPv6 should run both IPv4 and IPv6 stacks. When everyone has IPv6, and the Internet infrastructure ubiquitously supports IPv6, we can turn off IPv4 and everyone can still communicate via IPv6. Well, if there were actually some incentive 10 years ago to begin this dual-stack deployment and investment by practitioners, then this might well have been plausible. However, today, only a very small percentage of networks have IPv6 deployed, and only a VERY small amount of content is accessible via IPv6. No eyeballs, no need for content folks to move there. As for eyeballs, your average Internet user could care less about the Internet “substrate”, much less IPv4 and IPv6 – all they want is their applications. That is, don’t count on users calling up and asking for IPv6 support.

As such, if you want to run an IPv6-only network today, what can you access? Well, assuming IP infrastructure providers are IPv6 enabled, you could see the dancing kame turtle, or the bouncing Google logo (ipv6.google.com), but not much else. Unless, say, hrmm… you use something like NAT-PT to provide translation from IPv6 to IPv4 in order to reach most of the Internet? Well, that’s just what most of the EYOD experiments (with the exception of the IETF experiment) have done — taken the extreme “If this network were required to be IPv6-only today, what could I do and what could I not do, and how do I make it at least moderately useful?” Not surprisingly, most of the Internet is reachable, well, with a subset of applications, with the right transitional functions in place, that is.

However, lots of stuff doesn’t work. For example, if you’re an IPv6-only host and you do a DNS lookup for www.google.com and you receive a DNS A record response that maps to an IPv4 address, you can’t do anything with that. So, you now need some DNS hack in place (e.g., TOTD) that synthesizes DNS A record responses with IPv6-friendly AAAA records usable by IPv6 hosts – and ohh, BTW, you have to coordinate between that TOTD device and your NAT-PT so they know what prefix(es) are being used internally for the hack. Talk about molesting end-end transparency – for more details on this have a look at S4.4 of RFC 4966, and the TOTD pointer above. Note though, that lots of stuff does work.

Then there are the OS quirks. For example, Windows XP boxes support IPv6 … mostly. But, if you’re a native IPv6 Windows XP box you can’t actually do DNS lookups over the IPv6 stack, you can only do them over IPv4. So, in order to make a Windows XP box work in one of these IPv6-only EYOD networks, you need either a special LAN for XP boxes that provides local IPv4 DNS resolution services, with global IPv6 connectivity, or you need a hacked DNS resolver (e.g., BIND) running on the local system to mitigate the Windows XP problem. It turns out Active Directory and some other functions on Windows XP have similar problems when IPv6-enabled, and Microsoft is aware of the issue and recommends Windows Vista if you’re planning on doing much with IPv6 in Windows environments.

And, of course, layer violations are a huge issue when employing NAT-PT. That is, if you have protocols (e.g., FTP & RTP) that convey Network layer information (e.g., IP addresses) in Application layer protocols and require that information be present and accurate in order to function correctly, then you’ll need Application Level Gateways (ALGs) to provide those translations. Some additional information on this is also provided in RFC 4966.

Then there are other problems. My iPhone doesn’t provide the capability to enable IPv6, and my MacBook doesn’t support DHCPv6, so I’ve got to add IPv6 DNS resolver information manually. As for more interesting brokenness, if that DNS resolver IPv6 address has a capital ‘A’ in the address, well, it drops it! And so forth…

Much more information on these results of these experiments and various OS & application quirks is available in the slides here, and certainly, on the IPv4/IPv6 Operational Information Collection Wiki.

To wrap this up, a few points I’d like to convey:

• NAT-PT is nasty from a transparency perspective, but in the absence of bits on the wire compatibility between IPv4 and IPv6 (and that ship has sailed), perhaps a necessary evil.
• IPv6 transition actually means co-existence of IPv4 and IPv6 for a very, very long time
• End to End will be further compromised until transition is complete, and your packets will be further molested as a result
• IPv6 and related mechanisms (e.g., NAT-PT) increase attack surfaces considerably, be prepared
• IPv4 exhaustion is imminent and not very far away
• IPv6 deployment is necessary, and it’s much easier to do in a controlled dual-stack environment than IPv6-only flag day with translation
• Because there is no flag day, IPv6 is even sexier than Y2K to many folks
• Contention for IPv4 resources as free pool exhaustion occurs does have a side benefit WRT secure inter-domain routing, as previously outlined here.

One other thing to note. These EYOD experiments are sorta of taking an extreme position. If they were dual-stack, as may have been for years, most of the reported issues would be non-issues.

I’ll close with a quote I saw used today by a speaker at the RMv6TF meeting: Misery Motivates, not utopia –Karl Marx.

This entry was posted on Wednesday, April 9th, 2008 at 9:41 pm and is filed under Arbor Networks, Critical Infrastructure, Interesting Research. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.