It’s been said that IPv6 is like IPv4 but with a much bigger address space. While this is true, when you start comparing them side-by-side you realize they are more different than they are alike, especially when it comes to how you secure the two.
As I’ve written and presented on previously, IPv6 security is inherently hard. But just because something is hard doesn’t mean it should be ignored or used as an excuse to not do it. It’s why I and other IPv6 and security proponents spent the best part of eight years working on the recently published RFC 9099, which analyses the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques.
This post is the first of a series that will give you an overview of what is an extensive yet practical Internet Draft that details the advantages and/or disadvantages of certain security choices when deploying IPv6.
Nine years in the making
RFC 9099 was a long time in the making (nearly nine years between the first Internet Draft in the OPSEC working group and the final publication!). Much of this has to do with the breadth of the topic, many components of which are at the centre of nearly religious debates (like filtering of extension headers, or ULAs, plus other addressing topics). Hence many lengthy email threads on the working group’s mailing list were created, which made reaching consensus not necessarily easier.
Also, at some point, IETF procedures — this sounds better than ‘politics’ doesn’t it? — kicked in that led to additional delays (for those interested in this dimension of work within the IETF see Geoff Huston’s lucid Opinion: The making of an RFC in today’s IETF).
‘The’ list for all things IPv6 security
The document focuses on what we call ‘managed environments’ like service provider/operator networks or enterprise environments and is organized in several sections.
Addressing
Evidently, the addressing architecture chosen for a specific IPv6 deployment can have a significant impact on a network’s security posture (when it comes to routing, traffic filtering or logging), so the various types of IPv6 addresses and their security implications are presented in detail in this section.
Extension headers
These constitute one of the main technical differences between IPv4 and IPv6, and at the same time they have interesting (one could even say ‘challenging’) security properties; they’re discussed in a dedicated section.
Link-layer security
This section examines the local communication mechanisms of IPv6 both from an offensive and defensive point of view. It includes details on NDP attacks, rogue router advertisements, and their related protection mechanisms. Again, this is an area where major differences between IPv4 and IPv6 exist.
Control plane security
Securing the control plane is very important for high-speed forwarding devices as denial-of-service attacks against control plane protocols can severely impact the availability of entire networks. IPv6 poses some challenges in this space due to the introduction of extension headers and some changes to the role of ICMP(v6).
Routing security
IPv4 routing security best practices, for example RFC 7454 BGP Operations and Security, can, generally, be applied to IPv6. When discussing routing security, you need to consider:
- Authenticating neighbors/peers.
- Securing routing updates between peers.
- Route filtering.
Logging/monitoring
Some elements of the overall IPv6 architecture (like the ephemeral nature of IPv6 addresses, the fact that usually several of them coexist on a given interface, or their general format) have a significant impact on how logging and security monitoring are done in many organizations. These are examined in detail in this segment.
Transition/Coexistence technologies
From my experience, various organizations underestimate the effort required to properly secure dual-stack deployments (which is another argument for going v6-only where you can). Furthermore, using tunnel technologies traditionally creates headaches for security practitioners, so they merit respective considerations (at least we thought so). This section was heavily contested during the development of the RFC as people thought that the related security challenges do not stem from IPv6 itself but mostly from operational deficiencies in IPv4 networks, namely those not aware of the concurrent presence of IPv6 in their world.
General device hardening
A security guidance document wouldn’t be complete without this, right?
Enterprise-specific security considerations
Deploying IPv6 in enterprise environments needs some additional reflections (see also RFC 7381 Enterprise IPv6 Deployment Guidelines), which is why we cover the security side of things in a dedicated chapter that is split into two subsections on external and internal security.
Service provider security considerations
Obviously, operator networks need proper IPv6 security. While many of the required security controls are already covered in earlier parts of the RFC, some operator-specific aspects such as lawful intercept are discussed here.
Stay tuned for more
This post was meant to make you aware of RFC 9099 (in case you weren’t already) and provide a quick overview of its content.
Stay tuned for additional posts from the RFC co-authors (Merike Kaeo, Éric Vyncke and KK Chittimaneni), which will provide technical details on its individual areas.
Enno Rey is a long-term IPv6 enthusiast with lots of practical experience in the space.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.