Hi Tatuya, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Tatuya Jinmei via Datatracker <nore...@ietf.org> > Envoyé : jeudi 9 mars 2023 23:10 > À : int-...@ietf.org > Cc : draft-ietf-opsawg-add-encrypted-dns....@ietf.org; last- > c...@ietf.org; opsawg@ietf.org > Objet : Intdir telechat review of draft-ietf-opsawg-add-encrypted- > dns-10 > > Reviewer: Tatuya Jinmei > Review result: Ready with Issues > > 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, see > https://datatracker.ietf.org/group/intdir/about/. > > Based on my review, if I was on the IESG I would ballot this > document as DISCUSS. > > 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, [...]. [Med] What is actually more important in this para is the part in [...]. That text is there to provide an example of when the attributes can be present in CoA-Request. 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. > [Med] These considerations are specific to the dhcp options that will be carried in the RADIUS attribute. The security considerations (including issues with the use of reconfigure) fall under this part: Security considerations specific to the DHCP options that are carried in RADIUS are discussed in relevant documents that specify these options. > 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 > "corrected"): > > (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. > [Med] I also hesitated, but MAY is not used here as this does not impact interop. I had to reread Sections 5/6 of RFC2119 regularly for may/MAY. > - 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. > > [Med] The use of normative language is justified here because we don't want the RADIUS servers to blindly pass data. What this text says is that the attributes should not be seen as opaque data by the RADIUS server but it should understand the encoding of the enclosed options. Thanks. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
