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

[Gregory Mirsky <[e-mail]>]

Dear All,
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):

> - 2.1.1, is there any chance of moving on from the "Keyed SHA1"
> 
> from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to 
> get that kind of transition done as we can and moving to use of a 
> standard integrity check rather than a more home-grown one has some 
> benefits. The HMAC-SHA1-like thing you're doing is still probably ok, 
> (though could maybe do with crypto eyeballs on it as there may have 
> been relevant new results since 2010) but future-proofing would 
> suggest moving to HMAC-SHA256 if we can. (I can imagine such a change 
> might require a new document, but am asking anyway:-)
> 
> GIM>> The fact is that we're bound by what is defined in RFC 5880.

I wonder for how long though, that's now a five year old RFC.
Assuming it takes a few years for new deployments to pick up new algorithms, isn't it time that a whole bunch of algorithm choices were revisited?

> 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.

> - 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.

	Regards,
		Greg

-----Original Message-----
From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Dacheng Zhang
Sent: Monday, November 23, 2015 10:26 PM
To: Marc Binderberger; Reshad Rahman (rrahman); [e-mail]
Cc: [e-mail]
Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

Hi，I think this is an interesting draft. It is quite common that we have make a trade off between performance and security. Support for the adoption. ^_^

Some comments and questions:
1) discuss which types of frames MUST be authenticated and which ones SHOULD be authentication.
2) There is a discussion about how the sequence number should be increased in RFC5880, maybe you could follow that one and so avoid any unnecessary confusion.
3) Q: since in this solution, only a small number of frames need to be authenticated, maybe we could consider again to use SHA-2 since the influence in the performance brought by the strong algorithms will no longer be that serious.
4) Q: do you plan to propose a negotiation mechanism for the peers to decide the frames which should be authenticated? If not, please clarify this part of work is out of scope.

Cheers

Dacheng

在 15-11-21 下午6:29， "Rtg-bfd on behalf of Marc Binderberger"
<[e-mail] on behalf of [e-mail]> 写入:

>Hello Reshad and authors (and BFD experts on the list),
>
>it's a smart idea so I support the WG support ;-)
>
>But reading the document: it's at this point mainly outlining an idea 
>and I would expect more details to allow for interoperable 
>implementations.
>
>
>Regards, Marc
>
>
>
>
>
>On Fri, 20 Nov 2015 12:03:25 +0000, Reshad Rahman (rrahman) wrote:
>> BFD WG members,
>> 
>> Please indicate to the WG mailing list whether you would support or 
>> not support BFD WG adoption of the following document.
>> 
>> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/
>> 
>> Authors, as was mentioned at IETF94, you should get your proposal 
>>reviewed  by the security group.
>> 
>> Regards,
>> Jeff & Reshad.