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

Benjamin Kaduk <> Wed, 04 July 2018 03:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38312130F59; Tue, 3 Jul 2018 20:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jKPJ8FICI7bM; Tue, 3 Jul 2018 20:56: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 BC752130F86; Tue, 3 Jul 2018 20:56:57 -0700 (PDT)
X-AuditID: 1209190c-ecdff70000003cc8-b3-5b3c4588e1fe
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 8B.42.15560.8854C3B5; Tue, 3 Jul 2018 23:56:56 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w643usn5018721; Tue, 3 Jul 2018 23:56:55 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w643uoW4030648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2018 23:56:52 -0400
Date: Tue, 03 Jul 2018 22:56:49 -0500
From: Benjamin Kaduk <>
To: "Reshad Rahman (rrahman)" <>
Cc: The IESG <>, "" <>, Jeffrey Haas <>, "" <>, "" <>
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="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nrtvhahNt8OuOqsXkm6sZLTbt/Mlk MePPRGaL/QffslpcW9HKbvH5zzZGBzaPKb83snosWfKTyeNy71bWAOYoLpuU1JzMstQifbsE roy1zT3sBY+UKw58m8vWwDhdpouRk0NCwETia8985i5GLg4hgcVMEvvuvGGFcDYwSrxs+8wG 4Vxhkjja0sUC0sIioCJx4M1+dhCbDchu6L4M1M7BISJgKPFrjTVIPbPAJ0aJZeuvsILUCAvE Spz6dIwJxOYFWnfs4DxGEFtIoF5i85FFUHFBiZMzn4DNZxZQl/gz7xLYTGYBaYnl/zggwvIS zVtnM4PYnAK2EufvfwYrFxVQltjbd4h9AqPgLCSTZiGZNAth0iwkkxYwsqxilE3JrdLNTczM KU5N1i1OTszLSy3SNdTLzSzRS00p3cQIigROSZ4djGfeeB1iFOBgVOLhZaiwjhZiTSwrrsw9 xCjJwaQkyiu/ESjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhLdT3yZaiDclsbIqtSgfJiXNwaIk zpu9iDFaSCA9sSQ1OzW1ILUIJivDwaEkwfvBGahRsCg1PbUiLTOnBCHNxMEJMpwHaLieC8jw 4oLE3OLMdIj8KUZdjj/vp05iFmLJy89LlRLnVQMpEgApyijNg5sDSmAS2ftrXjGKA70lzLsA pIoHmPzgJr0CWsIEtKRnmyXIkpJEhJRUA+NuQyXzecvc1yjt+9f/1ire/X2Thm5N0uSKaZ8Y mdYY/ysodNa53Cpy/CrPWtYfq81Kv7Qu0mhfpHzyphDX8tp0hpvmDB9navt9fai4Y0H4BaGO RQIqp0N+m0oumzil9pDm0v6d7E+Md0W48sXNddR/86v3d9D8pz/TbCXZtEPO9+yfGv+BzU2J pTgj0VCLuag4EQA5Ycd2OwMAAA==
Archived-At: <>
X-Mailman-Version: 2.1.26
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, 04 Jul 2018 03:57:11 -0000

On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote:
> Hi,
> Thanks for the review. Please see inline <RR>.
> On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <> wrote:
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-bfd-yang-16: Discuss
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>     Please refer to
>     for more information about IESG DISCUSS and COMMENT positions.
>     The document, along with other ballot positions, can be found here:
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     Section 2.1 describes a scheme wherein an IGP may generate events that
>     cause BFD sessions to be created/destroyed; this effectively is proxying
>     commands from IGP over the local BFD API, which brings the authentication
>     and authorization of the IGP into scope, even if the local BFD
>     configuration access is authenticated.  (That is, the proxying component is
>     always authenticated, but now bears responsibility for performing
>     authentication/authorization/sanity checks on commands before proxying
>     them.)  Since IGP security is a topic for elsewhere, the changes to this
>     document seem scoped to documenting the requirements on the IGP/local proxy
>     for these checks, and arguably for only allowing authenticated IGP events
>     to create authenticated BFD sessions (though arguably not as well, for the
>     latter, since this is a YANG model document and not an architecture
>     document).
> <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

>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     I'm not very familiar with YANG notifications; is there a risk that they
>     can be abused as a DoS attack vector on the notification recipient by an
>     attacker (e.g., by causing a flapping series of state transition events or
>     by creating/destroying many sessions)?
> <RR> To do that an attacker would need to e.g. access the local device or the directly connected devices to cause those BFD state transitions.

Probably not the most effective vector available, then.

>     Regarding the Security Considerations:
>     It's unclear whether local-multiplier, the various intervals, and
>     authentication are the only nodes that merit mention for every
>     per-forwarding-path-type module.  For example, source/destination addresses
>     could be modified to direct traffic at unwitting recipients, and the
>     key-chain and meticulous settings also seem security-related.
>     Similarly, read-only access to the discriminators (and
>     key-chain/authentication information) could make it easier for an attacker
>     to spoof traffic.
> <RR> Good point. I will add those nodes.