Re: [homenet] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26
Hi Anthony, Thanks for the response and the multiple reviews. These reviews have been useful and in general I am happy with what we received from the various directorates - so thanks for the extra work. Yours, Daniel On Thu, Feb 9, 2023 at 5:31 AM Anthony Somerset wrote: > Hi Daniel > > > > I am happy with the proposed rewording of DDoS attack surface – this at > least remains accurate to what is taking place. > > > > Thanks > > > > Anthony > > > > *From: *Daniel Migault > *Date: *Wednesday, 08 February 2023 at 17:36 > *To: *Anthony Somerset > *Cc: *dns...@ietf.org , > draft-ietf-homenet-front-end-naming-delegation@ietf.org < > draft-ietf-homenet-front-end-naming-delegation@ietf.org>, > homenet@ietf.org , last-c...@ietf.org < > last-c...@ietf.org> > *Subject: *Re: [homenet] Dnsdir last call review of > draft-ietf-homenet-front-end-naming-delegation-26 > > CAUTION: This email has originated from a free email service commonly used > for personal email services, please be guided accordingly especially if > this email is asking to click links or share information. > > > > Hi Anthony, > > > > Thanks for the review. Please find below how we intend to address your > comments. > > > > Yours, > Daniel > > > > On Tue, Jan 31, 2023 at 12:32 PM Anthony Somerset via Datatracker < > nore...@ietf.org> wrote: > > Reviewer: Anthony Somerset > Review result: Ready with Issues > > Hello > > 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 are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > I previously Reviewed Version 18 of this draft and am re-rereviewing in > line with the comments I made in that review - > > https://datatracker.ietf.org/doc/review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/ > > Having re-read the new version a few times, and keeping track of the > various > reviews as not to duplicate reports for same issues i will try not say the > same > things again. > > I specifically note that Geoff has done a very definitive review of > version 25 > of the document and i won't repeat those comments in this review but > suffice > to say i do concur with the assessment of the situation in his review and > agree with the position of Ready with Issues as well > > I am happy with the large effort to reflow the document - it does now read > in a > more sensible order and helps with clarity. > > I am also happy with the additional security considerations that make > sense. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers - my original NIT was dealt with > but I > note that anycast is now referenced here which is still extraneous, we are > not > attempting to deal with the standard of how Public Authoritative Servers be > managed operationally > > > > I agree that we are not concerned on how the Public Authoritative Servers > are managed. I suppose the comment is concerning the following sentence. > > If that the case, I am not reading any suggestion on how these servers are > operated. Our main purpose here is to make sure the reader understands > which servers we are talking about. This is the sense of the sentence: "are > often implemented in an anycast fashion.". I propose to leave the text as > it, but remain open to changes if I am missing something. > > """ > > are the authoritative name servers for > the Public Homenet Zone. Name resolution requests for the > Registered Homenet Domain are sent to these servers. Some DNS > operators would refer to these as public secondaries, and for > higher resiliency networks, are often implemented in an anycast > fashion. > > """ > > > > > Section 3 - now Section 5 - i note specifically the comment about: > > "In the case the HNA is a CPE, outsourcing to the DOI protects the home > network > against DDoS for example." > > I personally would consider this a dangerously inaccurate statement. > > This offers NO protection against a DDoS, at best it (only) slightly > reduces > the attack sur
Re: [homenet] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26
Hi Anthony, Thanks for the review. Please find below how we intend to address your comments. Yours, Daniel On Tue, Jan 31, 2023 at 12:32 PM Anthony Somerset via Datatracker < nore...@ietf.org> wrote: > Reviewer: Anthony Somerset > Review result: Ready with Issues > > Hello > > 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 are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > I previously Reviewed Version 18 of this draft and am re-rereviewing in > line with the comments I made in that review - > > https://datatracker.ietf.org/doc/review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/ > > Having re-read the new version a few times, and keeping track of the > various > reviews as not to duplicate reports for same issues i will try not say the > same > things again. > > I specifically note that Geoff has done a very definitive review of > version 25 > of the document and i won't repeat those comments in this review but > suffice > to say i do concur with the assessment of the situation in his review and > agree with the position of Ready with Issues as well > > I am happy with the large effort to reflow the document - it does now read > in a > more sensible order and helps with clarity. > > I am also happy with the additional security considerations that make > sense. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers - my original NIT was dealt with > but I > note that anycast is now referenced here which is still extraneous, we are > not > attempting to deal with the standard of how Public Authoritative Servers be > managed operationally > I agree that we are not concerned on how the Public Authoritative Servers are managed. I suppose the comment is concerning the following sentence. If that the case, I am not reading any suggestion on how these servers are operated. Our main purpose here is to make sure the reader understands which servers we are talking about. This is the sense of the sentence: "are often implemented in an anycast fashion.". I propose to leave the text as it, but remain open to changes if I am missing something. """ are the authoritative name servers for the Public Homenet Zone. Name resolution requests for the Registered Homenet Domain are sent to these servers. Some DNS operators would refer to these as public secondaries, and for higher resiliency networks, are often implemented in an anycast fashion. """ > Section 3 - now Section 5 - i note specifically the comment about: > > "In the case the HNA is a CPE, outsourcing to the DOI protects the home > network > against DDoS for example." > > I personally would consider this a dangerously inaccurate statement. > > This offers NO protection against a DDoS, at best it (only) slightly > reduces > the attack surface exposed but it provides no meaningful additional > protection. > > I specifically repeat this and recommend the statement be removed or > re-worded > appropriately > > I see your point. I propose to replace: OLD: """ In the case the HNA is a CPE, outsourcing to the DOI protects the home network against DDoS for example. """ by NEW: """ In the case the HNA is a CPE, outsourcing to the DOI reduces the attack surface of the home network to DDoS for example. """ I assume the nit mentioned below have been addressed previously. In other words, no action is expected. Section 3.2 - Original NIT dealt with > > 1.1 - now 3 - NIT dealt with > > 3.1 now 5.1 - Typo fixed > > 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the > reflowing > of the document definitely helps here. > > Thanks > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet Mission accomplished ?
I (and probably with all co-authors) would like to thank Eric and the chairs Kiran and Stephen for their constant support in moving this work forward. We also thank the numerous reviewers for their careful reviews. Yours, Daniel On Wed, Feb 1, 2023 at 9:00 AM Kiran Makhijani wrote: > Hi Eric, > I am very happy to see that both the documents are now approved. Kudos to > the authors - I noticed they worked quite diligently in past few months to > bring the documents to approval level, addressing comments as they came in. > Thank you to you as well, for your continuous involvement in the process. > > With the naming architecture and dhc-options out, the WG has indeed > reached its logical conclusion. > Congratulations to the authors! > > —Kiran > > On February 1, 2023 at 1:07:22 AM, Eric Vyncke (evyncke) ( > evyncke=40cisco@dmarc.ietf.org) wrote: > > Dear Homenet, > > > > As you may have read on https://datatracker.ietf.org/wg/homenet/documents/ the > last WG documents have been approved for publication: > > - draft-ietf-homenet-front-end-naming-delegation-26 had a major rewrite > end of 2022 and the intended status is now experimental per IESG request > > - draft-ietf-homenet-naming-architecture-dhc-options-24 was approved > mid-2022 but I was delaying its approval until the main I-D was finally > approved, the change of status in the main document has created a downref > (i.e., a formal reference to an experimental I-D), but this downref was > accepted by the IESG > > > > All in all, it seems that the Homenet WG can now be closed. As the > responsible AD for Homenet, I will discuss with the chairs when to close > this long-lasting WG ;-) Of course, the mailing list will be kept active. > > > > Note: the perimeter security item of the charter will not be completed. > > > > As usual, comments are welcome. > > > > Regards and thanks for all the hard work done in Homenet > > > > -éric > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
Thanks for the feedback. We did remove one sentence with ULA but this is correct ULA has not entirely been removed. Yours, Daniel On Tue, Jan 17, 2023 at 9:25 AM Tim Chown wrote: > Thank you for the update Daniel, I am overall happy with the changes. I > suspect ULAs will be picked up by other reviews. > > Tim > > On 13 Jan 2023, at 19:17, Daniel Migault wrote: > > Hi Tim, > > Thanks for the feed backs. Please see how the document has been updated. > The ULA comment may remain open. > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6 > > You can also find some more description / comments inline. > > Thanks for the follow-up! > Yours, > Daniel > > > On Thu, Jan 12, 2023 at 10:28 AM Tim Chown wrote: > >> Hi, >> >> In-line... >> >> On 9 Jan 2023, at 18:15, Daniel Migault wrote: >> >> Hi Tim, >> >> Thanks for the review we updated the file as follows: >> >> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b >> >> Please see my responses in line for more details. >> >> Yours, >> Daniel >> >> On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker < >> nore...@ietf.org> wrote: >> >>> Reviewer: Tim Chown >>> Review result: Almost Ready >>> >>> Hi, >>> >>> I have reviewed this document as part of the Operational directorate's >>> ongoing >>> effort to review all IETF documents being processed by the IESG. These >>> comments were written with the intent of improving the operational >>> aspects of >>> the IETF drafts. Comments that are not addressed in last call may be >>> included >>> in AD reviews during the IESG review. Document editors and WG chairs >>> should >>> treat these comments just like any other last call comments. >>> >>> This document describes an architecture by which names and IP addresses >>> of >>> hosts or services may be made available in the public DNS through the >>> use of a >>> homenet naming authority (HNA) and associated (hidden) primary DNS >>> function >>> resident in the home network and a DNS outsourcing infrastructure (DOI) >>> function which through a distribution manager also acts as a secondary. >>> Methods >>> for synchronisation and control of the information between the HNA and >>> DOI are >>> presented. >>> >>> I would say this document is getting close to being Ready, but still has >>> issues. >>> >>> A significant problem is that the document is not particularly well >>> written. >>> The quality of the text is poor, with at least six typos or mistakes in >>> just >>> the initial two paragraph abstract, which does not put the reader in a >>> good >>> frame of mind to read the main body of the document. There are mistakes >>> throughout the document. I would suggest that a full check, from start >>> to >>> finish, is required before the draft can progress. >>> >>> It may be the fact that the draft is now over 10 years old means it has >>> been >>> “cobbled” over a long period and perhaps it therefore doesn’t flow as >>> well as >>> it would were it written from scratch today. >>> >>> General comments: >>> >>> The introduction section introduces a lot of new terms and language, and >>> notes >>> on how various elements and components are related, and communicate. A >>> clear >>> diagram would be really helpful here. There is one in 5.1, but a >>> high-level >>> one in section 1 would improve the document. >>> >>> You are probably right, but when we tried we almost ended up in >> repeating the figure of section 5.1 and finally removed it. If this is not >> essential, I would prefer to leave it as it is. >> >> >> The trouble is you are very familiar with the work. It’s a bit of a >> brick wall to those reading it for the first time, especially with so many >> new terms being used for things that could be referred to with more >> familiar terms. I would strongly recommend a figure early on, but >> obviously it’s up to the IESG as to what they want to see. >> >> > I have added a simplified figure of the architecture that I think is > readable. > >> Otherwise, I am ok with the general principle of what is proposed, i,.e. a >>> ‘hidden’ p
Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
Hi Tim, Thanks for the feed backs. Please see how the document has been updated. The ULA comment may remain open. https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6 You can also find some more description / comments inline. Thanks for the follow-up! Yours, Daniel On Thu, Jan 12, 2023 at 10:28 AM Tim Chown wrote: > Hi, > > In-line... > > On 9 Jan 2023, at 18:15, Daniel Migault wrote: > > Hi Tim, > > Thanks for the review we updated the file as follows: > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b > > Please see my responses in line for more details. > > Yours, > Daniel > > On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker < > nore...@ietf.org> wrote: > >> Reviewer: Tim Chown >> Review result: Almost Ready >> >> Hi, >> >> I have reviewed this document as part of the Operational directorate's >> ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written with the intent of improving the operational >> aspects of >> the IETF drafts. Comments that are not addressed in last call may be >> included >> in AD reviews during the IESG review. Document editors and WG chairs >> should >> treat these comments just like any other last call comments. >> >> This document describes an architecture by which names and IP addresses of >> hosts or services may be made available in the public DNS through the use >> of a >> homenet naming authority (HNA) and associated (hidden) primary DNS >> function >> resident in the home network and a DNS outsourcing infrastructure (DOI) >> function which through a distribution manager also acts as a secondary. >> Methods >> for synchronisation and control of the information between the HNA and >> DOI are >> presented. >> >> I would say this document is getting close to being Ready, but still has >> issues. >> >> A significant problem is that the document is not particularly well >> written. >> The quality of the text is poor, with at least six typos or mistakes in >> just >> the initial two paragraph abstract, which does not put the reader in a >> good >> frame of mind to read the main body of the document. There are mistakes >> throughout the document. I would suggest that a full check, from start to >> finish, is required before the draft can progress. >> >> It may be the fact that the draft is now over 10 years old means it has >> been >> “cobbled” over a long period and perhaps it therefore doesn’t flow as >> well as >> it would were it written from scratch today. >> >> General comments: >> >> The introduction section introduces a lot of new terms and language, and >> notes >> on how various elements and components are related, and communicate. A >> clear >> diagram would be really helpful here. There is one in 5.1, but a >> high-level >> one in section 1 would improve the document. >> >> You are probably right, but when we tried we almost ended up in repeating > the figure of section 5.1 and finally removed it. If this is not essential, > I would prefer to leave it as it is. > > > The trouble is you are very familiar with the work. It’s a bit of a brick > wall to those reading it for the first time, especially with so many new > terms being used for things that could be referred to with more familiar > terms. I would strongly recommend a figure early on, but obviously it’s up > to the IESG as to what they want to see. > > I have added a simplified figure of the architecture that I think is readable. > Otherwise, I am ok with the general principle of what is proposed, i,.e. a >> ‘hidden’ primary and a secondary in the DOI part, feeding the publicly >> accessible servers. But this could also be done with a standard DNS >> approach - >> should thus be noted and a section added pointing out the pros and cons >> of each >> approach? >> >> I suppose the standard approach you are referring to is the use of DNS > UPDATE. If that is the case, we tried to have such a section to state > differences between the two methods and removed it. The main difference is > that DNS UPDATE does not update the zone itself but of course one could > update each RRset of the zone. > > > Well, I don;’t think the primary has to live in the home network, for > example. I don’t think this draft describes a bad idea, but presenting the > trade-offs may be useful. Or perhaps that’s a separate draft. >
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)
Hi Paul, Thanks for the response. Please find my responses in line. You can find the changes there: https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/63/commits/0d45a331b5cd2595454578b13a2973f68ec9f0b6 Yours, Daniel On Mon, Jan 9, 2023 at 9:57 PM Paul Wouters wrote: > > On Mon, Jan 9, 2023 at 2:52 PM Daniel Migault wrote: > >> Hi Paul, >> >> Thanks for the review. We updated the document as follows. >> >> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/63/commits/f221d3413f71bf95f8961f8fe3c71e53f8f3dd20 >> > > Thanks for the update. > > >> The only comment that has not been addressed is the one concerning the >> MUD. You can find inline my comments. >> > > I'm not sure that's the only remaining issue left, see below. > > > >>> #1 Document Status >>> >>> As other ADs have pointed out, Standards Track would not be the right >>> intended status. Experimental would be a much better fit. I understand >>> this is done because otherwise 3gpp won't consider the document, but >>> whether the IETF should make its decisions based on that is something >>> I'd like to discuss with the other members of the IESG. >> >> > Note that this discussion happened, and the IESG decided that while the > situation > was a bit of an anomaly, to not block the document on this or insist to > change the > status to Experimental. > > >> >> >> #2 Security Considerations for DM/DOI missing >>> >>> There is no Security Considerations paragraph for the DM/DOI ? >>> >>> For example, if I want to use "ietf.org" for my Public Homenet >>> Zone, that should probably not be allowed to be served by the >>> ISPs DM/DOI infrastructure. Similarly, currently non-existing >>> domains like "mailietf.org" or TLDs should probably not be >>> allowed. When allowing subdomains of existing registrations, >>> perhaps it can recommend the DM/DOI does a verification check, >>> eg via draft-ietf-dnsop-domain-verification-techniques >>> >>> To my view, the protocol assumes the registered domain is legitimate, >> and this mostly because the HNA is authenticated. We do have a section that >> details ownership of the domain name is necessary. I think the draft you >> mention is a good fit in that section. >> > > Sure, it is a bit light there though. > > >> I am not against mentioning this in the security consideration, but one >> thing that remains unclear to me is if I am asking the DOI to server >> ietf.org, as the NS in the parent will not be updated, the zone will >> only be known to me. >> > > It is related to the same comments I gave to the catalog zone document, > spoofing via additional data sections. > > Say you use GoDaddy and push ietf.org as your Public Homenet Zone. > Indeed, no one will ask these godaddy servers normally. But now you > register another domain, > for example whateverisfree.org and give it an NS and A record of ietf.org. > Now a resolver resolvng whateverisfree.org goes to the godaddy nameserver > and it detects it can > add the A record for ietf.org to the response of the NS record for > whateverisfree.org. Now you might have poisoined a (non-DNSSEC) recursive > nameserver. > > A note in the security section on this would be good. No need to explain > this attack, just that there should be either a trust relationship, a new > domain natively hosted already by the DNS hoster, or some kind of domain > owner verification technique in use to prevent attacks against other > domains. > > >> Furthermore, I expect the DOI will realize very quickly the domain >> name is not legitimate. Then I am wondering if that is an issue. >> > > How would the DOI realize that? I can decide ietf.org is really my > internally used domain ? > > >> we have updated the text as follows: >> ## Registered Homenet Domain >> >> The DOI MUST NOT serve any Public Homenet Zone that it has not strong >> confidence the HNA owns the Registered Homenet Domain. >> Proof of ownership is outside the document and is assumed such phase has >> preceded the outsourcing of the zone. >> > > That is good enough for me. Thanks. > > >> >> #3 Conveying the name of the zone to use >>> >>> The HNA builds the Public Homenet Zone based on a template that >>> is >>> returned by the DM to the HNA. Section 6.5 explains how this >>> leverages the AXFR mechanism. >>> >>> If it uses AXFR, I guess the name itself cannot be part of
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault wrote: > > > On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson > wrote: > >> >> Roman Danyliw via Datatracker wrote: >> > [per -18] I’m not sure if this my misreading of the behavior of >> > internal clients. To clarify, the (internal) Homenet DNSSEC >> Resolver >> > will “... resolves the DS record on the Global DNS and the name >> > associated to the Public Homenet Zone (myhome.example) on the Public >> > Authoritative Servers.”? Why would the internal resolver serving a >> > request for an internal client for an internal service go to the >> Global >> > DNS if the information if it could come from the internal Homenet >> Zone >> > it is already configured with? >> >> Because it needs the glue records to prove it is authoritative. >> > There are cases - quite common - where the Homenet Authoritative server > does not exist. In such cases, the Homenet Resolvers just caches what is > published outside. > >> >> > As an operational consideration, why go >> > outside of the network if you don’t need to? As a privacy >> > consideration, why leak the request to an outside entity if the >> network >> > already has the information. >> >> We do mention in the version 21 that going outside has some privacy > implications. Note also that the resolver only goes outside once the TTL > has exceeded so that is not every time a DNS request is received. > > > [per -20] Thanks for the revised text: On the other hand, to provide >> > resilience to the Public Homenet Zone in case of WAN connectivity >> > disruption, the Homenet DNSSEC Resolver SHOULD be able to perform >> the >> > resolution on the Homenet Authoritative Servers. >> >> > -- Is there a reason this can’t be a MUST? >> > We finally put it to MUST while reviewing the SHOULD status - as requested by Murray ;-). The reason I was insisting on SHOULD is that I was reading MUST as mandating to implement the mechanism. I was literally ignoring the condition "IF you want to provide resilience ...". I apologize for the multiple round trips. > >> If the resolver and cache have been offline for long enough, any cached >> chain >> of DS/NS/DNSKEY records from . down to the myhome.example might have >> expired. >> (Consider a DNSSEC resolver on a host behind the gateway) >> >> What to do in this situation has many answers with different tradeoffs. >> >> Yes. answers and tradeoffs are indeed quite numerous and we can hardly go > beyond such a recommendation. Consider that the homenet an authoritative > server may not exist or the Homenet Naming Authority may play multiple > roles. Also keep in mind that our document is mostly focused on the Homenet > Naming Authority and Distributed Manager, not so much on the naming > architecture of the home network. As a result, strong recommendations > regarding the resolver may be a bit out of scope of the document. > >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Murray Kucherawy's Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)
Hi Murray,
Thanks for the review and please find below the changes we made:
We review all SHOULD and proceeded to some changes that you can find below:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f6ff51deb2bdca2894310ff17b28a1278740da90
The end result is 6 SHOULD.
The mangled part of section 4.1.1 has been fixed as mentioned below:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f66e354f883cd8aa879186e46ba6fbf30f098757
"""
* If the DOI is not the DNS Registrar, then the proof of ownership needs to
be established using some other protocol.
ACME {{?RFC8555}} is one protocol that would allow an owner of an existing
domain name to prove their ownership (but requires they have DNS already
setup!)
There are other ways such as putting a DOI generated TXT record, or web
site contents, as championed by entities like Google's Sitemaster and
Postmaster protocols.
"""
Yours,
Daniel
On Fri, Dec 30, 2022 at 9:54 PM Daniel Migault wrote:
> Hi Murray,
>
> Thanks for the review. I will provide a more complete review in a few
> days, but here are some quick and partial responses.
>
> Yours,
> Daniel
>
> On Fri, Dec 30, 2022 at 7:16 PM Murray Kucherawy via Datatracker <
> nore...@ietf.org> wrote:
>
>> Murray Kucherawy has entered the following ballot position for
>> draft-ietf-homenet-front-end-naming-delegation-25: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> According to the shepherd writeup (and assuming it still reflects reality
>> today; it's dated July of this year, nine revisions ago), there are no
>> implementations, and none are planned.
>
> One of the co-author (Ray) implemented it, but it is not published. I am
> planning to implement it as we recently had a use case for it.
>
>> There's no Implementation Status
>> section either. However, in the reply to Paul's earlier DISCUSS, there
>> as a
>> claim that some part of this was implemented. I've also been told there
>> is one
>> vendor planning to implement this, but that doesn't match the record. Can
>> someone clarify where we are today? The existence of implementations
>> would
>> certainly allay the previous concerns about complexity and clarity that
>> were
>> expressed in other prior ballot positions.
>>
>> This document has been in development for over 10 years. Assuming there
>> is no
>> wide deployment or an implementation to which one can refer, why are we
>> publishing this on the standards track? Wouldn't Experimental or
>> Informational
>> be more appropriate? The shepherd writeup doesn't explain why Proposed
>> Standard is justified; it just says "PS".
>>
> The reason we want a Standard Track is that our use case is 3GPP related
> and 3GPP only considers Standard Track.
>
>>
>> (Please note that RFC 2026 says implementations aren't required, so I am
>> not
>> requiring one either by posting this ballot. I just want to have the
>> discussion.)
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Thanks for all the work that went into this, especially since its last
>> pass
>> through the IESG.
>>
>> I generally found this to be readable if I look at it as an applicability
>> statement (RFC 2026, Section 3.2) over DNS for the Homenet use case. Was
>> that
>> the intent, or am I way off?
>>
>> Thanks to Darrel Miller for his ARTART review. (A second review on the
>> latest
>> revision is pending as I write this.)
>>
>> The last bullet of Section 4.1.1 appears to be mangled in a few places.
>> Please
>> review.
>>
>> I have my usual complaint about the use of SHOULD throughout the document:
>> SHOULD provides implementers with a choice, and generally the SHOULDs here
>> don't ack
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)
SHOULD follow the requirements of > [RFC9103]" and leave it up to 9103 to get updated for this document's > normative > reference to be considered updated as well. (this appears twice in the > document) > > changed > The use of a TLS session tickets [RFC8446], Section 4.6.1 is > RECOMMENDED. > > According to 2119, RECOMMENDED means SHOULD. I think that a SHOULD for > using TLS > session tickets is a bit strong. I could see that a setup like this might > not > need to communicate more than once every few days, in which case it is > likely > that the TLS session ticket has expired anyway. I think MAY would be more > appropriate here. > I am expecting more frequent SOA requests. > > The DM SHOULD ignore the Pre-requisite and Additional Data > sections, if > present. > > Why is this not a MUST ? > These fields are potentially left for future use. > > This document exposes a mechanism that prevents the HNA from being > exposed to queries from the Internet. > > It does not "expose a mechanism" for that. It did offer some policy > decisions on > how to limit queries and drop certain ones. Which is re-iterated in the > sentences immediately following this. I would remove this sentence. > > deleted > The DNSSEC keys are needed on an hourly to weekly basis, but not > more > often. > > This isn't entirely true, when devices' their IP addresses are being added, > removed of modified. Perhaps add some weasel wording like "are generally > needed > on an " > > changed > I find the term "home network operator" a bit misleading. We are really > talking > about endusers here, not qualified or licensed "operators". Some of the > Security Considerations given to these "home network operators" seems > rather > technical. Instead, I feel the protocol really needs to protect the enduser > from making mistakes. Perhaps the Security Considerations for them need to > be > tweaked to apply to the protocol and its implementers. > > I do agree. Home networks may also be quite large, and yes the considerations are more for the developers of the protocol which are expected to tweak it to their targeted end users. > Carriers may need to deploy additional mitigations to ensure that > attacks do not originate from their networks. The use of RFC8520 > (MUD) > filters is one such method. > > I didn't think MUD was deployed by Carriers for in-home devices? Do you > mean to > say that Carriers could recommend CPE equipment and in-home devices that > support the use of RFC8520 (MUD) filters ? Or do you envision MUD capable > devices in the HomeNet actually get their MUD profiles enforced by the > Carrier/ISP ? > > NITS: > > The DOI benefits from a cloud infrastructure > while the HNA is dimensioned for home network and as such likely > enable to support any load. > > Should that be "unable to support any load" ? > > yes. thanks. changed. > This specification defines a mechanism that re-use the [...] > > that re-uses > > changed > An error indicates the MD > > MD -> DM > > changed > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
e for DNSSEC, but is this a MUST? DNSSEC is mentioned
> many times, but this is unclear. In 5.1 and in 6.1 the sentence about this
> doesn’t say MUST, but later in section 11 it does. If it is a MUST, say so
> earlier. Of course, DNSSEC is not exactly pervasive as it is.
>
> This is how we would like things to be. However, we prefer the zone to be
signed by the DOI than not being signed.
> Specific comments:
>
> Abstract:
>
> “The names and IP address of the home network are present in the Public
> Homenet
> Zone by the Homenet Naming Authority (HNA)“ - “are present” needs
> correcting.
>
> change to set :
"""
The names and IP address of the home network are set in the Public Homenet
Zone by the Homenet Naming Authority (HNA), which in turn instructs an
outsourced infrastructure to publish the zone on the behalf of the home
owner.
"""
> “Home networks are increasingly numbered using IPv6 addresses, which makes
> this
> access much simpler.” - well, it means global addresses are available, but
> the
> issues of for example naming, numbering, firewalling and appropriate access
> control remain.
>
>
My understanding of the text you propose is that it can be interpreted as
there are no mechanisms to update the DNS and that we are raising multiple
issues that we do not deal with in the draft. I rephrase the abstract as
follows:
Home network owners may have devices or services hosted on this home
network that they wish to access from the Internet (i.e., from a network
outside of the home network).
Home networks are increasingly numbered using IPv6 addresses, which makes
this access much simpler, but their access from the Internet requires the
names and IP addresses of these devices and services to be made available
in the public DNS.
This document describes how an Home Naming Authority (NHA) instructs the
outsourced infrastructure to publish these pieces of information
in the public DNS.
The names and IP addresses of the home network are set in the Public
Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs
an outsourced infrastructure to publish the zone on the behalf of the home
network owner.
Section 3:
>
> ULA use here should be very strongly discouraged. For a “Public Homenet
> Zone”
> should we not use strong language for GUA? Documents talking about ULAs
> tend
> to take a long time to get published :)
>
> These are in my opinion recommendations that go a bit out of the scope of
the document as we limit our scope to the outsourcing mechanism. As a
result, I would prefer not to be too strong on these recommendations. We do
not limit what can be put in the zone file.
> Section 4:
>
> In 4.1.1 the method in bullet point 3 seems very ugly.
>
> This is an example. We updated the text as follows:
"""
* If the DOI is not the DNS Registrar, then the proof of ownership needs to
be established using some other protocol.
ACME {{?RFC8555}} is one protocol that would allow an owner of an existing
domain name to prove their ownership (but requires they have DNS already
setup!)
There are other ways such as putting a DOI generated TXT record, or web
site contents, as championed by entities like Google's Sitemaster and
Postmaster protocols.
"""
> Section 5:
>
> In the diagram, does the DOI in fact cover the public authoritative
> servers,
> given you say “The DOI will serve every DNS request of the Public Homenet
> Zone
> coming from outside the home network.“ As it is the diagram shows the DOI
> only
> populating the public authoritative servers?
>
> That seems correct, we will update the figure.
> In 5.2 does “protected” mean provision of confidentiality?
>
> at the very least with integrity protection, but here with TLS it means
confidentiality.
Section 6:
>
> In 6.1, “perhaps and” ?
>
> In 6.5, the use of a DNS zone transfer to provide commands seems ugly.
>
> this is the The HNA then performs a DNS Update operation
Section 12:
>
> Talks about power cycling of the HNA. This implies it’s resident on
> specific
> hardware, but what is expected or recommended? COPE an d HNA are sometimes
> used interchangeably in the document.
>
> This document considers the HNA is hosted on the CPE but the HNA may be
hosted elsewhere and the HNA should be seen as a function. In the
renumbering section, we prefer to say the CPE is being renumbered as
opposed to the function.
> Section 14:
>
> The document “exposes a mechanism” ?
>
> In 14.4, maybe mention here if any special considerations for a
> replacement CPE
> (and thus HNA if that model its used) are needed?
>
> Well, I believe that is more related to the operation of the HNA, and
this can be handled in multiple ways. The DHCP companion describes one way
to do.
Tim
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Murray Kucherawy's Discuss on draft-ietf-homenet-front-end-naming-delegation-25: (with DISCUSS and COMMENT)
Hi Murray, Thanks for the review. I will provide a more complete review in a few days, but here are some quick and partial responses. Yours, Daniel On Fri, Dec 30, 2022 at 7:16 PM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-25: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > -- > DISCUSS: > -- > > According to the shepherd writeup (and assuming it still reflects reality > today; it's dated July of this year, nine revisions ago), there are no > implementations, and none are planned. One of the co-author (Ray) implemented it, but it is not published. I am planning to implement it as we recently had a use case for it. > There's no Implementation Status > section either. However, in the reply to Paul's earlier DISCUSS, there as > a > claim that some part of this was implemented. I've also been told there > is one > vendor planning to implement this, but that doesn't match the record. Can > someone clarify where we are today? The existence of implementations would > certainly allay the previous concerns about complexity and clarity that > were > expressed in other prior ballot positions. > > This document has been in development for over 10 years. Assuming there > is no > wide deployment or an implementation to which one can refer, why are we > publishing this on the standards track? Wouldn't Experimental or > Informational > be more appropriate? The shepherd writeup doesn't explain why Proposed > Standard is justified; it just says "PS". > The reason we want a Standard Track is that our use case is 3GPP related and 3GPP only considers Standard Track. > > (Please note that RFC 2026 says implementations aren't required, so I am > not > requiring one either by posting this ballot. I just want to have the > discussion.) > > > -- > COMMENT: > -- > > Thanks for all the work that went into this, especially since its last pass > through the IESG. > > I generally found this to be readable if I look at it as an applicability > statement (RFC 2026, Section 3.2) over DNS for the Homenet use case. Was > that > the intent, or am I way off? > > Thanks to Darrel Miller for his ARTART review. (A second review on the > latest > revision is pending as I write this.) > > The last bullet of Section 4.1.1 appears to be mangled in a few places. > Please > review. > > I have my usual complaint about the use of SHOULD throughout the document: > SHOULD provides implementers with a choice, and generally the SHOULDs here > don't acknowledge that choice or provide implementers with any guidance > about > when it might be appropriate to exercise that choice. I suggest reviewing > them > (there are 25, and 6 RECOMMENDEDs) and either adding such prose, or > reconsidering whether they should be MUST or MAY. > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt
just one clarification: do we prefer to have a version 25 being published or should we leave it as version 24 ? Yours. Daniel On Wed, Dec 7, 2022 at 8:11 AM Daniel Migault wrote: > > > On Wed, Dec 7, 2022 at 7:56 AM Michael Richardson > wrote: > >> >> Eric Vyncke (evyncke) wrote: >> > As the text has changed a lot, not so much on the technical content >> but >> > more or completeness and readability, I will re-submit it to another >> > IESG evaluation early January in the hope that the IESG will approve >> > this draft. >> >> Thank you. >> >> > May I kindly request the authors to fix the idnits issues ? >> > >> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.txt >> > it is about a reference to RFC 6125 or its -bis and the use of >> > obsoleted RFC 5077. >> >> The text says: >> >>The HNA will validate the DM's control channel certificate by doing >>[RFC6125]/[I-D.ietf-uta-rfc6125bis] DNS-ID check on the name. >> >> The word "an" ought to be in front of [RFC6125]. >> I think that idnits is confused. >> >> I thought the UTA document was just a patch on RFC6125, but I see that >> it's a >> complete replacement, so referencing both makes less sense. >> >> Just removed rfc6125 > >> As for RFC5077. I have replaced it with RFC8446 (TLS1.3), section 4.6.1, >> but >> the reference feels less useful now. >> >> >> -- >> Michael Richardson. o O ( IPv6 IøT consulting >> ) >>Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt
On Wed, Dec 7, 2022 at 7:56 AM Michael Richardson wrote: > > Eric Vyncke (evyncke) wrote: > > As the text has changed a lot, not so much on the technical content > but > > more or completeness and readability, I will re-submit it to another > > IESG evaluation early January in the hope that the IESG will approve > > this draft. > > Thank you. > > > May I kindly request the authors to fix the idnits issues ? > > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.txt > > it is about a reference to RFC 6125 or its -bis and the use of > > obsoleted RFC 5077. > > The text says: > >The HNA will validate the DM's control channel certificate by doing >[RFC6125]/[I-D.ietf-uta-rfc6125bis] DNS-ID check on the name. > > The word "an" ought to be in front of [RFC6125]. > I think that idnits is confused. > > I thought the UTA document was just a patch on RFC6125, but I see that > it's a > complete replacement, so referencing both makes less sense. > > Just removed rfc6125 > As for RFC5077. I have replaced it with RFC8446 (TLS1.3), section 4.6.1, > but > the reference feels less useful now. > > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-23.txt
Thank Michael. I think the changes made are improving the clarity of the
text.
Yours,
Daniel
On Sat, Dec 3, 2022, 22:14 Michael Richardson wrote:
>
> internet-dra...@ietf.org wrote:
> > There is also an HTML version available at:
> >
> https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-23.html
>
> > A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-23
>
> Some notes from me.
> I've touched quite a lot of text through the document.
> It took me a half day on Tuesday/Wednesday/Thursday/Friday and today to do.
> (counting staring at the cat to figure out what to write)
>
> I have the advantage of not having really read it for a few months, so my
> proof reading is, I hope, beneficial to understanding without changing
> any content.
>
> I did however, delete figure 1, because it's basically repeated by figure
> 2,
> and I redrew figure 2 with asciio, and then made sure that it translated to
> SVG well. That made me adjust some things, and it had to fit in 72 columns
> too. I wound up truncating "Zo"ne. in one place.
>
> I see one place where markdown slipped through in {#sec-zone-delete}, and
> it's fixed in git.
>
> The technical place which I posted about a few days ago concerns where the
> Notifies go. I have placed them into the Control Channel.
>
> Note that the Control Channel offers:
> 1. AXFR to get the zone template.
> 2. DNSUPD to change the NS (Synchronization Channel), and the DS records.
> 3. receipt of Notify to poke the Synchization process.
>
> I have added some words about EKU on the certificates involved, basically
> saying to please ignore them. I posted to dnsop, and Daniel forwarded my
> query onwards, about this, as RFC9103 is silent about this. Ignoring them
> might be important, because if DOI Operator gets their certificates from
> LetsEncrypt via dns-01 challenge (a totally reasonable thing to do), then
> they probably will have an EKU with *WWW* TLS Client and *WWW* TLS Server
> bits set.
>
> I have tried to insert some of the more common terms from RFC8499, but
> there
> aren't enough terms, and the term "DOI" remains, and I'd be happy to
> replace
> it, but suggestions of "External DNS" are wrong. That would be confusing,
> and that term is never properly defined.
>
> I've also expanded DOI several times more often than required, and the RPC
> will freak about that, but I think it's worthwhile repeating what it means
> a
> few times since the term is so awkward.
>
> There are probably some typos and some repeated words, but I hope that the
> text is better.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Fri, Dec 2, 2022 at 9:50 AM Michael Richardson wrote: > > Daniel Migault wrote: > > In my opinion the Synchronization Channel is initiated by the DM and > > follows AXFR over TLS (9103). To my understanding NOTIFY, SOA > exchange > > may be protected by TLS or not. Of course if the TLS session has not > > been established by the DM the NOTIFY cannot be protected. > > Yes. It is initiated by the DM, and it's a TCP/TLS connection from > a random port on the DM to the designated port (853) on the HNA. > So, how does the *HNA* use this connection to send a Notify from the HNA to > the DM, when doesn't initiate to the DM? > That was my reading of 9103, but now I am thinking that if the tcp session is down, protection is probably using port 853 on the DM. In that case, using the control channel or a new TLS session seems to be the same. One advantage is that PSK can be used to the already established control channel. My impression is that using the control channel is one way to do and have some benefits, but that only one way to do and other ways could include 53 or a new TLS session. > > > While I do see the point in re-using the control channel, I do not > > think we should recommend this. Firstly it mixes the following > > channels, so if we find another way to set the DM / HNA configuration > > we will always have to handle the Notify. > > > I also believe that changes > > 9103, and I believe that would be good if we could re-se > implementation > > of 9103 without modifications. It might be good to mention the > Notifies > > may also take the control channel - just leaving this as a potential > > possibility. > > 9103 documents that NOTIFY messages travel over port-53, and are not > protected. > That's fine, since they just cause an SOA query in the other direction, but > in the case of the HNA and DM, the only port that the HNA knows about that > it > can send to is the Control Channel's port. > I see your point. I think that it is worth mentioning that the reason for using the control channel is that it is the only port we know the DM is reachable. I have connected all dots -thanks for the explanation - and I am fine with your recommendation. I agree with your two points. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Michael,
Just sharing my thoughts,
Yours,
Daniel
On Thu, Dec 1, 2022 at 8:56 PM Michael Richardson wrote:
> In re-editing I found that the section 7.1 is a bit vague about where the
> Notifies go. Ray Hunter please comment.
>
>
> https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-22.html#name-securing-the-synchronizatio
>
> Since the Synchronization Channel is from the DM->HNA, it can't be issued
> there. It must therefore be the case that the zone update Notifies go into
> the Control Channel.
>
> In my opinion the Synchronization Channel is initiated by the DM and
follows AXFR over TLS (9103). To my understanding NOTIFY, SOA exchange may
be protected by TLS or not. Of course if the TLS session has not been
established by the DM the NOTIFY cannot be protected.
But the text below doesn't say this, and is pretty wishy-washy about about
> whether TLS is used or not. It could very well be the case that Notifies
> are
> *not* protected at all.
> Since the Control Channel is not a regular DNS channel, and likely is port
> 853 DoT, it seems unlikely that a Notify to port 53 would go the right
> place.
> OTH, bringing up DoT just to send the Notify might be considered by some
> to be
> overkill. TLS resumption tickets to the rescue is my opinion.
>
> I'm looking for objections to:
>
> 1) Notifies go across the Control Channel (DoT)
>
While I do see the point in re-using the control channel, I do not think we
should recommend this. Firstly it mixes the following channels, so if we
find another way to set the DM / HNA configuration we will always have to
handle the Notify. I also believe that changes 9103, and I believe that
would be good if we could re-se implementation of 9103 without
modifications. It might be good to mention the Notifies may also take the
control channel - just leaving this as a potential possibility.
> 2) They are always sent in TLS.
>
> I am inclined to say that we should rely on 9103 as much as possible and
the price of a non encrypted NOTIFY can be acceptable. If that is not the
case, the control channel may be used - which should be agreed out-of band-
by the two parties.
This means that the text will get moved around a bunch.
>
>
>
> The text as it appears now:
>
>
> ## Securing the Synchronization Channel {#sec-synch-security}
>
> The Synchronization Channel uses standard DNS requests.
>
> First the HNA (primary) notifies the DM (secondary) that the zone must be
> updated and leaves the DM (secondary) to proceed with the update when
> possible/convenient.
>
> More specifically, the HNA sends a NOTIFY message, which is a small packet
> that is less likely to load the secondary.
> Then, the DM sends AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request.
> This request consists in a small packet sent over TCP (Section 4.2
> {{!RFC5936}}), which also mitigates reflection attacks using a forged
> NOTIFY.
>
> The AXFR request from the DM to the HNA MUST be secured with TLS
> {{!RFC8446}}) following DNS Zone Transfer over TLS {{!RFC9103}}.
> While {{!RFC9103}} MAY not consider the protection by TLS of NOTIFY and
> SOA requests, these MAY still be protected by TLS to provide additional
> privacy.
>
> When using TLS, the HNA MAY authenticate inbound connections from the DM
> using standard mechanisms, such as a public certificate with baked-in root
> certificates on the HNA, or via DANE {{?RFC6698}}.
> In addition, to guarantee the DM remains the same across multiple TLS
> session, the HNA and DM MAY implement {{?RFC8672}}.
>
> The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they only
> arrive from the DM Synchronization Channel.
> In this case, the HNA SHOULD regularly check (via a DNS resolution) that
> the address of the DM in the filter is still valid.
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
names is a small thing if homenet puts > all > my devices on the public IPv6 network. Scanning IPv6 is still fairly hard > to > do, even of endusers /64. And putting those IPv6 addresses in DNS makes it > much > much easier to find all these devices and use their exposed services to > compromise the device and/or network that they are in. These > considerations are > completely missing from the Security Considerations Section 12. > > Appendix A: > >This document does not deal with how the HNA is provisioned with a >trusted relationship to the Distribution Manager for the forward >zone. > > But that is core to the protocol ? > > No the core protocol is about outsourcing the zone to the DOI. >Similarly, if the HNA is provided by a registrar, the HNA may be >handed pre-configured to end user. > > How can that be if the user decides on the homenet network name it wants > to use? > > Then it needs to configure the HNA, THe example was provided as an illustration of use cases where such configuration is not performed by the end user. > Appendix C: > > The example zone used is n8d234f.r.example.net. I thought the idea was > for the > user to have a memorable zone it can use, eg sharing with friends. Was I > wrong? > If a user chooses a name it is likely the name will be more friendly. That name was provided as an example of free name provided by the hardware vendor for example. The ISP may provide similar type of names. It is clearly not a name that is nice, but that can also be used as a bootstrapping name that the user may use a nicer name and redirect that one to the ugly name. > > with the "dm_acl": "2001:db8:1234:111:222::/64", set, what happens to > the > zone "n8d234f.r.example.net." when the user got unplugged and replugged > and > lives on a different ip range now ? > > > The dm_acl is related to the DM so the renumbering of the HNA may not affect the parameter. That say, I agree that seom checks of the configuration are likely to be performed and an error may be raised. Note that we provided these parameters as plausible parameters but, it also shows that when not limited to the strict minimum it would be good to design a mechanism these configuration parameters can be provided automatically on a regular basis as to be able to refresh the configuration. > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Wed, Nov 23, 2022 at 9:12 AM Paul Wouters wrote: > On Nov 22, 2022, at 16:15, Daniel Migault wrote: > > > > > > Hi Paul, > > > > I am doing the follow-up and would like to check if there are any > specific questions regarding the current version of the document. > > During IETF-115 I talked to Michael. It helped confirm the parts that I > thought were unspecified. While I do believe that makes the protocol > practically undeployable, as the hard parts have been left out of scope, I > can now reread the document with that understanding. > Make sure you point out what you believe is practically undeployable. > > I do think Experimental is a better classification than Standard Track > though because of this. It is hard to see how two implementations can fully > interact and interoperate. Does anyone know of any implementations ? > Again make sure "this" is clearly specified so it can potentially be addressed/discussed. Until "this" is not clearly stated, it cannot justify the downgrade to Experimental. In our case, our products need a Standard Track. Ray has an implementation not published as open source yet. > > Paul -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi!
No problem. Let's do that next week, that sounds perfectly fine to me.
Yours,
Daniel
On Tue, Nov 22, 2022 at 4:43 PM John Scudder wrote:
> Hi Daniel,
>
> I’m not sure I’ll be able to do this before next week, but it’s at the
> front of my to-do list.
>
> Thanks,
>
> —John
>
> On Nov 22, 2022, at 4:24 PM, Daniel Migault wrote:
>
>
>
> Hi John,
>
> Just let us know what remains to be addressed or clarified. We are
> happy to move that document forward.
>
> Yours,
> Daniel
>
> On Fri, Oct 28, 2022 at 5:38 PM Daniel Migault
> wrote:
>
>>
>>
>> On Fri, Oct 28, 2022 at 4:18 PM John Scudder wrote:
>>
>>> > On Oct 28, 2022, at 2:52 PM, Daniel Migault
>>> wrote:
>>> >
>>> > Let me know if the text below is clearer.
>>>
>>> So much clearer! Thanks!
>>>
>>> > OLD:
>>> > The transport channel (including port number) is the same as the one
>>> used between theHN
>>> > A and the DM for the Control Channel.
>>> >
>>> > NEW:
>>> > The DNS exchanges performed by the DM to synchronize the zone is using
>>> the same destination port and same transport protocol as for the Control
>>> Channel.
>>> > This document only specifies DNS over TLS as the transport protocol.
>>> > If the Control Channel between the HNA and the DM uses DNS over TLS
>>> {{!RFC7858}} over port XX (XX being 853 by default), the Synchronization
>>> Channel between the DM and the HNA will use DNS Zone transfer over TLS
>>> {{!9103}} using port XX. Note that the source port may be different for
>>> both channels (see {{sec-synch}} for more details ).
>>> >
>>> > HNADM
>>> > - -
>>> > port control channel> port MM
>>> > port MM <-synchronization channel- port
>>> >
>>> > where arrow directions indicate who the initiator of the connection
>>> is, port denotes an ephemeral port, and port MM denotes a well-known
>>> port. As written, the most literal interpretation would be:
>>> >
>>> > HNADM
>>> > - -
>>> > port control channel> port MM
>>> > port <-synchronization channel--- port MM
>>> >
>>> > which regrettably doesn’t make sense. Without a better understanding
>>> of your intended meaning, I’m afraid I can’t propose wording.
>>> >
>>> > [… snip …]
>>> >
>>> > > ### Section 4.5.3
>>> > >
>>> > > ```
>>> > >Similarly to Section 4.5.2, DNS errors are used and an error
>>> > >indicates the DM is not configured as a secondary.
>>> > > ```
>>> > >
>>> > > Related to the previous comment -- is this true regardless of what
>>> error code
>>> > > is returned, for example would a FORMERR mean that the DM is not
>>> configured as
>>> > > a secondary?
>>> > >
>>> > > Even given that any error implies that the operation failed, what if
>>> the DM had
>>> > > already been previously configured as secondary, and the operation
>>> were merely
>>> > > updating some parameter? Would the previous configuration be voided,
>>> as the
>>> > > text currently implies? Or would the DM remain configured as
>>> secondary, using
>>> > > the previous configuration?
>>> > >
>>> > > We used DNS errors to imply that the standard DNS behavior is
>>> expected. When teh update fails, the data remains in its previous step.
>>> >
>>> > Doesn’t that mean the text as written isn’t accurate, though? A
>>> possible rewrite could be “… an error indicates that the requested update
>>> to the DM will not take effect."
>>> >
>>> > Just to avoid any confusion. In this case, DNS Updates are just ways
>>> to carry some configuration parameters from the HNA to the DM. In other
>>> words, they would not result in any update of a zone. - updates of the zone
>>> are handled by the synchronization channel. As result, an error of the DNS
>>> update indicates the secondary is not configured.
>>>
>>> I thought we had previously agre
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi John,
Just let us know what remains to be addressed or clarified. We are happy to
move that document forward.
Yours,
Daniel
On Fri, Oct 28, 2022 at 5:38 PM Daniel Migault wrote:
>
>
> On Fri, Oct 28, 2022 at 4:18 PM John Scudder wrote:
>
>> > On Oct 28, 2022, at 2:52 PM, Daniel Migault
>> wrote:
>> >
>> > Let me know if the text below is clearer.
>>
>> So much clearer! Thanks!
>>
>> > OLD:
>> > The transport channel (including port number) is the same as the one
>> used between theHN
>> > A and the DM for the Control Channel.
>> >
>> > NEW:
>> > The DNS exchanges performed by the DM to synchronize the zone is using
>> the same destination port and same transport protocol as for the Control
>> Channel.
>> > This document only specifies DNS over TLS as the transport protocol.
>> > If the Control Channel between the HNA and the DM uses DNS over TLS
>> {{!RFC7858}} over port XX (XX being 853 by default), the Synchronization
>> Channel between the DM and the HNA will use DNS Zone transfer over TLS
>> {{!9103}} using port XX. Note that the source port may be different for
>> both channels (see {{sec-synch}} for more details ).
>> >
>> > HNADM
>> > - -
>> > port control channel> port MM
>> > port MM <-synchronization channel- port
>> >
>> > where arrow directions indicate who the initiator of the connection is,
>> port denotes an ephemeral port, and port MM denotes a well-known port.
>> As written, the most literal interpretation would be:
>> >
>> > HNADM
>> > - -
>> > port control channel> port MM
>> > port <-synchronization channel--- port MM
>> >
>> > which regrettably doesn’t make sense. Without a better understanding of
>> your intended meaning, I’m afraid I can’t propose wording.
>> >
>> > [… snip …]
>> >
>> > > ### Section 4.5.3
>> > >
>> > > ```
>> > >Similarly to Section 4.5.2, DNS errors are used and an error
>> > >indicates the DM is not configured as a secondary.
>> > > ```
>> > >
>> > > Related to the previous comment -- is this true regardless of what
>> error code
>> > > is returned, for example would a FORMERR mean that the DM is not
>> configured as
>> > > a secondary?
>> > >
>> > > Even given that any error implies that the operation failed, what if
>> the DM had
>> > > already been previously configured as secondary, and the operation
>> were merely
>> > > updating some parameter? Would the previous configuration be voided,
>> as the
>> > > text currently implies? Or would the DM remain configured as
>> secondary, using
>> > > the previous configuration?
>> > >
>> > > We used DNS errors to imply that the standard DNS behavior is
>> expected. When teh update fails, the data remains in its previous step.
>> >
>> > Doesn’t that mean the text as written isn’t accurate, though? A
>> possible rewrite could be “… an error indicates that the requested update
>> to the DM will not take effect."
>> >
>> > Just to avoid any confusion. In this case, DNS Updates are just ways to
>> carry some configuration parameters from the HNA to the DM. In other words,
>> they would not result in any update of a zone. - updates of the zone are
>> handled by the synchronization channel. As result, an error of the DNS
>> update indicates the secondary is not configured.
>>
>> I thought we had previously agreed ("the data remains in its previous
>> step") that if the DM had been previously successfully configured as
>> secondary, after the failure the DM would still be a secondary.
>>
>> > Updates in the zone can only happen when the secondary is configured.
>> >
>> > I think your proposal is correct that an error to the DNS update
>> indicates requested update to the DM will not take effect, but I think it
>> introduces some ambiguity that an effective update of the Public homenet
>> zone was expected with this request. If we agree on this, I would prefer
>> not to introduce such ambiguity and prefer to stick to the consequences
>> which is that the DM is not configured . I am thou
Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Warren, I am doing the follow-up and would like to know if there are any technical concerns in the current version. Feel free to let us which they are so we can address them shortly. Yours, Daniel On Fri, Oct 28, 2022 at 4:49 PM Daniel Migault wrote: > > Hi Warren, > > This is a follow-up of the comments we could get from the notes of teh PDF > you shared. As far as I can tell we are addressing all notes we have found. > These notes did not result in any text being updated. > > In your DISCUSS you mention "The specification is impossible to > implement..." The protocol has technical flaws...", "It is unlikely that > multiple implementations...". However, so far we have not been able to > identify 1) why do you believe the protocol is impossible to implement - 2) > what these flaws are. Please point these aspects to us. > > As we have implemented multiple comments received so far the description > might be clearer. We would appreciate you focusing on what you believe is a > flaw or what makes the protocol impossible to be implemented as opposed to > nits and grammar. The current version is available here on github. We do > update it as we receive comments, so do not hesitate to provide comments > without performing a full review. > > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/blob/master/draft-ietf-homenet-front-end-naming-delegation.txt > > Yours, > Daniel > > > > > Upon receiving the response, the HNA MUST validate format and > properties of the SOA, NS and A or RRsets. If an error occurs, > the HNA MUST stop proceeding and MUST log an error. Otherwise, the > HNA builds the Public Homenet Zone by setting the MNAME value of the > SOA as indicated by the SOA provided by the AXFR response. The HNA > SHOULD set the value of NAME, REFRESH, RETRY, EXPIRE and MINIMUM of > the SOA to those provided by the AXFR response. > > Warren: Only those? > > mglt: It is unclear to me what that note refers to. If the comment refers > to the SOA, the only fields we are missing are the RNAME and SERIAL. For > the RNAME, we believe that both the HNA and the DOI may set it, the SERIAL > is to be set by the primary. Is there any text you would like to see for > the RNAME ? > > If the comment is associated with the number of RR we believe that these > RRsets are sufficient to carry the necessary information from the DM to the > HNA to configure the Public Homenet Zone in accordance with what is > publishable by the DOI. If any additional information is needed more RRsets > can be used. > > 4.5.2. Providing information for the DNSSEC chain of trust > To provide the DS RRset to initialize the DNSSEC chain of trust the > HNA MAY send a DNS update [RFC2136] message. > > Warren: > If you have all of this, why are you not just using dns updates normally? > > Authentication?! > > mglt: > I suppose the question is why do we set a primary/secondary as opposed to > using DNS Update. The reason is that we are looking at synchronizing zones > and not working on the level of the individual RRsets. Check Ted's response > for reasons to do so. On the DOI perspective, zone synchronization is > performed at the initiative of the DOI, not the end user, which is a better > design against DDoS. > The discussion can be endless and we are not claiming there are no > possible ways to do it with DNS update. We believe zone synchronization is > more appropriate. > > I do not understand what is the comment about authentication, in our case > we could have used it over TLS for example, or TSIG. We also believe TSL is > more appropriate for privacy reasons. > > > Upon receiving the DNS update request, the DM reads the DS RRset in > the Update section. The DM checks ZNAME corresponds to the parent > zone. The DM SHOULD ignore non-empty the Pre-requisite and > Additional Data section. The DM MAY update the TTL value before > updating the DS RRset in the parent zone. Upon a successful update, > the DM should return a NOERROR response as a commitment to update the > parent zone with the provided DS. An error indicates the MD does not > update the DS, and other method should be used by the HNA. > > Warren: > Like what? How does the user know when a rollover happens? > Appropriate? > > As the user is generating the zone. he knows when he is changing the key. > > I cannot tell what Appropriate means in that context. > > > > > > > On Thu, Oct 20, 2022 at 1:43 AM Daniel Migault > wrote: > >> Hi Warren, >> >> Thanks for the review. I went through all comments and addressed them >> here: >> >> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/451133ab826df6bae6d10d3b6042d9
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Paul, I am doing the follow-up and would like to check if there are any specific questions regarding the current version of the document. Yours, Daniel On Mon, Oct 31, 2022 at 10:34 PM Daniel Migault wrote: > Ray implemented the front end naming architecture but I am unaware if > there is any link to an open source implementation. > > I am unable to figure out what you believe is out of scope of the document > (or not), as gaps you believe are under specified. If stated explicitly we > will be able to address those or clarify them. I propose you start > mentioning what you believe are unspecified gaps that could lead to > interoperability issues. As you mentioned earlier you can start with one. > > Note that the current version 22 has been published today with all > addressable concerns: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:56 PM Paul Wouters > wrote: > >> On Oct 31, 2022, at 09:39, Daniel Migault wrote: >> >> >> >> Hi Paul, >> >> This is just a follow-up regarding the remaining concerns that need to be >> solved. Does Michael's response address your questions, if not please >> let us know what remains unclear as well as what other clarification is >> needed. >> >> >> It does clarify some of the process, but sadly adds more to the “this >> part is out of scope of this document”, still resulting in unspecified gaps >> in the solution that this document claims to facilitate. >> >> Has anyone implemented this? Maybe a reference opensource one that could >> help my understanding ? >> >> Paul >> >> >> >> >> Yours, >> Daniel >> >> On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson >> wrote: >> >>> >>> Paul Wouters wrote: >>> > These two sentences I think show the core of my lack of >>> understanding. >>> > Let's say I want to put my sauna on my public home net so I can >>> access it >>> > remotely and turn it on before I get home? >>> >>> > Is this envisioned as a goal of the homenet architecture? >>> >>> You say, "homenet architecture", but our document is not the homenet >>> architecture. >>> It's about the homenet naming architecture, and I'm sorry to be >>> pedantic, but >>> the subtle difference includes a whole bunch of possible sins. >>> I have no idea if your sauna can be remotely controlled, or if if your >>> home >>> router will let the traffic through, and it's not the job of this >>> document to >>> standardize either of those things. >>> >>> So, let's take a simpler version of this: >>> >>> Your sauna can connect to an IRC server to tell you about it's >>> temperature, >>> and the number of people currently in it. But, IRC being what it is, it >>> would like to have a valid reverse name, and for that reverse name to >>> match >>> the forward name before it will let you in. >>> >>> > Is it envisioned that this would be done by talking to the device, >>> using a >>> > name served by the "homenet public zone" ? >>> >>> No, your sauna would not be involved at all. >>> >>> > If so, can I determine the name of this zone, or is it only CPE >>> > auto-generated? >>> >>> You would inform your CPE to please publish the IP address of your sauna >>> under a name that you decide. How your CPE does this is not the concern >>> of >>> the specification, but here are some ideas: >>> * CPE identifies your sauna by MAC address, publishes the IPv6 that >>> the NCE >>> says is associated with it. >>> * CPE identifies your sauna by mDNS name >>> * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, >>> and >>> it publishes that >>> * something else >>> >>> > If I can determine the name, I am confused how this all would hook >>> into >>> > existing DNS infrastructure. It could be in my personal subdomain, >>> a custom >>> > generic domain in .com ? >>> >>> You could have obtained a domain, yes, perhaps in .com, for your CPE. >>> "paulshome.nohat.ca" if you desire. >>> >>> We suggest, non-normatively in Appendix C of a JSON blob that could be >>> copy >>> and
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
Hi Roman, I am just following up and I am wondering if there is anything that we missed to lift your DISCUSS ? Yours, Daniel On Thu, Nov 3, 2022 at 9:48 PM Daniel Migault wrote: > Thanks Roman for the follow-up. For some reason I could not find the > response. > > So let me start with the initial question that was. Why do we have: The > Homenet Resolver SHOULD request the Homenet Authoritative Server... as > opposed as The Homenet Resolver MUST request the Homenet Authoritative > Server. > > To start with, the core of the document is how the Homenet Authority (HNA) > and the Distributed Manager (DM) interact between each other, that is the > negotiation that leads to the HNA being configured as a primary DNS server > and the DM acting as secondary server. This ends up publishing the Public > zone. > > The purpose of the architecture section is to show where this relation > happens within the homenet. For that purpose we did represent a number of > naming entities that can be present in the homenet. The architecture in > itself is not normative and we do not mandate that any home network (MUST) > have all these entities. Typically with one CPE all these entities are > likely to be combined and not all of them might be present. > > You are absolutely correct that if we do want to provide some resilience > against the ISP disruption, the Homenet Resolver MUST request the Homenet > Authoritative Server. The question is how realistically this can be > deployed, and we need to balance a minimal implementation that ensures some > "acceptable" resilience versus a mechanism that ensures a complete > resilience against the ISP network interruption. > Suppose that in the worst case, there is no Homenet Authoritative Server, > and the resolver gets all its responses from querying the Public Homenet > Authoritative Server, only the first request (every TTL) goes outside. > Others are handled by the cache. Some may argue this achieves some sort of > resilience which might be enough especially as nothing needs to be done. > Some other implementations may be doing a bit more but may not be willing > for example to run a server for that only purpose and prefer to simply > cache a zone (the one of the HNA) in the resolver, perform an axfr to the > Public Homenet Authoritative Server and cache it. This could assume some > resilience that some vendors might consider acceptable. In this case there > will be no Homenet Authoritative Server, which makes it hard to require the > Homenet Resolver to request that entity. > In these latest cases, we do not have any queries leaking outside the home > network but we do not achieve a complete resilience toward ISP > disruption. > In fact, DNSSEC makes being completely resilient really challenging as > most DNSSEC clients have the root KSK as a Trust Anchor, and the chain of > trust for the root zone to the homenet zone (including the Delegated > Signature) need to be taken from outside the homenet. The other way around > is to have clients being configured with a homenet TA, but we are not there > yet. This is the case with the Homenet Authoritative Server being present > also. > > This is my understanding of what Michael pointed out as trade-offs. Now as > mentioned earlier the document provides an architecture overview to > position the functionalities between each other as to mandate it to be > implemented. This is why we do not go beyond the recommendation level > SHOULD. We also believe that anything beyond the scope of the protocol > between HNA and DM is out of scope of the document. > > Now going back to the question pre-homenet and homenet. With pre-homenet I > understand the use of DynDNS. > I am not mentioning the protocol aspect where there are multiple ways to > handle it where HTTP is a very common way to handle this [1][3] and the > recommended way by DynDNS to handle this [3]. > It is correct that - at least dyn - makes it possible to update via DNS > update and TSIG [4] (integrity but no confidentiality). TSIG is also using > a pre-shared key which comes with its own distribution issues. > Let's assume that DNS update + TSIG is used. updates are performed on a > per record level only the IP address of the device is updated. > While all devices could work independently as so being configured > individually (with the PSK), we can also consider a device like a CPE that > will update on behalf of most devices their respective IP address. > > With homenet, the granularity is the zone (the Homenet zone) not a > specific RRset ( IP address). Centralization is performed by design > which enables DNSSEC signing. The centralization together with the use of > standard DNS functionalities also eases the publication of the zone insi
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
integrate this mechanism with homenet would be to make it update the zone hosted by the HNA which then syncs it with the DM. Such an intermediary step ensures some resilience as opposed to the case where only the public server is updated. Back to your comments: Pre-Homenet DNS resolution for clients on the home network to access a home network server: -- … visible outside of the home network: NO DynDNS is updating the DOI directly so the changes seem to be visible from outside of the home network. -- … usable if CPE-to-carrier link goes down: YES In this case, if the link goes down the DNS resolution can be performed as long as there is an entity in the network that makes such a resolution possible. This is almost impossible if you only have independent devices updating their own IP address. On the other hand if one centralized managing the update, this is likely to be resilient to ISP disruption. Homenet DNS resolution for clients on the home network to access a home network server: -- … visible outside of the home network: YES -- … usable if CPE-to-carrier link goes down: NO With Homenet the name will be visible outside of the network as well. Similarly, Homenet makes it very likely to be relient to ISP disruption as homenet IS BY DESIGN centralized. One point maybe is that in both cases DynDNS or Homenet is published names that are intended to be published - only. I apologize for being so long, and I hope that clarified your concerns. Yours, Daniel [1] https://en.wikipedia.org/wiki/Dynamic_DNS [2]https://help.dyn.com/remote-access-api/perform-update/ [3]]https://help.dyn.com/update-client-faqs/ [4] https://help.dyn.com/tsig/ On Thu, Nov 3, 2022 at 1:35 PM Roman Danyliw wrote: > Hi! > > > > Please see an response to below to Michael’s email: > > > > *From:* Daniel Migault > *Sent:* Monday, October 31, 2022 9:02 AM > *To:* Michael Richardson > *Cc:* Roman Danyliw ; The IESG ; > draft-ietf-homenet-front-end-naming-delegat...@ietf.org; > homenet-cha...@ietf.org; homenet@ietf.org; stephen.farr...@cs.tcd.ie > *Subject:* Re: [homenet] Roman Danyliw's Discuss on > draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and > COMMENT) > > > > Hi Roman, > > > > This is just a follow-up. Currently we believe we have addressed your > concerns, but we would like to double check if there are any other > concerns/questions you would like us to address. > > > > Yours, > Daniel > > > > On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault > wrote: > > > > > > On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson > wrote: > > > Roman Danyliw via Datatracker wrote: > > [per -18] I’m not sure if this my misreading of the behavior of > > internal clients. To clarify, the (internal) Homenet DNSSEC Resolver > > will “... resolves the DS record on the Global DNS and the name > > associated to the Public Homenet Zone (myhome.example) on the Public > > Authoritative Servers.”? Why would the internal resolver serving a > > request for an internal client for an internal service go to the > Global > > DNS if the information if it could come from the internal Homenet > Zone > > it is already configured with? > > Because it needs the glue records to prove it is authoritative. > > There are cases - quite common - where the Homenet Authoritative server > does not exist. In such cases, the Homenet Resolvers just caches what is > published outside. > > > > As an operational consideration, why go > > outside of the network if you don’t need to? As a privacy > > consideration, why leak the request to an outside entity if the > network > > already has the information. > > We do mention in the version 21 that going outside has some privacy > implications. Note also that the resolver only goes outside once the TTL > has exceeded so that is not every time a DNS request is received. > > > > > [per -20] Thanks for the revised text: On the other hand, to provide > > resilience to the Public Homenet Zone in case of WAN connectivity > > disruption, the Homenet DNSSEC Resolver SHOULD be able to perform the > > resolution on the Homenet Authoritative Servers. > > > -- Is there a reason this can’t be a MUST? > > If the resolver and cache have been offline for long enough, any cached > chain > of DS/NS/DNSKEY records from . down to the myhome.example might have > expired. > (Consider a DNSSEC resolver on a host behind the gateway) > > What to do in this situation has many answers with different tradeoffs. > > Yes. answers and tradeoffs are indeed quite numerous and we can hardly go > beyond such a recommen
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Tue, Nov 1, 2022 at 6:11 AM Juliusz Chroboczek wrote: > Removing the IESG from CC. > > > I propose you start mentioning what you believe are unspecified gaps > > that could lead to interoperability issues. > > With all due respect, Daniel, I'm a little surprised by this development. > In this WG, we did spend a lot of effort ensuring that all of our > specifications have at least two independent implementations. This > allowed us to claim with assurance that our protocols are not only > implementable, but actually described clearly enough to allow independent > reimplementation. (Which didn't prevent a small minority of IESG members > from blocking progress for months, but that's a different story, and one > that's well documented in RFC 3774.) > > From your mail, it would appear that the burden of proof has changed > sides: it is apparently no longer the people who propose a protocol who > need to prove that it is implementable, but the people who have tried but > failed to understand how to implement a draft who need to prove that the > draft is incoplete. > > The purpose of a discussion is to try to understand what the other means. This is what we are trying to do. > When did that happen? > > -- Juliusz > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Ray implemented the front end naming architecture but I am unaware if there is any link to an open source implementation. I am unable to figure out what you believe is out of scope of the document (or not), as gaps you believe are under specified. If stated explicitly we will be able to address those or clarify them. I propose you start mentioning what you believe are unspecified gaps that could lead to interoperability issues. As you mentioned earlier you can start with one. Note that the current version 22 has been published today with all addressable concerns: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ Yours, Daniel On Mon, Oct 31, 2022 at 5:56 PM Paul Wouters wrote: > On Oct 31, 2022, at 09:39, Daniel Migault wrote: > > > > Hi Paul, > > This is just a follow-up regarding the remaining concerns that need to be > solved. Does Michael's response address your questions, if not please > let us know what remains unclear as well as what other clarification is > needed. > > > It does clarify some of the process, but sadly adds more to the “this part > is out of scope of this document”, still resulting in unspecified gaps in > the solution that this document claims to facilitate. > > Has anyone implemented this? Maybe a reference opensource one that could > help my understanding ? > > Paul > > > > > Yours, > Daniel > > On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson > wrote: > >> >> Paul Wouters wrote: >> > These two sentences I think show the core of my lack of >> understanding. >> > Let's say I want to put my sauna on my public home net so I can >> access it >> > remotely and turn it on before I get home? >> >> > Is this envisioned as a goal of the homenet architecture? >> >> You say, "homenet architecture", but our document is not the homenet >> architecture. >> It's about the homenet naming architecture, and I'm sorry to be pedantic, >> but >> the subtle difference includes a whole bunch of possible sins. >> I have no idea if your sauna can be remotely controlled, or if if your >> home >> router will let the traffic through, and it's not the job of this >> document to >> standardize either of those things. >> >> So, let's take a simpler version of this: >> >> Your sauna can connect to an IRC server to tell you about it's >> temperature, >> and the number of people currently in it. But, IRC being what it is, it >> would like to have a valid reverse name, and for that reverse name to >> match >> the forward name before it will let you in. >> >> > Is it envisioned that this would be done by talking to the device, >> using a >> > name served by the "homenet public zone" ? >> >> No, your sauna would not be involved at all. >> >> > If so, can I determine the name of this zone, or is it only CPE >> > auto-generated? >> >> You would inform your CPE to please publish the IP address of your sauna >> under a name that you decide. How your CPE does this is not the concern >> of >> the specification, but here are some ideas: >> * CPE identifies your sauna by MAC address, publishes the IPv6 that the >> NCE >> says is associated with it. >> * CPE identifies your sauna by mDNS name >> * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, >> and >> it publishes that >> * something else >> >> > If I can determine the name, I am confused how this all would hook >> into >> > existing DNS infrastructure. It could be in my personal subdomain, >> a custom >> > generic domain in .com ? >> >> You could have obtained a domain, yes, perhaps in .com, for your CPE. >> "paulshome.nohat.ca" if you desire. >> >> We suggest, non-normatively in Appendix C of a JSON blob that could be >> copy >> and pasted from your domain provider/DOI to your CPE in order to configure >> everything. We imagine flows where this actually all happens via >> browser/OAUTH2 >> flow, but that's not a normative part of the specification. >> >> Your CPE could have been provisioned with a name (probably ugly) by the >> maker >> of the CPE device. I have been involved in two proofs of concept for >> this. >> The ISP that provided the CPE to you, or some other party that sold you >> service. >> >> > Then we get to my sauna device. It calls itself "tylo". How does >> this end >> > up as a FQDN in t
Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-front-end-naming-delegation-19: (with COMMENT)
Hi, We just published today the latest version today, so you can rely on the one published in the datatracker. Yours, Daniel On Mon, Oct 31, 2022 at 9:46 AM Daniel Migault wrote: > Hi Lars, > > I am just doing a follow-up regarding the comment "This simply isn't > implementable as described.". We would like to know if the current version > is addressing that comment or if there is anything else that we need to > clarify. > Note that the document has undergone quite a lot of clarifications, and we > expect to publish a new version as soon as the datatracker re-open. It's > probably worth waiting for that new version (unless you read the one from > github). > > Yours, > Daniel > > On Thu, Oct 20, 2022 at 9:22 AM Daniel Migault > wrote: > >> Hi Lars, >> >> I have removed the section related to dynamic update which is a non >> technical section that everyone discusses. Such discussions had been >> endless and unhelpful in the homenet wg. We thought this section would >> close some of these discussions, but it seems it reopens others. We do not >> want to discuss speculation regarding one or the other protocol. >> >> We are happy to understand why you think the protocol cannot be >> implemented, but currently we do not see anything that supports this. >> >> Yours, >> Daniel >> >> >> >> On Thu, Oct 20, 2022 at 8:10 AM Lars Eggert via Datatracker < >> nore...@ietf.org> wrote: >> >>> Lars Eggert has entered the following ballot position for >>> draft-ietf-homenet-front-end-naming-delegation-19: Abstain >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ >>> >>> >>> >>> -- >>> COMMENT: >>> -- >>> >>> I agree with the Discusses and Comments on this document - this simply >>> isn't >>> implementable as described. >>> >>> My main reason for abstaining is something else though. This document >>> has been >>> worked on for almost ten years. While in the beginning, we might have >>> expected >>> or at least hoped that a solution in the shape that this document tries >>> to >>> describe would see adoption, it's become very clear that dynamic DNS >>> services >>> as described in Section 4 have won out here. These services are far from >>> perfect, but at least some of the limitations in Section 4 have been >>> addressed, >>> and others are arguably a feature and not a limitation. >>> >>> >>> >>> ___ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> >> -- >> Daniel Migault >> Ericsson >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-front-end-naming-delegation-19: (with COMMENT)
Hi Lars, I am just doing a follow-up regarding the comment "This simply isn't implementable as described.". We would like to know if the current version is addressing that comment or if there is anything else that we need to clarify. Note that the document has undergone quite a lot of clarifications, and we expect to publish a new version as soon as the datatracker re-open. It's probably worth waiting for that new version (unless you read the one from github). Yours, Daniel On Thu, Oct 20, 2022 at 9:22 AM Daniel Migault wrote: > Hi Lars, > > I have removed the section related to dynamic update which is a non > technical section that everyone discusses. Such discussions had been > endless and unhelpful in the homenet wg. We thought this section would > close some of these discussions, but it seems it reopens others. We do not > want to discuss speculation regarding one or the other protocol. > > We are happy to understand why you think the protocol cannot be > implemented, but currently we do not see anything that supports this. > > Yours, > Daniel > > > > On Thu, Oct 20, 2022 at 8:10 AM Lars Eggert via Datatracker < > nore...@ietf.org> wrote: > >> Lars Eggert has entered the following ballot position for >> draft-ietf-homenet-front-end-naming-delegation-19: Abstain >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> >> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ >> >> >> >> -- >> COMMENT: >> -- >> >> I agree with the Discusses and Comments on this document - this simply >> isn't >> implementable as described. >> >> My main reason for abstaining is something else though. This document has >> been >> worked on for almost ten years. While in the beginning, we might have >> expected >> or at least hoped that a solution in the shape that this document tries to >> describe would see adoption, it's become very clear that dynamic DNS >> services >> as described in Section 4 have won out here. These services are far from >> perfect, but at least some of the limitations in Section 4 have been >> addressed, >> and others are arguably a feature and not a limitation. >> >> >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Paul, This is just a follow-up regarding the remaining concerns that need to be solved. Does Michael's response address your questions, if not please let us know what remains unclear as well as what other clarification is needed. Yours, Daniel On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson wrote: > > Paul Wouters wrote: > > These two sentences I think show the core of my lack of > understanding. > > Let's say I want to put my sauna on my public home net so I can > access it > > remotely and turn it on before I get home? > > > Is this envisioned as a goal of the homenet architecture? > > You say, "homenet architecture", but our document is not the homenet > architecture. > It's about the homenet naming architecture, and I'm sorry to be pedantic, > but > the subtle difference includes a whole bunch of possible sins. > I have no idea if your sauna can be remotely controlled, or if if your home > router will let the traffic through, and it's not the job of this document > to > standardize either of those things. > > So, let's take a simpler version of this: > > Your sauna can connect to an IRC server to tell you about it's temperature, > and the number of people currently in it. But, IRC being what it is, it > would like to have a valid reverse name, and for that reverse name to match > the forward name before it will let you in. > > > Is it envisioned that this would be done by talking to the device, > using a > > name served by the "homenet public zone" ? > > No, your sauna would not be involved at all. > > > If so, can I determine the name of this zone, or is it only CPE > > auto-generated? > > You would inform your CPE to please publish the IP address of your sauna > under a name that you decide. How your CPE does this is not the concern of > the specification, but here are some ideas: > * CPE identifies your sauna by MAC address, publishes the IPv6 that the > NCE > says is associated with it. > * CPE identifies your sauna by mDNS name > * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, > and > it publishes that > * something else > > > If I can determine the name, I am confused how this all would hook > into > > existing DNS infrastructure. It could be in my personal subdomain, a > custom > > generic domain in .com ? > > You could have obtained a domain, yes, perhaps in .com, for your CPE. > "paulshome.nohat.ca" if you desire. > > We suggest, non-normatively in Appendix C of a JSON blob that could be copy > and pasted from your domain provider/DOI to your CPE in order to configure > everything. We imagine flows where this actually all happens via > browser/OAUTH2 > flow, but that's not a normative part of the specification. > > Your CPE could have been provisioned with a name (probably ugly) by the > maker > of the CPE device. I have been involved in two proofs of concept for this. > The ISP that provided the CPE to you, or some other party that sold you > service. > > > Then we get to my sauna device. It calls itself "tylo". How does > this end > > up as a FQDN in the homenet public zone ? How does my home end up > being > > able to query for it? > > How do the queries go when not at home? > > All of this is really in the document. > 1) How your CPE publishes the name tylo is up to the CPE. > > 2) the CPE is authoriative for the homenet public zone > > 3) the CPE tells the Domain Outsourcing Infrastructure (DOI) about the >localtion of the zone, and the DOI does a DoX to transfer it. The DOI >has some resilient infrastructure to publish things. Whether it's >ns1/ns2 on different subnets, or some multi-continent anycast system >depends upon what you pay. > > 4) when you aren't at home, the queries go to the ns1/ns2 that the DNS >has published. > > 5) When you are at home, we expect the CPE to answer authoritatively >itself. A well designed CPE would have cached the DS/NS/DNSKEY that > leads >to it's domain so that it can answer a secure chain even when the > Internet >connection is broken. > > > So I am guessing. The only known method for hostnames publishing > their > > names into a zone I know of is with Dynamic Updates on a local zone. > But > > perhaps what homenet > > envisions is that I give my sauna a static IP and configure some > webgui on > > my CPE to add it to my "zone" ? > > No, and the document explains why this is a non-starter. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
I forgot to put the github link below: https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/769a236615d47d812037bf3b74cddeefb9d5daf2 Yours, Daniel On Mon, Oct 31, 2022 at 9:34 AM Daniel Migault wrote: > Hi Paul, > > We implemented the change and used DNS over mutually TLS (DomTLS) to > represent DoT and XoT. We do believe we have address all your concerns for > this draft and your DISCUSS can be lifted. The other document has its > own DISCUSS and I do not believe there is any need to hold a DISCUSS. Of > course, the DISCUSS being raised does not mean no changes can be made. > > Yours, > Daniel > > On Fri, Oct 28, 2022 at 7:32 PM Daniel Migault > wrote: > >> I am happy to close this issue with DNS over mTLS. >> Yours, >> Daniel >> On Fri, Oct 28, 2022 at 7:19 PM Paul Wouters >> wrote: >> >>> I did see the previous reply and it doesn’t make too much sense to me. >>> >>> You could say “mutually authenticated TLS” or something but I find it a >>> little odd that these two things which are separate are one option. >>> >> >> Perhaps it is better if we resolve the other document DISCUSS first and >>> then see if that helps resolve this DISCUSS. >>> >>> Sent using a virtual keyboard on a phone >>> >>> On Oct 28, 2022, at 17:06, Daniel Migault wrote: >>> >>> >>> I thought I responded to it, but was not able to find the response... >>> until I realized the response is not inline... but in the main part of the >>> email. I am copying the response here - and take that inline text seems >>> much clearer. >>> >>> The reason we mentioned both RFC7858 and RFC9103 is that the >>> communication between the Homenet Naming Authority (HNA) and the >>> Distribution Manager (DM) involves two different channels. The Control >>> Channel that aims at configuring/managing the Synchronization Channel (i.e. >>> the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while >>> the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two >>> channels always go in pairs. As both are using DNS over TLS we use the >>> mnemonic 'DoT' for the Selected Transport. From what you are saying, it >>> might be clearer to just mention 'TLS' for the Selected Transport as DoT >>> might be really tightened to 7858. If you think this is clearer, I am happy >>> to do so as well as with any name that you think is clearer. >>> >>> Yours, >>> Daniel >>> >>> On Fri, Oct 28, 2022 at 4:17 PM Paul Wouters >>> wrote: >>> >>>> Was there a problem with my suggested CURRENT / NEW suggestion ? >>>> >>>> Sent using a virtual keyboard on a phone >>>> >>>> On Oct 28, 2022, at 15:14, Daniel Migault wrote: >>>> >>>> >>>> Hi Paul, >>>> >>>> I am wondering if there are any remaining concerns left for >>>> the draft-ietf-homenet-naming-architecture-dhc-options document and >>>> anything you would like us to address to lift your discuss. >>>> >>>> Yours, >>>> Daniel >>>> >>>> On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault >>>> wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thanks for the follow-up. The reason we mentioned both RFC7858 and >>>>> RFC9103 is that the communication between the Homenet Naming Authority >>>>> (HNA) and the Distribution Manager (DM) involves two different channels. >>>>> The Control Channel that aims at configuring/managing the Synchronization >>>>> Channel (i.e. the primary/secondary). The Control Channel uses DNS over >>>>> TLS >>>>> RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS >>>>> 9103. The two channels always go in pairs. As both are using DNS over TLS >>>>> we use the mnemonic 'DoT' for the Selected Transport. From what you are >>>>> saying, it might be clearer to just mention 'TLS' for the Selected >>>>> Transport as DoT might be really tightened to 7858. If you think this is >>>>> clearer, I am happy to do so as well as with any name that you think is >>>>> clearer. >>>>> >>>>> Yours, >>>>> Daniel >>>>> >>>>> On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters >>>>> wrote: >>>>> >>>>>&g
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
Hi Paul, We implemented the change and used DNS over mutually TLS (DomTLS) to represent DoT and XoT. We do believe we have address all your concerns for this draft and your DISCUSS can be lifted. The other document has its own DISCUSS and I do not believe there is any need to hold a DISCUSS. Of course, the DISCUSS being raised does not mean no changes can be made. Yours, Daniel On Fri, Oct 28, 2022 at 7:32 PM Daniel Migault wrote: > I am happy to close this issue with DNS over mTLS. > Yours, > Daniel > On Fri, Oct 28, 2022 at 7:19 PM Paul Wouters > wrote: > >> I did see the previous reply and it doesn’t make too much sense to me. >> >> You could say “mutually authenticated TLS” or something but I find it a >> little odd that these two things which are separate are one option. >> > > Perhaps it is better if we resolve the other document DISCUSS first and >> then see if that helps resolve this DISCUSS. >> >> Sent using a virtual keyboard on a phone >> >> On Oct 28, 2022, at 17:06, Daniel Migault wrote: >> >> >> I thought I responded to it, but was not able to find the response... >> until I realized the response is not inline... but in the main part of the >> email. I am copying the response here - and take that inline text seems >> much clearer. >> >> The reason we mentioned both RFC7858 and RFC9103 is that the >> communication between the Homenet Naming Authority (HNA) and the >> Distribution Manager (DM) involves two different channels. The Control >> Channel that aims at configuring/managing the Synchronization Channel (i.e. >> the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while >> the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two >> channels always go in pairs. As both are using DNS over TLS we use the >> mnemonic 'DoT' for the Selected Transport. From what you are saying, it >> might be clearer to just mention 'TLS' for the Selected Transport as DoT >> might be really tightened to 7858. If you think this is clearer, I am happy >> to do so as well as with any name that you think is clearer. >> >> Yours, >> Daniel >> >> On Fri, Oct 28, 2022 at 4:17 PM Paul Wouters >> wrote: >> >>> Was there a problem with my suggested CURRENT / NEW suggestion ? >>> >>> Sent using a virtual keyboard on a phone >>> >>> On Oct 28, 2022, at 15:14, Daniel Migault wrote: >>> >>> >>> Hi Paul, >>> >>> I am wondering if there are any remaining concerns left for >>> the draft-ietf-homenet-naming-architecture-dhc-options document and >>> anything you would like us to address to lift your discuss. >>> >>> Yours, >>> Daniel >>> >>> On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault >>> wrote: >>> >>>> Hi Paul, >>>> >>>> Thanks for the follow-up. The reason we mentioned both RFC7858 and >>>> RFC9103 is that the communication between the Homenet Naming Authority >>>> (HNA) and the Distribution Manager (DM) involves two different channels. >>>> The Control Channel that aims at configuring/managing the Synchronization >>>> Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS >>>> RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS >>>> 9103. The two channels always go in pairs. As both are using DNS over TLS >>>> we use the mnemonic 'DoT' for the Selected Transport. From what you are >>>> saying, it might be clearer to just mention 'TLS' for the Selected >>>> Transport as DoT might be really tightened to 7858. If you think this is >>>> clearer, I am happy to do so as well as with any name that you think is >>>> clearer. >>>> >>>> Yours, >>>> Daniel >>>> >>>> On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault >>>>> wrote: >>>>> >>>>>> While TLS gives you privacy, >>>>>> >>>>>>> the DNS Update cannot be done with only TLS (as far as I understand >>>>>>>>> it). >>>>>>>> >>>>>>>> please develop, but just in case, we do not use dns update to >>>>>>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT. >>>>>>>> >>>>>>> >>>&g
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
Hi Roman, This is just a follow-up. Currently we believe we have addressed your concerns, but we would like to double check if there are any other concerns/questions you would like us to address. Yours, Daniel On Thu, Oct 27, 2022 at 3:43 PM Daniel Migault wrote: > > > On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson > wrote: > >> >> Roman Danyliw via Datatracker wrote: >> > [per -18] I’m not sure if this my misreading of the behavior of >> > internal clients. To clarify, the (internal) Homenet DNSSEC >> Resolver >> > will “... resolves the DS record on the Global DNS and the name >> > associated to the Public Homenet Zone (myhome.example) on the Public >> > Authoritative Servers.”? Why would the internal resolver serving a >> > request for an internal client for an internal service go to the >> Global >> > DNS if the information if it could come from the internal Homenet >> Zone >> > it is already configured with? >> >> Because it needs the glue records to prove it is authoritative. >> > There are cases - quite common - where the Homenet Authoritative server > does not exist. In such cases, the Homenet Resolvers just caches what is > published outside. > >> >> > As an operational consideration, why go >> > outside of the network if you don’t need to? As a privacy >> > consideration, why leak the request to an outside entity if the >> network >> > already has the information. >> >> We do mention in the version 21 that going outside has some privacy > implications. Note also that the resolver only goes outside once the TTL > has exceeded so that is not every time a DNS request is received. > > > [per -20] Thanks for the revised text: On the other hand, to provide >> > resilience to the Public Homenet Zone in case of WAN connectivity >> > disruption, the Homenet DNSSEC Resolver SHOULD be able to perform >> the >> > resolution on the Homenet Authoritative Servers. >> >> > -- Is there a reason this can’t be a MUST? >> >> If the resolver and cache have been offline for long enough, any cached >> chain >> of DS/NS/DNSKEY records from . down to the myhome.example might have >> expired. >> (Consider a DNSSEC resolver on a host behind the gateway) >> >> What to do in this situation has many answers with different tradeoffs. >> >> Yes. answers and tradeoffs are indeed quite numerous and we can hardly go > beyond such a recommendation. Consider that the homenet an authoritative > server may not exist or the Homenet Naming Authority may play multiple > roles. Also keep in mind that our document is mostly focused on the Homenet > Naming Authority and Distributed Manager, not so much on the naming > architecture of the home network. As a result, strong recommendations > regarding the resolver may be a bit out of scope of the document. > >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
I am happy to close this issue with DNS over mTLS. Yours, Daniel On Fri, Oct 28, 2022 at 7:19 PM Paul Wouters wrote: > I did see the previous reply and it doesn’t make too much sense to me. > > You could say “mutually authenticated TLS” or something but I find it a > little odd that these two things which are separate are one option. > Perhaps it is better if we resolve the other document DISCUSS first and > then see if that helps resolve this DISCUSS. > > Sent using a virtual keyboard on a phone > > On Oct 28, 2022, at 17:06, Daniel Migault wrote: > > > I thought I responded to it, but was not able to find the response... > until I realized the response is not inline... but in the main part of the > email. I am copying the response here - and take that inline text seems > much clearer. > > The reason we mentioned both RFC7858 and RFC9103 is that the communication > between the Homenet Naming Authority (HNA) and the Distribution Manager > (DM) involves two different channels. The Control Channel that aims at > configuring/managing the Synchronization Channel (i.e. the > primary/secondary). The Control Channel uses DNS over TLS RFC7858 while the > Synchronization Channel uses DNS Zone transfer over TLS 9103. The two > channels always go in pairs. As both are using DNS over TLS we use the > mnemonic 'DoT' for the Selected Transport. From what you are saying, it > might be clearer to just mention 'TLS' for the Selected Transport as DoT > might be really tightened to 7858. If you think this is clearer, I am happy > to do so as well as with any name that you think is clearer. > > Yours, > Daniel > > On Fri, Oct 28, 2022 at 4:17 PM Paul Wouters > wrote: > >> Was there a problem with my suggested CURRENT / NEW suggestion ? >> >> Sent using a virtual keyboard on a phone >> >> On Oct 28, 2022, at 15:14, Daniel Migault wrote: >> >> >> Hi Paul, >> >> I am wondering if there are any remaining concerns left for >> the draft-ietf-homenet-naming-architecture-dhc-options document and >> anything you would like us to address to lift your discuss. >> >> Yours, >> Daniel >> >> On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault >> wrote: >> >>> Hi Paul, >>> >>> Thanks for the follow-up. The reason we mentioned both RFC7858 and >>> RFC9103 is that the communication between the Homenet Naming Authority >>> (HNA) and the Distribution Manager (DM) involves two different channels. >>> The Control Channel that aims at configuring/managing the Synchronization >>> Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS >>> RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS >>> 9103. The two channels always go in pairs. As both are using DNS over TLS >>> we use the mnemonic 'DoT' for the Selected Transport. From what you are >>> saying, it might be clearer to just mention 'TLS' for the Selected >>> Transport as DoT might be really tightened to 7858. If you think this is >>> clearer, I am happy to do so as well as with any name that you think is >>> clearer. >>> >>> Yours, >>> Daniel >>> >>> On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters >>> wrote: >>> >>>> >>>> >>>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault >>>> wrote: >>>> >>>>> While TLS gives you privacy, >>>>> >>>>>> the DNS Update cannot be done with only TLS (as far as I understand >>>>>>>> it). >>>>>>> >>>>>>> please develop, but just in case, we do not use dns update to >>>>>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT. >>>>>>> >>>>>> >>>> This to me was not clear and a missed reference by me. While you name >>>> RFC9103, the text states: >>>> >>>> DNS over TLS: indicates the support of DNS over TLS as described in >>>>[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 >>>> <https://datatracker.ietf.org/doc/html/rfc9103>]. >>>> >>>> I should have looked more closely at the references, and I would have >>>> realized 9103 is about DNS XFR over TLS. That document indeed explains >>>> that XoT uses mutually authenticated TLS which provides the >>>> authentication for the XFR streams. >>>> >>>> My suggestion: >>>> >>>> Current: >>>> >>>>
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Fri, Oct 28, 2022 at 4:18 PM John Scudder wrote:
> > On Oct 28, 2022, at 2:52 PM, Daniel Migault wrote:
> >
> > Let me know if the text below is clearer.
>
> So much clearer! Thanks!
>
> > OLD:
> > The transport channel (including port number) is the same as the one
> used between theHN
> > A and the DM for the Control Channel.
> >
> > NEW:
> > The DNS exchanges performed by the DM to synchronize the zone is using
> the same destination port and same transport protocol as for the Control
> Channel.
> > This document only specifies DNS over TLS as the transport protocol.
> > If the Control Channel between the HNA and the DM uses DNS over TLS
> {{!RFC7858}} over port XX (XX being 853 by default), the Synchronization
> Channel between the DM and the HNA will use DNS Zone transfer over TLS
> {{!9103}} using port XX. Note that the source port may be different for
> both channels (see {{sec-synch}} for more details ).
> >
> > HNADM
> > - -
> > port control channel> port MM
> > port MM <-synchronization channel- port
> >
> > where arrow directions indicate who the initiator of the connection is,
> port denotes an ephemeral port, and port MM denotes a well-known port.
> As written, the most literal interpretation would be:
> >
> > HNADM
> > - -
> > port control channel> port MM
> > port <-synchronization channel--- port MM
> >
> > which regrettably doesn’t make sense. Without a better understanding of
> your intended meaning, I’m afraid I can’t propose wording.
> >
> > [… snip …]
> >
> > > ### Section 4.5.3
> > >
> > > ```
> > >Similarly to Section 4.5.2, DNS errors are used and an error
> > >indicates the DM is not configured as a secondary.
> > > ```
> > >
> > > Related to the previous comment -- is this true regardless of what
> error code
> > > is returned, for example would a FORMERR mean that the DM is not
> configured as
> > > a secondary?
> > >
> > > Even given that any error implies that the operation failed, what if
> the DM had
> > > already been previously configured as secondary, and the operation
> were merely
> > > updating some parameter? Would the previous configuration be voided,
> as the
> > > text currently implies? Or would the DM remain configured as
> secondary, using
> > > the previous configuration?
> > >
> > > We used DNS errors to imply that the standard DNS behavior is
> expected. When teh update fails, the data remains in its previous step.
> >
> > Doesn’t that mean the text as written isn’t accurate, though? A possible
> rewrite could be “… an error indicates that the requested update to the DM
> will not take effect."
> >
> > Just to avoid any confusion. In this case, DNS Updates are just ways to
> carry some configuration parameters from the HNA to the DM. In other words,
> they would not result in any update of a zone. - updates of the zone are
> handled by the synchronization channel. As result, an error of the DNS
> update indicates the secondary is not configured.
>
> I thought we had previously agreed ("the data remains in its previous
> step") that if the DM had been previously successfully configured as
> secondary, after the failure the DM would still be a secondary.
>
> > Updates in the zone can only happen when the secondary is configured.
> >
> > I think your proposal is correct that an error to the DNS update
> indicates requested update to the DM will not take effect, but I think it
> introduces some ambiguity that an effective update of the Public homenet
> zone was expected with this request. If we agree on this, I would prefer
> not to introduce such ambiguity and prefer to stick to the consequences
> which is that the DM is not configured . I am though happy to consider any
> other wordings
>
> I’m sorry, I can’t figure out how we get from “the data remains in its
> previous step” to “the DM is not configured”. :-( Maybe I’m still missing
> some subtlety, it’s Friday after all. :-/
>
> Thanks,
>
> —John
Let me restart from zero.
The DNS update in the control channel is not used to update any sort of
zone. The control channel is just a channel to agree on some parameters.
The control channel could have been implemented by POSTing/Getting a JSON
file with the sufficient paramet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
I thought I responded to it, but was not able to find the response... until I realized the response is not inline... but in the main part of the email. I am copying the response here - and take that inline text seems much clearer. The reason we mentioned both RFC7858 and RFC9103 is that the communication between the Homenet Naming Authority (HNA) and the Distribution Manager (DM) involves two different channels. The Control Channel that aims at configuring/managing the Synchronization Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two channels always go in pairs. As both are using DNS over TLS we use the mnemonic 'DoT' for the Selected Transport. From what you are saying, it might be clearer to just mention 'TLS' for the Selected Transport as DoT might be really tightened to 7858. If you think this is clearer, I am happy to do so as well as with any name that you think is clearer. Yours, Daniel On Fri, Oct 28, 2022 at 4:17 PM Paul Wouters wrote: > Was there a problem with my suggested CURRENT / NEW suggestion ? > > Sent using a virtual keyboard on a phone > > On Oct 28, 2022, at 15:14, Daniel Migault wrote: > > > Hi Paul, > > I am wondering if there are any remaining concerns left for > the draft-ietf-homenet-naming-architecture-dhc-options document and > anything you would like us to address to lift your discuss. > > Yours, > Daniel > > On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault > wrote: > >> Hi Paul, >> >> Thanks for the follow-up. The reason we mentioned both RFC7858 and >> RFC9103 is that the communication between the Homenet Naming Authority >> (HNA) and the Distribution Manager (DM) involves two different channels. >> The Control Channel that aims at configuring/managing the Synchronization >> Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS >> RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS >> 9103. The two channels always go in pairs. As both are using DNS over TLS >> we use the mnemonic 'DoT' for the Selected Transport. From what you are >> saying, it might be clearer to just mention 'TLS' for the Selected >> Transport as DoT might be really tightened to 7858. If you think this is >> clearer, I am happy to do so as well as with any name that you think is >> clearer. >> >> Yours, >> Daniel >> >> On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters >> wrote: >> >>> >>> >>> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault >>> wrote: >>> >>>> While TLS gives you privacy, >>>> >>>>> the DNS Update cannot be done with only TLS (as far as I understand >>>>>>> it). >>>>>> >>>>>> please develop, but just in case, we do not use dns update to >>>>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT. >>>>>> >>>>> >>> This to me was not clear and a missed reference by me. While you name >>> RFC9103, the text states: >>> >>> DNS over TLS: indicates the support of DNS over TLS as described in >>>[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 >>> <https://datatracker.ietf.org/doc/html/rfc9103>]. >>> >>> I should have looked more closely at the references, and I would have >>> realized 9103 is about DNS XFR over TLS. That document indeed explains >>> that XoT uses mutually authenticated TLS which provides the >>> authentication for the XFR streams. >>> >>> My suggestion: >>> >>> Current: >>> >>> DNS over TLS: indicates the support of DNS over TLS as described in >>>[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 >>> <https://datatracker.ietf.org/doc/html/rfc9103>]. >>> >>> New: >>> >>> DNS Zone Transfer over TLS: indicates the support of DNS Zone Transfer >>> over TLS as described in [RFC9103] >>> >>> >> >>> The reference to RFC7858 is misleading - it only deals with stub to >>> recursive. >>> >>> If you think stub to recursive is in scope, it might be better to use >>> two DHCP options as these two things >>> seem to be very separate protocols (that just both happen to use DNS and >>> TLS) >>> >>> >>> >>> >>>> >>>>> So you are going against the RFC 5936 SHOULD. >>>>> >>>>> I even had to look this up because I didn't know you could do an AXFR >>>>> as a secondary >>>>> from a primary without DNS level authentication. Apparently you can, >>>>> but you SHOULD not. >>>>> >>>>> That is what we do. TLS provides enough security to replace TSIG / >>>> SIG(0). >>>> >>> >>> >>> Reading 9103 made that clear to me now, but the text in the document did >>> not. Perhaps that can be stated more clearly ? >>> >>> Paul >>> >> >> >> -- >> Daniel Migault >> Ericsson >> > > > -- > Daniel Migault > Ericsson > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Warren, This is a follow-up of the comments we could get from the notes of teh PDF you shared. As far as I can tell we are addressing all notes we have found. These notes did not result in any text being updated. In your DISCUSS you mention "The specification is impossible to implement..." The protocol has technical flaws...", "It is unlikely that multiple implementations...". However, so far we have not been able to identify 1) why do you believe the protocol is impossible to implement - 2) what these flaws are. Please point these aspects to us. As we have implemented multiple comments received so far the description might be clearer. We would appreciate you focusing on what you believe is a flaw or what makes the protocol impossible to be implemented as opposed to nits and grammar. The current version is available here on github. We do update it as we receive comments, so do not hesitate to provide comments without performing a full review. https://github.com/ietf-homenet-wg/ietf-homenet-hna/blob/master/draft-ietf-homenet-front-end-naming-delegation.txt Yours, Daniel Upon receiving the response, the HNA MUST validate format and properties of the SOA, NS and A or RRsets. If an error occurs, the HNA MUST stop proceeding and MUST log an error. Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of the SOA as indicated by the SOA provided by the AXFR response. The HNA SHOULD set the value of NAME, REFRESH, RETRY, EXPIRE and MINIMUM of the SOA to those provided by the AXFR response. Warren: Only those? mglt: It is unclear to me what that note refers to. If the comment refers to the SOA, the only fields we are missing are the RNAME and SERIAL. For the RNAME, we believe that both the HNA and the DOI may set it, the SERIAL is to be set by the primary. Is there any text you would like to see for the RNAME ? If the comment is associated with the number of RR we believe that these RRsets are sufficient to carry the necessary information from the DM to the HNA to configure the Public Homenet Zone in accordance with what is publishable by the DOI. If any additional information is needed more RRsets can be used. 4.5.2. Providing information for the DNSSEC chain of trust To provide the DS RRset to initialize the DNSSEC chain of trust the HNA MAY send a DNS update [RFC2136] message. Warren: If you have all of this, why are you not just using dns updates normally? Authentication?! mglt: I suppose the question is why do we set a primary/secondary as opposed to using DNS Update. The reason is that we are looking at synchronizing zones and not working on the level of the individual RRsets. Check Ted's response for reasons to do so. On the DOI perspective, zone synchronization is performed at the initiative of the DOI, not the end user, which is a better design against DDoS. The discussion can be endless and we are not claiming there are no possible ways to do it with DNS update. We believe zone synchronization is more appropriate. I do not understand what is the comment about authentication, in our case we could have used it over TLS for example, or TSIG. We also believe TSL is more appropriate for privacy reasons. Upon receiving the DNS update request, the DM reads the DS RRset in the Update section. The DM checks ZNAME corresponds to the parent zone. The DM SHOULD ignore non-empty the Pre-requisite and Additional Data section. The DM MAY update the TTL value before updating the DS RRset in the parent zone. Upon a successful update, the DM should return a NOERROR response as a commitment to update the parent zone with the provided DS. An error indicates the MD does not update the DS, and other method should be used by the HNA. Warren: Like what? How does the user know when a rollover happens? Appropriate? As the user is generating the zone. he knows when he is changing the key. I cannot tell what Appropriate means in that context. On Thu, Oct 20, 2022 at 1:43 AM Daniel Migault wrote: > Hi Warren, > > Thanks for the review. I went through all comments and addressed them here: > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/451133ab826df6bae6d10d3b6042d970a122e2ee > > Unless I am missing a previous message. None of your comments in this > email concerning the actual protocol. Though the number of comments is > impressive (and thank you for doing it), all concerns raised are mostly > concerns grammars and nits. 28 of of the 50 comments concerns sections that > can easily be removed if that is what you want. > > Given the DISCUSS and given that your comments are not addressing the > protocol sections - we expect you to clarify: > * what is impossible to implement > * what are the technical or clarity issues > * what are the protocol flaws > * why multiple implementations of the specification would interoperate, > usually due to vagueness or incomplete specific
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
Hi Paul, I am wondering if there are any remaining concerns left for the draft-ietf-homenet-naming-architecture-dhc-options document and anything you would like us to address to lift your discuss. Yours, Daniel On Mon, Oct 24, 2022 at 8:49 PM Daniel Migault wrote: > Hi Paul, > > Thanks for the follow-up. The reason we mentioned both RFC7858 and RFC9103 > is that the communication between the Homenet Naming Authority (HNA) and > the Distribution Manager (DM) involves two different channels. The Control > Channel that aims at configuring/managing the Synchronization Channel (i.e. > the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while > the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two > channels always go in pairs. As both are using DNS over TLS we use the > mnemonic 'DoT' for the Selected Transport. From what you are saying, it > might be clearer to just mention 'TLS' for the Selected Transport as DoT > might be really tightened to 7858. If you think this is clearer, I am happy > to do so as well as with any name that you think is clearer. > > Yours, > Daniel > > On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters > wrote: > >> >> >> On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault >> wrote: >> >>> While TLS gives you privacy, >>> >>>> the DNS Update cannot be done with only TLS (as far as I understand >>>>>> it). >>>>> >>>>> please develop, but just in case, we do not use dns update to >>>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT. >>>>> >>>> >> This to me was not clear and a missed reference by me. While you name >> RFC9103, the text states: >> >> DNS over TLS: indicates the support of DNS over TLS as described in >>[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 >> <https://datatracker.ietf.org/doc/html/rfc9103>]. >> >> I should have looked more closely at the references, and I would have >> realized 9103 is about DNS XFR over TLS. That document indeed explains >> that XoT uses mutually authenticated TLS which provides the >> authentication for the XFR streams. >> >> My suggestion: >> >> Current: >> >> DNS over TLS: indicates the support of DNS over TLS as described in >>[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 >> <https://datatracker.ietf.org/doc/html/rfc9103>]. >> >> New: >> >> DNS Zone Transfer over TLS: indicates the support of DNS Zone Transfer >> over TLS as described in [RFC9103] >> >> > >> The reference to RFC7858 is misleading - it only deals with stub to >> recursive. >> >> If you think stub to recursive is in scope, it might be better to use two >> DHCP options as these two things >> seem to be very separate protocols (that just both happen to use DNS and >> TLS) >> >> >> >> >>> >>>> So you are going against the RFC 5936 SHOULD. >>>> >>>> I even had to look this up because I didn't know you could do an AXFR >>>> as a secondary >>>> from a primary without DNS level authentication. Apparently you can, >>>> but you SHOULD not. >>>> >>>> That is what we do. TLS provides enough security to replace TSIG / >>> SIG(0). >>> >> >> >> Reading 9103 made that clear to me now, but the text in the document did >> not. Perhaps that can be stated more clearly ? >> >> Paul >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi John, Thanks for the follow-up - which is greatly appreciated. Please find my comment inline. The current changes can be seen on the commit below: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/72988ac88aafeda3d0a3417af048cf7553f348ba We are happy to address the changes as they are being discussed and will publish a new version as soon as the publication is open. Yours, Daniel On Thu, Oct 27, 2022 at 4:25 PM John Scudder wrote: > Hi Daniel, > > I haven’t reviewed the full change set yet, but I have a couple of > comments I didn’t want to hold back while I find time to review the rest. > > > On Oct 20, 2022, at 1:23 AM, Daniel Migault wrote: > > [… snip …] > > > ### Section 4.3 > > > > I don't understand what this paragraph is telling me about the provision > of the > > IP address by the HNA: > > > > ``` > >The HNA works as a primary authoritative DNS server, while the DM > >works like a secondary. As a result, the HNA must provide the IP > >address the DM is using to reach the HNA. The synchronization > >Channel will be set between that IP address and the IP address of the > >DM. By default, the IP address used by the HNA in the Control > >Channel is considered by the DM and the specification of the IP by > >the HNA is only OPTIONAL. The transport channel (including port > >number) is the same as the one used between the HNA and the DM for > >the Control Channel. > > ``` > > > > You start out by saying the "the HNA must provide the IP address the DM > is > > using to reach the HNA". (By the way when you say "is using" I think you > mean > > "should use". No?) I note the use of "must". > > > > > > But then you go on to say that "the specification of the IP by the HNA > is only > > OPTIONAL". (I assume that "the IP" here means "the IP address" that was > > discussed a few sentences back, probably you should add the word > "address" if > > so.) > > > > These two sentences, the "must" in the first one and the "OPTIONAL" in > the > > later, seem directly in opposition to one another. :-( > > > > To set the synchronization channel the secondary needs to know the IP > address of the secondary. (must). > > I guess you must mean the secondary needs the IP address of the *primary*? > So, in this case, that means the DM needs to know the IP address of the HNA. > > > Either the IP is derived as the IP addressed used in the control channel > or the IP address is explicitly provided. The latest option is optional. > > I hope the addition of explicit addresses your concerns: > > > > By default, the IP address used by the HNA in the Control Channel is > considered by the DM and the explicit specification of the IP by the HNA > is only OPTIONAL. > > I finally (think that I) get it, but I think the addition of “explicit” > doesn’t really clarify it very much. Here’s how the text stands in version > 21: > > ``` >The HNA works as a primary authoritative DNS server, while the DM >works like a secondary. As a result, the HNA must provide the IP >address the DM should use to reach the HNA. The synchronization >Channel will be set between that IP address and the IP address of the >DM. By default, the IP address used by the HNA in the Control >Channel is considered by the DM and the explicit specification of the >IP by the HNA is only OPTIONAL. The transport channel (including >port number) is the same as the one used between the HNA and the DM >for the Control Channel. > ``` > A possible version that would be clearer to me: > >The HNA works as a primary authoritative DNS server, while the DM >works as a secondary. As a result, the DM needs to know what IP >address it should use to reach the HNA. Since the HNA initiates the >control channel to the DM, the DM will normally be able to use the >source address from the control channel as the IP address it will use >to reach the HNA. The explicit specification of the IP address by the >HNA is only OPTIONAL. The transport channel (including port number) >is the same as the one used between the HNA and the DM for the >Control Channel. > > Does that correctly capture what’s meant? > This captures what we were trying to say. I am happy to take your text. > > Although, now that I read the text again, I’m also having a hard time > understanding what is meant by the final sentence, "The transport channel > (including port number) is the same as the one used between
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)
On Thu, Oct 27, 2022 at 5:32 AM Michael Richardson wrote: > > Roman Danyliw via Datatracker wrote: > > [per -18] I’m not sure if this my misreading of the behavior of > > internal clients. To clarify, the (internal) Homenet DNSSEC Resolver > > will “... resolves the DS record on the Global DNS and the name > > associated to the Public Homenet Zone (myhome.example) on the Public > > Authoritative Servers.”? Why would the internal resolver serving a > > request for an internal client for an internal service go to the > Global > > DNS if the information if it could come from the internal Homenet > Zone > > it is already configured with? > > Because it needs the glue records to prove it is authoritative. > There are cases - quite common - where the Homenet Authoritative server does not exist. In such cases, the Homenet Resolvers just caches what is published outside. > > > As an operational consideration, why go > > outside of the network if you don’t need to? As a privacy > > consideration, why leak the request to an outside entity if the > network > > already has the information. > > We do mention in the version 21 that going outside has some privacy implications. Note also that the resolver only goes outside once the TTL has exceeded so that is not every time a DNS request is received. > [per -20] Thanks for the revised text: On the other hand, to provide > > resilience to the Public Homenet Zone in case of WAN connectivity > > disruption, the Homenet DNSSEC Resolver SHOULD be able to perform the > > resolution on the Homenet Authoritative Servers. > > > -- Is there a reason this can’t be a MUST? > > If the resolver and cache have been offline for long enough, any cached > chain > of DS/NS/DNSKEY records from . down to the myhome.example might have > expired. > (Consider a DNSSEC resolver on a host behind the gateway) > > What to do in this situation has many answers with different tradeoffs. > > Yes. answers and tradeoffs are indeed quite numerous and we can hardly go beyond such a recommendation. Consider that the homenet an authoritative server may not exist or the Homenet Naming Authority may play multiple roles. Also keep in mind that our document is mostly focused on the Homenet Naming Authority and Distributed Manager, not so much on the naming architecture of the home network. As a result, strong recommendations regarding the resolver may be a bit out of scope of the document. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
Hi Paul, Thanks for the follow-up. The reason we mentioned both RFC7858 and RFC9103 is that the communication between the Homenet Naming Authority (HNA) and the Distribution Manager (DM) involves two different channels. The Control Channel that aims at configuring/managing the Synchronization Channel (i.e. the primary/secondary). The Control Channel uses DNS over TLS RFC7858 while the Synchronization Channel uses DNS Zone transfer over TLS 9103. The two channels always go in pairs. As both are using DNS over TLS we use the mnemonic 'DoT' for the Selected Transport. From what you are saying, it might be clearer to just mention 'TLS' for the Selected Transport as DoT might be really tightened to 7858. If you think this is clearer, I am happy to do so as well as with any name that you think is clearer. Yours, Daniel On Mon, Oct 24, 2022 at 7:20 PM Paul Wouters wrote: > > > On Sun, Oct 23, 2022 at 10:45 PM Daniel Migault > wrote: > >> While TLS gives you privacy, >> >>> the DNS Update cannot be done with only TLS (as far as I understand it). >>>> >>>> please develop, but just in case, we do not use dns update to >>>> synchronize the zone. we use AFXR/IXRF over TLS define din XoT. >>>> >>> > This to me was not clear and a missed reference by me. While you name > RFC9103, the text states: > > DNS over TLS: indicates the support of DNS over TLS as described in >[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 > <https://datatracker.ietf.org/doc/html/rfc9103>]. > > I should have looked more closely at the references, and I would have > realized 9103 is about DNS XFR over TLS. That document indeed explains > that XoT uses mutually authenticated TLS which provides the authentication > for the XFR streams. > > My suggestion: > > Current: > > DNS over TLS: indicates the support of DNS over TLS as described in >[RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and [RFC9103 > <https://datatracker.ietf.org/doc/html/rfc9103>]. > > New: > > DNS Zone Transfer over TLS: indicates the support of DNS Zone Transfer > over TLS as described in [RFC9103] > > > The reference to RFC7858 is misleading - it only deals with stub to > recursive. > > If you think stub to recursive is in scope, it might be better to use two > DHCP options as these two things > seem to be very separate protocols (that just both happen to use DNS and > TLS) > > > > >> >>> So you are going against the RFC 5936 SHOULD. >>> >>> I even had to look this up because I didn't know you could do an AXFR as >>> a secondary >>> from a primary without DNS level authentication. Apparently you can, but >>> you SHOULD not. >>> >>> That is what we do. TLS provides enough security to replace TSIG / >> SIG(0). >> > > > Reading 9103 made that clear to me now, but the text in the document did > not. Perhaps that can be stated more clearly ? > > Paul > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-naming-architecture-dhc-options-21
Thanks for the response. Yours, Daniel On Mon, Oct 24, 2022 at 3:49 AM Miek Gieben wrote: > [ Quoting in "Re: [homenet] Dnsdir telechat > revie..." ] > >OLD: > >It is worth noticing that the Supported Transport field does not enable to > >specify a port and the used port is defined by standard. > > > > > >NEW: > >It is worth noticing that the Supported Transport field does not enable to > >specify a port and the used port is defined by a standard. > > That looks like a good change to me. > > And thank you for explaining why only DoT is specified in this draft. > > This draft looks good to me. > > Regards, > Miek Gieben > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
Hi Paul, Thanks for the feedback. This is interesting. Please see my responses. I do not see any need to add some text, but I am happy to do so if you think that is needed. Yours, Daniel On Sun, Oct 23, 2022 at 8:57 PM Paul Wouters wrote: > > On Thu, Oct 20, 2022 at 4:04 PM Daniel Migault > wrote: > >> Hi Paul, >> >> Some brief element of response to your questions. While you are raising >> comments within a DISCUSS see your comment as a very high level question on >> what is the content of the draft with many questions related not to that >> draft. I am happy to respond, but there is nothing actionable that can be >> done, so please be more specific. >> -- >> >>> DISCUSS: >>> -- >>> >>> This might be my misunderstanding >> >> of homenet, so hopefully easy to resolve. >>> >>> The HNA (hidden primary?) to DM (primary) DNS communication using DNS >>> Update >>> needs some kind of authentication, TSIG or SIG0 ? >> >> no >> >>> While TLS gives you privacy, >>> the DNS Update cannot be done with only TLS (as far as I understand it). >> >> please develop, but just in case, we do not use dns update to synchronize >> the zone. we use AFXR/IXRF over TLS define din XoT. >> >>> I >>> don't see any DHCP options to relay authentication information for >>> automatic >>> deployment? >> >> >> The FQDN "Distribution Manager FQDN" and "Reverse Distribution Manager FQDN" >> are sufficent to set a TLS session. >> >> So I don't understand how this would startup and be able to setup a >>> secure DNS update channel ? >>> >> >> TLS needs only names. The certificates binds the names to a key used for >> the authentication. >> > > So you are using transport security as a means for data authentication. > > > https://datatracker.ietf.org/doc/html/rfc5936#section-5 states: > >Ensuring that an AXFR client does not accept a forged copy of a zone >is important to the security of a zone. If a zone operator has the >opportunity, protection can be afforded via dedicated links, physical >or virtual via a VPN among the authoritative servers. But there are >instances in which zone operators have no choice but to run AXFR >sessions over the global public Internet. > >Besides best attempts at securing TCP connections, DNS >implementations SHOULD provide means to make use of "Secret Key >Transaction Authentication for DNS (TSIG)" [RFC2845 > <https://datatracker.ietf.org/doc/html/rfc2845>] and/or "DNS >Request and Transaction Signatures ( SIG(0)s )" [RFC2931 > <https://datatracker.ietf.org/doc/html/rfc2931>] to allow >AXFR clients to verify the contents. These techniques MAY also be >used for authorization. > > So you are going against the RFC 5936 SHOULD. > > I even had to look this up because I didn't know you could do an AXFR as a > secondary > from a primary without DNS level authentication. Apparently you can, but > you SHOULD not. > > That is what we do. TLS provides enough security to replace TSIG / SIG(0). > Unauthenticated AXFR is meant for zones that are open to the public and > dns clients that want > to grab a copy. It's not really meant for the actual primary <-> secondary > channel. You might > find that some DNS software insists on authentication if configured as > secondary, as ACLs to > just limit on IP address is really considered too weak. > > While using mutually authenticated TLS > might be an option these days, most DoH/DoT/DoQ I believe only consider > their use for privacy > of unauthenticated connections. I'm not sure there are implementations and > configurations out > there that deploy DoH/DoT/DoQ with mutually authenticated TLS., > > so we only considered DoT in the document. Other protocols are left for future work and only mentioned as potential examples. OARC35 [1] announced ongoing support for XoT by NSD, Unbound, BIND, PowerDNS and [2] is the commit "New configuration variables for client-side certificate". I believe we can reasonably say mutual authentication is on its way to become widely available. [1] https://indico.dns-oarc.net/event/38/contributions/857/attachments/802/1470/oarc35-xot-slides.pdf [2] https://github.com/NLnetLabs/nsd/commit/044c4b5d267dba69996267164395c6ed799e389b > Paul > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
are those expected to be published on the Public Homenet
Zone.
Note that the TTL SHOULD be set following the resolver's guide line {{?I-D.
ietf-dnsop-ns
-revalidation}} {{?I-D.ietf-dnsop-dnssec-validator-requirements}} with a TTL
not exceedi
ng those of the NS.
Section 11:
>
> The Privacy Considerations section is a bit hard to read. But in the end it
> comes down to "dont make your homenet DNS publicly reachable if you want
> privacy".
Indeed, I find publishing my entire home network into public DNS a
> serious risk. DNS scanners will end up scanning for well known names of
> popular
> brands of TVs, washing machines, saunas, lightbulbs, etc. Or they will
> start
> scanning zones based on well known ISP based secondary services. It is
> almost
> as if the better solution would be to only provide a publicly reachable
> homenet
> VPN server, that provides both DNS and the only working routes from my
> (remote)
> devices on my to my home network based devices.
>
> This is one way to do, but you do not need DNS in that case. Managing
names over multiple VPNs is not trivial though - not to mention that
configuring and making VPN work is not easy.
> The privacy and security of the DNS names is a small thing if homenet puts
> all
> my devices on the public IPv6 network.
The document distinguishes Public homenet zone and homenet zone so not all
your devices are expected to be public.
> Scanning IPv6 is still fairly hard to
> do, even of endusers /64. And putting those IPv6 addresses in DNS makes it
> much
> much easier to find all these devices and use their exposed services to
> compromise the device and/or network that they are in. These
> considerations are
> completely missing from the Security Considerations Section 12.
>
> This is the purpose of the entire section ## Names are less secure than
IP addresses that comes after.
Appendix A:
>
>This document does not deal with how the HNA is provisioned with a
>trusted relationship to the Distribution Manager for the forward
>zone.
>
> But that is core to the protocol ?
>
no. we assume the HNA is provisioned with the DM.
>
>Similarly, if the HNA is provided by a registrar, the HNA may be
>handed pre-configured to end user.
>
> How can that be if the user decides on the homenet network name it wants
> to use?
>
> registrars provide names, this is probably the easiest case.
> Appendix C:
>
> The example zone used is n8d234f.r.example.net. I thought the idea was
> for the
> user to have a memorable zone it can use, eg sharing with friends. Was I
> wrong?
>
> There are different use cases, and maybe for some people that is easy to
remember. An ISP may provide a name just to identify the network, a
registrar may provide a name to bootstrap the relation.
> with the "dm_acl": "2001:db8:1234:111:222::/64", set, what happens to
> the
> zone "n8d234f.r.example.net." when the user got unplugged and replugged
> and
> lives on a different ip range now ?
>
update the zone, sends a notify to the dm.
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Thanks Matt, I now understand clearly your point of view and can commit to remain vigilant if any other opinion goes into your direction. Thank you for taking the time to review the document anyway - your feedback and discussion was highly appreciated. Yours, Daniel On Sat, Oct 22, 2022 at 4:56 AM Matt Brown wrote: > On Sat, Oct 22, 2022 at 4:11 AM Daniel Migault > wrote: > > > > Hi Matt, > > > > Thanks for the follow-up, please see my response. > > > > Yours, > > Daniel > > > > On Thu, Oct 20, 2022 at 4:37 PM Matt Brown wrote: > >> > >> On Thu, Oct 20, 2022 at 5:53 PM Daniel Migault > wrote: > >> > > >> > Thanks for the feed back. Please see my response inline. Note that we > are clarifying the use of transport protocols in the current document. For > the synchronization channel we mandate XoT, for the control channel we > mandate DoT - still with mutual authentication. I hope the line below > adresse you concern regarding mutual authentication. > >> > Yours, > >> > Daniel > >> > > >> > On Wed, Oct 19, 2022 at 8:29 PM Matt Brown wrote: > >> >> > >> >> On Wed, Oct 19, 2022 at 3:25 PM Daniel Migault > wrote: > >> >> > > >> > >> > >> > >> >> > I would be happy to understand though why DoT would be an issue. > The only point I can see is that 7858 specifies that it limits its scope to > client -to resolver communications while admitting such restriction is due > to a charter limitation. Since XoT mentions it is heavily relying on DoT, > and resolvers and authoritative servers both handle DNS packets, I tend to > assume that we may consider DoT can be used for any DNS communications, but > I might be missing something. > >> >> > >> >> What I understand when I read this draft is a proposal is to take a > >> >> protocol (DoT, RFC7858) with a primary purpose of providing *privacy* > >> >> and which states in its design that authentication of clients is not > >> >> in scope and use it in a context where *authentication of clients* is > >> >> the primary requirement (e.g. the DM needs to know that it's > receiving > >> >> a connection from a client authorized to control the domain in the > >> >> messages). That type of usage outside of the scope envisaged by > >> >> RFC7858 brings two concerns to my mind: > >> >> 1) *How* will clients/servers choose to implement the client > >> >> authentication and will they be compatible with each other without > >> >> further guidance/constraint being provided on how client > >> >> authentication in DoT should be performed? > >> > > >> > This is correct that if client authentication is disable it will not > happen. That said, we can believe that if that is what we are looking at > the TLS library will be configured appropriately. IN this case the clients > and the server are specific entities. > >> > > >> > Regarding 7858, it does not say the client is not authenticated, it > says that the client authenticates the server and after the negotiation > completes the connection is encrypted. Client authentication is part of the > TLS negotiation. > >> > > >> > Another example is also that when session resumption occurs, it > becomes hard to claim the client is not authenticated as TLS uses tha > PSK-ECDHE scheme. > >> > > >> > To keep things simple, I would say if DoT were not defined we would > have said the traffic is secured by TLS. If we cannot use DoT we are happy > to do so, but I do not think using Dot is a concern there. That said, I am > happy to learn more if I am missing anything. > >> > >> If I'm understanding you correctly, the argument is that the > >> underlying TLS libraries support mTLS, so can be used in the way > >> proposed, even though it is outside the scope of what is standardised > >> in RFC7858. This may very well be true, but in my understanding it's > >> then incorrect to call this using DoT. To me, what is proposed is to > >> build further protocol specifics (client authentication) on top of DoT > >> - which may work, but if that is what is intended, then it needs to be > >> done explicitly - e.g."this standard extends the DoT specification to > >> support client authentication via mTLS" or similar. > >> > >> Are there existing DoT implementations using mTLS to authenticate > >> clients to DoT servers that you are aware
Re: [homenet] Murray Kucherawy's No Record on draft-ietf-homenet-front-end-naming-delegation-19: (with COMMENT)
Thanks for the review Murray, Please find find my comments inline as well as in the following link: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/66a4d61ca0ca9e4c3ddfe69015b2a3fd88444da1 Yours, Daniel On Thu, Oct 20, 2022 at 3:44 AM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-19: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > -- > COMMENT: > -- > > I have not completed my review. I expect to ballot to at least support > some or > all of the existing DISCUSS positions, and will have comments of my own. > The > DISCUSSes are broad enough that I'm going to stop my review for now. > > The one thing I noticed right away is that Section 2 defines "Reverse > Public > Authoritative Servers" and "Reverse Distribution Manager", but those terms > appear nowhere else in the document. > > > The first expansion was missing. OLD: In addition, the DM and RDM may be NEW: In addition, the DM and Reverse Distribution Manager (RDM) may be We also combined DOI and Reverse Public Authoritative Servers but clarified that. OLD: The main difference is that the ISP that provides the IP connectivity is likely also owning the corresponding reverse zone and act as a default DOI for it. NEW: The main difference is that ISP that provides the IP connectivity is likely also the owner of the corresponding reverse zone and administrating the Reverse Public Authoritative Servers ( or being the DOI) > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-20: (with DISCUSS and COMMENT)
as well as
confidentiality. As noted in {{!RFC9103}}, some level of privacy may be
relaxed, by not protecting the existence of the zone.
This MAY involved a mix of exchanges protected by TLS and exchanges not
protected by TLS.
This MAY be handled by a off-line agreement between the DM and HNA as well
as with the use of RCODES defined in Section 7.8 of {{!RFC9103}}.
NEW:
The TLS communication between the HNA and the DM MUST comply with
{{!I-D.ietf-uta-rfc7525bis}}. The Control Channel and the Synchronization
Channel respectively follow {{!RFC7858}} and {{!RFC9103}} guidelines. The
highest level of privacy provided by {{!RFC9103}} SHOULD be enforced. As
noted in {{!RFC9103}}, some level of privacy may be relaxed, by not
protecting the existence of the zone.
This MAY involve a mix of exchanges protected by TLS and exchanges not
protected by TLS.
This MAY be handled by a off-line agreement between the DM and HNA as well
as with the use of RCODES defined in Section 7.8 of {{!RFC9103}}.
(2) Section 6.5
>
>The provisioning process SHOULD provide a method of securing the
>Control Channel, so that the content of messages can be
>authenticated.
>
> Per the changes made in (1), and the strict requirement to mutually
> authenticate with TLS, why isn’t this a MUST?
>
removed.
Note that this is typically some of the sentences we planned to clean up
due to the clarification of the transport channels. We are planning to
review fully the paper to remove all the remaining ones - if some remains
and ensure some coherence with the changes recently provided. I feel
ashamed you did it before us... but that is greatly appreciated. Thank you
for taking that time.
>
> ** Section 1.3
>
> [per -18]
>When the resolution is performed from within the home network, the
>Homenet DNSSEC Resolver MAY proceed similarly.
>
> [per -18] I’m not sure if this my misreading of the behavior of internal
> clients. To clarify, the (internal) Homenet DNSSEC Resolver will “...
> resolves
> the DS record on the Global DNS and the name associated to the Public
> Homenet
> Zone (myhome.example) on the Public Authoritative Servers.”? Why would the
> internal resolver serving a request for an internal client for an internal
> service go to the Global DNS if the information if it could come from the
> internal Homenet Zone it is already configured with? As an operational
> consideration, why go outside of the network if you don’t need to? As a
> privacy consideration, why leak the request to an outside entity if the
> network
> already has the information.
>
> [per -20] Thanks for the revised text:
>On the other hand, to provide resilience to the Public Homenet Zone
>in case of WAN connectivity disruption, the Homenet DNSSEC Resolver
>SHOULD be able to perform the resolution on the Homenet Authoritative
>Servers.
>
> -- Please also point out that the use of the Homenet resolver would enhance
> privacy since the user on the home network would no longer be leaking
> interactions with internal services to an external DNS provider and to an
> on-path observer.
>
> added
> -- Is there a reason this can’t be a MUST?
>
> yes. The first one is that such an authoritative server may not exist or
the HNA may play both roles. The second one is that recommendations apply
to resolvers (or authoritative servers) that could be a bit of a border
line to the scope of the current document.
The homenet WG planned to publish a naming document for homenet where this
would be detailed but that document never got finalized - this is actually
why the publication of this document took so much time. As a result, the
SHOULD seems sufficiently broad to put the focus on it, while not providing
a detail that derails the discussion.
> -- Editorial (comment level, but adding here for convenience) Consider if
> you
> want to use the “DNSSEC Resolver” or “DNS(SEC) Resolver” (as was introduced
> later) since DNSSEC is not mandatory.
>
>
> I changed it in 8 places
> ------
> COMMENT:
> --
>
> I support Warren, John and Paul’s DISCUSS positions.
>
> Thank you for addressing my COMMENTs.
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Hi Matt, Thanks for the follow-up, please see my response. Yours, Daniel On Thu, Oct 20, 2022 at 4:37 PM Matt Brown wrote: > On Thu, Oct 20, 2022 at 5:53 PM Daniel Migault > wrote: > > > > Thanks for the feed back. Please see my response inline. Note that we > are clarifying the use of transport protocols in the current document. For > the synchronization channel we mandate XoT, for the control channel we > mandate DoT - still with mutual authentication. I hope the line below > adresse you concern regarding mutual authentication. > > Yours, > > Daniel > > > > On Wed, Oct 19, 2022 at 8:29 PM Matt Brown wrote: > >> > >> On Wed, Oct 19, 2022 at 3:25 PM Daniel Migault > wrote: > >> > > > > > >> > I would be happy to understand though why DoT would be an issue. The > only point I can see is that 7858 specifies that it limits its scope to > client -to resolver communications while admitting such restriction is due > to a charter limitation. Since XoT mentions it is heavily relying on DoT, > and resolvers and authoritative servers both handle DNS packets, I tend to > assume that we may consider DoT can be used for any DNS communications, but > I might be missing something. > >> > >> What I understand when I read this draft is a proposal is to take a > >> protocol (DoT, RFC7858) with a primary purpose of providing *privacy* > >> and which states in its design that authentication of clients is not > >> in scope and use it in a context where *authentication of clients* is > >> the primary requirement (e.g. the DM needs to know that it's receiving > >> a connection from a client authorized to control the domain in the > >> messages). That type of usage outside of the scope envisaged by > >> RFC7858 brings two concerns to my mind: > >> 1) *How* will clients/servers choose to implement the client > >> authentication and will they be compatible with each other without > >> further guidance/constraint being provided on how client > >> authentication in DoT should be performed? > > > > This is correct that if client authentication is disable it will not > happen. That said, we can believe that if that is what we are looking at > the TLS library will be configured appropriately. IN this case the clients > and the server are specific entities. > > > > Regarding 7858, it does not say the client is not authenticated, it says > that the client authenticates the server and after the negotiation > completes the connection is encrypted. Client authentication is part of the > TLS negotiation. > > > > Another example is also that when session resumption occurs, it becomes > hard to claim the client is not authenticated as TLS uses tha PSK-ECDHE > scheme. > > > > To keep things simple, I would say if DoT were not defined we would have > said the traffic is secured by TLS. If we cannot use DoT we are happy to do > so, but I do not think using Dot is a concern there. That said, I am happy > to learn more if I am missing anything. > > If I'm understanding you correctly, the argument is that the > underlying TLS libraries support mTLS, so can be used in the way > proposed, even though it is outside the scope of what is standardised > in RFC7858. This may very well be true, but in my understanding it's > then incorrect to call this using DoT. To me, what is proposed is to > build further protocol specifics (client authentication) on top of DoT > - which may work, but if that is what is intended, then it needs to be > done explicitly - e.g."this standard extends the DoT specification to > support client authentication via mTLS" or similar. > > Are there existing DoT implementations using mTLS to authenticate > clients to DoT servers that you are aware of? I could not find any in > a quick search. > > As you noted previously the XoT spec provides a good example that > building on top of DoT in this way is feasible and a reasonable thing > to do - which is useful - but I think two things should be noted from > that comparison (emphasis mine below): > 1) XoT does not say it uses DoT, it says (end of Introduction): > "encrypting zone transfers using TLS [RFC8499] -- **based closely on > DoT [RFC7858]** -- seems like a simple step forward. This document > specifies how to use TLS (1.3 or later) as a transport to prevent zone > collection from zone transfers." - e.g. it is clear that what is being > described is not DoT, but something close to it. > 2) The level of detail in how to accomplish that extension is higher > than I see present in this draft (e.g. RFC9103 7.1, 7.3 cover TLS > establi
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS)
Hi Paul, Some brief element of response to your questions. While you are raising comments within a DISCUSS see your comment as a very high level question on what is the content of the draft with many questions related not to that draft. I am happy to respond, but there is nothing actionable that can be done, so please be more specific. Yours, Daniel On Thu, Oct 20, 2022 at 1:58 AM Paul Wouters via Datatracker < nore...@ietf.org> wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-homenet-naming-architecture-dhc-options-21: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ > > > > -- > DISCUSS: > -- > > This might be my misunderstanding of homenet, so hopefully easy to resolve. > > The HNA (hidden primary?) to DM (primary) DNS communication using DNS > Update > needs some kind of authentication, TSIG or SIG0 ? no > While TLS gives you privacy, > the DNS Update cannot be done with only TLS (as far as I understand it). please develop, but just in case, we do not use dns update to synchronize the zone. we use AFXR/IXRF over TLS define din XoT. > I > don't see any DHCP options to relay authentication information for > automatic > deployment? The FQDN "Distribution Manager FQDN" and "Reverse Distribution Manager FQDN" are sufficent to set a TLS session. So I don't understand how this would startup and be able to setup a > secure DNS update channel ? > TLS needs only names. The certificates binds the names to a key used for the authentication. > There was also talk about using ACME for TLS certificates, but wouldn't > that > require that the HNA already has a provisioned and working homenet domain ? > The draft does not mention ACME so I do not see what you are referring to. > (possibly more a question for the other draft, but just adding it here in > case > the hidden primary to primary is an "almost DNS Update" protocol that uses > TLS > instead f TSIG/SIG0. > > not at all. we do not use dns update at all for synchronizing the zones. > > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Lars Eggert's Discuss on draft-ietf-homenet-naming-architecture-dhc-options-22: (with DISCUSS and COMMENT)
Hi Zahed and Lars,
I think I mis-understood the comment.
I initially thought you were concerned that the server cannot specify
whatever port it wants. The current text was mostly saying "because DHCP
does not specify the port, the port needs to be defined by a standard. That
standard can be a document defining a default port for a transport protocol
or a document specifying the code point of the new Supported Transport.
>From the IESG telechat, I understand the concern is that if the client and
the server have agreed on another port - let's say out of band. They can
use that port.
If I understood correctly, I changed the following text:
OLD:
It is worth noticing that the Supported Transport field does not enable to
specify a por
t and the used port is defined by a standard.
In the case of DNS over TLS {{!RFC7858}}, the port is defined by
{{!RFC7858}} to be 853.
The need for such flexibility has been balanced with the difficulty of
handling a list o
f tuples ( transport, port ) as well as the possibility to use a dedicated
IP address fo
r the DM.
NEW:
It is worth noticing that the DHCP Option specifies the Supported
Transport without specifying any explicit port. Unless the HNA and the DM
have agreed on using a specific port - for example by configuration, or any
out of band mechanism -, the default port is used and must be specified.
The specification of such default port may be defined in the specification
of the designated Supported Transport or in any other document.
In the case of DNS over TLS {{!RFC7858}}, the default port is defined by
{{!RFC7858}} with the following value: 853.
The need to associate in the DHCP Option the port value to each Supported
Transport has been balanced with the difficulty of handling a list of
tuples ( transport, port ) as well as the possibility to use a dedicated IP
address for the DM in case the default port was already in use.
Yours,
Daniel
On Thu, Oct 20, 2022 at 9:37 AM Daniel Migault wrote:
> Hi Lars,
>
> Thanks for the comment. Please see my response inline below. The updates
> associated to your comments can be found below:
>
> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/3113e186f17ed36ee3ec635b1414bdc181e06484
>
> Yours,
> Daniel
>
>
> On Thu, Oct 20, 2022 at 8:21 AM Lars Eggert via Datatracker <
> nore...@ietf.org> wrote:
>
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-homenet-naming-architecture-dhc-options-22: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> # GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22
>>
>> CC @larseggert
>>
>> Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART)
>> review
>> (
>> https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY
>> ).
>>
>> ## Discuss
>>
>> ### Section 4.2, paragraph 8
>> ```
>> It is worth noticing that the Supported Transport field does not
>> enable to specify a port and the used port is defined by a standard.
>> In the case of DNS over TLS [RFC7858], the port is defined by
>> [RFC7858] to be 853. The need for such flexibility has been balanced
>> with the difficulty of handling a list of tuples ( transport, port )
>> as well as the possibility to use a dedicated IP address for the DM.
>> ```
>> 7858 actually says
>>
>>By default, a DNS server that supports DNS over TLS MUST listen for
>>and accept TCP connections on port 853, unless it has mutual
>>agreement with its clients to use a port other than 853 for DNS over
>>TLS.
>>
>> So it is fully permissible for a DoT server to run on a different port
>> under
>> such a mutual agreement. In general, for other possible transports, just
>> because
>> a port is assigned for use does not mean a deployment is obligated to run
>> on it.
>>
>>
>> I agree. What we are trying to say is that we did not find it useful to
&
Re: [homenet] Zaheduzzaman Sarker's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
Hi Zahed and Lars,
I think I mis-understood the comment.
I initially thought you were concerned that the server cannot specify
whatever port it wants. The current text was mostly saying "because DHCP
does not specify the port, the port needs to be defined by a standard. That
standard can be a document defining a default port for a transport protocol
or a document specifying the code point of the new Supported Transport.
>From the IESG telechat, I understand the concern is that if the client and
the server have agreed on another port - let's say out of band. They can
use that port.
If I understood correctly, I changed the following text:
OLD:
It is worth noticing that the Supported Transport field does not enable to
specify a por
t and the used port is defined by a standard.
In the case of DNS over TLS {{!RFC7858}}, the port is defined by {{!RFC7858}}
to be 853.
The need for such flexibility has been balanced with the difficulty of
handling a list o
f tuples ( transport, port ) as well as the possibility to use a dedicated
IP address fo
r the DM.
NEW:
It is worth noticing that the DHCP Option specifies the Supported
Transport without specifying any explicit port. Unless the HNA and the DM
have agreed on using a specific port - for example by configuration, or any
out of band mechanism -, the default port is used and must be specified.
The specification of such default port may be defined in the specification
of the designated Supported Transport or in any other document.
In the case of DNS over TLS {{!RFC7858}}, the default port is defined by
{{!RFC7858}} with the following value: 853.
The need to associate in the DHCP Option the port value to each Supported
Transport has been balanced with the difficulty of handling a list of
tuples ( transport, port ) as well as the possibility to use a dedicated IP
address for the DM in case the default port was already in use.
Yours,
Daniel
On Thu, Oct 20, 2022 at 10:11 AM Daniel Migault wrote:
> Thanks I will adresse this in a couple of hours.
> Yours,
> Daniel
>
> On Thu, Oct 20, 2022 at 9:59 AM Zaheduzzaman Sarker <
> zaheduzzaman.sar...@ericsson.com> wrote:
>
>>
>>
>> On 20 Oct 2022, at 15:47, Daniel Migault wrote:
>>
>> -- I clicked send to early.
>> Hi Zahed,
>>
>> Thanks for the review. Please find my response inline as well as the
>> updated text below:
>>
>> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/c29b4ca2b6e2af4de82ba20a975f3540fc93c458
>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-5f6c20e934f2ca0b=1=92ddb335-b817-49fd-9afc-6a7f2862d9c8=https%3A%2F%2Fgithub.com%2Fietf-homenet-wg%2Ffront-end-naming-delegation-dhc-options%2Fcommit%2Fc29b4ca2b6e2af4de82ba20a975f3540fc93c458>
>>
>> I hope it addresses your concerns.
>>
>> Yours,
>> Daniel
>>
>>>
>>>
>>> On Thu, Oct 20, 2022 at 8:39 AM Zaheduzzaman Sarker via Datatracker <
>>> nore...@ietf.org> wrote:
>>>
>>>> Zaheduzzaman Sarker has entered the following ballot position for
>>>> draft-ietf-homenet-naming-architecture-dhc-options-22: No Objection
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>>>>
>>>>
>>>>
>>>> --
>>>> COMMENT:
>>>> --
>>>>
>>>> Thanks for working on this document. I am supporting Lars's discuss to
>>>> clarify
>>>> the implication of a non standard port usage.
>>>>
>>>> We only chose to use the standard port. The reason we mentioned this is
>>> that when other transport modes will be used, a standard port will be
>>> defined. Either in the document defining the transport or in a document
>>> specifying the code point for the Supported Transport.
>>>
>>
>> What you wrote here is much clear than what is written in the document.
>> But then I would like to see normative language to use o
Re: [homenet] Zaheduzzaman Sarker's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
Thanks I will adresse this in a couple of hours. Yours, Daniel On Thu, Oct 20, 2022 at 9:59 AM Zaheduzzaman Sarker < zaheduzzaman.sar...@ericsson.com> wrote: > > > On 20 Oct 2022, at 15:47, Daniel Migault wrote: > > -- I clicked send to early. > Hi Zahed, > > Thanks for the review. Please find my response inline as well as the > updated text below: > > https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/c29b4ca2b6e2af4de82ba20a975f3540fc93c458 > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-5f6c20e934f2ca0b=1=92ddb335-b817-49fd-9afc-6a7f2862d9c8=https%3A%2F%2Fgithub.com%2Fietf-homenet-wg%2Ffront-end-naming-delegation-dhc-options%2Fcommit%2Fc29b4ca2b6e2af4de82ba20a975f3540fc93c458> > > I hope it addresses your concerns. > > Yours, > Daniel > >> >> >> On Thu, Oct 20, 2022 at 8:39 AM Zaheduzzaman Sarker via Datatracker < >> nore...@ietf.org> wrote: >> >>> Zaheduzzaman Sarker has entered the following ballot position for >>> draft-ietf-homenet-naming-architecture-dhc-options-22: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ >>> >>> >>> >>> -- >>> COMMENT: >>> -- >>> >>> Thanks for working on this document. I am supporting Lars's discuss to >>> clarify >>> the implication of a non standard port usage. >>> >>> We only chose to use the standard port. The reason we mentioned this is >> that when other transport modes will be used, a standard port will be >> defined. Either in the document defining the transport or in a document >> specifying the code point for the Supported Transport. >> > > What you wrote here is much clear than what is written in the document. > But then I would like to see normative language to use only the standard > port and not allow other ports that RFC7858 allows to use. > > >> >>> I also think this paragraph >>> >>>It is worth noticing that the Supported Transport field does not >>> enable to >>>specify a port and the used port is defined by a standard. In the >>> case of >>>DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853. >>> The need >>>for such flexibility has been balanced with the difficulty of >>> handling a >>>list of tuples ( transport, port ) as well as the possibility to use a >>>dedicated IP address for the DM. >>> >>> should be moved to section 4.4 if this consideration is also true for >>> section >>> 4.3. >>> >>> correct. I just copied the lines. >> >>> >>> >>> ___ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> >> -- >> Daniel Migault >> Ericsson >> > > > -- > Daniel Migault > Ericsson > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Robert Wilton's No Objection on draft-ietf-homenet-front-end-naming-delegation-19: (with COMMENT)
and serves > as a > requirements statement for mechanisms. Warning: Apostrophe might be > missing. > Suggested change: "requirements'" > > Section: A.1, draft text: > — the Registered Domain (e.g., myhome.example ) — the contact info for the > Distribution Manager (DM), including the DNS name (FQDN), possibly > including > the IP literal, and a certificate (or anchor) to be used to authenticate > the > service — the DM transport protocol and port (the default is DNS over TLS, > on > port 853) — the HNA credentials used by the DM for its authentication. > Warning: > Don't put a space before the closing parenthesis. Suggested change: ")" > > Section: A.1, draft text: > The above parameters MUST be be provisioned for ISP-specific reverse zones. > Warning: Did you mean been? > Suggested change: "been" > > Section: A.1, draft text: > Once the registrar has been selected, the HNA redirects the end user to > that > registrar in order to receive a access token. Warning: Use an instead of > 'a' > if the following word starts with a vowel sound, e.g. 'an article', 'an > hour' > Suggested change: "an" > > Section: Appendix B, draft text: > Note that HNA does not defines ports for the Synchronization Channel. > Warning: Did you mean define? As 'do' is already inflected, the verb > cannot > also be inflected. Suggested change: "define" > > Section: Appendix B, draft text: > Currently the Configuration Channel does not provide this, and limits its > agility to a dedicated IP address. Warning: Did you forget a comma after a > conjunctive/linking adverb? Suggested change: "Currently," > > Section: Appendix B, draft text: > The device would need to be provisioned with a device-unique credential, > and it > is likely that the Registered Homenet Domain would be derived from a public > attribute of the device, such as a serial number (see [sec-ex-manu] or > [I-D.richardson-homerouter-provisioning] for more details ). Warning: > Don't > put a space before the closing parenthesis. Suggested change: ")" > > Section: Appendix C, draft text: > In addition to having a assymmetric credential known to the manufacturer, > the > device also has been provisioned with an agreed upon name. Warning: Use an > instead of 'a' if the following word starts with a vowel sound, e.g. 'an > article', 'an hour' Suggested change: "an" > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Zaheduzzaman Sarker's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
-- I clicked send to early. Hi Zahed, Thanks for the review. Please find my response inline as well as the updated text below: https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/c29b4ca2b6e2af4de82ba20a975f3540fc93c458 I hope it addresses your concerns. Yours, Daniel > > > On Thu, Oct 20, 2022 at 8:39 AM Zaheduzzaman Sarker via Datatracker < > nore...@ietf.org> wrote: > >> Zaheduzzaman Sarker has entered the following ballot position for >> draft-ietf-homenet-naming-architecture-dhc-options-22: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> >> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ >> >> >> >> -- >> COMMENT: >> -- >> >> Thanks for working on this document. I am supporting Lars's discuss to >> clarify >> the implication of a non standard port usage. >> >> We only chose to use the standard port. The reason we mentioned this is > that when other transport modes will be used, a standard port will be > defined. Either in the document defining the transport or in a document > specifying the code point for the Supported Transport. > > >> I also think this paragraph >> >>It is worth noticing that the Supported Transport field does not >> enable to >>specify a port and the used port is defined by a standard. In the case >> of >>DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853. >> The need >>for such flexibility has been balanced with the difficulty of handling >> a >>list of tuples ( transport, port ) as well as the possibility to use a >>dedicated IP address for the DM. >> >> should be moved to section 4.4 if this consideration is also true for >> section >> 4.3. >> >> correct. I just copied the lines. > >> >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Zaheduzzaman Sarker's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
Hi Zahed, Thanks for the review. On Thu, Oct 20, 2022 at 8:39 AM Zaheduzzaman Sarker via Datatracker < nore...@ietf.org> wrote: > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-homenet-naming-architecture-dhc-options-22: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ > > > > -- > COMMENT: > -- > > Thanks for working on this document. I am supporting Lars's discuss to > clarify > the implication of a non standard port usage. > > We only chose to use the standard port. The reason we mentioned this is that when other transport modes will be used, a standard port will be defined. Either in the document defining the transport or in a document specifying the code point for the Supported Transport. > I also think this paragraph > >It is worth noticing that the Supported Transport field does not enable > to >specify a port and the used port is defined by a standard. In the case > of >DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853. The > need >for such flexibility has been balanced with the difficulty of handling a >list of tuples ( transport, port ) as well as the possibility to use a >dedicated IP address for the DM. > > should be moved to section 4.4 if this consideration is also true for > section > 4.3. > > correct. I just copied the lines. > > > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Lars Eggert's Discuss on draft-ietf-homenet-naming-architecture-dhc-options-22: (with DISCUSS and COMMENT)
^^ > ``` > This expression is usually spelled with a hyphen. > > Section 4.3, paragraph 2 > ``` > represents a supported transport, and a RDM MAY indicate the support of > multi > ^ > ``` > Use "an" instead of "a" if the following word starts with a vowel sound, > e.g. > "an article", "an hour". > > Section 4.3, paragraph 6 > ``` > FC8415] govern server operation in regards to option assignment. As a > conveni > ^ > ``` > Use "in regard to", "with regard to", or more simply "regarding". > > fixed > "A.3.", paragraph 4 > ``` > cribed in Appendix A.2, the HNA is expect to be able to handle multiple > Home >^^ > ``` > Consider using either the past participle "expected" or the present > participle > "expecting" here. > > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-front-end-naming-delegation-19: (with COMMENT)
Hi Lars, I have removed the section related to dynamic update which is a non technical section that everyone discusses. Such discussions had been endless and unhelpful in the homenet wg. We thought this section would close some of these discussions, but it seems it reopens others. We do not want to discuss speculation regarding one or the other protocol. We are happy to understand why you think the protocol cannot be implemented, but currently we do not see anything that supports this. Yours, Daniel On Thu, Oct 20, 2022 at 8:10 AM Lars Eggert via Datatracker < nore...@ietf.org> wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-19: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > -- > COMMENT: > -- > > I agree with the Discusses and Comments on this document - this simply > isn't > implementable as described. > > My main reason for abstaining is something else though. This document has > been > worked on for almost ten years. While in the beginning, we might have > expected > or at least hoped that a solution in the shape that this document tries to > describe would see adoption, it's become very clear that dynamic DNS > services > as described in Section 4 have won out here. These services are far from > perfect, but at least some of the limitations in Section 4 have been > addressed, > and others are arguably a feature and not a limitation. > > > > ___________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
how the homenet authoritative servers are provisioned with the zone they serve. > 41: > O: "The main issue is that the Dynamic DNS update would also update the > parent zone's (NS, DS and associated A or records) while the > goal is to update the DM configuration files. The visible NS records > SHOULD > remain pointing at the cloud provider's server IP address - which in many > cases will be an anycast addresses. Revealing the address of the HNA in > the > DNS is not desirable. " > C: Huh? *What* main issue? Is this text just misplaced and supposed to be > somewhere else? It seems completely unrelated to this section. Also, what > "cloud provider"? This is the only mention of a cloud provider. And what > Dynamic DNS update are you talking about here? > > This has been rephrased in Matt's comments. I think we clarified this. > 42: > O: "While > information is carried from the DOI to the HNA and from the HNA to > the DOI, the HNA is always initiating the exchange in both > directions. > As such the HNA has a prior knowledge of the DM identity (X509 > certificate), the IP address and port number to use and protocol to > set secure session." > C: "As such" doesn't make sense here (or I'm unable to parse it) -- the > first > bit says that the HNA initiates the exchanges, but the second bit says > that "As > such it has knowledge" - perhaps you mean "requires"? I have no idea what > this > is supposed to say. > > Since the HNA starts the exchange it knows which DM he is establishing a session with. Section 4.1. Information to Build the Public Homenet Zone: > 43: > O: "The HNA builds the Public Homenet Zone based on information retrieved > from the DM." > C: Retrieved how? (Link to 4.5.1, otherwise the reader will be very > confused.) > > added link > 44: > O: "The information includes at least names and IP addresses of the > Public Authoritative Name Servers. In term of RRset information this > includes: > * the MNAME of the SOA," > C: This says "this includes at least names and IP addresses" but then also > suddenly throws in the MNAME. Also, what is the MNAME actually used for? > The > document says that you have to put it in the zone, but why must it be > what the > DM says, but the other parameter in the SOA can be changed? > > The list points where these servers appears. The MNAME belongs to the Public Authoritative Name Servers 45: > O: "The DM MAY also provide operational parameters such as other fields > of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM)." > C: S 4.5.1 says that this is received over AXFR, so the HNA always gets > the SOA > -- so how is this a "MAY also provide"? Or is it supposed to be that it > always > provides these, but the HNA can ignore some or all of them? > yes, it is up to the DM. > > Section "4.2. Information to build the DNSSEC chain of trust" > 46: > O: "The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI > provides this value to the parent zone." > C: Is it that the HNA should provide the DS, or a hash of the KSK? (The DS > is > more than just the hash). C: "so that the DOI can provide" > > The section says: By accepting the DS RR, the DM commits in taking care of advertising the DS to the parent zone. Upon refusal, the DM clearly indicates it does not have the capacity to proceed to the update. We clarified saying: The HNA SHOULD provide the hash of the KSK via the DS RRset, 47: > O: "When such relation exists, the > HNA should be able to request the DOI to update the DS RRset in the > parent zone." > C: "should be able to request" - this implies that there is a specific way > for > the HNA to request this, if this relationship exists -- how would the HNA > know > this? Shouldn't it always send the DS? > We do not say MUST send the DS but we say SHOULD send the DS. > > 48: > O: "The HNA SHOULD provide... " and "Though the HNA may also later directly > update the values of the DS > via the Control Channel, it is RECOMMENDED to use other mechanisms". > "SHOULD provide" how? Over the Control Channel? And how does that relate > to > the RECOMMEND to use other mechanisms? > > We only provide one way to provide it. When other mechanism are used it needs to be provided once. > Section 4.3. Information to set the Synchronization Channel > 49: > O: "As a result, the HNA must provide the IP > address the DM is using to reach the HNA. The synchronization > Channel will be set between that IP address and the IP address of the > DM. By default, the IP address used by the HNA in the Control > Channel is considered by the DM and the specification of the IP by > the HNA is only OPTIONAL. The transport channel (including port > number) is the same as the one used between the HNA and the DM for > the Control Channel." > C: This entire paragraph is really confusing. I'm guessing that this is > trying > to sat that the HNA provides the IP for the DM to contact it? C: It also > says > that the DM "considers" the IP used by the HNA, and so the specification > of the > IP is OPTIONAL. I'm guessing that this is trying to say that the DM will, > by > default, use the IP that the HNA used to contact it? In the non-default > case, > how exactly does the HNA specify the address? (how is this communicated?). > C: > Also, "The transport channel (including port > number) is the same as the one used between the HNA and the DM for > the Control Channel." -- so the transport channel and Control Channel use > the > same IPs and ports? How are messages disambiguated? Isn't this jsut one > channel then? > > It says the two channels are using the same IP. Section shows why there is not possible ambiguation. > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
, or disregard, the > SHOULD? Only TLS packet or potentially some DNS packets (see XoT) packets SHOULD be allowed. This concerns firewall rules so not necessarily mandatory. > > ### Section 10 > > ``` >Then, >the HNA advertises the DM via a NOTIFY, that the Public Homenet Zone >has been updated > ``` > > Probably you mean "advertises to" or maybe better, "advises", where you've > written "advertises"? If not, then I don't understand what's happening in > this > part. > > ok changed to advertises to. > ### Section 12.2 > > Consider using "their" instead of "his". > > changed > ### Section 14 > > Was "its" chosen as the pronoun for two persons being thanked, based on > those > persons' preferences? If not then consider whether you've used the right > pronoun in those two places, in my experience it's fairly rare -- but not > unheard-of! -- for a person to prefer to be referred to as "it" rather > than the > more common "he", "she", or "they". > > changed. > ### Appendix A.1 > > I'm a little confused -- the first couple of paragraphs led me to believe > that > this section was just going to tell me what parameters are required, but > wasn't > going to mandate the means of providing them. But then we come to, > > ``` >The above parameters MUST be be provisioned for ISP-specific reverse >zones, as per [I-D.ietf-homenet-naming-architecture-dhc-options]. > ``` > > The "MUST" combined with the "as per" implies you're mandating that DHCPv6 > be > used to provision the parameters. If you really do intend to make > dhc-options > mandatory, it needs to be a normative reference. On the other hand if, as I > think is likely, you only intended to use dhc-options as an example, > perhaps > something like this rewrite? > > ``` >The above parameters MUST be be provisioned for ISP-specific reverse >zones. One example of how to do this can be found in >[I-D.ietf-homenet-naming-architecture-dhc-options]. > ``` > > changed thanks. > ### Appendix B - "registered_domain" or "zone"? > > This threw me off -- in the CDDL you show "registered_domain" but in the > explanatory text you describe (what I think is) this field as "Registered > Homenet Domain (zone)". Should the latter be "Registered Homenet Domain > (registered_domain)" instead? (Or, rename "registered_domain" in the CDDL > as > "zone"?) changed thanks. > > ### Appendix B - 2119 keywords > > It's weird that you lead with "This section is non-normative" but then > pepper > the content with the RFC 2119 keyword "OPTIONAL". I think probably you > don't > mean it's "non-normative" (that generally means something like "this is an > example, it doesn't define anything, it can safely be ignored"). Rather, I > think you mean implementing it is optional. I think you could fix this by > deleting the words "is non-normative and". > > changed. > Also, "MANDATORY" isn't an RFC 2119 keyword but you've capitalized it like > one. > If you want to introduce your own keyword to put the the force of VERY > SERIOUS > NORMATIVE CAPITALIZATION behind this word, I think it would be a good idea > to > define it in your Terminology section, probably right after the RFC 2119 > boilerplate paragraph. Alternately, you could just change all your uses of > "mandatory" and "optional" in this section to lower-case. It would still be > clear, IMO. > > done > ## NITS > > - "these names needs" --> "these names need" > - "The remaining of the document" --> "the rest of the document" > - "buys a domain name to a registrar" --> "buys a domain name from a > registrar" > - "DOI has a roof of ownership" --> "roof" should be... "proof"? > - "as detaille din further details below" --> "as detailed below" > - "rsynch" --> "rsync" > - "meth of" --> "method" > > changed. > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Thanks for the feed back. Please see my response inline. Note that we are
clarifying the use of transport protocols in the current document. For the
synchronization channel we mandate XoT, for the control channel we mandate
DoT - still with mutual authentication. I hope the line below adresse you
concern regarding mutual authentication.
Yours,
Daniel
On Wed, Oct 19, 2022 at 8:29 PM Matt Brown wrote:
> On Wed, Oct 19, 2022 at 3:25 PM Daniel Migault
> wrote:
> >
> > Hi Matt,
> >
> > Thanks for the review. I am only responding to the major comments - for
> now. I apologize for the partial response but I promise I will go through
> all other comments tomorrow (my) morning and hope you will still have this
> partial response (your) morning.
>
> No problem, likewise responding just to this first message now, and
> hopefully to your subsequent message later today!
>
> >> Major Issues (aka Not Ready):
> >>
> >> Mutual TLS and DoT - 3.2 and 4.6 recommend that the HNA and DM secure
> their
> >> control channel communications using mutual TLS and DoT - but DoT is not
> >> specified to support mutual authentication. While mutual TLS auth at the
> >> underlying TLS layer is clearly viable - how to integrate that at the
> DNS
> >> layer, and whether that is compatible with DoT on the existing port, or
> would
> >> need a further port allocation (and subsequent IANA consideration in
> 13) would
> >> need to be addressed. None of the alternative future protocols listed
> in 3.2
> >> support mTLS either as far as I am aware.
> >>
> >> Given the recommendation to use XoT (RFC9103) (which does specify mTLS
> >> capability) for the Synchronization channel in 5.1 - I wonder why this
> protocol
> >> has not also been considered for the control channel instead of DoT?
> >>
> > The section securing the Synchronization channel mentions:
> >
> > The AXFR request from the DM to the HNA SHOULD be secured and the use of
> TLS is RECOMMENDED {{!RFC9103}}.
> >
> > So this is effectively what we rely on, mostly for the following
> reasons: 1) most of our exchanges are IXFR/AXFR and these are the one with
> the main concern, and 2) we wanted to reuse what is implemented in major
> distributions.
> > To put it in another way, we wanted the transaction between the HNA and
> the DM to be protected by TLS, and probably split from DNS over TLS to DoT.
> Would replacing DoT by XoT address your concern ?
>
> I'll confess my first encounter with XoT was in reading this draft, so
> I don't have a lot of context on its suitability for this use-case
> yet, but in as much as it looks at a glance to be a protocol that is
> intended to support mTLS (where DoT is not) in a context where
> authentication is expected, then I think it would address my
> concern... more below.
>
> > I would be happy to understand though why DoT would be an issue. The
> only point I can see is that 7858 specifies that it limits its scope to
> client -to resolver communications while admitting such restriction is due
> to a charter limitation. Since XoT mentions it is heavily relying on DoT,
> and resolvers and authoritative servers both handle DNS packets, I tend to
> assume that we may consider DoT can be used for any DNS communications, but
> I might be missing something.
>
> What I understand when I read this draft is a proposal is to take a
> protocol (DoT, RFC7858) with a primary purpose of providing *privacy*
> and which states in its design that authentication of clients is not
> in scope and use it in a context where *authentication of clients* is
> the primary requirement (e.g. the DM needs to know that it's receiving
> a connection from a client authorized to control the domain in the
> messages). That type of usage outside of the scope envisaged by
> RFC7858 brings two concerns to my mind:
> 1) *How* will clients/servers choose to implement the client
> authentication and will they be compatible with each other without
> further guidance/constraint being provided on how client
> authentication in DoT should be performed?
>
This is correct that if client authentication is disable it will not
happen. That said, we can believe that if that is what we are looking at
the TLS library will be configured appropriately. IN this case
the clients and the server are specific entities.
Regarding 7858, it does not say the client is not authenticated, it says
that the client authenticates the server and after the negotiation
completes the connection is encrypted. Client authentication is part of the
TLS negotiation.
Another example is also that when session resumption occurs, it becomes
hard to claim the client is not aut
Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS and COMMENT)
rom the left, > or > right? Please also update Section 6 with this information. > > specified with left most and left to right in section 6. > ### Section 5.2 > > I'm not a DHCPv6 (or DHCP) expert so please help me out -- am I correct > that > there's no concept of a lease that applies to the options defined in this > document? > > There is no lease, you are correct. > My concern comes from musing about whether there's a need to talk about > what > must happen if a client retrieves a set of parameters, does things based on > them, later retrieves the parameters again and the new ones don't match > the old > ones. If the parameters were subject to lease expiration, this would be an > expected part of the lifecycle of the protocol and would probably merit > discussion. But, if they aren't subject to expiration, then I think it's > OK as > it stands. > > ## NITS > > ### Appendix B > > It looks like this should really be A.1, not a new major heading/appendix > of > its own, probably a glitch in your document source? > > correct I missed a # > ### Appendix B.2 > > Where you say "CE router" do you really mean "CPE router"? > > yes changed. > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
o. s/detaille din/detailed in/
>
> changed from previous comment
> ** Section 3. Editorial. Make clear this is a statement about the
> example.
>
> OLD
> The Public Homenet Zone is identified by the Registered Homenet
>Domain Name - myhome.example.
>
> NEW
> In this example, the Public Homenet Zone is identified by the Registered
> Homenet Domain Name - myhome.example.
>
> changed
> ** Section 3
>
> the HNA communicates and
>synchronizes it with the DOI using a primary/secondary setting as
>described in Figure 1.
>
> I understand the intent of the text and who is operating as the primary and
> secondary from it. However, I don’t see how Figure 1 reflects the primary
> and
> secondary configuration.
>
> we added primary and secondary
> ** Section 3. Editorial. The term “hidden primary” is not in used in
> RFC8499.
> I believe the term there is “hidden master” which we stopped using for
> inclusive language reasons. Cite Section 6 or provide bridging text
> between
> the old and new term.
>
> we changed to hidden master (now designated as hidden primary)
{{?RFC8499}}
** Section 3. Typo. Missing close parentheses. s/ one or more
> Distribution
> Channels (Section 6 that/one or more Distribution Channels (Section 6)
> that/
>
> addressed form previous comment
> ** Section 3.2.
> The visible NS records
> SHOULD remain pointing at the cloud provider's server IP address.
>
> Who is the cloud provider in Figure 1? Is cloud provide the DOI? If so,
> please use consistent terminology in the normative language.
>
> changed to DOI's Public Authoritative Servers' IP address
** Section 4.5. s/any any/
>
> changed
> ** Section 10. Typo. s/The remaining of the/The remainder of this/
>
> change din a previous commnent
> ** Section 11.
>
> The Public Homenet Zone lists the names of services hosted in the
>home network. Combined with blocking of AXFR queries, the use of
>NSEC3 [RFC5155] ...
>
> Thanks for calling out that NSEC3 provides some mitigation for zone
> enumeration. Since it’s use is not mandatory (only RECOMMENDED), please
> explicitly state the consequence of it NOT being used (i.e., an enumerated
> list
> of services on your internal network).
>
> I have the impression the current text already address your concern in the
> Privacy
Considerations. Let me know if anything needs to be added.
Combined with blocking of AXFR queries, the use of NSEC3 {{!RFC5155}} (vs
NSEC {{!RFC4034}}) prevents an attacker from being able to walk the zone,
to discover all the names.
Section 12.2. The analysis in this section seems to be focused on IPv6
> addresses. Section 1.1. seems to allow for IPv4. Please reflect that.
>
> This is correct, initially homenet was only IPv6 and the described
mechanism was extended to IPv4.
we added:
IPv4 Addresses are 4 bytes long leading to 2**32 possibilities.
With IPv6 addresses, the Interface
> ** Missing Operational Considerations.
>
> HomeNet technologies makes it easier to expose devices and services to the
> Internet. This imposes broader operational considerations for the
> operator and
> the Internet:
>
> -- The home network operator must carefully assess whether a device or
> service
> previously fielded only on a home network is robust enough to be exposed
> to the
> Internet
>
> -- The home network operator will need to increase the diligence to
> regularly
> managing these exposed devices due to their increased risk posture of being
> exposed to the Internet
>
> -- Depending on the operational practices of the home network operators,
> there
> is an increased risk to the Internet architecture through the possible
> introduction of additional internet-exposed system that are poorly managed
> and
> likely to be compromised. Carriers may not to deployed additional
> mitigations
> to ensure that attacks do not originate from their networks.
>
>
> Thank you very much, I added an Operational considerations section.
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [dnsdir] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Hi Tim, Thanks for the suggestion. This represents a good compromise I think to the comments regarding the length of the introduction as well as considering the history of the document. Yours, Daniel On Mon, Oct 17, 2022 at 4:40 PM Tim Wicinski wrote: > > > On Thu, Oct 13, 2022 at 9:48 AM Michael Richardson via dnsdir < > dns...@ietf.org> wrote: > >> >> as> Reviewer: Anthony Somerset >> as> Review result: Ready with Nits >> >> as> Section 3.2 = "SHOULD remain pointing at the cloud provider's >> server IP address >> as> - which in many cases will be an anycast addresses." >> >> as> I don't believe its correct to include this assumption about >> anycast addresses >> as> and is largely irrelevant to the content of the draft so i don't >> believe there >> as> is value in keeping the text after the hyphen >> >> I see your point. >> I feel that there is some relevance to pointing this out. >> >> One of important aspect of reminding people about this is to indicate >> that it >> should be surprising if queries to these addresses actually return >> different >> time views of the zone. It can take some minutes for all anycast hosts to >> update. >> >> A second important aspect is that the address that queries go to is not, >> because of anycast, the same as the place where the updates go. >> >> I don't feel strongly about this, I just think that we wrote this down >> for a reason. >> >> > The intro is very long and talks about things that don't get >> explained until >> > much later in document and could cause some confusion, it may be >> better to make >> > the intro more concise and move some of these aspects into the >> relevant >> > sections. >> >> It grew as a result of reviews. >> you are saying we overshot, sure. >> >> > Section 1.2 - to me this would flow better if it was its own >> section after the >> > solution is explained >> >> okay. >> >> > To second Anthony's comment about the Introduction being long I have to > concur. > The first part of the Introduction nicely lays out the document. > Could you do this: > > Introduction > Terminology > Selecting Names to Publish > Dynamic DNS Alternative solutions > > Envisioned deployment scenarios > > > Each of these sections seem solid enough to stand on their own > > I always like getting the terminology lined up right away so the reader > isn't reading ahead, but that is probably just me. > > tim > > (working on my dnsdir review also!) > > > > > >> -- >> Michael Richardson. o O ( IPv6 IøT consulting >> ) >>Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> -- >> dnsdir mailing list >> dns...@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsdir >> > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Hi Anthony, Thanks for the review. Please see my response in line. You can also find the commit associated to the comments here: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/2fcc1c1606b8fbaf2ff10505ad00fab2c020ddd9 Thanks for the review. Yours, Daniel On Wed, Oct 12, 2022 at 8:25 AM Anthony Somerset via Datatracker < nore...@ietf.org> wrote: > Reviewer: Anthony Somerset > Review result: Ready with Nits > > Hello > > 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 are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers > > I would suggest that we don't specifically mention the resiliency > comments but instead point readers to the relevant RFC which looks to be > RFC1034 Section 4.1 to be specific, this is because RFC1034 suggests the > requirement is MUST and not SHOULD so would otherwise appear to be > conflicting > > the sentence has been suppressed > Section 3.2 = "SHOULD remain pointing at the cloud provider's server IP > address > - which in many cases will be an anycast addresses." > > I don't believe its correct to include this assumption about anycast > addresses > and is largely irrelevant to the content of the draft so i don't believe > there > is value in keeping the text after the hyphen > > I agree this is out of scope of the document, but I find it illustrative, so I would prefer to keep this. > Other Editorial comments and NITs please feel free to ignore these. Please > note that these are not exhaustive. > > The intro is very long and talks about things that don't get explained > until > much later in document and could cause some confusion, it may be better to > make > the intro more concise and move some of these aspects into the relevant > sections. > > This is a recurrent comment I objected as these sections have been moved back and forth. That said, I believe Tim's proposal is a good compromise. I think that should address the concern regarding the length of the intro. Thanks. > Section 1.2 - to me this would flow better if it was its own section after > the > solution is explained > > NITs > > 1.1 2nd Para says that "the HNA would then collect the IPv6 address(es)" > but > following para says "A device or service may have Global Unicast Addresses > (GUA) (IPv6 [RFC3787] or IPv4)..." > > is the former a typo that accidentally excludes IPv4? and would it be > better to > say IPv6 and IPv4 addresses > > Initially the document was only considering IPv6 as Homenet only considers IPv6. On the other hand, the mechanism described is not restricted to IPv6 and so we have been considering IPv4. So this is a typo now - but we know were it comes from ;-) I changed this to IP addresses. 1.2 - "Dynamic Updates solution are not" possible typos? > should it be "Dynamic Update solutions are not" > > changed > 3.1 - Typo "Resolver as detaille din further details below." should be > "Resolver as detailed in further details below." > > changed from a previous comment from Matt I think. Just to let you know you may not see the change in your commit. > 4.5.1 > > this section initially talks about communicating with the DM (Distribution > Manager) via an AXFR but then refers to the DOI in the same context as a > responder but they are described as different components in glossary - > This > should probably be clarified > > I am wondering what can we add to clarify thi sin the glossary: DNS Outsourcing Infrastructure (DOI): : is the infrastructure responsible for receiving the Public Homenet Zone and publishing it on the Internet. It is mainly composed of a Distribution Manager and Public Authoritative Servers. > I think there would be merit in this going for security review > additionally. > My specific minor concerns about this is about the concept of having a DNS > service exposed to the internet on a CPE to enable the transmission of > data > between Homenet Naming Authority and Distribution Manager. > > I see this as being described in HNA DM channel in the security considerations section. I am wondering if there is anything we are missing. > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-front-end-naming-delegation-18
cult to read. Below I > have a > couple of editorial comments, and I think addressing those could improve > the > readability of the document. > > Major issues: N/A > > Minor issues: N/A > > Nits/editorial comments: > > Q1: > > In my opinion the Introduction section is too long, and goes into too many > details. There are also things which I don't think belong to the > Introduction. > > For example, I don't think the text in Section 1.1 belongs to the > Introduction, > and is not needed in order to get an overview of the mechanism. I think it > belongs to a separate section (perhaps an Appendix). The same applies to > Section 1.3. > > Similarly, Section 1.2 seems to talk about alternative solutions, before > the > solution in the draft has been clearly explained. I think it should be a > separate section, later in the document. > > Q2: > > It is quite difficult to get a picture of how the mechanism work. There > are no > examples, or step-by-step functionality/use-case descriptions. Also, > Section > 3.1 seems to be a mixture of architecture and functionality, which is a > little > confusing. > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
to an internal resource, while the > corresponding > external resources all start with 'Public' except in this case. So I would > expect the Homenet Reverse Zone to be the private zone matching home.arpa > containing RFC1918 and IPv6 ULA addresses, etc. > > changed > 3.1: s/detaille din/detailed in/ - in the final sentence of the first > paragraph. > > corrected > 3.1: "The DOI is also responsible for ensuring the DS record has been > updated > in the parent zone." - This statement is too authoritative, and conflicts > with > 4.2 which clarifies (correctly) that DS updates in the parent zone are > optional. I suggest removing this statement, or correcting it to somethign > like > "Depending on configuration, the DOI may also be responsible...". > > already updated ( see my previous comment) > 3.2: s/RECOMMENDED to use TLS with mutually authentication/RECOMMENDED to > use > TLS with mutual authentication/ - in the final sentence of the 2nd > paragraph. > > > done > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
clarity. > > 4: I find the format of this section confusing and hard to understand with > sections 4.1-4.4 describing the information to be conveyed, but not how it > is > conveyed, and then the message formats being described in 4.5. I suggest it > would be much clearer and more understandable to combine the details in > 4.5.x > with the earlier sections (e.g. put the AXFR details from 4.5.1 into 4.1, > and > the DNS update details from 4.5.2/4.5.3 into 4.2 and 4.3. > > 12: I wonder how protected the HNA actually is and whether more > exploration/discussion of the risks invovled is required here - in an IPv4 > use-case, the IP for the services published in the Public Homenet Zone is > highly likely to be the same IP with an open DNS port for the DM to > connect to > for XFR, and while the relationship in IPv6 is not as straightforward > given the > likely use of privacy addressing, etc it's not particularly hard to scan > the > enclosing /64 or beyond for an address with an open DNS port. > > Given the HNA is already opening a control connection to the DM, was > consideration given to re-using that connection (or a 2nd HNA initiated > connection to a different address if there is the need for different > servers in > the DM implementation between control/sync channesl) to prevent the need > for > opening any listening port on the HNA WAN addresses at all? > > > Nits (aka Ready with Nits): > > 1.1: This section is titled Selecting *Names* to Publish, but spends the > majority of its words actually discussing the nuances of which *addresses* > to > publish for the selected names. This section may be more accurately and > cleary > named to include address selection. > > 1.3: There is a missing word (scenarios) in the first sentence which I > think > needs to read: "A number of deployment *scenarios* ... > > 1.3.1: The example would be simpler and clearly if it just stated that the > vendor provisions each device with a TLS key pair and certificate matching > the > assigned name which are used for mutual authentication. The current > discussion of > 'proceeding to authentication' is confusing, as it's not a phrase I've > encoutered > before and implies to me that authentication is not completed using the > cert/keys, while the explanation about needing both names/keys for > regeneration > seems neither necessary or correct (any trusted key can be used to replace > itself, whether or not a certificate with name is also present). > > 1.3.2: I think it would be simpler and clearer if the example focused > solely on > establishing trust between DOI/HNA via the provision of credentials and > omitted > the speculation about verification of ownership that may or may not be > required, and seems like a very separate concern at a different level of > the > stack. > > 2. Clarification of some definitions > > Registered Homenet Domain: Given there can be multiple Public Homenet > Zones, > presumably there can also be multiple Registered Homenet Domains which > should > be stated here for clarity. > > Public Authoritative Servers: s/for the Homenet Domain/for the Registered > Homenet Domain/ - 'Homenet Domain' alone is not a defined term. > > Homenet Reverse Zone: Why is this not called the 'Public Homenet Reverse > Zone'? > Given the 'Homenet Zone' is private, and this is considered the reverse > for the > 'Public Homenet Zone' this seems like a confusing inconsistency. Every > other > term starting Homenet refers to an internal resource, while the > corresponding > external resources all start with 'Public' except in this case. So I would > expect the Homenet Reverse Zone to be the private zone matching home.arpa > containing RFC1918 and IPv6 ULA addresses, etc. > > 3.1: s/detaille din/detailed in/ - in the final sentence of the first > paragraph. > > 3.1: "The DOI is also responsible for ensuring the DS record has been > updated > in the parent zone." - This statement is too authoritative, and conflicts > with > 4.2 which clarifies (correctly) that DS updates in the parent zone are > optional. I suggest removing this statement, or correcting it to somethign > like > "Depending on configuration, the DOI may also be responsible...". > > 3.2: s/RECOMMENDED to use TLS with mutually authentication/RECOMMENDED to > use > TLS with mutual authentication/ - in the final sentence of the 2nd > paragraph. > > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-naming-architecture-dhc-options-21
Hi, Thanks for the review. So the reason we do not consider DOH is that DoH 8484 has been defined for communications between a client and a resolver while in our case TLS is used between two authoritative servers. This document focuses on communication between DNS clients (such as operating system stub resolvers) and recursive resolvers. I see your point regarding the standard. What we wanted to say is that the standard port is defined by a standard. The standard might be the standard defining the transport protocol - which is the case for DoT, or eventually by the DHCP option. The reason I do not like "standard action" is that in our case DoT there is no action to be taken - the standard is already there. On the other hand I did not like the current proposal either, so I changed to "a standard" and hope this addresses your concerns. Thanks for raising this. OLD: It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by standard. NEW: It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by a standard. Yours, Daniel On Fri, Oct 14, 2022 at 5:43 AM R. Gieben via Datatracker wrote: > Reviewer: R. Gieben > Review result: Ready with Nits > > A straight forward document specifying dhcpv6 options, had little trouble > reading it. Got a bit lost with acronyms though, i.e. forgetting what ORO > is > when nearing the end of the document. > > Any reason why DNS over HTTP (DoH, RFC 8484) isn't standardized in the same > document? > > A Nit (maybe): in section 4.2: "... defined by standard." -> "... defined > by > standard action" ? > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Opsdir telechat review of draft-ietf-homenet-naming-architecture-dhc-options-21
Thanks Al. That is what we understood and made the change in our local copy. I expect to publish it today or tomorrow. Yours, Daniel On Thu, Oct 6, 2022 at 1:09 PM Al Morton via Datatracker wrote: > Reviewer: Al Morton > Review result: Has Nits > > In Appendix A, the text says, "In this *section*..." It's more accurate to > say, "In this *Appendix*..." I tried to explain this in my previous review. > Hopefully this comment is clearer. > > There are likely other cases in Appendix B that need the same fix. > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Artart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21
Thanks Bron for the review, that is well appreciated. I like your suggestion and we will check with the RFC Editor and IANA what is the best way to handle this and avoid repeating the values assigned by IANA. Yours, Daniel On Wed, Oct 5, 2022 at 2:39 AM Bron Gondwana via Datatracker < nore...@ietf.org> wrote: > Reviewer: Bron Gondwana > Review result: Ready with Nits > > Thanks to the authors for this, and apologies for a slightly delayed > review. > > I read this document and skim-read the linked > draft-ietf-homenet-front-end-naming-delegation which describes why these > fields > might want to be provided by DHCPv6. > > I found this document clear and easy to read - there were no nits that > stood > out to me other than the double-definition of the "Supported Transport" > field. > While there is a chicken-and-egg problem, the RFC editor and IANA could be > instructed to link things up such that section 4 immediately named the > registry > to look up the values in rather than hard-coding an initial table into this > document, and having future readers reach this section without finding the > pointer to IANA in the natural place. > > Likewise once the values are assigned by IANA for the DHCP option codes, > putting them directly into this document in the spots where a reader would > naturally be looking would help implementations. > > Overall - this document has a very long history - well done for sticking > with > it. I hope one day to buy a product which uses the end result of this > work and > transparently configures MY home network! > > > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-front-end-naming-delegation-18
Hi Christer, Thanks for the review. I do agree with you the introduction is taken as a whole quite long. Its current structure resulted from (multiple) discussions where we have been told to clarify some upcoming questions many people in the group would come up with and needed to be clarified. This is why we do have a short introduction text that is followed by some more specific subsections. I do not necessarily disagree with you saying these sections could be in appendices. We tried and moved them back and forth from the very beginning of the draft to the very end. As a result, unless you have a strong feeling against the current structure, I would be inclined to leave it as it is. To address your second point, I can think of adding a figure with maybe one sentence in the introduction after the following text: This document describes how a Homenet Naming Authority (HNA) can instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public Homenet Zone on its behalf. Would this address your concern or do you have something more specific in mind ? Given the length of the document I would like to avoid adding any new section. Yours, Daniel On Tue, Oct 4, 2022 at 6:19 AM Christer Holmberg via Datatracker < nore...@ietf.org> wrote: > Reviewer: Christer Holmberg > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-homenet-front-end-naming-delegation-18 > Reviewer: Christer Holmberg > Review Date: 2022-10-04 > IETF LC End Date: 2022-10-04 > IESG Telechat date: 2022-10-20 > > Summary: > > Since the topic is outside the area of my expertise, I have no technical > comments. I do think the document is a little difficult to read. Below I > have a > couple of editorial comments, and I think addressing those could improve > the > readability of the document. > > Major issues: N/A > > Minor issues: N/A > > Nits/editorial comments: > > Q1: > > In my opinion the Introduction section is too long, and goes into too many > details. There are also things which I don't think belong to the > Introduction. > > For example, I don't think the text in Section 1.1 belongs to the > Introduction, > and is not needed in order to get an overview of the mechanism. I think it > belongs to a separate section (perhaps an Appendix). The same applies to > Section 1.3. > > Similarly, Section 1.2 seems to talk about alternative solutions, before > the > solution in the draft has been clearly explained. I think it should be a > separate section, later in the document. > > Q2: > > It is quite difficult to get a picture of how the mechanism work. There > are no > examples, or step-by-step functionality/use-case descriptions. Also, > Section > 3.1 seems to be a mixture of architecture and functionality, which is a > little > confusing. > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Opsdir last call review of draft-ietf-homenet-naming-architecture-dhc-options-20
Hi Al, Thanks for the review. We replaced the section by appendix. Actually we did not move the sections to the appendix and these have always been appendices - despite we called them sections. The reason to have them as appendices is that these are not describing the protocol. On the other hand, we have discussed having a separate companion document that contains the appendices. However, we are currently staying with the appendices at least for now. The changes can be seen on the git repo: https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/1e7e2d50ec554d64ebf7bca8ea4b08b33e24cfe3 Yours, Daniel On Wed, Sep 28, 2022 at 4:36 PM Al Morton via Datatracker wrote: > Reviewer: Al Morton > Review result: Ready > > >From the draft: > This document defines DHCPv6 options so an Homenet Naming Authority (HNA) > can > automatically proceed to the appropriate configuration and outsource the > authoritative naming service for the home network. In most cases, the > outsourcing mechanism is transparent for the end user. The document > describes > how a network can provision the HNA with a specific DOI. This could be > particularly useful for a DOI partly managed by an ISP, or to make home > networks resilient to HNA replacement. The ISP delegates an IP prefix to > the > home network as well as the associated reverse zone. It appears that the > document accomplishes these goals (although I'm not an expert in homenet > topics). The Shepherd's form says that this and a companion draft are the > last > items to complete before closing homenet (interest is waning). The protocol > details seem to be well-considered. > > It appears that the Scenarios were moved to Appendices, rather than as > normative section and subsections: > > Appendix A. Scenarios and impact on the End User > > This *section* details various scenarios and discuss their impact on > the > end user. This section is not normative and limits the description of a > limited scope of scenarios that are assumed to be representative. Many > other scenarios may be derived from these. > > s/section/Appendix/g and other fixes. > > > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21
Hi Ines,
Thanks for the reviews. We can of course include 7227 and I added the
reference as follows:
This section details the payload of the DHCPv6 options following the
guidelines of {
{?RFC7227}}.
Regarding your second comment, I think what we meant is that the trust
associated with the information obtained via the DHCP option described in
this document is similar to the trust associated with the IP prefix. I
think the texte might be clearer saying:
OLD:
The use of DHCPv6 options provides a similar level of trust as
the one used to provide the IP prefix
NEW:
The trust associated with the information carried by the DHCPv6 Options
described in this document is similar to the one associated with the IP
prefix - when configured via DHCPv6.
The changes can be seen on github:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/blob/master/draft-ietf-homenet-naming-architecture-dhc-options.md
Yours,
Daniel
On Tue, Oct 4, 2022 at 12:58 PM Ines Robles via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Ines Robles
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-homenet-naming-architecture-dhc-options-??
> Reviewer: Ines Robles
> Review Date: 2022-10-04
> IETF LC End Date: 2022-10-04
> IESG Telechat date: 2022-10-20
>
> Summary:
>
> This document defines DHCPv6 options so an Homenet Naming Authority (HNA)
> can
> automatically proceed to the appropriate configuration and outsource the
> authoritative naming service for the home network.
>
> The document is well written and easy to understand.
>
> I have two minor questions as nits.
>
> Major issues: None
> Minor issues: None
> Nits/editorial comments/Questions:
>
> 1- Have you consider in this document RFC 7227- Guidelines for Creating New
> DHCPv6 Options -? If yes, should it be added in the references? If not, why
> not? 2- Page 9: "The use of DHCPv6 options provides a similar level of
> trust as
> the one used to provide the IP prefix." In which features are similar? In
> which
> features are dissimilar?
>
> Thanks for this document,
>
> Ines.
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Just posted the 19 - usually I have one line per sentence... but not in that case ;-) I suspect we did not address all your concerns for the draft-ietf-homenet-front-end-naming-delegation but we are waiting for your feedbacks to see what else needs to be addressed. Thank you for the follow up! Yours, Daniel On Tue, Sep 20, 2022 at 9:30 AM Eric Vyncke (evyncke) wrote: > Merci Daniel, > > > > By looking at the diff -17-18, you have addressed all my concerns > > > > It would be ready for IETF Last Call, but you were too energetic when > removing the last sentence of section 6.2, you have actually removed the > whole paragraph and the IANA registry must have a registration policy. > So, we need to keep > > > > "Future code points are assigned under RFC Required as per [RFC8126]." > > > > Regards > > > > -éric-waiting-for-19 ;-) > > > > Also waiting for the revision of > draft-ietf-homenet-front-end-naming-delegation-17 as my plan is to group > the two I-D for the last call > > > > *From: *Daniel Migault > *Date: *Tuesday, 20 September 2022 at 15:05 > *To: *Eric Vyncke > *Cc: *"ralf.we...@akamai.com" , " > tomasz.mrugal...@gmail.com" , Stephen Farrell > , "homenet@ietf.org" > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > Hi, > > > > I just submitted version 18. All comments have been addressed except > moving the appendices to a companion document. I would be a bit hesitant to > start a full process of adoption, last call while this can be shipped in an > appendix. If that is not the case and there is a strong incentive toward > having a companion document we can easily publish such a document. > > > > Yours, > > Daniel > > > > On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke) > wrote: > > Daniel, Ralf, Tomek, > > > > Thank you for posting the -17 revision. > > > > Before requesting the IETF Last Call, I kindly request one small changes > in -17 in the IANA section + a couple of minor suggestions that can be > ignored, see below for EV> > > > > Stephen, as the doc shepherd, would you mind explaining why "PS" is the > right intended status? > > > > We can aim to request the Last Call still this week if this I-D and the > architecture revised I-Ds are quickly posted. > > > > Regards > > > > -éric > > > > > > *From: *homenet on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Friday, 12 August 2022 at 02:04 > *To: *"Eric Vyncke (evyncke)" > *Cc: *"homenet@ietf.org" > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > Hi Eric, > > > > Thank you for the review. Please find inline how we addressed your > comments. > > > > You can also find the change on github on the link below: > > > https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662 > > > > I will also send the IANA section for additional review to the IANA. > > > > Yours, > Daniel > > > > On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote: > > As usual, I do my own review before requesting the IETF Last Call for all > documents. The intent is to give another polishing pass on the I-D. > > > > For this review, the MD format is used. > > > > Hope this helps > > > > Regards > > > > -éric > > > > > > # Éric Vyncke, INT AD, comments for > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > CC @evyncke > > > > Thank you for the work put into this document. > > > > Please find below some blocking DISCUSS points, some non-blocking COMMENT > points (but replies would be appreciated even if only for my own education). > > > > Special thanks to Stephen Farrel for the shepherd's detailed write-up > including the WG consensus, *but* it lacks the justification of the > intended status (and the WGLC was extended to the DHC WG). > > > > I hope that this review helps to improve the document, > > > > Regards, > > > > -éric > > > > > > ## DISCUSS > > > > ### Section 4.2 port ? > > > > The DHCP option does not allow to run DoT over a non-standard port. Or if > another transport is defined without an associated default port, then there > is no way to specify a port. > > > > That is correct, the rationale was to min
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Hi,
I just submitted version 18. All comments have been addressed except moving
the appendices to a companion document. I would be a bit hesitant to start
a full process of adoption, last call while this can be shipped in an
appendix. If that is not the case and there is a strong incentive toward
having a companion document we can easily publish such a document.
Yours,
Daniel
On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke)
wrote:
> Daniel, Ralf, Tomek,
>
>
>
> Thank you for posting the -17 revision.
>
>
>
> Before requesting the IETF Last Call, I kindly request one small changes
> in -17 in the IANA section + a couple of minor suggestions that can be
> ignored, see below for EV>
>
>
>
> Stephen, as the doc shepherd, would you mind explaining why "PS" is the
> right intended status?
>
>
>
> We can aim to request the Last Call still this week if this I-D and the
> architecture revised I-Ds are quickly posted.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From: *homenet on behalf of Daniel Migault <
> mglt.i...@gmail.com>
> *Date: *Friday, 12 August 2022 at 02:04
> *To: *"Eric Vyncke (evyncke)"
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> Hi Eric,
>
>
>
> Thank you for the review. Please find inline how we addressed your
> comments.
>
>
>
> You can also find the change on github on the link below:
>
>
> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662
>
>
>
> I will also send the IANA section for additional review to the IANA.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document.
>
>
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points (but replies would be appreciated even if only for my own education).
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status (and the WGLC was extended to the DHC WG).
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> ## DISCUSS
>
>
>
> ### Section 4.2 port ?
>
>
>
> The DHCP option does not allow to run DoT over a non-standard port. Or if
> another transport is defined without an associated default port, then there
> is no way to specify a port.
>
>
>
> That is correct, the rationale was to minimize the number of arguments and
> reduce the complexity of handling the DHCP Option. If we would consider
> adding ports, these should be added to every supported transport. This
> would move the Supported Transport field being a list of ( transport, port
> ). While not technically infeasible, that seemed to introduce too much
> complexity with regard to using a dedicated IP address for the DM.
>
> If the DM really needs to use another port one may think of storing such
> information in the DNS.
>
>
>
> EV> it would have been nice to have some text explaining this reasoning.
> Up to the authors to decide whether it is worth adding it.
>
> ### Section 6 registry
>
>
>
> s/IANA is requested to maintain a new number space/IANA is requested to
> create a new registry/
>
>
>
> done
>
> Also follow RFC 8126 section 1.3 (and others) by notably adding a
> description, the parent grouping (DHC I guess)
>
>
>
> The sub section has been updated as follows:
>
>
> ## Supported Transport parameter
>
> IANA is requested to maintain a new registry of Supported Transport
> parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the
> Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The
> different parameters are defined in {{tab-st}} in {{sec-st}}.
>
> The Name of the registry is: Supported Transport parameter
>
> The registry description is: The Supported Transport field of the DHCPv6
> option i
Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16
Hi Eric,
Thanks for the clarification. I have reduced the list normative reference
by 10 items as shown in the PR [1].
Yours,
Daniel
[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/53/commits/5ce7aa5a82f253ab62ca27fe8a45f0206fc577d3#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5
On Thu, Aug 11, 2022 at 7:38 AM Eric Vyncke (evyncke)
wrote:
> [2nd attempt as O365 has rejected my first reply...]
>
>
>
> Hello Daniel,
>
>
>
> Thanks for the changes except for the references, the goal of the
> normative/informative is not ‘to pass the id-nits’ examination but rather
> to give the readers the list of what they MUST read to implement
> (normative) and the list of useful links to understand (informative)
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> PS: going in vacation mode for one week...
>
>
>
> *From: *Daniel Migault
> *Date: *Wednesday, 10 August 2022 at 18:00
> *To: *Eric Vyncke
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Eric,
>
>
>
> Thanks for the response. Just to follow-up on the latest comments
>
>
>
> On Tue, Aug 9, 2022 at 2:11 AM Eric Vyncke (evyncke)
> wrote:
>
> Hello Daniel,
>
>
>
> Thank you for the quick reply. I had a quick browse through the commit and
> it seems that some points are yet to be addressed:
>
>- List of normative references [1]
>
> Currently we set the normative and informational references so it passes
> the checks. As a result any standard track reference is moved to the
> normative section and informational references are moved to the informative
> section. . I am wondering if you are requesting that we only keep the
> essential normative references in the normative sections - that is the
> references that are mandatory to be considered. If that is the case, this
> could lead to a standard track reference being moved to the informative
> section. Before we proceed to the changes, we just would like to make
> sure this is what is expected.
>
>
>
>
>- RFC 7404 is not specifying LLA ;-)
>
> This is correct but it explains how to use them. We updated LLA
> references for IPv4/IPv6 as follows:
>
>
>
> A device or service may have Global Unicast Addresses (GUA) (IPv6
> {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as
> as well IPv6-Link-Local addresses{{!RFC4291}}{{!RFC7404}}, IPv4-Link-Local
> Addresses {{!RFC3927}} (LLA), and private IPv4 addresses {{!RFC1918}}.
>
>
>- s/ as as well/as well as/ ?
>
> changed
>
>
>-
>- no justification for ‘one to three’ in section 1.2, simply remove
>those words
>
> The justification we added was a plausible list of instances, but we are
> fine removing it.
>
> OLD:
>
> For a very few numbers (one to three) of hosts (media servers, VPN
> gateways, ... ),
>
> NEW:
>
> For a very few numbers of hosts,
>
>
>-
>
>
>
> Yours,
>
> Daniel
>
> Please continue the good work
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> [1] I am sure that you know
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
>
> *From: *Daniel Migault
> *Date: *Tuesday, 9 August 2022 at 04:21
> *To: *Eric Vyncke
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Erik,
>
>
>
> Thanks for the careful review. That is really much appreciated. We have
> addressed most of the changes in line as well as here:
>
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729
>
>
>
> There is one remaining change we need to make, and I hope we will be able
> to submit a new version in the coming days. Feel free to let us know if the
> changes are addressing your concerns.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-front-end-naming-delegation-16
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document. Multiple nits and typos are
> identified in the end of th
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
nd
> is unclear without this context. Suggest to remove this word.
>
>
>
removed
>
>
> ### Section 2 DOI
>
>
>
> Isn't it 'DNS Outsourcing Infrastructure' ?
>
correct and changed
>
>
> ### Section 2 DOI or DM ?
>
>
>
> ```
>
>This document describes how a network can provision the HNA with a
>
>specific DOI.
>
> ```
>
> Is it DOI or DM?
>
Both can be used. The DM is a specific entity while DOI is a bit more
abstract. As this is the second sentence where we just described DOI, it
might be clearer for the reader to keep DOI - in my opinion.
>
>
> ### Section CE or CPE
>
>
>
> Please use CPE to be consistent with the companion document.
>
>
>
changed
> ### Section 4.2 option name
>
>
>
> By consistency with section 4.3, should this be
> OPTION_FORWARD_DIST_MANAGER ?
>
The rational was to have forward as default, but we can change that to
remain fair with the reverse dm. Let us know your thoughts.
>
>
> ### Section 4.2 FQDN
>
>
>
> Some explanations about the use of a FQDN vs. IP addresses would be
> welcome.
>
>
>
We added the following text:
However, the use of a FQDN provides multiple advantages over IP addresses.
Firstly, it makes the DHCPv6 Option easier to parse and smaller -
especially when IPv4 and IPv6 addresses are expected to be provided.
Then the FQDN can reasonably be seen as a more stable identifier as well as
a pointer to additional information than the IP addresses may be useful to
in the future to establish the communication between the HNA and the DM.
### Section 4.2.1 flow
>
>
>
> As this section is also used by section 4.3, suggestion to move it after
> section 4.3 as section 4.4
>
>
>
moved
> ### Section 6 spec required
>
>
>
> I am concerned that 'spec required' is enough for such a 16-bit flags
> field. Should it be 'RFC required' ?
>
>
>
I am not too worried, but I am fine using the RFC required. Given the
reduced space this might be safer.
> ### References
>
>
>
> Unsure whether ietf-homenet-front-end-naming-delegation is normative, it
> is rather informative. Same for RFC 9103 and RFC 7858
>
>
>
I moved these references as informative. Regarding the status for
ietf-homenet. For the DHCP option itself, this is correct information is
probably right but to use the DHCP option this might lean toward
normative.
> ### App B
>
>
>
> The 1st and 3rd paragraph are quite repetitive.
>
>
>
The 1-3 paragraphs have been changed as follows:
OLD:
This section considers the case when the end user wants its home
network to use example.com not managed by her ISP (foo) as a
Registered Homenet Domain. This section still consider the ISP
manages the home network and still provides example.foo as a
Registered Homenet Domain.
When the end user buys the domain name example.com, it may request to
redirect the name example.com to example.foo using static redirection
with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com
is registered. The only information the end user needs to know is
the domain name assigned by the ISP. Once this configuration is done
no additional configuration is needed anymore. More specifically,
the HNA may be changed, the zone can be updated as in Appendix B
without any additional configuration from the end user.
NEW:
This section considers the case when the end user wants its home network
to use example.com not managed by her ISP (foo) as a Registered Homenet
Domain.
This section still considers the ISP manages the home network and still
provides foo.example as a Registered Homenet Domain.
When the end user buys the domain name example.com, it may request to
redirect the name example.com to foo.example using static redirection with
CNAME {{?RFC2181}}, {{?RFC1034}}, DNAME {{?RFC6672}} or CNAME+DNAME
{{?I-D.sury-dnsext-cname-dname}}.
The only information the end user needs to know is the domain name assigned
by the ISP.
Once the redirection has been configured, the HNA may be changed, the zone
can be updated as in {{sec-scenario-1}} without any additional
configuration from the end user.
>
> ### Appendix, why here ?
>
>
>
> There is little DHCP-related content in the appendix and the scenario
> would probably be more useful in the companion document.
>
The purpose of the appendix was to show that these DHCP option cannot be
used by an ISP to prevent users from using their own registered domain
names. I do not think that better fits the companion document which
describes the architecture and protocols to outsource the DNS zone. These
appendixes are focused on what can be done when the ISP provides an
outsourcing service.
>
>
> ## Notes
>
>
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
>
> [`ietf-comments` tool][ICT] to automatically convert this review into
>
> individual GitHub issues.
>
>
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>
> [ICT]: https://github.com/mnot/ietf-comments
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16
Thank you very much for the clarification!
Yours,
Daniel
On Thu, Aug 11, 2022 at 7:38 AM Eric Vyncke (evyncke)
wrote:
> [2nd attempt as O365 has rejected my first reply...]
>
>
>
> Hello Daniel,
>
>
>
> Thanks for the changes except for the references, the goal of the
> normative/informative is not ‘to pass the id-nits’ examination but rather
> to give the readers the list of what they MUST read to implement
> (normative) and the list of useful links to understand (informative)
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> PS: going in vacation mode for one week...
>
>
>
> *From: *Daniel Migault
> *Date: *Wednesday, 10 August 2022 at 18:00
> *To: *Eric Vyncke
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Eric,
>
>
>
> Thanks for the response. Just to follow-up on the latest comments
>
>
>
> On Tue, Aug 9, 2022 at 2:11 AM Eric Vyncke (evyncke)
> wrote:
>
> Hello Daniel,
>
>
>
> Thank you for the quick reply. I had a quick browse through the commit and
> it seems that some points are yet to be addressed:
>
>- List of normative references [1]
>
> Currently we set the normative and informational references so it passes
> the checks. As a result any standard track reference is moved to the
> normative section and informational references are moved to the informative
> section. . I am wondering if you are requesting that we only keep the
> essential normative references in the normative sections - that is the
> references that are mandatory to be considered. If that is the case, this
> could lead to a standard track reference being moved to the informative
> section. Before we proceed to the changes, we just would like to make
> sure this is what is expected.
>
>
>
>
>- RFC 7404 is not specifying LLA ;-)
>
> This is correct but it explains how to use them. We updated LLA
> references for IPv4/IPv6 as follows:
>
>
>
> A device or service may have Global Unicast Addresses (GUA) (IPv6
> {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as
> as well IPv6-Link-Local addresses{{!RFC4291}}{{!RFC7404}}, IPv4-Link-Local
> Addresses {{!RFC3927}} (LLA), and private IPv4 addresses {{!RFC1918}}.
>
>
>- s/ as as well/as well as/ ?
>
> changed
>
>
>-
>- no justification for ‘one to three’ in section 1.2, simply remove
>those words
>
> The justification we added was a plausible list of instances, but we are
> fine removing it.
>
> OLD:
>
> For a very few numbers (one to three) of hosts (media servers, VPN
> gateways, ... ),
>
> NEW:
>
> For a very few numbers of hosts,
>
>
>-
>
>
>
> Yours,
>
> Daniel
>
> Please continue the good work
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> [1] I am sure that you know
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
>
> *From: *Daniel Migault
> *Date: *Tuesday, 9 August 2022 at 04:21
> *To: *Eric Vyncke
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Erik,
>
>
>
> Thanks for the careful review. That is really much appreciated. We have
> addressed most of the changes in line as well as here:
>
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729
>
>
>
> There is one remaining change we need to make, and I hope we will be able
> to submit a new version in the coming days. Feel free to let us know if the
> changes are addressing your concerns.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-front-end-naming-delegation-16
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document. Multiple nits and typos are
> identified in the end of this review, I would have expected a document that
> has been through spell and grammar checkers.
>
>
>
> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only
>
Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16
Hi Eric,
Thanks for the response. Just to follow-up on the latest comments
On Tue, Aug 9, 2022 at 2:11 AM Eric Vyncke (evyncke)
wrote:
> Hello Daniel,
>
>
>
> Thank you for the quick reply. I had a quick browse through the commit and
> it seems that some points are yet to be addressed:
>
>- List of normative references [1]
>
> Currently we set the normative and informational references so it passes
the checks. As a result any standard track reference is moved to the
normative section and informational references are moved to the informative
section. . I am wondering if you are requesting that we only keep the
essential normative references in the normative sections - that is the
references that are mandatory to be considered. If that is the case, this
could lead to a standard track reference being moved to the informative
section. Before we proceed to the changes, we just would like to make
sure this is what is expected.
>- RFC 7404 is not specifying LLA ;-)
>
> This is correct but it explains how to use them. We updated LLA
references for IPv4/IPv6 as follows:
A device or service may have Global Unicast Addresses (GUA) (IPv6
{{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as
as well IPv6-Link-Local addresses{{!RFC4291}}{{!RFC7404}}, IPv4-Link-Local
Addresses {{!RFC3927}} (LLA), and private IPv4 addresses {{!RFC1918}}.
>
>- s/ as as well/as well as/ ?
>
> changed
>
>-
>- no justification for ‘one to three’ in section 1.2, simply remove
>those words
>
> The justification we added was a plausible list of instances, but we are
fine removing it.
OLD:
For a very few numbers (one to three) of hosts (media servers, VPN
gateways, ... ),
NEW:
For a very few numbers of hosts,
>
>-
>
>
>
Yours,
Daniel
> Please continue the good work
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> [1] I am sure that you know
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
>
> *From: *Daniel Migault
> *Date: *Tuesday, 9 August 2022 at 04:21
> *To: *Eric Vyncke
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-front-end-naming-delegation-16
>
>
>
> Hi Erik,
>
>
>
> Thanks for the careful review. That is really much appreciated. We have
> addressed most of the changes in line as well as here:
>
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729
>
>
>
> There is one remaining change we need to make, and I hope we will be able
> to submit a new version in the coming days. Feel free to let us know if the
> changes are addressing your concerns.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-front-end-naming-delegation-16
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document. Multiple nits and typos are
> identified in the end of this review, I would have expected a document that
> has been through spell and grammar checkers.
>
>
>
> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only
> for my own education), and some nits.
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status.
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
> ## DISCUSS
>
>
>
> ### id-nits, references to be updated
>
>
>
> Please have a look at
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-16.txt
> and address the updated references.
>
>
>
> ### id-nits, downref
>
>
>
> As noted by Stephen in his review (and I second his proposal), several
> normative references should probably "just" informative.
>
>
>
> downref have been moved to informative
>
> ### HNA certs
>
>
>
> >From my reading of the text, it is really unclear whether HNA certs are /
> may be self-signed and what the subject alt name is (IP address ? FQDN ?
> other).
&g
Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16
rge that reverse > >zone may be confronted with scalability issues. > > ``` > > > The reverse zone associated to ::/64 can be non trivial to manage especially when very few IPs are effectively being used. I suspect the wording is unclear and propose to replace it as follows: With IPv6, the reverse domain space for IP addresses associated to a subnet such as ::/64 is so large that reverse zone may be confronted with scalability issues. > ### Appendix A.2 > > > > s/RG router/CPE/ > > > ok > ### Appendix B > > > > Is not normative, then is it useful ? > > > > What is 'front-end protocol' ? > > > The front end protocol is the legacy name for the protocol described in this document. I think the section gives a good sense of how the HNA needs to be provisioned and configured, s I think that is important to have such a section. > ### Appendix B.1 > > > > Hmm a little unclear at first sight whether this section is explaining the > parameters of appendix B. > > agree the twp sections have been merged. > > > ### Appendix C > > > > Even if not normative, use cases are often described in the introduction > section. Consider moving this appendix in section 1. > > > moved as section 1.3 > ## NITS > > > > ### Abstract & section 1 > > > > s/needs/need/ > > > ok > ### Section 1.1 > > > > s/home network administrator (a human), will be presented with a list/home > network administrator, (a human being), will be presented with a list/ ? > > > ok > ### Section 1.2 > > > > s/For a very few number/For a very few numbers/ ? > > ok > > > ### Section 4.2 > > > > `so the that DOI`? how to parse this ? > > changed to: so the DOI > > > ### No comma before 'and' > > > > AFAIK, there is no comma before 'and', exception made for the Oxford comma > of course. > > > ok - works for me. > ### Section 4.2 > > > > s/were/was/ ? > > > I cannot find it in section 4.2 it might have been changed addressing a previous comment. > ### Section 4.5 > > > > s/long term session/long-term session/ > > > ok > ### Section 4.6 > > > > Unbalanced parenthesis. > > > ok > ### Section 4.7 > > > > s/describe din/described in/ > > ok > > > ### Section 5 > > > > Duplicate `toward a service a service` > > > ok > ### Section 6 > > > > s/is outside/are outside/ ? > > > ok > ### Non-empty well-known > > > > Several missing '-' in 'non-empty' and 'well-known' (when applicable). > > > ok > ### E.g. > > > > "E.g." should be enclosed in ','. > > > ok > ### Section 9 > > > > 'by by' ? > > ok > > > ### Section 10 > > > > s/privacy MAY be provide/privacy MAY be provided/ > > > ok > ### Section 11.1 > > > > `To ensure the multiple TLS session are are continuously authenticating ` > duplicated 'are' > > ok > > > s/This MAY Be handle by a off-line /This MAY be handled by an off-line/ > > > ok > ### DNS in uppercase > > > > There are a couple of 'dns' (lowercase) instances. > > > ok > ## Notes > > > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > > [`ietf-comments` tool][ICT] to automatically convert this review into > > individual GitHub issues. > > > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > > [ICT]: https://github.com/mnot/ietf-comments > > > > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-16.txt
Hi Erik, As far as I know, we have addressed all comments received during the WGLC for both drafts. In addition to what has been sent to the mailing list a brief overview of the changes can see the updates for the dhcp draft there: https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commits/master/draft-ietf-homenet-naming-architecture-dhc-options.md and for the hna draft the updates can be seen there: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commits/master/draft-ietf-homenet-front-end-naming-delegation.mkd Yours, Daniel On Wed, Jun 15, 2022 at 11:40 AM Eric Vyncke (evyncke) wrote: > Daniel, and other authors, > > > > Does this version address all comments received during the 2021 WG last > call [1] ? > > > > There is also a new version of the DHCP part, does this version also > address all comments received during the 2021 WG last call ? > > > > Thank you very much for the work done, I know that the last mile can be > very painful... > > > > Regards > > > > -éric > > > > [1] > https://mailarchive.ietf.org/arch/msg/homenet/2yussyqUPAFf9gKNFNGw43ywA_Y/ > > > > > > *From: *homenet on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Monday, 13 June 2022 at 11:07 > *To: *homenet > *Subject: *[homenet] Fwd: I-D Action: > draft-ietf-homenet-front-end-naming-delegation-16.txt > > > > Hi, > > > > Please find an update of the draft that describes the Provisioning of > Public Names for Residential Networks. We essentially, clarify the document > and move to the appendices the informative sections. We would like to thank > Kiran for all her comments that have led to the current version. We > believe this version addresses the comment regarding the readability of the > document. > > > > Yours, > Daniel > > > > -- Forwarded message - > From: > Date: Mon, Jun 13, 2022 at 12:55 PM > Subject: [homenet] I-D Action: > draft-ietf-homenet-front-end-naming-delegation-16.txt > To: > Cc: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Home Networking WG of the IETF. > > Title : Simple Provisioning of Public Names for > Residential Networks > Authors : Daniel Migault > Ralf Weber > Michael Richardson > Ray Hunter > Filename: > draft-ietf-homenet-front-end-naming-delegation-16.txt > Pages : 38 > Date: 2022-06-13 > > Abstract: >Home network owners often have devices that they wish to access >outside their home network - i.e., from the Internet using their >names. To do so, these names needs to be made publicly available in >the DNS. > >This document describes how a Homenet Naming Authority (HNA) can >instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public >Homenet Zone on its behalf. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-16 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-16 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-16.txt
Hi, Please find an update of the draft that describes the Provisioning of Public Names for Residential Networks. We essentially, clarify the document and move to the appendices the informative sections. We would like to thank Kiran for all her comments that have led to the current version. We believe this version addresses the comment regarding the readability of the document. Yours, Daniel -- Forwarded message - From: Date: Mon, Jun 13, 2022 at 12:55 PM Subject: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-16.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : Simple Provisioning of Public Names for Residential Networks Authors : Daniel Migault Ralf Weber Michael Richardson Ray Hunter Filename: draft-ietf-homenet-front-end-naming-delegation-16.txt Pages : 38 Date: 2022-06-13 Abstract: Home network owners often have devices that they wish to access outside their home network - i.e., from the Internet using their names. To do so, these names needs to be made publicly available in the DNS. This document describes how a Homenet Naming Authority (HNA) can instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public Homenet Zone on its behalf. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-16 Internet-Drafts are also available by rsync at rsync.ietf.org: :internet-drafts ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
Thank you very much for the feed backs. I will have a look at the comments today and should be able to implement them by early next week. Yours, Daniel On Thu, Jun 9, 2022 at 7:44 PM Kiran M wrote: > Hi Daniel, > > I finally managed to finish the review of front-end naming document. My > apologies for the delay. Many thanks for addressing the first round of > comments, the readability has improved quite a bit. The remainder of the > comments are in the Github. Hope we will see a revision soon. > > Cheers, > Kiran > > > ---------- > *From:* Daniel Migault [mailto:mglt.i...@gmail.com ] > *Sent:* Thursday, June 2, 2022, 6:36 AM > *To:* Eric Vyncke (evyncke) > *Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com; > Michael Richardson; Stephen Farrell > *Subject:* [homenet] naming drafts > > We are working on it with Kiran, I actually started yesterday to consider > her latest feedback (2nd round) - not yet being pushed, but that should > happen very soon. > > Yours, > Daniel > > On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) > wrote: > >> As we are halfway between IETF-113 and IETF-114, it is time to make a >> check as I have seen no revised version for those 2 ‘naming’ drafts. >> >> >> >> You may also have noticed that Ted’s ‘stub networking’ work is going in a >> SNAC BoF at IETF-114 (please attend and contribute to the s...@ietf.org >> mailing list). >> >> >> >> Therefore, the plan is to close Homenet early July 2022 if nothing >> changes. >> >> >> >> Hoping to see you in “Philly” to celebrate the achievments of Homenet ! >> >> >> >> Regards >> >> >> >> -éric >> >> >> >> *From: *homenet on behalf of "Eric Vyncke >> (evyncke)" >> *Date: *Thursday, 14 April 2022 at 09:16 >> *To: *"homenet@ietf.org" >> *Cc: *"kiran.i...@gmail.com" , Michael Richardson < >> mcr+i...@sandelman.ca>, Daniel Migault , Stephen >> Farrell >> *Subject: *Re: [homenet] naming drafts >> >> >> >> Dear Homenet, >> >> >> >> After 9 months, it is time to resurrect this email thread and move >> forward with the 'naming drafts', which are still in WG Last Call since May >> 2021: >> >> - draft-ietf-homenet-front-end-naming-delegation >> >> - draft-ietf-homenet-naming-architecture-dhc-options >> >> >> >> AT IETF-113, there was a meeting with two authors, the chairs, and I (as >> the responsible AD for Homenet). The plan is to give the authors a chance >> to issue a revised I-D considering Chris Blox's review as well as trying to >> improve the readability and flow of the text (which suffers from multiple >> revisions that have rendered the I-D difficult to read). Once done, the >> chairs will close the WGLC and will request publication to continue the >> process. This should be done by IETF-114 (July 2022) if not earlier. >> >> >> >> About the DynDNS discussion of last year, I am in favor of going forward >> anyway with the homenet drafts and wait for the IETF Last Call + IESG >> evaluation to get a broader scope than the Homenet WG on this very specific >> topic. >> >> >> >> Final point, the chairs and I have decided that once those 2 drafts have >> been approved by the IESG [1], then the Homenet WG can be closed after 11 >> years [2]. >> >> >> >> Of course, feedback and comments on the above are welcome. >> >> >> >> Regards >> >> >> >> -éric >> >> >> >> [1] or if the publication is not requested before IETF-114, then I will >> declare those two I-D as "dead" and proceed anyway with the closing of >> Homenet. >> >> [2] a new home will need to be found for Ted Lemon's drafts on "stub >> networking" >> >> >> >> *From: *homenet on behalf of Daniel Migault < >> mglt.i...@gmail.com> >> *Date: *Tuesday, 13 July 2021 at 23:28 >> *To: *Chris Box >> *Cc: *"homenet@ietf.org" >> *Subject: *Re: [homenet] naming drafts >> >> >> >> Hi, >> >> >> >> Thanks for the follow up Chris. I apologize for the delay. >> >> >> >> Yours, >> >> Daniel >> >> >> >> On Tue, Jun 22, 2021 at 12:31 PM Chris Box >> wrote: >> >> Daniel, >> >> >> >> On Wed, 16 Jun 2021 at 01:27, Daniel Migault wrote:
Re: [homenet] naming drafts
We are working on it with Kiran, I actually started yesterday to consider her latest feedback (2nd round) - not yet being pushed, but that should happen very soon. Yours, Daniel On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) wrote: > As we are halfway between IETF-113 and IETF-114, it is time to make a > check as I have seen no revised version for those 2 ‘naming’ drafts. > > > > You may also have noticed that Ted’s ‘stub networking’ work is going in a > SNAC BoF at IETF-114 (please attend and contribute to the s...@ietf.org > mailing list). > > > > Therefore, the plan is to close Homenet early July 2022 if nothing changes. > > > > Hoping to see you in “Philly” to celebrate the achievments of Homenet ! > > > > Regards > > > > -éric > > > > *From: *homenet on behalf of "Eric Vyncke > (evyncke)" > *Date: *Thursday, 14 April 2022 at 09:16 > *To: *"homenet@ietf.org" > *Cc: *"kiran.i...@gmail.com" , Michael Richardson < > mcr+i...@sandelman.ca>, Daniel Migault , Stephen > Farrell > *Subject: *Re: [homenet] naming drafts > > > > Dear Homenet, > > > > After 9 months, it is time to resurrect this email thread and move forward > with the 'naming drafts', which are still in WG Last Call since May 2021: > > - draft-ietf-homenet-front-end-naming-delegation > > - draft-ietf-homenet-naming-architecture-dhc-options > > > > AT IETF-113, there was a meeting with two authors, the chairs, and I (as > the responsible AD for Homenet). The plan is to give the authors a chance > to issue a revised I-D considering Chris Blox's review as well as trying to > improve the readability and flow of the text (which suffers from multiple > revisions that have rendered the I-D difficult to read). Once done, the > chairs will close the WGLC and will request publication to continue the > process. This should be done by IETF-114 (July 2022) if not earlier. > > > > About the DynDNS discussion of last year, I am in favor of going forward > anyway with the homenet drafts and wait for the IETF Last Call + IESG > evaluation to get a broader scope than the Homenet WG on this very specific > topic. > > > > Final point, the chairs and I have decided that once those 2 drafts have > been approved by the IESG [1], then the Homenet WG can be closed after 11 > years [2]. > > > > Of course, feedback and comments on the above are welcome. > > > > Regards > > > > -éric > > > > [1] or if the publication is not requested before IETF-114, then I will > declare those two I-D as "dead" and proceed anyway with the closing of > Homenet. > > [2] a new home will need to be found for Ted Lemon's drafts on "stub > networking" > > > > *From: *homenet on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Tuesday, 13 July 2021 at 23:28 > *To: *Chris Box > *Cc: *"homenet@ietf.org" > *Subject: *Re: [homenet] naming drafts > > > > Hi, > > > > Thanks for the follow up Chris. I apologize for the delay. > > > > Yours, > > Daniel > > > > On Tue, Jun 22, 2021 at 12:31 PM Chris Box > wrote: > > Daniel, > > > > On Wed, 16 Jun 2021 at 01:27, Daniel Migault wrote: > > > > The HNA SHOULD drop any packets arriving on the WAN interface that are > not issued from the DM. > > Depending how the communications between the HNA and the DM are secured, > only packets associated to that protocol SHOULD be allowed. > > > The separation looks good, but I'd like to tweak the second paragraph. By > "only packets associated to that protocol" do you mean destination port > filtering? > > > > To me IP and port filtering are implemented by the previous line. "only > packets associated with that protocol" to me means that only TLS packets > are allowed. The reason we are not mentioning TLS explicitly is that > other protocols may be used. > > > > Ah, I see, so this is about the payload of the packets. But surely > intelligent validation of the incoming packets is always going to happen? > This is a key property of any security protocol. > > If the DM is listening on TCP 443, and the incoming packet is not a TLS > Client Hello that it is happy with, it'll get ignored. > > If the DM is listening on UDP 500, and the incoming packet is not an > IKE_SA_INIT that it is happy with, it'll get ignored. > > > > So I'm not disagreeing with you, I'm just questioning whether the sentence > is needed. I don't really mind if it stays. > > This may not be necessary, but the reason I would pr
Re: [homenet] Looking for a Homenet co-chair
I also support that homenet work being made in homenet. It is unclear to me why we are looking at an alternate way to proceed. Yours, Daniel On Fri, Aug 27, 2021 at 7:05 AM Michael Richardson wrote: > > Michael Richardson wrote: > >> progress the stub networks draft because I've been too busy doing > >> dnssd work, but that would be an example. I'd really like to > progress > >> that draft /somewhere/, and it seems a /bit/ off-topic for dnssd. It > >> could go in v6ops, but it's pretty off-topic for v6ops. Same with > >> intarea. > > >> But of course the stub networks document isn't what Homenet set out > to > >> do. It's just a building block that might lead there. The original > >> work of homenet doesn't seem to have caught on in the market, and I > >> think it's because we didn't have an adoption strategy. Personally I > >> think stub networks is a good bottom-up beginning to a strategy that > >> could ultimately produce an adoptable version of what we originally > >> tried to do. But again, only if people here want to pursue that. > > > I thought that you *wanted* to go to INTAREA with this document. I > > agree that it's an important document. > > If we need to keep HOMENET open to do stub networks, then let's do that. > > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
Hi, Thanks for the follow up Chris. I apologize for the delay. Yours, Daniel On Tue, Jun 22, 2021 at 12:31 PM Chris Box wrote: > Daniel, > > On Wed, 16 Jun 2021 at 01:27, Daniel Migault wrote: > >> >>> The HNA SHOULD drop any packets arriving on the WAN interface that are >>>> not issued from the DM. >>>> >>>> >>>> Depending how the communications between the HNA and the DM are >>>> secured, only packets associated to that protocol SHOULD be allowed. >>>> >>>> >>> The separation looks good, but I'd like to tweak the second paragraph. >>> By "only packets associated to that protocol" do you mean destination port >>> filtering? >>> >> >> To me IP and port filtering are implemented by the previous line. "only >> packets associated with that protocol" to me means that only TLS packets >> are allowed. The reason we are not mentioning TLS explicitly is that >> other protocols may be used. >> > > Ah, I see, so this is about the payload of the packets. But surely > intelligent validation of the incoming packets is always going to happen? > This is a key property of any security protocol. > If the DM is listening on TCP 443, and the incoming packet is not a TLS > Client Hello that it is happy with, it'll get ignored. > If the DM is listening on UDP 500, and the incoming packet is not an > IKE_SA_INIT that it is happy with, it'll get ignored. > > So I'm not disagreeing with you, I'm just questioning whether the sentence > is needed. I don't really mind if it stays. > This may not be necessary, but the reason I would prefer to keep it is to head up that additional checks - when possible - may be performed in addition to port filtering. So unless you have a strong preference, I would prefer to keep this additional check that could be performed by the terminating node or a firewall. > > >> >>> I'm not concerned about the additional round trip. I was more concerned >>> that the DM could be implemented as a frontend/backend architecture. The >>> FQDN would resolve to the front end, and this is likely to be a small list >>> of addresses, or even a single address. But the backend servers would have >>> distinct, different addresses. Connections from the DM to the HNA might be >>> initiated from the backend. If the HNA only looked up the FQDN, it would >>> drop legitimate connections. This suggests we need a way to inform the HNA >>> of the set of legitimate source addresses. >>> >>> > What did you think of this last point? > I see your point. The architecture document envisioned this case by specifying the dm_acl parameter in the informative section 14. We did not include it into the DHCP option as we were requested to implement the simplest use case that is envisioned. My understanding was that DHCP Options had some history where complex options had been designed but hardly used. That said, if that is something you believe is really needed, we may bring this discussion and add this parameter to the current DHCP Options. It still represents a minor change as already considered in the architecture document. Another alternative may also consider adding an extension so the acl may be negotiated through the control channel, which I see more scalable than designing large DHCP options. At that point, I would rather keep the architecture as it is a let such option for future work - though fairly easy to set. > Chris > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
Hi Chris,
Thanks for the follow-up. Please find more details and specific responses
to your questions and comments below. I also just pushed the changes you
recommended for the DHCP options.
Thanks!
Yours,
Daniel
On Tue, Jun 15, 2021 at 1:10 PM Chris Box wrote:
> Hi Daniel. Responses inline below.
>
> On Tue, 15 Jun 2021 at 02:58, Daniel Migault wrote:
>
>>
>>>
>> """
>> Limited exchanges:
>> : the purpose of the Hidden Primary Server is to synchronize with the DM,
>> not to serve any zones to end users, or the public Internet.
>> This results in a limited exchanges (AXFR/IXFR) with a small number of IP
>> address and such limitations SHOULD be enforced by policies describe din
>> {{sec-cpe-sec-policies}}.
>> """
>>
>
> I'm happy with that.
>
>
>> 7 I'd prefer not to use the word "packets" when it's really messages that
>>> we considering. Also in my opinion invalid messages to/from the DM ought to
>>> be rejected rather than simply dropped.
>>>
>>> Here's my suggested version, with changes highlighted in red:
>>>The Hidden Primary SHOULD drop any packets arriving on
>>>the WAN interface that are not issued from the DM. The Hidden
>>>Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
>>>SOA response, IXFR response or AXFR responses. The Hidden Primary
>>>SHOULD reject any incoming messages other than DNS NOTIFY response,
>>> SOA
>>>query, IXFR query or AXFR query. The Hidden Primary SHOULD reject
>>> any
>>>non protected IXFR or AXFR exchange, depending on how the
>>>synchronization is secured.
>>>
>>>
>> My interpretation between drop and reject is that drop does not provide
>> any response and acts as if the service does not exist while reject allows
>> responding with an error which in this case indicates the service exists
>> and has blocked the traffic.
>>
>
> I have the same interpretation.
>
>
>> The way we envisioned these policies is enforced by a firewall (as
>> opposed to the HNA itself) so the intention is to protect the HNA -
>> including hiding the HNA, in which case dropping seems the most obvious way
>> to implement these policies.
>> Now, since the traffic is protected by TLS, the rules associated with the
>> HNA are more application specific rules, and we can envision that with a
>> trusted peer, rejection might be more appropriate.
>>
>
> Agree, rejection is better when the trusted peer sends an invalid message.
>
>
>>
>> To address your comment I propose to differentiate the DNS rules from
>> what can be implemented by a firewall and take a large part of the text you
>> proposed resulting in the following text:
>>
>> """
>> The HNA SHOULD drop any packets arriving on the WAN interface that are
>> not issued from the DM.
>>
>>
>> Depending how the communications between the HNA and the DM are secured,
>> only packets associated to that protocol SHOULD be allowed.
>>
>>
>>
>>
>> At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
>> NOTIFY query, SOA response, IXFR response or AXFR responses.
>>
>> The HNA SHOULD reject any incoming messages other than DNS NOTIFY
>> response, SOA query, IXFR query or AXFR query.
>> """
>>
>
> The separation looks good, but I'd like to tweak the second paragraph. By
> "only packets associated to that protocol" do you mean destination port
> filtering?
>
To me IP and port filtering are implemented by the previous line. "only
packets associated with that protocol" to me means that only TLS packets
are allowed. The reason we are not mentioning TLS explicitly is that
other protocols may be used.
>
> 12 This acknowledges that it's a little risky to publish names of home
>>> devices publicly, and notes that often it's only the home owner or
>>> immediate family that ought to be able to query these names. It says that
>>> limiting ability to query can be done by IP source (IMHO tricky), or VPN.
>>> To which I think, if the home owner is using a VPN to the home to query the
>>> public zone, why do we need external publication at all? Some words to
>>> explain that better might be useful.
>>>
>>>
>> I have added some text to provide some explanations. It is correct that
>> if all your traffic is redirected in the home network, then there is little
>> interest in publishing all the names as they will only b
Re: [homenet] naming drafts
iting ability to query can be done by IP source (IMHO tricky), or VPN. > To which I think, if the home owner is using a VPN to the home to query the > public zone, why do we need external publication at all? Some words to > explain that better might be useful. > > I have added some text to provide some explanations. It is correct that if all your traffic is redirected in the home network, then there is little interest in publishing all the names as they will only be accessed internally. The text was trying to mention that a node may be willing to set different policies for its traffic. Typically the web traffic is not tunneled while the traffic to the homenet is tunneled. In this case, the ability to define which IP address needs to be tunneled and which IP address does not need to be tunneled requires to have this IP address so to be able to publicly perform a DNS resolution. The added text is as follows: """ In such cases, the routing policy is likely to be defined by the destination IP address. This IP address potentially results from a DNS resolution over the Internet. """ I also added some references to lower the confidence in the security provided by NSEC3 as well as a reference to draft-ietf-dnsop-nsec3-guidance to configure appropriately NSEC3. > *draft-ietf-homenet-naming-architecture-dhc-options-14* > > 3 In both American and British English I think the word "collocate" should > be "colocate" (or alternatively "co-locate"). > > fixed. > 3 What exactly is meant by "(eventually by a self signed certificate)"? > > I added a reference to the section it is discussed in the architecture document. The idea is that in some cases such as the reverse zone, TLS is not necessarily required as the ISP identifies the line. On the other hand, we wanted to avoid to have different versions of the HNA - let's say a secure version that uses TLS and a unsecure version that did not use TLS. As a result, when authentication is not mandatory we prefer the use of a self signed certificate. > 4.2 I think the HNA also needs to learn the set of IP addresses that the > DM might legitimately use in order to contact the HNA, so that these IPs > can be whitelisted in the CPE's firewall. Simply looking up the FQDN > doesn't provide that. Should it be added to this DHCP option? > This is correct, so the idea is that we could provision a list of IPv4 and a list of IPv6. However, it seems simpler to only consider the DM FQDN and let the HNA retrieve the IP addresses from a DNS(SEC) resolution. This is correct that this provides an additional round trip and a resolution service to be working. This could be difficult in the case of setting a resolving service, but in our case, we do not have such issues. > > > Hope that's useful. > > Thanks, > Chris > > > On Fri, 4 Jun 2021 at 20:45, STARK, BARBARA H wrote: > >> Hi homenet WG, >> Stephen and I have been chatting about the status of the 2 naming drafts >> (draft-ietf-homenet-front-end-naming-delegation and >> draft-ietf-homenet-naming-architecture-dhc-options). >> >> We started a 3-week WGLC about a month ago (04 May). Both drafts received >> comprehensive review from Med. Stephen reviewed >> front-end-naming-delegation. Bernie reviewed the formatting of the DHC >> option. >> The authors provided updates to resolve these comments. Bernie >> acknowledged satisfactory resolution of his comments. >> Requests to change terminology were satisfactorily resolved -- but that >> discussion doesn't count as really being part of anyone's review of the >> drafts. >> Stephen and Juliusz expressed that they're still not convinced that DDNS >> isn't a good enough solution for the use case. >> >> Stephen and I do not believe these drafts have received enough review or >> support to put them forward as representing WG consensus. >> >> But the authors have spent significant effort in creating these drafts >> and the associated implementation. We will work with Éric V (as INT area >> AD) and the authors to determine next steps. >> >> Barbara and Stephen >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
Hi Stephen, I am just replying to clarify I am not complaining about you personally or even your review. If further discussions are needed I am happy to set a call at any time as email does not seem to me the most constructive path. Yours, Daniel On Tue, Jun 8, 2021 at 10:10 AM Stephen Farrell wrote: > > Hiya, > > On 08/06/2021 14:55, Daniel Migault wrote: > > I disagree that discussing whether the proposal will take over DDNS > > is a side discussion that unfortunately happens at a bad time. > > Sorry, I don't get what you mean. > Let me try to provide more background. I am reading or interpreting your response to Ray (quoted below) that the discussion on whether the proposal will take over DDNS is a simple discussion that does not have any consequences. I disagree with that. It seems that raising such discussion during a WGLC has consequences, perhaps because I do not see the technical aspect of the discussion. """ It was one amongst a bunch of personal comments I sent. And that I'm happy to discuss with the authors without wearing any chair or other hat. """ > > > If I > > interpret the WGLC report, it is clearly noted as a lack of support. > > No. It's me being critical of the text. I neither support > nor oppose this stuff, but the arguments presented for that > part aren't convincing IMO, which is what my comment said. > The lack of support appeared to me in the WGLC quoted below which mentions "not enough support". I interpreted this as partly resulting from challenging the proposal but maybe I am mis-interpreting this, though I understand it also included partly a number of reviews. """ Stephen and I do not believe these drafts have received enough review or support to put them forward as representing WG consensus. """ If I interprete "neither support nor oppose" of your response as being neutral, I do have hard time to read it from the WGLC report which describe your position as follows: """ Stephen and Juliusz expressed that they're still not convinced that DDNS isn't a good enough solution for the use case. """ That said, I am fine that there are different opinions and people have different predictions, as long as we agree these remain personal opinions that should not influence moving the document forward. This is not clear to me this is the way it is interpreted. > > > > Predictions are not a technical discussion and can be very wrong ( > > "we will never make a 32 bit operating system", "there is no reason > > anyone would want a computer in their home"... the list can be as > > long as we wish). It should not be considered in the decision to move > > the document forward. Will it replace DDNS - I do not know. Not more > > than Stephen or Juliusz. I am happy to have this discussion in 2 > > years. Today it gives a toxic tone to the discussion. > > Toxic? That's seems quite overblown. And plain wrong, if > you mean it to describe my review. I can understand the > frustration of working on something like this and not > seeing it progress as planned, but accusing me of creating > toxicity is not a fair accusation for you to make. > > I am not accusing anyone. The discussion is toxic in my point of view because at this point it is very hard to engage someone into reviewing the doc, as it is asking him to take a position in favor of or against some parties. I do not believe that this results from your review, but rather how your review has been summarized and has influenced the chair's decision. Reviews are always welcome. > > I agree that more reviews is always preferred, but I am wondering how > > many reviews would have been considered sufficient. > > Oh come on - we've tried a number of times to get people > to review these documents and we've never really gotten > that to happen. The level of review is nowhere near > sufficient to declare some meaningful WG consensus. > The question concerned the number of reviews that would have been considered sufficient. I do not understand how this can be interpreted as chairs not making enough effort to get reviews. It was not my intent. That said, I remember that people committed to review, and maybe a reminder would have been welcome. > > > Looking at the > > homenet mailing list we can see that the number of reviews reflects > > the participation of the mailing list. > > That's true. I think it may be time to recognise reality > and close the WG perhaps. > > I do not think that was not predictable, nor something that we learned during this WGLC. If we had some other specific expectations, those should have been clearly provided. And it is still unclear to me how many reviews were expected for example.
Re: [homenet] naming drafts
I disagree that discussing whether the proposal will take over DDNS is a side discussion that unfortunately happens at a bad time. If I interpret the WGLC report, it is clearly noted as a lack of support. Predictions are not a technical discussion and can be very wrong ( "we will never make a 32 bit operating system", "there is no reason anyone would want a computer in their home"... the list can be as long as we wish). It should not be considered in the decision to move the document forward. Will it replace DDNS - I do not know. Not more than Stephen or Juliusz. I am happy to have this discussion in 2 years. Today it gives a toxic tone to the discussion. I agree that more reviews is always preferred, but I am wondering how many reviews would have been considered sufficient. Looking at the homenet mailing list we can see that the number of reviews reflects the participation of the mailing list. Though I really value your review, I am not sure that (even with no hat) it encourages additional reviews, as it forces the potential reviewer to take position against the opinion of the chair. It seems to me that, if the number of reviews were an issue, this could have been addressed otherwise. >From my perspective all comments have been responded to, and technical comments have been addressed. Regarding the support, the proposal was initiated by an ISP. Today, I am interested in this proposal because we have some demand for it. That some folks prefer using DDNS for their own purpose is orthogonal to us. This is why we want it to be published. Yours, Daniel On Tue, Jun 8, 2021 at 6:06 AM Stephen Farrell wrote: > > Hiya, > > On 08/06/2021 10:29, Ray Hunter (v6ops) wrote: > > > > Just trying to understand this hurdle/ line of reasoning. > > > > So in addition to achieving "rough consensus", the IETF standardization > > process must also produce drafts that are very likely to gain traction > > to displace non-IETF non-standardised products that are already widely > > commercially deployed? > > No. This is not a process hurdle. It was one amongst > a bunch of personal comments I sent. And that I'm happy > to discuss with the authors without wearing any chair > or other hat. > > The process problem with these drafts is the lack of > review means there's no way to claim they represent any > useful level of WG consensus. > > Cheers, > S. > > _______ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hi Stephen, Please find inline some responses or follow-up discussion. Yours, Daniel On Wed, May 26, 2021 at 3:37 PM Stephen Farrell wrote: > > Hiya, > > A few responses below... > > On 26/05/2021 18:02, Daniel Migault wrote: > > Hi Stephen, > > > > Thanks for the questions / suggestions / comments. Please find some > > responses inline. I updated the document [1] and added issues on the > > git repo. > > > > Yours, Daniel > > > > [1] > > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/cc07384cf6a93794f984d3393100e700a306317c#diff-1fb3d4609e8b03755bf2390df10a5ccd792f989796a0b922a273cd63418fcaa5 > > > > > > > > On Mon, May 24, 2021 at 5:01 PM Stephen Farrell > > wrote: > > > >> > >> Hiya, > >> > >> I had a read of this one. My comments (as an individual, not as > >> chair) below. I'll chat with Barbara to see if we have a common > >> position on how to handle next steps but am happy to chat about > >> stuff below whenever. > >> > >> Cheers, S. > >> > >> review of draft-ietf-homenet-front-end-naming-delegation-15 sf, > >> 20210524 > >> > >> general/technical: > >> > >> #1 This needs significant editorial work, there are too many > >> grammatical issues, at least some of which lead to ambiguity. > >> > >> #2 If a home network/CPE isn't robust enough to serve as a DNS > >> server for it's public zone, then how is it robust enough to resist > >> attack/DoS on the addresses exposed in that zone? That seems to me > >> to counter a bunch of the arguments for this approach, so I'd like > >> to understand the proponents arguments there. At minimum, any > >> for an "inside" server/name means that the CPE's f/w will be > >> subject to the same kind of attacks that might happen if the CPE > >> was the only/primary DNS server for the zone. > >> > >> > > CPE are optimized for packet l2/l3 packet switching as opposed to > > terminate services. Resources of the CPE are estimated for > > volumetric attacks that are expected to be handled by the ISP. > > Hosting DNS changes the scope on that the CPE becomes an addressable > > target, subject to application DoS attacks which it has not been in > > general designed for and which are much harder to tackle for an ISP > > as this is "legitimate" traffic. The document does not specify the > > HNA is addressable from inside the network and Figure 1 clearly > > separates the authoritative server from the HNA. Of course this could > > be implemented this way, but I am wondering if there is any text that > > suggests such an approach. It seems to me that discussion over the > > management of the authoritative DNS server on the CPE is out of the > > scope of the document. In addition, if an DDoS attack is handled from > > inside the homenet, the network admin is more likely to unplug that > > device than if performed from the Internet. > > I still don't get it sorry. Shodan and zmap will allow anyone > to find the listening port in many cases, regardless of that > being port 53/853 on the CPE or 443 (or even, gulp! port 80) > on some host further into the homenet. > > My point here is not that one ought not provide a listening > process within a homenet, but only that this proposal doesn't > really solve robustness issues. > > It seems to me that your concern is that the HNA (while not serving the zone to the internet or in the homenet) remains exposed with a listening port (on the internet) to sync the zone with the secondary servers (DM). If that is correct, I believe that section 7 addresses this concern. In short, the HNA does not expose any listening port, as communications are restricted to the DM and thus protected by a firewall. While out of scope of the document, a similar configuration may be applied between the Homenet Authoritative server and the HNA if these two entities were not co-located. Does it address the concern ? Now that this listening port concern has been fixed. I believe we can agree that the proposed architecture provides a more robust way (internally and externally) to host a DNS service for the homenet, than hosting the server on the CPE. >> #3 The arguments about handling "disruption with the ISP" could do > >> with some more evidence, not necessarily as text in the draft, but > >> it ought exist - does it? E.g. do we know that publishing ULAs > >> isn't problematic? Do we know that GUAs in such scenarios aren't > >> still usable for longish durations given a realistic
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hi Juliusz, I think we responded to the question in 2014 [1]. I am happy to clarify our text of section 1.2. Could you please point out what in the draft you believe is wrong and what you would like to be updated. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/homenet/qL5BmPs5LOi281AMTCD_lHt49Is/ On Tue, May 25, 2021 at 8:23 AM Juliusz Chroboczek wrote: > > #5 The arguments why this is better than DDNS don't convince > > me, except for the last one (new RR types). Given that DDNS is > > deployed, what's the chances that this would also get traction? > > I think that's an important point. I actually asked the very same > question back in 2014: > > > https://mailarchive.ietf.org/arch/msg/homenet/CBoLV2St-kSW0vQNE4GtKqRQthA/ > > https://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c/ > > The authors integrated the discussion as Section 1.2 of the draft, which > is what you are referring to. I'm not sure if I'm convinced by their > arguments, I suspect that there's some unstated requirement that I don't > undestand. > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
uot;"" > - 5.1: It's not clear that DANE will always be ok there - there >should be a way to make it work but I don't think I've seen > any worked-out description of using DANE for DoX. > > The intention of the text is to mention that other mechanisms can be used. DANE is only used to carry the certificate. > - 5.1: "baked-in" isn't right - typically those lists are >updated by the OS (e.g. OpenWRT) or via application s/w > update. (My nearest OpenSSL install has an /etc/ssl/certs > directory.) > In this case I imagine the certificate being specific to the HNA (application) and provisioned as a sort of TA, CA... In particular I do not think the backed-in should be used for any other purposes. I opened an issue to clarify that point. https://github.com/ietf-homenet-wg/ietf-homenet-hna/issues/50 > > - 5.1: I'm not clear how exactly pinning via tickets would work >here but I didn't read RFC8672 just now so maybe it's all > clear from tha - is it? > > This is to ensure that the DM you started with remains the same one across the exchanges. - section 9: I don't understand: "This leave place for setting >up automatically the relation between HNA and the DNS > Outsourcing infrastructure as described in > [I-D.ietf-homenet-naming-architecture-dhc-options]." > > The ISP manages a DOI for the IP prefix domain name, identifies the line to which the IP prefix is assigned which makes out-of band configuration of the client unnecessary. Without such out-of-band step, the process can be completely automated. > - section 9: "2001:db8:babe:0001::2" - the string "babe" has >both innocent and less innocent interpretations, not sure if > you want to risk the latter being some reader's interpretation. > > Thanks. You are correct I prefer not to take the risk. When reading I did not go further than it is a word and the one I know is a kid's movie, so I did not pay attention. I changed it to aeae. - section 10: you use a different example here from earlier, >just one is probably better, unless there's a reason they > ought differ. > > Changed to myhome.example. Thanks. > - 11.1: is a subsection needed there really? (I kinda skipped >all that text TBH;-) > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
On Fri, May 14, 2021 at 11:17 AM Michael Richardson wrote: > > Daniel Migault wrote: > > Please find the new version that is considering the discussions of > the > > mailing list as well as comments received from Med. > > Daniel, I was just proofreading, and you'll see a pull request "typos" > > 1. reading at the beginning, I didn't recall if we had concluded that we > were >going to mandate the AXFR to be XoT (AXFR over TLS) or not. >We later reference [I-D.ietf-dprive-xfr-over-tls], but not section > 4.5.1. >Is it enough to say it in section 5.1? > In my mind, we were mandating AXFR over TLS. So we should probably clarify this in section 4.5.1 as well. > > 2. What if the zone template provided by the DM has to change. >(Because, for instance, the distribution server NS records change). >Is the template retrieve each time the zone is signed? >Once? (And never again?...) >Based upon some TTL? > > That is a good catch. The TTL of the NS may be a good indication. But we may also recommend the HNA to check it regularly, like every day or every week. > 3. Section 4.6, we say "SHOULD" on TLS, but in which case, what exception > are we >thinking? I guess we three will have to do another SHOULD/MUST audit. >Noting that RECOMMENDED ==> SHOULD. > > I think we said SHOULD in case some deployment wants to use other means. The one that come to my mind is if a deployment is willing to use TSIG for example. I am find moving this to MUST use TLS. > > Section 5 has "" and "XX"... which feels like maybe we forgot to do > some > IANA thing. Maybe we should omit the placeholders? What does the WG > think? > > I think the 4 digit port and 2 digit port are clearly represented by these variables, but I am fine we remove these if that bring any confusion. > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
Hi, Please find the new version that is considering the discussions of the mailing list as well as comments received from Med. Yours, Daniel -- Forwarded message - From: Date: Thu, May 13, 2021 at 2:08 PM Subject: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : Simple Provisioning of Public Names for Residential Networks Authors : Daniel Migault Ralf Weber Michael Richardson Ray Hunter Filename: draft-ietf-homenet-front-end-naming-delegation-15.txt Pages : 38 Date: 2021-05-13 Abstract: Home owners often have IPv6 devices that they wish to access over the Internet using names. Outsourcing the DNS servers to a DNS infrastructure protects against possible DDoS attacks as well as sudden renumbering of the home network. It has been possible to register and populate a DNS Zone with names since DNS became a thing, but it has been an activity typically reserved for experts. This document automates the process through creation of a Homenet Naming Authority (HNA), whose responsibility is to select, sign and publish names to a set of publicly visible servers. This document describes the mechanism that enables the HNA to outsource the naming service to the DNS Outsourcing Infrastructure (DOI) via a Distribution Manager (DM). In addition, this document deals with publication of a corresponding reverse zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-15 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-15 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WGLC started
s: > - pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.pdf > - doc: > https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.docx > > * draft-ietf-homenet-front-end-naming-delegation: > - pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.pdf > - doc: > https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.docx > > > Cheers, > Med > > > -Message d'origine- > > De : dns-privacy [mailto:dns-privacy-boun...@ietf.org] De la part de > > STARK, BARBARA H > > Envoyé : mardi 4 mai 2021 15:56 > > À : 'homenet@ietf.org' > > Cc : 'dh...@ietf.org' ; 'dns-priv...@ietf.org' > priv...@ietf.org>; 'int-a...@ietf.org' > > Objet : [dns-privacy] WGLC started > > > > Hi homenet, intarea, dhc, and dprive, > > Homenet has started WGLC for draft-ietf-homenet-front-end-naming- > > delegation-14 and draft-ietf-homenet-naming-architecture-dhc-options- > > 12. > > > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming- > > delegation/ (Simple Provisioning of Public Names for Residential > > Networks) https://datatracker.ietf.org/doc/draft-ietf-homenet-naming- > > architecture-dhc-options/ (DHCPv6 Options for Home Network Naming > > Authority) > > > > We're including intarea, dhc, and dprive to get a slightly wider > > audience for the technical aspects of these drafts (dhc is > > specifically asked to look at the dhc-options draft). > > The drafts do also need some editorial fixing-up. I'll be focusing on > > that so the technical experts can focus on the technical aspects. > > > > I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing > > this because > > - we're reaching out to WGs that haven't seen this before and asking > > them for comments > > - there are 2 drafts > > - I'm on vacation next week and was getting stressed out by > > everything I need to get done by this Friday > > > > The meeting minutes (from the homenet April 23 interim) list intarea, > > dprive, and dhc as other groups to request comments from. Is this the > > right list? Are there others? > > Please let me know if I should broaden this. > > Thx, > > Barbara > > > > ___ > > dns-privacy mailing list > > dns-priv...@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-privacy > > > _ > > 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. > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-14.txt
Hi, Please find the version that addresses Med's and Bernie's comments. Yours, Daniel -- Forwarded message - From: Date: Thu, May 13, 2021 at 1:54 PM Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-14.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking WG of the IETF. Title : DHCPv6 Options for Home Network Naming Authority Authors : Daniel Migault Ralf Weber Tomek Mrugalski Filename: draft-ietf-homenet-naming-architecture-dhc-options-14.txt Pages : 14 Date: 2021-05-13 Abstract: This document defines DHCPv6 options so an agnostic Homenet Naming Authority (HNA) can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-14 https://datatracker.ietf.org/doc/html/draft-ietf-homenet-naming-architecture-dhc-options-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-14 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WGLC started
Hi Med, Thanks for the review, please find some responses to your comments inline. I will publish shortly a new version that addresses your comments. Yours, Daniel In this context agnostic is used to mention the CE router can learn everything from the network without requiring interaction from the end user. [1] https://dictionary.cambridge.org/dictionary/english/agnostic [BMT17]: Do you assume that default ports are used? If not, how this is discovered? > Yes, we currently only configure the most simple configuration. There is no discovery. Non default parameters might be defined out of bound, or other mechanisms such as SVCB for example. [BMT18]: Why not returning a list of IP addresses? Or do you need it for authentication? > this has been extensively discussed but I agree a long time ago. As far as I remember, we used the FQDN for compactness and we assumed the CE is able to resolve the name. On Wed, May 5, 2021 at 8:33 AM wrote: > Hi all, > > FWIW, some comments to be considered by the authors as part the WGLC can > be seen at: > > * draft-ietf-homenet-naming-architecture-dhc-options: > - pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.pdf > - doc: > https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.docx > > * draft-ietf-homenet-front-end-naming-delegation: > - pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.pdf > - doc: > https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.docx > > > Cheers, > Med > > > -Message d'origine- > > De : dns-privacy [mailto:dns-privacy-boun...@ietf.org] De la part de > > STARK, BARBARA H > > Envoyé : mardi 4 mai 2021 15:56 > > À : 'homenet@ietf.org' > > Cc : 'dh...@ietf.org' ; 'dns-priv...@ietf.org' > priv...@ietf.org>; 'int-a...@ietf.org' > > Objet : [dns-privacy] WGLC started > > > > Hi homenet, intarea, dhc, and dprive, > > Homenet has started WGLC for draft-ietf-homenet-front-end-naming- > > delegation-14 and draft-ietf-homenet-naming-architecture-dhc-options- > > 12. > > > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming- > > delegation/ (Simple Provisioning of Public Names for Residential > > Networks) https://datatracker.ietf.org/doc/draft-ietf-homenet-naming- > > architecture-dhc-options/ (DHCPv6 Options for Home Network Naming > > Authority) > > > > We're including intarea, dhc, and dprive to get a slightly wider > > audience for the technical aspects of these drafts (dhc is > > specifically asked to look at the dhc-options draft). > > The drafts do also need some editorial fixing-up. I'll be focusing on > > that so the technical experts can focus on the technical aspects. > > > > I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing > > this because > > - we're reaching out to WGs that haven't seen this before and asking > > them for comments > > - there are 2 drafts > > - I'm on vacation next week and was getting stressed out by > > everything I need to get done by this Friday > > > > The meeting minutes (from the homenet April 23 interim) list intarea, > > dprive, and dhc as other groups to request comments from. Is this the > > right list? Are there others? > > Please let me know if I should broaden this. > > Thx, > > Barbara > > > > ___ > > dns-privacy mailing list > > dns-priv...@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-privacy > > > _ > > 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. > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12
Hi Bernie, Please find the update of the current draft. I am publishing a new version very shortly. Thanks for the review! Yours, Daniel On Wed, May 5, 2021 at 10:53 AM Bernie Volz (volz) wrote: > Hi: > > Looking at this primarily from the DHCP perspective ... regarding > https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/, > these DHCPv6 options are formatted properly (as per RFC7227 and standard > practices). > > I just have some nits: > - In 4.2, in the "option-code" description "DM Option" is used (only use). > Probably best if this was replaced with "Distributed Master Option"? (Yes, > DM is used in plenty of other places, but it seems odd to use it here as > the "name" of the option.) done > Also, "TDB3" in the IANA section does not use "DM". changed to TBD2 > Also, 4.3 "option-code" uses "Reverse Distributed Master Option (TBD4)". > changed to TBD3 > - In 4.3, the "Supported Transport" description says "DM". Should this be > "RDM", as this is the Reverse Distributed Master Server Option? > correct, this has been changed to RDM. > > And, something to ponder: > - In 5.3, is there any value in potentially allowing a Relay Agent to > supply these options to a server to potentially return to a client via the > RSOO option (RFC6422)? I raise this question as it seems no documents have > mentioned this and there was a case that recently came up where this was > useful for another option, so just want to remind folks that it exists and > to consider whether it could be used for these options. > > > I do plan to take a closer look at the other I-D as well, so may have > additional comments thereafter. > > - Bernie > > -Original Message- > From: dhcwg On Behalf Of STARK, BARBARA H > Sent: Tuesday, May 4, 2021 9:56 AM > To: 'homenet@ietf.org' > Cc: 'dh...@ietf.org' ; 'dns-priv...@ietf.org' < > dns-priv...@ietf.org>; 'int-a...@ietf.org' > Subject: [dhcwg] WGLC started > > Hi homenet, intarea, dhc, and dprive, > Homenet has started WGLC for > draft-ietf-homenet-front-end-naming-delegation-14 and > draft-ietf-homenet-naming-architecture-dhc-options-12. > > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > (Simple Provisioning of Public Names for Residential Networks) > https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ > (DHCPv6 Options for Home Network Naming Authority) > > We're including intarea, dhc, and dprive to get a slightly wider audience > for the technical aspects of these drafts (dhc is specifically asked to > look at the dhc-options draft). > The drafts do also need some editorial fixing-up. I'll be focusing on that > so the technical experts can focus on the technical aspects. > > I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing this > because > - we're reaching out to WGs that haven't seen this before and asking them > for comments > - there are 2 drafts > - I'm on vacation next week and was getting stressed out by everything I > need to get done by this Friday > > The meeting minutes (from the homenet April 23 interim) list intarea, > dprive, and dhc as other groups to request comments from. Is this the right > list? Are there others? > Please let me know if I should broaden this. > Thx, > Barbara > > ___ > dhcwg mailing list > dh...@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > ___ > dhcwg mailing list > dh...@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12
Thanks Bernie, in any case for raising this. It is always good information to process and think of carefully before bringing any conclusion. Yours, Daniel On Wed, May 12, 2021 at 1:46 PM Bernie Volz (volz) wrote: > Regarding RSOO, that’s fine if it doesn’t meet your needs. Just wanted to > raise it as it probably isn’t considered as often as it should be. > > > >- Bernie > > > > *From: *Daniel Migault > *Date: *Wednesday, May 12, 2021 at 1:11 PM > *To: *Michael Richardson > *Cc: *Ted Lemon , int-a...@ietf.org , > dh...@ietf.org , dns-priv...@ietf.org < > dns-priv...@ietf.org>, Bernie Volz (volz) , > homenet@ietf.org > *Subject: *Re: [dhcwg] WGLC started -- > draft-ietf-homenet-naming-architecture-dhc-options-12 > > Hi, > > > > Thank you all for the feedbacks. I will perform the editorial once we have > settled the terminology. > > Regarding the use of a DHCP Relay, we could of course make a use case of > it, but I believe it would go beyond the simplicity of the targeted > architecture and I would rather not consider this as RSOO enabled. > > > > Yours, > Daniel > > > > On Wed, May 5, 2021 at 3:10 PM Michael Richardson > wrote: > > > Ted Lemon wrote: > > On May 5, 2021, at 11:44 AM, Michael Richardson < > mcr+i...@sandelman.ca> > > wrote: > >> The end user might suffer slightly by having locally served reverse > >> names that are no longer connected: they should obsolete that zone > >> when they realize that their PD hasn't been renewed, until such > time, > >> (if it was a flash renumber), they would be right to think that they > >> legitimately control them. > > > In practice I don’t think this is an issue. The reverse lookup is > > usually triggered by receipt of a message from an IP address, so as > > long as the IP address is still in use internally, the presence of > the > > reverse zone is wanted. When the address changes, the old zone > becomes > > obsolete whether it continues to be served or not. The likelihood of > > the zone being re-allocated to some other network for which the > > original network will then do a reverse lookup is very small, so I > > don’t think there’s any reason to be concerned about this. > > I agree with you completely. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > dhcwg mailing list > dh...@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet naming drafts "terminology"
Sounds good to me. Anyone objecting DIstribution Manager ? If not I will consider this terminology. Yours, Daniel On Wed, May 12, 2021 at 5:11 PM Michael Richardson wrote: > > Daniel Migault wrote: > > "Distribution Primary" is probably my preferred alternative as the > > replacement of Master by Primary makes a smooth transition from what > is > > currently used. If that is fine with everyone I will update the > > document with it as well as the DHCP option draft. If not feel free > to > > provide a better alternative. > > I'm okay with that, but would list "Distribution Manager" as a nice TLA > preserving of "DM" > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- Daniel Migault Ericsson ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
