Secdir last call review of draft-ietf-bfd-yang-09

Christian Huitema <huitema@huitema.net> Thu, 01 February 2018 22:39 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C2112F28B; Thu, 1 Feb 2018 14:39:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
To: <secdir@ietf.org>
Cc: rtg-bfd@ietf.org, draft-ietf-bfd-yang.all@ietf.org, ietf@ietf.org
Subject: Secdir last call review of draft-ietf-bfd-yang-09
X-Test-IDTracker: no
X-IETF-IDTracker: 6.71.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151752475872.25625.14658191049524252377@ietfa.amsl.com>
Date: Thu, 01 Feb 2018 14:39:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Wg5SlL12Cjm-OG-EAXwcoa8An9g>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Feb 2018 22:39:19 -0000

Reviewer: Christian Huitema
Review result: Has Nits

BFD, defined in RFC5880, is a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including interfaces, data
link(s), and to the extent possible the forwarding engines themselves, with
potentially very low latency. The Yang module defined in this draft enables
management of this protocol, such as toggling parameters or receiving
notifications.

As stated in the security section, the module is "to be accessed via the
NETCONF protocol [RFC6241]", and as such its security is pretty much tied to
that of NETCONF.

My only nit comes from reading section 6.8.16 of RFC 5880, about
"Administrative Control". This points to an obvious issue when the
administrator of a router disables BFD on a particular link, either by mistake
or by malice. This will make future failures harder to notify, and can affect
operation of the network. Nothing much can be done about that on the node
itself, but I would expect that disabling BFD would raise some kind of alarm at
the other end of the link. I did not understand how that alarm is described in
the Yang module, but that may be because I am not all that familiar with Yang.