Re: [B.A.T.M.A.N.] [PATCH] batman-adv: introduce "noflood" broadcast flood prevention option

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 5446 bytes --]

On Friday, 26 April 2019 19:12:31 CEST Linus Lüssing wrote:
> With DAT DHCP snooping, the gateway feature and multicast optimizations
> in place in some scenarios broadcast flooding might not be strictly
> necessary anymore to be able to establish IPv4/IPv6 communication.
> Therefore this patch adds an option to disable broadcast flooding.
> 
> Larger mesh networks typically filter a variety of multicast packets via
> ebtables/netfilter to clamp on overhead. With this option such firewall
> rules can be relaxed so that such multicast packets are only dropped
> if they cannot be handled by multicast-to-unicast, for instance.
> 
> "noflood" comes in two flavours: If set to 1 then flood prevention is
> enabled for all multicast/broadcast packets except ICMPv6 and IGMP
> (cautious mode). Or, if set to 2 then flood prevention is enabled for
> all multicast/broadcast packets (aggressive mode). If set to 0 then
> flood prevention is disabled.
> 
> "noflood" is disabled by default as there are still some things to take
> care of to avoid breaking things (especially for the "aggressive mode").
> 
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
> 
> ---
> The initial approach was a "noflood"-mark which worked similar to the
> isolation mark. Which allowed more flexibility so that the user could
> mark specific packets to be excluded from broadcast flooding via
> ebtables/netfilter. However, in practice skb-marking is not that easy to
> configure and if misconfigured will break a network horribly. Which was
> also a downside noted and discussed at BattleMesh v11.
> 
> This version now is a less flexible but therefore also simpler to use
> variant.

It looks like this is an option which can break the mesh rather easily. Here 
some quotes from 2019-04-30/2019-05-01:

<marec> even the 'cautious' option drops everything except for IGMP and ICMPv6
<marec> nobody has a clear picture what that $everything is
<marec> how does it help you if IGMP and ICMPv6 go through if all other multicast / broadcast is dropped ?
<marec> (because of too many mesh participants with multicast optimizations disabled)
<T_X> with IGMP/ICMPv6 to always go through I hope we have the most basic things for IP-IP communication covered and unsucceptible to DoS cases you have already outlined
<marec> T_X: how so ?
<marec> T_X: even considering your gluon case - how many nodes would you need to update and have to enable mcast optimization to safely turn on noflood ?
<marec> as I recall, your meshes are all bridged together over vpns
<marec> with only 16 nodes not upgraded or mcast optimization disabled noflood will be permanently active
<marec> (or whatever your fanout value is)

<T_X> so even if no node were having the multicast optimizations enabled, then communication both on the intranet and to the internet would still work
<marec> that was not my point
<marec> I want to allow people to experiment with and use multicast in a variety of undefined applications. <<< how do you want to get there ?
<marec> while noflood drops everything
<marec> (except for maybe IGMP and ICMPv6)
<T_X> ah. yes. in that case, such applications would not / would stop working. but that's our current default case with basically filtering all/most multicast traffic except ICMPv6 via ebtables in Gluon

<marec> even standard DAT falls back to flooding, isn't it ?
<T_X> marec: yep
<marec> so, ARP does not work with noflood ?
<T_X> if no ARP response in x milliseconds (250ms I think?) then it will flood the ARP request
<T_X> marec: right


<marec> sounds to me the noflood will be pretty difficult to understand and debug
<marec> how does a normal user understand when ARP works sometimes .. or even normal mcast apps work sometimes ?
<marec> how will that seeming randomness be distinguishable from normal packet loss ?
<T_X> yes. would at least need some thorough wiki page, I guess. *cough* :)
<marec> I am talking about user outside the gluon garden
<marec> sorry for pointing it out again but this noflood feature still feels like a gluon tailored solution - assuming auto-updaters, mcast enabled, no IPv4 or other things other than IPv6 with router advertisements


<ordex> my opinion is that I agree with T_X when he says "just add this patch to the Gluon repository for now"
<ordex> honestly, skb-marking is much better imho. way less prone to mesh-explosions and people (that have a thorough understanding of ARP, ICMPv6, IGMP, MLD and understand what batman-adv would do or not) can decide how to treat such packets *externally* to batman-adv
<ordex> this is what how we use the client-isolation with skb-marking - the dropping logic is implemented outside
<ordex> with a match on the skb-mark
<T_X> ok. and both the client-isolation and noflood skb->markings would fullfil a kind of similar purpose - that is preventing specific packets from reaching $destination, which could not be fullfilled with netfilter alone, right?
[...]
<ordex> the reason for the skb-marking is to have something to match packets against. In the client isolation case the knowledge about what to drop was inside batman-adv, thus we needed a way to "export" this knowledge



I would guess that you can also do something like this using ebtables + tc 
filter. Even with (tc) eBPF... since eBPF seems to be the miracle solution 
for everything these days.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]