Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Daniel,

Thank you for the quick reply. I had a quick browse through the commit and it seems that some points are yet to be addressed:

  *   List of normative references [1]
  *   RFC 7404 is not specifying LLA ;-)
  *   s/ as as well/as well as/ ?
  *   no justification for ‘one to three’ in section 1.2, simply remove those words

Please continue the good work

Regards

-éric

[1] I am sure that you know https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

From: Daniel Migault <[e-mail]>
Date: Tuesday, 9 August 2022 at 04:21
To: Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [homenet] AD review of draft-ietf-homenet-front-end-naming-delegation-16

Hi Erik,

Thanks for the careful review. That is really much appreciated. We have addressed most of the changes in line as well as here:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f9157a3db159dc327a3e9d5c85e9f9f83a458729

There is one remaining change we need to make,  and I hope we will be able to submit a new version in the coming days. Feel free to let us know if the changes are addressing your concerns.

Yours,
Daniel

On Mon, Aug 8, 2022 at 9:31 AM Eric Vyncke (evyncke) <evyncke=[e-mail]<mailto:[e-mail]>> wrote:

As usual, I do my own review before requesting the IETF Last Call for all documents. The intent is to give another polishing pass on the I-D.



For this review, the MD format is used.



Hope this helps



Regards



-éric



# Éric Vyncke, INT AD, comments for draft-ietf-homenet-front-end-naming-delegation-16

CC @evyncke



Thank you for the work put into this document. Multiple nits and typos are identified in the end of this review, I would have expected a document that has been through spell and grammar checkers.



Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.



Special thanks to Stephen Farrel for the shepherd's detailed write-up including the WG consensus, *but* it lacks the justification of the intended status.



I hope that this review helps to improve the document,



Regards,



-éric



## DISCUSS



### id-nits, references to be updated



Please have a look at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-16.txt and address the updated references.



### id-nits, downref



As noted by Stephen in his review (and I second his proposal), several normative references should probably "just" informative.


 downref have been moved to informative

### HNA certs



>From my reading of the text, it is really unclear whether HNA certs are / may be self-signed and what the subject alt name is (IP address ? FQDN ? other).


The text does not specify how certificate authentication is performed and leaves it relatively open to what TLS supports. Since the communication between the DM and the HNA is mutually authenticated there are two certificates involved: the certificates of the HNA and the certificate of the  DM.
In most deployments the DM is expected to be authenticated using the web PKI or alternatively using DANE or when the HNA is completely provisioned with some provisioned keys. To authenticate the HNA, the DM may need to bind the HNA to a registered client with the associated Registered Homenet Domain.
There are multiple ways, one is that the certificate contains an account reference as well as the FQDN which could be both inserted in the SAN (URN and FQDN). Other deployments may only have certificates with the FQDN... It is highly probable that the DM will trust the information based on the  CA that issued the certificate - which as I imagine is likely to belong to the same organization as the DM. On the other hand, a Let's encrypt certificate may also be acceptable.

The current text in Section "Securing the Control Channel" omits all details and is as mentioned below:

OLD:
The DM SHOULD authenticate the HNA and check that inbound messages are from the appropriate client.
The DM MAY use a self-signed CA certificate mechanism per HNA, or public certificates for this purpose.

I propose the following text, please let me know if that addresses your concern.

NEW:
The DM SHOULD authenticate the HNA and check that inbound messages are from the appropriate client.
The DM MAY use a self-signed CA certificate mechanism per HNA, or public certificates for this purpose.
The HNA certificate needs to provide sufficient trust to the DM that the HNA is legitimate. When certificates are used, it is left to the DM to define what information carried by the certificate is acceptable as well as which CA can issue the certificate. For example, some deployments may use domain validation certificates with the Registered Homenet Domain as a SAN of type FQDN. Other deployments may use specifically formed certificates with additional information such as a user account as a SAN of type URN, signed by a specific CA may be used.



### Section 1, multiple IP addresses



In `A device may have a Global Unicast Address (GUA),`, it appears by the use of 'a' that devices can have only one. Suggest removing 'a'.



In the same vein, even in residential network, there may be global IPv4 addresses.


changed to:
A device may have Global Unicast Addresses (GUA) (IPv6 or IPv4), a Unique Local IPv6 Address (ULA), as as well IPv6-Link-Local addresses, IPv4-Link-Local      Addresses, and RFC1918 addresses.

### Section 1.2, 1 to 3 ?



Please justify the limit to 3 in `For a very few number (one to three) of hosts`


changed to:
For a very few number (one to three) of hosts (media servers, VPN gateways, .     .. ),...

### Section 1.2, requirements ?



Please add a reference (or rephrase) the requirement in `Such dependence does not meet the requirement for`.


adding  {{?RFC7368}} as a reference of the requirement.

### Section 2, Homenet Authoritative Servers:



For which zones `Homenet Authoritative Servers:` ?


adding:
for the  Homenet Zone

### Section 3.2



The I-D proposes to use DoH & DoQ as transport, but did the authors check that AXFR operations can be made over DoH ?
 I am not aware of this being standardized but I do not see anything that could prevent it.

The current text I see mentioning DoH and DoQ are as follows:

The information exchanged between the HNA and the DM uses DNS messages protected by DNS over TLS (DoT) {{!RFC7858}}.
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}}.

I do see some confusion that QUIC or DoH are not clearly identified as not supporting AXFR (now). I propose the following change:
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}}.

The other place I found is there and I do not think any other changes are needed.

Supported Transport (dm\_transport)
: The transport that carries the DNS exchanges between the HNA and the DM.
Typical value is "DoT" but it may be extended in the future with "DoH", "DoQ" for example.
This parameter is OPTIONAL and by default the HNA uses DoT.

### Section 4.5.4 SHOULD ?



Please explain when the 'SHOULD' does not apply.


SHOULD has been removed.


### Section 5, port XX



As the XX on DM is 853, does it require the HNA to also listen on XX == 853 ?


Yes for the synchronization channel:

On the other hand, the Synchronization Channel is set between the DM working as a client using port ZZZZ ( a high range port) toward a service provided  by the HNA at port XX.

### Section 5

```

   The use of a primary / secondary mechanism is RECOMMENDED instead of

   the use of DNS Update

```



What is 'primary/secondary mechanism' ? Missing transfer ?



'DNS update' is it the HTTP RESTful one ? Is it the same as 'DNS UPDATE [RFC2136]' used later in the section ?


I think the most accurate reference for primary / secondary is 1996. The mechanisms was described a master / slave. Yes DNS Update is DNS UPDATE. I added the two references and the text has been changed as follows:

 The use of a primary / secondary mechanism {{!RFC1996}} is RECOMMENDED instead of the use of DNS UPDATE {{?RFC2136}}.

We changed all DNS Update to DNS UPDATE as well.

### Section 11.3



Who is the end user in :

```

   ... For

   that reason end users may choose not to respond to PTR DNS queries

   and MAY instead return a NXDOMAIN response.

```
You are correct this is the end-user / admin. ;-)

OLD:
For that reason end users may choose not to respond to PTR DNS queries and MAY instead return a NXDOMAIN response.

NEW:
For that reason PTR DNS queries and MAY instead be configured to return with NXDOMAIN.



### Appendix A, why in appendix ?



Is there a reason why the reverse zone is in the appendix ? There should at least be a forward reference in the introduction to the appendix but better to move in the main body.


Re-added in the body. The reason it has been put in the appendix is that it is a variant of the forward zone - that is a specific case. On the other hand, it could be also seen as an essential part of the architecture.


## COMMENTS



### Shepherd's review, intended status



Stephen, as noted above, please include some justification for the intended PS status.



### Section 1, devices or services ?



```

   Home network owners often have devices that they wish to access

   outside their home network - i.e., from the Internet using their

   names.

```



As DNS contains more than mere IP addresses and as a single device can host many services with different IP addresses, propose to use 'devices and services'.



This issue also appears in other sections (e.g., sect 1.1)


we updated 6 ish occurrences.

### Section 1.1, un-parsable ?



Is it parsable for a native-English speaker ?

```

   While this document does not create any normative mechanism by which

   the selection of names to publish,

```


 I think the wording below might be better

While this document does not create any normative mechanism to select the names to publish, this document anticipates that the home network administrator      (a human), will be presented with a list of current names and addresses.


### Section 1.1, inside ?



Please define (or add a reference) for `on the inside of the home`.


see above.

### Section 1.1, DHCP rebinding ?



The reference to RFC 6644 is a little weird to me, either use 'DHCP rebind' or use the right RFC for DHCPv6.
The reference to DHCPv6 has been updated and the sentence is as follows:
The address of the device or service can be collected from a number of places     : mDNS {{!RFC6762}}, DHCP {{!RFC8415}}, UPnP, PCP {{!RFC6887}}, or manual con     figuration.



### Section 1.1, RFC 1918 or private



Please add a reference to ULA and use 'private IPv4 addresses' rather than 'RFC 1918 addresses' ?


Here is the updated text:

A device or service may have Global Unicast Addresses (GUA) (IPv6 {{?RFC3787}} or IPv4), a Unique Local IPv6 Address (ULA) {{?RFC4193}}, as as well IPv6-Link-Local addresses, IPv4-Link-Local Addresses (LLA) {{?RFC7404}}, and private IPv4 addresses {{!RFC1918}}.

### Section 1.1, TLS ?



Why is TLS mentioned here ? It should rather be in the security section.


I think the text is expected to highlight that name are global identifiers even if local scope IP addresses are used.

The old text was:
In general, one expects the GUA to be the default address to be published.
However, publishing the ULA and RFC1918 may enable local communications within the home network.
Since the communication has been initiated with a name which remains a global identifier, the communication can be protected by TLS the same way it is protected on the global Internet.
A direct advantage of enabling local communication is to prevent communications even in case of Internet disruption.

Perhaps the new text below is clearer:

In general, one expects the GUA to be the default address to be published.
However, publishing the ULA and RFC1918 may enable local communications within the home network.
A direct advantage of enabling local communication is to enable communications even in case of Internet disruption.
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.

### Section 1.1



This is probably the reverse:

```

A direct advantage of enabling local

   communication is to prevent communications even in case of Internet

   disruption.

```


changed prevent to enable

### Section 1.2



`As there are some commonalities provides by individual home` possibly a typo.


change provides to provided

### Section 3.1, which network ?



In `When the request is coming within the network`, which network ? Even if guessable, let's be clear.


changed to:
When the request is coming within the home network,


### Section 3.1



Should '.local' also appear in figure 1?


My understanding is that .local is mostly used with DNSSD which is advertised via multicast as opposed to a zone. For that reason home.arpa seems more appropriated. Now it is also correct that there are some mechanisms that convert .local advertised via DNSSD into a zone, but I think such considerations are a bit out of scope of the document.

### Section 3.2



What is `cloud provider's anycast addresses`?


 The anycast address is the address used by the cloud provider to distribute the homenet zone. I agree this is not necessarily an anycast address though I think it clearly shows the interest of using a cloud provider with specific properties.

Perhaps the following change can clarify the text:

OLD:
The visible NS records SHOULD remain pointing at the cloud provider's anycast addresses.

NEW:
The visible NS records SHOULD remain pointing at the cloud provider's server IP address -- which in many cases will be an anycast addresses.


### Section 4.6 oxymoron ?



Isn't `The DM MAY use a *self-signed CA* certificate mechanism per HNA` an oxymoron ?


I think what the text is trying to say is that the DM may use a dedicated CA specifically provisioned for the service and dedicated to issue certificates for HNA.
I agree that the text can be hard to parse and considering that we already changed some of the initial text in a previous comment, I think we can simply remove the sentence.
The full paragraph would move from :

OLD:
The DM SHOULD authenticate the HNA and check that inbound messages are from the appropriate client.
The DM MAY use a self-signed CA certificate mechanism per HNA, or public certificates for this purpose.
The HNA certificate needs to provide sufficient trust to the DM that the HNA is legitimate. When certificates are used, it is left to the DM to define what information carried by the certificate is acceptable as well as which CA can issue the certificate. For example, some deployments may use domain validation certificates with the Registered Homenet Domain as a SAN of type FQDN. Other deployments may use specifically formed certificates with additional information such as a user account as a SAN of type URN, signed by a specific CA may be used.

TO:
The DM SHOULD authenticate the HNA and check that inbound messages are from the appropriate client.
The HNA certificate needs to provide sufficient trust to the DM that the HNA is legitimate. When certificates are used, it is left to the DM to define what information carried by the certificate is acceptable as well as which CA can issue the certificate. For example, some deployments may use domain validation certificates with the Registered Homenet Domain as a SAN of type FQDN. Other deployments may use specifically formed certificates with additional information such as a user account as a SAN of type URN, signed by a specific CA may be used.


### Section 4.6, ambiguous



In `The DM MAY use a self-signed CA certificate mechanism per HNA`, is this cert used to verify the connection from HNA or rather used by the DM to sign its messages ?


It is for the DM to authenticate the HNA. I think the text above clarifies this as well.

### Section 4.7 SHOULD



When can an implementation not follow the "SHOULD" ?


The text in question is as follows:

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.
This results in a limited exchanges (AXFR/IXFR) with a small number of IP addresses and such limitations SHOULD be enforced by policies described in  {{sec-cpe-sec-policies}}.


The intent is to say that the implementation SHOULD enable filtering unexpected DNS packets and IP addresses. I think the following sentence may be clearer:
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}}.


### Section 3, synchronization or transfer



Just wondering whether 'synchronization' is the best word (as it is mainly HNA updated one-way the DM), why not simply 'transfer' ?
 I am obviously biaised, but I do think that synchronization is more appropriated as the channel is used to tranfer as well as to check the file version to ensure both primary and secondary have the same version of the zone file.

### Section 5



A small figure would be nice.
Actually Figure 1 mentions all channels. Do you think we should remind the reader about this or do you expect another figure ?



### Section 5, CPE only



```

   The HNA acts as a Hidden Primary Server, which is a regular

   authoritative DNS Server listening on the WAN interface.

```



Does this mean that only CPE can be a HNA ? Then, what about the previous paragraphs about multiple HNA at home?

Practically this is expected to be the most common case, but HNA is not necessarily a CPE. When there are multiple candidates for the HNA, we need to pick one.
I think we have some text that mentions this but feel free to let me know if I am missing something.

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.



### Section 5.1



Please also add which parties are the primary and secondary.


I suppose  the correspondence between HNA / DM and primary / secondary is missing. I propose the following change:

OLD:
First the primary notifies the secondary that the zone must be updated and leaves the secondary to proceed with the update when possible/convenient.

NEW:
First the HNA (primary) notifies the DM (secondary) that the zone must be updated and leaves the DM (secondary) to proceed with the update when possible/convenient.

Note that I also changed the exchange description that seems like an additional procedure  as opposed to a more detailed description of the high level mechanism just described above. I think that was part of the confusion and the text is now as follows:

More specifically, the HNA sends a NOTIFY message, which is a small packet that is less likely to load the secondary.
Then, the DM sends  AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request. This request consists in a small packet sent over TCP (Section 4.2 {{!RFC5936}}), which also mitigates reflection attacks using a forged NOTIFY.


### Section 5.1, DNS resolution



Humm is `(via DNS resolution)` normative ?


change to via a DNS resolution

When can the last 'SHOULD' be ignored ?


The SHOULD is likely to be ignored on minimal implementations. The additional SHOULD describes a mechanism to make the mechanism more stable but that is not strictly mandatory.

### Section 7, SHOULD



Please explain when the 'SHOULD' can be ignored.


The first SHOULD has been changed from:
OLD:
The HNA, as Hidden Primary SHOULD drop any DNS queries from the home network.
NEW:
 The HNA, as Hidden Primary SHOULD drop any DNS queries from the home network -- as opposed to return DNS errors.

The second SHOULD has been changed to :

OLD:
The HNA SHOULD drop any packets arriving on the WAN interface that are not issued from the DM.

NEW:
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.

### Section 9, reverse zone



In `it is RECOMMENDED that only the newly reachable IP addresses be published`, what is the recommendation for the reverse zone(s) ?


 As the HNA does not really own the reverse zone, once the IP address is not valid anymore, the HNA is expected to have no control over the reverse zone. As a result, I do not see any action to be done by the HNA for the reverse zone.

That said, we can probably detail this a bit. The added text is as follows:
Regarding the Homenet Reverse Zone, the new Homenet Reverse Zone has to be populat
ed as soon as possible, and the old Homenet Reverse Zone will be deleted by the ow
ner of the zone (and the owner of the old prefix which is usually the ISP) once th
e prefix is no longer assigned to the HNA. The ISP SHOULD ensure that the DNS cach
e has expired before re-assigning the prefix to a new home network. This may be en
forced by controlling the TTL values.

### Section 10



Suggest moving section 10 as a sub-section of section 11.



### Section 10



No clue of to understand:

```

   For instance, an adult child checking on the

   state of a home automation system for a parent.

```

I need to check  this with my co-authors.


### Section 11.2



Should temporary IPv6 addresses be mentioned as well ?


We have added some text and the current paragraph looks like this:

IP addresses may be used to locate a device, a host or a service.
However, home networks are not expected to be assigned a time invariant prefix by ISPs. In addition IPv6 enables temporary addresses that makes them even more volatile {{!RFC8981}}.

### Section 11.4



Please rename this section to something else as it is not the usual 'operational considerations' section.


changed to deployment considerations

### Appendix A



```

   In the case of the reverse zone, the DOI authenticates the source of

   the updates by IPv6 Access Control Lists.

```

DOI or DM ?

The DM is part of the DOI, so that will not become fundamentally wrong. The reason we keep DOI is that the DM is essentially focused on DNS aspects while authentication is likely to be defer to a dedicated function different from the DOI. I tend to refer DOI.



### Appendix A.1



s/2001:db8:aeae:0001::2/2001:db8:aeae:1::2/



Does this mean 2 control channels (one for WAN and one for inside LAN) ?


I think this is just one IP of the network. We probably did not take :2 as something generic as opposed to :1 or :0, but I am happy to hear what seems to you a better choice.

Unsure whether the following is true:

```

   With IPv6, the domain space for IP addresses is so large that reverse

   zone may be confronted with scalability issues.

```


The reverse zone associated to ::/64 can be non trivial to manage especially when very few IPs are effectively being used. I suspect the wording is unclear and propose to replace it as follows:
 With IPv6, the reverse domain space for IP addresses associated to a subnet such as ::/64 is so large that reverse zone may be confronted with scalability issues.


### Appendix A.2



s/RG router/CPE/


ok

### Appendix B



Is not normative, then is it useful ?



What is 'front-end protocol' ?


The front end protocol is the legacy name for the protocol described in this document. I think the section gives a good sense of how the HNA needs to be provisioned and configured, s I think that is important to have such a section.


### Appendix B.1



Hmm a little unclear at first sight whether this section is explaining the parameters of appendix B.
agree the twp sections have been merged.



### Appendix C



Even if not normative, use cases are often described in the introduction section. Consider moving this appendix in section 1.


moved as section 1.3


## NITS



### Abstract & section 1



s/needs/need/


ok

### Section 1.1



s/home network administrator (a human), will be presented with a list/home network administrator, (a human being), will be presented with a list/ ?


ok

### Section 1.2



s/For a very few number/For a very few numbers/ ?
 ok



### Section 4.2



`so the that DOI`? how to parse this ?
changed to: so the DOI



### No comma before 'and'



AFAIK, there is no comma before 'and', exception made for the Oxford comma of course.


ok - works for me.

### Section 4.2



s/were/was/ ?


I cannot find it in section 4.2 it might have been changed addressing a previous comment.

### Section 4.5



s/long term session/long-term session/


ok

### Section 4.6



Unbalanced parenthesis.


ok

### Section 4.7



s/describe din/described in/
ok



### Section 5



Duplicate `toward a service a service`


ok

### Section 6



s/is outside/are outside/ ?


ok

### Non-empty well-known



Several missing '-' in 'non-empty' and 'well-known' (when applicable).


ok

### E.g.



"E.g." should be enclosed in ','.


ok

### Section 9



'by by' ?
ok



### Section 10



s/privacy MAY be provide/privacy MAY be provided/


ok

### Section 11.1



`To ensure the multiple TLS session are are continuously authenticating ` duplicated 'are'
ok



s/This MAY Be handle by a off-line /This MAY be handled by an off-line/


ok

### DNS in uppercase



There are a couple of 'dns' (lowercase) instances.


ok

## 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






_______________________________________________
homenet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/homenet


--
Daniel Migault
Ericsson