IPv6 and “Teardrop” Attacks

Way back in 1997, CERT issued an advisory about “Teardrop” attacks (http://www.cert.org/advisories/CA-1997-28.html).  These are attacks where overlapping IP fragments are sent by a malicious actor in an attempt to either A) gain access to a protected system by evading IDS, firewall, and/or platform-based defenses, or B) disrupt the capabilities of the target environment – ideally in several parts of the network but especially the target node (the destination IP interface) itself.

In the 1997 CERT advisory, I am sure the concern was IPv4 systems.  In brief, CERT’s advice was to contact vendors for a solution, and that solution was almost always to upgrade the platform OS version – it seemed the vendors were able to patch implementations.  Presumably, this was done by discarding fragments associated with a Teardrop attack (any set of fragments where any two overlap).  Juniper, for example, added a user configurable switch on platforms to explicitly drop overlapping fragments.

Any node sending overlapping fragments make no sense at all, from a protocol standpoint.  Yet my understanding is that some old IP stacks did sometimes send overlapping fragments, not as an attack but as a result of a sloppy or buggy IP implementation.  Thus, in an effort to promote interoperability with these stacks, other vendors would accept overlapping fragments.  This philosophy goes all the way back to Jon Postel who said “be conservative in what you do, be liberal in what you accept from others”.

On the downside, this flexibility provided an exploitable vulnerability to malicious actors. Mostly, the attack was more directed at OS platform bugs than the IP stack.  Modern platforms for the most part have implementations hardened against Teardrop-style attacks on IPv4 or IPv6.

And while it is true that the IETF IPv6 specification (RFC 2460) does not explicitly prohibit overlapping fragments, most vendors implemented protections against those IPv6 fragments as a matter of best practice.  Later (December 2009) RFC 5722 made it out-of-spec for source nodes to send overlapping fragments, and made it required for the reassembling node (the ultimate destination) to silently discard all fragments associated with a fragmented packet when any two fragments overlap.  Fragments are silently discarded, as opposed to having the reassembling node send ICMPv6 error messages, to guard against reflection attacks (where the attacker uses a victim IPv6 address as the source of the offending packets), and because the sending node is already acting “fishy”, so best not to burden any system (including the originator) with processing ICMPv6 error messages.

There is also the issue of fragmentation attacks against “atomic fragments”.  These are IPv6 packets that are not actually fragmented, but carry the IPv6 Fragmentation Extension Header (with “Fragment Offset” set to zero and the “M” bit not set).  The reason for these to be allowed in the IPv6 specification is to support certain IPv6-to-IPv4 translation solutions.  To protect the capability from exploitation, there is an IETF draft (“Processing of IPv6 “Atomic” Fragments”) discussing ways to defend against fragmentation-centric attacks on this kind of packet.

With the improvements made to stack implementations over time (in the case of IPv4), and the fact that most IPv6 implementations were always “tighter”, the Teardrop attack has become a spent force on the Internet – really only affecting older platforms.  Thanks to RFC 5722, there is now official IETF guidance on how IPv6 stacks should be implemented in terms of handling overlapping fragments, and giving platform vendors the green light to discard these corrupted fragments aggressively.

It is a classic example of the “arms race” nature of IP security – whether for IPv4 or IPv6.  The bad guys discover a new vulnerability and an exploit, and the good guys close it off and harden everything else related to the vulnerability they can think of.   A good reminder that IPv6 security is only “better” than IPv4 security in a few ways, and secure environments really depend on rigorous deployment of security best practices and constant vigilance by an informed and talented security team.

What’s New with the Flow Label?

The IPv6 Flow Label specification has been updated by the IETF as of November, 2011, and includes changes and refinements that should make the Flow Label more useful in the near term.

IT networking specialists have considered the Flow Label “underspecified” since the first IPv6 specifications were written in the mid 1990s.  As a result, this 20-bit field carried in the IPv6 base header has been a bit of a waste, and has been little used.

In brief, there are three (3) IETF RFCs related to the Flow Label recently published.  Below is a brief digest of each:

RFC 6436 (Informational) is titled “Rationale for Update to the IPv6 Flow Label Specification”, and provides just that.  It provides a description of perceived shortcomings of the previous specification (RFC 3697) and makes recommendations on changes.  The most important bits of information in this RFC are:

  • RFC 3697 requires that only the source node set a Flow Label, and that the Flow Label be delivered intact to the destination node.  This means the Flow Label cannot be set by intermediate nodes, unlike the DSCP sub-field in the IPv6 Traffic Class field.
  • Because the Flow Label is not covered by any checksum, and it is not covered by IPsec protections (not even the Authentication Header), the field cannot really be trusted to not be changed accidentally or overtly along the path from source to destination.
  • The new RFC makes recommendations on updates to the Flow Label, which are specified more authoritatively in RFC 6437.

RFC 6437 (Proposed Standard) is titled “IPv6 Flow Label Specification”, and replaces the previous standard (RFC 3697).  Important elements of the new standard include:

  • Noting that the default implementation of the Flow Label is “stateless”, but that future other uses based on a signaling mechanism are not precluded.
  • Noting that the envisioned use case for stateless Flow Labels involves load-balancing traffic, either in the case of Equal Cost MultiPath (ECMP) or Link Aggregation (LAG) implementations.
  • Encourages source nodes to set Flow Labels, with a unique label per flow
  • Restates that Flow Labels should be well-distributed (random) and not guessable
  • IMPORTANT – removes the restriction that only the source node may set a Flow Label, making it permissible for any device to set a non-zero Flow Label in an IPv6 header where the Flow Label was previously zero (so, an intermediate node may set a Flow Label, but not re-set it)
  • UPSHOT HERE – this new permissiveness means that a router – perhaps the distribution-layer router – can set a Flow Label for flows that do not have them, making the Flow Label useful to other routers, further downstream, that may be performing ECMP or LAG.  The router can take action on the Flow Label where the host did not.  This is a little like an ingress router doing QoS classification and marking for the benefit of downstream routers.
  • The new specification also makes it permissible, on occasion, in high-security environments, for an intermediate node to set a non-zero Flow Label to zero, in an effort to eliminate the possibility of a covert channel being implemented in Flow Label values.
  • The RFC states numerous other possible security issues related to the Flow Label

RFC 6438 (Proposed Standard) is titled “Using the IPv6 Flow Label for ECMP and LAG in Tunnels”.  It describes a way by the Flow Label can be used as the title suggests.  The scenario is that a tunnel has been built where the tunneled traffic passes through a set of devices implementing LAG.   In brief it works like this:

  • Normally, tunnel traffic frustrates the LAG load-balancing algorithm.  Think about it.  If the traffic were not in a tunnel, the individual flows would be apparent – the traffic would be a collection of flows between varying sources and destination, and for different protocols and L4 services (the “5-tuple” would be available for load-balancing).  Because the traffic is tunneled, all traffic yields the same 5-tuple at the downstream LAG, where there is a single source (one end of the tunnel), a single destination (the other end of the tunnel), on protocol (perhaps IP-in-IP, or perhaps GRE).  In other words with the tunnel all traffic looks like a single “massive flow” to the LAG.
  • For a solution, the RFC describes a mechanism whereby the ingress Tunnel End-Points (TEP) examine the tunnel traffic as it enters the tunnel, and then write a Flow Label into the *outer* IPv6 base header based on the 5-tuple of the *inside* packets.  In short, the TEP and the Flow Label turn the “single massive flow” back into individual flows.  The LAG then load-balances on the IPv6 3-tuple (source, destination, Flow Label), and the balancing can be efficient.

That’s the quick wrap-up for all three (3) related RFCs.  IPv6 refinement continues apace, and the protocol continues to evolve gracefully to match the needs of a global scope network.

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.

IPv6 Implementation Expertise for Consumer Service Companies is Critical

Improving Competitiveness with IPv6

Providers such as Comcast moved to IPv6 to address scalability constraints and in the process, their brand became recognized Worldwide as thought leaders in IPv6.  Hurricane Electric set the pace in the Tier 1 SP space by focusing primarily on IPv6 and surpassing the IPv4 incumbents.  Free, the hyper innovative European provider jumped on IPv6 early and in the process it created a whole new approach to IPv6 deployment.  They were off the radar and now, other providers are using the standard defined by Free.  I worked with major providers such as ATT, Verizon and Centurylink who are also moving to IPv6 and the challenge they are facing is more related to backend systems and processes than basic transport.

The more devices to manage, the more you need IPv6

Mobile operators are committed to IPv6 out of necessity, they have so many devices to manage and deliver services to. T-mobile is a good example and they took a translation approach to running their trials; spoke to their architect last year.  Various service providers have different approaches to IPv6 adoption.  On the enterprise side, there’s Bechtel, where lots of interesting work is going on.  It was a complex adoption but under Fred Wettling’s leadership, Bechtelopened the way for IPv6 adoption in this space. They are now aligning the cloud and IPv6 initiatives.  This comes back to the whole idea that IPv6 adoption is not an overnight exercise.

As highly as we like to think about our capabilities, these are complex problems and good solutions are developed over several iterations. At national strategy level, Japan has been leading IPv6 adoption for some time, but similarly, China, India, Korea and Singapore are actively driving adoption as well.  They see IPv6 as a competitiveness play and there is lots of new activities and demand in Asia Pacific, especially with the APNIC announcement that it ran out of IPv4 addresses.

The time is now for IPv6

When I worked with these governments on national initiatives in the past, the efforts, the focus were more superficial than what is happening right now.  As far as implementation of IPv6 is concerned, we see most of the techniques are still in play. We love dual-stack; it is where everything is going however, we have 6rd which is an offshoot of 6to4 and NAT64 used for trials and proof of concepts.

The core has been dual-stack for quite some time but we cannot throw out the other transition mechanisms in the short term. I want to emphasize the importance of taking the early steps to do this right and make the most out of this transition.  Comcast was a great example.  They looked at IPv6 as a way to explore other options for their infrastructure.  After a lot of validation and testing which is very important with this transition, IPv6 adoption was a unique opportunityfor them to try a different routing protocol in the core.

Examples of companies who are embracing IPv6

In the case of one giant telecom company I have helped, they were concerned about the scalability of their IPv4 L2TP based model.  The problem was they wanted to secure new services; they wanted to deliver multicast based content over their access infrastructure.  L2TP would not scale to this model.  For them, the new business model depended on a completely new infrastructure.  They wanted to build a next generation infrastructure without a downtime on the operational IPv4 based services.  It was a true transformational process.  Look where you want to go and execute on IPv6.

Plan the move to the Cloud with IPv6 as a key Capability

IT organization’s today are planning the move to Cloud Computing. I am sitting here and thinking we have exhausted theIPV4 address space – so the future is IPv6. If IT organizations are doing the planning to choose the right Cloud delivery models and the right Service Providers, they might as well do the IPv6 assessment and planning at the same time.

The meticulous planning that Enteprises are going through for the Cloud contain all the same underlining components which are part assessment and analysis for determining IPv6 readiness.  They are reviews of:

  • Infrastructure elements
  • Operating Systems
  • Web Services, Application and Databases
  • Service Management Orchestration Tools
  • Security and Risk Impact
  • People and Process.
Are the providers that you choose for either IaaS/PaaS/SaaS capable of delivery IPv6 services across the stack? It will impact your business sooner than you expect.

Other elements, such as infrastructure design and implementation of solutions like  VBLOCK or FLEXPOD are IPv6 ready in addition to network services like Firewalls, Load Balancers, IPS, VPN-GWs to name a few.

If the plan is to move the Applications/Middleware into the Cloud and future proofing it for Next Generation make sure that the Web/Middlware/Applications and Databases are also v6 ready.

In conjunction with addressing the infrastructure, you need to educate the DC/Cloud Architects, Subject Matter Experts and IT Operations team to get ready for IPV6.

Yes the amount of changes required is considerable. But compared to the work that the teams are currently engaged in for strategy and planning for the Cloud the extra efforts will be well worth to futureproof the systems for IPv6.