Fabric Attach element spoofing at a shared convention venue
A convention center runs Fabric Connect with 120 Fabric Attach access points and 40 payment terminals. The FA server is a VSP 7400 pair using vIST and SMLT. FA clients are assigned to VLAN 300 for payments or VLAN 310 for guest Wi-Fi. The FA assignment is based on element ID and port ID, and the server has no allow-list. During a large event, the payment provider reports that terminals intermittently land in VLAN 310, and show fa element displays two entries with the same element ID but different port IDs. A contractor had plugged a laptop running LLDP into a public wall port; the laptop advertised the element ID of a payment terminal. The wall port is fa enable but has no 802.1X or port security. The venue wants to keep zero-touch FA for APs and terminals.
1. Explain how the spoofed FA element causes VLAN misassignment. Why is Fabric Attach not an authentication mechanism?
Read the worked answer
Fabric Attach uses LLDP to advertise an element ID, port ID, and assignment request. The FA server maps that identity to a VLAN or I-SID. If a laptop copies a payment terminal's element ID, the server sees a second element with the same identity but a different port ID. Depending on the assignment policy and timing, the server may apply the payment VLAN to the wrong port, apply the guest VLAN to the real terminal, or create conflicting entries. The terminals then intermittently land in VLAN 310 because the server is reacting to two claimants for one identity.
FA is a discovery and provisioning protocol, not an authentication protocol. It has no cryptographic proof of identity and no challenge-response. LLDP is link-local, but a public wall port is exactly where an untrusted device can send it. The security boundary must come from port authentication, physical control, or an allow-list, not from the FA element ID itself.
2. Propose controls that preserve zero-touch for trusted devices but stop this attack.
Read the worked answer
Segment trust by port. Disable FA on public wall ports and enable it only on ports that face known APs, terminal switches, or a trusted FA proxy. For payment terminals, use a static FA assignment or an element-ID allow-list rather than accepting any requesting element. Put the payment ports behind 802.1X or MAC authentication, and use port security to limit the number of MAC addresses. If the terminals cannot authenticate, place them on dedicated physical ports in a locked enclosure and keep those ports out of the public seating area.
Where third-party switches are used, deploy FA proxy at the trusted access switch so the server sees the proxy's identity rather than every downstream device. Monitor for duplicate element IDs and for FA assignments that change unexpectedly; alert on both. Keep guest Wi-Fi and payments on separate physical or logical paths, and do not let the FA server assign the payment VLAN to a port that has not been authenticated. This preserves zero-touch for the 120 APs while removing the public port as an attack vector.
3. What immediate recovery steps would you take during the event, and what long-term monitoring would you add?
Read the worked answer
Immediately shut or quarantine the public wall port that is advertising the duplicate element ID, then clear the spoofed FA element and re-provision the affected payment terminals. Verify show fa element has one entry per real device, confirm the terminals are in VLAN 300, and check that guest clients remain in VLAN 310. Do not simply clear the duplicate and leave the port enabled; the attacker can repeat it. If the payment provider cannot confirm terminal isolation, move payments to a dedicated switch or dedicated ports for the remainder of the event.
Long-term, add alerts for duplicate FA element IDs, FA element count per port, and VLAN changes on payment ports. Log LLDP neighbor changes on public ports, and add a monthly audit that FA is disabled on all untrusted ports. Include a change-control rule that no public wall port is configured with fa enable without 802.1X or port security.