Hi Daniel. Responses inline below.
On Tue, 15 Jun 2021 at 02:58, Daniel Migault <mglt.i...@gmail.com> wrote:
>
>>
> """
> 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}}.
> """
>
I'm happy with that.
> 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.
>
I have the same interpretation.
> 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.
>
Agree, rejection is better when the trusted peer sends an invalid message.
>
> 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.
> """
>
The separation looks good, but I'd like to tweak the second paragraph. By
"only packets associated to that protocol" do you mean destination port
filtering?
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.
> """
>
So let's consider this use case where access to homenet devices is required
to be via VPN to the home. In theory, only one address needs to be
published externally. This is the current WAN IP of the home's VPN
termination point. Then the steps to access a particular smart device would
be:
1. Look up address of the home's VPN server.
2. Establish VPN.
3. From the VPN, the client learns the set of home-specific routes, and the
address of the Homenet Resolver that it should use.
4. Client queries the Homenet Resolver (over the VPN) for the address of
the smart device.
5. Client establishes connection to the smart device, over the VPN.
For this use case, there is no need to publish more than one name to the
DOI. Do you agree?
However I think the aim of this draft is to enable more than just that
case, so I can see that non-VPN cases are also useful.
> 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.
>
The reference helps, thank you. But section 4.6 does not say that
self-signed is the target. It's given as one option, and that's probably
the right language. Hence I think the sentence here should be simplified to:
3. The HNA is authenticated (see Section 4.6 of
{{!I-D.ietf-homenet-front-end-naming-delegation}}) by the DM and the
RDM.
> 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.
>
I'm not concerned about the additional round trip. I was more concerned
that the DM could be implemented as a frontend/backend architecture. The
FQDN would resolve to the front end, and this is likely to be a small list
of addresses, or even a single address. But the backend servers would have
distinct, different addresses. Connections from the DM to the HNA might be
initiated from the backend. If the HNA only looked up the FQDN, it would
drop legitimate connections. This suggests we need a way to inform the HNA
of the set of legitimate source addresses.
Chris
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
