In message <[email protected]> "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:[email protected]] 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:[email protected]] 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 <[email protected]> > > wrote: > > > > > > > > > > > In message <cf17dd4e.2696b%[email protected]> > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/ospf
