Ballot for draft-ietf-homenet-front-end-naming-delegation
Discuss
Yes
No Objection
Abstain
No Record
Note: This ballot was opened for revision 18 and is now closed.
This isn't my only concern with this document but Warren Kumari has broadly covered the space with his own DISCUSS. I did want to highlight this one, though. I think it should be relatively easy to fix. Section 4.6, "Securing the Control Channel", almost-mandates security: ``` The control channel between the HNA and the DM MUST be secured at both the HNA and the DM. ``` It does not, however, specify any mandatory-to-implement security mechanism, although it provides an interesting and wide-ranging discussion of many options. It's very difficult for me to see how interoperable implementations can be built, that comply with the quoted requirement, by someone working from the current specification. It does seem from other hints in the document that the authors consider TLS mandatory even though it's not stated as such in Section 4.6. For example, Security Considerations subsection 12.1 says, ``` The channels between HNA and DM are mutually authenticated and encrypted with TLS [RFC8446] and its associated security considerations apply. ``` Another hint that TLS is viewed as mandatory-to-implement is from a different document also currently under review, draft-ietf-homenet-naming-architecture-dhc-options-21 (Sections 4.2 and 4.3): ``` The bit for DNS over TLS [RFC7858] MUST be set. ``` I talk about this more in my comment on Section 4.6, but there's just no way to read this paragraph as mandating TLS: ``` Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the transactions between the DM and the HNA. ``` It doesn't even quite mandate secure transport in general, since it's a SHOULD (so presumably there are times when an implementor can sensibly ignore it, though these are not discussed). What's more, TLS is only given as an example of one transport that would be OK, not as the mandatory-to-implement secure transport. As written, any secure transport, for example TCP-AO, would satisfy this SHOULD. Based on the hints throughout the rest of the document set, that the authors think of TLS as the mandatory-to-implement base transport, I think this section should be rewritten to match that expectation.
# RTG AD John Scudder's comments for draft-ietf-homenet-front-end-naming-delegation-18 CC @jgscudder Thanks for the work on this document, it clearly reflects a lot of effort. I hope these comments help you get it over the finish line. Although I'm not enough of a DNS expert to evaluate the details of what the document specifies, the number of inconsistencies and minor errors I've flagged in my review makes me concerned that there may be problems with implementability. For this reason I support Warren Kumari's DISCUSS. In my comments below I've flagged a few grammar nits, but for the most part I've tried to restrict myself to cases where it seemed like there was a risk of misunderstanding if not corrected. Even when/if these are fixed I think the document would benefit from a full go-over either manually or using an automated grammar checker, before sending it to the RFC Editor. (Yes the RFC Editor will do their best to fix all of these. But it's better for the authors to do it to the best of their ability, including because occasionally, despite their best efforts, the RFC Editor introduces a "fix" that results in an unwanted normative change.) ## COMMENTS ### Global - "associated to" There are at least 13 occurrences of the phrase "associated to". Can these all be replaced by the more idiomatically correct "associated with"? I hesitate, because "associated to" in computing can have a technically-distinct meaning, however if that's the case in any of these I think such uses of "associated to" may need clarification. So, to be clear: I suggest either replacing these by "associated with", or if that's inappropriate, clarifying the meaning. ### Global - SHOULD vs. MUST A quick grep shows 32 instances of SHOULD or SHOULD NOT in the document (not counting the two in the boilerplate). I haven't audited each one, but for many of these it's difficult to see why they're SHOULD and not MUST. My own heuristic is to think of SHOULD as a "must/unless" pair -- it's desirable to provide some guidance to the implementator as to what circumstances would justify ignoring the SHOULD. If you can't actually think of good reasons to do that, consider changing the SHOULD to a MUST. Or if you're using SHOULD in the sense of "we think you ought to implement it this way but we are trying to be considerate and not yell MUST at you all the time" it's also reasonable to use lower-case words instead of RFC 2119 keywords. I won't comment separately on each individual SHOULD in the document but I encourage you to review them. ### Section 1 "KSK (DS RRset)" Please provide a reference or other hints for those readers who don't speak DNSSEC as a first language (like me). "KSK" could probably use to be expanded on first use, too. ### Section 1.1 ``` However, since communications are established with names which remains a global identifier ``` I don't understand what that clause means. ### Section 1.2 ``` even adapted to IPv6 and ignoring those associated to an IPv4 development ``` I don't understand what this clause means. Is there a word missing between "those" and "associated", and perhaps "to" should be "with"? ### Section 1.3.2 Please expand "CSR" on first use (and provide a reference if appropriate). ### Section 3.1 - "as described" ``` as described in Figure 1 ``` Perhaps "as depicted in Figure 1"? I don't think Figure 1 can be said to be a (full) description of anything. ### Section 3.1 - "answer to" "it is not expected to answer to DNS requests" --> "it is not expected to answer DNS requests" (changed "answer to" to just "answer", there is a slightly different shade of meaning) ### Section 3.2 ``` The visible NS records SHOULD remain pointing at the cloud provider's server IP address" ``` This is the sole mention of a "cloud provider" in the document. Re-word? ### Section 4 ``` the IP address and port number to use and protocol to set secure session ``` I don't understand what that clause means (in particular "protocol to set secure session"). ### Section 4.2 For this text, ``` 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. ``` Would the below rewrite be correct? If not, please propose another. ``` By accepting the DS RR, the DM commits to advertise the DS to the parent zone. On the other hand if the DM does not have the capacity to advertise the DS to the parent zone, it indicates this by refusing the DS RR. ``` ### 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. :-( ### Section 4.5.2 ``` The DM SHOULD ignore non-empty the Pre-requisite and Additional Data section" ``` I don't know what this means. If "non-empty" weren't there, I would get it, it would just mean "ignore the pre-req and additional data sections no matter what their content is" -- so maybe the easiest fix is to delete "non-empty" (and changing "section" to "sections" while you're at it), as in ``` The DM MUST ignore the Pre-requisite and Additional Data sections, if present. ``` ### Section 4.5.2 These two paragraphs seem a little inconsistent: ``` An error indicates the MD does not update the DS, and other method should be used by the HNA. The regular DNS error message SHOULD be returned to the HNA when an error occurs. In particular a FORMERR is returned when a format error is found, this includes when unexpected RRSets are added or when RRsets are missing. A SERVFAIL error is returned when a internal error is encountered. A NOTZONE error is returned when update and Zone sections are not coherent, a NOTAUTH error is returned when the DM is not authoritative for the Zone section. A REFUSED error is returned when the DM refuses to proceed to the configuration and the requested action. ``` I would have guessed that the implication of some of the errors cited in the second paragraph is that the HNA should correct the problem and then retry. But the first paragraph seems to indicate that an HNA shouldn't bother even considering the error code, because "and other method should be used by the HNA". I'm not sure how, or if, to resolve this seeming inconsistency. ### 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? ### Section 4.6 These two paragraphs seem inconsistent: ``` The control channel between the HNA and the DM MUST be secured at both the HNA and the DM. Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the transactions between the DM and the HNA. ``` MUST the channel be secured? Or is it only SHOULD? Also, does the second paragraph really mean "secure *transport* protocols", or is the ambiguity intentional? By ambiguity, I suppose the paragraph as written might be satisfied by object-level security, for instance, and for that matter it leaves it up to the reader to even define exactly what they mean by "security". Finally, see also my DISCUSS comments -- if you actually want to mandate TLS (as implied by some of the other parts of this document, and draft-ietf-homenet-naming-architecture-dhc-options-21), you need to make some changes to this section. ### Section 4.6 Please expand SAN on first use. ### Section 7 ``` Depending how the communications between the HNA and the DM are secured, only packets associated to that protocol SHOULD be allowed. ``` This is too vague. What specifically about the means of securing the communications would lead the implementor to follow, or disregard, the SHOULD? ### 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. ### Section 12.2 Consider using "their" instead of "his". ### 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". ### 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]. ``` ### 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"?) ### 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". 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. ## 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" ## 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
I have to agree with Warren here. I do not understand how this protocol is supposed to work. It renames a bunch of DNS terms (hidden primary, primary, seconday, AXFR/IXFR, DNS update --> HNA, DM, DOI, Control Channel, Sync channel) which makes the document very hard to read. For those parts where protocol glue is needed to use these DNS technologies, the document presents no solutions. I don't understand if users can create their own named zones, or whether this is only provider generated zones. The latter seems less useful to the user, the former seems to need more specification on how to handle registry/registrar/registrant matters (especially with respect to DS) The security seems to mix up transport security with TLS and data integrity security of the DNS protocol (typically TSIG or SIG0, but the document claims this cannot be used) Having provider generated homenet named DNS zones makes scanning for hostnames in those zones much easier than scanning an entire /64 IPv6 for vulnerable devices. Eg well known host names like "tv" or "LG" or "washing_machine" or just any <= 8 character string based hostnames or dictionary attacks. Like Warren, I've added my notes as comments without splitting them further into DISCUSSes or COMMENTs
* the CPE/HNA router is unaware of the process, and cannot respond to queries for these names and communications to these names require an Internet connectivity is order to perform the DNS resolution. Such dependence does not meet the requirement for internal communications to be resilient to ISP connectivity disruptions [RFC7368]. If there is a host within the home network that is the DHCP/DNS server, then this does not require further support from a CPE/HNA or internet uplink. For example Linux openwrt with avahi and dnsmasq is a common deployment of this: https://openwrt.org/docs/guide-user/base-system/dhcp Arguably, one could say openwrt is the CPE/HNA in such case, provided that user has their own domain they can send "dynamic DNS" updates for on the public internet hosting their homenet zone. * the CPE/HNA router cannot control the process. Any host can do this regardless of whether or not the home network administrator wants the name published or not. There is therefore no possible audit trail. To be fair, even with dpeloying all of homenet, those hosts can still keep doing this - choices made here does not affect this, so I don't see this as a valid argument one way or the other. The DOI is also responsible for ensuring the DS record has been updated in the parent zone. This sentence carries a LOT of process/protocol work. Will it use CDS? How is the authorization boot strapped? Does it work for non-ISP generated zones, eg "toronto.nohats.ca" ? If so, how does it handle delegation of NS and DS ? The information exchanged between the HNA and the DM uses DNS messages protected by DNS over TLS (DoT) [RFC7858]. In the future, other specifications may consider protecting DNS messages with other transport layers, among others, DNS over DTLS [RFC8094], or DNS over HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250]. what does "protected" here mean? Privacy protection? Because if it is using DNS Dynamic Updates, the data authenticity protection comes from a TSIG/SIG0 key. The main issue is that the Dynamic DNS update would also update the parent zone's (NS, DS and associated A or AAAA 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 - But isn't this simply a "forward" statement for the zone to the private IP of the local DNS authoritative server within the local DNS recursive server? That way, the recursive dns IP does not need to have a NS record at all, so there is also no risk of accidentally pushing it out to public servers and replacing the real NS records? * By default, the HNA uses a single IP address for both the Control and Synchronization channel. However, the HNA MAY use distinct IP addresses for the Control Channel and the Synchronization Channel - see Section 5 and Section 4.3 for more details. Why does this matter and need mentioning? TSIG/SIG0 would not care about the IP address used, and/or whether it is NATed? 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. Ah, so this is a preconfigured IP/name/TSIG/SIG0 key, and limits the HNA to only CPE supported DNS providers? Either this locks in where users can host their homenet zone based on CPE preconfiguration, or it is just a fancy way of saying "configure your DNS server with your remote DNS settings" (which would not need anything of this document to run, and I was hoping this document was going to provide some automation for this?) The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI provides this value to the parent zone. A common deployment use case is that the DOI is the registrar of the Registered Homenet Domain and as such, its relationship with the registry of the parent zone enables it to update the parent zone. This now means that the solution is limited to those scenarios that have: - CPE support for homenet RFCs - ISP support for CPE for HNA for DOI that supports DNSSEC DS submission via EPP, or - A Registrar that is also DNS hoster AND supports DNSSEC AND supports CDS/CDNSKEY AND supports AXFR/IXFR AND supports homenet RFCs I would argue these requirements are far more restrictive than: - CPE with support for stock Dynamic DNS updates for itself only (eg client registrations, but could also be autoatic conversion of MDNS/.local to its local homenet zone. - CPE that can run recursive with an authoritative zone - Any DNS hoster that supports AXFR/IXFR, DNSSEC and CDS/CDNSKEY - Any Register that supports DNSSEC with the only difference that the latter one needs a one step registration of the initial DS record. Though the HNA may also later directly update the values of the DS via the Control Channel, it is RECOMMENDED to use other mechanisms such as CDS and CDNSKEY [RFC7344] for transparent updates during key roll overs. If this is going to be a fully automated enduser CPE solution, this RECOMMENDED is too weak. It should be a MUST because otherwise DNSSEC rollover is just impossible. Section 4 this all seems to imply "registered domains". Can these be subdomains? Eg can I own nohats.ca and configure one CPE for toronto.nohats.ca. and the other for amsterdam.nohats.ca. ? This involves talking to NS for nohats.ca for sub delegation, but I don't see that mentioned anywhere ? Section 4.5.1 How would the bootstrap work. I pick "paulhomenet.com" as my zone, but then my CPE doens't have nameservers for it, so it does AXFR via the Control Channel ? And get a set of NS records back that my CPE adds to paulhomenet.com ? And then it becomes authoritative? How is the ownership of paulhomenet.com tested? if it is registered, who will be the registrar, registrant? Is ".io" supported? Or other TLDs? Or will this all be under "nameyoupick.homenet.cpevender.com" ? AXFR is normally based on authentication of domain name plus shared key. How does that work when creating a _new_ domain name by the enduser? How can this be authenticated without knowing the zone name ? Section 4.5.3 The default IP address used by the HNA for the Synchronization Channel is the IP address of the Control Channel. To provide a different IP address, the HNA MAY send a DNS UPDATE message. What does this DNS UPDATE message contain? It says NS records but what name? And as this is the authoritative server sending an DMS UPDATE message, it would need to send the RRSIG too, which means it needs to set the entire NS RRset? Which means it needs to know the remote NS records, but how can it do that without first already using the proper IP address to talk to the systems? Section 4.5.4: If a deletion is processed, what happens with the domain name? Will all its NS records be deleted and it is now a lame delegation? How is the enduser supposed to get their domain under their own control again? Is it ever truly theirs? 4.6 Securing the control channel Isn't this channel DNS dynamic updates? Are these not secured by TSIG/SIG0 ? Did you mean TLS only for privacy considerations and not security considerations? Apparently this is not the case? A pure DNS solution using TSIG and/or SIG(0) to authenticate message was also considered. A way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0) space seems overly problematic, Why not use TSIG? That is literally the keyed hash of a blob, and the blob can be an OAUTH2 token ? ection 4.7 Interface Binding: the Hidden Primary Server will almost certainly listen on the WAN Interface, whereas a regular Homenet Authoritative Servers would listen on the internal home network interface. Does that matter if either one provides a routable public IPv6 address? 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. I thought it was serving endusers so that local things would keep working with a broken internet link? Or at least "serve" its "resolver" part. And also serve as auth server to take in DNS Dynamic Updates? Section 5: Uploading and dynamically updating the zone file on the DM can be seen as zone provisioning between the HNA (Hidden Primary) and the DM (Secondary Server). This can be handled via AXFR + DNS UPDATE. I don't see how the start of this works, when the end user tells their CPE the name of their local homenet zone ? (also I think you mean AXFR/IXFR ? The DNS UPDATE would be the local machine talking to the local CPE ? Not between HNA and DM?) Note that there is no standard way to distribute a DNS primary between multiple devices. As a result, if multiple devices are candidate for hosting the Hidden Primary, some specific mechanisms should be designed so the home network only selects a single HNA for the Hidden Primary. Selection mechanisms based on HNCP [RFC7788] are good candidates. This seems rather under specified. If there is only one, how is it found and used? I was expecting that the domainname configured on the CPE would be queried for DNS UPDATES by clients. But looking at RFC2136 Section 4: From a requestor's point of view, any authoritative server for the zone can appear to be able to process update requests, even though only the primary master server is actually able to modify the zone's master file. Requestors are expected to know the name of the zone they intend to update and to know or be able to determine the name servers for that zone. If the requestor has reasonable cause to believe that all of a zone's servers will be equally reachable, then it should arrange to try the primary master server (as given by the SOA MNAME field if matched by some NS NSDNAME This would be only one possible target based on the domainname given to a device via DHCP. What "some specific mechanism should be designed" will be deployed for the clients (eg my phones, laptop and TV ?) I think the only real chance they have of doing this (without waiting 10 years for all our electronics to cycle/get updated) is standard the SOA MNAME's IP address, eg RFC 2136 DNS Dynamic Updates. My devices already support this. So that redefines the above problem to "Who becomes the Hidden Primary", which I assumed was the CPE supporting this framework ? And if there are more than one CPE that can do this, it should be configured by the user to be done only by one CPE - similar to have a user should ensure there is only one DHCP server running in the network ? Section 5: First the HNA (primary) notifies the DM (secondary) The entire document would have been so much more readable if HNA and DM had not been introduced and primary/secondary was used througout. The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they only arrive from the DM Synchronization Channel. Unless the CPE is preconfiguted with service providers, these ACLs cannot come by default? Also, if this channel uses TSIG (which also needs preconfiguration) then it can already ACL this based on the known shared secret. No IP based ACLs needed (which are risky to put into CPE firmware as networks change) Section 7: Why can't the HNA be the local authoritative server for clients? Why should this functionality be split in two? It just means another recursive resolver needs to query the HNA (and have it configured as forwarder) for the local homenet zone (in case uplink goes down). For example, this could be a single instance of the Bind DNS server dong both authoritative and recursive DNS. Dropping received queries for DNS servers is always a bad idea, as it just causes the client to retransmit. Always returning an error is the common DNS reply strategy. This section goes against common best practise for DNS servers. Section 9: [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both the authoritative server and the resolver. The resolver side is out of scope of this document, and only the authoritative part of the server is considered. But if things must work without an internet connection working, then the resolver needs to be configured for the homenet domain to ask the HNA and not go the regular upstream path. So it should be in scope I believe. Typically, the DS RRset can be updated manually in the parent zone with nsupdate for example. I don't think this applies to "typical DS". The DS RRset lives on the "wrong" side of the zone cut. A dns update client is would not have permissions to update its parent zone with dns updates, only its own child zone. So this would be better done by pushing a CDS record and let the parent pull the CDS and recreate its own DS record. This method is not widely supported by TLDs, and I dont know how this solution would work for second or third level domains, eg if I use provider X to host nohats.ca, and provider Y for my home internet and I want toronto.nohats.ca to be my home network name using CPE vendor Z. Section 10: The ISP SHOULD ensure that the DNS cache has expired before re- assigning the prefix to a new home network. How does it do that? It can't send queries to get the data for TTL anymore, since the network already got renumbered and returned and the NS servers removed. The records now only live in worldwide caches. You don't know the TTL. Unless you grabbed the data just before getting it returned. But that is also unlikely, eg imagine a user taking down their CPE because they moved house. From the ISP point of view the network just vanished including all its nameservers for it (the public ones will work for a while but will the ISP act within that time?) And what of the CPE/HNA set TTLs on data of 1 year ? The TTL math in section 10 makes no sense to me as the CPE/HNA could set it to whatever it wants. The ISPs secondary servers cannot change the TTL (it is protected by DNSSEC from being modified) 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. The privacy and security of the DNS 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 ? 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? 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? 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 ?
(updated ballot for the -21 text) ** 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. -- Is there a reason this can’t be a MUST?
I support Warren, John and Paul’s DISCUSS positions. Thank you for addressing my COMMENTs.
# Internet AD comments for draft-ietf-homenet-front-end-naming-delegation-25 CC @ekline ## Comments ### S6.3 * Consider adding a forward reference to S6.6 at the of the last paragraph, just to say that the DM authenticates the HNA using a mechanism that has nothing to do with its (continuously changing) IP address(es). ### S6.5 * This says the authentication of the control channel SHOULD be based on certificates, but S6.6 seems to be saying that certificates are a MUST. Perhaps I'm just misunderstanding something. The language in S6.6 seems much more preferable. ### S10 * A weakness of this IPv6 ACL scheme would seem to be that it can be very hard for the ISP to know precisely *which* device within the access link address space (or delegated prefix address space) should be trusted to act as the HNA. Can any device in the home, or with access to the GUAs on the access link (assuming it's numbered), start being an HNA? The dhc-options draft seems to suggest that the HNA needs to have the requisite credentials for mutual TLS. If that's actually REQUIRED then that seems strong enough, and also worth mentioning here. ## Nits ### S6.1 * "The HNA then perhaps and DNS Update operation to the DOI" -> "The HNA then performs a DNS Update operation to the DOI" ### S9 * "differs the regular" -> "differs from the regular"
Supporting Warren and Roman's discuss.
My previous DISCUSS position for the record: https://mailarchive.ietf.org/arch/msg/homenet/GyVNZWfNBoYXNn3erPG2HNEVtXA/ After (in-person) discussions with one of the authors (Michael Richardson), and all of the changes made to the document, I am changing my original (blocking) DISCUSS position to (non-blocking) Abstain. The authors have made substantial changes to improve the document (https://www.ietf.org/rfcdiff?url1=draft-ietf-homenet-front-end-naming-delegation-18&url2=draft-ietf-homenet-front-end-naming-delegation-22&difftype=--html). I still find it very hard to follow and lacking in detail in many places (hence the Abstain), but feel that it is sufficiently improved that I'm removing my DISCUSS. Much much thanks to the authors for significant amounts of hard work (and also remaining polite during what I'm sure must have been very frustrating and discouraging).
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.
I support Warren's DISCUSS.
I support the other discuss positions on this document.
Like other ADs, I found this document hard to read. Rather than defining a JSON schema file in Appendix B, it would be much better if this was defined in YANG, which is the IETF standard data modelling language for network configuration. A JSON encoding for YANG defined data also exists so it would still work for what is proposed here. I also ran a grammar tool over the XML for -19, and it flagged up these warnings that you might want to consider checking/fixing in the next revision (they are not necessarily all valid): Spellings: Sometimes you use HomeNet, in other places, Homenet, and also homenet. Pre-requisite, SIgning, Grammar Warnings: Section: abstract, draft text: 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). Warning: This phrase is redundant. Consider using outside. Suggested change: "outside" Section: 1, draft text: The appendices discuss several management (see [sec-reverse]) provisioning (see [sec-reverse]), configurations (see [info-model]) and deployment (see [sec-deployment] and [sec-ex-manu]) aspects. Warning: Possible agreement error. The noun management seems to be uncountable; consider using: some management. Suggested change: "some management" Section: 3, draft text: The IPv6 ULA and the private IPv4 addresses may be useful to publish, if the home network environment features a VPN that would allow the home owner to reach the network. Warning: This noun normally spelled as one word. Suggested change: "homeowner" Section: 3, draft text: Since communications are established with names which remain a global identifier, the communication can be protected by TLS the same way it is protected on the global Internet - using certificates. Warning: Possible typo: you repeated a whitespace Suggested change: " " Section: 4, draft text: While the IETF has defined a DNS based mechanism Dynamic Update [RFC2136], in many – as far as the co-authors know in all cases – case commercial “Dynamic Update” solutions are primarily implemented via a HTTPS RESTful API. 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: 4, draft text: Any host can do this regardless of whether or not the home network administrator wants the name published or not. Warning: Consider shortening this phrase to just whether. It is correct though if you mean 'regardless of whether'. Suggested change: "whether" Section: 4, draft text: The DNS zone are then synchronized using an alternative mechanism as the one designed for zone synchronisation inherited from the primary used case where the synchronization is performed at the node level. Warning: Do not mix variants of the same word ('synchronisation' and 'synchronization') within a single text. Suggested change: "synchronization" Section: 4, draft text: Our proposal use the standard mechanism defined by DNS for zone synchronisation. Warning: Possible agreement error - use third-person verb forms for singular and mass nouns: uses. Suggested change: "uses" Section: 4, draft text: Our proposal use the standard mechanism defined by DNS for zone synchronisation. Warning: Do not mix variants of the same word ('synchronisation' and 'synchronization') within a single text. Suggested change: "synchronization" Section: 5.1, draft text: Such a domain name does not need to be human readable. Warning: This word is normally spelled with hyphen. Suggested change: "human-readable" Section: 5.1, draft text: Instead these keys are solely used by the HNA for the authentication to the DM. Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Instead," Section: 5.1.1, draft text: One potential mechanism to provide the parameters would be to provide the user with a JSON object which they can copy paste into the CPE - such as described in [info-model]. Warning: Did you mean copy and paste? Suggested change: "copy and paste" Section: 6.1, draft text: The “.local” as well as “.home.arpa” are explicitly not considered as Public Homenet zones and represented as Homenet Zone in [fig-naming-arch]. Warning: The singular proper name 'Homenet' must be used with a third-person or a past tense verb: zones, zoned. Suggested change: "Zones" Section: 3.1, draft text: In some cases, the HNA and Homenet Authoritative Servers may be combined together which would result in a common instantiation of an authoritative server on the WAN and inner homenet interface. Warning: 'combined together' is redundant. Use combined Suggested change: "combined" Section: 6.2, draft text: The Control Channel and the Synchronization Channel are the interfaces used between the HNA and the DOI. Warning: The singular proper name 'Channel' must be used with a third-person or a past tense verb: is, was, were. Suggested change: "is" Section: 4.1, draft text: In term of RRset information this includes: Warning: Did you mean the commonly used phrase In terms of? Suggested change: "In terms of" Section: 4.2, draft text: Though the HNA may also later directly update the values of the DS via the Control Channel, it is RECOMMENDED to use other mechanisms such as CDS and CDNSKEY [RFC7344] for transparent updates during key roll overs. Warning: This expression is normally spelled as one or with hyphen. Suggested change: "roll-overs" Section: 4.5.2, draft text: A SERVFAIL error is returned when a internal error is encountered. 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: 4.5.4, draft text: As indicated by [RFC2136] Section 2.5.2 the delete instruction is set by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0 and the RDATA MUST be empty. Warning: After 'the', do not use a verb. Make sure that the spelling of 'delete' is correct. If 'delete' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section: 7.6, draft text: TLS [RFC8446]) MUST be used to secure the transactions between the DM and the HNA and the DM and HNA MUST be mutually authenticated. Warning: Unpaired symbol: '(' seems to be missing Section: 4.7, draft text: This results in a limited number of possible exchanges (AXFR/IXFR) with a small number of IP addresses and an implementation SHOULD enable filtering policies as described in [sec-cpe-sec-policies]. Warning: Specify a number, remove phrase, use a few, or use some Suggested change: "a few" Section: 8, draft text: Note that the Control Channel and the Synchronization Channel are by construction different channels even though there they may use the same IP address. Warning: The singular proper name 'Channel' must be used with a third-person or a past tense verb: is, was, were. Suggested change: "is" Section: 8, draft text: On the other hand, the Synchronization Channel is set between the DM working as a client using port ZZZZ ( another high range port) toward a service provided by the HNA at port XX. Warning: Don't put a space after the opening parenthesis. Suggested change: "(" Section: 8.1, draft text: The AXFR request from the DM to the HNA MUST be secured with TLS [RFC8446]) following DNS Zone Transfer over TLS [RFC9103]. Warning: Unpaired symbol: '(' seems to be missing Section: 7, draft text: The HNA SHOULD drop any packets arriving on the WAN interface that are not issued from the DM – as opposed to server as an Homenet Authoritative Server exposed on the Internet. Warning: The usual proposition after "arriving" is "at" not "on". Did you mean arriving at? Suggested change: "arriving at" Section: 7, draft text: The HNA SHOULD drop any packets arriving on the WAN interface that are not issued from the DM – as opposed to server as an Homenet Authoritative Server exposed on the Internet. Warning: Use a instead of 'an' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university' Suggested change: "a" Section: 10, draft text: Only TLS packet or potentially some DNS packets ( see XoT) packets SHOULD be allowed. Warning: Don't put a space after the opening parenthesis. Suggested change: "(" Section: 7, draft text: The HNA SHOULD reject any incoming messages other than DNS NOTIFY response, SOA query, IXFR query or AXFR query. Warning: Possible typo: you repeated a whitespace Suggested change: " " Section: 8, draft text: More specifically, a common case is that the upstream ISP provides the IPv6 prefix to the Homenet with a IA_PD [RFC8415] option and manages the DOI of the associated reverse zone. 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: 11, draft text: Such constraints does not raise major concerns either for hot standby or load sharing configuration. Warning: You should probably use do. Suggested change: "do" Section: 11, draft text: Outsourcing the DNS Authoritative service from the HNA to a third party raises a few privacy related concerns. Warning: Possible agreement error. The noun privacy seems to be uncountable; consider using: little privacy. Suggested change: "little privacy" Section: 11, draft text: A well designed User Interface would combine a policy for making a service public by a name with a policy on who may access it. Warning: This word is normally spelled with hyphen. Suggested change: "well-designed" Section: 12.1, draft text: This MAY involved a mix of exchanges protected by TLS and exchanges not protected by TLS. Warning: The modal verb 'MAY' requires the verb's base form. Suggested change: "involve" Section: 12.1, draft text: 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]. 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: 12.3, draft text: In addition IPv6 enables temporary addresses that makes them even more volatile [RFC8981]. Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "addition," Section: 12.4, draft text: To provide resilience against CPE breaks, it is RECOMMENDED to backup these keys to avoid an emergency key roll over when the CPE breaks. Warning: Did you mean to back up? Suggested change: "to back up" Section: 17, draft text: The authors wish to thank Philippe Lemordant for his contributions on the early versions of the draft; Ole Troan for pointing out issues with the IPv6 routed home concept and placing the scope of this document in a wider picture; Mark Townsley for encouragement and injecting a healthy debate on the merits of the idea; Ulrik de Bie for providing alternative solutions; Paul Mockapetris, Christian Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC capabilities of small devices; Simon Kelley for its feedback as dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael Abrahamson, and Ray Bellis for their feedback on handling different views as well as clarifying the impact of outsourcing the zone signing operation outside the HNA; Mark Andrew and Peter Koch for clarifying the renumbering. Warning: The usual preposition for "contribution" is "to". Did you mean contributions to? Suggested change: "contributions to" Section: A.1, draft text: This section details what needs to be provisioned into the HNA 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"
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.