Re: [EXT] Re: [RFC 00/18] net: atlantic: MACSec support for AQC devices

From: Antoine Tenart <antoine.tenart@bootlin.com>
To: Igor Russkikh <irusskikh@marvell.com>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Mark Starovoytov <mstarovoitov@marvell.com>,
	Dmitry Bogdanov <dbogdanov@marvell.com>,
	"sd@queasysnail.net" <sd@queasysnail.net>
Subject: Re: [EXT] Re: [RFC 00/18] net: atlantic: MACSec support for AQC devices
Date: Wed, 26 Feb 2020 16:50:10 +0100	[thread overview]
Message-ID: <20200226155010.GC3190@kwain> (raw)
In-Reply-To: <BYAPR18MB2630CB1BE0BCD0878612F86BB7EA0@BYAPR18MB2630.namprd18.prod.outlook.com>

Hello Igor,

On Wed, Feb 26, 2020 at 08:12:31AM +0000, Igor Russkikh wrote:
> 
> I'd also like to stress on the following patch:
> 
> > > 1) patch 0008:
> > >   multicast/broadcast when offloading is needed to handle ARP requests,
> > >   because they have broadcast destination address;
> > >   With this patch we also match and encrypt/decrypt packets between
> > macsec
> > >   hw and realdev based on device's mac address.
> > >   This potentially can be used to support multiple macsec offloaded
> > interfaces
> > >   on top of one realdev.
> > >   On some environments however this could lead to problems, e.g. bridge
> > over
> > >   macsec configuration will expect packets with unknown src MAC
> > >   should come through macsec.
> > >   The patch is questionable, we've used it because our current hw setup
> > and
> > >   requirements assumes decryption is only done based on mac address
> > match.
> > >   This could be changed by encrypting/decripting all the traffic (except
> > control).
> 
> We now basically see two different approaches on macsec traffic
> routing between the devices.
> 
> If HW supports per mac decryption rules, this could be used to
> implement multiple secy channels, all offloaded.  But macsec code then
> should use dst MAC to route decrypted packets to the correct macsec
> device.
> 
> Another usecase we have to support in our system is having a bridge
> device on top of macsec device. To support this we had to
> encrypt/decrypt all the traffic against the single macsec dev (i.e.
> unconditionally, without mac addr filtering).
> And this imposes a limitation of having only a single secy.
> 
> Internally, we now separate these usecases basically by private module
> param (not in this patchset).
> 
> But it'd be good to hear from you and possibly other users if these
> are legitimate configurations and if this somehow should be supported
> in the offloading API.

I thought about those two use cases, and would be interested in having
more than a single secy per interface as well. I also came up with the
idea of using the dst MAC address to differentiate virtual interfaces
but as this would not work in some setups I decided not to implement it
at the time.

I don't have a good answer for this for now, except that having a
limitation in the upstream kernel is probably better than having known
non-working setups. But I would be interested in a solution for this :)

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com