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

Greg Mirsky <> Sat, 13 October 2018 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03F39130E67 for <>; Sat, 13 Oct 2018 13:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOinH7UDeYJF for <>; Sat, 13 Oct 2018 13:10:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 270B2130E27 for <>; Sat, 13 Oct 2018 13:10:58 -0700 (PDT)
Received: by with SMTP id a82-v6so11555147lfa.4 for <>; Sat, 13 Oct 2018 13:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gKBqciOMUlgUwEotqgLB7H4pCa/PZm4Trx/GrN0uFf4=; b=Hq6RohBQ8e65PY9qlkE61sxmFwOt6qeX8VUxR1QtzR4YFjOxkr8A9qbjEigpLzHXli dKATZqx2WvXF9vjIiMTaVvGe74/I6qZFrWHZCn8e+AKIRaaW0BZC7vOCnvO779c5ubN0 W2svSVyn14TA7xifW7LWdYaGyFbJhWV3GQN7JGzmOpqBywr7fUjPZ0u/4yOchFz6dPDs b5owfv1lg9ny/2oPO35j78Ac8MC90G1UJeQtEGcqqumlLa9Lur1s3Cf2yjWbMfkl0SEg SOfvFS4oXlX1DlerCGJR5vmEKIbAblEFfKLxvWUBMZnkHUhqd+4ywhDhB/+jD57jLsQF U9qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gKBqciOMUlgUwEotqgLB7H4pCa/PZm4Trx/GrN0uFf4=; b=bDMwSDK13+bwtNRl7hFxf6awQvAT7vLTYvh9U/jUhD0zQvFSCsrFECQVB8rDszd12S JQo+lQJ+fH+BZRPhzoVp5m1JzLGZzFiwJX43JElecZt4YafmTbm5f9H/42xgChgc8VZ/ 3PJtj7vi9MqPLPENRPHlqyeLNlf7AqINTYVTQ6WIAWDgMYOY0whETNm2ZMr0COTx0GLl Pbo6H5qIJeoSY5KrXTil7C4dqbU6Qf9BitI61s8Dqp5CpuIwHZGl00wF9mAB7vGOqzHc skmfcdf5qkFWct5xlvJsz5kyfKHIuDI3cvWt/b3BoGEgywxJbSWsxRw4OfebJSRDTYkD vjfA==
X-Gm-Message-State: ABuFfohupU6BhsIgssxZidjbNR7LYLYSDT1Z/r72K1W0hQPd5xKlYTrE 51z10LsWkuj7qSfX7Xh3luzV4nYPhKOi42pKHNA=
X-Google-Smtp-Source: ACcGV620gT9UIQBX+KviEqw262D6SZ9jdsL2HVIFUzRbrQx4+2rwtm/VgPbTA5GN2EnPZPIXaQlLJaf5S/tLmr4zdpI=
X-Received: by 2002:a19:4c02:: with SMTP id z2-v6mr6328815lfa.48.1539461456070; Sat, 13 Oct 2018 13:10:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Sat, 13 Oct 2018 13:10:44 -0700
Message-ID: <>
Subject: Re: I-D Action: draft-ietf-bfd-optimizing-authentication-06.txt
To: Mahesh Jethanandani <>
Cc: rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="0000000000003c1031057821cd95"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Oct 2018 20:11:01 -0000

Hi Mahesh, Authors, et. al,
thank you for your thoughtful consideration of the discussion in Montreal.
I've checked the changes in the new version and I think that the agreement
we've reached was not merely recommend that the authenticated BFD Control
packets be sent as series of at least Detect Multiplier packets but
require, i.e., make it mandatory for both periodic and state change modes.
Here's the quote from the minutes:
    Jeff Haas: one possibility is to send detect multiplier number of
consecutive authenticated packets, then the session will go down if
authentication packets fail validation.
    Greg Mirsky: does that require use of P/F procedure?
    Jeff Haas: P/F is not needed, we send consecutive authenticated packets
    Mahesh Jethanandani: we can make that change.
    Reshad Rahman: is there a need to do the same for state change?
    Mahesh Jethanandani: every state change packet has to be authenticated.
    Jeff Haas: for pedantic reasons, when making the state change we should
do the same. On P/F sequence we should do    this for the new multiplier if
it’s longer. We’ll take this back to the mailing list.
Thus I suggest to consider changes along the following:
 To detect a Man In the Middle (MITM)
   attack, it is also proposed that a non-state change frame be
   authenticated occasionally.  The interval of this non-state change
   frame can be configured depending on the detect multiplier and the
   capability of the system.  As an example, this could be equal to the
   detect multiplier number of packets.
  To detect a Man In the Middle (MITM)
   attack, it is also proposed that a non-state change set of authenticated
frames be
   sent occasionally.  The number of consecutively transmitted
authenticated BFD control packets in the set
   MUST be not lesser than the value of the Detect Multiplier and the
interval between such non-state change
   set of frames can be configured depending on the
   capability of the system.
If acceptable, similar change should be made to the following text:
   Authenticating a small subset of these frames, for example, a detect
   multiplier number of packets per configured period, significantly
   reduces the computational demand for the system while maintaining
   security of the session across the configured authentication periods.
to change from recommendation "for example" to stronger normative language.


On Thu, Oct 11, 2018 at 4:31 PM Mahesh Jethanandani <>

> This version of the draft addresses comments received at IETF 102 as part
> of LC. At this point, the authors believe that this document, along with
> draft-ietf-bfd-secure-sequence-numbers and draft-ietf-bfd-stability are
> ready for IESG.
> Thanks.
> > On Oct 11, 2018, at 4:25 PM, 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-06.txt
> >       Pages           : 7
> >       Date            : 2018-10-11
> >
> > Abstract:
> >   This document describes an optimization to BFD Authentication as
> >   described in Section 6.7 of BFD RFC5880.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> >
> > There are also htmlized versions available at:
> >
> >
> >
> > A diff from the previous version is available at:
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at
> >
> > Internet-Drafts are also available by anonymous FTP at:
> >
> >
> Mahesh Jethanandani