Subject: [Add] The ADD WG has placed draft-btw-add-home in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Wed, 27 Jan 2021 15:15:31 -0800

The ADD WG has placed draft-btw-add-home in state
Candidate for WG Adoption (entered by Glenn Deen)

The document is available at
https://datatracker.ietf.org/doc/draft-btw-add-home/

Comment:
Based on list and discussion during the January 27th ADD Interim this
document is being put up for call for WG Adoption.

WG Call for adoption is open until February 10th, 2021

---

From: <[email-masked]>
Date: Thu, 28 Jan 2021 11:53:19 +0000

Hi all, 

I support this draft, obviously. 

FWIW, I don't have any IPR related to this draft.

Cheers,
Med

> -----Message d'origine-----
> De : IETF Secretariat [mailto:[email-masked]]
> Envoyé : jeudi 28 janvier 2021 00:16
> À : [email-masked]; [email-masked]; [email-masked]
> Objet : The ADD WG has placed draft-btw-add-home in state "Candidate
> for WG Adoption"
> 
> 
> The ADD WG has placed draft-btw-add-home in state Candidate for WG
> Adoption (entered by Glenn Deen)
> 
> Based on list and discussion during the January 27th ADD Interim
> this document is being put up for call for WG Adoption.
> 

_________________________________________________________________________________________________________________________

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: Eric Orth <[email-masked]>
Date: Thu, 28 Jan 2021 11:43:22 -0500

I support adoption.  The general idea/mechanisms seems pretty
non-controversial to me.

On Wed, Jan 27, 2021 at 6:15 PM IETF Secretariat <
[email-masked]> wrote:

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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 28 Jan 2021 15:44:39 -0500

I think this draft is solving the right problem, but I have some concerns
about the actual content.  Most of the draft seems to concern the exact
formats of how to deliver resolver information over DHCP/RA, and I think
these formats should largely be rewritten to harmonize with DEER.

Broadly, I see two paths forward:

1. Just include a domain name, and apply DEER's authenticated mode to
establish a connection.  This avoids duplication of configuration,
minimizes packet size, and reduces the risk of configuration skew in some
cases.
2. Adjust the DHCP/RA contents to be isomorphic to the information
retrieved from DEER.  Ideally, the information from either one would be
sufficient to populate the other, simplifying network setup, and the
formats would match (e.g. reuse the relevant RDATA formats).

If we adopt the draft as-is, I'd like to see it substantially revised in
one (or both?) of these directions.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 29 Jan 2021 16:10:07 +0000

I support adoption. I agree with Ben (which is why I'm putting my reply on top of his) that we need to try to harmonize the DEER and RA/DHCP mechanisms. If they aren't harmonized, then we'll spend too much time arguing over which takes precedence and we'll cause confusion among end users because different applications will choose to behave differently (because I don't think we'll be able to get consensus on a rule that RA/DHCP always takes precedence in a world where they might produce different outcomes for the same domain).

Because I agree that this is important, I think it's critical to define the 2 mechanisms at the same time. We shouldn't be defining one first, and then moving on to the other (and discovering too late that we missed something we should have put into the first to allow them to be harmonized). We should treat these 2 mechanisms as equals at this point in the design and work on them simultaneously - with a specific goal of ensuring harmonization. That is, we need to know that we can get the same outcome independent of which was used (in the absence of attackers or error conditions for one or the other).
Barbara

I think this draft is solving the right problem, but I have some concerns about the actual content.  Most of the draft seems to concern the exact formats of how to deliver resolver information over DHCP/RA, and I think these formats should largely be rewritten to harmonize with DEER.

1. Just include a domain name, and apply DEER's authenticated mode to establish a connection.  This avoids duplication of configuration, minimizes packet size, and reduces the risk of configuration skew in some cases.
2. Adjust the DHCP/RA contents to be isomorphic to the information retrieved from DEER.  Ideally, the information from either one would be sufficient to populate the other, simplifying network setup, and the formats would match (e.g. reuse the relevant RDATA formats).

If we adopt the draft as-is, I'd like to see it substantially revised in one (or both?) of these directions.

On Thu, Jan 28, 2021 at 11:43 AM Eric Orth <ericorth=[email-masked]<mailto:[email-masked]>> wrote:
I support adoption.  The general idea/mechanisms seems pretty non-controversial to me.

On Wed, Jan 27, 2021 at 6:15 PM IETF Secretariat <[email-masked]<mailto:[email-masked]>> wrote:

Comment:

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Jan 2021 17:36:45 +0100

Hi Ben,

First I support adoption.  I also believe the document will need some more work.  Below.

> On 28 Jan 2021, at 21:44, Ben Schwartz <bemasc=[email-masked]> wrote:
> 

I don’t know that this is necessary or desirable, depending on what happens with (2).  For instance, I would like to get away from a requirement that the IP address be in a cert.  I’m sorry if that sounds like Eliot’s latest bugaboo, but I think that will be DEER's (DDR’s?) weakness because of deployment asymmetries (at least in some models).  And I am not sure it will be necessary to have that cert there in this use case since DDR’s weakness is that it relies on unvalidated data in the first place(!) when DHCP is in play.  So…..

> 2. Adjust the DHCP/RA contents to be isomorphic to the information retrieved from DEER.  Ideally, the information from either one would be sufficient to populate the other, simplifying network setu…

I am thinking that the source of the data needs authentication.  How that authentication happens is a good discussion to have. If the information is signed and the signature can be verified to have come from a trusted entity, then I think we have ourselves a ballgame.  I think the challenge is what to do with mobile devices.  That might require some form of federation to really solve for.  Conveniently there are a few of those around (eduroam, open roaming, etc).  Lots of details to sift through.

Eliot

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 29 Jan 2021 18:05:45 +0100 (CET)

>     Il 29/01/2021 17:10 STARK, BARBARA H <[email-masked]> ha scritto:
> 
> 
> 
>     I support adoption. I agree with Ben (which is why I’m putting my reply on top of his) that we need to try to harmonize the DEER and RA/DHCP mechanisms. If they aren’t harmonized, then we’ll spend too much time arguing over which takes precedence and we’ll cause confusion among end users because different applications will choose to behave differently (because I don’t think we’ll be able to get consensus on a rule that RA/DHCP always takes precedence in a world where they might produce different outcomes for the same domain).
> 
>      
> 
>     Because I agree that this is important, I think it’s critical to define the 2 mechanisms at the same time. We shouldn’t be defining one first, and then moving on to the other (and discovering too late that we missed something we should have put into the first to allow them to be harmonized). We should treat these 2 mechanisms as equals at this point in the design and work on them simultaneously – with a specific goal of ensuring harmonization. That is, we need to know that we can get the same outcome independent of which was used (in the absence of attackers or error conditions for one or the other).
> 
I agree with Barbara (and I support adoption of the draft).

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 29 Jan 2021 17:37:08 +0000

I support adoption of this draft.

I will also second(third?) Barbara and Ben’s concerns around harmonization of the mechanisms. We have already been through this before with DHCHv6 and RA DNS options and preference between the two (https://tools.ietf.org/html/rfc8106#section-5.3.1) and I remember dealing with this in cable’s eRouter spec based on RFC7084 which had MUSTs for both DHCPv6 DNS_SERVERS and DOMAIN_LIST and Router Advertisement Recursive DNS Server (RDNSS) and DNS Search List options.

I feel like we should keep https://tools.ietf.org/html/rfc6731 in mind as well.

Cheers,
Jason

From: Add <[email-masked]> on behalf of Vittorio Bertola <vittorio.bertola=[email-masked]>
Date: Friday, January 29, 2021 at 12:06 PM
To: "STARK, BARBARA H" <[email-masked]>, "[email-masked]" <[email-masked]>, ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] The ADD WG has placed draft-btw-add-home in state "Candidate for WG Adoption"

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 29 Jan 2021 09:59:42 -0800

I support adoption, as this is the right basis for adding DHCP and RA hints for encrypted resolvers. I strongly agree that we need this to harmonize well with DEER/DDR, and am willing to work on ensuring that the formats of information are compatible.

Best,
Tommy

> On Jan 29, 2021, at 9:37 AM, Weil, Jason <[email-masked]> wrote:
> 
> I will also second(third?) Barbara and Ben’s concerns around harmonization of the mechanisms. We have already been through this before with DHCHv6 and RA DNS options and preference between the two (https://tools.ietf.org/html/rfc8106#section-5.3.1 <https://tools.ietf.org/html/rfc8106#section-5.3.1>) and I remember dealing with this in cable’s eRouter spec based on RFC7084 which had MUSTs for both DHCPv6 DNS_SERVERS and DOMAIN_LIST and Router Advertisement Recursive DNS Server (RDNSS) and DNS Search List options.
>  
> I feel like we should keep https://tools.ietf.org/html/rfc6731 <https://tools.ietf.org/html/rfc6731> in mind as well. 
>  
> Cheers, 
> Jason
>  
> From: Add <[email-masked] <mailto:[email-masked]>> on behalf of Vittorio Bertola <vittorio.bertola=[email-masked] <mailto:vittorio.bertola=[email-masked]>>
> To: "STARK, BARBARA H" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, ADD Mailing list <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]> 
> The contents of this e-mail message and 
> any attachments are intended solely for the 
> addressee(s) and may contain confidential 
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you 
> in error, please immediately alert the sender
> by reply e-mail and then delete this message 
> and any attachments. If you are not the 
> intended recipient, you are notified that 
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment 
> is strictly prohibited. -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 29 Jan 2021 17:18:26 -0500

On Fri, Jan 29, 2021 at 11:36 AM Eliot Lear <lear=[email-masked]>
wrote:

> > I think this draft is solving the right problem, but I have some
> concerns about the actual content.  Most of the draft seems to concern the
> exact formats of how to deliver resolver information over DHCP/RA, and I
> think these formats should largely be rewritten to harmonize with DEER.
> >
> I don’t know that this is necessary or desirable, depending on what
> happens with (2).  For instance, I would like to get away from a
> requirement that the IP address be in a cert.
>

To clarify, I meant the mode in DEER-00 Section 5 [1], which does not
involve IP-certificates.

[1] https://datatracker.ietf.org/doc/html/draft-pauly-add-deer-00#section-5

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 Jan 2021 10:31:37 +0100

Hi Ben,

> To clarify, I meant the mode in DEER-00 Section 5 [1], which does not involve IP-certificates.
> 
> [1] https://datatracker.ietf.org/doc/html/draft-pauly-add-deer-00#section-5 <https://datatracker.ietf.org/doc/html/draft-pauly-add-deer-00#section-5>

Well then in the immortal words of Emily Litella, never mind ;-)

Seriously, I appreciate the specificity.  My suggestion is simply that as draft-btw-add-home evolves, if someone catches something that would cause a problem with DEER/DDR (really… what’s it called?) that it simply be called out as part of the draft development process.  However, I do think the group should consider additional authentication methods in this draft, even if they are inconsistent with DEER/DDR, so long as they do not cause a conflict.

Eliot