Hi Manav, 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 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.
BTW, can you please explain how rollover of the sequence number is expected to be handled in the new draft? Thanks, Srini. P.S> Have changed the "subject" ;-) -----Original Message----- From: Bhatia, Manav (Manav) [mailto:[email protected]] Sent: Thursday, February 17, 2011 9:57 PM To: Srinivasan K L; 'Alan Davey'; [email protected] Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3 Hi Srini, While 3623 alludes to using a clock to generate the seq number, I don't think we should, as the clock can go back in time, which can disrupt OSPF routing. There is no change in the crypto sequence number mechanism in this draft and we will be able to do GR similar to how its done for OSPFv2. Cheers, Manav > -----Original Message----- > From: Srinivasan K L [mailto:[email protected]] > Sent: Thursday, February 17, 2011 8.31 PM > To: Bhatia, Manav (Manav); 'Alan Davey'; [email protected] > Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3 > > 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
