Skip to main content

Telechat Review of draft-ietf-opsawg-add-encrypted-dns-10

Request Review of draft-ietf-opsawg-add-encrypted-dns
Requested revision No specific revision (document currently at 12)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2023-03-11
Requested 2023-02-27
Requested by Éric Vyncke
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Alan DeKok
I-D last updated 2023-03-09
Completed reviews Dnsdir Last Call review of -07 by Ralf Weber (diff)
Genart Last Call review of -09 by Robert Sparks (diff)
Intdir Telechat review of -10 by Tatuya Jinmei (diff)
Dnsdir Telechat review of -10 by Ralf Weber (diff)
Assignment Reviewer Tatuya Jinmei
State Completed
Request Telechat review on draft-ietf-opsawg-add-encrypted-dns by Internet Area Directorate Assigned
Posted at
Reviewed revision 10 (document currently at 12)
Result Ready w/issues
Completed 2023-03-09
I am an assigned INT directorate reviewer for
draft-ietf-opsawg-add-encrypted-dns-10.txt. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,

Based on my review, if I was on the IESG I would ballot this document as

I have the following (possible) DISCUSS/ABSTAIN level issue.

The draft states in section 5:

   Should any encrypted DNS-related information (e.g., Authentication
   Domain Name (ADN), IPv6 address) change, [...].  The NAS
   replaces the old encrypted DNS resolver information with the new one
   and sends a DHCPv6 Reconfigure message which leads the DHCPv6 client
   to initiate a Renew/Reply message exchange with the DHCPv6 server.

I suspect the use of Reconfigure is not always feasible. A Reconfigure message
needs to be authenticated (per RFC8415), and the only available method for the
authentication is the Reconfiguration Key Authentication Protocol. But this
protocol is weak in that a shared secret first needs to be sent from the server
to the client in plain text. It may be justifiable in the intended use case
(between a CPE and NAS, and the communication path between them can be
considered reasonably protected), but I believe such considerations should be
described explicitly, either/both in this section or/add in Section 6.

Now, I'm not sure if such an update operation is an integral part of this
draft. If it's considered to be a minor case (e.g. the information is mostly
static and periodic renew would suffice), or the matter of updates itself is
mostly out of scope of this doc, then my comment on this point is also minor.
On the other hand, if it's important to describe how such an update works with
this RADIUS extension, then I'd regard it as a DISCUSS level issue.  And, in
the latter case, I believe DHCPv4-specific considerations on the same point
should be included, too.

The following are other (possible) issues I found with this document that may
need be addressed before publication (I don't necessarily think these SHOULD be

(All of these are about Section 3)

- I wonder whether the two "may"s in this text need to be normative "MAY"s.

   RADIUS implementations may support a configuration parameter to
   control the DHCP options that can be included in a DHCP*-Options
   RADIUS attribute.  Likewise, DHCP server implementations may support
   a configuration parameter to control the permitted DHCP options in a
   DHCP*-Options RADIUS attribute.

- This "SHOULD" looks awkward to me. While it's a nice suggestion for
implementers, it doesn't affect interoperability.  I'd suggest making it a
non-normative recommendation.

   For ease of administrator configuration, the RADIUS server SHOULD
   expose the DHCP options and allow administrators to configure them,
   instead of requiring them to be entered as opaque data.