Re: [homenet] [dnsdir] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
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
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
On Tue, Oct 18, 2022 at 2:40 AM Michael Richardson wrote: > > > Thank you for this review! > You did a very good job.. > > Matt Brown via Datatracker wrote: > > 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. > > 18 quintillion addresses is quite a lot :-) > It's not easy to scan. Maybe you had some > > Here is a discussion in 6man, about using a browser to scan the IPv6-LL > of a local LAN: > https://mailarchive.ietf.org/arch/msg/ipv6/YDRrY71hxhQBdMGLS-XByHS1f7I/ Of course, please excuse the brain fart here and ignore this comment. > The other points are interesting, and I'll need to think about your > editorial suggestions about what order to present things in. Happy to chat more in due course. Thanks -- Matt Brown ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-homenet-front-end-naming-delegation-18: 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: -- Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ I am (reluctantly) balloting DISCUSS on the following criteria: * The specification is impossible to implement due to technical or clarity issues. * The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. * It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification. I apologize for doing this, as I know that this will be a difficult set of comments to address. This isn't just a few "here are the DISCUSS points", but rather "there are a sufficient number of lack of clarity issues (and readability issues) that I don't think it can be understood and implemented without ambiguity." I have reviewed most of the document, but have only transcribed my comments up to page 13. Because there are both nits and substantive comments on the same bits of text (and to stop this gettign even longer) I have not separated them into separate sections like I normally would. I wanted to send this out now, so that the authors, WG and AD can start reviewing and we can discuss some way to resolve this... -- COMMENT: -- Section 1: 1: O: The remaining of the document is as follows. P: The remainder of the document is as follows: C: Nit - Grammar 2: O: Section 3 provides an architectural view of the HNA, DM and DOI as well as its different communication channels P: Section 3 provides an architectural view of the HNA, DM and DOI as well as their different communication channels C: Nit - Plural. 3: O: Section 7 and Section 9 respectively details HNA security policies as well as DNSSEC P: Section 7 and Section 9 respectively detail HNA security policies as well as DNSSEC C: Nit - Grammar / plural Section 1.1: 4: O: Of these the link-local are never useful for the Public Zone, C: I don't really agree with the "never" - the document does discuss failing back to the Public zone if needed, and so this may sometimes be useful. I agree that it is much less common / useful, and this this is probably a nit... 5: O: "However, since communications are established with names which remains a global identifier, the communication can be protected by TLS the same way it is protected on the global Internet." C: "However" implies that the sentence follows on from a previous point and provides a refutation / comparison, and this sentence doesn't - it is more of a fragment / new thought. C: s/remains/remain/ (grammar) C: More text is needed here - I'm *assuming* that you are meaning that because the name is globally resolvable to an address, that this can be used to obtain a certificate for that name? If so, that's really not clear. Section 1.2: 6: O: "An alternative existing solution is to have a single zone, where a host uses a RESTful HTTP service to register a single name into a common public zone. " P: "An alternative existing solution for residential customers is to..." C: There are a number of alternative solutions, for example many companies use DHCP to populate a zone (usually using RFC 2136), Windows Active Directory does something similar, many cloud / hosting providers will add and remove entries, etc. 7: O: "This is often called "Dynamic DNS" [DDNS], and there are a number of commercial providers. While the IETF has defined Dynamic Update [RFC3007], in many - as far as the co-authors know in all cases - case commercial "Dynamic Update" solutions are implemented via a HTTPS RESTful API." C1: I think that you need to be much clearer that the "Dynamic DNS" you are talking about in the first sentence is different to Dynamic Updates. C2: I think that that is the wrong reference - RFC2136 is the Dynamic Updates RFC, RFC3007 wraps it in TSIG. C3: You have a repeated "case" (actually, "case" should move before the hyphen, and the second "cases" should be removed). C4: 30 seconds with a search engine shows that Dyn DNS (of of the largest providers)
Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Thank you for this review! You did a very good job.. Matt Brown via Datatracker wrote: > 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. 18 quintillion addresses is quite a lot :-) It's not easy to scan. Maybe you had some Here is a discussion in 6man, about using a browser to scan the IPv6-LL of a local LAN: https://mailarchive.ietf.org/arch/msg/ipv6/YDRrY71hxhQBdMGLS-XByHS1f7I/ The other points are interesting, and I'll need to think about your editorial suggestions about what order to present things in. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
Reviewer: Matt Brown Review result: Not Ready Kia ora, I'm a recent addition to dnsdir and have been asked to review this draft - this is my first formal IETF review, so apologies in advance if I don't quite hit the right spot in terms of what's looked for here - in particular I'm not sure how calibrated my "Result" status selection is... Review Conclusion: The intent and proposed mechanism the draft seeks to achieve is clear and the proposed high-level architecture of a hidden master is consistent with the overall format of the DNS ecosystem. The proposed implementation of the control channel requires a mode of communication (mutual TLS authentication via DoT) that is not an existing standards, nor specified in this document and therefore appear infeasible to me without further specification taking place. There are a number of other gramatical nits and improvements in wording which are needed to improve the clarity and understandability of the standard 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? As written (recommending DoT with mTLS), I do not believe this standard is implementable. Minor Issues (aka Ready with Issues): 2 and 3.1: DNSSEC Resolver - is the exclusion of unsigned/non-DNSSEC resolvers in the terminology and architecture overview intentional? Section 9 confirms that DNSSEC is not required (only RECOMMENDED), so it is possible that both the public and internal resolvers being used are not DNSSEC capable - therefore it seems strange for the architecture overview and terminology to imply that DNSSEC is required. 3.2: The 4th paragraph begins describing "the main issue", the solution to which is not explained in the paragraph, or in the referenced Section 4.2 (which is DNSSEC/DS specific vs the NS, A, context of the paragraph). In either case, the semantics of how the DM treats the information it receives from the HNA seems out of place in a section describing and primarily focused on the mechanics of the communication channel itself. I suggest removing or rewriting this 4th paragraph to improve the 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 cer
