Subject: [rbridge] rbridge Digest, Vol 84, Issue 8[d-vlan]

From: Rakesh Kumar <[email-masked]>
Date: Mon, 16 May 2011 12:31:46 +0530

Hi,
I have doubt that TRILL may enable VLAN attacks.

consider the case where end station enabled vlan is selected as D-Vlan
then end station on this D-vlan can emulate or spoof an RBridge, and
therefore gain access and control to the entire network.

Consider another case where Two rbridges(RB1 and RB2) connected through B2
as follows:

   +----+         +----+         +----+
   | RB1|---------| B2 |---------| RB3|
   +----+         +----+         +----+

 RB1 is in an insecure location, where an user might gain physical access
and compromise it.B2 and RB3 are in a secure location, and have ports
configured on VLAN 2 with servers attached. The administrator wants RB1 to
have access to VLAN 1, and to prevent a RB1 from being able to access the
servers on VLAN 2.

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. Since 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.An attacker that compromised RB1 could configure full access
to any end station on VLAN 2 attached to B2 and RB3.

regards,

RAKESH
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 16 May 2011 09:52:08 -0400

Hi Rakesh,

> therefore gain access and control to the entire network.

I assume that by "D-vlan" you mean Designated VLAN. If you want be
sure people will understand you, it is better to spell things out.

For the most part, I don't see why you think your concern above has
anything to do with TRILL. It is a general characteristic of any
dynamic routing protocol that if you cannot authenticate the routing
messages, someone can "spoof" a router, send routing control messages,
and screw things up. Using IS-IS authentication can help in the TRILL
case.

> RB1 is in an insecure location, where an user might gain physical access and
> compromise it.

By putting a router that can be compromised in an insecure location,
you have already abandoned security.

> B2 and RB3 are in a secure location, and have ports configured
> on VLAN 2 with servers attached. The administrator wants RB1 to have access
> to VLAN 1, and to prevent a RB1 from being able to access the servers on
> VLAN 2.

Is it actually that you don't want RB1 to access these VLAN 2 servers?
Or is it that you don't want end stations attached to RB1 to access
these VLAN 2 servers? If it the first, then you shouldn't be trusting
RB1 as a router at all. If it is the second and you can trust RB1,
then all you have to do is disable VLAN 2 (or arrange for there to
never be a VLAN 2 appointed forwarder) on all the RB1 ports that might
lead to one of the end stations you want to restrict.

> not the case.

Right. TRILL enables connectivity between all end stations in the same
VLAN and, if you replace bridges with RBridges, glues together what
might otherwise be VLAN islands. It was the consensus of the TRILL WG
that it work this way. This can have advantages. Say, for example,
that two parts of your campus are connected by carrier Ethernet
facilities that only pass frames labeled with some particular
arbitrary VLAN, say VLAN 2473. Then all you have to do is configure
that as the Designated VLAN on that link and you have full
connectivity.

Perhaps to get the effect you may want, you need something like the
optional feature described in
http://tools.ietf.org/html/draft-ietf-trill-rbridge-vlan-mapping-05

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

> Since VLAN tag isn’t copied to the outer MAC header, and
> designated VLAN. An attacker that compromised RB1 could configure full access

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 16 May 2011 16:46:07 -0700

On Mon, May 16, 2011 at 12:01 AM, Rakesh Kumar <[email-masked]>wrote:

>From a TRILL standpoint, B2 can be thought of as being
"open" to all VLANs i.e. if RB1 and RB2 were regular bridges,
then B2 is open to all VLANs on both ports.

Since RB1 is untrusted, the way to implement the policy
would be restrict decapsulation of RB1 traffic at RB3 to
only those VLANs which RB1 is allowed to send to RB3
which can be accomplished using ACLs.

In general, as Donald pointed out in his reply, it doesn't
make sense to have an untrusted device be part of
the same TRILL campus.  To solve the above, problem,
it would be better to design the network such that B2
is an RBridge and it receives regular, non-TRILL Ethernet
traffic from "RB1" which should be a regular bridge.

Your issue is valid, but the problem is with how the
network is constructed and not a problem with
TRILL itself.  Any MAC-in-MAC encapsulation protocol
(e.g. 802.1ah) would have a similar problem.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge