Hi Patrick, Thank you for the careful review. Really appreciated. A candidate version to address your review can be seen at: https://tinyurl.com/add-ike-latest. Let's us know if any further change is needed. Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Patrick Mevzek via Datatracker <noreply@xxxxxxxx> > Envoyé : jeudi 16 mars 2023 21:44 > À : dnsdir@xxxxxxxx > Cc : draft-ietf-ipsecme-add-ike.all@xxxxxxxx; ipsec@xxxxxxxx; > last-call@xxxxxxxx > Objet : Dnsdir last call review of draft-ietf-ipsecme-add-ike-09 > > Reviewer: Patrick Mevzek > Review result: Ready with Nits > > I have been selected as the DNS Directorate reviewer for this > draft. The DNS Directorate seeks to review all DNS or DNS-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to > provide assistance to the ADs. > For more information about the DNS Directorate, please see > https://wiki.ietf.org/en/group/dnsdir > > There are clear and direct references to various DNS RFCs and > currently active IDs and this draft is not in any major conflict > with the wider DNS space. > > At the IETF process level, which I don't master, because of last > note in §4, shouldn't that document explicitly say it updates > RFC8598? [Med] We discussed this point at the time (and I was personally for adding the header), but we didn't because the convention in ipsecme WG is to not add the Update header if implementations are clearly able to distinguish the cases when an extension is being used even if the extension would change the behavior defined in the existing RFCs. In this spec, if the initiator receives any of ENCDNS_IP* attributes, it will know that it should not expect the INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The note you are referring to is to make that clear. Other WGs would follow a distinct approach. This is one of the areas where a more consistent approach should be followed in the IETF. > > I do have the following nits or questions from a client > implementor point of view to report, which may be caused by my own > very superficial knowledge of IKE, so feel free to ignore as > irrelevant: > > - §3.1 > > "Length (2 octets, unsigned integer) - Length of the data in > octets." > > It is explained further how it is computed, but just this sentence > alone is unclear for someone implementing it as not stating length > of which part of the content (as the length field is kind of "in > the middle" of the content itself) Med: Made this change: s/Length of the data in octets/Length of the enclosed data in octets I think this change with the text right after this one is clear how to set the field. Please let us know if you still think is not sufficiently clear. > > In §3.2, there is "Length (2 octets, unsigned integer) - Length of > the data in octets." as well, with then no explanation on which > data to consider for the length. > Med: Added this NEW text: OLD: Length (2 octets, unsigned integer) - Length of the enclosed data in octets. NEW: 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". > "Authentication Domain Name (variable) - A fully qualified domain > name of the encrypted DNS resolver following the syntax defined in > [RFC5890]." > > Maybe specify which part of RFC5890? > But I agree not finding myself there a single section clearly for > that point, nor is the DNS terminology RFC providing a single > definition. > Med: Fair point. We can reuse similar wording as in RFC8598 and indicate the following: "in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890]." > - §3.2 > > "List of Hash Algorithm Identifiers (variable) - Specifies a list > of 16-bit hash algorithm identifiers that are supported by the > encrypted DNS client." > > Is order of items in the list relevant or not? Med: No. > > "Note that SHA2-256 is mandatory to implement." > > SHA2-256 is only defined later in the document, at section 5 with: > "Implementations MUST support SHA2-256 [RFC6234]." > > So the reference might need to be moved to its first appearance, > from section 5 to 3.2 Med: We already added a reference to that section as per a comment we received from Dhruv (opsdir). > > Also, I don't know if it is customary from elsewhere, but RFC6234 > does not talk at all about SHA2-256 only about SHA256 or SHA-256, > no "SHA2". So maybe use the same moniker? > Same for other lengths, including in all examples at end. > > I see that > https://www.iana.org/assignments/ikev2-parameters/ikev2- > parameters.xhtml#hash-algorithms > references RFC7427 instead, which does use SHA2-256 terminology, > so maybe better to reference RFC7427 instead of RFC6234 above? > Med: We use SHA2-256 as this is the label in the authoritative IANA reference for signaling the algos in IKE. Please note that the entity that will compute the hash is not an IKE speaker (DNS clients/DNS servers). I prefer to keep RFC6234, but other thoughts are welcome. > - §A.1 > > "For split-tunnel VPN configurations, the endpoint uses the > Enterprise-provided encrypted DNS resolver to resolve internal- > only domain names." > > Maybe add that the endpoint knows which domains are internal-only > in that case due to the INTERNAL_DNS_DOMAIN attribute? > Med: Local provisioning mechanisms may also be considered. Added this NEW text: "These names may be configured to the endpoints using Enterprise-specific provisioning mechanisms or INTERNAL_DNS_DOMAIN attribute." _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
