A brief note on "meticulous" that may be helpful as we bring these documents into harmony.
On Mon, Apr 07, 2025 at 01:36:13PM -0400, Alan DeKok wrote: > Thanks. I will address these comments, and the updated text will be > available in the next revision of the document. > > > On Apr 6, 2025, at 8:04 AM, Yingzhen Qu via Datatracker <nore...@ietf.org> > > wrote: > > > > Document: draft-ietf-bfd-secure-sequence-numbers > > Title: Meticulous Keyed ISAAC for BFD Authentication > > Reviewer: Yingzhen Qu > > Review result: Has Issues > > > > I'm assigned to do an early OPS DIR review of this document. > > > > Thanks to the authors for working on this document. However I think > > the following major issues should be addressed before progressing the > > document. > > > > Major: > > > > My understanding is that this document introduces a new authentication > > type for BFD, and it's called Meticulous Keyed ISAAC. However I don't > > see where this term is defined. > > The following text is from the Introduction: > > 102 This document proposes the use of an Authentication method which > > 103 provides meticulous keying, but which has less impact on resource > > 104 constrained systems. > > > > "Meticulous Keyed" is a name given by the authors. Please explicitly > > define it in the document, and add reference to RFC5880. Discussion on the optimized authentication draft lead to the realization that we didn't have a similar section present in RFC 5880 covering packet reception authentication procedures. We're attempting to resolve that here: https://github.com/bfd-wg/optimized-auth/pull/61 Part of that deals with "what is meticulous". Section 9 (Security Considerations) in RFC 5880 help define: : Meticulous Keyed MD5 authentication is stronger yet, as it requires : the sequence number to be incremented for every packet. Replay : attack vulnerability is reduced due to the requirement that the : sequence number must be incremented on every packet, the window size : of acceptable packets is small, and the initial sequence number is : randomized. There is still a window of attack at the beginning of : the session while the sequence number is being determined. This : authentication scheme requires an MD5 calculation on every packet : transmitted and received. For MD5 mode (similar procedure applies to SHA-1 in a different section), RFC 5880 section 6.7.3 covers: : For Meticulous : Keyed MD5, the sequence number is incremented on every packet. [...] : For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a : circular fashion (when treated as an unsigned 32-bit value). And the authentication procedure in particular locks down the primary difference: : If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For : Keyed MD5, if the sequence number lies outside of the range of : bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when : treated as an unsigned 32-bit circular number space), the received : packet MUST be discarded. For Meticulous Keyed MD5, if the : sequence number lies outside of the range of bfd.RcvAuthSeq+1 to : bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an : unsigned 32-bit circular number space) the received packet MUST be : discarded. Thus, receipt for Meticulous Keying requires us to receive something in the range of the *next* sequence number. A repeat of the last accepted received sequence number is not sufficient. -- Jeff
