I would like to start this question as an open discussion and would like to hear your opinions on it.
Background:
In the good old IPv4 world, it is common for consumers for their home networks to only have one public routable IP Address, if not a private IP address behind CG NAT. This has annoying disadvantages (e.g. if you want to run a server), but it also one big advantage: it offers some kind of privacy and security as your devices are not addressable from the internet and you share one IP Address with many devices.
With IPv6 world changes. If you enable IPv6 in your Home Network, all your devices can have a globally unique routable public IP Address.
This implies some security and privacy considerations. One of them regarding icmp6. I think an attacker could use icmp6 to gather information about the home network topology and active devices in it.
Therefore it may be beneficial to restrict icmp6 message types to only those that are mandatory for IPv6 connectivity, I think these are
On the input chain:
1 (Dest Unreachable)
2 (Packet too big)
3 (Time Exceeded)
4 (Parameter Problem)
Should these Types be allowed on the Input chain? Maybe this is not even necessary when getting PD from ISP via dhcpv6 (?)
(Drop all from WAN with Hop Limit != 255)
133 (Router Solicitation)
134 (Router Advertisement)
135 (Neighbor Solicitation)
136 (Neighbor Advertisement)
On the forward chain:
(Drop all from WAN with Hop Limit = 1)
1 (Dest Unreachable)
2 (Packet too big)
3 (Time Exceeded)
4 (Parameter Problem)
What do you think and feel about this? Is it worth protecting the router and devices in the home network with rules like this?
The Mikrotik Default Configuration just allows icmp6 on input and forward chain. I think there are other mechanics (for example the kernel checks) that will drop certain icmp6 malformed packages. Should we rely on these? Might it be better to have the rules in firewall filters explicitly?
Yes, right, in an internal home network, at best.... with a single /64....
there are only just 2^64 possible values... even if they were "only half"...
how long does it take to do a complete scan of 9,223,372,036,854,775,807 possible IPv6 addresses?
If you scanned 1000 IPv6 addresses per second, it would take 292,471,208 YEARS to complete the scan...
If you scanned 1000000000 IPv6 addresses per second, it would take ~290 YEARS to complete the scan... 84GBps of only ICPMv6...
Ignoring reserved addresses and all the rest,
pinging all the IPv4 addresses in the world while respecting the kernel limit of 100 takes less than a year and a half...
under the same conditions, IPv6 would "only" take about 58,494,241... centuries
Ok, yes, from a brute-force-perspective it makes absolutely no sense to scan an IPv6 /64 subnet, I totally agree.
But sometimes it is not necessary to brute-force the whole address space. Sometimes you already have a target IPv6 Address, for example from third party logs, from p2p connections (gaming, voip, …), from traffic analysis or from a ddns record. Last one could exist for example if you want to connect to your router from the go, which might be a common usecase.
I think there are other attack vectors than simply scanning for hosts in an address space.
Maybe an attacker could try to send malicious RAs or malicious Redirect Messages and so on. Maybe there are some vectors where an attacker does not necessarily need to know a specific target address either.
If I just allow all icmp6 in my firewall, then I have to trust other routers which are not under my control to do their job right and drop malicious messages before they reach my router.
What are you doing? Are you going with just allowing all icmp or do you filter specific types?
In my case, aside from the legal requirements in my country (which I have no intention of writing about, it's off-topic),
I stick to the default rules.
If you have time, you can study RFC4890, especially section 4 and its sub-sections.
You can see that the operating systems already handled many restrictions for you, like ensuring that certain message types are only allowed with link-local addresses, or will never be forwarded. Even your Hop Limit != 255 check is already handled.
You also have the list of message types that must be accepted or should not be dropped, and section with Traffic That Will Be Dropped Anyway -- No Special Attention Needed.
As for the "dangerous" things that you mentioned, router advertisements and redirects: in the default settings, both are not accepted by the router (IP forward enabled, together with the "yes if forwarding disabled" default settings). If not using Point-to-Point then you might have to turn on Accept Router Advertisements, but since 7.21 you can now limit that to only an interface list that you specify, and RouterOS should be able to ignore RA messages on all other interfaces.
In the end, there are only a few experimental or unassigned / undefined message types that are in the Should be dropped category. However, no one are consuming or processing them anyway, and they'll be ignored. Same with the Node Information message types, which will fall under:
It may be possible to disable the service on the node if it is not wanted, in which case these messages will be ignored and no filtering is necessary.
IMHO there is no need to handle the ICMPv6 packets down to the message types, apart from what MikroTik already have in their default defconf firewall rules that @rextended linked above.
Thanks for pointing me to the rfc, that’s really good resource and explains a lot to me.
And also your explanation sounds very reasonable to me, thanks also for that.
So, I conclude from your comments and what I’ve read in the rfc that there should be little to no harm via icmp6 as long as all components behave like they are supposed to.
I don’t know whether I will therefore forgo additional rules, but you’ve given me new perspective to think about it.
