Linux Ethernet Bridging - Mar 2022 - [Bridge] [PATCH v2 net-next 2/4] net: switchdev: add support for offloading of fdb locked flag

On fre, mar 25, 2022 at 16:00, Vladimir Oltean <olteanv at gmail.com>
wrote:
> On Fri, Mar 25, 2022 at 02:48:36PM +0100, Hans Schultz wrote:
>> > If you'd cache the locked ATU entry in the mv88e6xxx driver,
and you'd
>> > notify switchdev only if the entry is new to the cache, then
you'd
>> > actually still achieve something major. Yes, the bridge FDB will
contain
>> > locked FDB entries that aren't in the ATU. But that's
because your
>> > printer has been silent for X seconds. The policy for the printer
still
>> > hasn't changed, as far as the mv88e6xxx, or bridge, software
drivers are
>> > concerned. If the unauthorized printer says something again after
the
>> > locked ATU entry expires, the mv88e6xxx driver will find its MAC
SA
>> > in the cache of denied addresses, and reload the ATU. What this
>> > achieves
>> 
>> The driver will in this case just trigger a new miss violation and add
>> the entry again I think.
>> The problem with all this is that a malicious attack that spams the
>> switch with random mac addresses will be able to DOS the device as any
>> handling of the fdb will be too resource demanding. That is why it is
>> needed to remove those fdb entries after a time out, which dynamic
>> entries would serve.
>
> An attacker sweeping through the 2^47 source MAC address range is a
> problem regardless of the implementations proposed so far, no?
The idea is to have a count on the number of locked entries in both the
ATU and the FDB, so that a limit on entries can be enforced.
> If unlimited growth of the mv88e6xxx locked ATU entry cache is a
> concern (which it is), we could limit its size, and when we purge a
> cached entry in software is also when we could emit a
> SWITCHDEV_FDB_DEL_TO_BRIDGE for it, right?
I think the best would be dynamic entries in both the ATU and the FDB
for locked entries. How the two are kept in sync is another question,
but if there is a switchcore, it will be the 'master', so I don't
think
the bridge module will need to tell the switchcore to remove entries in
that case. Or?

On Fri, Mar 25, 2022 at 05:01:59PM +0100, Hans Schultz
wrote:
> > An attacker sweeping through the 2^47 source MAC address range is a
> > problem regardless of the implementations proposed so far, no?
> 
> The idea is to have a count on the number of locked entries in both the
> ATU and the FDB, so that a limit on entries can be enforced.
I can agree with that.

Note that as far as I understand regular 802.1X, these locked FDB
entries are just bloatware if you don't need MAC authentication bypass,
because the source port is already locked, so it drops all traffic from
an unknown MAC SA except for the link-local packets necessary to run
EAPOL, which are trapped to the CPU.

So maybe user space should opt into the MAC authentication bypass
process, really, since that requires secure CPU-assisted learning, and
regular 802.1X doesn't. It's a real additional burden that shouldn't
be
ignored or enabled by default.
> > If unlimited growth of the mv88e6xxx locked ATU entry cache is a
> > concern (which it is), we could limit its size, and when we purge a
> > cached entry in software is also when we could emit a
> > SWITCHDEV_FDB_DEL_TO_BRIDGE for it, right?
> 
> I think the best would be dynamic entries in both the ATU and the FDB
> for locked entries.
Making locked (DPV=0) ATU entries be dynamic (age out) makes sense.
Since you set the IgnoreWrongData for source ports, you suppress ATU
interrupts for this MAC SA, which in turn means that a station which is
unauthorized on port A can never redeem itself when it migrates to port B,
for which it does have an authorization, since software never receives
any notice that it has moved to a new port.

But making the locked bridge FDB entry be dynamic, why does it matter?
I'm not seeing this through. To denote that it can migrate, or to denote
that it can age out? These locked FDB entries are 'extern_learn', so
they aren't aged out by the bridge anyway, they are aged out by whomever
added them => in our case the SWITCHDEV_FDB_DEL_TO_BRIDGE that I mentioned.
> How the two are kept in sync is another question, but if there is a
> switchcore, it will be the 'master', so I don't think the
bridge
> module will need to tell the switchcore to remove entries in that
> case. Or?
The bridge will certainly not *need* to tell the switch to delete a
locked FDB entry, but it certainly *can* (and this is in fact part of
the authorization process, replace an ATU entry with DPV=0 with an ATU
entry with DPV=BIT(port)).

I feel as if I'm missing the essence of your reply.