Subject: [rbridge] Optional configuration of RBridge nickname

From: Radia.Perlman at sun.com ([email-masked])
Date: Thu, 03 May 2007 07:27:21 -0700

I think it is perfectly reasonable to have some RBridges configured with nicknames, and others not.
For example, some RBridges might be hosting more critical parts of the network. Or just that people in
charge of different parts of the net might have more energy for configuring nicknames.

I can also imagine people wanting priority for nickname.

Radia

----- Original Message -----
From: "Eric Gray (LO/EUS)" <eric.gray at ericsson.com>
Date: Thursday, May 3, 2007 6:24 am
Subject: Re: [rbridge] Optional configuration of RBridge nickname

> Silvano,
> 
> 	I believe that it is easily arguable that having a network
> in which some devices are configured not to negotiate, while the
> rest are not so configured (and default to negotiation) MUST be 
> considered a configuration error.  In many ways, this SHOULD be 
> considered the same sort of error as might occur if two devices 
> were configured with the same value.
> 
> 	One mitigating factor for this particular configuration 
> error is that one very likely way in which it would occur - i.e.
> - as a result of powering up an unconfigured device, is a "safe"
> operation if the (default) negotiation scheme favors the "status
> quo" assignment (as I believe we all have agreed it MUST).
> 
> 	Another likely pair of scenarios are as follows:
> 
> A) one in which a new device is added to an existing deployment 
>   where the existing devices are using negotiation and the new 
>   device is configured with a value that just happens to be the
>   same as one that an existing device has negotiated 
> 
>   - is clearly analogous to -
> 
> B) one in which a new device is added to an existing deployment
>   where the existing devices are configured with values (and
>   not using negotiation) and the new device is configured with
>   the same value as one that has previously been configured 
>   for an existing device.
> 
> 	I am reasonably confident that these SHOULD be viewed as
> simple configuration errors in both cases.
> 
> 	I suggest that it follows from this line of reasoning that
> it MUST always be possible to create a conflict situation as a 
> result of configuration errors.  Hence it should also follow that
> a simpler approach is more desirable than a more complicated one.
> 
> 	As the saying goes, let's apply the KISS principle and do
> what makes the most direct sense in terms of the goal we want to
> achieve.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [sgai at nuovasystems.com] 
> > Sent: Wednesday, May 02, 2007 7:50 PM
> > To: Eric Gray (LO/EUS); Radia Perlman
> > Cc: rbridge at postel.org
> > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > Importance: High
> > 
> > 
> > Eric, 
> > 
> > I think you are reading it correctly and having an implementation to
> > support a way to shut nickname-negotiation off is what we need.
> > 
> > The problem is that after I have manually configured a nickname 
> on an
> > RBridge I need to be sure that no other RBridge in the network 
> selects> it.
> > 
> > I also need to take into account that due to a mistake I can 
> manually> config the same nickname on two RBridges.
> > 
> > One thing after the other we ended up with Radia proposal, but if 
> you> have a better one, we are happy to listen.
> > 
> > Cheers
> > 
> > -- Silvano
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Gray (LO/EUS) [eric.gray at ericsson.com]
> > > Sent: Wednesday, May 02, 2007 10:17 AM
> > > To: Silvano Gai; Radia Perlman
> > > Cc: rbridge at postel.org
> > > Subject: RE: [rbridge] Optional configuration of RBridge nickname
> > > 
> > > Silvano,
> > > 
> > > 	Perhaps I am reading your requirement incorrectly,
> > > but it sounds to me that it could be as easily addressed
> > > by requiring that implementations support a way to shut
> > > nickname-negotiation off.
> > > 
> > > 	Consider simply having a pair of management objects
> > > - one to disable auto-nickname negotiation, and another
> > > (which must be assigned a value if the first is disabled)
> > > that contains the configured nickname.
> > > 
> > > 	In my opinion, that would be a much more acceptable
> > > approach - especially in comparison with using priority
> > > as a mechanism for varying the outcome of auto-negotiation
> > > without actually turning it off.
> > > 
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [sgai at nuovasystems.com]
> > > > Sent: Wednesday, May 02, 2007 12:06 PM
> > > > To: Eric Gray (LO/EUS); Radia Perlman; rbridge at postel.org
> > > > Subject: RE: [rbridge] Optional configuration of RBridge 
> nickname> > > Importance: High
> > > >
> > > >
> > > > Eric,
> > > >
> > > > There is a strong requirement in Enterprise to disable any 
> form of
> > > > autoconfiguration. I requested Radia to support a way to 
> manually> > > configure Nicknames. I am not asking this being the 
> default,> > > but it must
> > > > be supported.
> > > >
> > > > The solution that Radia has put together is satisfactory 
> > for me. If
> > I
> > > > want to manually configure a nickname I will do it and set the
> > highest
> > > > priority.
> > > >
> > > > Lacking a secure authentication scheme the network can be 
> attacked> by
> > > > any PC in a much easier way.
> > > >
> > > > --Silvano
> > > >
> > > > > -----Original Message-----
> > > > > From: rbridge-bounces at postel.org
> > [rbridge-bounces at postel.org]
> > > > On
> > > > > Behalf Of Eric Gray (LO/EUS)
> > > > > Sent: Wednesday, May 02, 2007 3:31 AM
> > > > > To: Radia Perlman; rbridge at postel.org
> > > > > Subject: Re: [rbridge] Optional configuration of 
> > RBridge nickname
> > > > >
> > > > > Radia,
> > > > >
> > > > > 	I would object strenuously to the use of a priority
> > > > > value in resolving the "ownership" of a nickname.
> > > > >
> > > > > 	The over-riding priority has to be determined in a
> > > > > way that ensures the existing network continues to work
> > > > > if a new device is inserted (i.e. - it would be best if
> > > > > any device were going to fail, it should be the one that
> > > > > has just been added).
> > > > >
> > > > > 	Adding "priority" would allow any device to assert
> > > > > a high priority ownership of any nickname currently in
> > > > > use, which would then make it trivially easy to stage a
> > > > > network disabling attack.
> > > > >
> > > > > 	Having it be so easy to attack the network, would
> > > > > necessitate mandatory defenses, almost certainly meaning
> > > > > that configuration would be required - possibly excepting
> > > > > the option of having the very highest priority value be
> > > > > the default assumed when no configuration is done at any
> > > > > RBridge.
> > > > >
> > > > > 	In either case (configuration absolutely required,
> > > > > or default highest priority with no configuration) would
> > > > > defeat your purpose.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > > > Principal Engineer
> > > > > Ericsson
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: rbridge-bounces at postel.org
> > > > > > [rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > > > > > Sent: Wednesday, May 02, 2007 12:26 AM
> > > > > > To: rbridge at postel.org
> > > > > > Subject: [rbridge] Optional configuration of RBridge 
> nickname> > > > >
> > > > > > Someone suggested that it would be useful to allow
> > > > configuration of
> > > > > > nicknames, so
> > > > > > that nicknames can be more stable, and there would be no
> > > > worry of an
> > > > > > RBridge coming
> > > > > > up and usurping a nickname from someone else. I'd like:
> > > > > > a) for it to remain possible to be zero configuration (as 
> in,> not
> > > > > > necessary to configure
> > > > > > a nickname
> > > > > > b) allow a mixture of configured and unconfigured nicknames
> > > > > > c) work even with misconfiguration (configuring two RBridges
> > with
> > > > the
> > > > > > same nickname)
> > > > > > d) never allow an unconfigured nickname to accidentally 
> usurp> > > > > a nickname
> > > > > > from
> > > > > > a ocnfigured RBridge
> > > > > >
> > > > > > So I'm proposing the following:
> > > > > >
> > > > > > a) allow configuration of a nickname value
> > > > > > b) have a "priority" value for owning a nickname
> > > > > > that can also be configured, which I'd propose would 
> > be an 8-bit
> > > > byte,
> > > > > > where only the bottom 7 bits can be configured
> > > > > > c) the 8th bit of the priority byte (the most significant
> > > > > > bit) indicates
> > > > > > whether
> > > > > > the nickname was configured or not
> > > > > > d) the default is priority=0 for RBridges that have not been
> > > > > > configured with
> > > > > > a nickname value, and priority=128 (top bit 1, rest 0) 
> for an
> > > > > > RBridge that
> > > > > > has been configured with a nickname
> > > > > > e) other values of nickname priority might be useful. For
> > > > > > instance, an
> > > > > > RBridge
> > > > > > implementation might increment the nickname value after it's
> > held
> > > > the
> > > > > > nickname
> > > > > > for some amount of time (say 10 minutes). Or someone might
> > > > > > want to configure
> > > > > > some RBridges to have a more stable nickname (by giving
> > > > them higher
> > > > > > priority).
> > > > > > f) Basically, the (nickname priority | system ID) is 
> > like the DR
> > > > > > priority in IS-IS,
> > > > > > where the DR election is based on (priority | system ID)
> > > > > >
> > > > > > Anyone object to this?
> > > > > >
> > > > > > 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
> > > >
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 3 May 2007 09:37:13 -0500

Radia,

	You're implying what is essentially "new information" to
me.  Are you suggesting that different portions of the same L2
domain may be under separate administrative management domains?

	That seems a little strange for a network in which at
leats one of the administrators is concerned about dynamic 
behavior in the network.

	If so, then how do we address the issue with contention
if more than one administrator wants to use a specific nickname
and so more than one sets the priority to the highest possible
value for the same configured nickname?

	Also, how do you propose to address the general problem
where two devices are configured with the same nickname but at
different priorities?  Does the one with the lower priority
fall back to negotiation?  If so, what effect does this have 
on network stability if the device with the higher priority 
starts to behave erratically?

	We need to consider potential _additional_ complexity
that might arise in _normal_ operation before we deliberately 
set out to get fancy.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] 
> Sent: Thursday, May 03, 2007 10:27 AM
> To: Eric Gray (LO/EUS)
> Cc: Silvano Gai; rbridge at postel.org
> I think it is perfectly reasonable to have some RBridges 
> configured with nicknames, and others not.
> For example, some RBridges might be hosting more critical 
> parts of the network. Or just that people in

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 4 May 2007 10:34:19 -0400

Hi Eric,

There are some things you seem to say that I don't understand.

(1) You seem to say that the nickname configuration feature, as
originally described, makes it much easier to attack the network by
causing what might be called "nickname churn". But it seems to me as
easy with the pure negotiation model for someone who was going to do
that to just hack an RBridge to assert the highest possible priority ID
and to repeated asset nicknames which other, lower priority Rbridges,
have so as to force them to change. So how does the nickname
configuration feature make such disruption that much easier?

(2) You seem to say that the nickname feature is very complex. But I
just don't see that. With the existing negotiation, you are doing a six
byte unsigned integer compare to get relative priority. With the
nickname configuration feature you are doing a seven byte unsigned
integer compare and adding something like a couple of MIB variables into
the Rbridge MIB you already have to have. How is that so complex? 

(3) On the tied conflict issue, you seem to say that adding the nickname
configuration feature somehow changes things. But as far as I see
whether you have all configured names or all negotiated names or a
mixture you can always end up with some sort of tie as long as you have
a malicious RBridge. How is a tie for highest priority between two
configured nodes which claim to have the same nickname, same configured
priority and ID any different from a tie between two negotiating nodes
which claim to have the same nickname and same ID/priority?

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eric Gray (LO/EUS)
Sent: Thursday, May 03, 2007 10:37 AM
To: Radia.Perlman at sun.com
Cc: rbridge at postel.org
Subject: Re: [rbridge] Optional configuration of RBridge nickname

Radia,

	That seems a little strange for a network in which at
least one of the administrators is concerned about dynamic 
behavior in the network.

--
Eric Gray
Principal Engineer
Ericsson

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Fri, 4 May 2007 10:03:54 -0500

Donald,

	Not sure how, but you've missed my MAIN POINT, and
completely misunderstood everything else I said.

	I object to the use of priority, not - as you have
apparently misunderstood me to have said - to configuration
of nicknames.

	That said, I have no way to respond to your questions
as they appear to be addressing something I have not said.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Friday, May 04, 2007 10:34 AM
> To: Eric Gray (LO/EUS)
> [mailto:rbridge-bounces at postel.org] On

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 4 May 2007 13:34:07 -0400

OK,  Sorry,
Donald 

-----Original Message-----
From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
Sent: Friday, May 04, 2007 11:04 AM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] Optional configuration of RBridge nickname

Donald,

Thanks!
--
Eric Gray
Principal Engineer
Ericsson