Re: [Int-dir] [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

[Daniel Migault <[e-mail]>]

Hi Tim,

Thanks for the feed backs. Please see how the document has been updated.
The ULA comment may remain open.
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6

You can also find some more description / comments inline.

Thanks for the follow-up!
Yours,
Daniel


On Thu, Jan 12, 2023 at 10:28 AM Tim Chown <[e-mail]> wrote:

> Hi,
>
> In-line...
>
> On 9 Jan 2023, at 18:15, Daniel Migault <[e-mail]> wrote:
>
> Hi Tim,
>
> Thanks for the review we updated the file as follows:
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b
>
> Please see my responses in line for more details.
>
> Yours,
> Daniel
>
> On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker <
> [e-mail]> wrote:
>
>> Reviewer: Tim Chown
>> Review result: Almost Ready
>>
>> Hi,
>>
>> I have reviewed this document as part of the Operational directorate's
>> ongoing
>> effort to review all IETF documents being processed by the IESG.  These
>> comments were written with the intent of improving the operational
>> aspects of
>> the IETF drafts. Comments that are not addressed in last call may be
>> included
>> in AD reviews during the IESG review.  Document editors and WG chairs
>> should
>> treat these comments just like any other last call comments.
>>
>> This document describes an architecture by which names and IP addresses of
>> hosts or services may be made available in the public DNS through the use
>> of a
>> homenet naming authority (HNA) and associated (hidden) primary DNS
>> function
>> resident in the home network and a DNS outsourcing infrastructure (DOI)
>> function which through a distribution manager also acts as a secondary.
>> Methods
>> for synchronisation and control of the information between the HNA and
>> DOI are
>> presented.
>>
>> I would say this document is getting close to being Ready, but still has
>> issues.
>>
>> A significant problem is that the document is not particularly well
>> written.
>> The quality of the text is poor, with at least six typos or mistakes in
>> just
>> the initial two paragraph abstract, which does not put the reader in a
>> good
>> frame of mind to read the main body of the document.  There are mistakes
>> throughout the document.  I would suggest that a full check, from start to
>> finish, is required before the draft can progress.
>>
>> It may be the fact that the draft is now over 10 years old means it has
>> been
>> “cobbled” over a long period and perhaps it therefore doesn’t flow as
>> well as
>> it would were it written from scratch today.
>>
>> General comments:
>>
>> The introduction section introduces a lot of new terms and language, and
>> notes
>> on how various elements and components are related, and communicate.  A
>> clear
>> diagram would be really helpful here.  There is one in 5.1, but a
>> high-level
>> one in section 1 would improve the document.
>>
>> You are probably right, but when we tried we almost ended up in repeating
> the figure of section 5.1 and finally removed it. If this is not essential,
> I would prefer to leave it as it is.
>
>
> The trouble is you are very familiar with the work.  It’s a bit of a brick
> wall to those reading it for the first time, especially with so many new
> terms being used for things that could be referred to with more familiar
> terms.  I would strongly recommend a figure early on, but obviously it’s up
> to the IESG as to what they want to see.
>
>
I have added a simplified figure of the architecture that I think is
readable.

> Otherwise, I am ok with the general principle of what is proposed, i,.e. a
>> ‘hidden’ primary and a secondary in the DOI part, feeding the publicly
>> accessible servers.  But this could also be done with a standard DNS
>> approach -
>> should thus be noted and a section added pointing out the pros and cons
>> of each
>> approach?
>>
>> I suppose the standard approach you are referring to is the use of DNS
> UPDATE. If that is the case, we tried to have such a section to state
> differences between the two methods and removed it. The main difference is
> that DNS UPDATE does not update the zone itself but of course one could
> update each RRset of the zone.
>
>
> Well, I don;’t think the primary has to live in the home network, for
> example.  I don’t think this draft describes a bad idea, but presenting the
> trade-offs may be useful.  Or perhaps that’s a separate draft.
>
In our case the HNA builds the zone so if the HNA is not in the home
network that becomes a very specific case. I agree there could be a way the
HNA may be split in to sub functions.  In my mind we provide a basic use
case, which can be further declined in more specific ways, and I agree that
these specificites should be the purpose of other drafts. At least that is
what I intend to do for the specific case we have.
I thought your initial comment was about comparing briefly DNSUPATE and
this proposal. We tried and failed more than once, so I prefer not to raise
that again.

>
> I would like to see, perhaps as an Appendix, a clear list of steps that
>> would
>> happen, to go from the starting point (presumably arrangement for the
>> domain(s)
>> and startup of the HNA function) to a steady operational state, maybe
>> even as a
>> state diagram. This could include a clearer view of how the user updates
>> the
>> information they wish to make available.  There’s hints of parts of this
>> in the
>> document, but not a whole view.
>>
>>
> The purpose of the draft is to set a primary / secondary to outsource the
> zone. How the domain name is acquired,  how the zone(s) are populated and
> how the HNA is implemented / deployed in the home network can be very
> complex and can be done in so many ways. We provided some hints but I fear
> the scope could be way too large. I suspect that the companion document
> DHCP options provide more than what you ask for but in the narrow scope of
> an ISP providing names and DOI. I agree it would be good if we have a more
> standard way, but currently I prefer that we remain focused on one
> functionality we want to implement.
>
>
> Perhaps an example, the simplest example, could be presented?
>

I think the use case section is appropriate for that if the description
remains quite high level as many of the details can go well over the scope
of the document and since this is one of the difficulties we had with that
document I would refrain too much to go beyond the scope of the document. I
think the current introduction of the envisioned deployment scenarios
address your concern.

"""
A number of deployment scenarios have been envisioned, this section aims at
providing a brief description.
The use cases are not limitations and this section is not normative.

The main difference between the various deployments concerns the
provisioning of the HNA - that is how it is configured to outsource the
Public Homenet Zone to the DOI - as well as how the Public Homenet Zone is
being provisioned before being outsourced.
In both cases, these configuration aspects are out of the scope of the
document.

Provisioning the configuration related to the DOI is expected to be
automated as much as possible and require as little as possible interaction
with the end user.
Zero configuration can only be achieved under some circumstances and
{{?I-D.ietf-homenet-naming-architecture-dhc-options}} provides one such
example under the assumption the ISP provides the DOI. {{sec-cpe-vendor}}
describes another variant where the CPE is provided preconfigured with the
DOI.
{{sec-agnostic-cpe}} describes how an agnostic CPE may be configured by the
home network administrator.
Of course even in this case, the configuration can leverage mechanisms to
prevent the end user manually entering all information.

On the other hand, provisioning the Public Homenet Zone needs to combine
the ability to closely reflect what the end user wishes to publish on the
Internet while easing such interaction.
The HNA may implement such interactions using Web GUI or specific mobile
applications.

With the CPE configured with the DOI, the HNA contacts the DOI to build a
template for the
Public Homenet Zone, and then provision the Public Homenet Zone.
Once the Public Homenet Zone is built, the HNA strats synchronizing it with
the DOI on the Synchronization channel.
"""


> Is the HNA typically a function in the home router?  Do we expect CPE
>> vendors
>> to implement this?  Which begs the question are there at least two
>> independent
>> implementations of what is described in this text?  Is what’s written here
>> theory, or has it been proven?  The ideas for this approach have clearly
>> been
>> around for some 10 years at least.
>>
>> We have one implementation.
>
>
> OK, that’s good. Is there any report or presentation on experience with it
> available?
>
Not that I know.

>
> The HNA signs the zone for DNSSEC, but is this a MUST?  DNSSEC is mentioned
>> many times, but this is unclear.  In 5.1 and in 6.1 the sentence about
>> this
>> doesn’t say MUST, but later in section 11 it does.  If it is a MUST, say
>> so
>> earlier. Of course, DNSSEC is not exactly pervasive as it is.
>>
>> This is how we would like things to be. However, we prefer the zone to be
> signed by the DOI than not being signed.
>
>
> OK, but the problem at the moment is the MUST comes late in the document.
> It’s vague to that point.
>

I changed the sentence to the one below in the architecture overview. I
think this addresses your concern.
"""
It is RECOMMENDED the HNA implements DNSSEC, in which case the HNA MUST
signs the Public Homenet Zone with DNSSEC.
"""


> Specific comments:
>>
>> Abstract:
>>
>> “The names and IP address of the home network are present in the Public
>> Homenet
>> Zone by the Homenet Naming Authority (HNA)“ - “are present” needs
>> correcting.
>>
>> change to set :
> """
> The names and IP address of the home network are set in the Public Homenet
> Zone by the Homenet Naming Authority (HNA), which in turn instructs an
> outsourced infrastructure to publish the zone on the behalf of the home
> owner.
> """
>
>
> That’s better, thanks.
>
> “Home networks are increasingly numbered using IPv6 addresses, which makes
>> this
>> access much simpler.” - well, it means global addresses are available,
>> but the
>> issues of for example naming, numbering, firewalling and appropriate
>> access
>> control remain.
>>
>>
> My understanding of the text you propose is that it can be interpreted as
> there are no mechanisms to update the DNS and that we are raising multiple
> issues that we do not deal with in the draft. I rephrase the abstract as
> follows:
>
>
> Well, you imply that “IPv6 makes it MUCH simpler”, I’m not (yet) convinced
> the “much” part is true, because the access is part of a broader picture.
> From a pure IP point of view, yes.
>
 I removed "much", but the idea was to say we did not have to NAT
everything.


> Home network owners may have devices or services hosted on this home
> network that they wish to access from the Internet (i.e., from a network
> outside of the home network).
> Home networks are increasingly numbered using IPv6 addresses, which makes
> this access much simpler, but their access from the Internet requires the
> names and IP addresses of these devices and services to be made  available
> in the public DNS.
>
> This document describes how an Home Naming Authority (NHA) instructs the
> outsourced infrastructure to publish these pieces of information
> in the public DNS.
> The names and IP addresses of the home network are set in the Public
> Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs
> an outsourced infrastructure to publish the zone on the behalf of the home
> network owner.
>
>
> I would change to "which in principle can make this access simpler”, but
> up to you.
>
> ok I changed to that abstract and adapted it to the intro as well.


> The abstract could say this is an IPv6-only mechanism, if that’s the case.
>
> That is what we had initially and since the mechanism we describe can also
be implemented for IPv4 we included both versions. So I prefer the first
alternative you proposed. ;-)

> Section 3:
>>
>> ULA use here should be very strongly discouraged. For a “Public Homenet
>> Zone”
>> should we not use strong language for GUA?  Documents talking about ULAs
>> tend
>> to take a long time to get published :)
>>
>>  These are in my opinion recommendations that go a bit out of the scope
> of the document as we limit our scope to the outsourcing mechanism. As a
> result, I would prefer not to be too strong on these recommendations. We do
> not limit what can be put in the zone file.
>
>
> I agree, my point is that mentioning ULA use is like mentioning SLAAC or
> DHCPv6.  Just leave it out.  Use regular GUAs as the example.
>
>
I am wondering if that would work for you. I need to discuss with my
co-authors about removing ULA as I think they had a case for it.

A device or service SHOULD have Global Unicast Addresses (GUA) (IPv6
{{?RFC3787}} or IPv4), but MAY also have Unique Local IPv6 Addresses (ULA)
{{?RFC4193}}, IPv6-Link-Local addresses{{?RFC4291}}{{?RFC7404}},
IPv4-Link-Local Addresses {{?RFC3927}} (LLA), and finally, private IPv4
addresses {{!RFC1918}}.

> Section 4:
>>
>> In 4.1.1 the method in bullet point 3 seems very ugly.
>>
>>  This is an example. We updated the text as follows:
>
> """
> * If the DOI is not the DNS Registrar, then the proof of ownership needs
> to be established using some other protocol.
> ACME {{?RFC8555}} is one protocol that would allow an owner of an existing
> domain name to prove their ownership (but requires they have DNS already
> setup!)
> There are other ways such as putting a DOI generated TXT record, or web
> site contents, as championed by entities like Google's Sitemaster and
> Postmaster protocols.
> """
>
>
> OK, but it’s still far from “simple”.
>
sure but automated ;-)

>
> Section 5:
>>
>> In the diagram, does the DOI in fact cover the public authoritative
>> servers,
>> given you say “The DOI will serve every DNS request of the Public Homenet
>> Zone
>> coming from outside the home network.“ As it is the diagram shows the DOI
>> only
>> populating the public authoritative servers?
>>
>> That seems correct, we will update the figure.
>
>
> ok.
>
>
> In 5.2 does “protected” mean provision of confidentiality?
>>
>> at the very least with integrity protection, but here with TLS it means
> confidentiality.
>
>
> So maybe say that explicitly.
>
> changed to:
 Since communications are established with names which remain a global
identifier, the communication can be protected (at the very least with
integrity protection) by TLS the same way it is protected on the global
Internet - using certificates.

> Section 6:
>>
>> In 6.1, “perhaps and” ?
>>
>> In 6.5, the use of a DNS zone transfer to provide commands seems ugly.
>>
>>  this is the The HNA then performs a DNS Update operation
>
> Section 12:
>>
>> Talks about power cycling of the HNA.  This implies it’s resident on
>> specific
>> hardware, but what is expected or recommended?  COPE an d HNA are
>> sometimes
>> used interchangeably in the document.
>>
>> This document considers the HNA is hosted on the CPE but the HNA may be
> hosted elsewhere and the HNA should be seen as a function. In the
> renumbering section, we prefer to say the CPE is being renumbered as
> opposed to the function.
>
>
> OK, but again if there were a common, simple deployment model/process
> example in the appendix that might be clearer.
>
> Section 14:
>>
>> The document “exposes a mechanism” ?
>>
>> In 14.4, maybe mention here if any special considerations for a
>> replacement CPE
>> (and thus HNA if that model its used) are needed?
>>
>>  Well, I believe that is more related to the operation of the HNA, and
> this can be handled in multiple ways. The DHCP companion describes one way
> to do.
>
>
> OK.
>
> I also think Experimental would be a more appropriate classification for
> the document.  But it’s good to see it getting this far, and an
> implementation being available.
>
> Best wishes,
>
that is needed ;-)

> Tim
>
>
> Tim
>>
>>
>>
>> _______________________________________________
>> homenet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>
> --
> Daniel Migault
> Ericsson
>
>
>

-- 
Daniel Migault
Ericsson