Hi, Loa: Thank you for the comments. No problem. Actually, there are two drafts for strengthening BFD security:
https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06, which specify a generic authentication mechanism for BFD. https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05, which discusses how to support SHA2 based on the generic authentication extension. The first draft has been adopted as a WG draft. So, it would be great for the group to review it again and let us know if you have any comments. Cheers Dacheng 在 15-11-25 下午3:22， "Loa Andersson" <[email protected]> 写入: >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" <[email protected]> 写入: >> >>> 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:[email protected]] >>> Sent: Monday, November 23, 2015 11:12 PM >>> To: Gregory Mirsky; Marc Binderberger; Reshad Rahman (rrahman); >>> [email protected]; Stephen Farrell >>> Cc: [email protected] >>> Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication >>> >>> >>> >>> 在 15-11-24 下午2:46， "Gregory Mirsky" <[email protected]> 写入: >>> >>>> 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. >>>> >>> >> >>
