netdev - Re: [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230809160945.386168f9@kernel.org>
Date: Wed, 9 Aug 2023 16:09:45 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jason Gunthorpe <jgg@...dia.com>, Leon Romanovsky <leonro@...dia.com>,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, linux-rdma@...r.kernel.org, Maor Gottlieb
 <maorg@...dia.com>, Mark Zhang <markzhang@...dia.com>,
 netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>, Patrisious Haddad
 <phaddad@...dia.com>, Raed Salem <raeds@...dia.com>, Saeed Mahameed
 <saeedm@...dia.com>, Simon Horman <horms@...nel.org>
Subject: Re: [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support

On Wed,  9 Aug 2023 11:29:12 +0300 Leon Romanovsky wrote:
> This series extends previously added MACsec offload support
> to cover RoCE traffic either.
> 
> In order to achieve that, we need configure MACsec with offload between
> the two endpoints, like below:
> 
> REMOTE_MAC=10:70:fd:43:71:c0
> 
> * ip addr add 1.1.1.1/16 dev eth2
> * ip link set dev eth2 up
> * ip link add link eth2 macsec0 type macsec encrypt on
> * ip macsec offload macsec0 mac
> * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
> * ip macsec add macsec0 rx port 1 address $REMOTE_MAC
> * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5
> * ip addr add 10.1.0.1/16 dev macsec0
> * ip link set dev macsec0 up
> 
> And in a similar manner on the other machine, while noting the keys order
> would be reversed and the MAC address of the other machine.
> 
> RDMA traffic is separated through relevant GID entries and in case of IP ambiguity
> issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we
> disable our physical GID in order to force the user to only use the MACsec GID.

Can you explain why you need special code to handle this?
MACsec is L2, RDMA is L4.