Telechat Review of draft-ietf-homenet-front-end-naming-delegation-25
review-ietf-homenet-front-end-naming-delegation-25-dnsdir-telechat-huston-2022-12-18-00

Reviewer: Geoff Huston
Review result: Ready with Issues

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

I am surprised that this draft has had 24 prior iterations and still has
managed to raise so many questions on the part of this reviewer.

These are not necessarily "major" issues, but there are many of them, including some
questions about the precise role of this document, noted below, so I think
"ready with issues" best encompasses my review advice.

It strikes me that the overall intent canm be summarised in one sentence: If
a homenet domain wished to publish in the DNS a number of homenet-located
services in the DNS and does not want to use a conventional DNS zone
delegation then a hidden primary DNS configuration may be appropriate.

The document does not make it clear if it is a discussion of design choices
or a normative protocol specification and the flip between the two modes is
highly confusing to the reader.

It may not be the normal practice in the Homenet working group but this
specificatiopn seems to be begging for at least two independent
implementations with proven interoperabil;ity as a precondition to
publication. The specification seem to be indistinct and vague in some
aspects as noted in the detaled comments and some feedback from
implementation might help

There are a few instances of lower case "must". Given that this uses
the normative terms it would be helpful to use a different word
if the normative MUST is not intended here, and use a capitalized version if
it was.

Document walk-through:
 
Section 2

It would be useful to include a catchall that explains that all other DNS
terms are used in the document with meanings as described in RFC8499

The definition  of "Public Authoritative Service" includes the comment that
"for higher resiliency networks, are often implemented in an anycast
fashion" which seems like a spurious comment to me in the context of this
document.

On a more general note I find it curious that the documnent is inventing 
new names for existing DNS concepts - "Homenet Zone" is just a Zone, 
"Registered Homenet Domain" is just a domain. Aside from adding "Homenet"
everywhere, does this deviation from a standard nomenclature for DNS
components provide some essential additional clarity to the document? This 
reviewer tends to answer this question in the negative.


Section 4.1 CPE Vendor

The text notes: "Such a domain name is probably not human friendly, and may
consist of some kind of serial number associated with the device being
sold." The use of a specific reference to a serial number in the domain name
is not clear to this reviewer. Surely the point is that such a
pre-configured domain name is unique to each individual CPE device.

4.1.1.  Agnostic CPE

s/roof/proof/

It is not clear to me that the issue of circularity in the use of ACME has been
appropriately considered. If the role of ACME is for the name holder is attempting
to demonstrate their control of an as-yet-undelegated domain via ACME then
how can the CA test this control if the domain is not delegated?

5. Architecture Description

Grammar: "this prevents HNA to handle the DNS traffic from the Internet
associated with the resolution of the Homenet Zone." surely this should read
"HNA from handling"?

"The DOI benefits from a cloud infrastructure" - This is not necessarily the
case. What technology the publically accessible DNS authoritative name
servers (or what this documnent oddly calls "DOI") uses to implemment their
service (cloud or otherwise) is up to them, not this document.

"In the case the HNA is a CPE, outsourcing to the DOI protects the home
network against DDoS for example." If only this were the case. If the CPE
uses a public network address then all form of unsolocited traffic can be
directed to it. Directing DNS authoritative server queries elsewhat does not
really provide any meaningful DDOS protection.

"The description of such a synchronization mechanism is the purpose of this
document." At this point I am left wondering about the purpose of this
document. If you strip the customised nomenclature then this document
advocates the use of a hidden primary for homenets. How secondaries
synchronise from a hidden primary is already existing practice. Why do we
need a dedicated document to add the work "homenet" to an already well
understood mechanism?

"The HNA signs the Public Homenet Zone with DNSSEC." - is this a MUST, a SHOULD,
or a MAY"

"The HNA handles all operations and keying material required for DNSSEC, so
there is no provision made in this architecture for transferring private
DNSSEC related keying material between the HNA and the DM." This is a
curious limitation as it precludes the use of authoritative servers that use
DNSSEC signing-on-the-fly. The document should note this limitation and
provide some justification for the limitation. Is there a genuine issue here
or is it precluded becuase it is just too hard to document here?

"Resolution is performed by DNS(SEC) resolvers." This is a paragraph that
a consideration of resolvers whether or not they perform DNSSEC validation,
and then considers the context of DS validation. This is a clumsy construction.

5.2 Distribution Manager (DM) Communication Channels

"The information exchanged between the HNA and the DM uses DNS
messages protected by DNS over TLS (DoT) [RFC7858]." - is this a MUST,
SHOULD or a MAY? Or at least use a forward reference to section 6.6.

"The Distribution Channel is internal to the DOI and as such is not
normatively defined by this specification." If the objective
is interoperation between different implementations then surely
this would benefit from a normative description.

6.  Control Channel

"The HNA is always initiating the exchange in both directions." - the HNA
always initiates communications between the HNA and the DM.

6.1.  Information to Build the Public Homenet Zone

The document is coy on the normative requirement for DNSSEC-signing
of the home zone until this point, and still is here. The sentence
states: "All the content of the zone MUST be created by the HNA, because
the zone is DNSSEC signed.", yet I can find no normative requirement 
for the zone to be DNSSEC signed.

"this information exchange is mandatory." It would be preferable to rephrase
this using normative language.

"The HNA then perhaps and DNS Update operation to the DOI, updating
the DOI with an NS, DS, A and AAAA records. " This is not a sentence.

"These indicates where its Synchronization Channel is." this is very 
unclear. Its unlikey that the DS records would be useful in this context.

6.2.  Information to build the DNSSEC chain of trust

"The HNA SHOULD provide the hash of the KSK via the DS RRset, so that
the DOI can provide this value to the parent zone. " - this does
not address the situation where the HNA uses a hash algorithm that is not
supported by the parent ands the parent performs a check on the DS prior to 
insertion into the zone (i.e. the rationale for the use of CDNSKEY). Should
the document address this casze, as in subsequent text in this paragraph
it explicitly mentions the is CDNSKEY

6.3.  Information to set up the Synchronization Channel

"If the HNA detects that it has been renumbered, then it MUST use the
Control Channel to update the DOI with the new IPv6 address it has
been assigned." - and what happens when its IPv4 address has changed?

"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." - this is unclear - is there a better way of expressing this?

6.5.  Messages Exchange Description

   
"Multiple ways were considered on how the control information could be
exchanged between the HNA and the DM.

This specification defines a mechanism that re-use the DNS zone
transfer format.  Note that while information is provided using DNS
exchanges, the exchanged information is not expected to be set in any
zone file, instead this information is used as commands between the
HNA and the DM.  This was found to be simpler on the home router
side, as the HNA already has to have code to deal with all the DNS
encodings/decodings.  Inventing a new way to encode the DNS
information in, for instance, JSON, seemed to add complexity for no
return on investment."

Is this justification a necessary part of a specification? It strikes
me that a commentary on the design decisions has no place in a normative
specification. At best a seperate RFC and if the desigire is a single
document then its best to make this an appendix.

"After a predefined timer" Best to NEVER use an unspecified timer in a
normative specification. Either give a value or give a range of values
and say "pick at random"

6.6.  Securing the Control Channel

"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]." Given that the three features used by this specificate
when using DoT is mutual authentication using TLS, payload intgegrity
and channel encryption, then DOH and DOQ appear to offer similar
functionalty and could be incorporated into this specification in a
seamless manner.

Regarding DNS over DTLS please see section 1.1 of RFC8094.

10.  Public Homenet Reverse Zone

This section is very IPv6-centric. What are the considerations in this
specification that apply to IPv4?

11.  DNSSEC compliant Homenet Architecture

"The HNA MUST DNSSEC sign the Public Homenet Zone and the Public Reverse Zone."
This turnsa the "highly desirable" turns RFC7368 into a normative
requirement. It seems odd to this reviewer to insist on this in all situation
including those when the parent zone is unsigned, as noted in the final
paragraph of this section.

 12.  Renumbering
 
"During a renumbering of the home network, the HNA IP address may be
changed and the Public Homenet Zone will be updated by the HNA with
new AAAA records." - what about if the IPv4 address changes?

The discussive commentary of section 12 is interesting, but is it properly
a part of a normative specification?
   

13.  Privacy Considerations

The discussive commentary of section 13 is interesting, but is it properly
a part of a normative specification?

There are some logical inconsistencies in this session. If it is the case
that "In general a home network owner is expected to publish only names for
which there is some need to be able to reference externally." then exactly what
is being protected by attempting to counter third party zone enumeration?

"Enterprise networks have generally adopted another strategy designated
as split-horizon-DNS. "  This paragraph seems to this reviewer to be
out of scope in a normative specification.