[rbridge] Rbridge port security

[Eric Gray (LO/EUS)]

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  

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