Re: [homenet] naming drafts

["Eric Vyncke (evyncke)" <[e-mail]>]

Dear Homenet,

After 9 months, it is time to resurrect this email thread and move forward with the 'naming drafts', which are still in WG Last Call since May 2021:

  *   draft-ietf-homenet-front-end-naming-delegation

-          draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and I (as the responsible AD for Homenet). The plan is to give the authors a chance to issue a revised I-D considering Chris Blox's review as well as trying to improve the readability and flow of the text (which suffers from multiple revisions that have rendered the I-D difficult to read). Once done, the chairs will close the WGLC and will request publication to continue the process. This should be done by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going forward anyway with the homenet drafts and wait for the IETF Last Call + IESG evaluation to get a broader scope than the Homenet WG on this very specific topic.

Final point, the chairs and I have decided that once those 2 drafts have been approved by the IESG [1], then the Homenet WG can be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I will declare those two I-D as "dead" and proceed anyway with the closing of Homenet.
[2] a new home will need to be found for Ted Lemon's drafts on "stub networking"

From: homenet <[e-mail]> on behalf of Daniel Migault <[e-mail]>
Date: Tuesday, 13 July 2021 at 23:28
To: Chris Box <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [homenet] naming drafts

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]<mailto:[e-mail]>> wrote:
Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault <[e-mail]<mailto:[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