[rbridge] Rbridge port security

Wed Apr 25 20:14:48 PDT 2007

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,

	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?

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

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

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

> -----Original Message-----
> 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
> Subject: RE: [rbridge] Rbridge port security
> Importance: High
> 
> 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,
> 
> 	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 things 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  
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org 
> > [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,
> > 
> > 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
> > 
> 