Re: [PATCH net] macsec: Abort MACSec Rx offload datapath when skb is not marked with MACSec metadata

[Rahul Rameshbabu <rrameshbabu@nvidia.com>]

On Wed, 01 Nov, 2023 23:31:33 +0100 Sabrina Dubroca <sd@queasysnail.net> wrote:
> 2023-11-01, 13:02:17 -0700, Rahul Rameshbabu wrote:
>> When MACSec is configured on an outer netdev, traffic received directly
>> through the underlying netdev should not be processed by the MACSec Rx
>> datapath. When using MACSec offload on an outer netdev, traffic with no
>> metadata indicator in the skb is mistakenly considered as MACSec traffic
>> and incorrectly handled in the handle_not_macsec function. Treat skbs with
>> no metadata type as non-MACSec packets rather than assuming they are MACSec
>> packets.
>
> What about the other drivers? mlx5 is the only driver that sets md_dst
> on its macsec skbs, so their offloaded packets just get dropped now?

After taking a deeper look throughout the tree, I realize there are
macsec offloading drivers that do not set md_dst. In this event, we fail
to correctly handle the skb and deliver to the port as you mentioned
previously. Sorry about this miss on my end.

However, I believe that all macsec offload supporting devices run into
the following problem today (including mlx5 devices).

When I configure macsec offload on a device and then vlan on top of the
macsec interface, I become unable to send traffic through the underlying
device.

(can replace mlx5_1 with any ifname of a device that supports macsec offload)

Side 1

  ip link del macsec0
  ip address flush mlx5_1
  ip address add 1.1.1.1/24 dev mlx5_1
  ip link set dev mlx5_1 up
  ip link add link mlx5_1 macsec0 type macsec sci 1 encrypt on
  ip link set dev macsec0 address 00:11:22:33:44:66
  ip macsec offload macsec0 mac
  ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
  ip macsec add macsec0 rx sci 2 on
  ip macsec add macsec0 rx sci 2 sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
  ip address flush macsec0
  ip address add 2.2.2.1/24 dev macsec0
  ip link set dev macsec0 up
  ip link add link macsec0 name macsec_vlan type vlan id 1
  ip link set dev macsec_vlan address 00:11:22:33:44:88
  ip address flush macsec_vlan
  ip address add 3.3.3.1/24 dev macsec_vlan
  ip link set dev macsec_vlan up

Side 2

  ip link del macsec0
  ip address flush mlx5_1
  ip address add 1.1.1.2/24 dev mlx5_1
  ip link set dev mlx5_1 up
  ip link add link mlx5_1 macsec0 type macsec sci 2 encrypt on
  ip link set dev macsec0 address 00:11:22:33:44:77
  ip macsec offload macsec0 mac
  ip macsec add macsec0 tx sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
  ip macsec add macsec0 rx sci 1 on
  ip macsec add macsec0 rx sci 1 sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
  ip address flush macsec0
  ip address add 2.2.2.2/24 dev macsec0
  ip link set dev macsec0 up
  ip link add link macsec0 name macsec_vlan type vlan id 1
  ip link set dev macsec_vlan address 00:11:22:33:44:99
  ip address flush macsec_vlan
  ip address add 3.3.3.2/24 dev macsec_vlan
  ip link set dev macsec_vlan up

Side 1

  ping -I mlx5_1 1.1.1.2
  PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 mlx5_1: 56(84) bytes of data.
  From 1.1.1.1 icmp_seq=1 Destination Host Unreachable
  ping: sendmsg: No route to host
  From 1.1.1.1 icmp_seq=2 Destination Host Unreachable
  From 1.1.1.1 icmp_seq=3 Destination Host Unreachable

I am thinking the solution is a combination of annotating which macsec
devices support md_dst and this patch. However, I am not sure this fix
would be helpful for devices that support macsec offload without
utilizing md_dst information (would still be problematic).

Would be glad to hear any suggestions you may have before sending out a
v2.

Sorry for the late reply. Was away from a trip and wanted to validate
some things before posting back.

--
Thanks,

Rahul Rameshbabu