[Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 05 December 2018 18:21 UTC
Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4C1276D0; Wed, 5 Dec 2018 10:21:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netconf-zerotouch@ietf.org, Mahesh Jethanandani <mjethanandani@gmail.com>, Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>, netconf-chairs@ietf.org, mjethanandani@gmail.com, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154403409772.31942.18387130156502248943.idtracker@ietfa.amsl.com>
Date: Wed, 05 Dec 2018 10:21:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/13Aw_xzJ4VG7HYjpBLEw8VayrAs>
Subject: [Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2018 18:21:38 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-netconf-zerotouch-25: Discuss 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-netconf-zerotouch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a well written document, it was a pleasure to read. I have a small list of issues that I would like to discuss before recommending approval of this document: In Section 5.3: If the zero touch information artifact contains redirect information, the device MUST, within limits of how many recursive loops the device allows, process the redirect information as described in Section 5.5. This is the recursion step, it will cause the device to reenter this algorithm, but this time the data source will definitely be a bootstrap server, as that is all redirect information is able to redirect a device to. I think you need to specify a "max redirect" value in order to prevent intentional or unintentional misconfigurations. Without such limit it is trivial to introduce denial-of-service attack on naive device implementations. 2) 10.3. The SMI Security for S/MIME CMS Content Type Registry IANA is kindly requested to add two entries in the "SMI Security for S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with values as follows: Decimal Description References ------- -------------------------------------- ---------- TBD1 id-ct-zerotouchInformationXML [RFCXXXX] TBD2 id-ct-zerotouchInformationJSON [RFCXXXX] id-ct-zerotouchInformationXML indicates that the "zerotouch- information" is encoded using XML. id-ct-zerotouchInformationJSON indicates that the "zerotouch-information" is encoded using JSON. You define these values, but they are not used anywhere in the document. It looks like you intended for this to be used in several places, for example: 3.1. Zero Touch Information When the zero touch information artifact is unsigned, as it might be when communicated over trusted channels, the CMS structure's top-most content type MUST be one of the OIDs described in Section 10.3, or the OID id-data (1.2.840.113549.1.7.1), in which case the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either Did you intend to use the above OIDs here? case, the associated content is an octet string containing "zerotouch-information" data in the expected encoding. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 4.2. DNS Server To use a DNS server as a source of bootstrapping data, a device MAY perform a multicast DNS [RFC6762] query searching for the service "_zerotouch._tcp.local.". Alternatively the device MAY perform DNS- SD [RFC6763] via normal DNS operation, using the domain returned to it from the DHCP server; for example, searching for the service "_zerotouch._tcp.example.com". I agree with Adam that "zerotouch" much be a registered as service name, see <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml> Artifact to Resource Record Mapping: Zero Touch Information: Mapped to a TXT record called "zt-info" containing the base64-encoding of the binary artifact described in Section 3.1. Owner Certificate: Mapped to a TXT record called "zt-cert" containing the base64-encoding of the binary artifact described in Section 3.2. Ownership Voucher: Mapped to a TXT record called "zt-voucher" containing the base64-encoding of the binary artifact described in Section 3.3. So just to double check, these would be zt-info._zerotouch._tcp.example.com, etc? 8.1. DHCPv4 Zero Touch Option o bootstrap-server-list: A list of servers for the client to attempt contacting, in order to obtain further bootstrapping data, in the format shown in [common-field-encoding]. [common-field-encoding] in this and subsequent sections looks like a reference to Section 8.3. Please fix before publication, as this looks like an undefined reference. 8.3. Common Field Encoding Both of the DHCPv4 and DHCPv6 options defined in this section encode a list of bootstrap server URIs. The "URI" structure is an option that can contain multiple URIs (see [RFC7227], Section 5.7). bootstrap-server-list: This is confusing, because I believe the following is a single entry in the list, not the whole list syntax: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | uri-length | URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ o uri-length: 2 octets long, specifies the length of the URI data. o URI: URI of zerotouch bootstrap server, using the HTTPS URI scheme defined in Section 2.7.2 of RFC7230. URI MUST be in form "https://<ip-address-or-hostname>[:<port>]". So if I am correct above, please clarify this by changing "bootstrap-server-list:" to "bootstrap-server-list is a list of 1 or more items, each with the following syntax:" (Or something like this.) Also, "URI" deserve to be a Normative Reference, as it defines the generic syntax you are referring to.
- [Netconf] Alexey Melnikov's Discuss on draft-ietf… Alexey Melnikov
- Re: [Netconf] Alexey Melnikov's Discuss on draft-… Kent Watsen
- Re: [Netconf] Alexey Melnikov's Discuss on draft-… ianfarrer
- Re: [Netconf] Alexey Melnikov's Discuss on draft-… Alexey Melnikov
- Re: [Netconf] Alexey Melnikov's Discuss on draft-… Alexey Melnikov
- Re: [Netconf] Alexey Melnikov's Discuss on draft-… Kent Watsen