[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 23 April 2020 01:39 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC473A095C; Wed, 22 Apr 2020 18:39:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netmod-factory-default@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Kent Watsen <kent+ietf@watsen.net>, kent+ietf@watsen.net
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158760594357.26781.2457435467839506098@ietfa.amsl.com>
Date: Wed, 22 Apr 2020 18:39:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/elde6X-p5pW4Z15boX9Otp3B4VQ>
Subject: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 01:39:04 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-factory-default-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While many of the secdir reviewer's complaints stem from the YANG security considerations boilerplate, it still seems like it would be worth some form of response to the review. Section 1 This document defines a method to reset a server to its factory default content. The reset operation may be used, e.g., when the existing configuration has major errors so re-starting the configuration process from scratch is the best option. A "factory-reset" RPC is defined. When resetting a device, all previous configuration settings will be lost and replaced by the factory default content. nit: these two paragraphs talk about the same thing, but the next paragraph is a different thing. It may be better to combine these two in to a single paragraph. A "factory-default" read-only datastore is defined, that contains the data to replace the contents of implemented read-write conventional configuration datastores at reset. [...] Can I suggest instead: % A "factory-default" read-only datastore is defined, that reflects what the % conventional read-write datastores would be overwritten with in the case of % a factory-reset operation. Section 2 All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be overwritten with zeros or a pattern before deletion. [...] I might suggest instead: % When this process includes security-sensitive data such as cryptographic % keys or passwords, it is RECOMMENDED to perform the deletion in as % thorough a manner as possible (e.g., overwriting the physical storage % medium with zeros and/or random bits) to reduce the risk of the sensitive % material being recoverable. It's probably worth noting that since this is only dymanically generated files, any cryptographic keys that are part of the factory-installed image will be retained (such as an IDevID certificate). Section 3 Following the guidelines for defining Datastores in the appendix A of [RFC8342], this document introduces a new optional datastore resource named "factory-default" that represents a preconfigured initial configuration that can be used to initialize the configuration of a nit/soapbox: "preconfigured initial configuration" feels like an awkward wording to me; perhaps "pre-set initial configuration" or "fixed initial configuration"? Section 4 description "This read-only datastore contains the factory default configuration for the device used to replace the contents of the read-write conventional configuration datastores during a 'factory-reset' RPC operation."; nit: the grammar here is off; maybe "for the device that will be used"? (Or some adaptation of my proposed text from earlier.) Section 6 If the factory-default configuration is an "open" one, then performing the reset could leave the device (and thus the network!) vulnerable to attack until it is properly configured. The rtgdir reviewer's comments seem related to this. An attacker that could somehow cause the factory-reset to be performed would cause the loss of running state/crypto keys that would potentially require a lot of operator effort to recover (in addition to the more immediate DoS issues). There is some discussion in draft-ietf-anima-bootstrapping-keyinfra about attacks that are possible when a device is restored to its factory default state; it might be worth trying to incorporate some of that discussion in some manner (whether inline or by reference). The "factory-reset" RPC can prevent any further management of the device if the session and client config are included in the factory default contents. I'm not sure this is 100% correct. If the factory default config overwrites this items, then yes, it will prevent further management. But we also say to delete dynamic files from nonvoliatile storage, which at least to me seems like it could include this class of items and cause the same symptoms even if the configuration items in question are not included in the factory default contents.
- [netmod] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk via Datatracker
- Re: [netmod] Benjamin Kaduk's No Objection on dra… Qin Wu
- Re: [netmod] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk
- Re: [netmod] Benjamin Kaduk's No Objection on dra… Qin Wu
- Re: [netmod] Benjamin Kaduk's No Objection on dra… Benjamin Kaduk
- Re: [netmod] Benjamin Kaduk's No Objection on dra… Qin Wu