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

Commentary: This PR attempts to describe / clarify the parameters of the YANG model . The current changes have been performed on the appendix section , but the appendix section may need to be merge in the main document .
Home owners often have IPv6 devices that they wish to access over the
Internet using names.  It has been possible to register and populate
a DNS Zone with names since DNS became a thing, but it has been an
activity typically reserved for experts.  This document automates the
process through creation of a Homenet Naming Authority, whose
responsibility is to select, sign and publish names to a set of
publically visible servers.
This document describes the mechanism that enables the Home Network
Authority (HNA) to outsource the naming service to the DNS
Outsourcing Infrastructure via a Distribution Master (DM).
Home owners often have IPv6 devices that they wish to access over the
Internet using names.  It has been possible to register and populate
a DNS Zone with names since DNS became a thing, but it has been an
activity typically reserved for experts.  This document automates the
process through creation of a Homenet Naming Authority (HNA), whose
responsibility is to select, sign and publish names to a set of
publicly visible servers.
This document describes the mechanism that enables the HNA to
outsource the naming service to the DNS Outsourcing Infrastructure
(DOI) via a Distribution Master (DM).
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 Homenet Naming Authority (HNA) function.
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.
In order to avoid resource exhaustion and other attacks, this
document describes 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 an DNS
Outsourcing Infrastructure (DOI) via a Distribution Master (DM).  The
DNS Outsourcing Infrastructure (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 hosted
primary being a stealth primary, and the Distribution Master a
secondary.
sec-arch-overview provides an architecture description that describes
the relation between the HNA and the Outsourcing Architecture.  In
order to keep the Public Homenet Zone up-to-date sec-synch describes
how the HNA and the DNS Outsourcing Infrastructure synchronizes the
Pubic Homenet Zone.
In order to avoid resource exhaustion and other attacks, this
document describes 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 an DNS
Outsourcing Infrastructure (DOI) via a Distribution Master (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 hosted primary being a stealth primary, and the
DM a secondary.
sec-arch-overview provides an architecture description that describes
the relation between the HNA and the DOI.  In order to keep the
Public Homenet Zone up-to-date sec-synch describes how the HNA and
the DOI synchronizes the Pubic Homenet Zone.
hna-provisioning discusses management and configuration of the Public
Homenet Zone.  It shows that the HNA configuration of the Outsourcing
infrastructure 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.
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.
A device may have a Global Unicast Address (GUA), a Unique Local IPv6
Address (ULA), as as well IPv6-Link-Local addresses, IPv4-Link-Local
Addresses, and RFC1918 addresses.  Of these the link-local are never
useful for the Public Zone, and should be ommitted.  The IPv6 ULA and
the RFC1918 addresses may be useful to publish, if the home network
environment features a VPN that would allow the home owner to reach
the network.
A device may have a Global Unicast Address (GUA), a Unique Local IPv6
Address (ULA), as as well IPv6-Link-Local addresses, IPv4-Link-Local
Addresses, and RFC1918 addresses.  Of these the link-local are never
useful for the Public Zone, and should be omitted.  The IPv6 ULA and
the RFC1918 addresses may be useful to publish, if the home network
environment features a VPN that would allow the home owner to reach
the network.
This section provides an overview of the architecture for outsourcing
the authoritative naming service fromn the HNA to the DNS Outsourcing
Infrastructure in sec-arch-overview.  Section sec-homenet-zone and
sec-configuration-parameters illustrates this architecture with the
example of a Public Homenet Zone as well as necessary parameter to
configure the HNA.
fig-naming-arch illustrates the architecture where the HNA outsources
the publication of the Public Homenet Zone to the DNS Outsourcing
Infrastructure (DOI).
This section provides an overview of the architecture for outsourcing
the authoritative naming service from the HNA to the DOI in sec-arch-
overview.  sec:yang-model defines necessary parameter to configure
the HNA.
fig-naming-arch illustrates the architecture where the HNA outsources
the publication of the Public Homenet Zone to the DOI.
Once the Public Homenet Zone has been built, the HNA outsources it to
the DNS Outsourcing Infrastructure as described in fig-naming-arch.
The HNA acts as a hidden primary while the DM behaves as a secondary
responsible to distribute the Public Homenet Zone to the multiple
Public Authoritative Servers that DNS Outsourcing Infrastructure is
responsible for.
a DM Control Channel (see section sec-ctrl) to configure the HNA
and the Outsourcing Infrastructure,
Once the Public Homenet Zone has been built, the HNA outsources it to
the DOI as described in fig-naming-arch.
The HNA acts as a hidden primary while the DM behaves as a secondary
responsible to distribute the Public Homenet Zone to the multiple
Public Authoritative Servers that DOI is responsible for.
a DM Control Channel (see section sec-ctrl) to configure the HNA
and the DOI,
There MAY be multiple DM's, and multiple servers per DM.  This text
assumes a single DM server for simplicity, but there is no reason why
each channel need to be implemented on the same server, or indeed use
the same code base.
It is important to note that while the HNA is configured as an
authoritative server, it is not expected to answer to DNS requests
from the public Internet for the Public Homenet Zone.  The function
of the HNA is limited to building the zone and synchronization with
the DM.
The addresses associated with the HNA SHOULD NOT be mentioned in the
NS records of the Public Homenet zone, unless additional security
provisions necessary to protect the HNA from external attack have
been taken.
The DNS Outsourcing Infrastructure is also responsible for ensuring
the DS record has been updated in the parent zone.
There MAY be multiple DM's, and multiple servers per DM.  This text
assumes a single DM server for simplicity, but there is no reason why
each channel needs to be implemented on the same server, or indeed
use the same code base.
It is important to note that while the HNA is configured as an
authoritative server, it is not expected to answer to DNS requests
from the public Internet for the Public Homenet Zone.  More
specifically, the addresses associated with the HNA SHOULD NOT be
mentioned in the NS records of the Public Homenet zone, unless
additional security provisions necessary to protect the HNA from
external attack have been taken.
The DOI is also responsible for ensuring the DS record has been
updated in the parent zone.
When the resolution is performed from within the home network, the
Homenet DNSSEC Resolver may proceed similarly.  On the other hand, to
provide resilience to the Public Homenet Zone in case of disruption,
the Homenet DNSSEC Resolver SHOULD be able to perform the resolution
on the authoritative name service of the home network implemented by
the Homenet Authoritative Servers.  These servers are not expected to
be mentioned in the Public Homenet Zone, nor to be accessible from
the Internet.  As such their information as well as the corresponding
signed DS record MAY be provided by the HNA to the Homenet DNSSEC
Resolvers, e.g., using HNCP.  Such configuration is outside the scope
of this document.
When the resolution is performed from within the home network, the
Homenet DNSSEC Resolver may proceed similarly.  On the other hand, to
provide resilience to the Public Homenet Zone in case of disruption,
the Homenet DNSSEC Resolver SHOULD be able to perform the resolution
on the Homenet Authoritative Servers.  These servers are not expected
to be mentioned in the Public Homenet Zone, nor to be accessible from
the Internet.  As such their information as well as the corresponding
signed DS record MAY be provided by the HNA to the Homenet DNSSEC
Resolvers, e.g., using HNCP RFC7788.  Such configuration is outside
the scope of this document.
The Control Channel and the Synchronization Channel are the
interfaces used between the HNA and the DNS Outsourcing
Infrastructure.  The entity within the DNS Outsourcing Infrastructure
responsible to handle these communications is the DM and
communications between the HNA and the DM SHOULD be protected and
mutually authenticated.  While section sec-ctrl-security discusses in
more depth the different security protocols that could be used to
secure, this specification RECOMMENDS the use of TLS with mutually
authentication based on certificates to secure the channel between
the HNA and the DM.
The Control Channel and the Synchronization Channel are the
interfaces used between the HNA and the DOI.  The entity within the
DOI responsible to handle these communications is the DM and
communications between the HNA and the DM SHOULD be protected and
mutually authenticated.  While section sec-ctrl-security discusses in
more depth the different security protocols that could be used to
secure, this specification RECOMMENDS the use of TLS with mutually
authentication based on certificates to secure the channel between
the HNA and the DM.
The information exchanged between the HNA and the DM is using DNS
messages.  DNS messages can be protected using various kind of
transport layers, among others, UDP:53/DTLS, TLS/TCP:53, HTTPS:443.
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 main one 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 Distribution Master's configuration files.  The
visible NS records SHOULD remain pointing at the cloud provider's
anycast addresses.  Revealing the address of the HNA in the DNS is
not desirable.  Please see section sec-chain-of-trust for more
details.
the HNA uses a single IP address for both the Control and
Synchronization channel by default.  However, the HNA MAY use
distinct IP addresses - see section sec-synch and section {sec-
sync-info}} for more details.
The Distribution Channel is internal to the DNS Outsourcing
Infrastructure and as such is not the primary concern of this
specification.
When the HNA builds the public zone, it must include information that
it retrieves from the DM relating to how the zone is to be published.
The information exchanged between the HNA and the DM is using DNS
messages.  DNS messages can be protected using various kind of
transport layers, among others, DNS over DTLS RFC8094, DNS over TLS
(DoT) RFC7858, or DNS over HTTPs (DoH) RFC8484.  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 main one 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 anycast addresses.
Revealing the address of the HNA in the DNS is not desirable.  Please
see section sec-chain-of-trust for more details.
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 sec-synch and section {sec-sync-info}} for more
details.
The Distribution Channel is internal to the DOI and as such is not
the primary concern of this specification.
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 (see sec-pbl-
homenet-zone), information to build the DNSSEC chain of trust (see
sec-chain-of-trust) and information to set the Synchronization
Channel (see 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.
Optionally the DNS Outsourcing Infrastructure 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
Outsourcing Infrastructure, this information exchange is mandatory.
The HNA SHOULD provide the hash of the KSK (DS RRset), so the that
DNS Outsourcing Infrastructure provides this value to the parent
zone.  A common deployment use case is that the Outsourcing
Infrastructure 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.  When such relation exists, the
HNA should be able to request the DNS Outsourcing Infrastructure to
update the DS RRset in the parent zone.  A direct update is
especially necessary to initialize the chain of trust.
As some deployment may not provide an DNS Outsourcing Infrastructure
that will be able to update the DS in the parent zone, this
information exchange is OPTIONAL.
Optionally 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 HNA SHOULD provide the hash of the KSK (DS RRset), so the that
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.  When such relation
exists, the HNA should be able to request the DOI to update the DS
RRset in the parent zone.  A direct update is especially necessary to
initialize the chain of trust.
As some deployment may not provide a DOI that will be able to update
the DS in the parent zone, this information exchange is OPTIONAL.
That information sets the primary/secondary relation between the HNA
and the DM.  The HNA works as a primary authoritative DNS server, and
MUST provide the corresponding IP address.
The specified IP address on the HNA side and the currently used IP
address of the DM defines the IP addresses involved in the
Synchronization Channel.  Ports and transport protocol are the same
as those used by the Control Channel.  By default, the same IP
address used by the HNA is considered by the DM.  Exchange of this
information is OPTIONAL.
The HNA works as a primary authoritative DNS server, while the DM
works like a secondary.  As a result, the HNA MUST provide the IP
address the DM is using to reach the HNA.
The synchronization Channel will be set between that IP address and
the IP address of the DM.  By default, the IP address used by the HNA
in the Control Channel is considered by the DM and teh specification
of the IP by the HNA is only OPTIONAL.  The transport channel
(including port) is the same as the one used between the HNA and the
DM for the Control Channel.
The information provided by the DM to the HNA is retrieved by the HNA
with an AXFR exchange.  The AXFR message enables the response to
contain any type of RRsets.  The response might be extended in the
future if additional information will be needed.  Alternatively, the
information provided by the HNA to the DM is pushed by the HNA via a
DNS update exchange.
The information provided by the DM to the HNA is retrieved by the HNA
with an AXFR exchange.  The AXFR message enables the response to
contain any type of RRsets.  The response might be extended in the
future if additional information will be needed.  Alternatively, the
information provided by the HNA to the DM is pushed by the HNA via a
DNS update exchange RFC2136.
The MNAME value of the SOA RDATA is the value provided by the DNS
Outsourcing Infrastructure to the HNA.
Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are
provided by the DNS Outsourcing Infrastructure as suggestions.
The NS RRsets are used to carry the Public Authoritative Servers of
the DNS Outsourcing Infrastructure.  Their associated NAME MUST be
the Registered Homenet Domain.
The MNAME value of the SOA RDATA is the value provided by the DOI
to the HNA.
Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are
provided by the DOI as suggestions.
The NS RRsets are used to carry the Public Authoritative Servers of
the DOI.  Their associated NAME MUST be the Registered Homenet
Domain.
The NAME in the SOA MUST be set to the parent zone of the
Registered Homenet Domain - that is where the DS records should be
inserted.
The DS RRset MUST be placed in the Update section of the UPDATE
query, and the NAME SHOULD be set to the Registered Homenet
Domain.
The RDATA of the DS RR SHOULD correspond to the DS record to be
inserted in the parent zone.
A NOERROR response from the MD is a commitment to update the
parent zone with the provided DS.
An error indicates the MD will not update the DS, and other method
should be used by the HNA.
To provide the IP address of the primary, the HNA MAY send a DNS
UPDATE message.
The RDATA MUST be a RRset of type A or AAAA that designates the IP
addresses associated to the primary.
There may be multiple IP addresses.
These IP addresses MUST be provided in the additional section.
A NOERROR response indicates the DM has configured the secondary
and is committed to serve as a secondary.
An error indicates the DM is not configured as a secondary.
The regular DNS error message SHOULD be returned to the HNA when an
error occurs.  In particular a FORMERR is returned when a format
error is found, this includes when unexpected RRSets are added or
when RRsets are missing.
A SERVFAIL error is returned when a internal error is encountered.
A NOTZONE error is returned when update and Zone sections are not
coherent, a NOTAUTH error is returned when the DM is not
authoritative for the Zone section.
A REFUSED error is returned when the DM refuses to proceed to the
configuration and the requested action.
To instruct to delete the delegation the HNA MAY send a DNS UPDATE
Delete message.
The NAME associated to the NS RRSet MUST be the Registered Domain
Name.
As indicated by RFC2136 section 2.5.2 the delete instruction is set
by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0 and the
RDATA MUST be empty.
Secure protocols (like TLS RFC8446 / DTLS I-D.ietf-tls-dtls13) SHOULD
be used to secure the transactions between the DM and the HNA.
The advantage of TLS/DTLS is that this technology is widely deployed,
and most of the devices already embed TLS/DTLS libraries, possibly
also taking advantage of hardware acceleration.  Further, TLS/DTLS
provides authentication facilities and can use certificates to
mutually authenticate the DM and HNA at the application layer,
including available API.  On the other hand, using TLS/DTLS requires
implementing DNS exchanges over TLS/DTLS, as well as a new service
port.
The HNA SHOULD authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE {!RFC6698}}.  The HNA is
expected to be provisioned with a connection to the DM by the
manufacturer, or during some user-initiated onboarding process, see
hna-provisioning.
The DNS update message is composed of a Header section, a Zone
section, a Pre-requisite section, and Update section and an
additional section.  The Zone section MUST set the ZNAME to the
parent zone of the Registered Homenet Domain - that is where the DS
records should be inserted.  As described RFC2136, ZTYPE is set to
SOA and ZCLASS is set to the zone's class.  The Pre-requisite section
MUST be empty.  The Update section is a DS RRset with its NAME set to
the Registered Homenet Domain and the associated RDATA corresponds to
the value of the DS.  The Additional Data section MUST be empty.
Though the pre-requisite section MAY be ignored by the DM, this value
is fixed to remain coherent with a standard DNS update.
Upon receiving the DNS update request, the DM reads the DS RRset in
the Update section.  The DM checks ZNAME corresponds to the parent
zone.  The DM SHOULD ignore non empty the Pre-requisite and
Additional Data section.  The DM MAY update the TTL value before
updating the DS RRset in the parent zone.  Upon a successful update,
the DM should return a NOERROR response as a commitment to update the
parent zone with the provided DS.  An error indicates the MD does not
update the DS, and other method should be used by the HNA.
The regular DNS error message SHOULD be returned to the HNA when an
error occurs.  In particular a FORMERR is returned when a format
error is found, this includes when unexpected RRSets are added or
when RRsets are missing.  A SERVFAIL error is returned when a
internal error is encountered.  A NOTZONE error is returned when
update and Zone sections are not coherent, a NOTAUTH error is
returned when the DM is not authoritative for the Zone section.  A
REFUSED error is returned when the DM refuses to proceed to the
configuration and the requested action.
To provide a non default IP address used by the HNA for the
Synchronization Channel, the HNA MAY send a DNS Update message.  Such
exchange is OPTIONAL.
Similarly to the sec-ds, the HNA MAY optionally specify the IP
address using a DNS update message.
The Zone section sets its ZNAME to the parent zone of the Registered
Homenet Domain, ZTYPE is set to SOA and ZCLASS is set to the zone's
type.
Pre-requisite is empty.  The Update section is a RRset of type NS.
The Additional Data section contains the RRsets of type A or AAAA
that designates the IP addresses associated to the primary (or the
HNA).
Upon receiving the DNS update request, the DM reads the IP addresses
and checks the ZNAME corresponds to the parent zone.  The DM SHOULD
ignore a non empty Pre-requisite section.  The DM configures the
secondary with the IP addresses and returns a NOERROR response to
indicate it is committed to serve as a secondary.
Similarly to sec-ds, DNS errors are used and an error indicates the
DM is not configured as a secondary.
To instruct to delete the delegation the HNA SHOULD send a DNS UPDATE
Delete message.
The Zone section sets its ZNAME to the Registered Homenet Domain, the
ZTYPE to SOA and the ZCLASS to zone's type.  The Pre-requisite
section is empty.  The Update section is a RRset of type NS with the
NAME set to the Registered Domain Name.  As indicated by RFC2136
section 2.5.2 the delete instruction is set by setting the TTL to 0,
the Class to ANY, the RDLENGTH to 0 and the RDATA MUST be empty.  The
Additional Data section is empty.
Upon receiving the DNS update request, the DM checks the request and
removes the delegation.  The DM returns a NOERROR response to
indicate the delegation has been deleted.
Similarly to sec-ds, DNS errors are used and an error indicates the
delegation has not been deleted.
Secure protocols (like TLS RFC8446 SHOULD be used to secure the
transactions between the DM and the HNA.
The advantage of TLS is that this technology is widely deployed, and
most of the devices already embed TLS libraries, possibly also taking
advantage of hardware acceleration.  Further, TLS provides
authentication facilities and can use certificates to mutually
authenticate the DM and HNA at the application layer, including
available API.  On the other hand, using TLS requires implementing
DNS exchanges over TLS, as well as a new service port.
The HNA SHOULD authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE RFC6698.  The HNA is expected to
be provisioned with a connection to the DM by the manufacturer, or
during some user-initiated onboarding process, see hna-provisioning.
the Hidden Primary Server will almost certainly listen on the WAN
Interface, whereas a regular authoritative server for the home
network would listen on the internal home network interface.
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.
On the other hand, regular authoritative servers would respond to any
hosts, and any DNS query would be processed.  The HNA SHOULD filter
IXFR/AXFR traffic and drop traffic not initiated by the DM.  The HNA
MUST listen for DNS on TCP and UDP and MUST at least allow SOA
lookups of the Homenet Zone.
On the other hand, regular authoritative servers would respond to any
hosts, and any DNS query would be processed.  The HNA SHOULD filter
IXFR/AXFR traffic and drop traffic not initiated by the DM.  The HNA
MUST MUST at least allow SOA lookups of the Homenet Zone.
The DM Synchronization Channel is used for communication between the
HNA and the DM for synchronizing the Public Homenet Zone.  Note that
the Control Channel and the Synchronization Channel are by
construction different channels even though there they MAY use the
same IP addresses.  In fact the Control Channel is set between the
HNA working as a client using port YYYY (a high range port) toward a
service provided by the MD at port XX (well known port).
The DM Synchronization Channel is used for communication between the
HNA and the DM for synchronizing the Public Homenet Zone.  Note that
the Control Channel and the Synchronization Channel are by
construction different channels even though there they MAY use the
same IP addresse.  In fact the Control Channel is set between the HNA
working as a client using port YYYY (a high range port) toward a
service provided by the DM at port XX (well known port).
The DM is configured as a secondary for the Homenet Domain Name.
This secondary configuration has been previously agreed between the
end user and the provider of the Outsourcing Infrastructure as part
of either the provisioning or due to receipt of UPDATE messages on
the DM Control Channel.
The DM is configured as a secondary for the Registered Homenet Domain
Name.  This secondary configuration has been previously agreed
between the end user and the provider of the DOI as part of either
the provisioning or due to receipt of DNS Update messages on the DM
Control Channel.
The AXFR request from the DM to the HNA SHOULD be secured.  DNS over
TLS RFC7858 is RECOMMENDED.
When using TLS, the HNA MAY authenticate inbound connections from the
DM using standard mechanisms, such as a public certificate with
baked-in root certificates on the HNA, or via DANE {!RFC6698}}.  In
addition, to guarantee the DM remains the same across multiple TLS
session, the HNA and DM MAY implement RFC8672.
The Hidden Primary, as described in this document SHOULD drop any
queries from the home network.  This could be implemented via port
binding and/or firewall rules.  The precise mechanism deployed is out
of scope of this document.  The Hidden Primary SHOULD drop any DNS
queries arriving on the WAN interface that are not issued from the
DM.  The Hidden Primary SHOULD drop any outgoing packets other than
DNS NOTIFY query, SOA response, IXFR response or AXFR responses.  The
Hidden Primary SHOULD drop any incoming packets other than DNS NOTIFY
response, SOA query, IXFR query or AXFR query.  The Hidden Primary
SHOULD drop any non protected IXFR or AXFR exchange,depending on how
the synchronization is secured.
The HNA, as Hidden Primary SHOULD drop any queries from the home
network.  This could be implemented via port binding and/or firewall
rules.  The precise mechanism deployed is out of scope of this
document.  The Hidden Primary SHOULD drop any DNS queries arriving on
the WAN interface that are not issued from the DM.  The Hidden
Primary SHOULD drop any outgoing packets other than DNS NOTIFY query,
SOA response, IXFR response or AXFR responses.  The Hidden Primary
SHOULD drop any incoming packets other than DNS NOTIFY response, SOA
query, IXFR query or AXFR query.  The Hidden Primary SHOULD drop any
non protected IXFR or AXFR exchange,depending on how the
synchronization is secured.
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
DNS Outsourcing Infrastructures.
The DS RRset can be updated manually with nsupdate for example.  This
requires the HNA or the DNS Outsourcing Infrastructure 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 DNS Outsourcing Infrastructure.  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 DNS
Outsourcing Infrastructure 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 DNS Outsourcing Infrastructure.
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 be not 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 DNS Outsourcing Infrastructure of the associated reverse
zone.
In the case of the reverse zone, the DNS Outsourcing Infrastructure
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.
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.
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.
With this relation automatically configured, the synchronization
between the Home network and the DNS Outsourcing Infrastructure
happens similarly as for the Public Homenet Zone described earlier in
this document.
Note that for home networks hosted by multiple ISPs, each ISP
provides only the DNS Outsourcing Infrastructure 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 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 hosted 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.
The HNA will need to select an IP address for communication for the
Synchronization Channel.  This is typically the outside WAN address
of the router, but could be an IPv6 LAN address in the case of a home
with multiple ISPs (and multiple border routers).  This is
communicated in section BLAH when the NS and A record is
communicated.
The above parameters MUST be be provisionined 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, it the HNA is provided by a registrar, the HNA may be
given configured to end user.
The HNA will need to select an IP address for communication for the
Synchronization Channel.  This is typically the outside WAN address
of the router, but could be an IPv6 LAN address in the case of a home
with multiple ISPs (and multiple border routers).  This is
communicated in section 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
given configured to end user.
The HNA may present the end user a web interface where it provides
the end user the ability to indicate the Registered Domain or the
registrar for example a preselected list.  Once the regsitrar 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.
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.
In a renumbering scenario, the 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.
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.
In the case of the make-before-break, seamless reachability is
provided as long as T_OLD_UNREACHABLE - T_NEW > 2 * TTL.  If this is
not satisfied, then devices associated with the old IP address in the
home network may become unreachable for 2 * TTL - (T_OLD_UNREACHABLE
- T_NEW).  In the case of a break-before-make, T_OLD_UNREACHABLE =
T_NEW, and the device may become unreachable up to 2 * TTL.
Once the Public Homenet Zone file has been updated on the Hidden
Primary, the Hidden Primary needs to inform the DNS Outsourcing
Infrastructure 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.
The Hidden Primary SHOULD inform the DM that the Public Homenet Zone
has been updated by sending a NOTIFY payload with the new IP address.
In addition, this NOTIFY payload SHOULD be authenticated using SIG(0)
or TSIG.  When the DM receives the NOTIFY payload, it MUST
authenticate it.  Note that the cryptographic key used for the
authentication SHOULD be indexed by the Registered Homenet Domain
contained in the NOTIFY payload as well as the RRSIG.  In other
words, the IP address SHOULD NOT be used as an index.
If authentication succeeds, the DM MUST also notice the IP address
has been modified and perform a reachability check before updating
its primary configuration.  The routability check MAY performed by
sending a SOA request to the Hidden Primary using the source IP
address of the NOTIFY.  This exchange is also secured, and if an
authenticated response is received from the Hidden Primary with the
new IP address, the DM SHOULD update its configuration file and
retrieve the Public Homenet Zone using an AXFR or a IXFR exchange.
Note that the primary reason for providing the IP address is that the
Hidden Primary is not publicly announced in the DNS.  If the Hidden
Primary were publicly announced in the DNS, then the IP address
update could have been performed using the DNS as described in sec-
secondary.
Renumbering of the Distribution Master results in it changing its IP
address.  As the DM is a secondary, the destination of DNS NOTIFY
payloads MUST be changed, and any configuration/firewalling that
restricts DNS AXFR/IXFR operations MUST be updated.
If the DM is configured in the Hidden Primary configuration file
using a FQDN, then the update of the IP address is performed by DNS.
More specifically, before sending the NOTIFY, the Hidden Primary
performs a DNS resolution to retrieve the IP address of the
secondary.
As described in sec-primary, the DM DNS information SHOULD be
coherent with the IP plane.  The TTL of the Distribution Master name
SHOULD be adjusted appropriately prior to changing the IP address.
Some DNS infrastructure uses the IP address to designate the
secondary, in which case, other mechanisms must be found.  A reason
for using IP addresses instead of names is generally to reach an
internal interface that is not designated by a FQDN, and to avoid
potential bootstrap problems.  Such scenarios are considered as out
of scope in the case of home networks.
In the case of the make-before-break, seamless reachability is
provided as long as T_OLD_UNREACHABLE - T_NEW > 2 * TTL.  If this is
not satisfied, then devices associated with the old IP address in the
home network may become unreachable for 2 * TTL - (T_OLD_UNREACHABLE
- T_NEW).  In the case of a break-before-make, T_OLD_UNREACHABLE =
T_NEW, and the device may become unreachable up to 2 * TTL.  Of
course if T_NEW >= T_OLD_UNREACHABLE, the disruption is increased.
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.
In general a home owner is expected only to publish names for which
there is some need to be able to reference externally.  Publication
of the name does not imply that the service is necessarily reachable
from any or all parts of the Internet.  RFC7084 mandates that the
outgoing-only policy RFC6092 be available, and in many cases it is
configured by default.  A well designed User Interface would combine
a policy for making a service public by a name with a policy on who
may access it.
In many cases, the home owner wishes to publish names for services
that only they will be able to access.  The access control may
consist of an IP source address range, or access may be restricted
via some VPN functionality.  The purpose of publishing the name is so
that the service may be access by the same name both within the home,
and outside the home.  Sending traffic to the relevant IPv6 address
causes the relevant VPN policy to be enacted upon.
In general a home network owner is expected to publish only names for
which there is some need to be able to reference externally.
Publication of the name does not imply that the service is
necessarily reachable from any or all parts of the Internet.  RFC7084
mandates that the outgoing-only policy RFC6092 be available, and in
many cases it is configured by default.  A well designed User
Interface would combine a policy for making a service public by a
name with a policy on who may access it.
In many cases, the home network owner wishes to publish names for
services that only they will be able to access.  The access control
may consist of an IP source address range, or access may be
restricted via some VPN functionality.  The purpose of publishing the
name is so that the service may be access by the same name both
within the home, and outside the home.  Sending traffic to the
relevant IPv6 address causes the relevant VPN policy to be enacted
upon.
The channels between DM and RDM are mutually authenticated and
encrypted with TLS RFC8446 and its associated security considerations
apply.  To ensure the multiple TLS session are are continuously
authenticating the same entity, TLS may take advantage of second
factor authentication as described in RFC8672.
The DNS protocol is subject to reflection attacks, however, these
attacks are largely applicable when DNS is carried over UDP.  The
interfaces between the HNA and DM and RDM are using TLS over TCP,
which prevents such reflection attacks.  Note that Public
Authoritative servers hosted by the DOI are subject to such attacks,
but that is out of scope of our document.
Note that in the case of the Reverse Homenet Zone, the data is less
subject to attacks than in the Public Homenet Zone.  In addition, the
DM and RDM may be provided by the ISP - as described in I-D.ietf-
homenet-naming-architecture-dhc-options, in which case DM and RDM
might be less exposed to attacks.
The channels between HNA and DM are mutually authenticated and
encrypted with TLS RFC8446 and its associated security considerations
apply.  To ensure the multiple TLS session are are continuously
authenticating the same entity, TLS may take advantage of second
factor authentication as described in RFC8672.
The DNS protocol is subject to reflection attacks, however, these
attacks are largely applicable when DNS is carried over UDP.  The
interfaces between the HNA and DM are using TLS over TCP, which
prevents such reflection attacks.  Note that Public Authoritative
servers hosted by the DOI are subject to such attacks, but that is
out of scope of our document.
Note that in the case of the Reverse Homenet Zone, the data is less
subject to attacks than in the Public Homenet Zone.  In addition, the
DM and RDM may be provided by the ISP - as described in I-D.ietf-
homenet-naming-architecture-dhc-options, in which case DM and RDM
might be less exposed to attacks - as communications within a
network.
This section specifies the various parameters required by the HNA to
configure the naming architecture of this document.  This section is
informational, and is intended to clarify the information handled by
the HNA and the various settings to be done.
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.  The session between
the HNA and the DM is authenticated with TLS.  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 values are Do53, DoT, DoH.  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".
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 DNS Outsourced
Infrastructure consists of a number of different systems.  An
array of addresses is permitted.  This parameter is OPTIONAL and
if unspecified, the CPE the IP addresses specified in the
dm_notify parameters or the IP addresses that result from the
DNS(SEC) resolution when dm_notify specifies 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.