Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-autoconfig-05.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

Anton -

Everyone agrees that router-id duplication is a low probability event if (as you say) implementations follow the rules about selecting a router id. Nevertheless the draft - quite correctly IMO - defines how to resolve duplication if it occurs because it is still possible. My proposal is a simple extension to the existing tie breaker rules to lessen the probability that the network need be disrupted in the event router-id duplication occurs during normal maintenance/upgrade procedures.

I have proposed no changes to the router-id selection logic and I was not motivated by the possibility of poor implementations - though I think that point only adds to the value of my proposal. (Of course one may rightly wonder if an implementation doesn't correctly implement router-id selection whether it can be expected to correctly implement tie breaking - but I think we are wandering into areas we have no control over. Buggy implementations can disrupt a network and we hope the marketplace eventually resolves that issue by not buying such products.)

   Les

> -----Original Message-----
> From: Anton Smirnov (asmirnov)
> Sent: Friday, February 07, 2014 5:47 AM
> To: Les Ginsberg (ginsberg); Acee Lindem; Curtis Villamizar
> Cc: OSPF List
> Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
> autoconfig-05.txt
> 
>     Hi Les,
>     if I understand correctly, all this is in addition to RID
> duplication and resolution mechanisms, i.e. you do not expect that doing
> *only* this will render RID duplication resolution unnecessary, right?
> 
>     If RID selection algorithm is good (i.e. statistical spread of
> selected RIDs is even over the whole space) then quick math shows that a
> device joining home network with, say, 1000 already connected devices
> has less than 1 chance in billion to generate conflicting RID. To me
> this risk looks not worth solving.
>     The big question of course is in statistical quality of RID
> selection algorithm implementations. Since there will be many different
> implementations some of them are going to be subpar. And bad
> implementation may make probability of RID conflict close to 1.
>     Is this what you are worried about?
> 
> Anton
> 
> 
> On 02/07/2014 09:31 AM, Les Ginsberg (ginsberg) wrote:
> > So, I am one person who raised this concern to Acee - but the proposal
> outlined by Acee is not what I had in mind. There is no need to use "uptime"
> or to invent some unusual exchange of LSAs prior to Exchange state.
> >
> > Also, in regards to Curtis's comment - it is not DOS attacks that I am
> trying to mitigate here. As he says if an attacker is in your network and
> able to originate credible packets no strategy is safe.
> >
> > The motivating use case is to minimize disruption of a stable network when
> a new router is added or an existing router is replaced/rebooted. In other
> words non-disruptive handling of the common maintenance/upgrade scenarios.
> >
> > What I have in mind is this:
> >
> > 1)A router needs a way to advertise that it has been up and running for a
> minimum length of time - for the sake of discussion let's say 20 minutes.
> Routers then fall into two categories:
> >
> >    o Old routers (up >= minimum time)
> >    o New routers (up < minimum time)
> >
> > 2)When a duplicate router-id is detected, the first tie breaker is between
> old routers and new routers. The old router gets to keep its router-id and
> the new router picks a new router-id.
> > If both routers are "new" or both routers are "old" then we revert to the
> existing tie breakers defined in the document (link local address for
> directly connected routers and fingerprint info for non-neighbors).
> >
> > 3)Advertisement of the "old/new" state requires a single bit - but it has
> to be available both in hellos and the new AC-LSA. Adding it to the AC-LSA is
> easy to do. For hellos, there are two possibilities:
> >
> >     o Use one of the Options Bits
> >     o Use LLS
> >
> > Be interested in how folks feel about this.
> >
> >     Les
> >