Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may 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 which might be of interest. We 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:
- IPv6 Extension Headers
- ICMPv6 Types 1–4
- Ping
- Router Advertisements
- Neighbor Solicitations & Advertisements
- ICMPv6 Redirects
- MLD
- DHCPv6
We 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 of RFC 2460 except for AH & ESP, which then leaves: HBH, Routing Header, Fragment Hdr, DestOptions.
There’s two main reasons to include them in our discussion and, in one way or another, in the filter list. It’s well known that 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 only provide limited protection against RA Guard evasion attacks (as laid out here and here) so having an additional layer of security (against extension headers) is probably a good idea. Furthermore some security products/components might expose a different default stance as for filtering EHs (e.g. 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 behavior of the filtering component in place or apply a well-defined ruleset yourself.
Last but not least one may keep in mind that packets with EHs but otherwise 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 generally 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 some risks (see the above sources on RA Guard evasion).
Overall this gives the following recommendation:
- Allow AH & ESP in case IPsec is needed towards the host.
- Allow HBH in case MLD is needed (see also below).
- Allow fragment header in case you consider it possible that legitimate fragmented packets come in (thinking of DNS[Sec] you may read this first). If you do so, reflect on explicitly denying fragmented RA/ND traffic but 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 considered vital for the proper functioning of network communications (in particular type 2 [PTB]). We hence recommend to allow (“don’t touch“) them. Besides Black Nurse (which mainly affected network devices/firewalls – has anybody ever tested against host operating systems? We’re not aware of any testing against host OSs… does any of our readers know any stuff?) there’s not many (publicly known) security issues with/of 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 RAs are/can be considered the most important IPv6 packets at all (I mean, they kind-of bring life to IPv6 stacks, which is why I occasionally compare sending an RA to a system with “kissing the sleeping beauty” ;-). We would hence expect to allow them (and in the 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 we recommend to be very careful to filter RAs, given their role in the big IPv6 picture.
Recommendation: allow. In “fully static configuration“ scenario one might deny/block them, but should do so only after diligent testing.
Neighbor Solicitations & Advertisements
In most cases blocking NS/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 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, not to be discussed in the present post).
Recommendation: allow.
ICMPv6 Redirects
Since 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 discuss 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, we 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 also 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 we’re happy to receive feedback from you guys.
Everybody have a great day
Enno
Hi Enno,
thanks for your info. It really helps.
One question regarding MLD: Can you *really* ignore it that way? Isn’t it needed (in theory) for advertising the solicited node multicast address to switches? Or are you assuming that the switches won’t use those MLD message and will “flood ~ broadcast” multicast messages out to all switchports anyway?
Thanks,
Johannes
Hi Johannes,
thanks for the feedback.
Couple of very quick comments/responses. I think there’s some misconception in what you’re writing re: “advertising SNMA to switches”, because
– such a thing would require the switch to “listen” to MLD messages.
– one could say that would be a violation of L2 vs. L3 in itself.
– but, yes, there’s a mechanism which is supposed to do exactly that: MLD snooping.
– MLD snooping is a mess for many reasons (amongst others it creates [potentially a lot of] additional state on devices and we’ve seen cases where it inhibits protocols from working correctly [DHCPv6]).
– that’s why we usually don’t recommend using MLD snooping anyway as long as you don’t *rly* need it (some VoIP scenarios come to mind).
– even if you use it *usually* link-local scope multicast groups are explicitly *excluded* from MLD snooping (for reasons, see above).
– however there’s no “consensus” about the latter (exclude ll-scoped mc addresses from MLD snooping).
– this might be due to the fact that there’s no “standardized way of doing MLD snooping” anyway (MLD snooping is somewhat vendor-proprietary. I suspect because political reasons [switches are considered L2 devices so IEEE responsibility as opposed to IETF taking care of L3 stuff and above]).
– so a switch might behave as you describe or not. in practice most don’t. a decade or so there was some discussion about this (see https://tools.ietf.org/html/draft-pashby-magma-simplify-mld-snooping-00).
tl;dr: it’s a mess. I don’t know a single switch/vendor which does what you describe/expect. MLD snooping sucks; don’t use it unless you rly know what you’re doing & needing and you’ve extensively tested it in your environment.
Cheers,
Enno
Hey Enno. Thanks a lot!
So, what are those “Multicast Listener Report Messages” for when it comes to those solicited node multicast addresses? As far as I understand you: There is no single reason for them, right? Why are all OSes sending them? I can see a lot of those messages on the wire… (E.g., have a look at the second Wireshark screenshot here: https://blog.webernetz.net/basic-ipv6-messages-wireshark-capture/)
To be honest, when talking about solicited node multicast addresses I do not understand those “exclude” or “include” statements within MLD anyway, since those initial reports are sometimes doing the one or the other, depending on the OS.