(Please also refer to this post or to this talk from the Troopers NGI event).

Some of this has already been discussed in RFC 4890 (Recommendations for Filtering ICMPv6 Messages in Firewalls), but that document is from 2007 and things may have changed in the interim.

Let’s start with a quick look at the traffic that might be of interest. I will take a server perspective here, read: which types of IPv6 traffic might have to be accepted by a host/NIC firewall in order to support proper operations? I will discuss the following, with a focus on the implications of filtering them locally:

1. IPv6 Extension Headers
2. ICMPv6 Types 1 - 4
3. Ping
4. Router Advertisements
5. Neighbour Solicitations & Advertisements
6. ICMPv6 Redirects
7. Multicast Listener Discovery protocol (MLD)
8. DHCPv6

I assume a white-list-based filtering approach (“allow known-good stuff and deny the rest“) and will give a respective recommendation for each of those types of traffic.

Extension Headers

To be discussed first as they might show up very early in a filter list (supposing that one is processed sequentially).

In the following (and similar to the remarks in the “Why IPv6 Security Is So Hard – Structural Deficits of IPv6 & Their Implications” talk) the term “IPv6 Extension Headers” denotes the “standard” ones as per RFC 2460 except for Authentication Header (AH) and Encapsulating Security Payload (ESP) — which then leaves Hop-by-Hop (HBH), Routing Header, Fragment Hdr and DestOptions.

There are two main reasons to include them in our discussion and, in one way or another, in the filter list. It’s well known that Extension Headers (EHs) can be abused for nefarious things on the local link. Presumably router advertisements will be allowed later on (see below), and RFC 6980 might provide only limited protection against RA Guard evasion attacks (as laid out here and here), so having an additional layer of security (against EHs) is probably a good idea.

Furthermore, some security products/components might expose a different default stance for filtering EHs (for example, Check Point firewalls filter most of them by default; also see Antonios Atlasis‘ research on several firewall products some years ago) so if you want to deploy a consistent policy you either have to find out the exact behaviour of the filtering component in place or apply a well-defined ruleset yourself.

Last, but not least, it’s worth keeping in mind that packets with EHs with permitted upper layer protocols might not be blocked by a final “default deny“ rule. In case inter-subnet multicast is needed, allowing HBH is probably helpful. You may also want to allow fragmented IPv6 packets and hence the fragment header, but on the other hand this would include allowing fragmented ND/RA packets, which bears quite a few risks (see the above sources on RA Guard evasion).

Recommendation for dealing with EHs:

• Allow AH and ESP in case IPsec is needed towards the host.
• Allow HBH in case MLD is needed (see below).
• Allow fragment header if you consider it is possible that legitimate fragmented packets come in (read this if you’re thinking of DNSSEC). If you do so, consider explicitly denying fragmented RA/ND traffic; this might not be supported configuration-wise and it might be debatable from a rule-set complexity/operational effort perspective.
• Explicitly deny other EHs, namely routing header (type 43) and Destination Options (type 60).

ICMPv6 Types 1 - 4

All of these are diagnostic/error messages and hence are considered vital for the proper functioning of network communications (in particular type 2 [PTB]). For this reason, I recommend allowing (“don’t touch“) them. Besides Black Nurse, which mainly affected network devices/firewalls (has anybody ever tested against host operating systems? I’m not aware of any testing against host OSes but I’m interested in hearing about it if you know), there are not many (publicly known) security issues with these packets.

Recommendation: allow.

Ping

Except for very specific circumstances (tenant isolation in cloud environments comes to mind) you’ll want to allow inbound Ping (Echo Request - ICMPv6 type 128) to a system. For the record, I’m a networking guy, with an operations background and subsequently have always been in the “the operational benefits of Ping are far greater than the real [usually even: perceived] negative security impact“ camp.

Recommendation: allow.

Router Advertisements

From an overall architecture perspective Router Advertisments (RAs) are/can be considered the most important IPv6 packets of all (I mean, they kind of bring life to IPv6 stacks, which is why I occasionally compare sending an RA to a system to “kissing the sleeping beauty”).

I would therefore expect to allow them (past mailing lists used to be full of messages of people who broke their network connectivity by erroneously filtering them) but, strictly speaking, you might not need them in one specific scenario (the “fully static configuration” approach from the server configuration post). Even in such a setup/setting, I recommend extreme care when filtering RAs, given their role in the big IPv6 picture.

Recommendation: allow. In “fully static configuration“ scenarios, you might consider denying/blocking them, but do so only after diligent testing.

Neighbour Solicitations and Advertisements

In most cases, blocking Neighbour Solicitations (NS)/Neighbour Advertisment (NA) packets (on an Ethernet link at least) will break something. As a consequence, you should simply accept/allow them.

In case you’re concerned about Neighbour Discovery Protocol (NDP) spoofing attacks, a local packet filter would be the wrong control anyway (NDP inspection on switch ports comes to mind but has its own set of limitations, and beyond the scope of the current post).

Recommendation: allow.

ICMPv6 Redirects

For many years there have been security discussions around ICMP(v6) redirect messages (ICMPv6 type 137). Strictly speaking, those are packets with a fully valid purpose and maybe even needed in some cases. On the other hand they can easily be abused for malicious purposes (traffic redirection), which is why it’s probably a good idea to block them (from an operational impact vs. associated security risk ratio perspective).

Recommendation: no action needed in a white-list rule set. If really really needed, allow them (ICMPv6 type 137).

MLD

As long as no inter-subnet multicast communication is actually needed/in place, you probably won’t need MLD. This can be expected for the vast majority of networks where the type of filtering we’re discussing here is applied at all. You can subsequently block MLD (as opposed to entirely disabling it, which on Windows breaks ND, but not on Linux; see also this post. Windows is not covered there, I can still confirm through lab testing.)

Recommendation: no action needed in a white-list rule set. If really needed, allow ICMPv6 types 130–132 and maybe 143 (depending on MLD versions in use).

DHCPv6

In case DHCPv6 is involved in parameter provisioning to the systems in question (for learning the DNS resolver[s] or when using the “DHCPv6 with reservations” configuration approach described here) you’ll need (to allow) it. In all other scenarios it won’t be needed.

RFC 3315 states: “Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.“

This means that, from a host/server perspective, inbound UDP 546 is needed (probably the client port of server-side packets is not always deterministic => do not include a source port in the rule).

You may also keep in mind that disabling a local DHCPv6 client might yield unintended results on Windows systems, depending on the method chosen for the task (see this post) so blocking those packets might be the best way of getting rid of DHCPv6 interactions.

Recommendation: no action needed in a white-list rule set. Explicitly allow inbound UDP 546 once a system needs to receive DHCPv6 messages.

As always, I’m happy to receive feedback.

The original post appeared on Insinuator.