linux-kernel - Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a4cfc6246f621d006af69d4d1f61ed1@kapio-technology.com>
Date:   Fri, 12 Aug 2022 14:29:48 +0200
From:   netdev@...io-technology.com
To:     Ido Schimmel <idosch@...dia.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
        Ivan Vecera <ivecera@...hat.com>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Shuah Khan <shuah@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry
 flag to drivers

On 2022-08-11 13:28, Ido Schimmel wrote:

>> > I'm talking about roaming, not forwarding. Let's say you have a locked
>> > entry with MAC X pointing to port Y. Now you get a packet with SMAC X
>> > from port Z which is unlocked. Will the FDB entry roam to port Z? I
>> > think it should, but at least in current implementation it seems that
>> > the "locked" flag will not be reset and having locked entries pointing
>> > to an unlocked port looks like a bug.
>> >
>> 

In general I have been thinking that the said setup is a network 
configuration error as I was arguing in an earlier conversation with 
Vladimir. In this setup we must remember that SMAC X becomes DMAC X in 
the return traffic on the open port. But the question arises to me why 
MAC X would be behind the locked port without getting authed while being 
behind an open port too?
In a real life setup, I don't think you would want random hosts behind a 
locked port in the MAB case, but only the hosts you will let through. 
Other hosts should be regarded as intruders.

If we are talking about a station move, then the locked entry will age 
out and MAC X will function normally on the open port after the timeout, 
which was a case that was taken up in earlier discussions.

But I will anyhow do some testing with this 'edge case' (of being behind 
both a locked and an unlocked port) if I may call it so, and see to that 
the offloaded and non-offloaded cases correspond to each other, and will 
work satisfactory.

I think it will be good to have a flag to enable the mac-auth/MAB 
feature, and I suggest just calling the flag 'mab', as it is short.

Otherwise I don't see any major issues with the whole feature as it is.