Hi Ketan, authors,
On the general comment below: I agree with Ketan that the normative references
on the other 2 documents doesn't seem to be needed. I believe we need an
informative reference on draft-ietf-bfd-secure-sequence-numbers (because of
section 6 in draft-ietf-bfd-stability-18), and no reference on
draft-ietf-bfd-optimizing-authentication is needed. Good catch.
Regards,Reshad.
On Thursday, May 15, 2025 at 07:06:00 AM EDT, Ketan Talaulikar
<[email protected]> wrote:
Hello Authors/WG,
Thanks for the work put into this document. It has been in the works for a long
time in an on/off mode. There is some more work needed before it can be taken
up for IESG evaluation.
I would like to share my review of the v18 of this document.
General Comment/Suggestion: This is about the contents of this document and its
relationship with draft-ietf-bfd-optimizing-authentication and
draft-ietf-bfd-secure-sequence-numbers. I believe this document does not depend
on those other two, at least not normatively as indicated today. This proposal
is self sufficient with the new null auth type and the two existing BFD auth
types that use meticulous incrementing sequence numbers. As such, for smooth
progression of this work, I would strongly recommend removing all references to
those drafts and the ISAAC-based auth types or the Optimized Auth from this
document. The draft-ietf-bfd-secure-sequence-numbers that actually specifies
the two ISAAC-based auth types can instead refer to the
draft-ietf-bfd-stability to indicate that those new auth types are suitable for
use for measuring BFD packet loss. This way, this document becomes independent
of the other two for its further processing.
Please find below my comments in the idnits output of v18 and look for <EoRv18>
at the very end of the review. If you don't see that, then likely the email has
been truncated by your email client and you should look at the BFD WG email
archive for the full version.
Thanks,Ketan
14 BFD Stability
15 draft-ietf-bfd-stability-18
17 Abstract
19 This document describes extensions to the Bidirectional Forwarding
20 Detection (BFD) protocol to measure BFD stability. Specifically, it
21 describes a mechanism for detection of BFD packet loss.
<major> The title/name of "BFD Stability" is misleading to me. It gives an
impression of how stable is the BFD session, as in - is it flapping a lot or is
staying up and stable for a long interval? Why not call this BFD Packet Loss
Monitoring ... or something like that which is a simple term and yet perhaps
gives the true picture of what this feature is about?
98 This document does not propose any BFD extension to measure data
99 traffic loss or delay on a link or tunnel and the scope is limited to
100 BFD packets.
<major> Please provide some text for justification for the experimental
status - something on similar lines as the other two documents will work just
as well.
120 The reader is expected to be familiar with the BFD [RFC5880],
121 Optimizing BFD Authentication
122 [I-D.ietf-bfd-optimizing-authentication] and Meticulous Keyed ISAAC
123 for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers].
<major> I see no reason for the above two references or dependencies in this
document. They seem unnecessary to me. What is the normative (must
have)dependency that I am missing? And why is even an informative reference
reallynecessary?
139 In a faulty datapath scenario, an operator can use BFD health
140 information to trigger delay and loss measurement OAM protocol
141 (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay
142 Measurement (DM)) to further isolate the issue.
<minor> Please provide informative references for the CFM and DM technologies
150 5. NULL Auth Type
<question> Why is a null auth type, or even a sequence number necessary for BFD
packet loss calculation? Is it not OK to expect that the other endpoint is
going to send X number of packets every interval? And if we don't get those X
packets at every interval, then we have a packet loss? Perhaps I am missing
something obvious and if so, it would be good to capture the rationale that
really needs these sequence numbers for this measurement.
179 Auth Key ID: The authentication key ID in use for this packet. Must
180 be set to zero and ignored on receipt.
<minor> s/must/MUST
216 6.1. Loss Measurement
218 Loss measurement counts the number of BFD control packets missed at
219 the receiver during any Detection Time period. The loss is detected
220 by comparing the Sequence Number field in successive BFD control
221 packets. The Sequence Number in each successive control packet
222 generated on a BFD session by the transmitter is incremented by one.
223 This loss count can then be exposed using the YANG module defined in
224 the subsequent section.
<major> Packets may be reordered and arrive with different delays. Let us say
that the
packet that was supposed to arrive in interval I were delayed to arrive in
interval
I+1. i.e., we get one extra packet in the interval I+1. This does not indicate
a packet loss in interval I, but the procedure above seems to log it as a
packet loss?
226 The first BFD authentication section with a non-zero sequence number,
227 in a valid BFD control packet, processed by the receiver is used for
228 bootstrapping the logic.
<major> Is the loss counter reset when the BFD session goes down? Is there a
notion of time period that is tracked/reported here? Is there a notion of a
percentage of BFD packets lost that is being reported? How useful is it to
simply report the lost packet count without any of these other contexts?
Looking at the model, the history of this data for the previous uptime is also
not being tracked. Have these aspects been considered by the WG?
239 Implementations MAY provide mechanisms wherein all expected packets
240 received across an expected interval but delivered out of order are
241 not considered lost packets.
<major> Why is this not a MUST? How is it ok to do incorrect and inaccurate
reporting of BFD packet loss? Please see my previous comment.
243 7. Stability YANG Module
<question> I am not an IETF YANG expert. I would like to check if there are
any issues with an experimental RFC augmenting a standards track YANG model.
599 9. Security Consideration
601 9.1. YANG Security Considerations
<minor> Please reorder the sections. I know some of the authors are YANG
champs, but let us not put the cart before the horse :-)
626 addition, and as stated in Out of Order Packets (Section 6.2), on
627 links such as LAG or ECMP, there is a possibility of packets being
628 delivered out of order. A strict comparison of increasing sequence
629 numbers may result in classifying those out of order packets as
630 packet loss.
<minor> Does this text blob not belong to the Null Auth or a separate BFD
Packet loss monitoring sub-section?
652 When the NULL Authentication type is used for BFD Stability purposes,
653 maliciously injected packets that do not reset the BFD session can
654 resemble high packet loss. Sessions such as, multi-hop routed paths,
655 tunnels without authentication, or MPLS LSP, therefore, have security
656 guarantees that are identical to situations where BFD is run without
657 authentication.
<minor> How about someone could manipulate the sequence numbers and give a
wrong idea of packet loss? Possibly raise false alarms?
<EoRv18>
