As an end-user, you should never receive STP BPDU frames from the ISP. The workstation in enterprise networks should not either. It is always a result of misconfiguration or lack of knowledge from network engineers about basics of network security. BPDU can reveal information about your network that can be later used to compromise it. In the worst case, an attacker can impact your system by changing the spanning-tree topology and perform a Man-In-The-Middle attack.

I noticed that my ISP is sending me BPDU frames. Let’s see, using this case real-life scenario, what we can tell about his network.

Ethernet frame header

Let’s start by looking at the frame header.

Ethernet frame header can give us overview of what switch is used

The destination MAC address is as expected – the 01:80:c2:00:00:00 is IEEE 802.1D reserved multicast address called “Spanning tree (for bridges).” More interesting is the source MAC address. In this case, we got lucky to see not commonly used vendor Raisecom. Quick Google search reveals it is a company producing the Carrier Ethernet devices including Access Switches and Aggregation Switches. Why is this information valuable? It may be useful when an attacker would try to use known vulnerability on such platform.

The Logical-Link Control layer does not provide any useful information in this case and consists of default values pointing to BPDU frames in the lower protocol.

The Logical-Link Control layer with default values pointing to BPDU frames in the lower protocol

BPDU Header Flags

Let’s now look at the BPDU header

Protocol Identifier should always be 0x0000 for STP BPDU. The Protocol Version Identifier provides us information that Multiple Spanning Tree (MST) protocol is in use due to a value of 3 – the 802.1D uses a value of 0 here, while Rapid Spanning Tree has assigned a value of 2. We also see that this is Config BPDU type of RST/MST by the value of 0x02 in BPDU Type field.

Knowing that my ISP uses MSTP protocol may be useful. This knowledge may lead us to craft own spoofed BPDU frame not to mention it gives us an overview of how ISP built its network.

Lets now look at the flags. The first one, Topology Change, and the last one, Topology Change Acknowledgment, are set to 0 which meant there were no changes in the path to the Root Bridge. During long monitoring changes in TC flag gives an attacker overview how stable is the ISP network or if his disruption attempts works.

The Proposal and Agreement Flags

Because the ISP switch does not have STP knowledge of my router (this is expected because I terminate the connection on Layer 3 interface) it sends BPDU with the Proposal flag set. That means it will listen to the BPDU I may want to send, which may be the Superior BPDU.  However, things get little strange at this point.

In a typical situation, the RSTP switch sends the BPDU with the Proposal flag set only if the Designated Port is in Discarding or Learning state. The worse switch accepts the proposal and set Agreement flag in response clearing the Proposal flag. It can reject the proposal the Agreement flag in response is not set. In general, the response is a copy of the proposal BPDU but with the Proposal flag cleared and Agreement flag either set or not. Only this way switch knows which proposal the agreement it receives corresponds.

I went through IEEE 802.1D-2004 standard document, and I cannot find the situation when both flags should be set. Also, I see no sense in such configuration. The switch can either accept or refuse the proposal it receives.

Also if the port is in the Forwarding state, the Proposal flag should never be set.

So why is it happening here? Probably due to poor RSTP/MSTP implementation on ISP hardware.

Root Bridge

Time for Root Identifier and Bridge Identifier section

Root Identifier and Bridge Identifier

The primary thing we should notice is Root Bridge Priority set to 32768, which is the default value for almost any switch available on the market. It means that the network was not designed with a care of Layer 2 topologies and it may be a security issue. With no additional protection like Root Guard and BPDU Guard, an attacker may connect its device with lower priority and became root bridge for the segment. From Root Bridge in STP domain sniffing the traffic or performing the Man-In-The-Middle attack is easy. MST is not giving any real additional protection here.

MST Extension

The last part is MST Extension section

MST Extension section in BPDU

As we can see MST is in use, but no there are no regions. So is the configuration of MST correct? The answer is “yes.” Such approach should be standard if we have a network built using devices from multiple vendors. STP and RSTP implementations may differ in details. Significant difference everyone notice is between Cisco per-VLAN implementation of STP (PVSTP+, PVRSTP+) versus other vendors. Juniper builds one spanning tree topology for all VLANs when using STP or RSTP protocol. Juniper devices, therefore, don’t understand BPDU sent by Cisco switches and won’t process them. That may lead to loops and unpredicted behavior in case of link problems or not careful design or implementation.

We also see here that CIST Bridge Priority is left to the default value. Also, configuration name is the default empty string which makes possible attacks even easier. The MST Config Digest value of ac:36:17:7f:50:28:3c:d4:b8:38:21:d8:ab:26:de:62 is specific value of digest when all VLANs are assigned to particular instance.

I am the ISP, what I can do better?

Based on just one BPDU frame we were able to obtain several useful information about the ISP network:

• They use MSTP protocol probably because devices of multiple vendors are in use (which is a right design approach)
• They are most likely use Raisecom hardware on access layer
• Bridge priorities and MST configuration are left with default values (which is bad design approach)
• The Root Bridge for the segment is not the access switch I am connected to, so there is at least one more switch in the STP domain.
• The access port is configured as Edge Port (remember that MSTP uses RSTP for building the tree) but with no BPDU filtering because it is still sending the BPDUs. In Service Provider networks Edge Ports should not send BPDUs, just listen if they receive any.

I cannot say if there is additional protection deployed without attempting an attack which I am not going to do. However, if we assume, there are none an attacker can make himself the Root Bridge of the segment and sniff the traffic or perform a Man-In-The-Middle attack. He can also disrupt topology by injecting fake BPDUs using tools like scappy.

Following security features should be implemented:

• Define port as an RSTP Edge Port with BPDU filtering which stops sending the BPDU
• Configure customer access ports with the BPDU Guard or at least the Root Guard feature – that will block unwanted BPDUs
• Change the default Root Bridge Priority from default value and enforce placement of root bridge based on your preference, not the priority calculated based on MAC address

Raisecom notes

The Raisecom configuration guide provides two ways of root bridge enforcement – by setting the priority or using spanning-tree root command. The documentation lacks an explanation of how this enforces the Root Bridge and Backup Root Bridge placement. The vendor also does not recommend changing the priority values – I disagree with this approach.

The administrator can manually configure the port as the Edge Port. The interface would remain in this state unless it received BPDU. By default, all ports are in Edge Port auto detection mode. The Edge Port state has to be manually cleared.

Switches have RootGuard and LoopGuard features but not the BPDUGuard.