Skip to main content

Last Call Review of draft-ietf-netmod-factory-default-14
review-ietf-netmod-factory-default-14-secdir-lc-kent-2020-03-09-00

Request Review of draft-ietf-netmod-factory-default
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-03-16
Requested 2020-03-02
Authors Qin Wu , Balázs Lengyel , Ye Niu
I-D last updated 2020-03-09
Completed reviews Yangdoctors Last Call review of -07 by Carl Moberg (diff)
Rtgdir Last Call review of -14 by Tony Przygienda (diff)
Genart Last Call review of -14 by Stewart Bryant (diff)
Secdir Last Call review of -14 by Stephen Kent (diff)
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-netmod-factory-default by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/eOlWlkpf9OCFU92bajM9w6jbB7w
Reviewed revision 14 (document currently at 15)
Result Has issues
Completed 2020-03-09
review-ietf-netmod-factory-default-14-secdir-lc-kent-2020-03-09-00
SECDIR review of draft-ietf-netmod-factory-default-14

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 with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This is a very brief document- only 9 pages (ignoring notes that are to be
removed before publication)! It is a proposal for a YANG data model that will
allow clients to reset a server to its factory default settings. It also
defines a “factory-default” datastore that enables a client to determine the
values for the default settings for a server. The datamodel is said to conform
to the architecture defined in RFC 8342.

RFC 8342, and RFC 7950, define the terms used in this document, and the
terminology Section (1.1) cites these RFCs when enumerating these terms. This
reader would prefer to have the definitions replicated here for the nine terms
in question. Only one additional term is defined in this document, the
factory-default datastore. The acronym “RPC” (remote procedure call) is not
expanded upon first use.

The description of how to effect a factor-reset RPC, in Sections 2 & 3 seems
pretty thorough, and includes appropriate comments about security-relevant
data, e.g., private keys and certificates. I an not familiar enough with YANG
to evaluate the module definition in Section 4.

Section 6, Security Considerations, calls for use of SSH (RFC 6242) with
NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current,
citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH
with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC
4253 for a description of SSH. 4253 is a very much out of date document; the
integrity and key management algorithms in the original RFC have been updated 3
times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all
outdated. This discussion of SSH security for use with NETCONF, based on the
one citation, seems to be inconsistent with current IETF crypto guidelines.
This is a problem that the net management area should address before this
document is approved.

The discussion of how a factory-reset RPC may isolate a device, is good, as is
the warning about not relying on this RPC to prevent recovery of
security-sensitive data from NV storage.