Re: [Add] I-D Action: draft-ietf-add-dnr-01.txt

[[e-mail]]

Hi Ben,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[e-mail]]
Envoyé : mercredi 5 mai 2021 01:11
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
Cc : [e-mail]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-01.txt

Thanks for this update.  I think this is a good design.

Some notes:

Sections 4-6:
The ADN is self-delimiting, so the ADN length field is redundant in both encodings.  (It's also unnecessarily wide in the IPv6 encodings, since domain names are limited to 255 octets.)  I would suggest getting rid of the ADN length field.  For precedent, see the DNSSL option (RFC 8106 Section 5.2).

I wonder if anyone else would prefer an Addr Count instead of Addr Length?  That would allow us to have a consistent 1-byte field for v4 and v6, and avoid the divisibility requirements.  Better to multiply than divide!
[Med] I confirm that we first considered “Addr Count” but changed it. This was one of the discussion points I had with Bernie and which triggered this thread in dhc WG: https://mailarchive.ietf.org/arch/msg/dhcwg/baHgUt99kHmqSB5pmhPm6YyN4O4/. For the your two points above, we will be following the guidelines from the dhc wg.

I think the draft should probably have a one-sentence warning like "Senders SHOULD NOT include ipv4hint or ipv6hint SvcParams, which would be superseded by the included addresses."
[Med] I went for a more strict wording:

“The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses.”

Section 7 and Appendices A+B:

I think these sections should move to a separate draft (where they can be full-fledged body text, and not merely appendices).  This guidance is not specific to DNR (it also applies to DDR), and applies to very particular deployment scenarios.  I also think that this operational guidance is much more speculative than the format itself, and I'd like them to be able to make progress independently.
[Med] I’m not sure if all applies to DDR, but it is fair to ask for separating the options design vs. deployment considerations. Let’s see what others think about this.

Section 8:

I would like this section to take a different approach.  Rather than simply enumerating attacks, I think we should be discussing the security properties that this process provides.  In particular, we need to be clear that DNR can guarantee that the resolver is the one selected by the DHCP sender, but it cannot provide any information about who that sender is.
[Med] This is more valid on the LAN side, not the WAN side.

One particular note: The draft says "Also, an attacker can use a public IP address and get an 'IP address'-validated public certificate from a CA to host an Encrypted DNS server.".  This is currently not supported: DNR requires an Authentication Domain Name, which cannot be an IP address.  (That's OK with me; I just think the text should be consistent.)
[Med] This one is left on purpose as the current spec does not preclude returning an “ADN Length” set to 0. In such case the IP address will be used as the authentication reference identifier. We don’t have an explicit text for it but this is a point we would like to have more feedback from the WG.

On Tue, May 4, 2021 at 6:03 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

This version takes into account the inputs received during the last IETF meeting: that is, leverage SVCB. One single option is thus defined to carry the authentication domain name, IP address(es), and service parameters. The service parameters are encoded as SvcParams specified in the SVCB I-D. We added text to explain the rationale of reusing that encoding + why one single option is defined.

We also updated the structure of section 3 to take into account some of the comments from Michael.

The DHCP part was reviewed by Bernie (co-chair of dhc wg). All seems good.

Cheers,
Med

> -----Message d'origine-----
> De : Add [mailto:[e-mail]<mailto:[e-mail]>] De la part de internet-
> [e-mail]<mailto:[e-mail]>
> Envoyé : mardi 4 mai 2021 14:42
> À : [e-mail]<mailto:[e-mail]>
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : [Add] I-D Action: draft-ietf-add-dnr-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Adaptive DNS Discovery WG of the
> IETF.
>
>         Title           : DHCP and Router Advertisement Options for
> the Discovery of Network-designated Resolvers (DNR)
>         Authors         : Mohamed Boucadair
>                           Tirumaleswar Reddy
>                           Dan Wing
>                           Neil Cook
>                           Tommy Jensen
>       Filename        : draft-ietf-add-dnr-01.txt
>       Pages           : 30
>       Date            : 2021-05-04
>
> Abstract:
>    The document specifies new DHCP and IPv6 Router Advertisement
> options
>    to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over-
>    TLS, DNS-over-QUIC).  Particularly, it allows to learn an
>    authentication domain name together with a list of IP addresses
> and a
>    set of service parameters to reach such encrypted DNS servers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-add-dnr-01
> https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-add-dnr-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org<http://tools.ietf.org>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> --
> Add mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add

_________________________________________________________________________________________________________________________

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.

--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add

_________________________________________________________________________________________________________________________

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.