Re: [homenet] naming drafts

[Daniel Migault <[e-mail]>]

Thank you very much Chris for the review. That was very useful.  I have
updated the two documents according to your reviews. The resulting
architecture document is available here [1] and the resulting DHCP document
is available here [2].

You can also find a more detailed response inline.

Thanks again for the review!

Yours,
Daniel

[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f1cb4c679b8b8f96bdeddcf056cdbe4e80f91c25

[2]
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/f4608d0ee2718c7d3747c848b5cbba028653c2e0

On Thu, Jun 10, 2021 at 1:21 PM Chris Box <[e-mail]> wrote:

> Hi everyone
>
> I have belatedly reviewed both drafts. I missed the WGLC due to both
> $dayjob and the IETF having a plethora of interesting working groups. But
> still, I hope this feedback is useful
>
> In general, I appreciate the aim of the drafts which I will paraphrase as
> creating a way to automatically and reliably publish a home zone containing
> a number (n) of smart devices. This makes a lot of sense when we know n is
> going to carry on growing, and of course renumbering can be frequent.
>
> My specific feedback is below, organised by section number.
>
> *draft-ietf-homenet-front-end-naming-delegation-15*
> 1 It would be useful if the introductory text in the Abstract also
> appeared here in the Introduction.
>
>

we added the text at the beginning of the introduction


> 1.1 Typos: "humuan" and "addressees "
>

corrected. Thanks.


>
> 3.1 I'd prefer the diagram to be located at the beginning of this section.
>

The figure has been moved at the beginning of the section.


> 4.7 This section should also state, as it does in section 7, that the
> Hidden Primary Server be firewalled such that only the known address range
> of the DMs are permitted to connect to it.
>

Good catch.  Looking at the two sections, it looks these are a little bit
redundant, so rather than repeating the rules I prefered to suggest
firewalling as detailed in section 7.

This basically results by the text below:
"""
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
address and such limitations SHOULD be enforced by policies describe din
 {{sec-cpe-sec-policies}}.
"""

>
> 7 I'd prefer not to use the word "packets" when it's really messages that
> we considering. Also in my opinion invalid messages to/from the DM ought to
> be rejected rather than simply dropped.
>
> Here's my suggested version, with changes highlighted in red:
>    The Hidden Primary SHOULD drop any packets arriving on
>    the WAN interface that are not issued from the DM.  The Hidden
>    Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
>    SOA response, IXFR response or AXFR responses.  The Hidden Primary
>    SHOULD reject any incoming messages other than DNS NOTIFY response, SOA
>    query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject any
>    non protected IXFR or AXFR exchange, depending on how the
>    synchronization is secured.
>
>
My interpretation between drop and reject is that drop does not provide any
response and acts as if the service does not exist while reject allows
responding with an error which in this case indicates the service exists
and has blocked the traffic.

The way we envisioned these policies is enforced by a firewall (as opposed
to the HNA itself) so the intention is to protect the HNA - including
hiding the HNA, in which case dropping seems the most obvious way to
implement these policies.
Now, since the traffic is protected by TLS, the rules associated with the
HNA are more application specific rules, and we can envision that with a
trusted peer, rejection might be more appropriate.

To address your comment I propose to differentiate the DNS rules from what
can be implemented by a firewall and take a large part of the text you
proposed resulting in the following text:

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

Depending how the communications between the HNA and the DM are secured,
only packets associated to that protocol SHOULD be allowed.



At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
NOTIFY query, SOA response, IXFR response or AXFR responses.

The HNA SHOULD reject any incoming messages other than DNS NOTIFY response,
SOA query, IXFR query or AXFR query.
"""


> 12 This acknowledges that it's a little risky to publish names of home
> devices publicly, and notes that often it's only the home owner or
> immediate family that ought to be able to query these names. It says that
> limiting ability to query can be done by IP source (IMHO tricky), or VPN.
> To which I think, if the home owner is using a VPN to the home to query the
> public zone, why do we need external publication at all? Some words to
> explain that better might be useful.
>
>
I have added some text to provide some explanations. It is correct that if
all your traffic is redirected in the home network, then there is little
interest in publishing all the names as they will only be accessed
internally. The text was trying to mention that a node may be willing to
set different policies for its traffic. Typically the web traffic is not
tunneled while the traffic to the homenet is tunneled. In this case, the
ability to define which IP address needs to be tunneled and which IP
address does not need to be tunneled requires to have this IP address so to
be able to publicly perform a DNS resolution.   The added text is as
follows:

"""
In such cases, the routing policy is likely to be defined by the
destination IP address.
This IP address potentially results from a DNS resolution over the Internet.
"""
I also added some references to lower the confidence in the security
provided by NSEC3 as well as a reference to draft-ietf-dnsop-nsec3-guidance
to configure appropriately NSEC3.




> *draft-ietf-homenet-naming-architecture-dhc-options-14*
>
> 3 In both American and British English I think the word "collocate" should
> be "colocate" (or alternatively "co-locate").
>
> fixed.

> 3 What exactly is meant by "(eventually by a self signed certificate)"?
>
> I added a reference to the section it is discussed in the architecture
document. The idea is that in some cases such as the reverse zone, TLS is
not necessarily required as the ISP identifies the line. On the other hand,
we wanted to avoid to have different versions of the HNA - let's say a
secure version that uses TLS and a unsecure version that did not use TLS.
As a result, when authentication is not mandatory we prefer the use of a
self signed certificate.


> 4.2 I think the HNA also needs to learn the set of IP addresses that the
> DM might legitimately use in order to contact the HNA, so that these IPs
> can be whitelisted in the CPE's firewall. Simply looking up the FQDN
> doesn't provide that. Should it be added to this DHCP option?
>

This is correct, so the idea is that we could provision a list of IPv4 and
a list of IPv6. However, it seems simpler to only consider the DM FQDN and
let the HNA retrieve the IP addresses from a DNS(SEC) resolution. This is
correct that this provides an additional round trip and a resolution
service to be working. This could be difficult in the case of setting a
resolving service, but in our case, we do not have such issues.


>
>
> Hope that's useful.
>
> Thanks,
> Chris
>
>
> On Fri, 4 Jun 2021 at 20:45, STARK, BARBARA H <[e-mail]> wrote:
>
>> Hi homenet WG,
>> Stephen and I have been chatting about the status of the 2 naming drafts
>> (draft-ietf-homenet-front-end-naming-delegation and
>> draft-ietf-homenet-naming-architecture-dhc-options).
>>
>> We started a 3-week WGLC about a month ago (04 May). Both drafts received
>> comprehensive review from Med. Stephen reviewed
>> front-end-naming-delegation. Bernie reviewed the formatting of the DHC
>> option.
>> The authors provided updates to resolve these comments. Bernie
>> acknowledged satisfactory resolution of his comments.
>> Requests to change terminology were satisfactorily resolved -- but that
>> discussion doesn't count as really being part of anyone's review of the
>> drafts.
>> Stephen and Juliusz expressed that they're still not convinced that DDNS
>> isn't a good enough solution for the use case.
>>
>> Stephen and I do not believe these drafts have received enough review or
>> support to put them forward as representing WG consensus.
>>
>> But the authors have spent significant effort in creating these drafts
>> and the associated implementation. We will work with Éric V (as INT area
>> AD) and the authors to determine next steps.
>>
>> Barbara and Stephen
>>
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson