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

[Loa Andersson <[e-mail]>]

Dacheng,

Maybe do it the IETF way - discuss on the mailing list how it should
be updated, when we have consesnsus - update draft, and then see if
there is anything that we need to take up time to do at the f2f
meeting :) !

/Loa

On 2015-11-25 13:57, Dacheng Zhang wrote:
> Great! Let us update that draft and discuss it in the next IETF meeting.
> ^_^
>
> Cheers
>
> Dacheng
>
> 在 15-11-25 上午9:33， "Gregory Mirsky" <[e-mail]> 写入:
>
>> Hi Dacheng,
>> HW became more capable and we, one hopes, wiser. Perhaps it's time to
>> re-visit our options.
>>
>> 	Regards,
>> 		Greg
>>
>> -----Original Message-----
>> From: Dacheng Zhang [mailto:[e-mail]]
>> Sent: Monday, November 23, 2015 11:12 PM
>> To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman);
>> [e-mail]; Stephen Farrell
>> Cc: [e-mail]
>> Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication
>>
>>
>>
>> 在 15-11-24 下午2:46， "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.
>>
>> I am one of the co-author of that draft. We didn’t try to update document
>> because we got the feedback from the group that the influence on the
>> performance is a big concern. That is why I raised the question in the
>> last email whether it is a good time for us to re-consider the usage of
>> aha-2 in BFD.
>>>
>>
>
>