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 <chris.box.i...@gmail.com> wrote: > Daniel, > > On Wed, 16 Jun 2021 at 01:27, Daniel Migault <mglt.i...@gmail.com> 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
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
