Subject: [rbridge] seeking input on abstract for problem and applicability statement

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 17:46:44 -0700

Here's a proposed abstract.

Thoughts appreciated.

Joe

- -----

RBridges are layer-2 devices that automatically aggregate into a virtual
device that emulates a single bridge on a conventional 802.1 Ethernet.

(I had thought that was a concise description, but with recent
discussion about non-participation in some bridge protocols, I'm not
sure. I still think the rbridge MUST participate in order to avoid
loops, but if that's contentious it can't be part of the abstract yet...)

They combine layer 2?s ability to allow hosts to reattach without
renumbering with layer 3?s routing benefits. RBridges use existing link
state routing to provide higher internal cross-section bandwidth, faster
convergence under reconfiguration, and more robustness to link
interruption than an equivalent set of conventional bridges using
existing spanning tree forwarding. They are intended to apply to similar
L2 network sizes as conventional bridges and are intended to be backward
compatible with those bridges as well. This document describes the need
for RBridges and describes situations where it will be useful.

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Wed, 12 Oct 2005 07:57:04 +0200

--On tirsdag, oktober 11, 2005 17:46:44 -0700 Joe Touch <touch at ISI.EDU> 

> device that emulates a single bridge on a conventional 802.1 Ethernet.

question: is the "automatically" part necessary & sufficient?
somehow I get this awful feeling when I see a disruption-sensitive 
infrastructure that devices can "automatically" join..... too many IETFs 
watching NOC crew hunt down rogue devices of various kinds...

no objection to "can automatically".....

> This document describes the need

nit: singular/plural mismatch (or I parsed the sentence incorrectly)

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 23:19:07 -0700

> question: is the "automatically" part necessary & sufficient?

I thought so, in the same sense that bridges automatically aggregate
into a single spanning tree.

> no objection to "can automatically".....

'can' implies they might not, which would be bad (consider bridges that
refused to participate in spanning tree).

> nit: singular/plural mismatch (or I parsed the sentence incorrectly)

Nope - thanks for the catch.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051011/5b8f9f42/signature.bin

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Wed, 12 Oct 2005 11:48:01 +0200

--On tirsdag, oktober 11, 2005 23:19:07 -0700 Joe Touch <touch at ISI.EDU> 

> refused to participate in spanning tree).

My worry is the end-user PC that attaches to an rbridge, calls itself an 
rbridge, and injects fake mappings for another PC in order to deny service 
to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
"dsniff".

I guess you could do the same thing with spanning tree.... the defense is 
probably to let the bridges distinguish between "core ports" and "user 
ports" - but then we're out of the "automatic" configuration space again....

                   Harald, paranoid.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Oct 2005 07:02:24 -0700

> ports" - but then we're out of the "automatic" configuration space again....

My understanding is that rbridges are not intended to fix any security
problems that persist with an equivalent deployment of bridges.

Somebody let me know if otherwise ;-)

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051012/45828096/signature.bin

---

From: loa at pi.se (Loa Andersson)
Date: Wed, 12 Oct 2005 16:17:54 +0200

Joe Touch wrote:
<snip>

do we have any idea on to what level security enters into the
trill work? not at all, or do the rbridges also in this respect
behave as routers?

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson at acreo.se
                                            loa at pi.se

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Wed, 12 Oct 2005 10:46:32 -0400

I support "can automatically" because the customers will always want
knobs.
(Seems we're arguing about defaults).

> > refused to participate in spanning tree).

I've run into managed switches which, as best as I can tell, came from
the factory with spanning tree turned off by default.  

> to someone he doesn't like. Or perhaps sniff/modify the traffic ala 

Indeed.  And to toss in another wrinkle, I may want my multi-ported
server to appear on the rbridge cloud simultaneously at multiple points
without necessarily being willing to provide "transit" to anything other
than the real or virtual end systems inside my box. 

> ports" - but then we're out of the "automatic" configuration space again....

Yep.  People who actually manage their networks will want those knobs.

On the other hand, given crypto authentication support in the underlying
routing protocol, the "core" vs "user" distinction might be managed by
what the other device "knows" rather than by which port it's plugged
into.

					- Bill

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Oct 2005 08:34:12 -0700

> trill work? not at all, or do the rbridges also in this respect

IMO, they behave as bridges - except perhaps in participation in the
spanning trees with bridges at their edge.

They do NOT behave as routers - they can't. Routers would kill
broadcasts, for one. Routers don't exist at L2 anyway - as far as the L2
is concerned, they're just nodes.

RBridge MAC addresses should only ever be known or used by other
rbridges, never by other nodes on the L2.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Oct 2005 08:37:26 -0700

> (Seems we're arguing about defaults).

Yes, I think so.

> the factory with spanning tree turned off by default.  

Are those compliant? Or is that just a vendor choice to distribute them
in non-compliant mode for some reason?

> than the real or virtual end systems inside my box. 

That's not a wrinkle. That's a single physical box that - as far as L2
is concerned - *IS* multiple nodes on the L2.

L2 doesn't care whether a node is an L3 transit (router) or an L3
source/sink (host). Nodes are L2 sources/sinks, and everything else is a
link or emulation thereof (bridges, hubs, etc.)

> Yep.  People who actually manage their networks will want those knobs.

Sure. Right now, ports can be both core and user at the same time, but
there could be options to prohibit traffic of either type.

> what the other device "knows" rather than by which port it's plugged

'core' traffic is defined by the existence of the campus transit header
(CTH) [the shim header].

everything else is user traffic.

There's no need to designate the two per-port; the rbridge device
already needs to know the distiction between the two. Core is forwarded
or decapsulated (if the L2 destination matches); edge is encapsulated
and forwarded.

While crypto for campus routing would be nice, it's like crypto for the
spanning tree - it would inhibit plug-and-play, and the lack of it
doesn't add a new vulnerability.

Joe

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 12 Oct 2005 19:16:07 -0700

> ports" - but then we're out of the "automatic" configuration space again....

Yes, you can do similar things with spanning tree; the details might be 
a bit different though.

I think the requirement for TRILL should be to do no harm, which I 
interpret as not being any worse than a bridged network. We can easily 
do that without any configuration.

There are two ways I think we can do better, but it requires 
configuration. The first one is to use the features in the routing 
protocol to make sure that your PC can't spoof routing protocol updates. 
As Bill said, this doesn't require distinguishing between different type 
of ports on the rbridges.

But since at the edge the rbridges, just like bridges, need to learn the 
location of the MAC address from received frames, this still doesn't 
prevent your PC from sourcing packets with my MAC address, thereby 
causing packets to be routed towards you. This is compatible with bridge 
behavior ;-)

If we want to prevent this we need something different (hence 
incompatible) at the edge. One way would be to use 802.1X at the edge, 
and some EAP backend which associates the authenticated identity with 
the allowed MAC address. If you do that, then the rbridges don't need to 
learn from received packets but can instead use the completion of the 
802.1X EAP exchange as the time when the route is injected.

 > than the real or virtual end systems inside my box.

I assume you might want to be able to have a single MAC address and 
receive packets over multiple ports - with the rbridges using the 
shortest path. Is this correct?

That is more of a functional problem than a security problem I think.
Since end stations might move around, one would assume that when a MAC 
address appears on a different port, perhaps on a different rbridge as 
well, that the host has moved. Thus it would make sense to add the route 
which points to the new place, and remove the route that points to the 
old place.

But in your case you would need that both routes remain in place 
somehow. Perhaps we can do that by being smarter about when we remove a 
route for a MAC address?

I don't think 802.1X type security changes this, because 802.1X doesn't 
(reliably) indicate when something goes away.

    Erik

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu, 13 Oct 2005 17:15:01 -0400

> shortest path. Is this correct?

Exactly.  You'll get better performance when all paths are working, and
simple failover when they aren't.

> That is more of a functional problem than a security problem I think.

so, a simple way to do this functionally is for the host to just become
an rbridge.  but then historically many sites are organized such that
the people who administer the network don't trust the people who run the
hosts and vice versa.....

> somehow. Perhaps we can do that by being smarter about when we remove a 

yup.  routing protocols already provide a way to solve that problem, but
then you get into the organizational issue alluded to above.

					- Bill