Re: Request for WG adoption of draft-mahesh-bfd-authentication

[Jeffrey Haas <[e-mail]>]

On Tue, Nov 24, 2015 at 06:46:40AM +0000, Gregory Mirsky wrote:
> I'd like to share comment by Security AD Stephen Farrell on a work that is directly related to BFD, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf (hope it is OK to raise security awareness in BFD community):
> > There was a proposal to strengthen BFD security BFD Generic 
> > Cryptographic  Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03> but the document had expired.
> 
> Pity that.

I'd recommend that the generic crypto mechanism and the related SHA-2 draft
be picked up and analyzed in the context of the optimizing authentication
draft.  The generic crypto mechanism was a good idea, but simply lacked
motivation to get the changes to the authentication in implementations done.

> > - 2.1.1, I'd recommend saying any password auth-type MUST NOT be used - would that be possible?
> > 
> > GIM>> I think that we’ll need to make changes to RFC 5880 first (5880bis?). 
> 
> I don't see any reason why that is true. This document can easily say "you MUST NOT use the horribly weak option specified in that old RFC" with changing that old RFC.
> 
> The point? It may be sacrificing security for sake of performance may be not the better choice. I can rationalize such choice for BFD over LSP, micro-BFD as these effectively monitor not Layer 3 but Layer 2.5 and Layer 2 entities respectively. I would not support such choice for multi-hop BFD. Single-hop BFD? Open for discussion.

I believe that Stephen is also missing out on the simplified case that
password-auth is a trivial session collision prevention mechanism.  This is
handy when you otherwise either don't care about security (he always does)
or have alternate mechanisms to provide for security, such as link-layer
security.

-- Jeff