Wandering Thoughts archives

What IPsec being mandatory in IPv6 really means

You read here and there that in IPv6, IPsec is mandatory; depending on which side of the firewall divide you're on, this either sounds great or alarming. But what does it actually mean? Recently, I got curious and did some digging, and it turns out that it is less than it sounds.

The summary:

A conformant IPv6 implementation must be capable of IPsec, but does not have to use it for anything.

The IPsec RFCs spell out the mechanics of IPsec; how you go about encrypting and decrypting and signing and so on, and how you respond to various sorts of packets. In the process it requires that conformant hosts have certain capabilities (some of them slightly weird ones). This is what is mandatory in IPv6.

It is not mandatory that you be willing to actually do IPsec connections with anyone; that is up to your local security policy to decide. This is unlike something like SSL/TLS, where having 'mandatory SSL' does not merely mean that you have SSL crypto code available and might theoretically use it if you liked someone, it means that you are actually using it to get encrypted connections.

(If I am reading the IPsec RFC correctly, it is also mandatory that hosts support IKE, which is a protocol for negotiating automatic keys. However, they do not have to be willing to do it; the capability just has to be there if you want to set things up.)

Thus, in practice IPv6 is no more likely to do IPsec than any modern IPv4 system, all of which are going to have IPsec available too, and turning on IPv6 does not get you any more encrypted connections than you had before.

My reference for this is skimming through RFC 2401, the core IPsec RFC, or at least the core RFC for the version of IPsec that seems to be implemented on Linux. (There is RFC 4301 from 2005 which theoretically supersedes RFC 2401, but it doesn't really change the picture.)

Platform risk and platform (in)security

One of the perennial arguments between Mac people and Windows people is whether or not Macs are better than Windows machines for staying safe on the Internet, and if they are, why this is so; not infrequently, the debates get quite heated. I think that one reason for this is that people confuse the concepts of platform risk and platform (in)security, and thus miss something important:

Risk is not the same as insecurity.

(Here, a platform's risk is the likelihood that people using it will be successfully attacked; a platform's security or insecurity is how hard it is to create a successful attack.)

In particular, a platform can (currently) be less risky without being more secure, and vice versa; a more secure platform can still be more risky. The distinction between low risk and high security matters partly because risk levels can change radically over time without any change in the platform itself, so if you confuse low risk for high security, you are risking a severe problem if the risk level changes (for example, if someone targets you specifically). And similarly, just because you have a secure platform does not mean that you don't have to worry about attacks.

I suspect that there are at least two reasons that this confusion persists. First, it's natural to feel that the two must be strongly related, although this is not necessarily so. Second, it's hard for most people to really know how secure something is, while risk is essentially an observed fact (how much malware is there, how common in the wild is it, and so on) that anyone can see. It's thus very tempting to use your intuition to extrapolate from the observed facts to a conclusion about a system's security.

(This entry was sparked by reading the comments on this Matasano Chargen blog entry.)

A thought about the speed of IPv6 deployment

The following thought about the push for IPv6 deployment struck me recently, so I'm going to dump it here.

One of the problems with IPv6 is that its major benefit is to expand the available address space, and the expansion of address space doesn't benefit people who are already on the Internet. Instead they are being asked to do a great amount of work for the benefit of other people, which rarely goes down very well.

(The people who are already on the Internet by and large already have address space; it is the people not yet on the Internet who may not be able to get it.)

One way to reduce the amount of work necessary and thus make IPv6 more likely is to have a genuinely IPv6 ready environment. By this I don't mean things that can in theory do IPv6 if you really want to find lurking problems, I mean things that are ready to do it at the flip of an option, and do it just the same as IPv4, so that adding IPv6 is a transparent thing that you don't have to think about.

(For example, if your 'IPv6 capable' firewall is not defaulting to giving you exactly the same restrictions on IPv6 traffic that you are configuring for IPv4 traffic, it is not IPv6 ready in this sense, because you would have to write and test a bunch of new firewall rules if you added IPv6. And just how are you supposed to take a current NAT-based architecture and move it to IPv6? (Hint: 'stop doing NAT' is not an answer that will get you very far in the field.))

That systems today are not like that is why I think that IPv6 is not going to happen any time soon. In fact, I think you can extrapolate the timing from system replacement schedules, so I don't expect IPv6 to get very much traction much until five or six years after everything you buy will be IPv6 ready. (And that will just be the start of things, since many bits of hardware and software live far longer than six years.)

Of course there is a chicken and egg problem here, because making things IPv6 ready takes a bunch of work and it is stupid to do that work if customers aren't demanding it. Especially when the effects of some IPv6 issues may not be fully understood until people start using it at Internet scale in the field (for example, the effect of pervasive endpoint IPSec on current firewall and IDS/IPS technology and policies).