Re: WGLC BFD Authentication Drafts

Ashesh Mishra <mishra.ashesh@outlook.com> Mon, 07 May 2018 18:21 UTC

Return-Path: <mishra.ashesh@outlook.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66012D779 for <rtg-bfd@ietfa.amsl.com>; Mon, 7 May 2018 11:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wxU8wnbY9pb for <rtg-bfd@ietfa.amsl.com>; Mon, 7 May 2018 11:21:18 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004105.outbound.protection.outlook.com [40.92.4.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BDF12D9FF for <rtg-bfd@ietf.org>; Mon, 7 May 2018 11:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rrga2+2FH07ud9Q8pvrkWBph0pkKaAWCgky47rxM+qE=; b=cEqqsaV0nnq4EN0uCmezoNEF2+21hqoLXv2PWfNH7+2SO2rIczaWBhZ80ncGzZMwxYvDdeDbOPqMdhM8nDk4bFdxhbetLej1pMm/QF+ckhOsNTBmzN6pkiNASFmM1td1o/PoSjkeJb/id4ukPscWdgxp3T2Ltsgq7ZuprDT9GH4BD6h6dRlPTkKH6Q2j1aILg+Jx3wVoxQvDXWWQMs5HPiJJcoMSV77DDbv1DWnstDq+upPpv29p3ngjxI9LLs3Cvlbn6bUFIxFqD8ozH7LjQTl80/9mT87shtpdZUE7y7a2SuPz7bMrZwveY4xLJsWEAulpLkXb32nUr37QQK5fQg==
Received: from CY1NAM02FT031.eop-nam02.prod.protection.outlook.com (10.152.74.57) by CY1NAM02HT130.eop-nam02.prod.protection.outlook.com (10.152.74.176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.16; Mon, 7 May 2018 18:21:11 +0000
Received: from MW2PR0102MB3561.prod.exchangelabs.com (10.152.74.59) by CY1NAM02FT031.mail.protection.outlook.com (10.152.75.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.735.16 via Frontend Transport; Mon, 7 May 2018 18:21:11 +0000
Received: from MW2PR0102MB3561.prod.exchangelabs.com ([fe80::5528:8ea8:4cbd:f59f]) by MW2PR0102MB3561.prod.exchangelabs.com ([fe80::5528:8ea8:4cbd:f59f%13]) with mapi id 15.20.0715.025; Mon, 7 May 2018 18:21:11 +0000
From: Ashesh Mishra <mishra.ashesh@outlook.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC BFD Authentication Drafts
Thread-Topic: WGLC BFD Authentication Drafts
Thread-Index: AQHTxrM8j4pe2ek2RUW1GIkZ+QU4DqPnD20AgAT20DKAAa1ggIABNeIAgADi1gCACIenAIAAk7SAgCuoLwA=
Date: Mon, 07 May 2018 18:21:11 +0000
Message-ID: <9FBE2FC9-C4A9-4BF5-BCC7-73451391BECF@outlook.com>
References: <20180328163856.GB3126@pfrc.org> <CA+RyBmVLPBKq1wthriY44FQN51bq85w3LfSR4K6WuRi=Kr1L9w@mail.gmail.com> <BL0PR0102MB33454D88A214B8EFFDD242B5FAA70@BL0PR0102MB3345.prod.exchangelabs.com> <CA+RyBmWh+_nKd-pvyg7W2xtdOFE9BkXEqTM3W48K_rifaUAYXw@mail.gmail.com> <36BBC371-54A2-43B0-8597-69782CFFD5E9@outlook.com> <CA+RyBmWue4iM9a2gazuTu=h-7yFN+YKEGMY8=_2C3gsj3yxekw@mail.gmail.com> <350B7795-76FC-4E7A-9532-2F3CF0577C31@outlook.com> <CA+RyBmVXzaHo1_AjkuYdGCJ2MUOPdobXS8awA0Fn9O8+JMFVQQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVXzaHo1_AjkuYdGCJ2MUOPdobXS8awA0Fn9O8+JMFVQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:FEA649AAD0D060333DA72493B688CB6750EC8406D4162577D8BF0A8A88C82EB3; UpperCasedChecksum:0D0587AF46A052323F70C03BEA3A5D106EC7E007099371D549AEAD7939A5A579; SizeAsReceived:7494; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [uAgkbHV1gYvRESb6rUJbr49j2zsB6A0+]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1NAM02HT130; 7:ZNSpRxXLdyFOWsgfxqyylZR6Lqg9yU36LB4nyrIy71CzUQUSrNMYJZ8tj7o6LpTG8pIl61r3TUOldSXDZlr8q56tqCfHHJFhDx0melb44AAEIFX3clyorBYnXieRBiXknAviEfXNvaZqOoAGiAYykFu2BsMUQfU6vB2dwFQZBly4l48inRk/eenBdMbRVmJiyqcqvYZ6AVhi8NGdkTGTJ+tUsLe/YyoBe/syRxria+BxAQppRuQgAFdYBwoAW+Xu
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CY1NAM02HT130;
x-ms-traffictypediagnostic: CY1NAM02HT130:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CY1NAM02HT130; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT130;
x-forefront-prvs: 066517B35B
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CY1NAM02HT130; H:MW2PR0102MB3561.prod.exchangelabs.com; FPR:; SPF:None; LANG:;
x-microsoft-antispam-message-info: W1AkP3OSOA1Xp/lsO50lzmDTJet07TKbbHTwE2XeI4vy/IaSeQ4OPgydFh4b22Kvn60AkKGMtjWDoL10vxK8ORLIu5vb4Fi24+ieXfvh4+4AjgCL/WyfeHkxqjtzO2To4QEpOWfVpFx6MsPv4LJHJc4Lg87to8sxy1YQrK5X3Dq/nMKQmdOQQdHEziQcN+VA
Content-Type: multipart/alternative; boundary="_000_9FBE2FC9C4A94BF5BCC773451391BECFoutlookcom_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 381a5cb9-64e7-4956-86fd-08d5b4474fae
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-Network-Message-Id: 381a5cb9-64e7-4956-86fd-08d5b4474fae
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: dd759f05-a917-4aa0-a2f5-4cc35c50e0c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 18:21:11.4683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT130
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/OxS15yo3ZEvMBSE6g06Ly0Bnm5M>
X-Mailman-Approved-At: Mon, 07 May 2018 11:56:43 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2018 18:21:24 -0000

Hi Greg,

Apologies for the delayed response. The message got lost in the mail.

I was wrong in stating that a single failed auth frame can bring a session down. There needs to be text in the draft to suggest tracking the number of consecutive discarded authentication frames. When that counter hits the detect multiplier, the session is marked oper-down. Is that a more reasonable solution?

Ashesh

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Monday, April 9, 2018 at 3:40 PM
To: Ashesh Mishra <mishra.ashesh@outlook.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC BFD Authentication Drafts

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.ashesh@outlook.com<mailto:mishra.ashesh@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 <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Tuesday, April 3, 2018 at 8:35 PM

To: Ashesh Mishra <mishra.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@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 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.ashesh@outlook.com<mailto:mishra.ashesh@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 <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Monday, April 2, 2018 at 12:34 PM
To: Ashesh Mishra <mishra.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@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.ashesh@outlook.com<mailto:mishra.ashesh@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-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@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 <jhaas@pfrc.org<mailto:jhaas@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