Re: [homenet] naming drafts

2022-06-02 Thread Michael Richardson

Eric Vyncke (evyncke)  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.

Yes... I think that *I* said that I wouldn't have time.

> 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 !

will be there.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Re: [homenet] naming drafts

2022-06-02 Thread Daniel Migault
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) 
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  on behalf of "Eric Vyncke
> (evyncke)" 
> *Date: *Thursday, 14 April 2022 at 09:16
> *To: *"homenet@ietf.org" 
> *Cc: *"kiran.i...@gmail.com" , Michael Richardson <
> mcr+i...@sandelman.ca>, Daniel Migault , Stephen
> Farrell 
> *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  on behalf of Daniel Migault <
> mglt.i...@gmail.com>
> *Date: *Tuesday, 13 July 2021 at 23:28
> *To: *Chris Box 
> *Cc: *"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 
> wrote:
>
> Daniel,
>
>
>
> On Wed, 16 Jun 2021 at 01:27, Daniel Migault  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
> 

Re: [homenet] naming drafts

2022-06-02 Thread Eric Vyncke (evyncke)
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  on behalf of "Eric Vyncke (evyncke)" 

Date: Thursday, 14 April 2022 at 09:16
To: "homenet@ietf.org" 
Cc: "kiran.i...@gmail.com" , Michael Richardson 
, Daniel Migault , Stephen Farrell 

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  on behalf of Daniel Migault 

Date: Tuesday, 13 July 2021 at 23:28
To: Chris Box 
Cc: "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 
mailto:chris.box.i...@gmail.com>> wrote:
Daniel,

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