Re: [netconf] [Technical Errata Reported] RFC8572 (6685)

[[e-mail]]

Hi Alex,

I suggest that we continue this discussion off-list and see if we can get the config working.

Thanks,
Ian

From: Alex Krichevsky <[e-mail]>
Date: Thursday, 23. September 2021 at 16:34
To: Farrer, Ian <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Ofer Rotschield <[e-mail]>, Evgeny Lischuk <[e-mail]>, Michael Freidkin <[e-mail]>, Dan Berin <[e-mail]>
Subject: RE: [Technical Errata Reported] RFC8572 (6685)
Hi Ian,

I tried this hex method.

On the server:
subnet 10.30.30.0 netmask 255.255.255.0 {
  range 10.30.30.50 10.30.30.200;
  option broadcast-address 10.30.30.255;
  option routers 10.30.30.17;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  option sztp-redirect 00:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:31:2e:63:6f:6d:2f:0a:00:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:32:2e:63:6f:6d:2f:0a;
}

I get on the client side the following:
lease {
  interface "eth1.106";
  fixed-address 10.30.30.125;
  option subnet-mask 255.255.255.0;
  option sztp-redirect 0:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:31:2e:63:6f:6d:2f:a:0:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:32:2e:63:6f:6d:2f:a;
  option routers 10.30.30.17;
  option dhcp-lease-time 515172565;
  option dhcp-message-type 5;
  option domain-name-servers 8.8.8.8,8.8.4.4;
  option dhcp-server-identifier 10.30.30.2;
  option broadcast-address 10.30.30.255;
  option domain-name "mplane.local";
  renew 3 2028/11/15 12:17:12;
  rebind 4 2035/05/31 07:34:43;
  expire 0 2037/06/14 15:30:58;
}

Note that for some reason, it is still transferred as an ASCII string containing hex codes with colons, exactly as it was configured on the server side, and the DHCP client does not decode it automatically. If we follow this approach, there should be some extra code that calculates the length, encodes it from ASCII to hex on the server side, and another code on the client side that decodes and extracts the entries.

Also, as I mentioned below:

RFC7227 provides guidelines for DHCPv6 options only, while section 8.3 refers to both DHCPv4 and DHCPv6. In case of DHCPv4, using RFC7227 is theoretically possible but you end up with option-length 1 octect long and uri-length 2 octects long. If option-length limits the length to 255 octects then having uri-length 2 octects long does not make sense. In case of DHCPv6, it’s fine since option-length is 2 octects long.

Since the RFC is relatively new, I can assume we are one of the first early adaptors who try to implement this. I can only give my feedback here that it looks much more complicated comparing to a simple straight-forward comma-separated format. In O-RAN, it’s all about interoperability. DHCP server and DHCP client can run on components that come from different vendors, so in my opinion, the format should be as simple and clear as possible.

Thanks,
Alex


From: [e-mail] <[e-mail]>
Sent: Wednesday, 22 September 2021 14:15
To: Alex Krichevsky <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Ofer Rotschield <[e-mail]>; Evgeny Lischuk <[e-mail]>; Michael Freidkin <[e-mail]>; Dan Berin <[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8572 (6685)

Hi Alex,

>From the ISC DHCP 4.4 server documentation (https://kb.isc.org/v1/docs/isc-dhcp-44-manual-pages-dhcp-options#DEFINING%20NEW%20OPTIONS) I think you could configure it to work as currently described in RFC8572 (taken from the ISC docs, I haven’t tested):

Use a custom option with a string type :
“An option whose type is a data string is essentially just a collection of bytes, and can be specified either as quoted text, like the text type, or as a list of hexadecimal contents separated by colons whose values must be between 0 and FF.”

e.g. for 2 bootstrap server URIs
https://example1.com/
Hex encoding: 68 74 74 70 73 3a 2f 2f 65 78 61 6d 70 6c 65 31 2e 63 6f 6d 2f 0a
https://example2.com/
Hex encoding: 68 74 74 70 73 3a 2f 2f 65 78 61 6d 70 6c 65 32 2e 63 6f 6d 2f 0a

Each of these has a length of 22 bytes which need to be hex encoded using 2 octets, so 00 16 is prepended to each of entries for the uri-length field.

The resulting dhcpd.conf entry would be:

option option_v4_sztp_redirect code 143 = string;
option_v4_sztp_redirect 00:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:31:2e:63:6f:6d:2f:0a:00:16:68:74:74:70:73:3a:2f:2f:65:78:61:6d:70:6c:65:32:2e:63:6f:6d:2f:0a;

As mentioned, I haven’t tested the above, but I have been successful in using hex encoding for defining other options that are not explicitly implemented by a server in the past.

Alternatively, I think that you could also define the custom option as an array of records containing two fields { uint16, text }.

Thanks,
Ian

From: Alex Krichevsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 22. September 2021 at 10:51
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>, Farrer, Ian <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Ofer Rotschield <[e-mail]<mailto:[e-mail]>>, Evgeny Lischuk <[e-mail]<mailto:[e-mail]>>, Michael Freidkin <[e-mail]<mailto:[e-mail]>>, Dan Berin <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8572 (6685)
Hi Ian, Kent,

Thank you once again for your responses! Please see more details below.

Thanks,

Alex Krichevsky
Embedded Software Director
21 Hamelacha Street|Rosh Haayin, 48091|
Edan 1 Twin Building|Park Afek|P.O.Box 11459|Israel
Mobile: +972+506347290
Web: www.asocscloud.com<http://www.asocscloud.com/>|
Follow us on LinkedIn<https://www.linkedin.com/company/54063/>
[cid:[e-mail]16140]


From: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Sent: Monday, 20 September 2021 19:08
To: Alex Krichevsky <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8572 (6685)

Hi Alex,

               Per Ian’s response, are you okay with this Errata being closed?

Kent



On Sep 15, 2021, at 10:29 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi,

To clarify, is the errata meant to permit the configuration of multiple, comma separated bootstrap server URIs in a single entry for uri-data?
[Alex Krichevsky] It meant to redefine the format: replace the proposed uri-data format that includes uri-length field and URI field, by a string that may contain multiple comma separated URI entries.

If so, the intended function is to have one URI entry per uri-data entry (containing URI-length and the associated URI). Multiple instances of uri-data entry are permitted. I think the text describes this adequately as does the reference to RFC7227. From section 8.3:


“Both of the DHCPv4 and DHCPv6 options defined in this section encode

   a list of bootstrap server URIs.  The "URI" structure is a DHCP option that can contain multiple URIs (see [RFC7227], Section 5.7<https://datatracker.ietf.org/doc/html/rfc7227#section-5.7>).
   Each URI entry in the bootstrap-server-list is structured as follows:”
[Alex Krichevsky] I would suggest removing the reference to RFC7227 as well, for the following reasons:

  1.  RFC7227 provides guidelines for DHCPv6 options only, while section 8.3 refers to both DHCPv4 and DHCPv6. In case of DHCPv4, using RFC7227 is theoretically possible but you end up with option-length 1 octect long and uri-length 2 octects long. If option-length limits the length to 255 octects then having uri-length 2 octects long does not make sense. In case of DHCPv6, it’s fine since option-length is 2 octects long.
  2.  If you accept my proposal to have a comma separated list instead of the structure described in RFC7227, then RFC7227 should not be referenced as not applicable.


They could be represented in the DHCP server’s configuration via a comma separated list, but in the DHCP option sent to the client they need to be formatted as separate uri-data entries.
[Alex Krichevsky] That’s the point – please see my explanation about the server behavior below.

I’m unsure about the relevance of Note: “Most DHCP servers can only be configured with ASCII strings for options”

[Alex Krichevsky] As part of our O-RAN Management Plane implementation , we are trying to configure OPTION_V4_SZTP_REDIRECT on ISC DHCP server. This server is widely used and de-facto standard for Linux based implementations. Only ASCII strings for DHCP options data can be configured on the server, and the server just sends the exact string as it is configured. Therefore, bootstrap-server-list should be a plain ASCII string. But section 8.3 mandates using a structure that contains uri-length which is non-ASCII binary field. Because of that, we cannot implement section 8.3 as it is currently defined. This is actually the main reason why I submitted the errata. The idea is that the list would be sent in a comma-separated format, and the DHCP client side is responsible to parse and separate the URI entries.

This is just my proposal that I believe can work. Do you know if anyone was able to implement the existing definition by now?

The URI encoding scheme is defined by RFC3986, which only permits ASCII.

Thanks,
Ian

From: RFC Errata System <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 14. September 2021 at 13:25
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Farrer, Ian <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Technical Errata Reported] RFC8572 (6685)
The following errata report has been submitted for RFC8572,
"Secure Zero Touch Provisioning (SZTP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6685

--------------------------------------
Type: Technical
Reported by: Alex Krichevsky <[e-mail]<mailto:[e-mail]>>

Section: 8.3

Original Text
-------------
   Each URI entry in the bootstrap-server-list is structured as follows:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
    |       uri-length              |          URI                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

    * uri-length: 2 octets long; specifies the length of the URI data.
    * URI: URI of the SZTP bootstrap server.

Corrected Text
--------------
Multiple URI entries can be specified in a comma-separated list.

Notes
-----
Most of DHCP servers can be configured only with ASCII string for options.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8572 (draft-ietf-netconf-zerotouch-29)
--------------------------------------
Title               : Secure Zero Touch Provisioning (SZTP)
Publication Date    : April 2019
Author(s)           : K. Watsen, I. Farrer, M. Abrahamsson
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG