On Wed, Aug 09, 2023 at 04:09:45PM -0700, Jakub Kicinski wrote: > 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. It is similar in concept to how TCP validates the 5 tuple, and optionally Rx netdev of every packet. The RDMA Rx layer uses a hardware handle for the entire L2/L3 path called the 'GID Index'. It has the interface IP, VLAN information and so on. Logically for MACSEC the 'GID Index' should include the L2 MADSEC association too. For security, at the L4 layer, the RDMA engines enforce that queues can only process packets that are matching the correct 'GID Index'. Ie you cannot Rx a packet on VLAN 10 and have it be delivered to a queue that thinks it is working on VLAN 11. Or Rx on IP A to a queue working on IP B. Same basic principle for MADSEC, rx unencrypted/wrong SA cannot be delivered to a queue that is expecting a certain SA. This HW generation is not able to directly associate the MADSEC L2 information with the GID index. Thus we cannot create distinct GID Indexes for the same IP, same VLAN but differing in MADSEC. Thus if there is an attempt to create two identical GID indexes the driver will prioritize the encrypted one under the idea that is the more secure option in case of misconfiguration. Jason
