[homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

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) supports RFC2136 dynamic DNS updates - https://help.dyn.com/tsig/,
 as does Dynu - https://www.dynu.com/DynamicDNS/IPUpdateClient/NSUpdate . I'm
 assuming that many others to too...

8:
 O: "For a very few numbers of hosts, the use of such a system provides an
 alternative to the architecture described in this document."
 C: Why? There are a huge number of users/hosts using Dynamic DNS services, and
 many of the Dynamic DNS providers are doing quite well, so I don't understand
 how their users count as "a very few".

 9:
 O: "Dynamic
 DNS - even adapted to IPv6 and ignoring those associated to an IPv4
 development - does suffer from some severe limitations:"
 C1: Why do you say "even adapted to IPv6"? IPv6 Dynamic DNS already exists and
 is deployed -- e.g:
 https://www.noip.com/blog/2019/11/03/ip-now-offers-ipv6-dynamic-dns/ C2: " and
 ignoring those associated to an IPv4 development" - I'm unable to parse this.

 10:
O: "* 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."
C: In many many cases the CPE itself is the Dynamic DNS clinet, e.g:
https://www.noip.com/support/knowledgebase/how-to-configure-ddns-in-router/
lists 9 vendors of CPE whose devices do DDNS, and I'm aware of many many more.

11:
O: "* 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."
C: This proposal doesn't "fix" that -- any host will stil be able to run a DDNS
client and publish a name. I don't really view this as a bug, but if you are
pointing out "issues"/"limitations" with something that you are aiming to
replace, you should clarify that your proposal doesn't address some of them.

12:
O: "* "all the good names are taken" - current services provide a small
 set of zones shared by all hosts across all home networks. More
 especially, there is no notion of a domain specific home network."
 C: That's completely wrong - a number of Dynamic DNS providers do this. 10
 seconds with a search engine show:
 https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
 https://www.namecheap.com/support/knowledgebase/article.aspx/595/11/how-do-i-enable-dynamic-dns-for-a-domain/
 https://blog.jswart.xyz/posts/cloudflare-dynamic-dns/
 https://support.google.com/domains/answer/6147083?hl=en

 13:
 O: "* Dynamic Updates solution are not interoperable and each provider
 has its own way to implement it."
 C: This is also wrong. A number of providers support the 'dyndns2' protocol,
 including Dyn DNS, Amazon Route 53, Google Domains, No-IP, etc.

 Section 1.3.1:
 14:
 O: "A specific vendor with specific relations with a registrar or a
 registry may sell a CPE that is provisioned with provisioned domain
 name."
C: "is provisioned with provisioned"

15:
O: "Such domain name does not need to be necessary human readable."
C1: "Such *a* domain name"
C2: Remove "necessary"
C3: Is it really useful to have a name like
"aheriuthga23.somevendor.exmaple.com"?

16:
O: "One possible way is that the vendor also provisions..."
C: One possible way to what? The previous sentence talks about a vendor selling
CPE, so one possible way for them to sell something? You probably need some
text around "one way for a vendor to bootstrap" or "provision this", or
something. Needs work.

17:
O: "One possible way is that the vendor also provisions the HNA with a
 private and public keys as well as a certificate."
C1: Either "with a private and public keys" or "with a
 private and public key"
C2: You say with keys and a certificate, and then talk about what the purpose
of the keys are, but not what the cert is used for.

18:
O: "Instead these
 keys are solely used by the HNA to proceed to the authentication."
C: "solely used" - does this mean that they cannot / must not be used for
anything else? C: "proceed to the authentication" does not parse. Perhaps "used
for authentication" or "to the authentication phase" (not that that is really
described either)

19:
O: "The reason to combine the domain name and the
 key is that DOI are likely handle names better than keys and that
 domain names might be used as a login which enables the key to be
 regenerated."
C: "are likely handle" doesn't parse.
C: "domain names might be used as a login" - the domain name and what?
Presumably I cannot just login with the credential "foo.cpe.example" without
some other piece of information or anyone could regenerate the keys. And in
that case, why are keys pre-provisioned on the device?

20:
O: "When the home network owner plugs the CPE at home, ...""
C: "plugs in the CPE"

Section 1.3.2. Agnostic CPE:
21:
O: "An CPE that is not preconfigured may also take advantage to the
 protocol defined in this document but some configuration steps will
 be needed."
C: s/An CPE/A CPE/
C: s/may also take advantage to the protocol/may also take advantage of the
 protocol/ (actually I think "may also use the protocol", but whatever...)

22:
O: " 1. The owner of the home network buys a domain name to a registrar,
 and as such creates an account on that registrar"
C: s/to a registrar/from a registrar/

23:
O: "A good way to provide the
 parameters would be the home network be able to copy/paste a JSON
 object"
C: home networks cannot copy and paste. Perhaps "One potential mechanism would
be to provide the user with a JSON object which they can copy and paste into
the CPE" (or similar).

24:
O: "What matters at that point is the DOI
 being able to generate authentication credentials for the HNA to
 authenticate itself to the DOI.
C: s/being able/is able/
C: It also isn't that it needs to be able to do this, but rather that it can
provide authentication credentials to the HNA.

25:
O: "If the DOI is not the registrar, then the proof of ownership needs
 to be established using protocols like ACME [RFC8555] for example
 that will end in the generation of a certificate."
C: Why does it need to "end in the generation of a certificate"? All you need
is proof of ownership, yes? And ACME is generally used to prove ownership of a
hostname / SAN - it is very unclear here what exactly you are proving ownership
of / to -- the hostname to the IP/device? Presumably not because the purpose of
this is to create that delegation...

26:
O: "ACME is used
 here to the purpose of automating the generation of the
 certificate, the CA may be a specific CA or the DOI. "
C: Why "a specific CA or the DOI"? If I get a (valid) cert from any old CA, is
that not valid? And it I get a cert from the DOI, it is acting as a CA, isn't
it? What is this actually trying to say?

27:
O: "With that
 being done, the DOI has a roof of ownership and can proceed as
 above."
C: "proof of ownership"

Section 3. Architecture Description
28:
O: "Note that
 Appendix B defines necessary parameter to configure the HNA."
C: Does this mean that Appendix B is normative?
C: s/parameter/parameters/

29:
O: "The DOI will
 serve every DNSSEC request of the Public Homenet Zone coming from
 outside the home network."
C: The DOI gets DNS requests, not DNSSEC requests (there isn't really such a
thing as a DNSSEC request) C: "every"? C: What about if a device inside the
home queries the DOI? It should still respond, yes?

30:
O: "the resolution is expected to be handled by the Homenet
 Resolver as detaille din further details below."
C: "detailed in"

31:
O: "Registered Homenet Domain Name"
C: You don't have "Registered Homenet Domain Name" in the terminology section,
either add it or (better yet) s/Name/name/

32:
O: "The HNA SHOULD build the Public Homenet Zone in a single view
 populated ..."
C: It is unclear what "in a single view" means here - views are a way of
mapping clients to different sets of answers, and they are not in a zone.

33:
O: "Once the Public Homenet Zone has been built, the HNA communicates and
 synchronizes it with the DOI using a primary/secondary setting as
 described in Figure 1. "
C: It is unclear what "using a primary/secondary setting" means, and it isn't
"described in Figure 1."

34:
O: "The HNA acts as a hidden primary [RFC8499]"
C: 8499 doesn't define hidden primary; it does define Hidden master and Primary
server. It also says that a master and a primary are the same, but the
reference should be clearer.

35:
O: "the DM behaves as a secondary responsible to distribute the
 Public Homenet Zone to the multiple Public Authoritative Servers that
 DOI is responsible for."
 C: s/responsible to distribute/responsible for distributing/
 C: "the multiple Public Authoritative Servers" - which servers? A DOI may have
 many many sets of authoritative servers, only some of which may be
 authoritative for this zone.

 36:
 O: "one or more Distribution Channels (Section 6 that distribute the
 Public Homenet Zone from the DM to the Public Authoritative Server
 serving the Public Homenet Zone on the Internet."
C: (Section 6/ (Section 6)/
C: s/Public Authoritative Server/Public Authoritative Servers/

37:
O: "Resolution is performed by the DNSSEC resolvers."
C: Which "the DNSSEC resolvers"? ("the" implies a specific set) Also, why are
these "DNSSEC resolvers"? Does this mean that non-DNSSEC validating DNS servers
cannot resolve these names (presumably not, but...)

38:
O: "When the resolution
 is performed outside the home network, the DNSSEC Resolver resolves
 the DS record on the Global DNS and the name associated to the Public
 Homenet Zone (myhome.example) on the Public Authoritative Servers."
C: What is this actually trying to say? The DS record is resolved on the
"Global DNS" but the name is resolved on the "Public Authoritative Servers" -
is this supposed to mean that the Public Authoritative Servers are not part of
the Global DNS? And the DS record is part of the "name associated to the Public
Homenet Zone", but published at the parent. Is this supposed to just be "is
resolved like any other name"?

39:
O: "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."
C: "the Homenet DNSSEC Resolver" - this implies that this is only one. It also
seems odd to say that it "SHOLD be able to", and then immediately say that this
can't actually be done because this isn't any (current) way to configure the
DNSSEC information (or, if it is defined in 7788 I missed it)

40:
O: "How the Homenet Authoritative Servers are provisioned is also out of
 scope of this specification. It could be implemented using primary
 and secondary servers, or via rsync."
C: It is unclear what this is trying to say - "are provisioned" with what? It
this trying to say "how the zone information is syncronized between the
servers"? Or how the domains are provisioned onto the servers?

41:
O: "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 - 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?

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.

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.)

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?

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?

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"

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?

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?

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?