[Netconf] Alexey Melnikov's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

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.