Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

Manav Bhatia <manavbhatia@gmail.com> Thu, 23 July 2020 02:31 UTC

Return-Path: <manavbhatia@gmail.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 C7A813A0B18 for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Jul 2020 19:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HHpHrjbtJcI9 for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Jul 2020 19:31:13 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE233A0855 for <rtg-bfd@ietf.org>; Wed, 22 Jul 2020 19:31:13 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id e64so4704644iof.12 for <rtg-bfd@ietf.org>; Wed, 22 Jul 2020 19:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHnk9eUC2XyLgYaJbUqHI3falNbVAYqGwbqM9okz9cc=; b=YV3U+N0qKIfOSPNC6x2NGAfeDhhP7mY+pkkvRrUovstVW+wD0wYIviXtC4lXyNMYwf nm6rRLFmYBMrD/dVCqfezXBxY0aOtzVkR1mzhdoOkMguA7mflFMAHLj64sq7tqt//iQ0 oTv4qFyA7irtCmsxJYfr+6nd9bV4/pItOhzD0+RznFHn/8dFTdaNOGOEvU2Q8+TNhoI6 9dkR3ARgWza4n9UP+A1kRbKS9xDy/IOjDdPk5xHOK7xELITJZan3GNjfF8Kj7+xozn87 Z3ytTO5JPp1Xt3eQUQUUtJJVA/xGxX78JycGae1A1aSjjvFkuOTYxEonTmbTBJ6gcblk Mjmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gHnk9eUC2XyLgYaJbUqHI3falNbVAYqGwbqM9okz9cc=; b=JgD8GniI99V3keE2j1O7mjGug0r4RLdE5w5JmLjSTsu58uTzFAIZsv+Y1UAyqQinPW 31nEfqVJcg6+YDMTC0rBbLLMJRvsZv83ftZ/u12G09mASFiHEaxDmKUWLv8uCTbgpWJc WvOjn0C8qLG6LrNdRDfdpS3NK9DQHMtnnWrKQa4nYU47Jdixvi0HklNpFQO1tL5GTm1H ANq1iSCUx54V+HceoUatDeGzb8MTB10pbRo8n8XVaDoBoNKcyAwE4zCeYofirEiUCwH5 gRtMKYrMQ7daxCnprDd9lnLMfr2abSIdadwTcrAmb6VfmIKw55pbp191lIlZaKcswI0W kJCg==
X-Gm-Message-State: AOAM531ZT2W9smsPskciGf90kz45EcnO9XjlSNxzAr/tdG1WI2or1/k2 V3UUp9e2H5y8ZNvqyFKVa2OcErTOn3GmCE3g0mE=
X-Google-Smtp-Source: ABdhPJy8296PtUFEBD+OW4GYpjcUuaOGAjZb91y+H4wxnWn30feRh4eMI6wjeNL0qU0KbbPgC1sdWsK/WMjgkuntM8c=
X-Received: by 2002:a5d:8143:: with SMTP id f3mr2723950ioo.157.1595471472556; Wed, 22 Jul 2020 19:31:12 -0700 (PDT)
MIME-Version: 1.0
References: <159466724499.14803.15233027731222579839@ietfa.amsl.com> <FC5206AF-9CDB-4CC2-9967-B4BF5A17141B@gmail.com> <20200721004857.GB31779@pfrc.org> <2C632683-57D0-4E40-809E-6A907B38CDB5@gmail.com> <AF1DDAD1-D362-4BCA-A2D6-EB1477BDBDEF@cisco.com>
In-Reply-To: <AF1DDAD1-D362-4BCA-A2D6-EB1477BDBDEF@cisco.com>
From: Manav Bhatia <manavbhatia@gmail.com>
Date: Thu, 23 Jul 2020 08:01:01 +0530
Message-ID: <CAG1kdoifsdnawsB8jhcDMbprQt4e8p0g3rxxD2Wuw+5pH79e1g@mail.gmail.com>
Subject: Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt
To: "Reshad Rahman (rrahman)" <rrahman=40cisco.com@dmarc.ietf.org>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005efcfe05ab12a6be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/p6nsT_kdNqcd1O9MNuP2TkTI17I>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 23 Jul 2020 02:31:15 -0000

GIven that there isnt a huge advantage in using Auth during INIT -> INIT
and Down -> Down we should probably stick to NULL for the sake of
simplicity. Unless, somebody finds a problem with using NULL.

Cheers, Manav

On Thu, Jul 23, 2020 at 6:32 AM Reshad Rahman (rrahman) <rrahman=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Mahesh and Jeff,
>
> On 2020-07-20, 9:29 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <
> rtg-bfd-bounces@ietf.org on behalf of mjethanandani@gmail.com> wrote:
>
>     Hi Jeff,
>
>     > On Jul 20, 2020, at 5:48 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>     >
>     > Mahesh,
>     >
>     > While reviewing version -10, I had the following questions:
>     >
>     > For the state machine changes, in the Init->Init state, we have NULL
> auth.
>     > While this is a "boring" transition, it's also happening at a very
> slow part
>     > of the state machine; timers should be once a second.  Is there a
> strong
>     > argument to use NULL here?
>
>     Not particularly. The reason to choose NULL was because of the
> (limited) impact it would have. But if the WG feels otherwise, I can change
> it to Auth.
> <RR> I don't have a strong opinion on this yet. But if we change
> INIT->INIT to be Auth, we should be consistent and change Down->Down to
> Auth too?
>
> Regards,
> Reshad.
>
>     >
>     > In section 3:
>     > :   Sequence Number: The sequence number for this packet.
> Implementation
>     > :   may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD
>     > :   [RFC5880], or secure sequence numbers as defined in Secure BFD
>     > :   Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].
>     >
>     > In the core BFD spec, it distinguishes between occasional and
> meticulous
>     > modes and uses different code points to determine what you do.  I
> suspect
>     > your intent is that we always use meticulous mode here?
>
>     Yes, the intent was meticulous. I can clarify that.
>
>     >
>     > -- Jeff
>     >
>     >
>     > On Mon, Jul 13, 2020 at 01:56:14PM -0700, Mahesh Jethanandani wrote:
>     >>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>     >>> This draft is a work item of the Bidirectional Forwarding
> Detection WG of the IETF.
>     >>>
>     >>>       Title           : Optimizing BFD Authentication
>     >>>       Authors         : Mahesh Jethanandani
>     >>>                         Ashesh Mishra
>     >>>                         Ankur Saxena
>     >>>                         Manav Bhatia
>     >>>         Filename        :
> draft-ietf-bfd-optimizing-authentication-10.txt
>     >>>         Pages           : 8
>     >>>         Date            : 2020-07-13
>     >>>
>     >>> Abstract:
>     >>>  This document describes an optimization to BFD Authentication as
>     >>>  described in Section 6.7 of BFD RFC 5880.  This document updates
> RFC
>     >>>  5880.
>     >
>     >
>
>     Mahesh Jethanandani
>     mjethanandani@gmail.com
>
>
>
>
>