Subject: [Add] R2.1 (was RE: WGLC for draft-ietf-add-dnr)

From: <[email-masked]>
Date: Thu, 10 Mar 2022 07:26:24 +0000

Re-,

I have several comments:

  *   The draft has always this scope of RA/DHCP and I don’t remember that we received a request during the development of the spec to also consider ipv6cp/ipcp.
  *   Also, the document does not intend to cover every existing mechanisms. For example,
     *   as it seems that ADD WG attached less priority to secured discovery mechanisms, we are developing encrypted DNS IKE attributes in a separate spec (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/).
     *   We don’t include a proposal for PCO IE to cover mobile networks given that this is owned by 3GPP. A CR to support such IEs should be made following 3GPP procedures.
     *   Also, note that mobile networks can use Stateless DHCPv6 with the options defined in this spec following “normal” procedures, e.g., Section 2.7 of RFC7066.
  *   As you know, there is no IPV6CP option for DNS for obvious reasons. Please check pppext archives.
  *   I don’t think there is a need for ipcp extensions. If there is a need for IPCP options, this can be handled in a separate document, not in this one.

Thank you.

Cheers,
Med

De : Add <[email-masked]> De la part de Chris Box
Envoyé : mercredi 9 mars 2022 18:36
À : Deen, Glenn <Glenn_Deen=[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] WGLC for draft-ietf-add-dnr

Hi everyone.

    | R2.1        | Networks SHOULD be able to announce one or more   |

    |             | designated encrypted DNS resolvers using existing |

    |             | mechanisms such as DHCPv4, DHCPv6, IPv6 Router    |

    |             | Advertisement, and the Point-to-Point Protocol.   |

Met for the first three mechanisms, but PPP is missing. I'll come back to that in a minute.

…

Whichever generic format we select, it could then also be applied to PPP IPCP as a new extension:
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type TBA   |    Length     |      Encrypted-DNS-Server
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Encrypted-DNS-Server (cont)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

_________________________________________________________________________________________________________________________

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: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 10:29:31 +0100

On Thu, 10 Mar 2022 at 08:26, <[email-masked]> wrote:

>
>
>    - The draft has always this scope of RA/DHCP and I don’t remember that
>    we received a request during the development of the spec to also consider
>    ipv6cp/ipcp.
>    - Also, the document does not intend to cover every existing
>    mechanisms. For example,
>       - as it seems that ADD WG attached less priority to secured
>       discovery mechanisms, we are developing encrypted DNS IKE attributes in a
>       separate spec (
>       https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/).
>       - We don’t include a proposal for PCO IE to cover mobile networks
>       given that this is owned by 3GPP. A CR to support such IEs should be made
>       following 3GPP procedures.
>       - Also, note that mobile networks can use Stateless DHCPv6 with the
>       options defined in this spec following “normal” procedures, e.g., Section
>       2.7 of RFC7066.
>    - As you know, there is no IPV6CP option for DNS for obvious reasons.
>    Please check pppext archives.
>    - I don’t think there is a need for ipcp extensions. If there is a
>    need for IPCP options, this can be handled in a separate document, not in
>    this one.
>
>
This is a question for the working group to consider.

My view is that DNR should be an umbrella term for a set of closely-related
protocols that between them cover all networks in common use. This grants
the power of encrypted DNS to these networks while sharing as much code as
possible.

How many documents do we want to spread that across?

Chris

---

From: <[email-masked]>
Date: Wed, 23 Mar 2022 14:39:49 +0000

Hi Chris,

I think your question is about IPCP, not IPV6CP.

This is not a question about number, but whether there is interest to get an extension for a specific protocol made available.

We should at least agree that IPCP was never mentioned as a candidate during the dev of the DNR spec.

Cheers,
Med

De : Chris Box <[email-masked]>
Envoyé : mercredi 23 mars 2022 10:30
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] R2.1 (was RE: WGLC for draft-ietf-add-dnr)

On Thu, 10 Mar 2022 at 08:26, <[email-masked]<mailto:[email-masked]>> wrote:

My view is that DNR should be an umbrella term for a set of closely-related protocols that between them cover all networks in common use. This grants the power of encrypted DNS to these networks while sharing as much code as possible.

Chris

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 23 Mar 2022 15:16:52 +0000

I agree with Med; Chris, if you are interested in doing new work to address IPCP or anything else, you should share a draft so that we can discuss. I will review. The number of drafts this WG produces should be driven by WG appetite for scenarios to be addressed, not a pre-meditated plan to address all possible scenarios.

The scope of DNR has been well-understood from its inception as DHCP (v4/v6) and RA because these are how end user (or even IoT) client devices, whose DNS behavior we are trying to improve, typically receive network configuration. I fail to see how a lack of IPCP support would cause DNR to fail in its goal, which makes it a new feature and not a missing dependency. It's certainly the first time I'm hearing about it in the ADD WG context.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, March 23, 2022 7:40 AM
To: Chris Box <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [Add] R2.1 (was RE: WGLC for draft-ietf-add-dnr)

Hi Chris,

Cheers,
Med

De : Chris Box <[email-masked]<mailto:[email-masked]>>
Envoyé : mercredi 23 mars 2022 10:30
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Add] R2.1 (was RE: WGLC for draft-ietf-add-dnr)

  *   The draft has always this scope of RA/DHCP and I don't remember that we received a request during the development of the spec to also consider ipv6cp/ipcp.
  *   Also, the document does not intend to cover every existing mechanisms. For example,

     *   as it seems that ADD WG attached less priority to secured discovery mechanisms, we are developing encrypted DNS IKE attributes in a separate spec (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ipsecme-add-ike%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C521f947934b34f91abbf08da0cdb0746%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836432121567586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VXzZjrWG9an7T31Gs5CmMijzfTQOBGhgUC7q7OCsqLg%3D&reserved=0>).
     *   We don't include a proposal for PCO IE to cover mobile networks given that this is owned by 3GPP. A CR to support such IEs should be made following 3GPP procedures.
     *   Also, note that mobile networks can use Stateless DHCPv6 with the options defined in this spec following "normal" procedures, e.g., Section 2.7 of RFC7066.

  *   As you know, there is no IPV6CP option for DNS for obvious reasons. Please check pppext archives.
  *   I don't think there is a need for ipcp extensions. If there is a need for IPCP options, this can be handled in a separate document, not in this one.

Chris

Thank you.

---

From: Chris Box <[email-masked]>
Date: Wed, 23 Mar 2022 17:30:01 +0100

On Wed, 23 Mar 2022 at 16:17, Tommy Jensen <[email-masked]>
wrote:

> I agree with Med; Chris, if you are interested in doing new work to
> address IPCP or anything else, you should share a draft so that we can
> discuss. I will review. The number of drafts this WG produces should be
> driven by WG appetite for scenarios to be addressed, not a pre-meditated
> plan to address all possible scenarios.
>

Tommy that makes a lot of sense, and I can offer a draft if needed. It's
just a question of how we group protocols into drafts. With this draft we
have three protocols in one, so I'm not getting the sense that there's a
rule of one to one.

> The scope of DNR has been well-understood from its inception as DHCP
> (v4/v6) and RA because these are how end user (or even IoT) client devices,
> whose DNS behavior we are trying to improve, typically receive network
> configuration. I fail to see how a lack of IPCP support would cause DNR to
> fail in its goal, which makes it a new feature and not a missing
> dependency. It’s certainly the first time I’m hearing about it in the ADD
> WG context.
>

It shouldn't be the first time, because Point-to-Point Protocol was listed
in requirement R2.1.  From my reading, RFC1332's IPCP is the part of PPP
that configures IP, and RFC1877 defines the delivery of Do53 resolvers
using IPCP extensions. Hence the task is to define an extension that
supports encrypted DNS.

Chris