Re: [homenet] naming drafts

[Daniel Migault <[e-mail]>]

Thank you very much for the feed backs. I will have a look at the comments
today and should be able to implement them by early next week.
Yours,
Daniel

On Thu, Jun 9, 2022 at 7:44 PM Kiran M <[e-mail]> wrote:

> 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] <[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]>, 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
>
>

-- 
Daniel Migault
Ericsson