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

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-prev] [day] [month] [year] [list]

Message-ID: <20200226155010.GC3190@kwain>
Date:   Wed, 26 Feb 2020 16:50:10 +0100
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     Igor Russkikh <irusskikh@...vell.com>
Cc:     Antoine Tenart <antoine.tenart@...tlin.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Mark Starovoytov <mstarovoitov@...vell.com>,
        Dmitry Bogdanov <dbogdanov@...vell.com>,
        "sd@...asysnail.net" <sd@...asysnail.net>
Subject: Re: [EXT] Re: [RFC 00/18] net: atlantic: MACSec support for AQC
 devices

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