Draft: draft-ietf-homenet-front-end-naming-delegation

Commentary: published version 16 
 Line # 720 in renumbering . ( could not do this inline ) The intent of the text is not very convincing . I do not see your recommendation to support make - before - break . How does HNA satisfy the condition of seamless reachability ? What does it need to do ? Is there a state machine needed here ? Especially , one of the claims of this document is the automation of the procedures . How do you achieve renumbering without asking the end - user to do something ? Do you want HNA to be provisioned with these time values ? This was my last inline comment . I will skip the security / privacy part for now . I have gone through it once and did n't find anything I could add to . Other general comments on the document are : for addressing earlier comments . The document looks much better to me . places in the document , felt more like " how to do this , now that you have an HNA " rather than the HNA specification itself . Maybe this is due to my lack of domain knowledge but I felt the document could have been more concise .
This document describes the mechanism that enables the HNA to
outsource the home network naming service to the DNS Outsourcing
Infrastructure (DOI) via a Distribution Manager (DM).
In addition, this document deals with publication of a corresponding
reverse zone.
The HNA is responsible for making devices within the home network
accessible by a public name within the home network as well as from
outside the home network (e.g. the Internet).  IPv6 connectivity
provides the possibility of global end to end IP connectivity.
The use of a DNS zone for each home network is a reasonable and
scalable way to make the set of public names visible.  There are a
number of ways to populate such a zone.  This specification proposes
a way based on a number of assumptions about typical home networks.
The names of the devices accessible from the Internet are stored
in the Public Homenet Zone, served by a DNS authoritative server.
It is unlikely that home networks will contain sufficiently robust
platforms designed to host and expose to the Internet a service
such as the DNS and as such would expose the home network to DDoS
attacks.
RFC7368 emphasizes that the home network is subject to
connectivity disruptions with the ISP.  But, names used within the
home MUST be resilient against such disruption.
This specification makes the public names resolvable within both the
home network and on the Internet, even when there are disruptions.
This is achieved by having a function inside the home network that
builds, signs, publishes, and manages a Public Homenet Zone, thus
providing bindings between public names, IP addresses, and other RR
types.
The management of the names can be under the responsibility the
Customer Premises Equipment (CPE) does.  Other devices within the
home network could fulfill this role e.g. a Network Attached Storage
server, but for simplicity, this document assumes the function is
located on one of the CPE devices.
The homenet architecture RFC7368 makes it clear that a home network
may have multiple CPEs.  The management of the Public Homenet Zone
involves DNS specific mechanisms that cannot be distributed over
multiple servers (primary server), when multiple nodes can
potentially manage the Public Homenet Zone, a single node needs to be
selected per outsourced zone.  This selected node is designated as
providing the HNA function.
The process by which a single HNA is selected per zone is not in
scope for this document.  It is envisioned that a future document
will describe an HNCP mechanism to elect the single HNA.
CPEs, which may host the HNA function are usually low powered devices
not designed for supporting a heavy traffic.  As a result, hosting an
authoritative DNS service visible to the Internet may expose the home
network to resource exhaustion and other attacks.  On the other hand,
if the only copy of the public zone is on the Internet, then Internet
connectivity disruptions would make the names unavailable inside the
homenet.
In order to avoid resource exhaustion and other attacks, this
document describes in sec-arch-overview an architecture that
outsources the authoritative naming service of the home network.
More specifically, the HNA builds the Public Homenet Zone and
outsources it to a DNS Outsourcing Infrastructure (DOI) via a
Distribution Manager (DM).  The DOI is in charge of publishing the
corresponding Public Homenet Zone on the Internet.  The transfer of
DNS zone information is achieved using standard DNS mechanisms
involving primary and secondary DNS servers, with the HNA being a
stealth primary, and the DM a secondary.
In order to keep the Public Homenet Zone up-to-date sec-synch
describes how the HNA and the DOI synchronize the Pubic Homenet Zone.
The architecture is explicitly designed to enable fully functional
DNSSEC, and the Public Homenet Zone is expected to be signed with a
secure delegation.  DNSSEC key management and zone signing are
handled by the HNA.
hna-provisioning discusses management and configuration of the Public
Homenet Zone.  It shows that the HNA configuration of the DOI can
involve no or little interaction with the end user.  More
specifically, it shows that the existence of an account in the DOI is
sufficient for the DOI to push the necessary configuration.  In
addition, when the DOI and CPE are both managed by an ISP, the
configuration can be entirely automated - see sec-reverse.
sec-reverse discusses management of one or more reverse zones.  It
shows that management of the reverse zones can be entirely automated
and benefit from a pre-established relation between the ISP and the
home network.  Note that such scenarios may also be met for the
Public Homenet Zone.
sec-renumbering discusses how renumbering should be handled.
Finally, sec-privacy and sec-security respectively discuss privacy
and security considerations when outsourcing the Public Homenet Zone.
The Public Homenet Zone is expected to contain public information
only in a single universal view.  This document does not define how
the information required to construct this view is derived.
It is also not in the scope of this document to define names for
exclusive use within the boundaries of the local home network.
Instead, local scope information is expected to be provided to the
home network using local scope naming services.  mDNS RFC6762 and
DNS-SD RFC6763 are two examples of these services.  Currently mDNS is
limited to a single link network.  However, future protocols and
architectures I-D.ietf-homenet-simple-naming are expected to leverage
this constraint as pointed out in RFC7558.
The document introduces the Synchronization Channel and the Control
Channel between the HNA and the Distribution Manager (DM) that
belongs to the DOI.
The Synchronization Channel (see sec-synch) is used to synchronize
the Public Homenet Zone.  The HNA is configured as a primary, while
the DM is configured as a secondary.
The Control Channel (see sec-ctrl) is used to set the Synchronization
Channel.  For example, to build the Public Homenet Zone, the HNA
needs the authoritative servers (and associated IP addresses) of the
servers of the DOI actually serving the zone.  Similarly, the DOI
needs to know the IP address of the primary (HNA) as well as
potentially the hash of the KSK (DS RRset) to secure the DNSSEC
delegation with the parent zone.
The remaining of the document is as follows.  sec-arc-desc provides
an architectural view of the HNA, DM and DOI as well as its different
communication channels (Control Channel, Synchronization Channel, DM
Distribution Channel) respectively described in sec-ctrl, sec-synch
and sec-dist.  sec-cpe-sec-policies and sec-dnssec-deployment
respectively details HNA security policies as well as DNSSEC
compliance within the home network.  sec-renumbering discusses how
renumbering should be handled.  Finally, sec-privacy and sec-security
respectively discuss privacy and security considerations when
outsourcing the Public Homenet Zone.
The appendices discuss several management (see sec-reverse)
provisioning (see sec-reverse), configurations (see info-model) and
deployment (see sec-deployment and sec-ex-manu) aspects.
The IPv6 ULA addresses are significantly safer to publish, as the
RFC1918 addresses are likely to be confusing to any other entity.
In general, one expects the GUA to be the default address to be
published.  However, during periods when the home network has
connectivity problems, the ULA and RFC1918 addresses can be used
inside the home, and the mapping from public name to locally useful
location address would permit many services secured with HTTPS to
continue to operate.
An alternative existing solution in IPv4 is to have a single zone,
where a host uses a RESTful HTTP service to register a single name
into a common public zone.  This is often called "Dynamic DNS"DDNS,
and there are a number of commercial providers.  These solutions were
typically used by a host behind the CPE to make its CPE IPv4 address
visible, usually in order to enable incoming connections.  This is
the most common scenario considered in this section, while some
variant may also consider the client being hosted in the CPE.
the CPE/HNA router is unaware of the process, and cannot respond
to queries for these names when there are disruptions in
connectivity.  This makes the home user or application dependent
on having to resolve different names in the event of outages or
disruptions.
The IPv6 ULA addresses are safer to publish with a significantly
lower probability of collision than RFC1918 addresses.
In general, one expects the GUA to be the default address to be
published.
However, publishing the ULA and RFC1918 may enable local
communications within the home network.  Since the communication has
been initiated with a name which remains a global identifier, the
communication can be protected by TLS the same way it is protected on
the global Internet.  A direct advantage of enabling local
communication is to prevent communications even in case of Internet
disruption.
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.  This is often called "Dynamic DNS" DDNS, and
there are a number of commercial providers.  While the IETF has
defined Dynamic Update RFC3007, in many - as far as the co-authors
know in all cases - case commercial "Dynamic Update" solutions are
implemented via a HTTPS RESTful API.
These solutions were typically used by a host behind the CPE and
since the CPE implements some NAT, the host can only be reached from
the global Internet via its CPE IPv4 address.  This is the most
common scenario considered in this section, while some variant may
also consider the client being hosted in the CPE.
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.
"all the good names are taken" - current services put everyone's
names into some small set of zones, and there are often conflicts.
Distinguishing similar names by delegation of zones was among the
primary design goals of the DNS system.
"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 provides by individual home
networks, there are often conflicts.  This makes the home user or
application dependent on having to resolve different names in the
event of outages or disruptions.  Distinguishing similar names by
delegation of zones was among the primary design goals of the DNS
system.
Dynamic Updates solution are not interoperable and each provider
has its own way to implement it.  RFC3007 is the standard solution
to update a DNS RRset, but most Dynamic Update providers use HTTPS
RESTful API.
contains the names in the home network that are expected to be
publicly resolvable on the Internet.
contains the names in the home network that are expected to be
publicly resolvable on the Internet.  A home network can have
multiple Public Homenet Zones.
fig-naming-arch illustrates the architecture where the HNA outsources
the publication of the Public Homenet Zone to the DOI.
fig-naming-arch illustrates the architecture where the HNA outsources
the publication of the Public Homenet Zone to the DOI.  The DOI will
serve every DNSSEC request of the Public Homenet Zone coming from
outside the home network.  When the request is coming within the
network, the resolution is expected to be handled by the Homenet
Resolver as detaille din further details below.
a DM Control Channel (sec-ctrl) to configure the HNA and the DOI,
a DM Synchronization Channel (sec-synch) to synchronize the Public
Homenet Zone on the HNA and on the DM,
DM Control Channel (sec-ctrl) to configure the HNA and the DOI.
This includes necessary parameters to configure the primary/
secondary relation as well as some information provided by the DOI
that needs to be included by the HNA in the Public Homenet Zone.
DM Synchronization Channel (sec-synch) to synchronize the Public
Homenet Zone on the HNA and on the DM with the appropriately
configured primary/secondary.
The Control Channel is used to set up the Synchronization Channel.
We assume that the HNA initiates the Control Channel connection with
the DM and as such has a prior knowledge of the DM identity (X509
certificate), the IP address and port number to use and protocol to
set secure session.  We also assume the DM has knowledge of the
identity of the HNA (X509 certificate) as well as the Registered
Homenet Domain.  For more detail to see how this can be achieved,
please see hna-provisioning.
The information exchanged between the HNA and the DM uses DNS
messages protected by DNS over TLS (DoT) RFC7858.  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 I-D.ietf-dprive-dnsoquic.  There
was consideration to using a standard TSIG RFC2845 or SIG(0) RFC2931
to perform a dynamic DNS update to the DM.  There are a number of
issues with this.  The first one is that TSIG or SIG(0) make
scenarios where the end user needs to interact via its web browser
more complex.  More precisely, authorization and access control
granted via OAUTH would be unnecessarily complex with TSIG or SIG(0).
The information exchanged between the HNA and the DM uses DNS
messages protected by DNS over TLS (DoT) RFC7858.  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 I-D.ietf-dprive-dnsoquic.
The DM Control Channel is used by the HNA and the DOI to exchange
information related to the configuration of the delegation which
includes information to build the Public Homenet Zone (sec-pbl-
homenet-zone), information to build the DNSSEC chain of trust (sec-
chain-of-trust) and information to set the Synchronization Channel
(sec-sync-info).
When the HNA builds the Public Homenet Zone, it must include
information that it retrieves from the DM relating to how the zone is
to be published.
The DM Control Channel is used by the HNA and the DOI to exchange
information related to the configuration of the delegation which
includes information to build the Public Homenet Zone (sec-pbl-
homenet-zone), information to build the DNSSEC chain of trust (sec-
chain-of-trust) and information to set the Synchronization Channel
(sec-sync-info).  While information is carried from the DOI to the
HNA and from the HNA to the DOI, the HNA is always initiating the
exchange in both directions.
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.  The DM acquires knowledge of the identity of the
HNA (X509 certificate) as well as the Registered Homenet Domain.  For
more detail to see how this can be achieved, please see hna-
provisioning.
The HNA builds the Public Homenet Zone based on information retrieved
from the DM.
The DOI MAY also provide operational parameters such as other fields
of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM).  As the
information is necessary for the HNA to proceed and the information
is associated to the DOI, this information exchange is mandatory.
The DM MAY also provide operational parameters such as other fields
of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM).  As the
information is necessary for the HNA to proceed and the information
is associated to the DM, this information exchange is mandatory.
There are multiple ways this information could be exchanged between
the HNA and the DM.  This specification defines a mechanism that re-
use the DNS exchanges format.  The intention is to reuse standard
libraries especially to check the format of the exchanged fields as
well as to minimize the additional libraries needed for the HNA.  The
re-use of DNS exchanges achieves these goals.  Note that while
information is provided using DNS exchanges, the exchanged
information is not expected to be set in any zone file, instead this
information is uses as commands between the HNA and the DM.
The decision to delete an inactive HNA by the DM is part of the
commercial agreement between DOI and HNA.
There are multiple ways this information could be exchanged between
the HNA and the DM.  This specification defines a mechanism that re-
use the DNS exchanges format, while the exchange in itself is not a
DNS exchange involved in any any DNS operations such as DNS
resolution.  Note that while information is provided using DNS
exchanges, the exchanged information is not expected to be set in any
zone file, instead this information is used as commands between the
HNA and the DM.
As a result, even though the same couple of IP addresses may be
involved the Control Channel and the Synchronization Channel are
always distinct channels.
As a result, even though the same pair of IP addresses may be
involved the Control Channel and the Synchronization Channel are
always distinct channels.
The AXFR request from the DM to the HNA SHOULD be secured and the use
of TLS is RECOMMENDED RFC9103.  While RFC9103 does not consider the
protection by TLS of NOTIFY and SOA requests, these MAY still be
protected by TLS to provide additional privacy.
This section details security policies related to the Hidden Primary
/ Secondary synchronization.
The HNA as hidden primary processes only a limited message exchanges.
This should be enforced using security policies - to allow only a
subset of dns requests to be received by HNA.
At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
NOTIFY query,   SOA response, IXFR response or AXFR responses.  The
HNA SHOULD reject any incoming messages other than DNS NOTIFY
response, SOA   query, IXFR query or AXFR query.
The HNA SHOULD NOT send DNS messages other than DNS NOTIFY
query,   SOA response, IXFR response or AXFR responses.  The
HNA SHOULD reject any incoming messages other than DNS NOTIFY
response, SOA   query, IXFR query or AXFR query.
This document assumes the HNA signs the Public Homenet Zone.
Secure delegation is achieved only if the DS RRset is properly set in
the parent zone.  Secure delegation is performed by the HNA or the
DOIs.
The DS RRset can be updated manually with nsupdate for example.  This
requires the HNA or the DOI to be authenticated by the DNS server
hosting the parent of the Public Homenet Zone.  Such a trust channel
between the HNA and the parent DNS server may be hard to maintain
with HNAs, and thus may be easier to establish with the DOI.  In
fact, the Public Authoritative Server(s) may use Automating DNSSEC
Delegation Trust Maintenance RFC7344.
The Public Homenet Zone is associated to a Registered Homenet Domain
and the ownership of that domain requires a specific registration
from the end user as well as the HNA being provisioned with some
authentication credentials.  Such steps are mandatory unless the DOI
has some other means to authenticate the HNA.  Such situation may
occur, for example, when the ISP provides the Homenet Domain as well
as the DOI.
In this case, the HNA may be authenticated by the physical link
layer, in which case the authentication of the HNA may be performed
without additional provisioning of the HNA.  While this may not be so
common for the Public Homenet Zone, this situation is expected to be
quite common for the Reverse Homenet Zone.
More specifically, a common case is that the upstream ISP provides
the IPv6 prefix to the Homenet with a IA_PD RFC8415 option and
manages the DOI of the associated reverse zone.
This leaves place for setting up automatically the relation between
HNA and the DNS Outsourcing infrastructure as described in I-D.ietf-
homenet-naming-architecture-dhc-options.
In the case of the reverse zone, the DOI authenticates the source of
the updates by IPv6 Access Control Lists.  In the case of the reverse
zone, the ISP knows exactly what addresses have been delegated.  The
HNA SHOULD therefore always originate Synchronization Channel updates
from an IP address within the zone that is being updated.
For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN
interface (by DHCPv6, or PPP/RA), then the HNA should originate
Synchronization Channel updates from, for example, 2001:db8:f00d::2.
An ISP that has delegated 2001:db8:aeae::/56 to the HNA via
DHCPv6-PD, then HNA should originate Synchronization Channel updates
an IP within that subnet, such as 2001:db8:aeae:0001::2.
With this relation automatically configured, the synchronization
between the Home network and the DOI happens similarly as for the
Public Homenet Zone described earlier in this document.
Note that for home networks connected to by multiple ISPs, each ISP
provides only the DOI of the reverse zones associated to the
delegated prefix.  It is also likely that the DNS exchanges will need
to be performed on dedicated interfaces as to be accepted by the ISP.
More specifically, the reverse zone associated to prefix 1 will not
be possible to be performs by the HNA using an IP address that
belongs to prefix 2.  Such constraints does not raise major concerns
either for hot standby or load sharing configuration.
With IPv6, the domain space for IP addresses is so large that reverse
zone may be confronted with scalability issues.  How the reverse zone
is generated is out of scope of this document.  RFC8501 provides
guidance on how to address scalability issues.
This document does not deal with how the HNA is provisioned with a
trusted relationship to the Distribution Manager for the forward
zone.
This section details what needs to be provisioned into the HNA and
serves as a requirements statement for mechanisms.
the HNA credentials used by the DM for its authentication.
The HNA will need to select an IP address for communication for the
Synchronization Channel.  This is typically the WAN address of the RG
router, but could be an IPv6 LAN address in the case of a home with
multiple ISPs (and multiple border routers).  This is detailed in
sec-ip-hna when the NS and A or AAAA RRsets are communicated.
The above parameters MUST be be provisioned for ISP-specific reverse
zones, as per I-D.ietf-homenet-naming-architecture-dhc-options.  ISP-
specific forward zones MAY also be provisioned using I-D.ietf-
homenet-naming-architecture-dhc-options, but zones which are not
related to a specific ISP zone (such as with a DNS provider) must be
provisioned through other means.
Similarly, if the HNA is provided by a registrar, the HNA may be
handed pre-configured to end user.
In the absence of specific pre-established relation, these pieces of
information may be entered manually by the end user.  In order to
ease the configuration from the end user the following scheme may be
implemented.
The HNA may present the end user a web interface where it provides
the end user the ability to indicate the Registered Homenet Domain or
the registrar for example a preselected list.  Once the registrar has
been selected, the HNA redirects the end user to that registrar in
order to receive a access token.  The access token will enable the
HNA to retrieve the DM parameters associated to the Registered
Domain.  These parameters will include the credentials used by the
HNA to establish the Control and Synchronization Channels.
Such architecture limits the necessary steps to configure the HNA
from the end user.
This section details how renumbering is handled by the Hidden Primary
server or the DM.  Both types of renumbering are discussed i.e.
"make-before-break" and "break-before-make" (aka flash renumbering).
In the make-before-break renumbering scenario, the new prefix is
advertised, the network is configured to prepare the transition to
the new prefix.  During a period of time, the two prefixes old and
new coexist, before the old prefix is completely removed.
In the break-before-make renumbering scenario, the new prefix is
advertised making the old prefix obsolete.
Renumbering has been extensively described in RFC4192 and analyzed in
RFC7010 and the reader is expected to be familiar with them before
reading this section.
In a renumbering scenario, the HNA or Hidden Primary is informed it
is being renumbered.  In most cases, this occurs because the whole
home network is being renumbered.  As a result, the Public Homenet
Zone will also be updated.  Although the new and old IP addresses may
be stored in the Public Homenet Zone, we recommend that only the
newly reachable IP addresses be published.
It is RECOMMENDED the HNA signs the Public Homenet Zone.
Secure delegation is achieved only if the DS RRset is properly set in
the parent zone.  Secure delegation can be performed by the HNA or
the DOIs and the choice highly depends on which entity is authorized
to perform such updates.  Typically, the DS RRset can be updated
manually in the parent zone with nsupdate for example.  This requires
the HNA or the DOI to be authenticated by the DNS server hosting the
parent of the Public Homenet Zone.  Such a trust channel between the
HNA and the parent DNS server may be hard to maintain with HNAs, and
thus may be easier to establish with the DOI.  In fact, the Public
Authoritative Server(s) may use Automating DNSSEC Delegation Trust
Maintenance RFC7344.
During a renumbering of the network, the HNA IP address is changed
and the Public Homenet Zone is updated potentially by by the HNA.
Then, the HNA advertises the DM via a NOTIFY, that the Public Homenet
Zone has been updated and that the IP address of the primary has been
updated.  This corresponds to the standard DNS procedure performed on
the Synchronization Channel and no specific actions are expected for
the HNA (See sec-sync-info).
The remaining of the section provides recommendations regarding the
provisioning of the Public Homenet Zone - especially the IP
addresses.  Renumbering has been extensively described in RFC4192 and
analyzed in RFC7010 and the reader is expected to be familiar with
them before reading this section.  In the make-before-break
renumbering scenario, the new prefix is advertised, the network is
configured to prepare the transition to the new prefix.  During a
period of time, the two prefixes old and new coexist, before the old
prefix is completely removed.  In the break-before-make renumbering
scenario, the new prefix is advertised making the old prefix
obsolete.
In a renumbering scenario, the HNA or Hidden Primary is informed it
is being renumbered.  In most cases, this occurs because the whole
home network is being renumbered.  As a result, the Public Homenet
Zone will also be updated.  Although the new and old IP addresses may
be stored in the Public Homenet Zone, it is RECOMMENDED that only the
newly reachable IP addresses be published.
Once the Public Homenet Zone file has been updated on the Hidden
Primary, the Hidden Primary needs to inform the DOI that the Public
Homenet Zone has been updated and that the IP address to use to
retrieve the updated zone has also been updated.  Both notifications
are performed using regular DNS exchanges.  Mechanisms to update an
IP address provided by lower layers with protocols like SCTP RFC4960,
MOBIKE RFC4555 are not considered in this document.  Instead the IP
address of the HNA is updated using the Synchronization Channel as
described in sec-sync-info.
The zone is also exposed during the synchronization between the
primary and the secondary.  RFC9103 only specifies the use of TLS for
XFR transfers, which leak the existence of the zone and has been
clearly specified as out of scope of the threat model of RFC9103.
Additional privacy MAY be provide by protecting all exchanges of the
Synchronization Channel as well as the Control Channel.
At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or
newer) SHOULD be supported.
At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or
newer) SHOULD be supported.  It is RECOMMENDED that all DNS exchanges
between the HNA and the DM be protected by TLS to provide integrity
protection as well as confidentiality.  As noted in RFC9103, some
level of privacy may be relaxed, by not protecting the existence of
the zone.  This MAY involved a mix of exchanges protected by TLS and
exchanges not protected by TLS.  This MAY Be handle by a off-line
agreement between the DM and HNA as well as with the use of RCODES
defined in Section 7.8 of RFC9103.
This section is non-normative for the front-end protocol.  It
specifies an optional format for the set of parameters required by
the HNA to configure the naming architecture of this document.
In cases where a home router has not been provisioned by the
manufacturer (when forward zones are provided by the manufacturer),
or by the ISP (when the ISP provides this service), then a home user/
owner will need to configure these settings via an administrative
interface.
By defining a standard format (in JSON) for this configuration
information, the user/owner may be able to just copy and paste a
configuration blob from the service provider into the administrative
interface of the HNA.
This format may also provide the basis for a future OAUTH2 RFC6749
flow that could do the setup automatically.
The HNA needs to be configured with the following parameters as
described by this CDDL RFC8610.  These are the parameters are
necessary to establish a secure channel between the HNA and the DM as
well as to specify the DNS zone that is in the scope of the
communication.
The Domain Name of the zone.  Multiple Registered Homenet Domains
may be provided.  This will generate the creation of multiple
Public Homenet Zones.  This parameter is MANDATORY.
The associated FQDNs or IP addresses of the DM to which DNS
notifies should be sent.  This parameter is MANDATORY.  IP
addresses are optional and the FQDN is sufficient and preferred.
If there are concerns about the security of the name to IP
translation, then DNSSEC should be employed.
As the session between the HNA and the DM is authenticated with TLS,
the use of names is easier.
As certificates are more commonly emitted for FQDN than for IP
addresses, it is preferred to use names and authenticate the name of
the DM during the TLS session establishment.
The transport that carries the DNS exchanges between the HNA and
the DM.  Typical value is "DoT" but it may be extended in the
future with "DoH", "DoQ" for example.  This parameter is OPTIONAL
and by default the HNA uses DoT.
Indicates the port used by the DM.  This parameter is OPTIONAL and
the default value is provided by the Supported Transport.  In the
future, additional transport may not have default port, in which
case either a default port needs to be defined or this parameter
become MANDATORY.
Note that HNA does not defines ports for the Synchronization Channel.
In any case, this is not expected to part of the configuration, but
instead negotiated through the Configuration Channel.  Currently the
Configuration Channel does not provide this, and limits its agility
to a dedicated IP address.  If such agility is needed in the future,
additional exchanges will need to be defined.
How the HNA authenticates itself to the DM within the TLS
connection(s).  The authentication meth of can typically be
"certificate", "psk" or "none".  This Parameter is OPTIONAL and by
default the Authentication Method is "certificate".
Authentication data ("hna_certificate", "hna_key"): : The certificate
chain used to authenticate the HNA.  This parameter is OPTIONAL and
when not specified, a self-signed certificate is used.
The subnet from which the CPE should accept SOA queries and AXFR
requests.  A subnet is used in the case where the DOI consists of
a number of different systems.  An array of addresses is
permitted.  This parameter is OPTIONAL and if unspecified, the CPE
uses the IP addresses provided by the dm parameter either directly
when dm indicates an IP address or the IP addresses returned by
the DNS(SEC) resolution when dm indicates a FQDN.
The forward zone outsourcing may be provided by the maker of the
Homenet router.  In this case, the identity and authorization
could be built in the device at manufacturer provisioning time.
The device would need to be provisioned with a device-unique
credential, and it is likely that the Registered Homenet Domain
would be derived from a public attribute of the device, such as a
serial number (see sec-ex-manu or I-D.richardson-homerouter-
provisioning for more details ).
The forward zone outsourcing may be provided by the Internet
Service Provider.  In this case, the use of I-D.ietf-homenet-
naming-architecture-dhc-options to provide the credentials is
appropriate.
The forward zone may be outsourced to a third party, such as a
domain registrar.  In this case, the use of the JSON-serialized
YANG data model described in this section is appropriate, as it
can easily be copy and pasted by the user, or downloaded as part
of a web transaction.
For reverse zones, the relationship is always with the upstream ISP
(although there may be more than one), and so I-D.ietf-homenet-
naming-architecture-dhc-options is always the appropriate interface.
The following is an abbridged example of a set of data that
represents the needed configuration parameters for outsourcing.