[rbridge] TTL only - was RE: New fields in shim header?

[Gray, Eric]

--- [SNIP] ---
--> 
--> The issue is not Rogue RBridges, the issue is that in a network there
--> will be RBridges that will connect unsecured hosts/links and the network
--> manager may desire an easy way to restrict them to a subset of the TRILL
--> cloud.

Do you have a real deployment example in which an enterprise 
would not use firewalls and/or routers to protect an entire
LAN but would use bridges to protect portions of it?

This does not sound very practical to me.

In addition - if you don't filter at an ingress, and it is 
possible to spoof the inner source MAC address - how is it
useful to filter based on the ingress and egress RBridge at
any point other than the ingress?  If you do, you are only
saying that any traffic arriving from bridged segment "X" 
is not allowed to be delivered to bridged segment "Y" and -
if that is what you want to do, there are better ways to do
it than to use ACLs on a bridge (or RBridge).

--> 
--> > a larger shim header to optimize dropping their packets then
--> > things are in a pretty bad shape. If there are network elements
--> > that cannot ultimately be physically disconnected by the network
--> > administrator then they should probably be separated by a router
--> > and not included in the subnet.
--> 
--> In today world, any tool you can give a network administrator to
--> segregate traffic is welcomed.

I'd like to hear that directly from a network administrator.  There
are practical limits to the capacity of their "tool belt" and more
tools means even more administration/management complexity.

--> 
--> > 
--> > And given that any RBRidge header is not going to have IPSEC
--> > quality authentication the degree to which we can provide
--> > protection from a malicious RBridge is fundamentally limited.
--> > 
--> > Let's be realistic and keep security at the IP layer.
--> 
--> This is IEEE 802.1D replacement, there may not be an IP layer.

The request was "let's be realistic."  The statement that "there
may not be an IP layer" is a significant departure from realism,
in today's networks.

--> 
--> 
--> > The originally proposed short envelope solves the
--> > essential problems. The additional fields that Radia's
--> > recent draft suggested are all interesting. Many of
--> > them MIGHT help RBridges perform certain functions
--> > more efficiently. But I do not believe any of the
--> > extra fields are necessary, and my initial thought
--> > is that they do not justify eating away at the MTU.
--> 
--> I am much more concerned that TRILL will provide a superset of
--> the functionalities that 802.1D and all its variations provide, 
--> than saving few bytes in the shim headers. I think the times 
--> where optimizing to the last byte was important are long gone 
--> with 1 and 10 GE.

Herein lies the disconnect.  Attempting to support every variation
of 802.1D in specifications produced by this WG is a non-starter.

We therefore have to decide what is, and is not, in scope.

Since there are certainly existance proofs of tunneling technologies
that do not retain all of the information of the tunneled data in an
"outer" (tunneling) encapsulation (indeed, what would be the point
of tunneling otherwise), then it is completely legitimate to state
that this is out of scope.

--> 
--> -- Silvano
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->