Hi Srini, Ok, so now were NOT discussing the Authentication Trailer draft! Thanks for clearing the confusion!
> While I too am not so keen on using the clock, it must be > admitted that > using the clock is a "cheap" way of generating non-decreasing sequence > numbers. Given that clock changes will not be frequent, it I don't think it's a reasonable to use a clock for generating sequence numbers citing the reason that clock changes will not be frequent. Even if it changes once the router does become vulnerable to attacks. > can be argued > that this is ok. But the new draft rules this possibility out > completely by > mandating the use of strictly increasing sequence numbers. So while GR > will/can work by the existing mechanism, the new draft makes > it difficult. > So it may be better to give a solution for this too. The existing GR mechanism will only work if you can somehow remember your last sequence number. If you have the ability to do that then you can easily increment your sequence number the next time you come up. > BTW, can you please explain how rollover of the sequence > number is expected > to be handled in the new draft? There are two proposals in the draft now. One uses the nonce and the session ID and the other uses the 64 bit crypto sequence. Lets first look at the latter, as that's much easier. When the router reboots, the most significant 4 bytes would increase by one and the helpers will accept the packets as they'll come with a seq number that's higher than what they have. In this case we don't even need the restriction that's currently placed in 3623 about preserving the sequence number across restarts. In case the WG decides to go by the nonce/session ID mechanism then we could add a note saying that the restarting router must preserve its FIB and other state information, such as the grace period, nonce, session ID and cryptographic sequence number for an interface, across the restart. I am not a big fan of preserving too much state across restarts and we can also think of mechanisms by which the restarting router need not preserve its nonce and session ID info across restarts. However, lets only spend time on this once we have some clarity on the approach the WG wants to take. If the WG decides to go by the expanded cryptographic sequence space then we don't need to worry about this. We will also add a note on the graceful restart mechanism in the next version of the draft. Cheers, Manav _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
