Subject: [Add] I-D Action: draft-ietf-add-dnr-04.txt

From: [email-masked]
Date: Wed, 08 Dec 2021 22:51:46 -0800

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-04.txt
	Pages           : 21
	Date            : 2021-12-08

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 is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-add-dnr-04

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: <[email-masked]>
Date: Thu, 9 Dec 2021 06:59:00 +0000

Hi all, 

This version fixes an issue about DHCP option ordering: we used to rely upon the options appearance but this is against RFC7227.

We also made some editorial changes to clean the reference to the deployment I-D.

Looking forward seeing the I-D in WGLC. 

Cheers,
Med

> -----Message d'origine-----
> De : Add <[email-masked]> De la part de [email-masked]
> Envoyé : jeudi 9 décembre 2021 07:52
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Add] I-D Action: draft-ietf-add-dnr-04.txt
> 
> 
>         Title           : DHCP and Router Advertisement Options for the
> Discovery of Network-designated Resolvers (DNR)
> --
> Add mailing list
> [email-masked]
> 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.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Dec 2021 16:37:03 -0500

Now that the SvcPriority is included in the payload, I would suggest moving
the IP addresses to the beginning of the payload.  That would allow the
remainder to be syntactically identical to SVCB RDATA, so it can be
synthesized and parsed using the exact same code used for SVCB records.
(It would also save one byte.)

As I mentioned previously I would also prefer to provide the _count_ of IP
addresses, rather than the _length_ of the IP address field.  This avoids
the potential for memory safety vulnerabilities when Addr Length is
impossible (e.g. 13) and saves one byte for IPv6.

On Thu, Dec 9, 2021 at 1:59 AM <[email-masked]> wrote:

> Hi all,
>
> This version fixes an issue about DHCP option ordering: we used to rely
> upon the options appearance but this is against RFC7227.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 10 Dec 2021 07:08:27 +0000

Hi Ben,

No problem to list the IP addresses first as both are variable-length.

For the length vs. count, this is something we considered in the past. I have reported at that time that we depend on the dhc recommendations. As a reminder, the discussion we had with Bernie (dhc wg Chair) triggered https://mailarchive.ietf.org/arch/msg/dhcwg/gZ_EbiPVOt-3tARDeQHYLHbh8R8/.

Cheers,
Med

De : Ben Schwartz <[email-masked]>
Envoyé : jeudi 9 décembre 2021 22:37
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt

Now that the SvcPriority is included in the payload, I would suggest moving the IP addresses to the beginning of the payload.  That would allow the remainder to be syntactically identical to SVCB RDATA, so it can be synthesized and parsed using the exact same code used for SVCB records.  (It would also save one byte.)

As I mentioned previously I would also prefer to provide the _count_ of IP addresses, rather than the _length_ of the IP address field.  This avoids the potential for memory safety vulnerabilities when Addr Length is impossible (e.g. 13) and saves one byte for IPv6.

On Thu, Dec 9, 2021 at 1:59 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

> De : Add <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
> À : [email-masked]<mailto:[email-masked]>
> Cc : [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: <[email-masked]>
Date: Mon, 13 Dec 2021 13:34:12 +0000

Hi all,

The format was updated to list the IP addresses first: https://www.ietf.org/rfcdiff?url1=draft-ietf-add-dnr-04&url2=draft-ietf-add-dnr-05

Cheers,
Med

De : Add <[email-masked]> De la part de [email-masked]
Envoyé : vendredi 10 décembre 2021 08:08
À : Ben Schwartz <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt

Hi Ben,

Cheers,
Med

De : Ben Schwartz <[email-masked]<mailto:[email-masked]>>
Envoyé : jeudi 9 décembre 2021 22:37
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt

Cheers,
Med

Thank you.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 13 Dec 2021 10:12:23 -0500

This is not what I meant.  I meant that you can now get rid of the "ADN
length" field, because the authentication domain name is self-delimiting.
This makes the remainder of the payload (after the IPs) syntactically
identical to SVCB RDATA.

If we keep the ADN length field, then I don't think this reordering is an
improvement.

On Mon, Dec 13, 2021 at 8:34 AM <[email-masked]> wrote:

> Hi all,
>
>
>
> The format was updated to list the IP addresses first:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-add-dnr-04&url2=draft-ietf-add-dnr-05
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Add <[email-masked]> *De la part de*
> [email-masked]
> *Envoyé :* vendredi 10 décembre 2021 08:08
> *À :* Ben Schwartz <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt
>
>
>
> Hi Ben,
>
>
>
> For the length vs. count, this is something we considered in the past. I
> have reported at that time that we depend on the dhc recommendations. As a
> reminder, the discussion we had with Bernie (dhc wg Chair) triggered
> https://mailarchive.ietf.org/arch/msg/dhcwg/gZ_EbiPVOt-3tARDeQHYLHbh8R8/.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Ben Schwartz <[email-masked]>
> *Envoyé :* jeudi 9 décembre 2021 22:37
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt
>
>
>
> Now that the SvcPriority is included in the payload, I would suggest
> moving the IP addresses to the beginning of the payload.  That would allow
> the remainder to be syntactically identical to SVCB RDATA, so it can be

---

From: <[email-masked]>
Date: Mon, 13 Dec 2021 15:40:13 +0000

Ben,

We don’t introduce specific treatments based on the null label but rely on the explicit length field to identify name (like any other variable-length field in dhcp). This approach was reviewed by dhcp experts and are OK with it.

Cheers,
Med

De : Ben Schwartz <[email-masked]>
Envoyé : lundi 13 décembre 2021 16:12
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt

This is not what I meant.  I meant that you can now get rid of the "ADN length" field, because the authentication domain name is self-delimiting.  This makes the remainder of the payload (after the IPs) syntactically identical to SVCB RDATA.

If we keep the ADN length field, then I don't think this reordering is an improvement.

On Mon, Dec 13, 2021 at 8:34 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

De : Add <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 10 décembre 2021 08:08
À : Ben Schwartz <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-04.txt

Hi Ben,

Cheers,
Med

Cheers,
Med

Thank you.

Thank you.