Re: [homenet] WGLC started

[Daniel Migault <[e-mail]>]

Hi Med,

Thanks for the very careful review of the HNA architecture. I believe the
new published version addresses your concerns but please find some
complementary responses.

Yours,
Daniel


IPv6 connectivity provides the possibility of global end to end IP
connectivity.

[BMT2]: As firewalls may be enabled on the RG, the same issues as per IPv4
will be encountered (need to open pinholes). There is also a requirement on
stable IP addresses, unless a mechanism is enabled to update the records
dynamically.

> I agree with the comment, but I think that IPv6 and the use of global IP
addresses ease the end to end connectivity. It is not impossible with IPv4
but way more difficult than just opening an IP address.
This is also correct: the mechanism provides the zone to be dynamically
sync.
Currently, I think it is better to keep that sentence. Now going to the
next comment I have the impression the removal was requested to avoid
redundancies.


3. {{!RFC7368}} emphasizes that the home network is subject to connectivity
disruptions with the ISP.
But, names used within the home MUST be resilient against such disruption.

[BMT5]: The LAN connectivity is resilient against WAN failure. Reaching a
device based on a local name is just factural.

> Correct. Here we were listing the constraints of the homenet. I think the
comment is addressed by the sentence right after the enumeration:

This specification makes the public names resolvable within both the home
network and on the Internet, even when there are disruptions.

[BMT6]: Unless you define what is meant by a “public name” vs. “private
name”.

We clarified the public name is the name of the device by which it is
reachable from outside as well as from within the home network.

[BMT8]: Also, please note that rfc6092 says the following: “REC-8: By
DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be
processed by any integrated DNS resolving server.”

> I think that is interesting but I am not sure this is clarifying. This
case is considered bad in our scenario since it exposes the interface on
the interface.
We have never - at least in my case - considered having a single server
inside and outside, so I prefer not to introduce this potential confusion.

[BMT12]: Why not other device identifiers?
[BMT14]: How is this known/configured? Or do you expect this to be handled
by an administrator. That said, I don’t see this as case is worth to be
discussed here as VPN setups do not involve CPEs.

> The type of IP address is expected to be selected by the administrator
which will determine what can be outsourced to the DOI.
The idea of the VPN was to mention that there are some cases where non
global IP addresses may be published globally.

[BMT17]: I’m not sure this is needed.
> The section is not intended to describe an alternative way, it is
expected to position the architecture toward what is believed to be a more
common mechanism.

[BMT18]: How this is supposed to work for IPv4 even when no failure is
experienced? I’m asking this as given that the same IP address is shared
and that a port number is needed to map to an internal host.
The CPE should be involved, otherwise failures will be observed.

> I now understand the earlier comments. The scope of homenet is IPv6 so we
were basically translating the mechanism to IPv6 use case. I clarified
this, but did not consider the IPv4 issues.


"""On the other hand, to provide resilience to the Public Homenet Zone in
case of WAN connectivity disruption, the Homenet DNSSEC Resolver SHOULD be
able to perform the resolution on the Homenet Authoritative Servers. These
servers are not expected
"""
[BMT21]: MUST?

I understand why MUST is suggested. The reason It would rather stay with
SHOULD is that it is not given that homenet have authoritative servers.

"""
How the Homenet Authoritative Servers are provisioned is also out of scope
of this specification.
It could be implemented using primary and secondary servers, or via rsync.
In some cases, the HNA and Homenet Authoritative Servers may be combined
together which would result in a common instantiation of an authoritative
server on the WAN and inner homenet interface.
Note that {{?RFC6092}} REC-8 states this must not be the default
configuration.
Other mechanisms may also be used.
"""

> I added the reference to RFC6092 there.


"""communications between the HNA and the DM SHOULD be protected and..."""

[BMT23]: MUST?

> For the reverse zone, there are some situations where the use of strong
authentication may not necessarily be needed. We however updated it to MUST
to avoid specific unsecured implementations to be deployed.




On Wed, May 5, 2021 at 8:33 AM <[e-mail]> wrote:

> Hi all,
>
> FWIW, some comments to be considered by the authors as part the WGLC can
> be seen at:
>
> * draft-ietf-homenet-naming-architecture-dhc-options:
> - pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.pdf
> - doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.docx
>
> * draft-ietf-homenet-front-end-naming-delegation:
> - pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.pdf
> - doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.docx
>
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : dns-privacy [mailto:[e-mail]] De la part de
> > STARK, BARBARA H
> > Envoyé : mardi 4 mai 2021 15:56
> > À : '[e-mail]' <[e-mail]>
> > Cc : '[e-mail]' <[e-mail]>; '[e-mail]' <dns-
> > [e-mail]>; '[e-mail]' <[e-mail]>
> > Objet : [dns-privacy] WGLC started
> >
> > Hi homenet, intarea, dhc, and dprive,
> > Homenet has started WGLC for draft-ietf-homenet-front-end-naming-
> > delegation-14 and draft-ietf-homenet-naming-architecture-dhc-options-
> > 12.
> >
> > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-
> > delegation/ (Simple Provisioning of Public Names for Residential
> > Networks) https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-
> > architecture-dhc-options/ (DHCPv6 Options for Home Network Naming
> > Authority)
> >
> > We're including intarea, dhc, and dprive to get a slightly wider
> > audience for the technical aspects of these drafts (dhc is
> > specifically asked to look at the dhc-options draft).
> > The drafts do also need some editorial fixing-up. I'll be focusing on
> > that so the technical experts can focus on the technical aspects.
> >
> > I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing
> > this because
> > - we're reaching out to WGs that haven't seen this before and asking
> > them for comments
> > - there are 2 drafts
> > - I'm on vacation next week and was getting stressed out by
> > everything I need to get done by this Friday
> >
> > The meeting minutes (from the homenet April 23 interim) list intarea,
> > dprive, and dhc as other groups to request comments from. Is this the
> > right list? Are there others?
> > Please let me know if I should broaden this.
> > Thx,
> > Barbara
> >
> > _______________________________________________
> > dns-privacy mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson