Last Call Review of draft-ietf-bfd-yang-09
|Requested rev.||no specific revision (document currently at 17)|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
|Requested by||Jeffrey Haas|
|Draft last updated||2018-02-21|
Secdir Last Call review of -09 by Christian Huitema
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.
|Reviewed rev.||09 (document currently at 17)|
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). Regards, Reshad. On 2018-02-01, 5:39 PM, "Christian Huitema" <firstname.lastname@example.org> 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 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.