Re: MAC Privacy Protection Protocol Driver Announcement

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Oct 26, 2026 at 10:54:34PM +0000, Smith, Cameron T wrote:
> On Fri, Oct 23, 2026 at 03:00:23AM +0200 Andrew Lunn wrote:
> > So if you use it without MACSEC, you preappend a new header, and send
> > it out. Isn't the inner header than in plain text, making it somewhat
> > pointless?
> 
> Yes. In practice if MAC Privacy data is not encrypted, the changes 
> it's made to traffic can be trivially observed and reversed. However,
> the standard doesn't require encryption or mandate how encryption
> should take place.

What happens in practice? Just because the standard allows you to do
something does not mean we actually need to support it, especially if
it gives a sense of privacy when in fact it does not.

From an architecture perspective, i'm wondering if it should be a thin
sublayer in drivers/net/macsec.c. That then forces you to use it in
the correct way, it does actually give you privacy.

> This flexibility allows the use case where mac
> privacy encryption takes place on another device, such as an 
> Ethernet Data Encryptor. (See 802.1AEdk-2023 Section 21.8)

Does linux support this? And since this is 802.1AE, i assume it is an
extension to MACSEC? So would it be implemented in
drivers/net/macsec.c ?

> > For the timing part, how does this interact with TSN, sk_buff->tstamp
> > TAPRIO and ETF Qdisc? Clearly you want to reuse as much of that as
> > possible.
> 
> I definitely want to reuse as much as possible. MAC Privacy can use
> VLAN tags to indicate priority (See 802.1AEdk-2023 Figure 17-2), but
> I will need to look more closely at this topic.

I suspect this work will split into two parts. You will need TC and
some form of Qdisc, maybe extensions to the existing one, or maybe a
new one. And you need a layer somewhere to do the packet manipulation.

> Adding a MAC Privacy link to an existing Ethernet link named eth0
> without macsec might look like this:
> 
> ip link add link eth0 name macpriv0 type macpriv
> 
> Adding a MAC Privacy link to an existing macsec link named macsec0
> might look like this:
> 
> ip link add link macsec0 name macpriv0 type macpriv

As you can see above, i'm not yet convinced it should be a new device
stacked on top of macsec. Please explore what it would mean if the
packet manipulation part was inside the existing macsec driver. And
the packet scheduling is done via a Qdisc.

    Andrew