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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"Les Ginsberg (ginsberg)" writes:
> 
> 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


Les,

Excluding DoS attack, we are talking about a one in 4 billion case
(for any two routers, so with 400 routers, still well under one in 1M)
where two routers hash a MAC address or pick a one time random number
from out of nowhere and end up with the same number.

If that does happen (and one in 1M is certainly possible), then it
would be nice if the routers always ended up with the same router-id.
This could be accomplished by some fixed method such as hashing a
constant with the first choice or router-id or using the router-id as
a seed for the random number generator (which will pick the same
sequence of random numbers each time).  If this is done, then a
conflict would always produce the same set of next picks.  The set of
routers in a given network would always end up with the same
router-ids once they all came up and if only one went down at a time
then it would always end up with the same router-id when it came up.

Zero conf was mainly intended for unmanaged networks (motivated by
work in the homenet WG).  In these small unmanaged networks it doesn't
matter which router gets what router-id as long as they end up unique
and convergence is in a reasonable time relative to keeping eyeballs
happy.  It could be applied to enterprise or providers but in either
case having the routers end up with the same router-ids would make for
easier management.

For your scenario to matter at all with current rules, both routers in
the conflict would have to go down.  If only the one that is preferred
goes down, the other is not going to change its router-id as a result
so when it comes up it gets its first pick with no conflict.  If the
one that was not preferred goes down, it comes up, sees a conflict and
takes its second pick (loses the conflict every time).  It is only if
they both go down and the one that normally loses the conflict comes
up first that there is a change in router-id.  That too can be solved
with a rule that you always come up with the last router-id used.

Curtis


> > -----Original Message-----
> > From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem
> > Sent: Thursday, February 06, 2014 5:12 PM
> > To: Curtis Villamizar
> > Cc: OSPF List
> > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
> > autoconfig-05.txt
> > 
> > Hi Curtis,
> > I agree and believe the significance of this use case where a new router is
> > inserted into an auto-configured domain has been greater exaggerated.
> > Thanks,
> > Acee
> > On Feb 5, 2014, at 3:58 PM, Curtis Villamizar <[e-mail]> wrote:
> > 
> > >
> > > 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
> > 
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf