Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
draft-ietf-ipsecme-add-ike-14
Yes
Roman Danyliw
No Objection
Erik Kline
Jim Guichard
(Andrew Alston)
(John Scudder)
Note: This ballot was opened for revision 10 and is now closed.
Roman Danyliw
Yes
Éric Vyncke
Yes
Comment
(2023-04-26 for -11)
Sent
Thank you for the work put into this document. It really helps to achieve the goals of the ADD WG :-) (only regret is that the IPSECME WGLC was not formally extended to the ADD WG, a little more of cross-WG collaboration is always welcome even if authors are also very active in ADD). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Patrick Mevzek, the DNS directorate reviewer, please consider this dns-dir review: https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir-telechat-mevzek-2023-04-04/ (and I have read Med's reply so all it good) and the previous https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc-mevzek-2023-03-16/ (and the authors/chairs have also replied) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if this may be the IPSECME WG usual process, it is not the IETF process). ## Section 1 In the discussion about private CA / address for the DNS resolver, one more sentence stating the obvious (when using a private CA then the client may use the digest info payload) would be welcome. Alternatively, moving this paragraph before the reference to the appendix will make it clearer the link with ENCDNS_DIGEST_INFO. ## Section 2 Should RFC 8499 be normative (note RFC 7296 is normative and used in the same way)? ## Section 3.2 What is the responder behaviour when receiving a CFG_REQUEST with "ADN Length" different from 0 ? Symmetrical case for the initiator when "Num Hash Algs" is not 1 in a CFG_SET. If the generic behaviour described in section 4 (`As a reminder, badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296].`), then why other fields (notably "R") have specific text ? The reminder of section 4 should rather be in section 3 (but this is a matter of taste). `Note that SHA2-256 is mandatory to implement` does this mean that SHA2-256 identifier *MUST* always be in the list or is it implicit and does not have to be in the list ? # NITS (non-blocking / cosmetic) ## Appendix A.1 No need to expand VPN as it is both well-known and used before without expansion ;)
Erik Kline
No Objection
Jim Guichard
No Objection
Paul Wouters
(was Discuss)
No Objection
Comment
(2023-05-10 for -13)
Sent
Thanks for the discussion and the resulting changes. It addresses my concerns.
Zaheduzzaman Sarker Former IESG member
(was Discuss)
Yes
Yes
(2023-04-28 for -13)
Sent
Thanks for addressing my discuss comments.. the -13 looks good to me.
Andrew Alston Former IESG member
No Objection
No Objection
(for -11)
Not sent
John Scudder Former IESG member
No Objection
No Objection
(for -11)
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2023-04-24 for -11)
Not sent
# GEN AD review of draft-ietf-ipsecme-add-ike-11 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/4W1GbLLH-dUSHMRjawTAsl7Zp38). ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Robert Wilton Former IESG member
(was Discuss)
No Objection
No Objection
(2023-04-27 for -11)
Sent
Clearing discuss based on proposed resolution text. Minor level comments: (2) p 0, sec This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ). Are there any updates needed to RFC 9061 needed to cover manageability aspects/updates of the attributes defined in this draft? Note, I'm not requesting that they be added to this draft, but instead, I want to check if there is any need or plan to address them. (3) p 2, sec 2. Terminology Do53: refers to unencrypted DNS. This term only turns up a few (3 times) in this doc, and its not clear to me that it improves its readability. I didn't know what it meant, possibly just referencing to "Unencrypted DNS" would be better for the wider audience? (4) p 3, sec 3.1. ENCDNS_IP* Configuration Payload Attributes - 0 if the Configuration payload has types CFG_REQUEST (if no specific DNS resolver is requested) or CFG_ACK. If the 'Length' field is set to 0, then later fields shown in Figure 1 are not present. I found this text unclear & confusing when combined with the following two paragraphs. I would suggest rewording the first sentence to something like: 0, if the Configuration payload has (i) type CFG_REQUEST and no specific DNS resolver is requested or (ii) type CFG_ACK. (5) p 13, sec Appendix A. Sample Deployment Scenarios Readability may be slightly improved by adding a sentence here to explain what the purpose of this section is. (6) p 14, sec Appendix A. Sample Deployment Scenarios Enterprise networks are susceptible to internal and external attacks. To minimize that risk all enterprise traffic is encrypted (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). Would "SHOULD be encrypted" be better than "is encrypted"? Or, alternatively, "Encrypting all internal enterprise traffic minimizes the risks of attacks (Section 2.1 of [I-D.arkko-farrell-arch-model-t]). (7) p 14, sec Appendix B. Examples I would suggest putting each of the two examples into its own subsection. Nit level comments: (8) p 4, sec 3.1. ENCDNS_IP* Configuration Payload Attributes - 0 if the Configuration payload has types CFG_REQUEST (if no specific DNS resolver is requested) or CFG_ACK. If the 'Length' field is set to 0, then later fields shown in Figure 1 are not present. - (4 + Length of the ADN + N * 4 + Length of SvcParams) for ENCDNS_IP4 attributes if the Configuration payload has types CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of included IPv4 addresses ('Num addresses'). Possibly "(4 + 'Length of the ADN' + (N * 4) + Length of SvcParams)", and similarly for IPv6, would be more explicit. (9) p 5, sec 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute * Length (2 octets, unsigned integer) - Length of the enclosed data in octets. This field MUST be set to "2 + 2 * number of included hash algorithm identifiers". For clarity, I suggest: "2 + (2 * 'number of included hash algorithm identifiers')" (10) p 6, sec 3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute * Length (2 octets, unsigned integer) - Length of the enclosed data in octets. This field MUST be set to "2 + 2 * number of included hash algorithm identifiers". * Num Hash Algs (1 octet) - Indicates the number of included hash algorithm identifiers. This field MUST be set to "(Length - 2)/2". I suggest, included 'hash algorithm identifiers'. Regards, Rob