Not talking about ATM, PPP, HDLC, Frame Relay WAN. Ethernet is the new WAN.
Sometimes you need an easy to use encryption, which is just added to a Link between two devices – and you don’t want to invent IPSec-VPNs which at least add complexity to the design.
MACsec solved this problem bringing absolutely transparent encryption, but – since MACsec-Sessions are sent to a „link-local“ ethernet destination address (01-80-c2-00-00-03) they aren’t allowed to be forwarded by any device. A typical „non-dark-fiber“ WAN-Link can’t be encrypted using MACsec.
http://www.ieee802.org/1/files/public/docs2013/ae-seaman-macsec-hops-0213-v02.pdf discussed years ago the elegant technical solution.
Years later these thoughts are moving into production: Cisco invented „WAN MACsec“:
- simply allowing the network-designer to change destination-mac-address and the ethernet-frametype.
This makes it possible for active provider devices to forward MACsec-Sessions through the WAN so the WAN-Customers could create a virtual encrypted link between sites, completely transparent
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/white-paper-c11-737544.html
This example shows the most simple suggestion:
- change the destination-mac from link-local-multicast to broadcast 😉
Router A
key chain KC_WAN macsec key 1 key-string PASSWORD interface GigabitEthernet0/0/0 ip address 10.0.0.1 255.255.255.252 eapol destination-address broadcast mka pre-shared-key key-chain KC_WAN macsec
Router B
key chain KC_WAN macsec key 1 key-string PASSWORD interface GigabitEthernet0/0/0 ip address 10.0.0.2 255.255.255.252 eapol destination-address broadcast mka pre-shared-key key-chain KC_WAN macsec
Might make sense to change the cipher, increase the anti-reply-window etc…