Re: [homenet] naming drafts

[Chris Box <[e-mail]>]

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.


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

Chris