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

Thanks Paul for the review,

Most of the DISCUSS was composed of questions we answered all of them, and
updated the text when necessary. You can see the change below:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/27233e962f66ad72db91dac7ec7b65b7cd3b00f4

We clarified the TTL and the use of CDS as an example. Please let us know
if there is anything you want us to change.

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.
>
> The document describes HNA, DM and DOI. These elements re-uses existing
architecture elements, protocols to communicate. I do not see and renaming,
but  maybe you might be more explicit. happy to clarify.

> For those parts where protocol glue is needed to use these DNS
> technologies,
> the document presents no solutions.

The comment i sunclear to me. Please be more explicit so I can address your
comment.

> 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)
>
> I do not understand the comment. The HNA creates the zone that is expected
to be published and instructs the DOI via the HNA to publish the zone. With
respect to the DS what the document says is that two entities can handle
the DS update the HNA and the DOI. We recommend when possible this to be
handled by the DOI. The HNA is able to request the DOI to take that in
charge and the DOI is able to respond whether it will handle it. How the
update is performed is out of the scope of the document.

> 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)
>
> no, the current version of the document does not  have the words TSIG and
SIG(0). In the previous version we had one section where we explained our
motivation for using TLS that was all. I am taking from your comment that
the more recent version address your comment correct ?

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 do not understand the comment. Typically the zone content is managed by
the user via the HNA.

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

yes, there are alternate ways to do what we do - we never said we were the
only way to handle this. We are the only one handling this at the zone
level as opposed to on a per RRSet basis.

>
>    *  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 the comment applies to has been removed. The section was non
essential to the protocol.

>    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 ?
>
> This was an example.

>    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.
>
> we never used TSIG, SIG(0)

>    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?
>
> The parent zone is part of the DNS infrastructure. What you seem to
describe is the configuration of the local resolver to request the local
authoritative server. We describe this aspect in the deployment
consideration mentioning it out of scope.

>    *  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?
>
> We use TLS, so we are relying on sessions

>    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?)
>

The text is saying HNA initiates a TLS session to a DM it knows. In oter
words the tLS session can be established.

>
>    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 cannot say what makes you think so. The homenet needs to support the HNA
and the DOI needs to support the DOI.that is all. What needs to be
supported is re-use a lot of existing DNS technologies, which makes things
straightforward.

> 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.
>
>    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 need more context to respond as it seems your well off track of what we
are saying in the document.

> 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 ?
>
> This is managed at th ezone level. I do not see any issue for what I
understand of your comment.

> 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"
> ?
>
> We use TLS with mutual authentication so the DM can authenticate the HNA.

> 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 ?
>
> see above.

> 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?
>
> see  Providing information for the Synchronization Channel. There no
RRSIG. DNS Update is just used to carry specific information to the DM.

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?
>
> If you delete a RRset in teh HNA, the synchronization mechanism will
delete it on the public servers.

> 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?
>
no TSI/SIG(0) only TLS.

>
> 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 want to avoid the management of PSK.

> 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?
>
> please explain. If there is no internal interface, the purpose of having a
homnet authoritative resolver is limited as far as I can see.

>    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?
>
> It could if the HNA and the Homenet AUthoritative Servers are combined,
but the general case is no.

> 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 ?
>
> (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 only purpose of this sentence is to say that other ways could be used.
It explains why we believe zone synchronization is prefered in our opinion.
This is an informative text.

>    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:
>
> generally it is assumed you know your domain name.

>    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.
>
> I agree the net admin is expected to knwo the domain name, but I think I
am missing the comment.

>    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
>
> 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.
>
> We hardly mention DHCP in this document. We are operating at teh zone
level. phones, laptop, tv do not need to implement anything.

> 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 ?
>
> In the simple case the HNA is colocated to the CPE, but that is not a
requirement otherwise we would have probably calle dit CPE.

> 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.
>
> The HNA and DM use a primary / secondary to synchronize their zone via the
synchronization channel, but that is not their only function.
Both have a control channel, HNA and DM create and update the zone, in a
different way primary/secondary usually do.

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

These ACLs need some parameters specific to the homenet, and we expect
these to be generated once the service has all it s parameters to operate.
It is unclear thought what do you mean with "Unless the CPE is pre
configured with service providers, ".

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)
>
no TSIG, we do not use TSIG.

> 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.
>
> could be yes. We do not prevent it and the Homenet Authoritative Server
has been introduced to distinguish the functionality of the HNA and
the Homenet Authoritative Server.

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

The idea of the HNA is a bit like the RZM. Its purpose is to issue the
Public Homenet zone to whoever needs it. It is not supposed to server the
zone. Now as you point out you may combine these functions.

>
> 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.
>
>  The architecture section (way before section 9) mentions what you are
saying I guess.
"""
As such their information as well as the corresponding signed DS record MAY
be provided by the HNA to the Homenet DNS(SEC) Resolvers, e.g., using HNCP
{{?RFC7788}} or a by configuring a trust anchor
{{?I-D.ietf-dnsop-dnssec-validator-requirements}}.
Such configuration is outside the scope of this document.
Since the scope of the Homenet Authoritative Servers is limited to the home
network, these servers are expected to serve the Homenet Zone as
represented in {{fig-naming-arch}}.
"""

We mention the resolver side is out of scope as we do not specify how it is
provisioned.

   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.
>
>  changed to
 Typically, the DS RRset can be updated manually in the parent zone with
nsupdate or othe
r mechanisms such as CDS {{!RFC7344}} for example.

>  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?)
>

I think the next sentence explains how this could be done. Just to clarify
here we mentioned the reverse zone - that owned by the ISP>The ISP SHOULD
ensure that the DNS cache has expired before re-assigning the prefix to a
new home network. This may be enforced by controlling the TTL values.

> And what of the CPE/HNA set TTLs on data of 1 year ?
>
> see above.

> 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)
>
> This is correct however, resolver will not consider that long TTL as per
ietf-dnsop-dnssec-validator-requirements and ietf-dnsop-ns
-revalidation.

We added the following text which I think provides clearer guidance:

The TTL and RDATA are those expected to be published on the Public Homenet
Zone.
Note that the TTL SHOULD be set following the resolver's guide line {{?I-D.
ietf-dnsop-ns
-revalidation}} {{?I-D.ietf-dnsop-dnssec-validator-requirements}} with a TTL
not exceedi
ng those of the NS.

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.
>
> This is one way to do, but you do not need DNS in that case. Managing
names over multiple VPNs is not trivial though - not to mention that
configuring and making VPN work  is not easy.

> The privacy and security of the DNS names is a small thing if homenet puts
> all
> my devices on the public IPv6 network.

The document distinguishes Public homenet zone and homenet zone so not all
your devices are expected to be public.

> 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.
>
>  This is the purpose of the entire section ## Names are less secure than
IP addresses that comes after.

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. we assume the HNA is provisioned with the DM.

>
>    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?
>
> registrars provide names, this is probably the easiest case.

> 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?
>
> There are different use cases, and maybe for some people that is easy to
remember. An ISP may provide a name just to identify the network, a
registrar may provide a name to bootstrap the relation.....

> 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 ?
>
 update the zone, sends a notify to the dm.

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

-- 
Daniel Migault
Ericsson