From nobody Fri Jun 24 09:02:00 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECF312DC59; Fri, 24 Jun 2016 09:00:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Subject: bfd - Requested session has been scheduled for IETF 96 X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160040.10933.73425.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:40 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:40 -0000 Dear Jeffrey Haas, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bfd Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Potsdam II size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Jeffrey Haas Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: idr i2rs mpls sfc spring bier lime Second Priority: bess isis nvo3 ospf pals rtgwg teas Special Requests: --------------------------------------------------------- From nobody Thu Jun 30 11:26:11 2016 Return-Path: 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 DFA2212DAE9; Thu, 30 Jun 2016 11:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qaJu3lveD6Se; Thu, 30 Jun 2016 11:26:08 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7DA12D8D2; Thu, 30 Jun 2016 11:26:04 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-20-577559e34028 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 9A.96.09012.3E955775; Thu, 30 Jun 2016 19:41:55 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 14:26:02 -0400 From: Gregory Mirsky To: "draft-ietf-bfd-optimizing-authentication@ietf.org" Subject: Mail regarding draft-ietf-bfd-optimizing-authentication Thread-Topic: Mail regarding draft-ietf-bfd-optimizing-authentication Thread-Index: AdHS+vLmHu8wsm3pSNisVI8Xy0PXKA== Date: Thu, 30 Jun 2016 18:26:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221ABDE23@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221ABDE23eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPrO7jyNJwgy03zSw+LD3CbPH5zzZG ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlTHl7gqXgj0rFpWnH2RoYb8p3MXJySAiYSPzt7meF sMUkLtxbz9bFyMUhJHCUUaLv8U5WCGc5o8Si9pNMIFVsAkYSLzb2sIPYIgK5EktO9zKD2MwC mhJNJz6DxYUFHCQOfXjDBFHjKrHk13ZGCFtPYtbWV2wgNouAqsStO3vB4rwCvhLnny8Cu4IR 6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+B3W1ksSkpedYIerzJX5/OcEMMVNQ4uTM JywTGIVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxQU5uupHB JkZgdByTYNPdwXh/uuchRgEORiUe3gU8JeFCrIllxZW5hxglOJiVRHivJpaGC/GmJFZWpRbl xxeV5qQWH2KU5mBREucVe6QYLiSQnliSmp2aWpBaBJNl4uCUamDcY9I0w/d7/lmtDh3bvS7f /df4Mr/YcWbxvqa/Rne+3PfYe3959RTVs9ppp8Ov3b5xqm+bz/v9z9yTnlYuWSH77M8unj91 h249UucuUJ/Q/O1FgY1ObO6XPd1blBcwNex5WFSdNm3X6eZLEarqJwPmPnx3ODTNn/uv4tcF 5vc/GzdsXajNar7iixJLcUaioRZzUXEiANz0UMaKAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 18:26:10 -0000 --_000_7347100B5761DC41A166AC17F22DF11221ABDE23eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I've got a question on how the proposed mechanism to use Authentication onl= y for the state transition signaling affects the state machine. Consider BF= D implementation that uses HW-assistance. BFD control packets with NUL Auth= TLV can easily be validated in the HW but those that have real Authenticat= ion may require a punt and processing out of the fast path. Authenticated p= acket to be validated must pass authentication verification and that may ha= ppen much later. If we imagine, though it is a stretch, that the next two p= ackets get lost or corrupted, then we may have false negative because valid= ation of the authenticated packet is outside of the normal validation path. Or consider another scenario when validation fails because of the Authentic= ation. Should this have immediate impact on the state machine? If not, the = new state will be learnt from the very next BFD control packet, which is no= t authenticated as I understand the proposal. Then what is the benefit of s= ending state change with Authentication? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221ABDE23eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

I’ve got a question on how the proposed mechan= ism to use Authentication only for the state transition signaling affects t= he state machine. Consider BFD implementation that uses HW-assistance. BFD = control packets with NUL Auth TLV can easily be validated in the HW but those that have real Authentication may require= a punt and processing out of the fast path. Authenticated packet to be val= idated must pass authentication verification and that may happen much later= . If we imagine, though it is a stretch, that the next two packets get lost or corrupted, then we may have= false negative because validation of the authenticated packet is outside o= f the normal validation path.

Or consider another scenario when validation fails b= ecause of the Authentication. Should this have immediate impact on the stat= e machine? If not, the new state will be learnt from the very next BFD cont= rol packet, which is not authenticated as I understand the proposal. Then what is the benefit of sending state ch= ange with Authentication?

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF11221ABDE23eusaamb103erics_--