[saag] Fate of BFD extended authentication mechanisms

[Jeffrey Haas <[e-mail]>]

Security-folk,

Partially as a response to work concluded in the KARP Working Group, there
was previously some effort to enhance the cryptographic authentication
mechanisms present in BFD.  The core BFD protocol is described in RFC 5880,
including its authentication mechanisms.

The two main documents covering this work are below:

https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06
https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05

To somewhat tritely summarize the work in these two documents, the generic
doc provides for:
- Increase the number space of authentication sequence number to 64 bits
  from 32.
- Provide a larger numbering space for key identifiers, from 8 bits to 16
  bits.
- Re-using this structure for all future types rather than making it a
  property of the individual authentication section for a given mechanism.

The hmac-sha doc describe SHA-2 variants of ciphers.

In general, these are understood to be the Right Things to do for BFD.
However, lack of interest in the industry from either vendors or customers,
and lack of drive from within the working group have contributed to these
documents going stale.

There is also the secondary issue that as a result of the speed at which BFD
operates and the fact it is often operating under extremely constrained
compute resources, even existing ciphers are not well deployed in spite of
the known weaknesses in the strength of those ciphers.  There is a separate
effort beginning in BFD that may mitigate these issues, but I have requested
the authors of that draft to contact the security area separately to discuss
their proposal:

https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

Now to my question:

It's generally understood that implementations of security mechanisms often
lag their specifications.  It's also generally understood that you want
those specifications to exist because when you need them, it's possibly
already too late.

Given this, I'm looking at options to help drive the BFD generic crypto and
hmac-sha document to publication.

As mentioned, the interest in the BFD WG is low.

My question is what is the perceived status of security related documents
that are on the Experimental track?  

For these documents to progress on the standards track, they'd have to have
some likelihood of being deployed.  That point is, as above, unclear.

-- Jeff