IPv6 Security Part 1, RA Guard – The Theory


at first a happy new year to our loyal readers (and, of course, to everybody else too ;-)! We hope you all had some pleasant transition times, not suffering from bad hangovers after 27C3 or sth 😉

Things are heating up for Troopers and in the course of that we started putting together the slides for the workshops (I’m delighted that Flo told me today there’s already quite a number of bookings for the workshops…). I myself will give the “IPv6 Security in LANs” workshop, together with Christopher. The workshop preparation will be accompanied by a series of blogposts with three main areas to be covered:

– IPv6 behavior in the LAN, its underlying trust model and subsequent attacks (all the attacks centered around ND, RA etc.).
– tunnel technologies and their inherent risks.
– risks associated with IPv6 addressing (reachability of internal systems due to route leakage, problems related with privacy extensions etc.).
Pls note that we assume that the reader already disposes of some knowledge of IPv6 inner workings so we’re not going to cover protocol basics here.
[at some point we might provide a list of books we regard valuable for the topic though]

To get some inspiration and an update on current attacks I just watched the youtube video of Marc Heuse’s (aka Van Hauser from THC) talk at 27C3 on “Recent advances in IPv6 insecurities”. Impressing stuff! I’d say: a must see for everybody involved in IPv6 security.
The Q+A session will serve as a starting point to today’s post.
The second question (at about 44:55 in the youtube video) comes from a guy asking for “mitigation techniques”. Marc’s answer is “vendor updates”.
While this is certainly correct to some degree I’d like to add that there are – depending on the network infrastructure deployed – fairly simple ways to mitigate all the nasty “spoofed RA”, “RA flooding” etc. stuff.

To illustrate those let’s take ERNW’s “Seven Sisters of Network Security” approach which describes fundamental guidelines for infrastructure security that can be applied regardless of the technology/-ies in question (or even regardless of the network context. They work for any kind of complex system, be it a network, a building, a production plant etc.).

a) Sister no. 1: “Access Control” (keep the threat out of the overall system). Obviously keeping an attacker who tries to perform all those awful IPv6 based things out of your network at all (e.g. by using 802.1x) would be elegant and nice. Still let’s assume for the moment that the approach of access control is, for whatever reason, not available.

b) Sister no. 2: “Isolation” (limit the assets’ visibility/reachability with regard to the threat).

The isolation principle can be applied in two ways. First it should be obvious that, given the link-local nature of RAs, most of RA/ND related attacks can only be performed on the local link (“IP subnet” in IPv4 lingo) so putting systems-to-be-protected in different segments than those where attacks can be expected (e.g. due to type of users or systems located in them) would be a first step. So, once more, proper network segmentation can be your friend. This can’t be stated often enough! Unfortunately this isolation approach isn’t present in many environments and can’t be implemented easily either.

Second – and this (finally ;-)) is the main point of this post – on an abstract level router advertisments are kind-of sensitive traffic that should not originate from “the untrusted access domain” but only from “trusted infrastructure devices”. So preventing “the access domain” from injecting RAs and limiting RA originators to some trusted entities (e.g. identified by the network ports they’re connected to) would be “the architectural approach”. Which is exactly what the “Router Advertisment [RA] Guard” feature does.
RA Guard, currently described (note that I’m not writing “specified”) in this IETF draft (after all available as a “08 version” which means there’s some momentum in the process) works quite similarly to other Layer 2 protection mechanisms (for example “DHCP snooping”) available on many access switches nowadays: “do not accept a certain type of [infrastructure protocol] packets on certain ports”. In our context this would mean “do not accept RAs on all ports except those where the trusted L3 devices are connected”. Usually this type of protection mechanisms requires (only!) one extra line of config added to your “secured port configuration templates” – that all of you use, don’t you? 😉 – which in the case of Cisco devices would be “ipv6 nd raguard” (see this doc for more details).

Unfortunately, in the Cisco space (haven’t checked other vendors so far) RA guard seems currently only available on recent images for either Cat65K with Sup 720/Sup-32 and 4500/4900 series devices. We have a Cat65 with Sup-32 in our lab but I certainly don’t want to use this for the workshop (hint: being in the same room as a running Cat65 and trying to understand what the instructor tells you might instantly become tedious, for you… or the instructor ;-)).
So, for today, I can only state that based on my “paper understanding” of the way RA guard works, this will certainly be a good (means: operationally feasible) way of addressing a number of problems related with IPv6’s trust model in LANs. I just bought a 4948 on ebay and will start playing around with the feature once it arrives and share my thoughts on it here. I’m sure that RA guard will creep into other images soon as well so I’d surprised if it wouldn’t be present on, say, 3750s in the near future.

c) For completeness’ sake it should be noted that going with sister no. 3 “Restriction” (restrict/filter traffic between threat and asset) would be another option.
Filtering ICMP message 134 by port based or VLAN ACLs _could_ be another potential mitigation approach. Albeit one with much more operational cost than going with RA guard. So, if available, pls use RA guard and not the filtering approach. And pls don’t use both (at least not on the same devices). Why? See this post

d) Again, for completeness’ sake I’d like to add that sister no. 4 “Use of Cryptography” could come into play as well, by using SEND (SEcure Neighbor Discovery as of RFC 3971). Personally I do not expect many environments to use SEND at all due to the large crypto and subsequent operational overhead.
Remember: the initial architecture of IPv6 was developed in the 90s where the naive thinking of “LANs are trusted and crypto can solve all problems if there are any” was still prevalent and (practically) nobody considered operational effort as a main driver (or “inhibitor”).

Will keep you updated once the 4948 “shows up” and I can perform some practical testing.



Leave a Reply

Your email address will not be published. Required fields are marked *