Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

Hi Paul,

As mentioned offline, I am rebooting the conversation and addressing the
DISCUSS and comments. Please let me know if there is anything that needs to
be clarified or if additional information is needed. I tried to remain
quite high level in my responses in an effort to address high level
concerns.
I think this will fix the main concerns and we can later narrow the
discussion to more technical / detailed discussion. I can envision some
more specific text regarding the update of the DS for example.

Yours,
Daniel

On Thu, Oct 20, 2022 at 1:46 AM Paul Wouters via Datatracker <
noreply@ietf.org> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-homenet-front-end-naming-delegation-18: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I have to agree with Warren here. I do not understand how this protocol is
> supposed to work. It renames a bunch of DNS terms (hidden primary, primary,
> seconday, AXFR/IXFR, DNS update --> HNA, DM, DOI, Control Channel, Sync
> channel) which makes the document very hard to read.
>
> As far as I can tell, I do not think we rename any entities. Let me give a
more detailed overview. The overall mechanism is that the homenet defines a
DNS zone for its home network and this zone contains the names of the
devices that can at least be published outside.

Because the CPE of the home network is not willing to host the
authoritative server on the wild Internet it will outsource this to a DNS
Outsourcing Infrastructure. The draft details how the home network
outsource the DNS zone to the DOI.
The entity in the home network that is in charge of outsourcing the DNS
zone to the DOI is the Homenet Naming Authority (HNA). The DOI has at least
two functions: 1) interacting with the HNA and 2) publishing the DNS zone
on the Internet. The entity interacting with the HNA is designated as the
DM  (Distribution Manager). The protocol we describe in the document is
solely between the HNA and the DM.
DNS defines a mechanism known as primary secondary or master slave
synchronization to synchronize a zone between two servers. Such mechanism
is instantiated between the HNA and the DM and requires the DM and teh HMA
some configurations parameters to be agreed. This is why we have two
channels:
* the control channel where the HNA and the DM agree with the necessary
parameters to set their primary / secondary relation
* the synchronization channel which is the   primary / secondary relation.

As a result HNA and DM can be seen as the entity configuring the zone
synchronization as well as configuring the zone synchronization. In a
homenet perspective the HNA is also likely to generate the zone and sign it.

Though we do not modify  in any way the DNS zone synchronization
mechanisms, the control channel uses DNS messages to exchange some
parameters between the HNA and the DM. We could have used JSON, but the WG
chose to re-use DNS messages as a means to carry some information and the
messages that have been selected were DNS update and AXFR exchanges.  This
are only used a s a convention and do not have the standard meaning we
usually give to AXFR and DNS update. In fact no zone is involved over the
parameters exchanged over the control channel.

> For those parts where protocol glue is needed to use these DNS
> technologies,
> the document presents no solutions. I don't understand if users can create
> their own named zones, or whether this is only provider generated zones.
> The
> latter seems less useful to the user, the former seems to need more
> specification on how to handle registry/registrar/registrant matters
> (especially with respect to DS)
>
> So, the idea is that the honment is able to generate its own zone as it
wishes. Our protocol assumes the HNA knows which DM it needs to contact and
the DM is able to authenticate the HNA ( as the owner of the
registered domain name). In the most generic way, these parameters needs to
be configured in the HNA, however, we just mention in the document there
are cases where such configuration can be eased.
The protocol we describe limits its scope to the outsourcing operation from
the HNA to the DOI. This requires for example the zone is being
provisioned with the appropriate NS of the DOI, this requires the DM to be
aware of the IP address of the HNA to synch the zone and operate as a
secondary. Regarding the update of the DS we do not provide any additional
mechanism except that we enable the HNA to request the DOI to proceed to
the update and let the DOI to respond whether it will do it or not. If the
DOI is not doing it, the HNA has to find how it will do it, but we do not
go beyond this.

> The security seems to mix up transport security with TLS and data integrity
> security of the DNS protocol (typically TSIG or SIG0, but the document
> claims
> this cannot be used)
>
> We are only using TLS, that is no TSIG, and no SIG(0).

> Having provider generated homenet named DNS zones makes scanning for
> hostnames
> in those zones much easier than scanning an entire /64 IPv6 for vulnerable
> devices. Eg well known host names like "tv" or "LG" or "washing_machine" or
> just any <= 8 character string based hostnames or dictionary attacks.
>
> I agree we do have such a statement in the  "Names are less secure than
IP addresses". I am happy to add whatever you think is missing in that
section, but I think that idea is there.

> Like Warren, I've added my notes as comments without splitting them further
> into DISCUSSes or COMMENTs
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>    *  the CPE/HNA router is unaware of the process, and cannot respond
>       to queries for these names and communications to these names
>       require an Internet connectivity is order to perform the DNS
>       resolution.  Such dependence does not meet the requirement for
>       internal communications to be resilient to ISP connectivity
>       disruptions [RFC7368].
>
> If there is a host within the home network that is the DHCP/DNS server,
> then this does not require further support from a CPE/HNA or internet
> uplink. For example Linux openwrt with avahi and dnsmasq is a common
> deployment of this: https://openwrt.org/docs/guide-user/base-system/dhcp
> Arguably, one could say openwrt is the CPE/HNA in such case, provided
> that user has their own domain they can send "dynamic DNS" updates for
> on the public internet hosting their homenet zone.
>
> This comment concerned the section that compared DynDNS and our mechanism.
We removed the section as it was controversial. At a very high level what
we are saying is that each device being configured with a dynDNS client is
harder to manage than having the HNA managing the zone and outsourcing the
zone. As pointed out by Warren, there are some cases where the CPE can use
DynDNS and synchronize multiple names. This could result in a similar
behavior as handling a zone but on  a per record basis. To me the major
difference is that you can outsource a zone as opposed to outsource a set
of records. This provides much more flexibility to the home network for
example.

Back to your comment, yes the dynamic update can be sent by the HNA.

>    *  the CPE/HNA router cannot control the process.  Any host can do
>       this regardless of whether or not the home network administrator
>       wants the name published or not.  There is therefore no possible
>       audit trail.
>
> To be fair, even with dpeloying all of homenet, those hosts can still keep
> doing this - choices made here does not affect this, so I don't see this
> as a valid argument one way or the other.
>
The section has been removed, but what we meant was that for an admin
having a centralized solution is easier for management purposes. We did not
intend to say the mechanism prevents individual nodes to do otherwise.
This could potentially be handled by firewall rule, but we did not mention
this.

>
>    The DOI is also responsible for ensuring the DS record has been
>    updated in the parent zone.
>
> This sentence carries a LOT of process/protocol work. Will it use CDS? How
> is
> the authorization boot strapped? Does it work for non-ISP generated zones,
> eg
> "toronto.nohats.ca" ? If so, how does it handle delegation of NS and DS ?
>
> I do agree this is not trivial work and we did not detail how the DOI is
doing it. The position of the draft is to basically say, this has to be
done either by the HNA or the DOI. In practice we expect the DOI to have
the ability to do that with the parent zone. We do not expect the practice
to be different from what is currently being used today.

>    The information exchanged between the HNA and the DM uses DNS
>    messages protected by DNS over TLS (DoT) [RFC7858].  In the future,
>    other specifications may consider protecting DNS messages with other
>    transport layers, among others, DNS over DTLS [RFC8094], or DNS over
>    HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250].
>
> what does "protected" here mean? Privacy protection? Because if it is using
> DNS Dynamic Updates, the data authenticity protection comes from a
> TSIG/SIG0
> key.
>
> Protected means TLS here. We only use TLS.

>    The main issue is that the Dynamic DNS update would also update the
>    parent zone's (NS, DS and associated A or AAAA records) while the
>    goal is to update the DM configuration files.  The visible NS records
>    SHOULD remain pointing at the cloud provider's server IP address -
>
> But isn't this simply a "forward" statement for the zone to the private IP
> of the local DNS authoritative server within the local DNS recursive
> server?
> That way, the recursive dns IP does not need to have a NS record at all, so
> there is also no risk of accidentally pushing it out to public servers and
> replacing the real NS records?
>

So the document is primarily focused on describing the interaction between
the  HNA and the DM. The remaining information related to how this
integrates with the more generic naming architecture of the home network is
sort of complementary information to explain 1) what we are describing 2)
how what we are describing may interact with other components of the home
network.
Here what we are saying is that the zone outsourced by the HNA should not
have the private IP address of the homenet authoritative DNS server because
the zone will be published to the Internet by the DOI.
As you are pointing out, for a node inside the homenet there is not a
necessity to reach the DOI on the wild internet, but the resolution can be
handled internally. Internally there are at least three entity that can be
reached 1) the local resolver, 2) the local authoritative server, 3) the
hidden primary.  As you can guess there are many ways these three entities
can be combined.
As far as I remember, we tried to highlight that the
local authoritative server may not be implemented and might be combined
with the resolver (by dumping the zone of the hidden primary). I do not
think we mention the resolver setting the local authoritative server as a
forwarder, but that could be also one way to implement it.

The main challenge we foresee is that making DNSSEC resolution entirely
inside the home network, requires the chain to be validated which either
requires some provisioning mechanism to distribute the TA that have not yet
been defined. We believe that for a long time caching the necessary RRset
from a global DNSSEC resolution will be considered sufficient.

>    *  By default, the HNA uses a single IP address for both the Control
>       and Synchronization channel.  However, the HNA MAY use distinct IP
>       addresses for the Control Channel and the Synchronization Channel
>       - see Section 5 and Section 4.3 for more details.
>
> Why does this matter and need mentioning? TSIG/SIG0 would not care about
> the
> IP address used, and/or whether it is NATed?
>
> In this case we used TLS to secure the transactions. The DM needs to know
the IP address of the HNA to request the SOA and for the zone transfer.

>    As such the HNA has a prior knowledge of the DM identity (X509
>    certificate), the IP address and port number to use and protocol to
>    set secure session.
>
> Ah, so this is a preconfigured IP/name/TSIG/SIG0 key, and limits the HNA to
> only CPE supported DNS providers? Either this locks in where users can host
> their homenet zone based on CPE preconfiguration, or it is just a fancy
> way of
> saying "configure your DNS server with your remote DNS settings" (which
> would
> not need anything of this document to run, and I was hoping this document
> was
> going to provide some automation for this?)
>
Some elements are configured. The document provides some information of
potential mechanism that could ease even further the configuration but the
current document basically says, there is some basic information the CPE
(HNA) needs to be configured with other information can be dynamically be
retrieved from your DOI and as such do not need to be configured.

The section  Information Model for Outsourced information details the
potential information and  draft-ietf-homenet-naming-architecture-dhc-options
provides some examples of the parameters that are needed.
Essentially, you need to configure the HNA with the registered domain (that
is the domain name used for your home network) and the DM ( a FQDN). In the
DHCP option we specified the transport but currently only one transport is
used DNS over TLS. It is likely you also use a certificate so the DM
authenticates the HNA.
The DHCP option completely automates the process for example.  There
probably means to take advantage of other mechanisms (OAUTH, ACME) to
further automate this but we only mention them and did not specify further
how this can be done.

>
>    The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
>    provides this value to the parent zone.  A common deployment use case
>    is that the DOI is the registrar of the Registered Homenet Domain and
>    as such, its relationship with the registry of the parent zone
>    enables it to update the parent zone.
>
> This now means that the solution is limited to those scenarios that have:
> - CPE support for homenet RFCs
> - ISP support for CPE for HNA for DOI that supports DNSSEC DS submission
> via
> EPP, or - A Registrar that is also DNS hoster AND supports DNSSEC AND
> supports
> CDS/CDNSKEY AND supports AXFR/IXFR
>   AND supports homenet RFCs
>
> I would argue these requirements are far more restrictive than:
> - CPE with support for stock Dynamic DNS updates for itself only (eg client
> registrations,
>   but could also be autoatic conversion of MDNS/.local to its local homenet
>   zone.
> - CPE that can run recursive with an authoritative zone
> - Any DNS hoster that supports AXFR/IXFR, DNSSEC and CDS/CDNSKEY
> - Any Register that supports DNSSEC
>
> with the only difference that the latter one needs a one step registration
> of
> the initial DS record.
>

What is needed is
- a CPE that supports this specification
- a DOI that supports this specification

More specifically, the ISP is out of the scope. The document mentions the
ISP only for the reverse zone in which case it plays a specific role. Of
course the ISP may also play the role of a registrar.
The registrar does not necessarily need to support DNSSEC as the zon eis
expected to be signed by the HNA. If the Registrar is able to take in
charge the DS update with the parent zone this eases the process.
The registrar does not support AXFR/IXFR on the Internet, however, these
requests are used between the HNA and the DM to synchronize the zone. This
is equivalent to supporting the DNS update.

Note also that HNA and DOI may also agree out-of-band that the DOI will
handle the DNSSEC signing, but this is seen as outside the scope of this
document. In that case, the HNA is probably not expected to sign the zone.

Regarding the DS update, I do not think we are changing how this is done
today.  In other words the text is not trying to make it different, but if
you feel this is underspecified, we can add some clarifications. To our
perspective there are two entities that can take the DS update in charge:
the HNA and the DOI and the HNA is able to determine if the DOI will handle
that on its behalf or not.

>
>    Though the HNA may also later directly update the values of the DS
>    via the Control Channel, it is RECOMMENDED to use other mechanisms
>    such as CDS and CDNSKEY [RFC7344] for transparent updates during key
>    roll overs.
>
> If this is going to be a fully automated enduser CPE solution, this
> RECOMMENDED
> is too weak. It should be a MUST because otherwise DNSSEC rollover is just
> impossible.
>

I am happy to move it to SHOULD.

>
> Section 4
>
> this all seems to imply "registered domains". Can these be subdomains? Eg
> can I
> own nohats.ca and configure one CPE for toronto.nohats.ca. and the other
> for
> amsterdam.nohats.ca. ? This involves talking to NS for nohats.ca for sub
> delegation, but I don't see that mentioned anywhere ?
>
> If you buy nohats.ca, you can do whatever you wish under that zone. Such
configuration is a bit out of scope of the homenet as your are trying to
sync to different homenet within a single domain. I cannot say this has
been seen as the primary use case, which is the reason we do not extend the
description. We initially also considered multiple domain names, but
we agree to remain focused on the simplest use case.
That said, I do not see what prevents you from doing what you want. One way
to do this is to sync three different zones.  Another way is to combine all
subdomains into a single zone.

> Section 4.5.1
>
> How would the bootstrap work. I pick "paulhomenet.com" as my zone, but
> then my
> CPE doens't have nameservers for it, so it does AXFR via the Control
> Channel ?
> And get a set of NS records back that my CPE adds to paulhomenet.com ?
> And then
> it becomes authoritative? How is the ownership of paulhomenet.com tested?
> if it
> is registered, who will be the registrar, registrant? Is ".io" supported?
> Or
> other TLDs? Or will this all be under "nameyoupick.homenet.cpevender.com"
> ?
>
> In the current model we assume that picking means you registered at
paulhomenet.com in which case, you can be authenticated by the registrar.
The DOI may be the registrar or any other entity but that is correct it
needs to get some proof you own the domain. Such ownership is proved by
default when the registrar and the  DOI are the same entity. registrar and
DOI may also communicate out of band. The situation is not different from
what we have today between a DNS hoster and a registrar.
Assuming the DOI can authenticate you as the owner of the domain name, yes
you get information from the control channel to configure your zone. you
use axfr but consider this as a HTTP/GET. With that information (and other)
the HNA  is able to configure the zone and the primary/secondary setting.
Once set the DOI sync the zone and publishes it.

AXFR is normally based on authentication of domain name plus shared key. How
> does that work when creating a _new_ domain name by the enduser? How can
> this
> be authenticated without knowing the zone name ?
>
This is not something we defined. If you want paulhomenet2.com you will
have to buy / register that domain.

>
> Section 4.5.3
>
>    The default IP address used by the HNA for the Synchronization
>    Channel is the IP address of the Control Channel.  To provide a
>    different IP address, the HNA MAY send a DNS UPDATE message.
>
> What does this DNS UPDATE message contain? It says NS records but what
> name? And as this is the authoritative server sending an DMS UPDATE
> message, it would need to send the RRSIG too, which means it needs to
> set the entire NS RRset? Which means it needs to know the remote NS
> records, but how can it do that without first already using the proper
> IP address to talk to the systems?
>
> The DNS UPDATE is just a conventional format used to carry the
information. You should see it as a HTTP/POST. The message is carried over
the TLS protected channel between the HNA and the DM. There is no zone
being updated. The DM just takes the value provided to configure the
secondary / primary.

> Section 4.5.4:
>
> If a deletion is processed, what happens with the domain name? Will all
> its NS records be deleted and it is now a lame delegation? How is the
> enduser
> supposed to get their domain under their own control again? Is it ever
> truly
> theirs?
>
>  Deleting the delegation means the zone is not anymore hosted by the DOI.
The DOI - at least in the current document - is not oowning the domain
name., INstead the domain name is owned by the hoement user.

4.6 Securing the control channel
>
> Isn't this channel DNS dynamic updates? Are these not secured by TSIG/SIG0
> ?
> Did you mean TLS only for privacy considerations and not security
> considerations?
>
> Apparently this is not the case?
>
>    A pure DNS solution using TSIG and/or SIG(0) to authenticate message
>    was also considered.
>
>    A way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0)
>    space seems overly problematic,
>
> Why not use TSIG? That is literally the keyed hash of a blob, and the blob
> can
> be an OAUTH2 token ?
>
> We only use TLS. We agreed to move away from TSIG as key management was
considered too hard to be handled properly.

> ection 4.7
>
>    Interface Binding:  the Hidden Primary Server will almost certainly
>       listen on the WAN Interface, whereas a regular Homenet
>       Authoritative Servers would listen on the internal home network
>       interface.
>
> Does that matter if either one provides a routable public IPv6 address?
>
> We assumed the homenet communication are using local scope addresses. Of
course if there is no internal interface, that is something to be adapted.
That said, I would not consider this as a best practice, so if we
would like to take this path, we probably need to raise situation where
this makes sense.

   Limited exchanges:  the purpose of the Hidden Primary Server is to
>       synchronize with the DM, not to serve any zones to end users, or
>       the public Internet.
>
> I thought it was serving endusers so that local things would keep working
> with a broken internet link? Or at least "serve" its "resolver" part. And
> also serve as auth server to take in DNS Dynamic Updates?
>

As mentioned earlier, the naming architecture has been provided as
illustrative for our purpose. We distinguished the Homenet resolver, the
Homenet authoritative server and the HNA with hidden primary.   These
entities are expected to have different functions, though real
implementation may combine these functions in one way or another.
Essentially the purpose of the homenet authoritative server is to replicat
ethe zone on teh DOI as to ensure resolution can be performed in case
of internet disruption.,

>
> Section 5:
>
>    Uploading and dynamically updating the zone file on the DM can be
>    seen as zone provisioning between the HNA (Hidden Primary) and the DM
>    (Secondary Server).  This can be handled via AXFR + DNS UPDATE.
>
> I don't see how the start of this works, when the end user tells their CPE
> the name of their local homenet zone ?
>

The end user tells the CPE the name of its network by configuring it.

>
> (also I think you mean AXFR/IXFR ? The DNS UPDATE would be the local
> machine
>  talking to the local CPE ? Not between HNA and DM?)
>

The purpose of this sentence is to say that there may be other mechanisms
we do not mean to define the only way this can be achieved. However, we
believe we provide some advantage over the way Dynamic DNS does.

>
>    Note that there is no standard way to distribute a DNS primary
>    between multiple devices.  As a result, if multiple devices are
>    candidate for hosting the Hidden Primary, some specific mechanisms
>    should be designed so the home network only selects a single HNA for
>    the Hidden Primary.  Selection mechanisms based on HNCP [RFC7788] are
>    good candidates.
>
> This seems rather under specified. If there is only one, how is it found
> and
> used? I was expecting that the domainname configured on the CPE would be
> queried for DNS UPDATES by clients. But looking at RFC2136 Section 4:
>
>    From a requestor's point of view, any authoritative server for
>    the zone can appear to be able to process update requests, even
>    though only the primary master server is actually able to modify the
>    zone's master file.  Requestors are expected to know the name of the
>    zone they intend to update and to know or be able to determine the
>    name servers for that zone.
>
> We do not update the zone using DNS update and the synchronization of a
DNS zone is only performed between a primary and a secondary./ You cannot
have n primaries and one secondary each primaries taking in charge of a
subpart of the zone.

   If the requestor has reasonable cause to believe that all of a
>    zone's servers will be equally reachable, then it should arrange to
>    try the primary master server (as given by the SOA MNAME field if
>    matched by some NS NSDNAME
>
> The point you raise is that if a device were using the DNS update to
update its IP address for example, it would send it to the DNS
authoritative servers of the DOI. In the document we do not specifically
mention how the provisioning of the zone is performed, and we assigned
the HNA to be responsible for this.  There are probably ways to specify
this in more detail in the document, but I believe that is more related to
a naming architecture document.,

> This would be only one possible target based on the domainname given to
> a device via DHCP. What "some specific mechanism should be designed" will
> be deployed for the clients (eg my phones, laptop and TV ?) I think the
> only real chance they have of doing this (without waiting 10 years for
> all our electronics to cycle/get updated) is standard the SOA MNAME's IP
> address, eg RFC 2136 DNS Dynamic Updates. My devices already support this.
>
> I suspect HNCP is designed to do this.

> So that redefines the above problem to "Who becomes the Hidden Primary",
> which I assumed was the CPE supporting this framework ? And if there
> are more than one CPE that can do this, it should be configured by
> the user to be done only by one CPE - similar to have a user should
> ensure there is only one DHCP server running in the network ?
>
> HNCP does proceed to an election.

> Section 5:
>
>         First the HNA (primary) notifies the DM (secondary)
>
> The entire document would have been so much more readable if HNA and DM
> had not been introduced and primary/secondary was used througout.
>
> primary / secondary are one function implemented by the HNA and the DM. I
also believe that in a homenet context the HNA give more context to what is
happening than the hidden primary - as this is an entity responsible to
manage the naming of the homenet.

>    The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they
>    only arrive from the DM Synchronization Channel.
>
> Unless the CPE is preconfiguted with service providers, these ACLs cannot
> come by default? Also, if this channel uses TSIG (which also needs
> preconfiguration) then it can already ACL this based on the known shared
> secret. No IP based ACLs needed (which are risky to put into CPE firmware
> as
> networks change)
>
> We do not use TSIG, but essentially the ACL can likely be generated
automatically including or not the IP address depending on what is believed
more appropriated.

> Section 7:
>
> Why can't the HNA be the local authoritative server for clients? Why should
> this functionality be split in two? It just means another recursive
> resolver
> needs to query the HNA (and have it configured as forwarder) for the local
> homenet zone (in case uplink goes down). For example, this could be a
> single
> instance of the Bind DNS server dong both authoritative and recursive DNS.
>
> sure it could but not necessarily. We split the functions to make it clear
these are different functions. As mentioned earlier, how these functions
will interact is really dependant on implementations and many things can
happen.

> Dropping received queries for DNS servers is always a bad idea, as it just
> causes the client to retransmit. Always returning an error is the common
> DNS reply strategy. This section goes against common best practise for DNS
> servers.
>
we can work on that but the idea was to avoid the application layer to be
activated unless it is legitimate.  I believe that there is no reasons to
receive a DNS packet in this interface and that filtering at the IP layer
is appropriate.

>
> Section 9:
>
>   [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both
>    the authoritative server and the resolver.  The resolver side is out
>    of scope of this document, and only the authoritative part of the
>    server is considered.
>
> But if things must work without an internet connection working, then the
> resolver needs to be configured for the homenet domain to ask the HNA
> and not go the regular upstream path. So it should be in scope I believe.
>
> So it is in scope of a naming architecture, but the scope of the document
is limited to the outsourcing of the zone to a DOI. As far as I can say,
the document provides some insight on how this could be achieved - using
HNCP, but does not go any further.

>    Typically, the DS RRset can be updated
>    manually in the parent zone with nsupdate for example.
>
> I don't think this applies to "typical DS". The DS RRset lives on the
> "wrong"
> side of the zone cut. A dns update client is would not have permissions to
> update its parent zone with dns updates, only its own child zone. So this
> would be better done by pushing a CDS record and let the parent pull the
> CDS
> and recreate its own DS record. This method is not widely supported by
> TLDs,
> and I dont know how this solution would work for second or third level
> domains,
> eg if I use provider X to host nohats.ca, and provider Y for my home
> internet
> and I want toronto.nohats.ca to be my home network name using CPE vendor
> Z.
>
> Typically was here to illustrate the previous sentence that said DS needs
to be updated by an authorized party.  I agree manual may be not the right
wording. I agree with your thought and will be mostly happy with anything
you would prefer toi see.

> Section 10:
>
>    The ISP SHOULD ensure that the DNS cache has expired before re-
>    assigning the prefix to a new home network.
>
> How does it do that? It can't send queries to get the data for TTL anymore,
> since the network already got renumbered and returned and the NS servers
> removed. The records now only live in worldwide caches. You don't know the
> TTL.
> Unless you grabbed the data just before getting it returned. But that is
> also
> unlikely, eg imagine a user taking down their CPE because they moved house.
> >From the ISP point of view the network just vanished including all its
> nameservers for it (the public ones will work for a while but will the ISP
> act
> within that time?)
>
In that case the ISP is the DOI and is able to implement a maximum TTL. It
can take this maximum value as the upper bar.

>
> And what of the CPE/HNA set TTLs on data of 1 year ?
>
> The DOI is expected to provide a maximum TTL.

> The TTL math in section 10 makes no sense to me as the CPE/HNA could set
> it to
> whatever it wants. The ISPs secondary servers cannot change the TTL (it is
> protected by DNSSEC from being modified)
>
> Section 11:
>
> The Privacy Considerations section is a bit hard to read. But in the end it
> comes down to "dont make your homenet DNS publicly reachable if you want
> privacy". Indeed, I find publishing my entire home network into public DNS
> a
> serious risk. DNS scanners will end up scanning for well known names of
> popular
> brands of TVs, washing machines, saunas, lightbulbs, etc. Or they will
> start
> scanning zones based on well known ISP based secondary services. It is
> almost
> as if the better solution would be to only provide a publicly reachable
> homenet
> VPN server, that provides both DNS and the only working routes from my
> (remote)
> devices on my to my home network based devices.
>
Handling multiple VPNs makes such a solution quite hard to manage. I agree
this could be an alternative but with very limited usage. The case we have
been discussed is when you need to have access to a few homenets.

>
> The privacy and security of the DNS names is a small thing if homenet puts
> all
> my devices on the public IPv6 network. Scanning IPv6 is still fairly hard
> to
> do, even of endusers /64. And putting those IPv6 addresses in DNS makes it
> much
> much easier to find all these devices and use their exposed services to
> compromise the device and/or network that they are in. These
> considerations are
> completely missing from the Security Considerations Section 12.
>
> Appendix A:
>
>    This document does not deal with how the HNA is provisioned with a
>    trusted relationship to the Distribution Manager for the forward
>    zone.
>
> But that is core to the protocol ?
>
> No the core protocol is about outsourcing the zone to the DOI.

>    Similarly, if the HNA is provided by a registrar, the HNA may be
>    handed pre-configured to end user.
>
> How can that be if the user decides on the homenet network name it wants
> to use?
>
> Then it needs to configure the HNA, THe example was provided as an
illustration of use cases where such configuration is not performed by the
end user.

> Appendix C:
>
> The example zone used is n8d234f.r.example.net. I thought the idea was
> for the
> user to have a memorable zone it can use, eg sharing with friends. Was I
> wrong?
>
If a user chooses a name it is likely the name will be more friendly. That
name was  provided as an example of free name provided by the hardware
vendor for example. The ISP may provide similar type of names. It is
clearly not a name that is nice, but that can also be used as a
bootstrapping name that the user may use a nicer name and redirect that one
to the ugly name.

>
> with the "dm_acl"    : "2001:db8:1234:111:222::/64", set, what happens to
> the
> zone "n8d234f.r.example.net." when the user got unplugged and replugged
> and
> lives on a different ip range now ?
>
>
>  The dm_acl is related to the DM so the renumbering of the HNA may not
affect the parameter. That say, I agree that seom checks of the
configuration are likely to be performed and an error may be raised. Note
that we provided these parameters as plausible parameters but, it also
shows that when not limited to the strict minimum it would be good to
design a mechanism these configuration parameters can be provided
automatically on a regular basis as to be able to refresh the
configuration.

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

-- 
Daniel Migault
Ericsson