In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.
As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.
It is hence recommended to filter at least some extension headers (hop-by-hop, destination options, routing header, in some cases fragment header) at the border to non-trusted networks (to the Internet and also to the business partner networks). This might be accompanied by a suitable logging/monitoring approach to identify use cases that may develop later. A sample ACL implementing this for Cisco devices looks like this (actually not all images support all keywords):
deny ipv6 any any hbh
deny ipv6 any any dest-option
deny ipv6 any any fragments
deny ipv6 any any mobility
deny ipv6 any any routing
On Filtering IPv6 Fragments
In the sample ACL displayed above IPv6 fragments are also filtered. Within the IPv6 security community there is some debate if this approach is too strict, and it may lead to legitimate traffic (e.g. large DNS query responses) being filtered as well. We think that the achieved protection benefit of filtering IPv6 fragments is to be considered more valuable than potential negative impact. In particular the consequences as for DNS queries can be prevented via a proper implementation of firewalls and DNS servers within an organization (allowing TCP based DNS, EDNS0-option in UDP based DNS etc., see also this post for a detailed discussion).
Eric Vyncke suggests to also use “deny IPv6 any any undetermined-transport” but we’re a bit sceptical wrt this one as this would also drop GRE (which we see in use, at the perimeter, in some corp environments for receiving traffic once it’s scrubbed by a cloud-based anti-DoS provider), and we have the impression that “undetermined-transport” still has some teething problems (for some background see one of these links).
===
It should further be noted that RFC 4942 “IPv6 Transition/Coexistence Security Considerations” states “Firewall vendors and administrators may choose to ignore these [RFC 2460 on Extension Header & fragmentation processing] rules in order to provide enhanced security as this does not appear to have any serious consequences with the currently defined set of extensions”. Actually for example Check Point Firewalls do the following by default:
This is a reasonable stance and it’s also reasonable to not have knobs for adjustment in the “Global Properties” pane, as this prevents hectically enabling them in one of those situations where “the business yells that their fancy new app does not work properly due to the firewall”… [in my days as a firewall admin we kept our fingers away from manually editing table.def and I’d be surprised if this would be considered a frequently performed action nowadays ;-)]
Filtering of Invalid (Source) Addresses
Inbound traffic from certain address ranges should be filtered in general (namely traffic sourced from such addresses):
- Packets with a source address from of the organization.
- Packets with a source address out of segments that are not yet planned for any assignment from the Internet Assigned Numbers Authority (IANA) through the Regional Internet Registries, e.g. the RIPE NCC (see also here). Those addresses are sometimes called Bogon Addresses.
- Packets with source or destination address out of a segment that is assigned for special use purposes. Those addresses are described in RFC 6890 Special-Purpose IP Address Registries, see also here.
- Packets containing certain multicast addresses, in particular from the scope of link-local (ff02::/16 prefix) as destination address (multicast addresses must not exist as source addresses, see RFC 4291, Sect. 2.7: “Multicast addresses must not be used as source addresses in IPv6 packets or appear in any Routing header.”), to prevent remote attacks with ICMPv6 or MLD as target (for the latter a receiving node usually does not check if a packet [still] has a hop-limit of 255 – in contrast to most ND packets – but we suggest such a check).
deny 0400::/6 any
deny 0800::/5 any
deny 1000::/4 any
deny 2d00::/8 any
deny 2e00::/7 any
deny 3000::/4 any
deny 4000::/3 any
deny 6000::/3 any
deny 8000::/3 any
deny a000::/3 any
deny c000::/3 any
deny e000::/4 any
deny f000::/5 any
deny f800::/6 any
deny fe00::/9 any
deny ipv6 host ::1 any log-input [on this particular one see this post]
deny ipv6 fc00::/7 any
deny ipv6 fec0::/10 any
deny ipv6 2001:db8::/32 any
deny ipv6 2001:2::/48 any
While the above sample ACL implements a black-list approach, alternatively a white-list approach similar to the following ACL could be considered:
deny ipv6 2001:db8::/32 any
permit ipv6 2000::/3 any
permit ipv6 fe80::/10 any
(permit ipv6 :: any] [for duplicate address detection (DAD) on the local-link]
deny ipv6 any any
This ACL was suggested by Eric Vyncke and, while we’ve seen “our approach” in some environments already (not least because we’ve recommended going this way, so there’s some self-fulfilling prophecy here), we actually like the latter (Eric’s) one due to its simplicity.
That’s it for today; in the next part we’ll discuss First Hop Security features.
We wish all our readers Merry Christmas and a Happy New Year!
Enno