[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200421170249.GA4054840@bistromath.localdomain>
Date: Tue, 21 Apr 2020 19:02:49 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Dmitry Bogdanov <dbogdanov@...vell.com>
Cc: Igor Russkikh <irusskikh@...vell.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Mark Starovoytov <mstarovoitov@...vell.com>,
Antoine Tenart <antoine.tenart@...tlin.com>
Subject: Re: [EXT] Re: [PATCH net 1/2] net: macsec: update SCI upon MAC
address change.
2020-04-20, 09:51:23 +0000, Dmitry Bogdanov wrote:
> Hi Sabrina,
>
> Thanks for the feedback.
> But this patch does not directly related to send_sci parameter.
>
> Any manual change of macsec interface by ip tool will break
> wpa_supplicant work. It's OK, they are not intended to be used
> together.
Are you sure? Before this patch, if you change the MAC address on a
macsec device with "send_sci on", packets can still be encrypted and
decrypted correctly.
> Having a different MAC address on each macsec interface allows to
> make a configuration with several *offloaded* SecY.
If you need to change the MAC address on the macsec device anyway, why
not do that at creation? Then the SCI is already picked:
ip link add link ens3 macsec0 addr 92:23:25:22:bf:bc type macsec
ip macsec show
13: macsec0: [...]
[...]
TXSC: 92232522bfbc0001 on SA 0
> That is to make
> feasible to route the ingress decrypted traffic to the right
> (macsecX /ethX) interface by DST address. And to apply a different
> SecY for the egress packets by SRC address. That is the only option
> for the macsec offload at PHY level when upper layers know nothing
> about macsec.
I see. It would have been nice to have all this information in the
commit message.
I'm concerned about the software implementation, and that patch
is changing its behavior, AFAICT without fixing a bug in it.
--
Sabrina
Powered by blists - more mailing lists