Hi Asheh, thank you for taking time to review the minutes from BFD WG meeting at IETF-98. I don't think that we had enough time to discuss in details my question:
Greg Mirsky: One of the possible modes when the session is up is to use authentication with periodic timer trigger? I'd break it into couple more specific questions: - can the periodic Optimized Authentication mode be used without authorization o state changes; - if the answer to the previous question "yes", then when the first authorized BFD control packet must be transmitted by the system; - does the BFD state machine (section 6.2 RFC 5880) changes resulting from introduction of periodic optimized authentication mode; And additional comments: - "For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only." I don't think that nodes "decide" anything but are configured to do something. - "If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled ..." I couldn't find the negotiation procedure being described in the document. Is it out-of-band, i.e. by control or management plane, not part of this BFD enhancement? - "The configuration of the periodic authentication interval for BFD CC UP frames is an open issue." I believe that this open issue must be resolved in the definitive manner before the draft moved to WGLC. Regards, Greg On Sun, Apr 1, 2018 at 6:11 PM, Ashesh Mishra <mishra.ash...@outlook.com> wrote: > Hi Greg, > > > Your questions in the IETF-98 meeting seemed to stem from the challenges > of authentication in fast BFD sessions at high scale. > > > I'll address the issue in two parts - > > > "Is there a need for authenticated BFD sessions?" - I believe we can all > agree that there is a clear market need for BFD authentication. So we > should direct the conversation to the way in which we can address this > requirement. > > > "How can authentication work at scale?" - BFD authentication puts > significant stress on the system and a non-meticulous method alleviates > this computation pressure. That's the premise of this draft as it presents > a way to relieve the BFD authentication requirement based on the capability > of the system to handle the additional stress which maintaining the > session scale. > > > There are some BFD systems in the market, which are not conducive to > authentication (even the optimized method), where the impediment to > authentication is due to the implementation details specific to that vendor > or system. > > > I believe all these issues were address during the meeting. Are there any > specific questions that I missed or any recommendations for the method in > which the requirements can be addressed? > > > Thanks, > > Ashesh > ------------------------------ > *From:* Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Thursday, March 29, 2018 4:09:32 AM > *To:* Jeffrey Haas > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: WGLC BFD Authentication Drafts > > Dear WG Chairs, et. al, > I cannot support WG LC for draft-ietf-bfd-optimizing-authentication as my > comments at BFD WG meeting dating back to IETF-98 > <https://datatracker.ietf.org/meeting/98/materials/minutes-98-bfd-00> still > not have been addressed nor even there was an attempt to address. As I've > asked to clarify impact of the proposed mechanism, particularly periodic > authentication, on the BFD State Machine, I'd point that the proposed > mechanism directly affects BFD security as discussed in RFC 5880 and the > section Security Considerations in the document, in my view, does not > adequately reflects that and doesn't explain how the security of the BFD > session maintained when the periodic authentication is in use. > > Regards, > Greg > > On Wed, Mar 28, 2018 at 7:38 PM, Jeffrey Haas <jh...@pfrc.org> wrote: > > Working Group, > > The authors of the following Working Group drafts have requested > Working Group Last Call on the following documents: > > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-01 > https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 > https://tools.ietf.org/html/draft-ietf-bfd-stability-01 > > Given the overlap of functionality, WGLC will conclude for the bundle > simultaneously. > > Authors, please positively acknowledge whether or not you know about any > IPR > for your documents. Progression of the document will not be done without > that statement. > > Last call will complete on April 20. > > -- Jeff > > >
