[dhcwg] AD review of draft-ietf-opsawg-add-encrypted-dns-07

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Thanks for this document.  Here are my AD review comments for draft-ietf-opsawg-add-encrypted-dns-07

Moderate level comments:

(1) p 2, sec 1.  Introduction

   This document specifies two new RADIUS attributes: DHCPv6-Options
   (Section 3.1) and DHCPv4-Options (Section 3.2) Attributes.  These
   attributes can include DHCP options that are listed under the IANA
   registries that are created in Sections 8.4.1 and 8.4.1.  These two
   attributes are specified in order to accommodate both IPv4 and IPv6
   deployment contexts while taking into account the constraints in
   Section 3.4 of [RFC6158].

It isn't really clear to me why some of the registries are needed, specifically the ones in 8.4.1 and 8.4.2.  Why not allow any v4 or v6 DHCP attribute to be carried within the DHCPv6-Options or DHCPv4-Options field?


(2) p 4, sec 3.  DHCP Options RADIUS Attributes

   Absent any explicit configuration on the DHCP server, RADIUS supplied
   data by means of DHCP*-Options Attributes take precedence over any
   local configuration.

This point may be worth discussing.  Naturally, I would explicit configuration to a network device to generally take precedent over implicitly learned configuration from the network.


(3) p 6, sec 3.2.  DHCPv4-Options Attribute

      Permitted DHCPv4 options in the DHCPv4-Options Attribute are
      maintained by IANA in the registry created in Section 8.4.2.

Comparing this text to the description for v6, this description is silent on whether multiple instances of the same DHCPv4 option MAY be included.  Should that be specified here?


(4) p 10, sec 7.  Table of Attributes

   The following table provides a guide as what type of RADIUS packets
   that may contain these attributes, and in what quantity.

Am I right that this is just a duplication of what is described in section 3?  If so, perhaps change "guide" to "informative guide" and include text to refer back to the  canonical definition in section 3.


(5) p 13, sec 8.4.3.  Guidelines for the Designated Experts

   Registration requests that are undetermined for a period longer than
   28 days can be brought to the IESG's attention for resolution.

I'm wondering whether we need the process related text in this document at all, or whether we let IANA apply their standard policies?  I may be misinformed, but I'm not aware of many *-review mailing lists.


(6) p 15, sec 10.2.  Informative References

   [I-D.ietf-add-dnr]
              Boucadair, M., Reddy, T., Wing, D., Cook, N., and T.
              Jensen, "DHCP and Router Advertisement Options for the
              Discovery of Network-designated Resolvers (DNR)", Work in
              Progress, Internet-Draft, draft-ietf-add-dnr-13, 13 August
              2022, <https://www.ietf.org/archive/id/draft-ietf-add-dnr-
              13.txt>.

Should this be a normative reference?  E.g., if feels like the IANA registry values are bound to whatever is published in ietf-add-dnr.



Minor level comments:

(7) p 2, sec 1.  Introduction

   With the advent of encrypted DNS (e.g., DNS-over-HTTPS (DoH)
   [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ)
   [RFC9250]), additional means are required to provision hosts with
   network-designated encrypted DNS.  To fill that void,
   [I-D.ietf-add-dnr] leverages existing protocols such as DHCP and IPv6
   Router Advertisement to provide hosts with the required information
   to connect to an encrypted DNS resolver.  However, there are no
   RADIUS attributes that can be used to populate the discovery messages
   discussed in [I-D.ietf-add-dnr].  The same concern is likely to be
   encountered for future services that are configured using DHCP.

>From this introduction, I thought that this would be covering options for both DHCP and ND, but it looks like only DHCP is covered.  Perhaps this introduction text could be tweaked slightly to make this clearer?


(8) p 3, sec 3.  DHCP Options RADIUS Attributes

   These attributes use the "Long Extended Type" format in order to
   permit the transport of attributes encapsulating more than 253 octets
   of data.  DHCP options that can be included in the DHCP*-Options
   RADIUS attributes are limited by the maximum packet size of 4096
   bytes.  In order to accommodate deployments with large options,
   implementations are RECOMMENDED to support a packet size up to 65535
   bytes.

I didn't find this text clear.  E.g., limit is 4k but should support up to 64K.  Which implementations should support larger packet sizes?  Is this RADIUS implementations?


(9) p 5, sec 3.1.  DHCPv6-Options Attribute

      This field contains a list of DHCPv6 options.  Multiple instances
      of the same DHCPv6 option MAY be included.  Consistent with
      Section 17 of [RFC7227], this document does not impose any option
      order when multiple options are present.

Is there any requirement to merge multiple instances of options together, presumably they are logically just concatenated today.


(10) p 5, sec 3.1.  DHCPv6-Options Attribute

      Permitted DHCPv6 options in the DHCPv6-Options Attribute are
      maintained by IANA in the registry created in Section 8.4.1.

As per above, presumably there isn't just an DHCPv6 options registry that can be reused rather than needing a separate one to be setup and maintained.


(11) p 6, sec 4.1.  Context

   The RADIUS Attributes suboption [RFC4014] enables a DHCPv4 relay
   agent to pass identification and authorization attributes received
   during RADIUS authentication to a DHCPv4 server.  However, [RFC4014]
   defines a frozen set of RADIUS attributes that can be included in
   such a suboption.  This limitation is suboptimal in contexts where
   new services are deployed (e.g., support of encrypted DNS
   [I-D.ietf-add-dnr]).

I like 'suboptimal', very diplomatic. ;-)


(12) p 8, sec 5.  Applicability to Encrypted DNS Provisioning

         Figure 1: An Example of RADIUS IPv6 Encrypted DNS Exchange

As a minor comment, I wonder whether it would be helpful to also include RADIUS client in the NAS box description?


(13) p 12, sec 8.4.1.  DHCPv6

   IANA is requested to create a new sub-registry entitled "DHCPv6
   Options Permitted in the RADIUS DHCPv6-Options Attribute" in the
   "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
   [DHCP-RADIUS].

Do we need to define the definition of columns for this (and the v4 equivalent) registries.  E.g., do the values need to match another registry?


(14) p 12, sec 8.4.1.  DHCPv6

                      Table 4: Initial DHCPv6 Options
                          Permitted in the RADIUS
                          DHCPv6-Options Attribute

Is 144 (and 162 for v4) a permanent IANA assignment?  Or should the value be bound to that allocated by draft-ietf-add-dnr.


Nit level comments:

(15) p 2, sec 1.  Introduction

   This document specifies two new RADIUS attributes: DHCPv6-Options
   (Section 3.1) and DHCPv4-Options (Section 3.2) Attributes.  These
   attributes can include DHCP options that are listed under the IANA
   registries that are created in Sections 8.4.1 and 8.4.1.  These two
   attributes are specified in order to accommodate both IPv4 and IPv6
   deployment contexts while taking into account the constraints in
   Section 3.4 of [RFC6158].

Nit, "Sections 8.4.1 and 8.4.1", presumably should be 8.4.1 and 8.4.2?

Regards,
Rob