Re: WGLC BFD Authentication Drafts

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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 <[e-mail]
>> > 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 <gregimirsky@gmail..com <[e-mail]>>
>>>
>>> *Date: *Tuesday, April 3, 2018 at 8:35 PM
>>>
>>>
>>> *To: *Ashesh Mishra <[e-mail]>
>>> *Cc: *Jeffrey Haas <[e-mail]>, "[e-mail]" <
>>> [e-mail] <rtg-bfd@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 <
>>> [e-mail]> 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 <[e-mail]>
>>> *Date: *Monday, April 2, 2018 at 12:34 PM
>>> *To: *Ashesh Mishra <[e-mail]>
>>> *Cc: *Jeffrey Haas <[e-mail]>, "[e-mail]" <
>>> [e-mail]>
>>>
>>>
>>> *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 <[e-mail]>
>>> 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 <[e-mail]> on behalf of Greg Mirsky <
>>> [e-mail]>
>>> *Sent:* Thursday, March 29, 2018 4:09:32 AM
>>> *To:* Jeffrey Haas
>>> *Cc:* [e-mail]
>>> *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 <[e-mail]> 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
>> [e-mail]
>>
>>
>
> Mahesh Jethanandani
> [e-mail]
>
>