Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
PFFC JHAAS <jhaas@pfrc.org> Mon, 30 July 2018 20:45 UTC
Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA7130ED8; Mon, 30 Jul 2018 13:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gra9wgTx5Q5z; Mon, 30 Jul 2018 13:45:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD6130E07; Mon, 30 Jul 2018 13:45:46 -0700 (PDT)
Received: from [10.105.118.35] (mobile-166-176-249-24.mycingular.net [166.176.249.24]) by slice.pfrc.org (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)
From: PFFC JHAAS <jhaas@pfrc.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <20180730144138.GG79679@kduck.kaduk.org>
Date: Mon, 30 Jul 2018 16:45:35 -0400
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, The IESG <iesg@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <016ED101-53A8-4E83-89B1-A2ACB619261A@pfrc.org>
References: <20180710234621.GD12853@pfrc.org> <DBDBAFD1-8280-4389-B7F9-08785FC01BF8@cisco.com> <650FCD2E-A555-447A-A7AA-87D67B4E2BDE@cisco.com> <D4C67FBF-10C0-4F22-B8C6-1D9DD9CFE7B0@cisco.com> <EB68C226-A9F7-4254-97D8-042FB6FB6DFF@cisco.com> <B14B0368-0795-4163-8A6D-A4D03B4568A1@pfrc.org> <20180711150238.GT59001@kduck.kaduk.org> <20180711153217.GO12853@pfrc.org> <20180715130447.GU59001@mit.edu> <A0093463-AE48-472D-BC40-A72087BFD37C@cisco.com> <20180730144138.GG79679@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/psrh_Y91YzWtZ5xwQWB1Qotl-qE>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 20:45:50 -0000
Benjamin, Your proposal would be fine. It basically says be mindful of the relationship. Jeff > On Jul 30, 2018, at 10:41, Benjamin Kaduk <kaduk@mit.edu> 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" <kaduk@mit.edu> 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 >> >>
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-1… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Acee Lindem (acee)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Acee Lindem (acee)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… PFFC JHAAS
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)