A Quick Security Evaluation of IPv6

In my last post on “IPv6 Security on the Stack Level” I mentioned that the journey to a secure IPv6 environment might start with a properly secured stack which then would have to be followed by operational processes & tools.
Accidentally I just re-read an old post on “Protocol Properties & Attack Vectors“, and I’d hence like to take the opportunity to discuss IPv6 from the perspective of the approach laid out in that post. While this will be an admittedly somewhat abstract exercise – regular readers know I have a soft spot for such reflections 😉 – it can help to develop an understanding of the types of operational controls one might need in a complex environment, in order to properly secure an IPv6 deployment effort.
The factors listed in that post were the following:

• Scope of interaction
• Integrated security capabilities
• Impact on packet forwarding
• Execution of an election process
• Amount of state
• Ratio of (numbers & sizes) of requests to responses

Let’s have a look at IPv6 from these angles. As stated in another slightly aged post on “IPv6 & Complexity“, talking about “the IPv6 protocol” here encompasses helper protocols to be found in most IPv6 networks like ICMPv6.

Scope of interaction

This boils down to “from where can a threat vector usually interact with $PROTOCOL” (with ‘threat vector’ including attackers or misconfigured other systems), which obviously can have a huge impact on the risk exposure of a system running it. For example security vulnerabilities of an LLDP implementation (like those discussed here) can only be exploited from an L2-adjacent node, whereas vulnerabilities in routing protocols often require the ability to send multicast packets (which in turn means an attackers has to be on a subnet shared with a router interface that has the protocol in question enabled).
Discussing this property from an IPv6 point of view is particularly interesting for (at least) three reasons:

• The by-default presence of the link-local address (LLA), together with joining several multicast groups, might allow for interesting interaction possibilities (once an attacker is in the same subnet).
• The latter two technical properties (LLA & multicast stuff) didn’t exist in IPv4 which once again makes clear that IPv6 is very different from IPv4 from a security perspective. Let me just emphasize: thinking that “IPv6 security is like IPv4 security, just with longer addresses” might lead to the implementation of inappropriate controls.
• Some IPv6 helper functionalities are supposed to interact mostly by means of multicast which in turn is supposed to be limited by L3 boundaries, and some implement “Generalized TTL Security Mechanism“-style checks in order to make sure only link-local sourced packets are processed (e.g. see the sections on “Message Validation” in RFC 4861). One may note I used “supposed” several times here 😉

Let’s assume one operates an IPv6 router and one wants to allow SSH access for a certain network segment (only), to a specific interface (represented by a specific address). A related, as it is/was called in Cisco space, ‘Infrastructure ACL‘ could roughly look like this:

permit tcp 2001:db8:10::/64 host 2001:db8::1 eq 22    # allow SSH access from management network 2001:db8:10::/64 
deny tcp any host 2001:db8::1 eq 22         # deny SSH from anywhere else
permit ipv6 any any # allow all transit traffic

Such an ACL would still leave SSH access open via the LLA of the specific interface, so for other systems in the same subnet. This might pose a relevant risk, or not. Point is that the mere existence of multiple addresses with different reachability properties might require adapted packet filtering rules for a number of systems. Also, generally speaking, moving packet filtering closer to the nodes (instead of doing it on the network level) might make sense in IPv6 times, but I’ll discuss the practical implications of the intellectual exercise performed in this post in yet another, upcoming, one 😉

In the context of recently published CVE-2020-16898 (for some background see these two threads and Francisco Falcon‘s great “Beware the Bad Neighbor” write-up) there was some discussion if one could attack a system from a non-local origin. Fernando Gont mentioned on the ipv6hackers mailing list (btw, here some more IPv6-related mailing lists) that he had performed some testing and it seems “*BSD, Linux, MS Windows” do properly perform implement the relevant checks (“GTSM”, see above. essentially checking if the received packet [still] has a hop-limit of 255). If that’s true let’s hope that Windows does that check before it parses (the length of) the RDNSS option…
In any case it should be noted that a while ago major router vendors were affected by a vulnerability that allowed sending unicast NDP/RA packets over the Internet to their devices, which in turn led to DoS conditions given the high priority queues/pipelines those packets are/were processed in. Chris Werny demoed this for Cisco devices in this post, and here’s the related Juniper advisory.

Integrated security capabilities

This area of evaluation is about the security capabilities which the protocol brings with it. More importantly it’s about their operational feasibility, read: (provided there are any such capabilities) can those be used in a way that provides a reasonable operational-effort-to-risk-reduction ratio?

Again, looking at IPv6 provides an interesting picture here. Following some naïve 90s “crypto will solve all network sec problems” optimism, there were hopes that ‘integrated IPsec’ would solve the looming security issues of the Internet. As we know, this hasn’t really happened yet (but backported-to-IPv4 IPsec became a success story in itself).

Furthermore there’s ‘SEcure Neighbor Discovery (SEND)’ as of RFC 3971, but let me be blunt here: the idea of enhancing the security of a by-itself highly complex network infrastructure protocol by certificate-based mechanisms is somewhat ridiculous from an operations perspective. For that good reason SeND has never gained any ground, and I don’t expect that to change anytime soon. Actually I expect SeND to be forgotten at some point ;-).

Alas those hopes (on IPsec) meant that existing authentication capabilities were removed (or replaced by practically unusable IPsec-based variants) from higher layer infrastructure protocols such as VRRPv3 or OSPFv3. For the latter this was later ‘corrected’ by re-introducing an authentication header in RFC 7166 (RFC 6506), which in turn reflected operational reality and needs from pre-IPv6 times.

Overall the in-practice absence of available built-in security mechanisms has produced two things of interest for an IPv6 security practitioner:

• the inability to establish (crypto-based) trust relationships for core helper protocols led to the development of compensating controls on the network level. The most prominent example is RA Guard which replaces protocol-inherent authentication by a ‘topology-based’ approach. Think: “if you can’t use a watchword to authenticate a messenger of a sensitive piece of information, then at least restrict the door through which the messenger can enter the room”.
• several later RFCs (such as RFC 6980 or RFC 7112) try to address IPv6 security issues (stemming from overly liberal design decisions) by inducing additional checks. While on the 1st glance this may seem a good idea, it should be kept in mind that additional checks usually increase the code base of an IPv6 stack. Not everybody would agree that more lines of code necessarily lead to more security…

Impact on packet forwarding

Let’s paraphrase this one as: “by means of an attack against $PROTOCOL, can we alter the future path taken by IP packets?” (which could either lead to Denial-of-Service scenarios or eavesdropping/Man-in-the-Middle attacks against unencrypted higher layer protocols). There’s a reason for the popularity of dsniff and Ettercap in the good old IPv4 days. IPv4’s helper protocol ARP was an ideal candidate for attacks: no integrated security capabilities while at the same time having an impact on the (local) destination of IP packets. Also the majority of existing attacks against DNS has the eventual objective to alter the path that IP packets take, based on falsified name-to-address mappings.

So what about IPv6 in this realm? Unfortunately (from the perspective in focus here) IPv6 introduced a very powerful function to provision default routes (and DNS servers) to hosts within a subnet, that is router advertisements. Keeping the absence of feasible security capabilities for NDP in mind (see previous section) we end up with a unfortunate combination of:

• a mighty control mechanism.
• which does not bring any authentication or integrity control properties.
• is expected to run by default on all end notes and which might even be needed for their full IPv6 life.

Furthermore pretty much every other main IPv6 helper protocol (NDP, DHCPv6, MLD) can be attacked in a way that allows to modify the future path of (some) IPv6 packets on the local link, which means all of those have to be carefully considered in a shared L2-environment, such as campus networks. A silver line being here that quite some enterprise Wi-Fi offerings nowadays come with built-in capacities to filter this stuff.

Execution of an election process

This again is a quite interesting one. Some of you might recall those days when Yersinia was the main tool for the network part of security assessments, and one of main reasons for this was the simple fact that quite a few infrastructure protocols (e.g. STP or HSRP) performed elections (of active forwarding devices) without many security precautions. Similarly in this talk from Black Hat Europe 2010 we discussed how to win a specific election in Cisco-based Wi-Fi networks (using the WLCCP protocol).

Looking at IPv6 it becomes clear there are many election procedures. Hosts choose between routers to act as their default gateway based on different router preferences as of RFC 4191 (which is the reason why all attack tools ofc send their RAs with router pref=high). The MLD querier role can change when a “query [is] received from a router with a lower IP address” (literal quote from RFC 2710 ;-), and some helpers select information on a ‘last received packet’ basis when facing multiple alternatives.

Amount of state

Here let’s look at ‘state’ as the amount of memory needed on hosts or network devices  in order to perform the expected functions of $PROTOCOL, or to perform related security functions (e.g. packet filtering or NIPS). The more state, the higher the susceptibility to resource starvation, either from an attack (DoS) or just from a misconfiguration (human error).

IPv6 has well-known issues in this regard (such as neighbor cache exhaustion), and certain helper packets (e.g. router advertisements or some related to MLDv2) are super-complex by themselves (leading to respective parsing efforts + resources for storing associated data structures).

Evidently the biggest issue in this space is related to IPv6 extension headers and fragmentation. Besides other security problems they may cause (see this paper) both stacks of local systems and network or security devices can have a hard time when it comes to packet reassembly and subsequent security decisions. RFC 8200 ‘allows’ up to one minute (“within 60 seconds”) between the 1st fragment of a packet and others needed for reassembly – how would any security device trying to look at a full (reassembled) packet in 2020 networks handle this?? Limiting the resources spent on this, and with this the depth of inspection, seems the only reasonable strategy here. From an operations perspective – and regular readers won’t be surprised at this point 😉 – just dropping all packets with EHs like HbH, RH, DestOptions or fragmentation might also be a good idea for some networks (not least as fragmentation can be expected to decrease over time, given latest developments like the DNS flag day. I have another post on that subject in the works).

Ratio of (numbers & sizes) of requests to responses

This is the aspect that is relevant for amplification attacks. If an attacker, either from a spoofed IP address or in the context of multicast, can trigger a lot of response packets (‘ideally’ of a large size), then DoS situations can be created. Protocols being unauthenticated and/or mostly stateless (running over UDP might play a role here) can influence these abilities, too.
In the IPv6 world several such scenarios come to mind, like:

• a single router solicitation (RS) can trigger an RA where “the usual case is to multicast the response to the all-nodes group” (RFC 4861, section 6.2.6), which in turn can be particularly annoying in Wi-Fi networks (which is why it’s a good idea to send RAs via unicast in such networks, see this talk from Troopers #TR16).
• triggering MLD report messages (as shown in this talk) from many hosts can create significant packet load on the local subnet.

---

In this post I discussed properties of IPv6 (incl. helper protocols) which can have an impact on the overall security and stability of environments using it. While this was meant to be a somewhat intellectual exercise, I will use this as a basis for a discussion of common IPv6 security measures in an upcoming post. Stay tuned & thank you for reading so far ;-).