Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Jeffrey Haas <jhaas@pfrc.org> Tue, 10 July 2018 23:46 UTC
Return-Path: <jhaas@slice.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 02A7A130DDC; Tue, 10 Jul 2018 16:46:38 -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 txfkOzxKLdIH; Tue, 10 Jul 2018 16:46:33 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BD94B1311CF; Tue, 10 Jul 2018 16:46:33 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 3D42E1E28F; Tue, 10 Jul 2018 19:46:22 -0400 (EDT)
Date: Tue, 10 Jul 2018 19:46:22 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Message-ID: <20180710234621.GD12853@pfrc.org>
References: <153064928232.4913.5177531623706237853.idtracker@ietfa.amsl.com> <69638E39-860F-4D2F-AE2B-3B0B0A7BA855@cisco.com> <20180704035647.GF60996@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180704035647.GF60996@kduck.kaduk.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/On-XomBq6a4ZgVjCqS-eZK6gX-I>
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: Tue, 10 Jul 2018 23:46:38 -0000
On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote: > On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote: > > <RR> I am not 100% sure I understand the point being made. Is it a question of underlying the importance of having the IGPs authenticated since the IGPs can create/destroy BFD sessions via the local API? > > That's the crux of the matter, yes. Since (in this case) the IGP state > changes are being translated directly into BFD configuration changes, > the NETCONF/RESTCONF authentication is not really used. So, any > authentication/authorization decisions that are made must be on the basis > of authentication at the IGP level. This does not necessarily mean a hard > requirement for IGP authentication, though using unauthenticated IGP would > then be equivalent (for the purposes of this document) to allowing > anonymous NETCONF/RESTCONF access. > > I'd be happy to just have a note in the security considerations that "when > BFD clients such as IGPs are used to modify BFD configuration, any > authentication and authorization for the configuration changes take place > in the BFD client, such as by using authenticated IGPs". But feel free to > reword in a better fashion; this is really just about acknowledging the new > access mechanism (since the boilerplate covers SSH/TLS for > NETCONF/RESTCONF). I must admit to being somewhat perplexed by the request here. In the cases where BFD as a top level module is not the creator of a BFD session, you seem to be concerned that BFD can be used to attack a resource by spoofing that non-BFD client. While this is perhaps logically true, it also means that you have a far greater problem of being able to spoof the underlying BFD clients. To give some real-world examples: - BGP typically requires explicit configuration for its endpoints. - Both OSPF and ISIS will require a matched speaker with acceptable configuration parameters for a session to come up. - Static routes with BFD sessions will require explicit configuration. In each of these cases, a client protocol that also wants to use BFD, the simple spoofing of the protocol endpoints is already a massive disaster since it will allow injection of control plane or forwarding state into the device. This is so much worse than convincing a BFD session to try to come up with its default one packet per mode that ... well, I'm boggled we're even talking about this. :-) My request would be that we not complicate the security considerations of this module for such cases. -- Jeff
- 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)