[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR18MB235709AA95C28FAD4C6C39C2A4D40@BYAPR18MB2357.namprd18.prod.outlook.com>
Date: Mon, 20 Apr 2020 09:51:23 +0000
From: Dmitry Bogdanov <dbogdanov@...vell.com>
To: Sabrina Dubroca <sd@...asysnail.net>,
Igor Russkikh <irusskikh@...vell.com>
CC: "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.
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.
Having a different MAC address on each macsec interface allows to make a configuration with several *offloaded* SecY. 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.
BR,
Dmitry
-----Original Message-----
From: Sabrina Dubroca <sd@...asysnail.net>
Sent: Friday, April 17, 2020 12:06 PM
To: Igor Russkikh <irusskikh@...vell.com>
Cc: netdev@...r.kernel.org; Mark Starovoytov <mstarovoitov@...vell.com>; Antoine Tenart <antoine.tenart@...tlin.com>; Dmitry Bogdanov <dbogdanov@...vell.com>
Subject: [EXT] Re: [PATCH net 1/2] net: macsec: update SCI upon MAC address change.
External Email
----------------------------------------------------------------------
Hello,
2020-03-10, 18:22:24 +0300, Igor Russkikh wrote:
> From: Dmitry Bogdanov <dbogdanov@...vell.com>
>
> SCI should be updated, because it contains MAC in its first 6 octets.
Sorry for catching this so late. I don't think this change is correct.
Changing the SCI means wpa_supplicant (or whatever MKA you're using) will disagree as to which SCI is in use. The peer probably doesn't have an RXSC for the new SCI either, so the packets will be dropped anyway.
Plus, if you're using "send_sci on", there's no real reason to change the SCI, since it's also in the packet, and may or may not have any relationship to the MAC address of the device.
I'm guessing the issue you're trying to solve is that in the "send_sci off" case, macsec_encrypt() will use the SCI stored in the secy, but the receiver will construct the SCI based on the source MAC address. Can you confirm that? If that's the real problem, I have a couple of ideas to solve it.
Thanks, and sorry again for the delay in looking at this,
--
Sabrina
Powered by blists - more mailing lists