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

[Silvano Gai]

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