Re: MAC Privacy Protection Protocol Driver Announcement

[Andrew Lunn <andrew@lunn.ch>]

On Thu, Oct 22, 2026 at 10:55:59PM +0000, Smith, Cameron T wrote:
> Hi Andrew,
> 
> Thanks for the recommendation to include Sabrina Dubroca.
> 
> On 10/21/26, 12:10, "Andrew Lunn" <andrew@lunn.ch <mailto:andrew@lunn.ch>> wrote:
> > So this is part of macsec?
> 
> Yes and no. It's standardized by IEEE as an amendment to 802.1AE and 
> intended for use with MACsec. However, it's defined as a separate protocol 
> with a dedicated ethertype, and the specification allows it to be used 
> without MACsec. 

I spent maybe 10 minutes looking at standard, so i've not got a good
understanding of it, so maybe i'm asking dumb questions.

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?

> > Lets start with architecture. How does this interactive with macsec?
> > Is it a layer on top? Is it integrated into the existing macsec
> > driver? Is it layered below? Are there devices which support 802.1AEdk
> > in hardware? There are PHYs which can do macsec and there is an API to
> > perform this offload. Do we need to extend this API?
> 
> When used with MACsec, each MAC Privacy protection Protocol Data Unit
> (MPPDU) is placed within the payload of a MACsec data unit. Also, as 
> mentioned above, use of MACsec is not required, and one could use another 
> protocol, such as Ethernet, instead. Because of this, I think it makes 
> sense to implement MAC Privacy as a separate driver from MACsec. 

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.

> To my knowledge there are not currently any devices which support 802.1AEdk
> in hardware. Implementing MAC Privacy as a separate driver means
> hardware offload for MACsec can be used without changes while allowing
> Linux to perform MAC Privacy.

But we need a path for when MAC privacy is in hardware. However, is
that actually possible? The encapsulation to hide the MAC addresses
and perform padding should be possible, but what about the timing
part? Can that be offloaded? I guess not in a PHY, but a MAC
implementation would be possible, it pulling packets out of a queue at
a given rate, adding the extra header and padding, and then putting it
on the wire.

What does you user configuration API look like? Can you give us
examples of what you think iproute2 would look like, both with it
stacked on macsec, and directly on top of Ethernet. And what tc
commands are required.

   Andrew