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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"Les Ginsberg (ginsberg)" writes:
 
> One other thing I forgot to mention.
>  
> Using the mechanisms I define below, a modestly clever implementation
> could implement a startup mode where it does not advertise any
> reachability until it has formed at least one neighbor and acquired
> the full LSA database. At this point it should know whether it has a
> duplicate router-id or not and if so it can assign itself a new
> router-id without affecting forwarding behavior at all.
>  
>    Les


Good suggestion.

Curtis


> > -----Original Message-----
> > From: OSPF [mailto:[e-mail]] On Behalf Of Les Ginsberg
> > (ginsberg)
> > Sent: Friday, February 07, 2014 12:31 AM
> > To: Acee Lindem; Curtis Villamizar
> > Cc: OSPF List
> > Subject: Re: [OSPF] OSPFv3 Autoconfiguration - draft-ietf-ospf-ospfv3-
> > autoconfig-05.txt
> > 
> > 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
> > 
> > 
> > > -----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