Document: draft-ietf-bfd-secure-sequence-numbers Title: Meticulous Keyed ISAAC for BFD Optimized Authentication Reviewer: Mallory Knodel Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-bfd-secure-sequence-numbers-?? Reviewer: Mallory Knodel Review Date: 2025-08-13 IETF LC End Date: 2025-08-18 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies the provision of a Meticulous Keyed mode for Bidirectional Forwarding Detection (bfd) authentication. Major issues: Thanks very much for this draft. As others have pointed out, this document is clearly establishing a new terminology and a foundational specification as described in the bfd charter, however there persists inconsistency in how this is described. Separately I have found (capitalization preserved, indicating confusion about what is/isn't a proper noun): * "Meticulous Keyed ISAAC for BFD Optimized Authentication" (title) * "Meticulous Keyed ISAAC authentication" * "Meticulous Keyed ISAAC Authentication" * "Meticulous Keyed ISAAC for BFD Authentication" * "BFD Optimized Authentication using Meticulous Keyed MD5" * "Optimized MD5 Meticulous Keyed ISAAC Authentication" * "...Meticulous Keyed ISAAC Keyed..." (from draft-ietf-bfd-optimizing-authentication) It seems that the nomenclature should be somewhat patterned in format everywhere consistently thusly: * "Meticulous Keyed mode for BFD authentication" * eg, "Meticulous Keyed [ISAAC/SHA-1/etc] for BFD authentication" The rest of the variations seem to be an attempt to coin a proper noun, which may not be entirely necessary and because so many descriptors are involved, eg "BFD," "Optimised", that perhaps it would be challenging to ever remember their proper order. Thus one could instead just rely on "Meticulously Keyed" as the proper noun and treat the rest as adjectives or descriptors in context. I do agree with other reviewers' suggestions that without a clear definition that unfamiliar readers might be struggle to understand the core specification. I found reading the bfd charter and milestone drafts helpful and perhaps you could write a brief description in the introduction, perhaps as a second paragraph, about this document as it relates to the BFD's larger slate of work. Section 3 helpfully does some of this work. I appreciate Section 1.1. but I think it can be presented as an update to RFC5880 unself-consciously, for instance: In RFC5880 [RFC5880], "(sequence number excerpt)." Here the terms "meticulous keyed" and "meticulous keying" ... (final paragraph) means that the Sequence number is incremented on every new packet that is sent. The term "keyed" means that ... "Meticulous Keyed" therefore refers to BFD authentication type where each packet is unique, and can be authenticated. Just pointing out that if meticulous means unique and keyed means authenticated then 'meticulous keyed bfd authentication' means unique authenticated bfd authentication. This coarse simplification might illustrate how to streamline the terminology, to the extent that you can use this document and the optimizing-authentication draft to gently revise terms and definitions inherited from prior documents. Minor issues: * What is the reason that this draft is experimental? Is there something more stable that is or should be used instead that this replaces? If so, please clearly state that. * S 3.1. "originator of the packet is authentic" or "originator of the packet is authenticated"? * Document outline could be streamlined. Sections 4.1. and 6. have the same title but present different information. Perhaps Sections 4-6 could be better organized, or the current structure justified with more descriptive titles. * In security considerations I think the final sentence could be more explicit about the tradeoff between generator security and resource constraints and that picking something stronger like AES is infeasible in routing protocols. Nits/editorial comments: * S 3.1. "If / when" can just be "if" logically. * "page" and "next page" (rather than "next" page) need only be in quotes on the first use to indicate they are terms of art. * It's enough that "Your Discriminator" is in uppercase, so I think the use of quotes is never needed. It doesn't seem this convention is followed for other field names, or at least the document should harmonize how it indicates field names. Sometimes it seems that field entries are put within quotations, rather than field names. * Section 15.1. penultimate paragraph "dictionary attaches" should be "dictionary attacks". Again, appreciate all your work on this document. I hope these comments and suggestions can be helpful. -Mallory -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
