gluon-ebtables-filter-multicast: drop icmpv6 echo-requests to all-nodes & all-routers

[ohrensessel]

in a layer 2 mesh network, pings to ff02::1 (all-nodes) and ff02::2 (all-routers) cause a lot of traffic in the network, significantly increasing the 'background noise' (= Grundrauschen) and stressing nodes in the network.

picture shows increased background noise (peaks on the right) in the network (~850 nodes, 1500 clients at that moment) generated by pings to ff02::1.

a solution would be the switch to a layer 3 mesh, but this is not a possible short-term change.

@T-X stated, that there should be no problems by blocking this: "ja, denke, ICMPv6 echo-req. nach ff02::1 und ff02::2 sollte man blockieren. habe noch keinen RFC gefunden, der damit probleme hätte"

[ohrensessel]

I can confirm that no echo-requests come through when ping6 -I br-client ff02::1 is executed on a node with the suggested ebtables rules in place. Will test with a client associated to such a node soon.

[ohrensessel]

just tested the rule when pinging ff02::1 from a client. while rule is active: no echo-requests reach the gateway and there are no responses except from local mesh nodes. while rule is inactive: normal behaviour, request visible on gateways and a lot of responses coming in.

do you need any other information?

[jplitza]

Is this intended to avoid accidental DoS of the network or to prevent malicious attacks? Because regarding the latter, this is by far not enough. Just a quick look into the manpage of ping6 told me about the -N option, which sends other ICMP types but provokes replies too.

[ohrensessel]

the '-N' option sends a ping to a specific solicited-node multicast address, which is for example used for neighbour discovery. such an address is generated from the lower 24 bits of an IPv6 address, thus leading to a lot less hosts answering to echo-requests than with ff02:1 addressing all nodes.

from time to time we are having clients in hamburg that ping ff02:1 and by that harming the network: gateways get overloaded. this pr should solve that problem while not breaking anything.

[jplitza]

No, the -N Node Information Queries can still be sent to ff02::1, and I get answers from like 50 Apple devices. And this was only intended as an example, there are surely other things we can send to ff02::1 to provoke a storm of answers.

[ohrensessel]

ah yes, you are right. sorry. in Hamburg I get replies from 195 apple devices when using '-N name' on ff02::1.

so this pr reduces the scope of possible DoS possibilities. we will never be able to block everything harmful. it was just inspired by experiences from the network in Hamburg.

[neocturne]

As long as we use a layer 2 mesh, we don't even need to start to try blocking malicious DoS...

Some more thoughts:

• Do we only want to drop echos for ff02::1 and ff02::2, or all multicast echos?
• We should at least block the node information queries as well. The ICMPv6 codes 128 to 255 are different kinds of informational messages. Some are essential, others not so much... maybe we want to maintain a whilelist rather than a blacklist here for multicast packets?

[ohrensessel]

• some multicast echo-requests are needed for neighbour detection, aren't they?
• not all of these informational messages have such a big impact on the network I guess. node information queries (code 139) we really should block I guess. for the others, it's hard for me to decide which to whitelist and which not.

[tcatm]

I believe a multicast whitelist that allows for ND may be good solution. Care should be taken not to block any multicasts originating from the node itself though as protocols like alfred, ripng or babel (ontop of batman-adv) require multicast.

[ohrensessel]

• regarding blocking echo-requests to 255.255.255.255: ebtables doesn't offer a possibility to filter vor ICMPv4 codes, or does it? Blocking ICMP to 255.255.255.255, I'm not sure if that breaks something?
• regarding the whitelist: I will work on that soon.

[T-X]

Regarding what this PR should solve:

• Of course, the extra peak in the picture isn't desirable. But I don't see yet how a +30% increase can be used to harm the overall network.
• It solves an easy DoS possibility on a local node, the one where requests are sent from, though. That's the node which will be overwhelmed by responses. (of course there are many more local DoS possibilities, including radio jammers)
• ff02::1/ff02::2 could theoretically be used to harm the overall network, e.g. if combined with fake source addresses

So I agree, ICMPv6 echo-requests to these two addresses should be blocked.

As far as I can tell, other multicast destinations for ICMPv6 echo requests can't be utilized in the same way (that is generating a reply storm). For now, I would therefore opt for not overblocking ICMPv6 echo requests to other destinations as long as they aren't a problem. I'd also like to use them for debugging and development purposes.

Regarding echo-requests to 255.255.255.255: I think we are already blocking any broadcasts to FF:FF:... as long as it's not ARP.

Regarding IPv6 node information queries: Yes, if it generates a similar response storm when used with ff02::1/ff02::2 then it should be blocked too. I haven't heard of this RFC4620 before so I don't know whether something specific is using this. The RFC states that it's for debugging purposes and that it's an experimental RFC, so I guess blocking in a way similar to echo-requests should be fine.

Maybe another PR could be made for RFC4620. This PR looks good to me.

[ohrensessel]

• regarding the extra peak mentioned by you: in the graph shown by me, there are multiple peaks visible, all coming from pings to ff02::1. during that time, fastd on the gateway to which the node is attached that is the source of the echo-request (or has the client associated that produces theses) is overloaded for some seconds (100% cpu load). so there is an effect on the network.
• pinging 255.255.255.255 is currently possible.

[T-X]

Ok, right, multicast ping is allowed by 110-mcast-allow-icmp. I think that one can simply be removed. (unless someone remembers a specific protocol this rule fixes)

[neocturne]

I think I'm in favour of a blacklist after all, as a whitelist might also block new ICMPv6 codes that aren't specified at the moment.

Can we agree on the following additions to the blacklist (or removals from the whitelist in the IPv4 case)?

• All multicast ICMP (v4)
• Multicast ICMPv6 echos
• Multicast ICMPv6 node information queries

I think it would make sense to block these packet types for all multicast destinations, not just ff02::1 and ff02::2, but I guess those two are the most important ones.

[T-X]

Ok, great, the blacklist part :). For filtering only ff02::1+ff02::2 or all multicast for the according types, I changed my mind, too. I'm okay with the latter. if I'd need solicited multicast addresses for debugging, I can usually simply, temporarily disable the according rule on my own test router anyway.

I don't quite understand why ICMPv4 is treated differently, but I don't feel stongly about the tedious ways of doing multicast in IPv4 anyway. (So no objection, but still curious about the reasoning :) )

[neocturne]

I think we treat ICMPv4 differently because there are no essential multicast/broadcast ICMPv4 messages (IGMP is a separate protocol for IPv4), while ICMPv6 has tons of subtypes that use multicast and are essential for the functioning of IPv6 (RA/RS, ND, MLD, ...).

[neocturne]

@tcatm mentioned to me that he'd like to keep the node information requests, but I'd like to blacklist those as well. In a large mesh, there might well be hundreds of Apple devices answering such a request... Can we get a concensus on this?

[ohrensessel]

I don't care about the node information requests. (I don't see any possible application here.)

What did we agree on? Should I alter my pr?

[neocturne]

@ohrensessel, I interpret @T-X's last post as agreement, and @tcatm mentioned in IRC that he doesn't care too much about this issue... so I guess we can go with my last suggestion?

[neocturne]

@ohrensessel, okay, no disagreement for more than a week, please update your PR.