MAC Privacy Protection Protocol Driver Announcement

MAC Privacy Protection Protocol Driver Announcement

[Smith, Cameron T]

Hello networking and Rust maintainers,

I'm working on a Rust network driver for MAC Privacy Protection protocol (IEEE 802.1AEdk). There are a number of Rust abstractions within the `net` subsystem which need to be added to make this possible. These abstractions will need to be in place before my driver can be upstreamed, but will also be helpful for anyone else implementing network drivers in Rust. I intend to submit new abstractions in several chunks to prevent patch series from being too large and to submit patches to `net-next`. I understand that it may also be helpful to submit an RFC patch series which includes the driver and the abstractions to provide some context for the abstractions. This will be my first contribution, so I'm still trying to understand the process. Please let me know if this is not the optimal approach or if there is anything else I should know before submitting my first patch series.

Thank you for your time,

~ Cameron Smith

On Wed, Oct 21, 2026 at 06:33:58PM +0000, Smith, Cameron T wrote:
> Hello networking and Rust maintainers,
>
> I'm working on a Rust network driver for MAC Privacy Protection protocol (IEEE
> 802.1AEdk).

Hi Cameron

[Goes and looks at 802.1AEdk]

  Abstract: This amendment specifies a MAC Privacy protection
  encapsulating protocol and its use in conjunction with the MAC
  Security protocol (MACsec) to hide the source and destination MAC
  addresses of user data frames, and to reduce any correlation between
  observable frame sizes and transmission timing. This helps to
  protect user and application identities and to hide the purpose and
  content of communications. Management of MACsec and privacy
  protection is supported by YANG models and SNMP MIBs. Privacy
  considerations for bridged networks are reviewed.

So this is part of macsec?

You probably want to include Sabrina Dubroca <sd@queasysnail.net> in
the discussion, the macsec maintainer.

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?

We should first make sure the architecture is correct. There is no
point discussion rust abstractions until the basic design is correct.

        Andrew

Re: MAC Privacy Protection Protocol Driver Announcement

[Jakub Kicinski]

On Thu, 22 Oct 2026 21:11:33 +0000 Smith, Cameron T wrote:
> I'm working on a Rust network driver for MAC Privacy Protection
> protocol (IEEE 802.1AEdk). There are a number of Rust abstractions
> within the `net` subsystem which need to be added to make this
> possible. These abstractions will need to be in place before my
> driver can be upstreamed, but will also be helpful for anyone else
> implementing network drivers in Rust.

I'm assuming you're writing it using an LLM, so I'd strongly prefer
if you just wrote it in C instead of adding a huge additional work
for maintainers of thinking thru Rust abstractions for datapath
drivers while we are overloaded with all the LLM fixes.

Re: MAC Privacy Protection Protocol Driver Announcement

[Andrew Lunn]

On Wed, Oct 21, 2026 at 06:33:58PM +0000, Smith, Cameron T wrote:
> Hello networking and Rust maintainers,
> 
> I'm working on a Rust network driver for MAC Privacy Protection protocol (IEEE
> 802.1AEdk).

Hi Cameron

[Goes and looks at 802.1AEdk]

  Abstract: This amendment specifies a MAC Privacy protection
  encapsulating protocol and its use in conjunction with the MAC
  Security protocol (MACsec) to hide the source and destination MAC
  addresses of user data frames, and to reduce any correlation between
  observable frame sizes and transmission timing. This helps to
  protect user and application identities and to hide the purpose and
  content of communications. Management of MACsec and privacy
  protection is supported by YANG models and SNMP MIBs. Privacy
  considerations for bridged networks are reviewed.

So this is part of macsec?

You probably want to include Sabrina Dubroca <sd@queasysnail.net> in
the discussion, the macsec maintainer.

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?

We should first make sure the architecture is correct. There is no
point discussion rust abstractions until the basic design is correct.

	Andrew

Re: MAC Privacy Protection Protocol Driver Announcement

[Smith, Cameron T]

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. 

> 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. 

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.

~ Cameron

Re: MAC Privacy Protection Protocol Driver Announcement

[Andrew Lunn]

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

Re: MAC Privacy Protection Protocol Driver Announcement

[Smith, Cameron T]

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. 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)

> 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.

> But we need a path for when MAC privacy is in hardware. However, is
> that actually possible?

That's not my area of expertise, so I'm open to suggestions. For what
it's worth, I've been in contact with multiple hardware vendors who 
have stated they would like to see a software implementation of MAC 
Privacy in Linux prior to starting development of their own
implementations.

> 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.

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

We'd also likely add a new macpriv subcommand to like the existing
one for macsec which could be used for configuration. It would have a
set sub command for MAC Privacy-specific settings and a show command 
to print MAC Privacy specific settings. For example:

ip macpriv set macpriv0 up 0 pt pre rde on pad 32 ap 0
ip macpriv show

I don't yet know which tc commands would be required.

~ Cameron

Re: MAC Privacy Protection Protocol Driver Announcement

[Andrew Lunn]

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