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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
