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:

 

macsec_over_l2circuit

 

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.

 

The following two tabs change content below.

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

So empty here ... leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: