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

From: sgai at nuovasystems.com (Silvano Gai)
Date: Sun, 15 Oct 2006 18:24:38 -0700

Eric,

The fact that the network is under a single administrative domain and
the fact that different part of the network have different
users/security are not in contradiction.

Let's take a University, a single backbone interconnecting many networks
(Departments, Labs, Administration, External) and many users (Profs,
Students, Admin). Firewall, Routers and 5-Tuple ACLs are probably used
for security, but it is also important to guarantee that firewalls and
routers are not bypassed. Therefore it is possible to think that a
network administrator may want to disallow the RBdridges connecting the
Labs to talk directly with the Rbridges connecting the administrations
and so on.

Radia mentioned a Hospital Network: I think it has similar issues.

Clearly ingress/egress RBridge ACLs cannot be the only tool, but being
able to test in a generalized ACL the ingress and egress RBridge address
is valuable.

If we put the ingress RBridge address in the packet then products can
test it in value added features, if it is not there, such features
cannot be built.

In addition to ACLs, I have read that having the two RBridge addresses
can be useful for:
- Policy based forwarding
- Network Troubleshooting
- Hardware based learning

I think this WG should seriously consider inserting both addresses in
the shim header

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Friday, October 13, 2006 4:27 PM
> To: Silvano Gai; 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?)
> 
> 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
> -->

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 16 Oct 2006 10:03:15 -0700

Silvano Gai wrote:...
> - Hardware based learning

The source address tells you which source did the encapsulation, which
may have changed. It might be useful for debugging, but so might a lot
of other information; we can't fit a full set of diagnostics there.

Policy-based forwarding implies that the source rbridge is useful
information; as I noted in my other post, it can change while a packet
is in transit, so it doesn't really mean much anyway.

It'd be useful to understand what 'hardware based learning' refers to;
there are still source/dest MAC addresses used between the rbridge
components which support existing hardware learning ('smart bridges').

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061016/667328fe/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 18 Oct 2006 09:46:41 -0700

Silvano,

That sounds like a good argument for using VLANs.

But I have a more fundamental question. Are people accomplishing what 
you are requesting of RBridges using 802.1D bridges today?
If so, how are they doing it?

There is nothing in the 802.1D data plan which indicates the first 
bridge that forwarded a frame.

The reason I'm asking is because I see a big difference between asking 
RBridges to provide some new degree of filtering/security, and making 
sure it isn't any worse than a bridged network.

> I think this WG should seriously consider inserting both addresses in

I think the WG is; that's why there are all these emails ;-)

Regards,
    Erik