A Less Secure IPv6?

There has been a relatively recent revision at the IETF –still in Draft but shaping up – to change the IPv6 stack requirement for IPsec implementation from “MUST” to “SHOULD”.  This has been under discussion at the IETF for a few revisions of the Draft, but appears to be “solid” now.  This change has been controversial, and deserves a bit of a closer look and some careful thought about the impact on IPv6’s ongoing evolution and deployment future.

The base IPv6 IETF specification (RFC 2460) mandates IPsec support (“MUST”) in all “full implementations” of IPv6.  In the early years of IPv6 promotion, this gave rise to the overstatement that “IPv6 has security built-in” or “IPv6 is more secure than IPv4”.  Both these taglines for IPv6 are inaccurate.  IPsec is a (terrific) layer-3 solution to provide in-transit security services to IPv6 (or IPv4, in many, many IPv4 stack implementations) packet flows.  It is not the right security tool to solve all security problems, and IPv6 – like IPv4 – faces a number of very different kinds of attack strategies.

More specifically, RFC 2460 mandates support of AH (Authentication Header) and ESP (Encapsulating Security Payload) in IPv6.

The latest twist in this story is the change in “IPv6 Node Requirements” (draft-ietf-6man-node-req-bis-XX”), on track for Informational status, moving IPsec support in IPv6 stacks from “MUST” to “SHOULD”.

A reasonable question at this point is “why is the IETF removing IPsec as a mandatory element of IPv6” and maybe “does this really matter”?  I don’t have answers to those questions, but I will suggest a way to look at this issue.

For the first, my understanding is that some vendors object to a blanket requirement for IPsec in IPv6 stacks because; (a) their customers are not asking for it; and/or (b) they believe their product will run better or faster or use less power or have a smaller footprint if they are able to omit IPsec support; and perhaps they simply want to make their own decisions about IPsec’s relative priority in their product.  This generates a reasonable question – essentially “what price is paid by unique implementations for the standard that all IPv6 stacks MUST support IPsec, and what is the value of a standards-driven requirement?”.

The second question is harder.  There are some IPv6 standards that assume
IPsec is present, as “promised” by RFC 2460.  Perhaps most notable is OSPFv3, which removes all L4+ security services in favor of leveraging the node’s underlying IPsec service for security.  It would not be good to have OSPFv3 unable to use a secured routing plane in cases where IPsec is not provided by the platform vendor, or to make vendor OSPFv3 implementations non-interoperable, by driving vendors to build varying security solutions into their OSPFv3 implementation.

And it is simpler – and simpler is often better – to have a straightforward rule like “all IPv6 stacks have IPsec” than something more complex like “most IPv6 stacks have IPsec, but not all, in all cases, so careful evaluation is required by buyers/implementers”.

A careful read of the Node Requirements Draft actually shows it does two things concurrently.  On the “add complexity side”, it does make IPsec support by IPv6 stacks optional.  Vendors are free to implement IPsec in their IPv6 stacks or not, at their discretion. That means buyers need to evaluate their need for IPsec separately from their need for IPv6, and consider the tradeoffs of buying an “IPsec-free” IPv6 implementation.

On the “add clarity side” of the balance sheet, the Draft tightens the exact requirements for IPv6 IPsec implementation **when the IPsec implementation is present**.  As an example, the Draft makes support for RFC 4301 (“Security Architecture for the Internet Protocol”) mandatory for IPv6 IPsec implementations.  That RFC in turn requires support for IKE (Internet Key Exchange) automatic key management within those IPsec implementations, which makes IPsec much more deployable and secure.  RFC 4301 also requires support for a minimum set of supported cryptographic algorithms, which makes IPsec more interoperable across vendor implementations.

To wrap up, then, these new IPsec requirements in the Draft have two significant impacts:

  1. IPsec becomes optional to implement on IPv6 stacks
  2. Where IPsec is implemented for IPv6, it will be more interoperable and more robust

My own opinion is that these revised requirements are a good outcome.  They allow vendors to serve their customers best, by implementing IPsec (or not) as their particular solution demands.  And where IPsec is a market requirement (even if no longer a strict RFC requirement), as an implementer I will have increased confidence IPsec will be deployable, interoperable, and robust – thanks to additions and clarifications above and beyond what RFC 2460 required that are described in the Node Requirements Draft.  I am willing to trade off the uncertainty of the former for the assurance of the latter.