Re: [homenet] naming drafts

[Daniel Migault <[e-mail]>]

Hi,

Thanks for the follow up Chris. I apologize for the delay.

Yours,
Daniel

On Tue, Jun 22, 2021 at 12:31 PM Chris Box <[e-mail]> wrote:

> Daniel,
>
> On Wed, 16 Jun 2021 at 01:27, Daniel Migault <[e-mail]> wrote:
>
>>
>>> 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.
>>>>
>>>>
>>> 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?
>>>
>>
>> To me IP and port filtering are implemented by the previous line. "only
>> packets associated with that protocol" to me means that only TLS packets
>> are allowed.   The reason we are not mentioning TLS explicitly is that
>> other protocols may be used.
>>
>
> Ah, I see, so this is about the payload of the packets. But surely
> intelligent validation of the incoming packets is always going to happen?
> This is a key property of any security protocol.
> If the DM is listening on TCP 443, and the incoming packet is not a TLS
> Client Hello that it is happy with, it'll get ignored.
> If the DM is listening on UDP 500, and the incoming packet is not an
> IKE_SA_INIT that it is happy with, it'll get ignored.
>
> So I'm not disagreeing with you, I'm just questioning whether the sentence
> is needed. I don't really mind if it stays.
>
This may not be necessary, but the reason I would prefer to keep it is to
head up that additional checks - when possible - may be performed in
addition to port filtering. So unless you have a strong preference, I would
prefer to keep this additional check that could be performed by the
terminating node or a firewall.

>
>
>>
>>> 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.
>>>
>>>
> What did you think of this last point?
>

I see your point.   The architecture document envisioned this case by
specifying the dm_acl parameter in the informative section 14.
We did not include it into the DHCP option as we were requested to
implement the simplest use case that is envisioned. My understanding was
that DHCP Options had some history where complex options had been designed
but hardly used.
That said, if that is something you believe is really needed, we may bring
this discussion and add this parameter to the current DHCP Options. It
still represents a minor change as already considered in the architecture
document.

Another alternative may also consider adding an extension so the acl may be
negotiated through the control channel, which I see more scalable than
designing large DHCP options. At that point, I would rather keep the
architecture as it is a let such option for future work - though fairly
easy to set.




> Chris
>


-- 
Daniel Migault
Ericsson