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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Dec 2018 10:21:37 -0800

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.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Dec 2018 23:03:49 +0000

Hi Alexey,

Thanks for your review!
See below for responses.

Kent // coauthor

> I have a small list of issues that I would like to discuss before
> recommending approval of this document:
>
>
> In Section 5.3:
>
> 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.

There is a Security Consideration on this very point, where is says:

   Implementations SHOULD limit the maximum number of recursive
   redirects allowed; no more than a half dozen seems reasonable.

Here's direct link:
  https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-25#section-9.9

Is this now acceptable as is?  If not, would it be suffice to 
add a reference the Security Consideration?  If not, then, yes,
a max-redirect value could be defined, but it would have to be 
somewhat high (25?) so that the standard doesn't prematurely
limit some unforeseen use.  Please advise.

>   Decimal  Description                             References

Aye, you're right!  At least, they're not referenced by name, which
complicates searching for them...  (see my next response for more)

> Did you intend to use the above OIDs here?

Yes, exactly, and also in two other places in Section 3.1.  In
all three instances, we could either:

  OLD:
    ...one of the OIDs described in Section 10.3,

  NEW1:
    ...one of the OIDs described in Section 10.3 (i.e., 
    id-ct-zerotouchInformationXML or id-ct-zerotouchInformationJSON),

or

  NEW2:
    ...one of the OIDs described in Section 10.3 (i.e., 
    1.2.840.113549.1.9.16.1.TBD1 or 1.2.840.113549.1.9.16.1.TBD2),

Do you have a preference?

> 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.

Agreed, and I responded to Adam previously as follows:

  ===start===
  You are quite right.  Here is the Github commit to add an IANA registration
  for the "zerotouch" service:  https://github.com/netconf-wg/zero-touch/commit/6280763339a3e91b9efb21703b26a6bdbf05349b.

  Please let me know if you suggest any further changes.  
  ===stop===

And likewise, Alexey, please also let me know if you suggest any 
further changes.  

> So just to double check, these would be zt-info._zerotouch._tcp.example.com,

I'm not a DNS expert, but my understanding is that lookup would be on, e.g., _zerotouch._tcp.example.com and that the TXT records would be returned as follows:

_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_info=base64encodedvalue=="
_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_cert=base64encodedvalue=="
_zerotouch._tcp.example.com.  3600  IN  TXT  "zt_voucher=base64encodedvalue=="

For instance ['\' added for readability]:

  # dig txt gab.com
  <snip/>
  ;; ANSWER SECTION:
  gab.com.		300	IN	TXT	"v=spf1 include:_spf.protonmail.ch mx ~all"
  gab.com.		300	IN	TXT	"ca3-56e3739f7f644cdaaa0e7edc903cf648"
  gab.com.		300	IN	TXT	"protonmail-verification=\
                                  96ca5019e36fc3a6dc5c4399efabe68792e55cc7"
  <snip/>

Do you feel that an example in the document is warranted?

> [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.

Good grief, fixed (in both locations)!

  s/[common-field-encoding]/Section 8.3/

> This is confusing, because I believe the following is a single entry
> in the list, not the whole list syntax:
>
> Also, "URI" deserve to be a Normative Reference, as it defines the
> generic syntax you are referring to.

I have ask my coauthor, Ian, to respond to this comment.

Thanks again!
Kent

---

From: [email-masked]
Date: Tue, 11 Dec 2018 16:52:22 +0100

Hi Alexey,

Thanks for the review. Please see my response for you comment on the Common Field Encoding below.

Thanks,
Ian

>> in the list, not the whole list syntax:

[if  Propose removing the ‘bootstrap-server-list:’ line and extending
the intro paragraph to read:

 "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). Each URI
 entry in the bootstrap-server-list is structured as follows:”

Also, I’ve added RFC7230 to the normative references.]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Dec 2018 16:45:45 +0000

Hi Kent,

>    redirects allowed; no more than a half dozen seems reasonable.

I think this is weaker than I would like. I also didn't read the second part (half dozen) as normative. So my suggestion is below.

> limit some unforeseen use.  Please advise.

I think I prefer something like this:

    Implementations MUST limit the maximum number of recursive
    redirects allowed; the maximum number of recursive
    redirects allowed SHOULD be 25.

And adding a reference to the Security Considerations.

I.e., I think imposing a limit should be a MUST with the value 25 recommended.

> Do you have a preference?

I think NEW1 is clearer.

>   for the "zerotouch" service:  
> https://github.com/netconf-wg/zero-touch/commit/6280763339a3e91b9efb21703b26a6bdbf05349b.

This looks reasonable. (Note, saying that this is an extension of HTTPS in a note doesn't help. I think it would be better to say "this protocol uses HTTPS as a substrate". The current text would make people wonder why you need to register a new service name.)
 
> I'm not a DNS expert, but my understanding is that lookup would be on, 
> e.g., _zerotouch._tcp.example.com and that the TXT records would be 
> returned as follows:
> 

This is not what your text is saying. I also don't think that your description is correct. "TXT record called X" is not something defined. You need to define TXT record which can contain attribute=value syntax and allowed attributes are one of 3 you define.

> Do you feel that an example in the document is warranted?

Definitely you should add some examples. 

> I have ask my coauthor, Ian, to respond to this comment.

Ok.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Dec 2018 16:46:42 +0000

Hi Ian,

On Tue, Dec 11, 2018, at 3:52 PM, [email-masked] wrote:
> Hi Alexey,
> 
> Thanks for the review. Please see my response for you comment on the
> Common Field Encoding below.> 
> Thanks,
> Ian
> 
>> 
>> 
>>>  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.>>> 
>>> "bootstrap-server-list:" to "bootstrap-server-list is a list of 1
>>> or more>>> items, each with the following syntax:" (Or something like this.)
>>> 
> [if  Propose removing the ‘bootstrap-server-list:’ line and extending> the intro paragraph to read:
> 
>  "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). Each URI>  entry in the bootstrap-server-list is structured as follows:”
> 
Yes, this looks good to me.

Thank you,
Alexey

---

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Dec 2018 19:48:47 +0000

Hi Alexey,

Responses below.

Also, please be advised that an update has been published that
we hope addresses all your comments:

    https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-26

Thanks,
Kent

> I think this is weaker than I would like. I also didn't read the second
> part (half dozen) as normative. So my suggestion is below.
>
>> Here's direct link: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-25#section-9.9
>> 

I incorporated your text, but in a slightly different way.  Instead of 
changing the Security Consideration, I changed the text in Section 5.3
directly and the *removed* that Security Consideration, as it is no 
longer needed with the new normative text.  Here's the new text:

   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.
   Implementations MUST limit the maximum number of recursive redirects
   allowed; the maximum number of recursive redirects allowed SHOULD be
   no more than ten.  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 redirect information is only
   able to redirect devices to bootstrap servers.

>> Do you have a preference?

Done!  (Section 3.1 updated)
Here's the new text:

   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 (i.e.,
   id-ct-zerotouchInformationXML or id-ct-zerotouchInformationJSON), or
   the OID id-data (1.2.840.113549.1.7.1).  When the OID id-data is
   used, the encoding (JSON, XML, etc.)  SHOULD be communicated
   externally.  In either case, the associated content is an octet
   string containing "zerotouch-information" data in the expected
   encoding.

>> > name, see https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.
>> 
>>   You are quite right.  Here is the Github commit to add an IANA 
>>   registration for the "zerotouch" service:  
> This looks reasonable. (Note, saying that this is an extension of HTTPS
> in a note doesn't help. I think it would be better to say "this protocol
> uses HTTPS as a substrate". The current text would make people wonder
> why you need to register a new service name.)
 
Section 10.6 now says "This protocol uses HTTPS as a substrate."

>> I'm not a DNS expert, but my understanding is that the lookup would be 
>> on, e.g., _zerotouch._tcp.example.com and that the TXT records would
>> be returned as follows:
>> 
> This is not what your text is saying. I also don't think that your description
> is correct. "TXT record called X" is not something defined. You need to define
> TXT record which can contain attribute=value syntax and allowed attributes are
> one of 3 you define.

Responding to this item turned out to be way more effort than anticipated.
The more I looked into DNS, the more I realized that a lot of what was
written wasn't saying things quite right.  In the end, after getting up
to speed on DNS and conferring with a DNS expert (Wes Hardaker), I updated
this section to more accurately say what was intended.  Here's a direct
link to the section in the just posted draft update:

  https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-26#section-4.2

> Section 4.2 in the updated draft now has examples for both queries and responses.

 
>> I have ask my coauthor, Ian, to respond to this comment.

Section 8.3 in the update draft includes the text that you and Ian agreed on.