Hi Greg, The suggestion to authenticate every Nth frame came to us when we initially presented the draft. It was not part of the original draft. If I remember, the reason given was that if a MITM had taken over the session, then authenticating an occasional frame would help detect that. Note, however, a MITM cannot change the state of the session, because a change in the state of the session requires those frames to be authenticated by the sender, and for those frames to be marked valid by the receiver.
Cheers. > On Jul 2, 2018, at 11:06 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Hi Mahesh, > you've said: > > If three or more frames are discarded because one or all three of them were > marked with NULL Auth TLV, and all of them fail authentication, the receiver > brings the session down. Again, this is no different from three or more > unauthenticated or meticulously authenticated frames being discarded, causing > the receiver to bring the session down. > > My understanding of periodic mode is that when the BFD session is in Up state > every Nth BFD Control packet is authenticated while rest of packets are not. > Consider the scenario when each authenticated packet fails validation while > unauthenticated packet pass. Would the state of the session remain Up? If so, > what is the purpose of authentication? If not, if the session transitions to > Down state, then it is, in my opinion, the change to BFD state machine per > RFC 5880. > > Regards, > Greg > > On Mon, Jul 2, 2018 at 9:58 AM, Mahesh Jethanandani <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>> wrote: > Picking up on this thread. > > The way to look at this draft is, that it suggests which frames will undergo > authentication. This draft does not suggest any change to the state machine, > or believe it causes a change in it. Frames that need authentication will > carry the NULL Auth TLV. If they are not authenticated or do not need > authentication they will not have the TLV. > > If a BFD session is down, and it is going through a P/F sequence the frames > need to be authenticated, since these frames cause a state machine > transition. If authentication fails, frames are discarded and the session > remains down. This is no different from a unauthenticated or a meticulously > authenticated P/F frame getting discarded, keeping the session down. > > If the session is up, and it needs to be brought down, then the frame to > bring it down needs to be authenticated, again because these frames cause a > change in state machine. If it fails authentication, the frame is discarded > and the session remains up. Again, this is no different from a > unauthenticated frame or a meticulously authenticated frame being discarded, > keeping the session up. > > If three or more frames are discarded because one or all three of them were > marked with NULL Auth TLV, and all of them fail authentication, the receiver > brings the session down. Again, this is no different from three or more > unauthenticated or meticulously authenticated frames being discarded, causing > the receiver to bring the session down. > > Cheers. > >> On Apr 9, 2018, at 12:39 PM, Greg Mirsky <gregimir...@gmail.com >> <mailto:gregimir...@gmail.com>> wrote: >> >> Hi Ashesh, >> thank you for your response to my questions.. I think I need some more of >> your help to locate the text in RFC 5880 that, as you've stated, mandates >> that the single failure to authenticate a BFD control packet in Up state >> triggers the transition to Down state. I only see section 6.7 that describes >> authentication validation and when the received control packet must be >> discarded because of validation failure and the following text: >> If the A bit is set, the packet MUST be authenticated under the >> rules of section 6.7, based on the authentication type in use >> (bfd.AuthType). This may cause the packet to be discarded. >> But I don't find any text that states that if authentication is in use, then >> Detect Time calculated regardless of the value of the Detect Mult field. >> Perhaps I will extend the description of the scenario: >> authentication is in use and every, for example, the fourth packet to be >> authenticated, i.e. three control packets with NULL Auth TLV followed by >> "real" authenticated control packet; >> initial packets, three-way handshake, pass authentication verification and >> the session is Up; >> at some point, the verification of the "real" authenticated packets fails >> and it is discarded; >> packets with NUL Auth TLV pass the validation. >> Appreciate your consideration and help. >> >> Regards, >> Greg >> >> On Mon, Apr 9, 2018 at 10:51 AM, Ashesh Mishra <mishra.ash...@outlook.com >> <mailto:mishra.ash...@outlook.com>> wrote: >> Hi Greg, >> >> >> >> What I meant to say was that the state machine remains the same as in the >> case of 5880 authentication. If an authentication frame fails validation >> then the session goes down regardless of good OPER-UP frames (authentication >> or normal) before or after that frame. Since the behavior in 5880 does not >> require any more than 1 frame to fail validation, the mechanism works as-is >> in the new proposal. Once the session is down, all frames need to be >> authenticated to bring the session up so again, the session can’t come back >> up just because the frame that failed validation is followed by a stream of >> unauthenticated frames. >> >> >> >> Hope that addresses the gap that you presented. >> >> >> >> Ashesh >> >> >> >> From: Greg Mirsky <gregimir...@gmail..com <mailto:gregimir...@gmail.com>> >> >> >> Date: Tuesday, April 3, 2018 at 8:35 PM >> >> >> To: Ashesh Mishra <mishra.ash...@outlook.com >> <mailto:mishra.ash...@outlook.com>> >> Cc: Jeffrey Haas <jh...@pfrc.org <mailto:jh...@pfrc.org>>, "rtg-bfd@ietf.org >> <mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org <mailto:rtg-...@ietf..org>> >> Subject: Re: WGLC BFD Authentication Drafts >> >> >> >> Hi Asheh, <> >> thank you for the detailed response to my questions and consideration of my >> comments. >> >> I think I cannot agree that the BFD state machine remains unchanged if >> optimized BFD authentication is in periodic mode. Let's consider case when >> only every 5th BFD control packet is authenticated when the session is in Up >> state. What happens if from some moment every authenticated packet fails to >> be validated? Would the session go to Down state? But all unauthenticated >> BFD control packets pass the validation check and since only one packet >> seems to miss validation the session, if the state machine remains >> unchanged, will stay Up. >> >> >> >> Do you see this as plausible scenario? >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Apr 3, 2018 at 11:03 AM, Ashesh Mishra <mishra.ash...@outlook.com >> <mailto:mishra.ash...@outlook.com>> wrote: >> >> Thanks for the clarification, Greg. >> >> >> >> Here are my thoughts on the issues: >> >> >> >> 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; >> >> [AM] The optimized authentication can be used without state changes and the >> first auth packet will be the DOWN state frame to kick-off the session >> negotiation as the proposal suggests that all DOWN state frames are >> authenticated. The state machine does not change in this proposal but it >> only indicates which frames should be authenticated and which ones can use >> NULL-AUTH TLV (un-authenticated frames). >> >> 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. >> >> >> >> [AM] I agree that the language is not accurate. We’ll change it in the next >> revision. The intention is to use indicate configuration rather than >> negotiation. >> >> · "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? >> >> >> >> [AM] The language should indicate configuration instead of negotiation. >> >> · "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. >> >> >> >> [AM] This line should be removed and the preceding text should indicate that >> the parameters for authentication should be configured on the session >> end-points. >> >> >> >> Regards, >> Ashesh >> >> >> >> From: Greg Mirsky <gregimir...@gmail.com <mailto:gregimir...@gmail.com>> >> Date: Monday, April 2, 2018 at 12:34 PM >> To: Ashesh Mishra <mishra.ash...@outlook.com >> <mailto:mishra.ash...@outlook.com>> >> Cc: Jeffrey Haas <jh...@pfrc.org <mailto:jh...@pfrc.org>>, "rtg-bfd@ietf.org >> <mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>> >> >> >> Subject: Re: WGLC BFD Authentication Drafts >> >> >> >> 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 >> <mailto: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 <mailto:rtg-bfd-boun...@ietf.org>> >> on behalf of Greg Mirsky <gregimir...@gmail.com >> <mailto:gregimir...@gmail.com>> >> Sent: Thursday, March 29, 2018 4:09:32 AM >> To: Jeffrey Haas >> Cc: rtg-bfd@ietf.org <mailto: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 >> <mailto: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-secure-sequence-numbers-01> >> https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04 >> <https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-04> >> https://tools.ietf.org/html/draft-ietf-bfd-stability-01 >> <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 >> >> >> >> >> >> >> >> > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > Mahesh Jethanandani mjethanand...@gmail.com
