Subject: [rbridge] Rbridge port security

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 20 Apr 2007 15:53:12 -0400

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.

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

Thanks,
Donald

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 20 Apr 2007 13:22:02 -0700

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. 
> 
> Unless there is some objection, this will be added to the
> protocol specification and should probably be mentioned in the
> architecture document. 
> 
> Thanks,
> Donald
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

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.

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 topoloty", "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.

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

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.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 21 Apr 2007 16:49:08 -0400

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

> course, the zero configuration default would be to accept TRILL

@@@ 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.

Two questions:

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

	the pre-configured topology", "all discovered RBridges

@@@ 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.

@@@ 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.

@@@ 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

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 23 Apr 2007 09:12:38 -0700

Eastlake III Donald-LDE008 wrote:

> 
> @@@ 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

I could even see a requirement that there MUST be a method
that once enabled can ensure that no RBridge enapsulated
will be accepted via RBridge-disabled ports, and that two
mechanisms known to achieve this are...

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 25 Apr 2007 08:57:49 -0500

Caitlin,

	We need to be careful at this point about what we claim
to know will work...  :-)

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler
> Sent: Monday, April 23, 2007 12:13 PM
> Subject: Re: [rbridge] Rbridge port security
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 25 Apr 2007 09:09:19 -0500

Donald,

	In the past, it has not been necessary to explicitly state
this sort of thing, except in some general way.  Otherwise, it is
easy to get snarled up in phraseology around thinsg like "RBridge
enabled ports" and so on.

	As an historical example (I am sure there are others), the
concept of global label spaces in MPLS is intended to be similarly
constrained.

	To a certain extent, we don't want to get wrapped up around 
an axle in trying to tell people how to build good implementations
- our focus should be on interoperable implementations, right?

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, April 20, 2007 3:53 PM
> To: Rbridge at postel.org
> Subject: [rbridge] Rbridge port security
> 
> Hi,
> 
> document to hit
> configuration
> course, the zero

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 25 Apr 2007 07:51:08 -0700

I agree with Eric, I am not sure I want to specify a specific port
configuration variable for this particular case.

Products will implement this through a potentially more complex scheme
that may include trusted/non-trusted ports/VLANs, authentications, ACLs,
etc.

-- Silvano

> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, April 25, 2007 7:09 AM

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 25 Apr 2007 11:14:57 -0400

Eric,

Sure, we don't want to get too bogged down in details. On the other
hand, while some of the IESG comments on the routing requirements
document seem to be based on a misunderstanding of the purpose of that
document, I still feel that security and management will both be a
primary concerns for the architecture and protocol documents.

Our charter requirement of "zero or minimal" configuration is helpful in
motivating a default configuration for Rbridges which has security
weaknesses that parallel those of unmanaged bridges. However, I think we
are going to have to say something about management and provide for a
standard way to configure Rbridges to provide at least the suggested
ability to not run IS-IS on selected ports.

Donald

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
Sent: Wednesday, April 25, 2007 10:09 AM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Rbridge port security

Donald,

Thanks!
--
Eric Gray
Principal Engineer
Ericsson

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 25 Apr 2007 10:32:43 -0500

Donald,

	I can't say that I understand why.  Is there nothing along
the same lines in any of the IS-IS specifications?  If there is 
not, why are we expected to make statements about IS-IS security
that are likely to apply to a more general problem?  If there is,
cannot we simply refer to that?

	While I tend to agree that there should be a general way to
manage devices to accomplish identical results - rather than ask
each vendor to come up with their own and all users/operators to
deal with the associated complexity.  But, as Silvano indicated,
this may not be done the same way for each vendor and - more
importantly - we are not in an experiential position to guess (at
this point) what way is the best way to handle this particular
set of security issues...

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Wednesday, April 25, 2007 11:15 AM
> To: Eric Gray (LO/EUS); Rbridge at postel.org
> Importance: High

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 25 Apr 2007 23:14:48 -0400

Hi Eric,

There are IESG members who will be intent on assuring that Rbridges are
manageable and have reasonable provisions for security and I tend to
agree with them. See below at @@@.

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
Sent: Wednesday, April 25, 2007 11:33 AM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Rbridge port security

Donald,

@@@ IS-IS might be the biggest component an RBridge but it is not all of
it. The concern will be with the management and security of Rbridges,
not just of their IS-IS component.

@@@ Looks like the IS-IS MIB is in RFC 4444. It's probably pretty
thorough. At least the RFC is over 100 pages :-) If it covers this
point, of course we could just reference it. Looks like 802.1 bridge
MIBs are in RFC 4188 and RFC 4363. If someone is familiar with these
MIBs, or is willing to read them and comment on their applicability to
TRILL, I think that would be very useful for this working group.

@@@ I don't buy that we have to deploy Rbridges and have experience
before we specify some basic security provisions.

@@@ I think that if we want to get it approved for publication, the
Architecture document will have to say what protocol we expect to be
used to manage RBridges, e.g., SNMP, and may have to say how we expect
them to be configured, e.g., via a TRILL MIB. We already have at least
one new per-Rbridge configuration variable, called RequestTree in
protocol draft -03.

@@@ I don't think the Architecture draft needs many details. Nor do all
the details necessarily have to be in a successor to the current
protocol specification as there could be a separate document on
management.

@@@ Thanks,
@@@ Donald

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> easy to get snarled up in phraseology around things like "RBridge

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 26 Apr 2007 13:39:28 -0500

Donald,

	Specific excerpts from your response below:

	Good, because I ain't sellin' it.

	For control plane activities, we have 4 things to consider
	(and address) in the interactions between RBridges:

	1.  IS-IS (as extended) interactions - presumably we will not
	    define new security mechanisms (in TRILL) that apply more
	    generally to IS-IS.
	2.  Bridge control interactions - we WILL NOT define security
	    mechanisms that apply to this general area, whatever the
	    IESG may, or may not, feel about existing L2 exposures.
	3.  Merged bridging and IS-IS interactions that introduce new
	    vulnerabilities not encountered previously.
	4.  Other vulnerabilities introduced in RBridge interactions
	    not specifically related to either bridging or IS-IS.

	It cannot be over-emphasized that it is only in interactions
	between RBridges that any of these things become relevant in
	defining RBridge control protocol specifications, including
	those relating to security.

	Items 3 and 4 above are the areas where we will need to say
	something directly about security - both what the risks are 
	and how we feel they might be addressed.  But what we say is 
	likely to be largely based on a SWAG - except where we may 
	have experience in interactions between multiple RBridges, 
	built by multiple RBridge vendors.  To think otherwise, is - 
	IMO - overly optimistic.

	Hence, what we say should be said with this in mind; i.e. -
	we need to state what we think the issues will be, but also
	acknowledge that the list is likely to be incomplete. AND we
	need to propose mechanisms that address at least those parts
	of any specific security solution that are related to how a
	set of RBridges need to interact with each other in dealing
	with the issues we know about.  

	There is nothing in any of this that implies we should not
	define "basic security provisions."

@@@ I don't think the Architecture draft needs many details. 
    Nor do all the details necessarily have to be in a successor
    to the current protocol specification as there could be a 
    separate document on management.

	Agree.

@@@ I think that if we want to get it approved for publication,
    the Architecture document will have to say what protocol we
    expect to be used to manage RBridges, e.g., SNMP, and may 
    have to say how we expect them to be configured, e.g., via 
    a TRILL MIB.

	Possibly, but I believe it is safe to say that this is a 
	new requirement of architecture documents, assuming it is
	a requirement even now.  I don't know - off hand - of a 
	single architecture document in the RFC database right 
	now that addresses this aspect of a device or solution 
	architecture.

	I looked at a number of them, just to make sure I hadn't
	missed out on this aspect in existing architecture RFCs,
	and found exactly one single example of an architecture
	RFC that says anything specific about how a protocol is
	going to be managed.

	The ones I looked at included at least a dozen of the 
	most recent RFCs on architecture.  The exception was RFC
	4655 - which has an experimental "manageability section" 
	and includes an operational model explicitly based on use
	of a network management system.

	That RFC does not mention SNMP, but it does state that 
	there must be a (one or more) management MIB(s) for 
	managing the system that architecture defines.

	The inclusion of manageability considerations is based on 
	an "experiment" that is currently in Internet Draft form,
	and that (currently) addresses PCE documents only.

	I believe that there is no requirement for us to include
	such a section (at present) and that doing so requires a
	consensus from the working group (to include that same
	section in all working group documents).

	Hence, I am inclined to believe that any IESG member who
	proposes to make this a major issue is simply being a tad
	on the capricious side...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, April 25, 2007 11:15 PM

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 26 Apr 2007 12:41:26 -0700

rbridge-bounces at postel.org wrote:
> Hi Eric,
> 
> There are IESG members who will be intent on assuring that
> Rbridges are manageable and have reasonable provisions for
> security and I tend to agree with them. See below at @@@.
> 

That's valid, and we can provide security guidance even before
deployment (although Eric raised a valid point on the exact
wording of that advice).

My main concern is that we do allow multiple methods of
achieving the goal of only accepting RBridge encapsulated
traffic on ports where it is reasonable for a known RBridge
to have sent them.

Specifically, as part of its overall RBridge/Bridge functionality,
an RBridge MAY already have anti-spoofing protections that guard
against ANY frame arriving on a port that is inconsistent with
the source address of the frame. Further, I believe it is a safe
statement that any network middlebox is always free to choose
not to associate with other network elements when the local
configuration indicates that it would be unsafe or against
administrative policy to do so.

Therefore, without needing to add something to the protocol
specifications, I believe an RBridge could already be configured
with instructions that amount to "join NO RBRidge-collective
that claims to have RBridges on port X", or "port X support
is limited to at most N MAC addresses, none of which may be
an RBridge", or even "only the following MAC addresses are
supported on port x".

That implies that a totally safe method of controlling where
RBridges can exist could be implemented with all of the
*additional* security checking being done during RBridge
discovery. *Existing* per-frame anti-spoofing techniques
would not need to be enhanced, no matter how slightly.
Shifting from MUST to SHOULD does't really solve the
problem. I would argue that an RBridge SHOULD NOT perform
per-frame security checks that are completely redundant.
If the per-frame checks are generalize anti-spoofing checks
then there is an equivalent security measure in place then
there is no point in also doing redundant per-frame checks.