Hi Manav, With this new draft, since the sequence number MUST be strictly increasing, I think using the clock may no longer be an option. Also, unplanned GR can never be supported since at RouterDeadInterval, the rebooted router will be declared down and there would be no use in processing the Grace LSAs after that. Would this not be a significant restriction ? Maybe we can find a solution for this too....
Regardsm Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Bhatia, Manav (Manav) [mailto:[email protected]] Sent: Thursday, February 17, 2011 8:18 PM To: Srinivasan K L; 'Alan Davey'; [email protected] Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi Srini, This problem is not unique to this solution. As per RFC 3623: "The router may need to preserve the cryptographic sequence numbers being used on each interface in non-volatile storage. An alternative is to use the router's clock for cryptographic sequence number generation and ensure that the clock is preserved across restarts (either on the same or redundant route processors). If neither of these can be guaranteed, it can take up to RouterDeadInterval seconds after the restart before adjacencies can be reestablished and this would force the grace period to be lengthened greatly." Cheers, Manav ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Srinivasan K L Sent: Thursday, February 17, 2011 8.03 PM To: 'Alan Davey'; [email protected] Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi, This question has set me thinking on the draft "Security Extension for OSPFv2 when using Manual Key Management". When a router reboots, assuming that it cannot remember the last sequence number it used, how will it start re-establishing peers. Are the existing peers supposed to accept (temporarily maybe, without losing the previous sequence number information - anyway the challenge mechanism can protect against replay attacks) packets with a new (lower) sequence number that pass authentication. Or will it take RouterDeadInterval for the rebooted router to get accepted? In case it takes RouterDeadInterval, unplanned GR cannot be supported, since the first packets sent out will be grace LSAs, probably with lower (zero) sequence numbers. I think this should be explicitly covered in the draft. Regards, Srini. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Alan Davey Sent: Thursday, February 17, 2011 5:20 PM To: [email protected] Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 Folks I have read draft-ietf-ospf-auth-trailer-ospfv3-02 and have a few minor nits as follows. - After an unplanned graceful restart, a router may send Grace-LSAs in an LS Update packet before any Hello packets. Unless I am missing something, the draft should include such LS Update packets in the list of those that MUST have the AT-bit set. - In Figure 1, for the packet on the left hand side, the IP Header Length HL = PL + LL (not PL + AL). - In section 4.1 Authentication Trailer, in the Auth type bullet, the following wording be clearer; "At present, the only value defined is 1, to denote ..."? Regards Alan Davey Software Engineer, Network Technologies Division Metaswitch Networks [email protected] <mailto:[email protected]> +44 (0) 20 8366 1177 www.metaswitch.com <http://www.metaswitch.com/> _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
