[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Gray, Eric]

Silvano,

	I am still having difficulty in understanding why, in a single
layer 2 network (LAN) and in a common administrative domain, we should
be concerned about the possibility of attack from one portion of the
LAN and not be concerned about other portions of the same LAN.

	If you have suspected bad-guys in your LAN, inside the protection
typically provided by a router/firewall, why would the risk be common 
to one bridged segment and not a factor in others?

	I suspect that the concern you have - if applied to any bridged
segment connected to an RBridge might apply as well to bridged segments
that connect RBridges.  Consequently, it doesn't help to know what the
"ingress RBridge" is if that can be spoofed by a bad-guy operating in a
bridged segment connecting two or more RBridges.

	If - in fact - you know that there is a subset of "questionably
trustworthy" bridged segments, you should isolate them.  Typically
that would be done at the IP (network) layer.    

	Also, if you put your bad-guys in a cell, you station a guard on 
the cell, not at all the other doors in the building.

	If your intent is to prevent anyone in bridged segment "X" from
sending anything to bridged segment "Y", (this is a different problem)
why would you not put them in separate VLANs - thus forcing separation 
and forwarding via a router?

	We're not actually trying to replace the routing function, so we
would be stepping over the bounds to suggest that certain functions we
currently support using firewalls/gateways/routers should be subsumed
by RBridges.

	If you want to do filtering based on which bridged segment it is
going to arrive from, why would you do the configuration at arbitrarily
many egress RBridges rather than at the corresponding ingress RBridge?

	Generally the more places you have to do configuration, the more 
likely a configuration error is to occur.  

	Why, specifically, would the risk of a single misconfiguration 
error be considered more severe if it effects the entire LAN, when the 
trade off is potentially many such errors effecting many different 
parts of the same LAN in potentially many different ways?  

	You usually don't want to address risks of misconfiguration errors 
by introducing more configuration requirements.  Moreover, it is very
well understood that you don't want to block/drop on egress as you are 
them consuming network resources for frames/packets you will not deliver.

--
Eric


--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Friday, October 13, 2006 4:47 PM
--> To: Radia Perlman; Caitlin Bestler
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> Radia,
--> 
--> I will repeat myself,
--> 
--> Ingress ACLs are much weaker than egress ACLs. A single 
--> misconfigured
--> port opens the whole network to attack.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]
--> On
--> > Behalf Of Radia Perlman
--> > Sent: Friday, October 13, 2006 12:21 PM
--> > To: Caitlin Bestler
--> > Cc: rbridge at postel.org
--> > Subject: Re: [rbridge] Range of appllicability (was Re: 
--> TTL only - was
--> RE:
--> > New fields in shim header?)
--> > 
--> > Caitlin said:
--> > 
--> > >Given that an RBridge is presumably a single 
--> administrative domain,
--> > >why would you use the ingress-RBridge to *infer* a class 
--> of service
--> > >rather than just stating the class of service in the F-Tag?
--> > >
--> > I agree that for RBridges, source address filtering is 
--> best done at
--> the
--> > ingress RBridge, and that
--> > our trust model is that RBridges should trust each other 
--> not to forge
--> > the header fields. So that use
--> > of ingress RBridge in the shim header doesn't seem too compelling.
--> > 
--> > So let's see if the field makes sense for service classes.
--> > 
--> > It seems like there are two types of classes of service:
--> > a) those that affect the forwarding decision
--> > b) those that affect how you handle the packet (as in 
--> priority queue).
--> > 
--> > ********
--> > Let's first examine the use of ingress RBridge for the 
--> first type of
--> > service class:
--> > 
--> > The simplest forwarding decision is a single forwarding 
--> table, and you
--> > do a lookup based on destination
--> > address.
--> > 
--> > To use F-tags, you'd need a different forwarding table 
--> for each F-tag.
--> > 
--> > To also base forwarding decisions based on ingress 
--> RBridge, I guess
--> > you'd need to multiply the
--> > number of forwarding tables by the number of ingress 
--> RBridges? That
--> > certainly seems impractical.
--> > If you trust the ingress RBridge to put in the right 
--> F-tag, it seems
--> > like you wouldn't need both fields.
--> > 
--> > *******
--> > So, that leaves only one rationale I think for ingress 
--> RBridge...which
--> > is for priority, but the MPLS-like
--> > header already has a priority field.
--> > 
--> > The only thing I can think of is that different portions of the
--> > RBridged-topology would have different
--> > priorities for different ingress RBridges.
--> > 
--> > And speaking of filtering...I think my posts to rbridge 
--> aren't getting
--> > through, or at any rate, have a very
--> > long delay (as in many hours).
--> > 
--> > Radia
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > rbridge at postel.org
--> > http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->