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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Acee Lindem writes:
 
> The OSPFv3 autoconfiguration draft was cloned and presented in the
> ISIS WG (http://www.ietf.org/id/draft-liu-isis-auto-conf-00.txt). In
> the ISIS WG, there was a concern that the resolution of a duplicate
> system ID did not include the amount of time the router was
> operational when determining which router would need to choose a new
> router ID. With additional complexity, we could incorporate router
> uptime into the resolution process. One way to do this would be to:
>  
>      1. Add a Router Uptime TLV to the OSPFv3 AC-LSA. It would include
>         the uptime in seconds.
>  
>      2. Use the Router Uptime TLV as the primary determinant in
>         deciding which router must choose a new OSPFv3 Router
>         ID. Router uptimes less than 3600 (MaxAge) seconds apart are
>         considered equal.
>  
>      3. When an OSPFv3 Hello is received with a different link-local
>      	source address but a different router-id, unicast the OSPFv3
>      	AC-LSA to the neighbor so that OSPFv3 duplicate router
>      	resolution can proceed as in the case where it is received
>      	through the normal flooding process. This is somewhat of a
>      	hack as the we'd also need to accept OSPF Link State Updates
>      	from a neighbor that is not in Exchange State or greater.
>  
> An alternative to #3 would be to use Link-Local Signaling (LLS) for
> signaling the contents of the OSPFv3 AC-LSA. However, you'd only want
> to send the Router-Uptime and Router Hardware Fingerprint when a
> duplicate Router-ID is detected. This requires implementing the
> resolution two ways but may be preferable since it doesn't require
> violating the flooding rules.
>  
> In any case, I'd like to get other opinions as to whether this problem
> is worth solving.
>  
> Thanks,
> Acee


Acee,

If the basis for router-id on boot up results in a fixed value, and if
a duplicate will occur on a give network, then which of two duplicate
routers gets that value may change after one of them reboots.  If
uptime is not considered, it will never change as long as one router
stays up at any given time.

We are talking about a very low probability event (a duplicate) except
if this is a DoS attack and then either using or not using uptime
won't matter since the attacker will claim an impossibly long uptime.

Curtis