Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines
RFC 7492

[Ballot comment]
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

[Ballot discuss]
Sorry for the late discuss, the SecDir review came in late and Sam has a few questions that really should get addressed as it has the potential to change the draft.  It would be helpful to understand a few of the decisions and see if some of his suggestions assist with the options that the WG goes forward with.  It may or may not apply, but would be helpful to discuss and understand that.

Here is a link to the review:
https://www.ietf.org/mail-archive/web/secdir/current/msg04976.html

[Ballot comment]
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!

[Ballot comment]
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...

[Ballot comment]

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.

[Ballot comment]
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.

[Ballot comment]
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 …

Hello authors and shepherd,

IETF last call has completed.
Thanks for the update to address the Routing Directorate review from Les.

I think you also received some comments from Tom Taylor. They look minor, but you should still pick them up.

Cheers,
Adrian

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-karp-bfd-analysis-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:
- 'Analysis of Bidirectional Forwarding Detection (BFD) Security
  According to KARP Design Guide'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document analyzes the Bidirectional Forwarding Detection
  protocol (BFD) according to the guidelines set forth in section 4.2
  of KARP Design Guidelines [RFC6518].

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-karp-bfd-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-karp-bfd-analysis/ballot/

No IPR declarations have been submitted directly on this I-D.