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 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg