MACsec over l2circuit
In two older posts, Media Access Control Security(MACsec IEEE 802.1AE) – static secure association keys and Media Access Control Security(MACsec IEEE 802.1AE) – static connectivity association key
we saw how you can configure MACsec on EX4550 switches.
In both examples, the two devices where MACsec was configured were directly connected.
But what happens when you want to protect your traffic using MACsec and that traffic has to go over a service provider’s network? Your devices will not be directly connected hence the intermediary devices will tamper with MACsec requirements.
You can overcome this problem on Juniper devices by using Ethernet over MPLS circuits or CCC connections where the devices looks to each other as being directly connected.
In this example, we will simulate the service provider network devices using QFX5100 and the CE devices using EX4600 as seen in the diagram:
Due to the fact that the PEs are QFX5100, there are few MPLS limitations(applicable to both QFX5100 and EX4600) that don’t allow us to use CCC, therefore we will use EoMPLS circuits to achieve MACsec connectivity between the two CE devices.
The two PE devices and the two CE devices are configured almost identical, hence the configuration will be shown only for one of each the two type of devices.
So let’s start with the relevant configuration of the PE devices regarding the interfaces:
{master:0}[edit] root@QFX5100-1# show interfaces xe-0/0/6 { mtu 9216; encapsulation ethernet-ccc; unit 0 { family ccc; } } et-0/0/102 { mtu 9216; unit 0 { family inet { address 10.10.10.1/24; } family mpls; } } lo0 { unit 0 { family inet { address 1.1.1.1/32; } family mpls; } } {master:0}[edit] root@QFX5100-1#
And this is the protocols configuration:
{master:0}[edit] root@QFX5100-1# show protocols ## ## Warning: requires 'mpls' license ## mpls { interface lo0.0; interface et-0/0/102.0; } ospf { area 0.0.0.0 { interface lo0.0; interface et-0/0/102.0; } } ldp { interface et-0/0/102.0; interface lo0.0; } l2circuit { neighbor 1.1.1.2 { interface xe-0/0/6.0 { virtual-circuit-id 6; } } } {master:0}[edit] root@QFX5100-1#
Once configured, the L2 circuit should come up:
{master:0}[edit] root@QFX5100-1# run show l2circuit connections | no-more Layer-2 Circuit Connections: Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration BK -- Backup Connection ST -- Standby Connection CB -- rcvd cell-bundle size bad SP -- Static Pseudowire LD -- local site signaled down RS -- remote site standby RD -- remote site signaled down HS -- Hot-standby Connection XX -- unknown Legend for interface status Up -- operational Dn -- down Neighbor: 1.1.1.2 Interface Type St Time last up # Up trans xe-0/0/6.0(vc 6) rmt Up Oct 6 10:49:47 2016 1 Remote PE: 1.1.1.2, Negotiated control-word: Yes (Null) Incoming label: 299776, Outgoing label: 299776 Negotiated PW status TLV: No Local interface: xe-0/0/6.0, Status: Up, Encapsulation: ETHERNET Flow Label Transmit: No, Flow Label Receive: No {master:0}[edit] root@QFX5100-1#
Now let’s move to the CE configuration. The traffic for VLANs 100 and 200 should be protected by MACsec:
{master:0}[edit] root@EX4600-1# show interfaces xe-0/0/6 { unit 0 { family ethernet-switching { interface-mode trunk; vlan { members [ v100 v200 ]; } } } } irb { unit 100 { family inet { address 100.100.100.101/24; } } unit 200 { family inet { address 200.200.200.201/24; } } } {master:0}[edit] root@EX4600-1#
And this is the MACsec configuration. I used the static connectivity association key way to configure MACsec:
{master:0}[edit] root@EX4600-1# show security ## ## Warning: requires 'macsec' license ## macsec { connectivity-association CA { security-mode static-cak; mka { transmit-interval 5000; key-server-priority 100; } pre-shared-key { ckn 1e1e1e1e2f2f2f2f; cak "$9$JjUk.zF/AuODiApO1yrYg4JGik.PF39kqT36/tpIEcyvWN-w"; ## SECRET-DATA } } interfaces { xe-0/0/6 { connectivity-association CA; } } } {master:0}[edit] root@EX4600-1#
Once everything configured on CE devices, you should see the inbound/outbound secure channels which should be the sign that everything might work properly. This from CE-1:
{master:0}[edit] root@EX4600-1# run show security macsec connections Interface name: xe-0/0/6 CA name: CA Cipher suite: GCM-AES-128 Encryption: on Key server offset: 0 Include SCI: no Replay protect: off Replay window: 0 Outbound secure channels SC Id: 64:64:9B:25:1C:89/1 Outgoing packet number: 2145 Secure associations AN: 0 Status: inuse Create time: 00:56:40 Inbound secure channels SC Id: 64:64:9B:25:7B:89/1 Secure associations AN: 0 Status: inuse Create time: 00:56:40 {master:0}[edit] root@EX4600-1#
And this is from CE-2:
{master:0}[edit] root@EX4600-2# run show security macsec connections Interface name: xe-0/0/6 CA name: CA Cipher suite: GCM-AES-128 Encryption: on Key server offset: 0 Include SCI: no Replay protect: off Replay window: 0 Outbound secure channels SC Id: 64:64:9B:25:7B:89/1 Outgoing packet number: 891 Secure associations AN: 2 Status: inuse Create time: 00:56:45 Inbound secure channels SC Id: 64:64:9B:25:1C:89/1 Secure associations AN: 2 Status: inuse Create time: 00:56:45 {master:0}[edit] root@EX4600-2#
But let’s test it by sending traffic in VLAN 100 from CE-1(100.100.100.101) to CE-2(100.100.100.102):
{master:0}[edit] root@EX4600-1# run ping 100.100.100.102 count 3 PING 100.100.100.102 (100.100.100.102): 56 data bytes 64 bytes from 100.100.100.102: icmp_seq=0 ttl=64 time=3273.755 ms 64 bytes from 100.100.100.102: icmp_seq=1 ttl=64 time=2273.313 ms 64 bytes from 100.100.100.102: icmp_seq=2 ttl=64 time=1272.386 ms --- 100.100.100.102 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1272.386/2273.151/3273.755/817.055 ms {master:0}[edit] root@EX4600-1#
It’s working and we can check if the packets where encrypted:
{master:0}[edit] root@EX4600-1# run show security macsec statistics Interface name: xe-0/0/6 Secure Channel transmitted Encrypted packets: 4 Encrypted bytes: 322 Protected packets: 0 Protected bytes: 0 Secure Association transmitted Encrypted packets: 4 Protected packets: 0 Secure Channel received Accepted packets: 4 Validated bytes: 0 Decrypted bytes: 322 Secure Association received Accepted packets: 4 Validated bytes: 0 Decrypted bytes: 0 {master:0}[edit] root@EX4600-1#
They were encrypted as expected. Although we sent/received 3 ICMP packets, there were 4 packets sent/received. The fourth packet(actually the first one) was the ARP request/reply as you can see in the “monitor traffic” output collected on CE-1 when the ping was started:
20:06:09.271606 Out arp who-has 100.100.100.102 tell 100.100.100.101 20:06:09.282673 In arp reply 100.100.100.102 is-at 64:64:9b:25:7b:80 20:06:09.282752 Out IP truncated-ip - 34 bytes missing! 100.100.100.101 > 100.100.100.102: ICMP echo request, id 17676, seq 0, length 64 20:06:09.282763 Out IP truncated-ip - 34 bytes missing! 100.100.100.101 > 100.100.100.102: ICMP echo request, id 17676, seq 1, length 64 20:06:09.282768 Out IP truncated-ip - 34 bytes missing! 100.100.100.101 > 100.100.100.102: ICMP echo request, id 17676, seq 2, length 64 20:06:09.293711 In IP truncated-ip - 28 bytes missing! 100.100.100.102 > 100.100.100.101: ICMP echo reply, id 17676, seq 0, length 64 20:06:09.293846 In IP truncated-ip - 28 bytes missing! 100.100.100.102 > 100.100.100.101: ICMP echo reply, id 17676, seq 1, length 64 20:06:09.293963 In IP truncated-ip - 28 bytes missing! 100.100.100.102 > 100.100.100.101: ICMP echo reply, id 17676, seq 2, length 64
And this is how you can protect the traffic using MACsec when the devices are not directly connected.
Now, if your PE devices support CCC, then you can configure the PE devices like this in order to have MACsec over CCC. Just keep in mind that you need to create a LSP on each PE and then reference the local LSP as transmit-lsp and the remote LSP(the LSP created on the other PE) as receive-lsp when the CCC is created.
Comparing to the L2circuit, the change happens only on protocols hierarchy.
This is for the PE-1
{master:0}[edit] root@QFX5100-1# show protocols rsvp { interface et-0/0/102.0; interface lo0.0; } ## ## Warning: requires 'mpls' license ## mpls { label-switched-path 1-to-2 { to 1.1.1.2; no-cspf; } interface lo0.0; interface et-0/0/102.0; } ospf { area 0.0.0.0 { interface lo0.0; interface et-0/0/102.0; } } connections { remote-interface-switch INTF_PE1 { interface xe-0/0/6.0; transmit-lsp 1-to-2; receive-lsp 2-to-1; } } {master:0}[edit] root@QFX5100-1#
And this is for PE-2:
{master:0}[edit] root@QFX5100-2# show protocols rsvp { interface lo0.0; interface et-0/0/51.0; } ## ## Warning: requires 'mpls' license ## mpls { label-switched-path 2-to-1 { to 1.1.1.1; no-cspf; } interface lo0.0; interface et-0/0/51.0; } ospf { area 0.0.0.0 { interface lo0.0; interface et-0/0/51.0; } } connections { remote-interface-switch INTF_PE2 { interface xe-0/0/6.0; transmit-lsp 2-to-1; receive-lsp 1-to-2; } } {master:0}[edit] root@QFX5100-2#
I hope you found this post useful and now you should have two possible workarounds when you need to use MACsec over a third party network.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Comments
So empty here ... leave a comment!