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) <evyn...@cisco.com> 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 s...@ietf.org > 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 <homenet-boun...@ietf.org> on behalf of "Eric Vyncke > (evyncke)" <evyncke=40cisco....@dmarc.ietf.org> > *Date: *Thursday, 14 April 2022 at 09:16 > *To: *"homenet@ietf.org" <homenet@ietf.org> > *Cc: *"kiran.i...@gmail.com" <kiran.i...@gmail.com>, Michael Richardson < > mcr+i...@sandelman.ca>, Daniel Migault <mglt.i...@gmail.com>, Stephen > Farrell <stephen.farr...@cs.tcd.ie> > *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 <homenet-boun...@ietf.org> on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Tuesday, 13 July 2021 at 23:28 > *To: *Chris Box <chris.box.i...@gmail.com> > *Cc: *"homenet@ietf.org" <homenet@ietf.org> > *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 <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 > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
