MPLS VPN Security 102 - VPLS Label Injections

MPLS label hopping example 102 - Injecting traffic into an MPLS L2 VPN using a hub and access to a SP core link. No one can be sure of how IOS-XE on the CSR1000v's is inspecting the incoming customer frames and potentially filtering or interfering with them, apart from the Cisco developers. That is being tested here.

Topology and Baseline
Broadcast destination MAC, unicast destination IPv4 address
Broadcast destination MAC, broadcast destination IPv4 address
Broadcast destination MAC, fake Ethertype
Multicast destination MAC, multicast destination IP
Results

 

Topology and Baseline

This is the logical topology for a test network running VPLS (but really any layer 2 MultiPoint2MultiPoint broadcast scenario using MPLS will be similar) to look at example MPLS injection issues with MPLS L2 VPNs:

The PE routers are CSR1000v images (03.16.01a.S [15.5(3)S1a]) running in VMWare so the following is the physical topology for this virtual lab. The Ubuntu VM is also running in VMware and connected to a VMNet 1 that links PE1 to PE2, the VMNets shown below provide separate layer 2 broadcast domains between each CPE and PE:

The following is a raw hex dump of a capture of a ping request from CPE1 to CPE2 to create a baseline packet:

PE2  Dst MAC: 00 0C 29 7A 7D 96 (PE2-Gi0/0/1, Link to PE1)
PE1  Src MAC: 00 0C 29 1E 8C 0F (PE1-Gi0/0/2, Link to PE2)
CPE2 Dst MAC: CA 05 11 48 00 08 (Fa0/0, Link to PE2)
CPE1 Src MAC: CA 04 15 14 00 08 (Fa0/0, Link to PE1)
CPE2 Dst IP:  C0 A8 00 02       (Fa0/0, 192.168.0.2)
CPE1 Src IP:  C0 A8 00 01       (Fa0/0, 192.168.0.1)


000c297a7d96 000c291e8c0f 8847 000121ff 00000000 ca0511480008 ca0415140008 0800 4500006400010000ff013a44 c0a80001 c0a80002 0800a15c00000001000000000000dcecabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcds

As would be expected based on MPLS VPN Security 101 one can inject a ping to CPE2 from CPE1 on the link between PE1 and PE2 by setting the source MAC as PE1 and destination MAC as PE2:

Just like L3 VPNs traffic can easily be injected into L2 VPNs, but basic unicast pings aren't much of an issue!

 

Broadcast destination MAC, unicast destination IPv4 address

The output below from PE2 shows a test which is to inject 10 fake ping request packets into the pseudowire, with a broadcast destination MAC but unicast source MAC (CPE1) and unicast source IP (CPE1) and unicast destination IP (CPE2). If accepted by PE2 and transmitted out the interface facing CPE2 then it would be possible to flood the LAN at the CPE2 site whilst spoofing where the traffic is coming from (CPE1/site 1) whilst also having evaded any input storm control filters on PE1.

As can be seen in the below output from PE2, incoming broadcast frames are being sent out the access circuit interface by PE2 however the drop counters on the VPLS instance are also increasing, which when compared against a vanilla ping from CPE1 to CPE2, the drop counters do not increase only the sent/received packet counters (my speculation is that the VMWare VMNet might be sending those broadcast frames back into the PE again, but I'm not sure):

Ostinato Settings:

L1: MAC
L2: Ethernet II
Payload: Hex Dump

SRC-PE1: 00:0c:29:1e:8c:0f
DST-PE2: 00:0c:29:7a:7d:96 
HexDump:
88 47 00 01 21 ff 00 00 00 00 ff ff ff ff ff ff 
ca 04 15 14 00 08 08 00 45 00 00 64 00 01 00 00 
ff 01 3a 44 c0 a8 00 01 c0 a8 00 02 08 00 a1 5c 
00 00 00 01 00 00 00 00 00 00 dc ec ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd 

This Wireshark capture on the link between PE2 and CPE2 shows the packets being sent towards the CPE although there is no response of course:

Whilst this doesn't seem too unusual, what is unusual is that changing the unicast IP destination from 192.168.0.2 (CPE2) to 192.168.0.10 (a non-existent destination, but the PE's don't know that, it could be a new host that was just connected to the LAN) the faked ping packets are no longer sent by PE2 out of the local access interface and dropped.

192.168.0.10 was added to CPE2 and CPE2 sent pings to 192.168.0.1, CPE1 with a source address of .10 which was successful. A fake ping to .10 still couldn't be injected on the PE1-PE2 link. Is PE2 performing some sort of layer 3 inspection building an ARP table as well as a MAC table?

 

Broadcast destination MAC, broadcast destination IPv4 address

In the previous test the source MAC is CPE1 and destination MAC is the broadcast address FF:FF:FF:FF:FF:FF but at the IP layer unicast source and destination IPs are used (the CPE1 IP as the source address and CPE2 IP as the destination address).

The test is repeated below with a broadcast IP destination set (255.255.255.255) so the 10 fake ping packets have both a broadcast destination MAC and IP, with unicast source MAC and IP (both CPE1). PE2 drops the frames ingressing from the MPLS LSP and nothing is seen out of the local attachment circuit interface:

Ostinato Settings:

L1: MAC
L2: Ethernet II
Payload: Hex Dump

SRC-PE1: 00:0c:29:1e:8c:0f
DST-PE2: 00:0c:29:7a:7d:96 
HexDump:
88 47 00 01 21 ff 00 00 00 00 ff ff ff ff ff ff 
ca 04 15 14 00 08 08 00 45 00 00 64 00 01 00 00 
ff 01 3a 44 c0 a8 00 01 ff ff ff ff 08 00 a1 5c 
00 00 00 01 00 00 00 00 00 00 dc ec ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd 
ab cd ab cd ab cd ab cd ab cd ab cd 

The above test further indicates that PE2 is possibly inspecting incoming packets. We can make a slight modification to this test and change the IP destination to be the local subnet broadcast range, 192.168.0.255. In this case the same behaviour is observed, PE2 is dropping the packets as they are received into the VPLS instance and nothing is transmitted onto the local access circuit. PE2 should be unaware that this is the local broadcast address as it should be forwarding based on layer 2 information. So this is the same result as the previous tests where the destination was essentially any unicast IP but an unknown one.

 

Broadcast destination MAC, fake Ethertype

Broadcast and multicast frames are of course transmitted over a VPLS instance, ARP for example is working otherwise the baseline ping would have failed. From the Wireshark screenshot below, CPE1 is asked to ping to an unknown IP 192.168.0.9 (unknown in that is has no adjacency [ARP] info) forcing it to ARP out across the VPLS instance. PE1 is receiving the ARP at the local attachment interface and forwards it into the MPLS LSP towards PE2 (and PE3, although this capture is on the PE1-PE2 link). PE2 forwards the ARP out of it's local attachment interface (as does PE3). So broadcasts definitely do work but the PEs aren't letting just any kind of broadcast traffic through it seems, as per the above tests with a broadcast destination MAC and IP address.

No issues or surprises in the above Wireshark capture. Next the ARP packet is replayed using Ostinato on the PE1-PE2 link but this time the Ethertype is changed to 0x1234, a fictional Ethertype so PE2 should not be able to inspect the payload and simply forward the frame based upon the destination MAC address. Sure enough, as the frame has a broadcast MAC address it is sent out of the local attachment circuit which is where the below Wireshark capture was made (note in this case an unknown unicast source address of 50:50:50:50:50:50 is used, this also caused PE2 to "learn" this new MAC address):

So far we can see that any Ethertype is permitted however when using the IPv4 Ethertype 0x0800 with a broadcast destination MAC and IP address the frame was dropped. To further test this a baseline is taken (the current output packet counters on Gi3, the local attachment circuit on PE2), 10 pings are then injected on the PE1 to PE2 link with a broadcast destination but unicast destination IPv4 address of 192.168.0.20 (which doesn't exist in this lab topology) and the output packet counters are captured again. Then finally the 10 pings are repeated with the broadcast MAC and unicast IP destination address but the Ethertype is changed to 0x1234 and again the output packet counters are captured.

Here it can be observed that the IPv4 packets are dropped by PE2 (the drop counters on the VPLS instance increase in line with these interface output counters NOT incrementing) but with the fake Ethertype PE2 allows the frames to pass through (this is double verified with a packet capture on the AC, also note with the fake Ethertype no host would be able to process the fake pine packets). This traffic was also injected into the CPE1 to PE1 link to test that PE1 accepts the frames on the access circuit, which it does.

 

Multicast destination MAC, multicast destination IP

In this example a fake multicast ping packet is crafted from a unicast MAC of 50:50:50:50:50:50 and unicast IPv4 address 192.168.0.10 to a multicast destination MAC of 01:00:5E:00:00:01 and multicast IPv4 destination address of 244.0.0.1.

Ostinato Settings:

L1: MAC
L2: Ethernet II
Payload: Hex Dump

SRC-PE1: 00:0c:29:1e:8c:0f
DST-PE2: 00:0c:29:7a:7d:96 
HexDump:
88 47 00 01 21 ff 00 00 00 00 01:00:5E:00:00:01
50:50:50:50:50:50 08 00 45 00 00 64 00 01 00 00
ff 01 3a 44 c0 a8 00 0a e0 00 00 02 08 00 a1 5c
00 00 00 01 00 00 00 00 00 00 dc ec ab cd ab cd
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd
ab cd ab cd ab cd ab cd ab cd ab cd 

In this test PE2 is dropping the packets as they are received from the MPLS LSP into the VPLS instance, as per the below router output which is also verified with a Wireshark capture on the local attachment circuit, CPE2 receives nothing:

As with the previous tests, this packet we "re-headered" and sent into the CPE1 to PE1 access link and PE1 did forward the packet into the VPLS instance, but as above PE2 is dropping it.

A third test was made back on the link between PE1 and PE2 again, this time the Ethertype was changed to 0x1234 and now again PE2 is forwarding the frame onto the local access circuit. Further indication that any destination MAC address is permitted but when the Ethernet payload is ARP or IPv4 the egress PE is inspecting the frames.

 

Results

In some of the tests the source unicast MAC address 50:50:50:50:50:50 was used to check if the PEs required the MAC address to already be present in the VPLS bridge-domain MAC tables before they would forward incoming frame on. For example, if the PEs haven't seen an ARP from a given MAC they won't forward other broadcast to or from that MAC, however that was not the case in any tests and the traffic was always forwarded.

• Tx to broadcast destination MAC, unicast IP - These frames are transported across the VPLS instance and transmitted on the local access circuit by both PE2 and PE3 - they are not checking for a matching broadcast IP when broadcast MAC is present (and how could they, if they forward at layer 2, they should be ignorant of the IPv4 adressing scheme in use) however some weird issues have been seen with unknown unicast IP destination. An attack may require a valid IP target.
  
  
• Tx to broadcast destination MAC and broadcast IP - These frames are transported across the MPLS instance but dropped by the egress PE.
  
  
• Tx to broadcast destination MAC with custom Ethertype - These frames are transported across the MPLS instance and permitted by the remote PE out of the remote attachment circuit. No Ethertype filtering seems to be in place. Expanding on the "broadcast destination MAC, unicast IP" tests, it can be observed that unless the custom Ethertype is specified packets to an unknown unicast destination IP are not being transmitted by PE2.
  
  
• Tx to multicast destination MAC and multicast IP - These frames are allowed into the VPLS instance by PE and transported across to the remote PEs but the egress PEs are dropping them. Switching to a custom Ethertype permits the frames out of the egress PEs to remote access circuits. This is further indication that PE2 is filtering based on a combination of destination MAC and IP if the Ethernet payload is IPv4.

---