A friend of mine told me about a “VXLAN is insecure, the sky is falling” presentation from RIPE-77 which claims that you can (under certain circumstances) inject packets into VXLAN virtual networks from the Internet.

Welcome back, Captain Obvious. Anyone looking at the VXLAN packet could immediately figure out that there’s no security in VXLAN. I pointed that out several times in my blog posts and presentations, including Cloud Computing Networking (EuroNOG, September 2011) and NSX Architecture webinar (August 2013).

Another conclusion I made in NSX Architecture webinar (slide 28, included below) was “transport network MUST be secure” (notice the RFC2119 use of MUST).

I would also like to point out that VXLAN is no different from most other layer-heaping technologies including GRE, L2TP, and MPLS, or earlier virtual circuit technologies like Frame Relay and ATM. The moment an intruder gains access to the transit network it’s game over… but of course it’s so much more fun to make the same point with examples like “I can insert UDP packets into a VXLAN network”.

Well, the presenter should have gone a step further: in VXLAN networks that use dynamic MAC learning instead of a decent control plane, the VTEPs would blindly accept whatever is injected from the outside, and create forwarding entries that would ensure the return traffic gets back to the intruder.

Does that mean VXLAN is broken? Not really, any technology can be dangerous in hands of clueless incompetents… including Kinder Surprise Eggs (there must be a reason they are banned in some countries). At least in the VXLAN case, the drawbacks are clearly documented in the Security Considerations section of RFC 7348:

Traditionally, Layer 2 networks can only be attacked from ‘within’ by rogue end points – either by having inappropriate access to a LAN and snooping on traffic, by injecting spoofed packets to ’take over’ another MAC address, or by flooding and causing denial of service. A MAC-over-IP mechanism for delivering Layer 2 traffic significantly extends this attack surface. This can happen by rogues injecting themselves into the network by subscribing to one or more multicast groups that carry broadcast traffic for VXLAN segments and also by sourcing MAC-over-UDP frames into the transport network to inject spurious traffic, possibly to hijack MAC addresses.

As always, whenever you want to start using a new tool, you should understand how it works, and what its advantages and limitations are… after all, you want to call yourself an engineer, right? Oh, and don’t be surprised when the $vendors don’t tell you what the limitations and drawbacks are.

Finally, I would love to see security researchers shift their focus from “OMG, look how I managed to break it” to “there are some fundamental limitations of what can be done, and if you don’t know what they are you might get hurt… like in this example.”

And just in case you want to know more – you’ll find tons of details in VXLAN details in VXLAN Technical Deep Dive and EVPN Technical Deep Dive.

Revision History

2022-02-22

Added a quote from RFC 7348