A city security board asks whether enabling VXLAN by itself encrypts tenant traffic across the fabric. What is the accurate data-plane security statement?
Select an answer to reveal the explanation.
Short Explanation
Wrapping a postcard in a bigger envelope doesn’t lock it—anyone who opens the truck can still read it. VXLAN is encapsulation, not a cipher. If the city needs confidentiality, add real crypto (IPsec, MACsec, or another approved layer)—don’t assume the VNI is a padlock.
Full Explanation
A city security board asking whether enabling VXLAN by itself encrypts tenant traffic should hear a clear data-plane security statement: VXLAN encapsulation is not encryption; confidentiality requires a separate cryptographic overlay or underlay control if policy demands it. VXLAN provides segmentation identifiers and tunneling, but the encapsulated payload is not confidential merely because it rides a VNI across the civic fabric.
VXLAN does not always provide AES-GCM because the VNI field doubles as a key identifier. UDP 4789 does not inherently encrypt payloads whenever EVPN is configured. It is false that only BUM frames are encrypted while known unicast remains cleartext by design for performance.
Exam caveat: segmentation is not confidentiality; municipal risk reviews must not equate VXLAN with encryption.
Operational check: document in the security architecture that VXLAN alone is unencrypted tunneling; if policy requires confidentiality, validate MACsec, IPsec, or another approved crypto layer on the relevant paths and prove it with capture or crypto counters. Update the city’s risk register to list VXLAN as transport/segmentation, with crypto as a separate control. Sample production captures (in an approved window) to show inner payloads are readable without the crypto layer.