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:mglt.i...@gmail.com]
*Sent:* Thursday, June 2, 2022, 6:36 AM
*To:* Eric Vyncke (evyncke)
*Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com;
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)
<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
<mailto:mcr%2bi...@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
