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

Commentary: addressing issue 17
sec-reverse discusses management of one or more reverse zones.  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.
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, but not necessarily.
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.
This section is focused on the Homenet Reverse Zone.
Firstly, all considerations for the Public Homenet Zone apply to the
Homenet Reverse Zone.  The main difference between the Homenet
Reverse Zone and the Homenet Zone is that the parent zone of the
Homenet Reverse Zone is most likely managed by the ISP.  As the ISP
also provides the IP prefix to the HNA, it may be able to
authenticate the HNA using mechanisms outside the scope of this
document e.g. the physical attachment point to the ISP network.  If
the Reverse DM is managed by the ISP, credentials to authenticate the
HNA for the zone synchronization may be set automatically and
transparently to the end user.  I-D.ietf-homenet-naming-architecture-
dhc-options describes how automatic configuration may be performed.
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
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 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 Outsourcing Infrastructure of the associated reverse
zone.  This leave place for setting up automatically the relation
between HNA and the Outsourcing infrastructure as described in I-
D.ietf-homenet-naming-architecture-dhc-options.
With this relation automatically configured, the synchronization
between the Home network and the 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 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.
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
HNA and the DM MAY belong to the same administrative domain, i.e. the
ISP.  More specifically, the WAN interface is located in the ISP
network.  As a result, if provisioned using DHCPv6, the security
credential may not even transit in the home network.  On the other
hand, if the HNA is not hosted at the border of the home network, the
credential may rely on the security associated to DHCPv6.  Even if
HNA and DM are in the same administrative domain it is strongly
RECOMMENDED to use a secure channel.