[rbridge] Rbridge port security

[Eastlake III Donald-LDE008]

Hi Caitlin,

See below at @@@ 

-----Original Message-----
From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
Sent: Friday, April 20, 2007 4:22 PM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Rbridge port security

rbridge-bounces at postel.org wrote:
> Hi,
> 
> I'm continuing to work through the comments on our first
> document to hit the IESG, the routing requirements document.
> 
> Based on these, I would say that we have to add a per port
> configuration variable for Rbridges that indicates there are
> no Rbridges connected via that port. The effect would be that
> any TRILL frames arriving on that port would be assumed to be
> forged and would be discarded. This would include frames
> claiming to be core or per-VLAN IS-IS messages as well as
> messages that claim to be TRILL encapsulated frames. Of
> course, the zero configuration default would be to accept TRILL
> frames on all ports. 

@@@ My message should have also said that IS-IS messages are not
emitted. (It does not need to say that TRILL encapsulated messages are
not emitted since an RBridge should never do that if it has not detected
any Rbridges out that port and it can't detect them if it doesn't
receive and emit IS-IS Hellos.) Probably the better way to say all this
is that it doesn't run the core IS-IS instance on that port.

> Unless there is some objection, this will be added to the
> protocol specification and should probably be mentioned in the
> architecture document. 
> 
> Thanks,
> Donald

Two questions:

Would the default be that a port was allowed to have
RBridge encapsulated traffic on it? Given the zero-
configuration intent I think that default needs to
be made explicit.

@@@ Sure. The default has to be such that Rbridges will provide their
intended service.

Secondly, does this really need to be a per-frame check
that is specific to RBridge traffic?

Wouldn't the following be sufficient?

	An implementation MAY have configuration constraints
	on the results of RBridge discovery. Possible examples
	could include "discovered topology MUST be a subset of
	the pre-configured topology", "all discovered RBridges
	MUST be no more than 2 hops from X", "at most N RBridges",
	etc.

		And it SHOULD/MUST include the ability to configure
		ports that do not lead to other RBridges.

	Each RBridge MAY/SHOULD drop frames allegedly from other 
	RBRidges where the ingress port is inconsistent with the
	discovered topology.

That would make the RBridge specific logic pertain only during
RBridge discovery, and then allow generic "acceptable ingress
port" logic to apply rather than an RBridge specific rule.

@@@ I assume by "ingress port" in the two paragraphs above you mean the
port on which the Rbridge receives the frame, not the TRILL ingress,
which is where a frame gets encapsulated. I would agree that it is also
reasonable to drop frames received on a port which the Rbridge believes
has no other Rbridges attached to it even if Rbridge discovery isn't
configured off for that port.

If a given bridge already has anti-spoofing features it wouldn't
make much sense to require additional RBridge specific checks.

@@@ Well, a bridge isn't an Rbridge and I wasn't proposing to make any
changes in bridges.

@@@ I believe that bridges sometimes have a per port "anti-spoofing"
feature which could be expressed as controlling whether or not *STP runs
on that port (i.e., whether it discards any received BPDUs and does not
emit any for that port). But such a feature would do nothing to protect
against forged TRILL messages. One way or another you have to either
expand the "anti-spoofing feature" configuration or add an additional
"anti-spoofing feature" which is Rbridge specific. Also, bridges don't
encapsulate or modify native frames so it really wouldn't make any sense
to say you want to block bridged frames but Rbridges do encapsulate
native frames so it is reasonable to block such "Rbridged" frames on
ports which are not supposed to have any Rbridges attached to them.

@@@ I think the best way to think of the feature I am talking about is
controlling whether or not the core instance of IS-IS runs on a port.
And to satisfy the eventual security and management considerations
review of our protocol draft, there will have to be some standard way to
configure this, presumably via SNMP and a standard MIB.

For an example, an RBridge built into a piece of equipment could
indeed know that its internal "ports" have no RBridges on them.
But it might know that because it knows the MAC address associated
with each of those ports. It can easily enforce that they are not
RBridges during discovery, and it can easily enforce that the only
traffic originating on those ports have the correct MAC address.
Given those checks, I see no need for such an implementation to
dynamically block RBridge encapsulated frames from originating
on the internal ports.

@@@ I would have no problems with using "SHOULD" for the default of
running the core IS-IS and most of this, with an example of an exception
being a special purpose device where you have additional knowledge.

@@@ Thanks,
@@@ Donald