Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Mon, 30 July 2018 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 443491277BB; Mon, 30 Jul 2018 07:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JWMM1o3RpsTr; Mon, 30 Jul 2018 07:41:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2CB81310E3; Mon, 30 Jul 2018 07:41:53 -0700 (PDT)
X-AuditID: 1209190f-e79ff700000078a5-46-5b5f23afff9a
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CB.4A.30885.0B32F5B5; Mon, 30 Jul 2018 10:41:52 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w6UEfkp6024209; Mon, 30 Jul 2018 10:41:48 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w6UEffqx028454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2018 10:41:43 -0400
Date: Mon, 30 Jul 2018 09:41:41 -0500
From: Benjamin Kaduk <>
To: "Reshad Rahman (rrahman)" <>
Cc: Jeffrey Haas <>, "Acee Lindem (acee)" <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixG6nortBOT7a4PAvVYvJb+cxW0y+uZrR YtPOn0wWM/5MZLbYf/Atq8W1Fa3sFp//bGN0YPeY8nsjq8eSJT+ZPC73bmUNYI7isklJzcks Sy3St0vgylg05T57wWmDipd33zE1MB5U6WLk5JAQMJG4seIScxcjF4eQwGImieNf50E5Gxkl uhY0M4FUCQlcZZI41qgFYrMIqErM23WEHcRmE1CRaOi+DNTAwSEiYCjxa401SC+zwAQmiQuX DrGB1AgLxEqc+nQMbA4v0LZDZz+xQyy4wCzR1TOVESIhKHFy5hMWEJtZQF3iz7xLYEOZBaQl lv/jgAjLSzRvnc0MYnMK2Eqc6P/LCmKLCihL7O07xD6BUXAWkkmzkEyahTBpFpJJCxhZVjHK puRW6eYmZuYUpybrFicn5uWlFuma6OVmluilppRuYgTFBKck/w7GOQ3ehxgFOBiVeHgzpOKi hVgTy4orcw8xSnIwKYny/pePjxbiS8pPqcxILM6ILyrNSS0+xCjBwawkwmsjA5TjTUmsrEot yodJSXOwKInz3qsJjxYSSE8sSc1OTS1ILYLJynBwKEnw5ikBNQoWpaanVqRl5pQgpJk4OEGG 8wANNwWp4S0uSMwtzkyHyJ9i1OX4837qJGYhlrz8vFQpcd4uRaAiAZCijNI8uDmgVCaRvb/m FaM40FvCvHNBRvEA0yDcpFdAS5iAlmiHxIIsKUlESEk1MMqfd3IIPr2kSSbz0/SJOxj3RiaF 7T8w933cgltHJ3RNZLG7Ju877TDb6ZYtSw+eFKi7d2H9u+0PP9nd+LR91s4H66I+5/w9MdH6 RMD112lmD3X2p0UqtqY6SR/u6dE7NuvRjy4Ldb/FdV56UqULtsRsZ7k4zyhqRlfJR5ETN2z+ nT681/PRyhgeJZbijERDLeai4kQAIcduqEADAAA=
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jul 2018 14:41:57 -0000

Hi Reshad,

On Thu, Jul 26, 2018 at 12:16:05AM +0000, Reshad Rahman (rrahman) wrote:
> Hi Benjamin and Jeff,
> Following our discussion in Montreal, would the following, or something along these lines, be OK with you in the Security Considerations section.
>    When BFD clients are used to modify BFD configuration (as described
>    in Section 2.1), any authentication and authorization for the BFD
>    configuration changes have to take place in the BFD clients.  For
>    example, if the BFD client is an IGP then the IGP SHOULD be
>    authenticated. Also, consideration should be given to the access control of
>    the BFD clients.

I can't speak for Jeff, but I think this is edging closer to the bits he
doesn't like.  (It seems to capture the topics I had in mind just fine,

>From our discussion in Montreal, it seemed like we might end up at
something more like:

When BFD clients are used to modify BFD configuration (as described
in Section 2.1), the BFD clients need to be included in an analysis of
the security properties of the BFD-using system (e.g., when considering the
authentication and authorization of control actions).  In many cases, BFD
is not the most vulnerable portion of such a composite system, since BFD is
limited to generating well-defined traffic at a fixed rate on a given path;
in the case of an IGP as BFD client, attacking the IGP could cause more
broad-scale disruption than (de)configuring a BFD session could cause.


> On 2018-07-15, 9:05 AM, "Benjamin Kaduk" <> wrote:
>     On Wed, Jul 11, 2018 at 11:32:18AM -0400, Jeffrey Haas wrote:
>     > Benjamin,
>     > 
>     > On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
>     > > "may be overkill in some circumstances" sounds exactly like an RFC 2119
>     > > SHOULD, does it not?
>     > 
>     > Putting it slightly a different way, I am always wary of trying to embed too
>     > much operational and security wisdom in documents for the following reasons:
>     > - What's wise in one set of circumstances may not be in another.  By being
>     >   proscriptive, you may lead to implementations that lack necessary
>     >   flexibility.
>     In my opinion, including guidance with the supporting motivation suffices
>     to leave flexibility for unanticipated future cases with differing needs.
>     > - You're imposing a level of fate binding between mechanisms that may
>     >   contravene desired behaviors from some operators that have split
>     >   operational roles.
>     If the stated motivation does not apply to operators with such split roles,
>     do we not think they are smart enough to see that the prerequisite is not
>     met and ignore the advice?
>     > [...]
>     > > To frame the same idea in a different fashion, we have this nice security
>     > > considerations boilerplate for YANG modules, talking about how the usual
>     > > access methods are NETCONF/RESTCONF, with MTI secure transport of ssh/TLS.
>     > > The scheme being described here is effectively providing a new access
>     > > mechanism (IGP) for a subset of the YANG module,
>     > 
>     > This is perhaps my personal disconnect.
>     > 
>     > Much of the point of providing a common configuration grouping for BFD for
>     > client protocols was to encapsulate, "I'm a client of BFD, here's my
>     > parameters".  An implementation is free to use the "please use bfd with
>     > these parameters for my protocol" or perhaps ignore them.  But in
>     > circumstances that an operator may wish to limit access to protocol BFD
>     > behavior, it has the existing ability in NACM to enforce its policy on those
>     > BFD nodes within the protocol tree.
>     > 
>     > What I feel you're saying is we need to call special attention to these
>     > instantiations that may be imported by some module.  
>     > 
>     > What I'm confused about is why such an import is any more special than any
>     > other import from another module.
>     I've been trying to wrap my head around your explanation for the past few
>     days, and I'm not sure I'm succeeding at it.  The only reason I'm raising
>     this point with this document is because there is text in the document like
>     "[f]or example, when a new IGP peer is discovered, the IGP would create a
>     BFD session to the newly discovered peer and similarly when an IGP peer
>     goes away, the IGP would remove the BFD session to that peer."  Imagine if
>     I was writing a document about a device that controls a physical door, and
>     the usual way to operate the device is to manually enter a PIN while
>     physically in front of the door.  If I also said "some people expose this
>     door-unlocking device to the internet and accept unlock requests over
>     HTTP", that would be incredibly unresponsible of me unless I added some
>     extra qualifier.  Perhaps it would be "and these people are crazy", or
>     perhaps "but HTTP itself is insecure, so in such situations TLS ought to be
>     used with mutual authentication, authorization checks for the party
>     requesting unlocking, and the best practices from RFC 7525".
>     So, in my head, I see this document as using a not-quite-throwaway example
>     to make a point about the limitations of the main focus of the document,
>     and should properly qualify the different security properties of that
>     example.  Your description above still reads to me as if it's focusing on
>     YANG modules not specified in this document but that also use the same BFD
>     grouping.  In such a case, when the NACM applies, isn't that still going
>     through normal management paths for that respective YANG module?  I'm still
>     trapped in a rut thinking about "received IGP packet from the network that
>     instantiates a new IGP session; as a side effect instantiate a BFD session
>     as well", where the incoming IGP packet is just the IGP implementation and
>     not a "management function" per se.
>     -Benjamin