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

[Anton Smirnov <[e-mail]>]

    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
>