[homenet] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

(1) The security properties of the communication channels would benefit from
refinement.  In trying to piece them together, there appear to be
inconsistencies:

** Section 3.2.
   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].

-- Is this guidance scoped to all of the information exchanged between the HNA
and the DM?

-- (Editorial, treat as COMMENT). If so, please explicitly state the use of DoT
with normative language -- "DNS over TLS (DoT) MUST be used for ..."

-- If so, this suggests to me that all traffic is over TLS.  This text doesn’t
align with the Section 4.6’s weaker guidance that “[s]ecure protocols (like TLS
[RFC8446]) SHOULD be used to secure the transactions between the DM and the
HNA” as the text in this section does not make for allowance for anything
beyond DoT.

** Section 4.6.  Thanks for discussing the flexible deployment options in
section.  My concern is that the mandatory to implement security properties are
not sufficiently specified for an interoperable solution.  The statement “The
control channel between the HNA and the DM MUST be secured at both the HNA and
the DM” is helpful.  How does one conform to it?  What exact security
properties are required (MUST)?

Various text hints at these properties:
(a) Section 3.2 said that HNA and DM communication uses DoT (no normative
language)

(b) Section 3.2, “it is RECOMMENDED to use TLS with mutually authentication
based on certificates to secure the channel between the HNA and the DM.”

(c) Section 4.5, “ The provisioning process SHOULD provide a method of securing
the Control Channel, so that the content of messages can be    authenticated.”

(d) Section 4.6, “Secure protocols (like TLS) SHOULD ...” be used

(e) Section 4.6., “HNA SHOULD authenticate inbound connections from the DM …”

(f)  Section 4.6., “DM SHOULD authenticate the HNA …

Even assuming DoT is a MUST (which is not stated), all of these statements are
SHOULD or RECOMMENDED suggesting that the HNA might not need to authenticate to
the DM.

** Section 12.1.

The channels between HNA and DM are mutually authenticated and
   encrypted with TLS [RFC8446] and its associated security
   considerations apply.

I would recommend this design.  Where is this stated in a normative fashion? 
The text in Section 4.6 and 5.1 states that mutual authentication is a SHOULD.

(2) Why would internal clients have to use public DNS for internal services
given that there is an authoritative server for the Homenet Zone in the
internal network?

** Section 1.3
   When the resolution is performed from within the home network, the
   Homenet DNSSEC Resolver MAY proceed similarly.

I’m not sure if this my misreading of the behavior of internal clients.  To
clarify, the (internal) Homenet DNSSEC Resolver will “... resolves the DS
record on the Global DNS and the name associated to the Public Homenet Zone
(myhome.example) on the Public Authoritative Servers.”?  Why would the internal
resolver serving a request for an internal client for an internal service go to
the Global DNS if the information if it could come from the internal Homenet
Zone it is already configured with?  As an operational consideration, why go
outside of the network if you don’t need to?  As a privacy consideration, why
leak the request to an outside entity if the network already has the
information.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Warren's DISCUSS position and tried to be more specific on the
rational in my DISCUSS write-up.  I also support John's DISCUSS position which
highlights similar or potentially identical issues.  I have not attempted to
deconflict them.

** Section 1.
   Home network owners often have devices and services that they wish to
   access outside their home network - i.e., from the Internet using
   their names.  To do so, these names needs to be made publicly
   available in the DNS.

Note: this paragraph is also in the abstract

This text isn’t clear on the problem setup.
-- Per “… using their names”, names defined where?

-- Is there the unstated assumption that these devices are hosted on the home
network?

NEW
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).  To enable this access, the names and IP addresses of these
devices and services needs to be made available in the public DNS.

** Section 1.

   This document describes how a Homenet Naming Authority (HNA) can
   instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public
   Homenet Zone on its behalf.

-- Editorially, this paragraph doesn’t bridge at all from the previous one
describing the “home network” with “devices and services”.  What is the
relationship between the HNA, DOI and Public Homenet Zone and that previously
described network

** Section 1.  The last two paragraphs describe the role of most of the
sections in the document.  However, they omit Section 2.

** Section 1.1
(a)    While this document does not create any normative mechanism to select
   the names to publish, this document anticipates that the home network
   administrator (a human being), will be presented with a list of
   current names and addresses.

(b)   The administrator would mark which devices and services (by name),
   are to be published.

(c) The HNA would then collect the IPv6 address(es)
   associated with that device or service, and put the name into the
   Public Homenet Zone.

Per (c), why does the HNA need to collect the IPv6 addresses if the selecting
and marking processes of (a) and (b) already appear to have both the names+IP
addresses?  Aren’t the “marked” names+IP addresses from (b) getting fed into
the HNA?

** Section 1.2
   An alternative existing solution is to have a single zone, where a
   host uses a RESTful HTTP service to register a single name into a
   common public zone.

Why does it have to be a “single name”?  For example, the edge CPE/NAT/reverse
proxy device running the DDNS client could resolved to multiple public names
using the inbound SNI as a discriminator.

** Section 1.2.  the limitation sub-bullets #1 and 2 (“the CPE/HNA router …”)
makes reference to an HNA router without defining what it is.  If there is
going to be a comparison to the current practice to what’s proposed in this
specification, the architectural elements which are being compared need to be
introduced.  Baring that, at least provide a forward reference.

** Section 1.2.
     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].

Can you please provide a more specific section number in RFC7368 enumerating
the requirement that the CPE must serve the DNS queries for the services behind
it.

** Section 1.2.
   *  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.

-- Can’t the CPE and home network interdict the communication of the clients
contacting and registering an DDNS provider

** Section 1.2
      This is not a
      problem for a technical user to do with one or two hosts, but it
      does not scale to multiple hosts and becomes a problem for non-
      technical users.

Why does sharing of DDNS credentials not scale for technical users beyond one
or two hosts.  Is there an assumption that these are being shared by hand?

** Section 1.2
"all the good names are taken"  -current services provide a small
      set of zones shared by all hosts across all home networks.  More
      especially, there is no notion of a domain specific home network.
      As there are some commonalities provided by individual home
      networks, there are often conflicts.

I’m having trouble following the thesis of this bullet.

-- Per “current services provide …”, is it current “dynamic DNS services …”?

-- what is a “domain specific home network”?

-- what are the “commonalities provided by individual home networks …”?

** Section 1.2.

The RESTful services do not always support all RR types.

Is there a sense for what kinds of devices or services for which this is an
impediment?  Put in another way, many Dynamic DNS doesn’t support this now, so
what are the things running on the home network now that would benefit?

** Section 1.3.  Editorial. Given the sequencing of the text, the deployment
scenarios are not illustrative and largely opaque.  They rely on knowledge and
terminology of the proposed solution not yet explained in the document.  There
are no forward references to orient the reader.

** Section 1.3.1

Instead these
   keys are solely used by the HNA to proceed to the authentication.
   Normally the keys should be necessary and sufficient to proceed to
   the authentication. The reason to combine the domain name and the
   key is that DOI are likely handle names better than keys and that
   domain names might be used as a login which enables the key to be
   regenerated.

-- What does “proceed to authentication” mean?  Is there some kind of MFA
happening? -- The text says “The reason to combine the domain name and key …”,
but the text prior didn’t explain that this was happening.

** Section 1.3.1.  Editorial.

OLD
An CPE that is not preconfigured may also take advantage to the
   protocol

NEW
An CPE that is not preconfigured may also take advantage of the
   protocol

** Section 1.3.1.  Editorial.

OLD
The owner of the home network buys a domain name to a registrar

NEW
The owner of the home network buys a domain name from a registrar

** Section 3.  Typo. s/detaille din/detailed in/

** Section 3.  Editorial.  Make clear this is a statement about the example.

OLD
The Public Homenet Zone is identified by the Registered Homenet
   Domain Name - myhome.example.

NEW
In this example, the Public Homenet Zone is identified by the Registered
Homenet Domain Name - myhome.example.

** Section 3

the HNA communicates and
   synchronizes it with the DOI using a primary/secondary setting as
   described in Figure 1.

I understand the intent of the text and who is operating as the primary and
secondary from it.  However, I don’t see how Figure 1 reflects the primary and
secondary configuration.

** Section 3.  Editorial.  The term “hidden primary” is not in used in RFC8499.
 I believe the term there is “hidden master” which we stopped using for
inclusive language reasons.  Cite Section 6 or provide bridging text between
the old and new term.

** Section 3.  Typo.  Missing close parentheses.  s/ one or more Distribution
Channels (Section 6 that/one or more Distribution Channels (Section 6) that/

** Section 3.2.
The visible NS records
SHOULD remain pointing at the cloud provider's server IP address.

Who is the cloud provider in Figure 1?  Is cloud provide the DOI?  If so,
please use consistent terminology in the normative language.

** Section 4.5. s/any any/

** Section 10.  Typo. s/The remaining of the/The remainder of this/

** Section 11.

The Public Homenet Zone lists the names of services hosted in the
   home network.  Combined with blocking of AXFR queries, the use of
   NSEC3 [RFC5155] ...

Thanks for calling out that NSEC3 provides some mitigation for zone
enumeration.  Since it’s use is not mandatory (only RECOMMENDED), please
explicitly state the consequence of it NOT being used (i.e., an enumerated list
of services on your internal network).

Section 12.2.  The analysis in this section seems to be focused on IPv6
addresses. Section 1.1. seems to allow for IPv4.  Please reflect that.

** Missing Operational Considerations.

HomeNet technologies makes it easier to expose devices and services to the
Internet.  This imposes broader operational considerations for the operator and
the Internet:

-- The home network operator must carefully assess whether a device or service
previously fielded only on a home network is robust enough to be exposed to the
Internet

-- The home network operator will need to increase the diligence to regularly
managing these exposed devices due to their increased risk posture of being
exposed to the Internet

-- Depending on the operational practices of the home network operators, there
is an increased risk to the Internet architecture through the possible
introduction of additional internet-exposed system that are poorly managed and
likely to be compromised.  Carriers may not to deployed additional mitigations
to ensure that attacks do not originate from their networks.