[rbridge] VLAN hopping: firewall on a stick

[Kris Price]

Hi Radia,

Radia Perlman wrote:
> Although it's good to have people look at things with a fresh eye, part 
> of the problem with looking at it
> so late is that some decisions might have been made that you might 
> disagree with, and you didn't have a chance
> to argue about it at the time.

I respect that and realise it's probably too late to revisit the overall 
architecture or some of these decisions, but I like idea behind TRILL 
and really want it to be successful, so (lacking any diplomacy perhaps) 
I can't help but question things that seem counter intuitive or 
contradictory to me. Maybe I'd be better to explore those things in a 
paper or some such tho.

> We did discuss this issue, and the conclusion was that RBridges didn't 
> have to behave *exactly* like bridges in
> various configuration-intensive situations.

Okay. My experience differs, and maybe that's due to a regional thing. 
Down under I would say this kind of configuration is the norm, perhaps 
considered intensive, but certainly the norm. I haven't personally seen 
a configuration free 802.1 network since 1999, and at that time we were 
still using thinnet there. Even very small sites here are configured 
with VLANs for remote management and such. And when I imagine replacing 
them with an RBridge it would seem to never require less configuration. 
But in quite a few RBridges would seem to require more configuration due 
to security, and in quite a few places be disqualified from use if what 
I've been talking about isn't solvable. Which is why I wondered if it 
had evolved to being really just targeted at people with big clusters.

> However, in this case -- VLAN hopping -- if you really want the feature 
> of keeping two communities, both
> labelled "VLAN 5" distinct within a layer 2 cloud, can't you accomplish 
> that with VLAN mapping, which RBridges
> do support?

It might do. I'm reading draft-ietf-trill-rbridge-vlan-mapping-00.txt 
but it isn't completely clear to me. Let's see if I have it right.

In the diagram the <1, 2, n> lists the VLANs allowed on the link as 
configured on the ports at both ends. If these were all 802.1Q bridges 
then B1 would not be able to reach stations in VLANs 2 and 3 attached to 
B2 or B3, even if it changed its configuration.

Let's assume again that B1 and B3 have been swapped out to RBridges and 
B2 is still the 802.1Q bridge. Again B1 is untrusted so capable of 
changing its port configuration or crafting frames, etc.

   +----+       +----+           +----+
   | B1 |--<1>--| B2 |--<1,2,3>--x B3 |
   +----+       +----+           +----+

We want to prevent B1 from accessing VLANs 2 and 3. Remembering B1 is 
untrusted, so possibly compromised and capable of changing its port 
configuration or crafting frames, etc.

Using VLAN mapping, would we configure a map on the port "x" on B3, to 
map the VLANs we want to protect to other VLAN IDs? E.g. map VLAN 2 to 
VLAN 998 and map VLAN 3 to VLAN 999. Then make sure VLAN IDs 998 and 999 
are never used for anything else. Is that how we'd do it?

Can we map 2 and 3 to the same garbage VLAN ID or do we need to make a 1 
for 1 mapping for every VLAN we want to protect?

Can we do this inbound/outbound on the same trunk port?

What happens if B1 sends a crafted frame tagged with 998 or 999 to B3, 
does it get mapped back to 2 or 3?



Regards

Kris