Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines
draft-ietf-karp-bfd-analysis-08

This document could be strongly - both in describing the scaling issues for how BFD is run and the locality.  For instance, the difference between BFD sessions for a one-hop session where the TTL can be trivially checked and the BFD sessions run at ms granularity vs. multi-hop sessions where they can be much slower.

The document would really benefit from a section discussing deployment use-cases and discussing the attacks and appropriate mitigation in each of those scenarios.

As written, I don't feel that the draft conveys much useful or actionable information and is more likely to be interpreted as not quite understanding realistic deployments - which is a pity.

I am tempted to make this a discuss...

It would be helpful to distinguish between cases where a replay attack requires that you be on-link (e.g. some link-layer encapsulation) versus the cases such as ipv4/ipv6 maybe mpls that could potentially be injected /spoofed from offlink.

I agree with Stephen's comment and would also liked to have seen a better discussion in this draft on the issues.  A more complete discussion of vulnerabilities in the draft would have been helpful.  I'll move my discuss to a comment with the same reasoning as STephen, that more analysis is needed… although I'm not sure of the value of this raft without that analysis.

In addition to Stephen's points, I'd also like to highlight the following that came up during the SecDir review and has not been added into the draft:

A discussion of algorithm agility would be helpful and expanding on limitations (if any) rather than just adding stronger hash algorithms.  As Stephen points out, the computation factors may not be as bad as the author detailed in the draft from what we know of OpenSSL.

The draft should also explain how it came to the following premise, that BFD needs to use algorithms that match the routing algorithm strength.  It would be good to know if there is anything to it or not.  Are the attack models aligned?
   Moving the routing protocols to a stronger algorithm while using
   weaker algorithm for BFD would allow the attacker to bring down BFD
   in order to bring down the routing protocol.  BFD therefore needs
   to match the routing protocols in its strength of algorithm.

Should we be bothering with this draft given the last comment in the SecDir review: Lastly, RFC5880 (the BFD spec) says:
   An attacker who is in complete control of the link between the
   systems can easily drop all BFD packets but forward everything else
   (causing the link to be falsely declared down), or forward only the
   BFD packets but nothing else (causing the link to be falsely
   declared up).  This attack cannot be prevented by BFD.

Link to SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg04976.html

Is this text:

   There are several requirements described in section 3 of The Threat
   Analysis and Requirements for Cryptographic Authentication of Routing
   Protocols' Transports [RFC6862] that BFD does not currently meet:

still going to be true when it appears in an RFC? Perhaps “that BFD as defined in [RFC5880] does not meet”? or whatever the right reference would be …

This is not a DISCUSS as I think more analysis is needed on
the threats faced by BFD than is presented here (apologies if
that's elsewhere and I'm ignorant) and a later solutions
draft that doesn't do that can always attract a DISCUSS.
Anyway, the point is that simply complaining that the current
auth schemes don't work doesn't tell you what to fix.  (Note:
I am not saying that GMAC is the wrong answer, I'm saying
that there's not enough presented here to know so a solution
draft that says "look there - GMAC has to be right" could
well attract such a DISCUSS.)

As a separate general point, I have to say that this document
doesn't explain to the reader why there's a real problem with
crypto for BFD. And doing a HMAC in microseconds is not a
problem - opennssl tells me that it takes about 8
microseconds for a hmac-md5 over 1024 bytes on my laptop in
pure s/w - 10 milliseconds for 3 instances of HMAC is ages. I
think you're neglecting here to say that there are 1000's of
parallel sessions or something, but in any case, as presented,
the timing constraints do not seem to be at all hard which
makes the document less convincing that I believe ought be
the case. (Note - I do believe from chatting with folks that
there is some real problem with BFD security, but this
document does not capture that well as far as I can see.)

section 2: MD5 and SHA-1 are used with HMAC, right?  With
HMAC, collision resistance for the hash function is not the
required property, but rather pre-image resistance and we
don't know that SHA-1 is weak in that respect, and even
HMAC-MD5 is still ok. There are still be good reasons to want
new algorithms, but I don't think that lack of collision
reisistance for hash function used in HMAC is one of them.

section 3 says: "Echo packets are not defined in the BFD
specification, though they can keep the BFD session up.  The
format of the echo packet is local to the sending side and
there are no guidelines on the properties of these packets
beyond the choice of the source and destination addresses."
That seems really weird. The "add security but we're not
saying how" that follows is even weirder.

In 3:
   However,
   in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1
   mechanisms, the sequence member is required to monotonically increase
   with each successive packet.

"monotonically increasing" means the same thing as "non-decreasing."   That is, a for monotonically increasing function f, it is always true that f(x) <= f(x+k) for all positive values of k.  I think you mean "strictly increasing."   But really you could just say "is required to increase with each successive packet."

Thanks for doing this analysis!