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

PFFC JHAAS <> Mon, 30 July 2018 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1EA7130ED8; Mon, 30 Jul 2018 13:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gra9wgTx5Q5z; Mon, 30 Jul 2018 13:45:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9CCD6130E07; Mon, 30 Jul 2018 13:45:46 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 602881E290; Mon, 30 Jul 2018 16:45:29 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <>
Date: Mon, 30 Jul 2018 16:45:35 -0400
Cc: "Reshad Rahman (rrahman)" <>, "Acee Lindem (acee)" <>, "" <>, "" <>, The IESG <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Benjamin Kaduk <>
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 20:45:50 -0000


Your proposal would be fine. It basically says be mindful of the relationship. 


> On Jul 30, 2018, at 10:41, Benjamin Kaduk <> wrote:
> 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,
> though.)
>> 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.
> -Benjamin
>> 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