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

From: Igor Russkikh <irusskikh@marvell.com>
To: Antoine Tenart <antoine.tenart@bootlin.com>
Cc: "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 08:12:31 +0000	[thread overview]
Message-ID: <BYAPR18MB2630CB1BE0BCD0878612F86BB7EA0@BYAPR18MB2630.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20200221145751.GA3530@kwain>

> Hello Igor,
> 
> Thanks for sending this series!
> 
> Please Cc Sabrina Dubroca <sd@queasysnail.net> (the IEEE 802.1AE driver
> author) on such series.
> 
> Antoine

Hi Antoine, thanks for reviewing this, your comments are all correct, will respin.

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.

Regards,
  Igor