Hi Mahesh, thank you for sharing the history of this mode. Are you proposing to remove it from the specification?
Regards, Greg On Mon, Jul 2, 2018 at 11:41 AM, Mahesh Jethanandani < mjethanand...@gmail.com> wrote: > 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> 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> 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 >> > 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 <gregimir...@gmail.com>> >>> >>> *Date: *Tuesday, April 3, 2018 at 8:35 PM >>> >>> >>> *To: *Ashesh Mishra <mishra.ash...@outlook.com> >>> *Cc: *Jeffrey Haas <jh...@pfrc.org>, "rtg-bfd@ietf.org" < >>> rtg-bfd@ietf.org <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> 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> >>> *Date: *Monday, April 2, 2018 at 12:34 PM >>> *To: *Ashesh Mishra <mishra.ash...@outlook.com> >>> *Cc: *Jeffrey Haas <jh...@pfrc.org>, "rtg-bfd@ietf.org" < >>> 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> >>> 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 >>> >>> >>> >>> >>> >>> >>> >> >> >> Mahesh Jethanandani >> mjethanand...@gmail.com >> >> > > Mahesh Jethanandani > mjethanand...@gmail.com > >
