Skip to main content

Last Call Review of draft-ietf-netconf-system-notifications-
review-ietf-netconf-system-notifications-secdir-lc-weis-2011-12-04-00

Request Review of draft-ietf-netconf-system-notifications
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-11-29
Requested 2011-11-08
Authors Andy Bierman
I-D last updated 2011-12-04
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-netconf-system-notifications by Security Area Directorate Assigned
Completed 2011-12-04
review-ietf-netconf-system-notifications-secdir-lc-weis-2011-12-04-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This document defines a YANG module that allows a NETCONF client to receive
notifications for some common system events. Events reported include change of
system configuration, start or stop of of a NETCONF client, and the like. These
are important notifications for the purposes of accounting and auditing.

I have two comments on the Security Considerations text:

1) The first paragraph indicates that SSH is mandatory-to-implement for the
transport layer and cites RFC 6242 ("Using the NETCONF Protocol over Secure
Shell (SSH)". This is certainly good and acceptable, but I'm not sure where the
statement is made that says RFC 6242 MUST be implemented as part of a NETCONF
implementation. It would be good to cite that RFC as well.

2) The second paragraph wisely states that read access to the data nodes
described in this memo should be controlled. It would be helpful to give some
advice how the control can be done. For example, this could be an authorization
step by the SSH server as part of authenticating a client. Or it could be true
because authentication credentials known by server are only given to users who
are authorized to have read access. The first paragraph of RFC 62642's Security
Considerations discusses this a bit and seems to imply the latter authorization
model. If that's the intention here, a statement recommending giving out
authentication credentials only to users/devices authorized to read the NETCONF
notifications would be sufficient.

Brian