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
