The Persistent Problem of State in IPv6 (Security)

I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state  – you know, “stateful” firewalls and the like 😉 – before (here and here. btw, the widely discussed IPv6-related network outage at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the unfortunate relationship of MLD and ND).

One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.

Antonios Atlasis has demonstrated in this recent post that stateless ACLs, if configured in an insufficient way (which nevertheless can be observed frequently), can be circumvented quite easily. This seems to be a well-known problem as this slide from the above mentioned session shows:

 

 

Within the session exactly the same mitigation Antonios mentioned was recommended, that is going with “undetermined-transport” (keyword in ACLs):

 

 

 

 

with these additional comments:

 

 

So, problem solved?

Well, not fully. There’s some additional remarks and lessons (to be learned) from our side here:

a) first of all it has to kept in mind that “undetermined-transport” has its own flaws to. In the (btw: great resource!)  Cisco “First Hop Security” Wiki (to the best of my knowledge maintained by Andrew himself) it’s nicely stated: “Some platforms may not support acl keyword “undetermined-transport”. In that case they may either reject the command altogether, act erratically on such ACLs, or refuse to accept the ACL on the interface” and we have seen this exact thing happening (as described here and here).

b) the potentially complex nature of IPv6 packets requires that stateless security controls have to be verified as for their actual security benefit and have to potentially “enhanced” by tweaks previously unknown in the IPv4 world (like “undetermined-transport”).

c) overall, once again, this means that going for full IPv6 security is not about “feature parity” but about “identifying the right features/controls for the task”, carefully taking IPv6 specifics into account.

Have a great day everybody

Enno