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

Jeffrey Haas <> Tue, 10 July 2018 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02A7A130DDC; Tue, 10 Jul 2018 16:46:38 -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 txfkOzxKLdIH; Tue, 10 Jul 2018 16:46:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD94B1311CF; Tue, 10 Jul 2018 16:46:33 -0700 (PDT)
Received: by (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 <>
To: Benjamin Kaduk <>
Cc: "Reshad Rahman (rrahman)" <>, 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.5.21 (2010-09-15)
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: 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

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