[rbridge] VLAN hopping: firewall on a stick
trill at punk.co.nz
Sun Mar 15 23:56:20 PDT 2009
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?
More information about the rbridge