Last Call Review of draft-ietf-bfd-yang-09

Request Review of draft-ietf-bfd-yang
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-02-09
Requested 2018-01-24
Requested by Jeffrey Haas
Authors Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Santosh Pallagatti, Greg Mirsky
Draft last updated 2018-02-21
Completed reviews Secdir Last Call review of -09 by Christian Huitema (diff)
Rtgdir Last Call review of -09 by Ravi Singh (diff)
Yangdoctors Last Call review of -09 by Jürgen Schönwälder (diff)
Genart Last Call review of -14 by Meral Shirazipour (diff)
Secdir Last Call review of -14 by Christian Huitema (diff)
The BFD Yang module is a dependency for several routing-area drafts.  This interwork with those drafts, particularly with regards to session configuration, may have security implications that should be examined in tandem with the importing yang module.

The routing area directorate is requested to specifically examine interwork/usability of the BFD yang module with regards to the importing protocol yang modules.

It is understood that the deadline is likely overly aggressive, but was chosen to coincide mostly with the BFD WGLC on this document.  This document has been reviewed for BFD usability several times and is otherwise considered mature.
Assignment Reviewer Christian Huitema 
State Completed
Review review-ietf-bfd-yang-09-secdir-lc-huitema-2018-02-01
Reviewed rev. 09 (document currently at 17)
Review result Ready
Review completed: 2018-02-21


Christian, thank you for the review.

Regarding the concern expressed below, the alarm is issued at the other end via the Notifications (section 2.3).


On 2018-02-01, 5:39 PM, "Christian Huitema" <> wrote:

    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
    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.