Re: [homenet] naming drafts

[Kiran M <[e-mail]>]

Hi Daniel,

I finally managed to finish the review of front-end naming document. My 
apologies for the delay. Many thanks for addressing the first round of 
comments, the readability has improved quite a bit. The remainder of the 
comments are in the Github. Hope we will see a revision soon.

Cheers,
Kiran


------------------------------------------------------------------------
*From:* Daniel Migault [mailto:[e-mail]]
*Sent:* Thursday, June 2, 2022, 6:36 AM
*To:* Eric Vyncke (evyncke)
*Cc:* Eric Vyncke (evyncke); [e-mail]; [e-mail]; 
Michael Richardson; Stephen Farrell
*Subject:* [homenet] naming drafts

> We are working on it with Kiran, I actually started yesterday to 
> consider her latest feedback (2nd round) - not yet being pushed, but 
> that should happen very soon.
>
> Yours,
> Daniel
>
> On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) 
> <[e-mail]> wrote:
>
>     As we are halfway between IETF-113 and IETF-114, it is time to
>     make a check as I have seen no revised version for those 2
>     ‘naming’ drafts.
>
>     You may also have noticed that Ted’s ‘stub networking’ work is
>     going in a SNAC BoF at IETF-114 (please attend and contribute to
>     the [e-mail] mailing list).
>
>     Therefore, the plan is to close Homenet early July 2022 if nothing
>     changes.
>
>     Hoping to see you in “Philly” to celebrate the achievments of
>     Homenet !
>
>     Regards
>
>     -éric
>
>     *From: *homenet <[e-mail]> on behalf of "Eric
>     Vyncke (evyncke)" <evyncke=[e-mail]>
>     *Date: *Thursday, 14 April 2022 at 09:16
>     *To: *"[e-mail]" <[e-mail]>
>     *Cc: *"[e-mail]" <[e-mail]>, Michael
>     Richardson <[e-mail]
>     <mailto:[e-mail]>>, Daniel Migault
>     <[e-mail]>, Stephen Farrell <[e-mail]>
>     *Subject: *Re: [homenet] naming drafts
>
>     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]> 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
>
>
>
> -- 
> Daniel Migault
> Ericsson