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

Benjamin Kaduk <> Sun, 15 July 2018 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 609F1130DEA; Sun, 15 Jul 2018 06:05:00 -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 wBHeDBarhwd8; Sun, 15 Jul 2018 06:04:58 -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 0D2771294D0; Sun, 15 Jul 2018 06:04:57 -0700 (PDT)
X-AuditID: 1209190f-367ff70000001832-11-5b4b46783c1b
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 E2.CA.06194.8764B4B5; Sun, 15 Jul 2018 09:04:56 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w6FD4tGn021009; Sun, 15 Jul 2018 09:04:56 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w6FD4oos002503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jul 2018 09:04:53 -0400
Date: Sun, 15 Jul 2018 08:04:50 -0500
From: Benjamin Kaduk <>
To: Jeffrey Haas <>
Cc: Reshad Rahman <>, "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="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixG6nrlvh5h1tcPyitcXkt/OYLSbfXM1o sWnnTyaLGX8mMlvsP/iW1eLailZ2i89/tjE6sHtM+b2R1WPJkp9MHpd7t7IGMEdx2aSk5mSW pRbp2yVwZTxu+ctcsEehovXkNqYGxiapLkZODgkBE4lzjbdZuhi5OIQEFjNJ/PxykRHC2cgo 0bHsBDOEc5ZJoutPFztIC4uAqsT5B39ZQGw2ARWJhu7LzCC2iICixPz/nWwgDcwCU5gkbj/Y DNYgLBArcerTMaYuRg4OXgEdif9/eEDCQgI3mCVmXc0FsXkFBCVOznwCNpNZQEvixr+XYOXM AtISy/9xgIQ5BfQkTixfDbZKVEBZYm/fIfYJjAKzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi 1GTd4uTEvLzUIl0TvdzMEr3UlNJNjKAQ55Tk38E4p8H7EKMAB6MSD2+FjVe0EGtiWXFl7iFG SQ4mJVHeiS1AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8q8SBcrwpiZVVqUX5MClpDhYlcd7s RYzRQgLpiSWp2ampBalFMFkZDg4lCd4tLt7RQoJFqempFWmZOSUIaSYOTpDhPEDDt4PU8BYX JOYWZ6ZD5E8x6nL8eT91ErMQS15+XqqUOK+6K1CRAEhRRmke3BxQapLI3l/zilEc6C1hXjWQ Kh5gWoOb9ApoCRPQEr0OT5AlJYkIKakGRhYX9U82Klss+8UWHBL5OuFH0rmbJ62dRfebxBrr mxw+tE8zt/boL8P4yH0Wz18frry+eRVT/XzeU1+e1y3XDfQImpM6wV/wufbCPx/e9FRuTL37 pIldNnu1qFJ0lZzzvWtK1m4plq+XXDCx3j/3299//eq3z7VxM/j3pVoa75GeuU7CXvFboRJL cUaioRZzUXEiANqE1qwoAwAA
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: Sun, 15 Jul 2018 13:05:01 -0000

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.