Without a proper understanding of TRILL’s behaviour an engineer introducing TRILL to a network may make it vulnerable to VLAN attacks.
Background
In 802.1Q networks VLANs provide isolation between different sets of end stations. An end station on one VLAN is unable to transmit a frame to an end station on another VLAN. In a VLAN attack this rule is broken by exploiting vulnerabilities in the bridge software or hardware. Over the years various such attacks have been discovered and resolved, and properly configured VLANs are now considered secure.
Today, the most important and widely used control when securing VLANs is the ability to constrain their topology. This is a well defined feature in the 802.1Q standard. A VLAN topology is constrained by configuring VLAN memberships on ports. A bridge only accepts a frame on a port when the frame’s VLAN tag matches the port’s VLAN memberships. Similarly, a bridge only transmits a frame on a port — such as in the case of a broadcast flood — when there is also a match.
Let’s consider the following simple example.
+----+ +----+ +----+ | B1 |--dot1Q--| B2 |--dot1Q--| B3 | +----+ +----+ +----+
There are three 802.1Q bridges. B1 is in an insecure location, such as a meeting room or wiring closet, where an attacker might gain physical access and compromise it. B2 and B3 are in a secure location, such as a server room, and have ports configured on VLAN 2 with servers attached. The administrator wants B1 to have access to VLAN 1, and to prevent a rogue B1 from being able to access the servers on VLAN 2. So on B2, he configures the port connected to B1 to only be a member of VLAN 1. Now, if an attacker compromises B1, he can configure VLAN 2 on the compromised bridge, but this access will not extend to the target servers. To do this the attacker would need to gain access to and compromise B2, which is considered to be in a secure location.
Enter TRILL
So how might TRILL make a network vulnerable? Essentially the problem is that TRILL bypasses the existing VLAN topology (or policy) of a network. When an Ethernet frame arrives at an RBridge it’s encapsulated with a TRILL header and an outer MAC header. But, importantly, the VLAN tag isn’t copied to the outer MAC header, and instead TRILL forwards the frame over a single common VLAN called the designated VLAN.
Going back to the example, if B1 and B3 are replaced with RBridges, one might naturally expect a TRILL VLAN to behave like an 802.1Q VLAN, so that VLAN 2 will still be constrained by the configuration on B2, but this is not the case. An attacker that compromised B1 could configure full access to any end station on VLAN 2 attached to B2 and B3. In fact, the attacker could configure full access to any VLAN which any other RBridge in the network can access. This is because B1 will encapsulate VLAN 2 frames from the attacker, forward them to B3, where they are decapsulated and forwarded appropriately. B2 is unable to recognise the encapsulated VLAN 2 frame so lets it pass.
Other scenarios in which TRILL may enable VLAN attacks may also exist. For example, consider the case where end stations exist on the designated VLAN. Can an end station then emulate or spoof an RBridge, and therefore gain access to the entire network? In some cases, yes.
Conclusion
TRILL has adopted the term VLAN, but what it calls a VLAN behaves differently from the 802.1Q definition of a VLAN. TRILL views a VLAN as a community, more like a BGP/MPLS IP VPN, and believes that all end stations in a VLAN should be able to reach each other. TRILL also takes the view that all RBridges in a network are at the same trust level. Again, this is similar to MPLS, and we see that no one ever puts an MPLS router in an insecure location for that reason. TRILL goes so far as to impose this view on existing 802.1Q networks when it is deployed incrementally.
So what could be done? Well, there are only two ways to properly fix this.
The first is for TRILL to copy the inner VLAN tag to the outer VLAN tag, so that a TRILL encapsulated frame could still only travel on the same links as before RBridges were deployed. As an advantage, the VLAN forwarding behaviour of RBridges and bridges remain similar.
The second is for TRILL to form regions of directly coupled RBridges, where TRILL is only done on RBridge-RBridge links. This would require making these TRILL regions appear to STP as though they are bridges through some clever processing of BPDUs, or making the TRILL regions transparently tunnel BPDUs. This would have the added benefit of being similar to existing systems, such as Multiple Spanning Tree, 802.1ad Provider Bridges, and VPLS.
It is likely that implementations of RBridges will allow administrative filtering of the inner VLAN, but this is not included in the specification and so may vary. (At a minimum I feel this filtering should be covered in the specification.) This will allow administrators, provided they understand TRILL properly and deploy RBridges in the right sequence, to mimic their existing policy.
It strikes me as strange that a protocol aimed at resolving many of the problems with bridges has chosen to create new, preventable problems. It has chosen to adopt existing terms but behave differently, and has opted for the best incremental optimisation outcome over respecting the existing security policy. I think it’s likely that we will see RBridges sold as drop-in replacements for bridges, and I remain concerned that in the early days, because of this, there will misunderstandings and problems.