Arent we mixing this draft with draft-bhatia-karp-ospf-ip-layer-protection-03?
If not, then I don't see why AT will create any new problems for GR? Cheers, Manav > -----Original Message----- > From: Acee Lindem [mailto:[email protected]] > Sent: Thursday, February 17, 2011 10.15 PM > To: Srinivasan K L > Cc: Bhatia, Manav (Manav); Alan Davey; [email protected] > Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3 > > Hi Srini, > The fact that graceful restart will be more difficult is part > of the cost of implementing this draft. One of the jobs of > the OSPF WG is determining whether the "medicine is worse > than the disease". In this case, the disease is well-timed > replay attacks and the medicine is the proposed solution. > Thanks, > Acee > On Feb 17, 2011, at 10:01 AM, Srinivasan K L wrote: > > > 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 > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
