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
