ffwizard, olsr: validate mesh addresses, filter large HNAs

[pktpls]

Maintainer:
Environment:

Description:

There are a couple of issues with mesh addresses that could be considered invalid.

• Addresses that aren't part of our mesh prefixes, e.g. configuring and announcing 192.168.0.0/24 and similar
• HNAs that are way too big and cause issues when they're added to / removed from the kernel routing table - large route modifications seem to exhaust resources in some way, and might halt route updates altogether. We noticed this with a large /5 announcement a while ago.

Options:

• Let the wizard validate that addresses are within our /16 ranges in 10.0.0.0/8.
• Let OLSR reject HNAs that are larger than /23.

[pmelange]

Since we want the wizard to be usable with other communities (eg potsdam or fuerstenwalde) then limiting the wizard to our /14 and multiple /16 ranges would have to be set in the community profiles. The communities would have to maintain their profiles, or we generate the profiles from https://github.com/freifunk/icvpn-meta (example Berlin https://github.com/freifunk/icvpn-meta/blob/master/berlin). We would have to assume that the communities are keeping this information up-to-date

I use a totally non freifunk-berlin range of IP addresses when I do unit testing. It would be an inconvenience to have to use freifunk-berlin ip addresses, but it also won't be that bad.

About having OLSRd reject HNA's larger than a /23... I think /22 would be better. But where would you want to do this check? In the OpenWrt init script https://github.com/openwrt/routing/blob/master/olsrd/files/olsrd4.init or in the cfgparser code of OLSRd https://github.com/OLSR/olsrd/tree/master/src/cfgparser. In either case, I think this change would not be done at the falter-packages level.

[pktpls]

Thanks, good points.

Since we want the wizard to be usable with other communities

It could also allow something larger like 10.0.0.0/8 to cover all communities, although I'm not sure if someone's still using 104.0.0.0/8.

I'm basically just worrying about someone announcing subsets of the default route which aren't equal to the default route and thus harder to spot. E.g. announce (= hijack) only Gmail prefixes and fly under the radar because it's just another /24.

About having OLSRd reject HNA's larger than a /23... I think /22 would be better

Sure /22 works too

But where would you want to do this check?

Yep it'd probably have to be in OLSR. Another option would be routing table masking (i.e. have a second table that "masks" the actual OLSR kernel table) but I don't know if that's an actual thing.