It seems sending side and receiving side should follow the 3th/3th rule, which will not violate both the description of mentioned OSPFv2 and OSPFv3 RFC.
Best Regards Aijun Wang China Telecom From: [email protected] <[email protected]> On Behalf Of Veerendranatha Reddy V Sent: Monday, March 8, 2021 11:30 AM To: [email protected] Subject: [Lsr] [OSPFv2/v3] Regarding Authentication process during last key expiry or no active keys of key chain Hi All, As per OSPF authentication RFCs , during last key expired/inactive key of key chain the behavior of authentication process is different between OSPFv2/v3 For OSPFv2 from RFC 5709, [ From Section 3.2] Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured. For OSPFv3 from RFC7166, [From Section 3] Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated. For new implementation for these RFCs, I am requesting to provide the suggested behavior. Sending side: 1) Should not send the packet until valid key configured on key chain. 2) Packet send without authentication. 3) Packet send with the last expired authentication key. Receiving side: 1) Ignore the packets until valid key configured on key chain. 2) Accept the packets without authentication. 3) Accept the packets matches the last expired key. Thanks & Regards, Veerendranath
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
