Some virtual environments do not allow the forwarding of EAPOL packets. In order to provide for encryption in transit for high security compliance environments, it would be useful to be able to implement MACsec in those cloud environments where MKA is not functional.

While this is not easily scalable, unless possibly through API automation, it would fill a potential gap in capability.

The proposal would be to statically define a TX key, and then define RX peers with MAC address and key. This could maybe be a similar config syntax to that of Wireguard peers.

Linux command line syntax for TX key would be similar to the following:

ip macsec add macsec0 tx sa 0 pn 1 on key <KEY ID> <KEY>

Linux command line syntax for each RX key would be similar to the following:

ip macsec add macsec0 rx port 1 address <PEER MAC ADDRESS> sa 0 pn 1 on key <KEY ID> <KEY>

Configuration for static configuration could potentially be as follows, where either "mka" or "static" must be defined

interfaces {
    macsec macsec0 {
        address 192.168.1.1/24
        security {
            cipher gcm-aes-128
            encrypt
            static {
                tx-key <keyID> <KEY>
                peer <friendly name> {
                    mac-address <MAC ADDRESS>
                    rx-key <keyID> <KEY>
                }
            }
        }
        source-interface eth0
    }
}

Manual key rotation would need to be explored as well, so tx-key and rx-key statements would need to allow for multiple entries I think.