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

"Reshad Rahman (rrahman)" <> Wed, 01 August 2018 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7F86130DF6; Wed, 1 Aug 2018 14:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JJDuy92gewpZ; Wed, 1 Aug 2018 14:28:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BEC31277BB; Wed, 1 Aug 2018 14:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9460; q=dns/txt; s=iport; t=1533158906; x=1534368506; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AX6H/cX2epg+evU8upr3+BVHJt/TCgzPT6QcXdmkT2s=; b=kiqz40WyOjXZKwT+IGicCGugxDv12RHm/Ev3TZGbzzSzyAcDjjjeGlEJ RzlZkMrj2P8YKNdt80TToWOfnXnHDLRBhsylOGG3uUAIJSlqtpSmUTQar UC0vnBDzf7XfkPE0Adg17l/pWsWKXVktEFs6FsvbrldS1UWkYLT5ITgt6 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,433,1526342400"; d="scan'208";a="429122816"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2018 21:28:25 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w71LSP98002972 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Aug 2018 21:28:25 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 1 Aug 2018 16:28:24 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 1 Aug 2018 16:28:24 -0500
From: "Reshad Rahman (rrahman)" <>
To: PFFC JHAAS <>, Benjamin Kaduk <>
CC: "Acee Lindem (acee)" <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Date: Wed, 01 Aug 2018 21:28:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 01 Aug 2018 21:28:29 -0000

I'm integrating Benjamin's proposal in the next rev.


On 2018-07-30, 4:45 PM, "PFFC JHAAS" <> wrote:

    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