In the previous parts of this series (part 1, part 2, part 3, part 4) we covered several aspects of IPv6 security, mainly on the infrastructure level. In today’s post I will follow up by briefly discussing so-called First Hop Security features.
IPv6 First Hop Security (“IPv6 FHS”) is a collection of features (initially implemented, and named, by Cisco but available on other platforms too) that can be found on many access layer switches to prevent different attacks in IPv6 networks. The availability of those features is sometimes divided into three phases and started in 2010 with the release of IOS images containing mainly RA Guard (see below) and port-based IPv6 ACLs. Phase two was released in early 2012 and contained some more features (namely from the “IPv6 Snooping” framework) whereas phase three was released at the end of 2012 and contained some more advanced features (e.g. IPv6 Source Guard). Nowadays usually “phase one” features are supported on many platforms, at least on physical ones (support on virtual switches is still somewhat lacking).
There’s an excellent Cisco FHS Wiki maintained by Andrew Yourtchenko, Scott Hogg wrote a good overview, as did Ivan Pepelnjak, and this is a nice presentation on some elements by Jim Small from 2013. Still, from our perspective the main question is: which of those features should be deployed in production networks/can be observed in real-life enterprise networks. Actually it’s only two:
RA Guard
The Router Advertisement Guard (“RA Guard”) feature is specified in RFC 6105 (we’ve discussed it here some years ago) and is meant to discard inbound Router Advertisements (ICMPv6 Type 134) on a configured port. This feature should always be implemented (even in seemingly IPv4-only networks, as we will discuss in a later part) to provide network stability through preventing unauthorized router advertisements being sent by an entity. It is implemented in a stateless way in order to work in wire speed, so there is no reassembly of packets. Therefore RA Guard can be bypassed (with the use of extension headers and fragmentation). To prevent these kind of bypasses, operating systems in general should implement/incorporate RFC 6980. Unfortunately as of December 2015 only Linux based operating systems have implemented the controls defined in RFC 6980.
DHCPv6 Guard
DHCPv6 is a similar port-based feature which drops also incoming messages supposed to originate from DHCPv6 servers (e.g. Advertise or Reply messages). Therefore it’s meant to prevent unauthorized DHCPv6 servers in a segment/network. It can also be bypassed with attacks using fragmented packets.
From our experience all other features than those two either have teething problems or their configuration is cumbersome from an operations perspective (e.g. this applies to all features based on “policies” in Cisco space) so we usually recommend just going with sth along the lines of:
- RA Guard (on the port level)
- DHCPv6 Guard (on the port level)
- Logging of packets that are dropped from one of those features.
which equates (in Cisco land) to a sample (port-based) configuration like the following:
ipv6 snooping logging packet drop
interface GigabitEthernet1/0/1
switchport mode access
ipv6 nd raguard
ipv6 dhcp guard
FHS Support / Road Map in Cisco
Here’s an overview of FHS support from a Cisco Live event in 2015 (I couldn’t find a better reference, pls feel free to provide a better/newer source):
Furthermore recently a guy from Cisco wrote to us:
“FHS on NEXUS is still roadmaps for Nx7K in 7.3 due on CCO in January 2016. What FHS means in this context is RA Guard, DHCPv6 Guard and IPv6 Snooping. The other NEXUS platforms will follow later in 2016. The rest of the IPv6 FHS features will be extended to all platforms as well.”
FHS on HP Platforms
The features recommended above are also available on HP platforms (at least on current Comware based platforms). For example on pre Comware 7 R3109P03 platforms (since then there’s even a “RA Guard” command) a typical configuration would include the following (“global”) commands:
ipv6 nd detection [~ ra guard]
ipv6 dhcp snooping
ipv6 nd snooping
It should be noted though that the actual configuration approaches differ between the two vendors Cisco (“protection features enabled on port level”) and HP (“features get enabled globally & ‘trust’ has to be configured on port level, as an exception from feature”).
This difference can confuse operations personnel or, more importantly, require a different way of handling in templates. Actually mimicking the HP way on Cisco platforms might be cumbersome or impossible. On the other hand a port-based configuration (template) approach might be possible in HP space with sufficiently new images (those which implement “RA Guard”). Overall we recommend to carefully evaluate a potential/planned template-based configuration strategy with this in mind.
Christopher will provide an in-depth presentation on FHS configuration on HP devices at the upcoming Troopers IPv6 Security Summit and we’ll also run the traditional “Basic Attacks & Defenses in IPv6 Networks” workshop (which includes some of this stuff) in case you’re interested in the practical side of things.
In the next part of this series we’ll leave the space of infrastructure level controls and we’ll start looking at host/system level IPv6 security measures.
Everybody have a Happy New Year and a great 2016!
Enno