Hi Matt,
Following up with other minor concerns. You can see the changes below:
Yours,
Daniel
Daniel
On Mon, Oct 17, 2022 at 9:11 AM Matt Brown via Datatracker <noreply@xxxxxxxx> wrote:
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.
We considered DNSSEC on how the architecture can fit DNSSEC requirements. DNSSEC might me disabled. DNSSEC impacted our design in many aspects, so the baseline we took is to have DNSSEC enabled.
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, AAAA 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.
The purpose of this paragraph is to highlight that HNA needs some information from the DM and vice versa. I suggest the following changes:
OLD:
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 fil
es. 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. Refer to {{sec-chain-of-trust}} for more details.
es. 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. Refer to {{sec-chain-of-trust}} for more details.
NEW:
It is worth noticing that both DM and HNA need to agree on a common configuration to set up the synchronization channel as well as to build and server a coherent Public Homenet Zone.
Typically, the visible NS records of the Public Homenet Zone (built by the HNA) SHOULD remain pointing at the cloud provider's server IP address -- which in many cases will be an anycast address. Revealing the address of the HNA in the DNS is not desirable. In addition and depending on the configuration of the DOI, the DM also needs to update the parent zone's (NS, DS and associated A or AAAA records). Refer to {{sec-chain-of-trust}} for more details.
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.
We put the message format description in one section to avoid repeating many information. I prefer to have it in one place.
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.
Homenet considers IPv6 deployment but the mechanism described here is also valid for IPv4, this is why IPv4 has been included.
If your CPE is serving the Public Homenet Zone, you are typically exposing your network to DDoS as its capacity is very very limited. The same is likely true for any homenet device.
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?
We did not consider a self organisation between HNAs. We focused on the minimal setting.
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.
changed
1.3: There is a missing word (scenarios) in the first sentence which I think
needs to read: "A number of deployment *scenarios* ...
changed
1.3.1: The example would be simpler and clearly if it just stated that the
vendor provisions each device with a TLS key pair and certificate matching the
assigned name which are used for mutual authentication. The current discussion of
'proceeding to authentication' is confusing, as it's not a phrase I've encoutered
before and implies to me that authentication is not completed using the
cert/keys, while the explanation about needing both names/keys for regeneration
seems neither necessary or correct (any trusted key can be used to replace
itself, whether or not a certificate with name is also present).
As far as I remember, I think the text here wanted to highlight that there is a possibility to handle keys even if the infrastructure has been designed to handle name only.
OLD
One possible way is that the vendor also provisions the HNA with a private and public keys as well as a certificate.
NEW
One possible way is that the vendor also provisions the HNA with a private and public keys as well as a certificate used for the mutual TLS authentication.
1.3.2: I think it would be simpler and clearer if the example focused solely on
establishing trust between DOI/HNA via the provision of credentials and omitted
the speculation about verification of ownership that may or may not be
required, and seems like a very separate concern at a different level of the
stack.
The purpose of the example is to show how the configuration can be completely automated. I agree the description goes beyond the scope of the document.
2. Clarification of some definitions
Registered Homenet Domain: Given there can be multiple Public Homenet Zones,
presumably there can also be multiple Registered Homenet Domains which should
be stated here for clarity.
changed to :
Registered Homenet Domain:
: is the domain name that is associated with the home network. A given home network may have multiple Registered Homenet Domain.
: is the domain name that is associated with the home network. A given home network may have multiple Registered Homenet Domain.
Public Authoritative Servers: s/for the Homenet Domain/for the Registered
Homenet Domain/ - 'Homenet Domain' alone is not a defined term.
replaced
Homenet Reverse Zone: Why is this not called the 'Public Homenet Reverse Zone'?
Given the 'Homenet Zone' is private, and this is considered the reverse for the
'Public Homenet Zone' this seems like a confusing inconsistency. Every other
term starting Homenet refers to an internal resource, while the corresponding
external resources all start with 'Public' except in this case. So I would
expect the Homenet Reverse Zone to be the private zone matching home.arpa
containing RFC1918 and IPv6 ULA addresses, etc.
changed
3.1: s/detaille din/detailed in/ - in the final sentence of the first paragraph.
corrected
3.1: "The DOI is also responsible for ensuring the DS record has been updated
in the parent zone." - This statement is too authoritative, and conflicts with
4.2 which clarifies (correctly) that DS updates in the parent zone are
optional. I suggest removing this statement, or correcting it to somethign like
"Depending on configuration, the DOI may also be responsible...".
already updated ( see my previous comment)
3.2: s/RECOMMENDED to use TLS with mutually authentication/RECOMMENDED to use
TLS with mutual authentication/ - in the final sentence of the 2nd paragraph.
done
_______________________________________________
homenet mailing list
homenet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/homenet
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
