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