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

Commentary: … ument , dealing with issue 
 handling different views ( 7.0 ) .... some would like to have different views , This document deals with the view that the Internet gets from the CPE(s ) only .
sec-arch-overview provides an architecture description that describes
the relation between the Homenet Naming Authority and the Outsourcing
Architecture.  In order to keep the Public Homenet Zone up-to-date
sec-synch describes how the Homenet Zone and the Public Homenet Zone
can be synchronized.  The proposed architecture aims at deploying
DNSSEC, and the Public Homenet Zone is expected to be signed with a
secure delegation.  The zone signing and secure delegation may be
performed either by the Homenet Naming Authority or by the
Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two
alternatives. sec-views discusses the consequences of publishing
multiple representations of the same zone also commonly designated as
views.  This section provides guidance to limit the risks associated
with multiple views.  sec-reverse discusses management of the reverse
zone. sec-renumbering discusses how renumbering should be handled.
Finally, sec-privacy and sec-security respectively discuss privacy
and security considerations when outsourcing the Homenet Zone.
sec-arch-overview provides an architecture description that describes
the relation between the Homenet Naming Authority and the Outsourcing
Architecture.  In order to keep the Public Homenet Zone up-to-date
sec-synch describes how the Homenet Zone and the Public Homenet Zone
can be synchronized.  The proposed architecture aims at deploying
DNSSEC, and the Public Homenet Zone is expected to be signed with a
secure delegation.  The zone signing and secure delegation may be
performed either by the Homenet Naming Authority or by the
Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two
alternatives. sec-reverse discusses management of the reverse zone.
sec-renumbering discusses how renumbering should be handled.
Finally, sec-privacy and sec-security respectively discuss privacy
and security considerations when outsourcing the Homenet Zone.
The Homenet Zone is expected to host public information only.  It is
not the scope of this DNS service to define local home network
boundaries.  Instead, local scope information is expected to be
provided to the home network using local scope naming services. mDNS
RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently
mDNS is limited to a single link network.  However, future protocols
are expected to leverage this constraint as pointed out in RFC7558.
The Outsourcing Infrastructure is described in fig-auth-servers.  The
Synchronization Server receives the Homenet Zone as an input.  The
received zone may be transformed to output the Public Homenet Zone.
Various operations may be performed here, however this document only
considers zone signing as a potential operation.  This should occur
only when the HNA outsources this operation to the Synchronization
Server.  On the other hand, if the HNA signs the Homenet Zone itself,
the zone would be collected by the Synchronization Server and
directly transferred to the Public Authoritative Server(s).  These
policies are discussed and detailed in sec-dnssec-deplyment and sec-
views.
The Outsourcing Infrastructure is described in fig-auth-servers.  The
Synchronization Server receives the Homenet Zone as an input.  The
received zone may be transformed to output the Public Homenet Zone.
Various operations may be performed here, however this document only
considers zone signing as a potential operation.  This should occur
only when the HNA outsources this operation to the Synchronization
Server.  On the other hand, if the HNA signs the Homenet Zone itself,
the zone would be collected by the Synchronization Server and
directly transferred to the Public Authoritative Server(s).  These
policies are discussed and detailed in sec-dnssec-deplyment.
As depicted in fig-naming-arch and fig-auth-servers, the Public
Homenet Zone is hosted on the Public Authoritative Server(s), whereas
the Homenet Zone is hosted on the HNA.  Motivations for keeping these
two zones identical are detailed in sec-views, and this section
considers that the HNA builds the zone that will be effectively
published on the Public Authoritative Server(s).  In other words
"Homenet to Public Zone transformation" is the identity also commonly
designated as "no operation" (NOP).
As depicted in fig-naming-arch and fig-auth-servers, the Public
Homenet Zone is hosted on the Public Authoritative Server(s), whereas
the Homenet Zone is hosted on the HNA.  This section considers that
the HNA builds the zone that will be effectively published on the
Public Authoritative Server(s).  In other words "Homenet to Public
Zone transformation" is the identity also commonly designated as "no
operation" (NOP).
2) Keeping the Homenet Zone and the Public Homenet Zone equal to
securely address the connectivity disruption independence detailed
in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible
in case of network disruption, communications within the home
network can still rely on the DNSSEC service.  Note that
outsourcing the zone signing operation does not address
connectivity disruption independence with DNSSEC.  Instead local
lookup would provide DNS as opposed to DNSSEC responses provided
by the Public Authoritative Server(s).
Keeping the Homenet Zone and the Public Homenet Zone equal to
securely address the connectivity disruption independence detailed
in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible
in case of network disruption, communications within the home
network can still rely on the DNSSEC service.  Note that
outsourcing the zone signing operation does not address
connectivity disruption independence with DNSSEC.  Instead local
lookup would provide DNS as opposed to DNSSEC responses provided
by the Public Authoritative Server(s).
3) Keeping the Homenet Zone and the Public Homenet Zone equal to
guarantee coherence between DNS responses.  Using a unique zone is
one way to guarantee uniqueness of the responses among servers and
places.  Issues generated by different views are discussed in more
details in sec-views.
4) Privacy and Integrity of the DNSSEC Homenet Zone are better
guaranteed.  When the Zone is signed by the HNA, it makes
modification of the DNS data -- for example for flow redirection --
impossible.  As a result, signing the Homenet Zone by the HNA
provides better protection for end user privacy.
Privacy and Integrity of the DNSSEC Homenet Zone are better
guaranteed.  When the Zone is signed by the HNA, it makes
modification of the DNS data -- for example for flow redirection
-- impossible.  As a result, signing the Homenet Zone by the HNA
provides better protection for end user privacy.
The Homenet Zone provides information about the home network.  Some
users may be tempted to have provide responses dependent on the
origin of the DNS query.  More specifically, some users may be
tempted to provide a different view for DNS queries originating from
the home network and for DNS queries coming from the Internet.  Each
view could then be associated with a dedicated Homenet Zone.
Note that this document does not specify how DNS queries originating
from the home network are addressed to the Homenet Zone.  This could
be done via hosting the DNS resolver on the HNA for example.
This section is not normative. sec-reasons details why some nodes may
only be reachable from the home network and not from the global
Internet. sec-consequences briefly describes the consequences of
having distinct views such as a "home network view" and an "Internet
view".  Finally, sec-guidance provides guidance on how to resolve
names that are only significant in the home network, without creating
different views.
1: An end user may want to have services not published on the
Internet.  Services like the HNA administration interface that
provides the GUI to administer your HNA might not seem advisable to
publish on the Internet.  Similarly, services like the mapper that
registers the devices of your home network may also not be desirable
to be published on the Internet.  In both cases, these services
should only be known or used by the network administrator.  To
restrict the access of such services, the home network administrator
may choose to publish these pieces of information only within the
home network, where it might be assumed that the users are more
trusted than on the Internet.  Even though this assumption may not be
valid, at least this may reduce the surface of any attack.
2: Services within the home network may be reachable using non global
IP addresses.  IPv4 and NAT may be one reason.  On the other hand
IPv6 may favor link-local or site-local IP addresses.  These IP
addresses are not significant outside the boundaries of the home
network.  As a result, they MAY be published in the home network
view, and SHOULD NOT be published in the Public Homenet Zone.
Enabling different views leads to a non-coherent naming system.
Depending on where resolution is performed, some services will not be
available.  This may be especially inconvenient with devices with
multiple interfaces that are attached both to the Internet via a
3G/4G interface and to the home network via a WLAN interface.
Devices may also cache the results of name resolution, and these
cached entries may no longer be valid if a mobile device moves
between a homenet connection and an internet connection e.g. a device
temporarily loses wifi signal and switches to 3G.
Regarding local-scope IP addresses, such devices may end up with poor
connectivity.  Suppose, for example, that DNS resolution is performed
via the WLAN interface attached to the HNA, and the response provides
local-scope IP addresses, but the communication is initiated on the
3G/4G interface.  Communications with local-scope addresses will be
unreachable on the Internet, thus aborting the communication.  The
same situation occurs if a device is flip / flopping between various
WLAN networks.
Regarding DNSSEC, if the HNA does not sign the Homenet Zone and
outsources the signing process, the two views are different, because
one is protected with DNSSEC whereas the other is not.  Devices with
multiple interfaces will have difficulty securing the naming
resolution, as responses originating from the home network may not be
signed.
For devices with all its interfaces attached to a single
administrative domain, that is to say the home network, or the
Internet.  Incoherence between DNS responses may still also occur if
the device is able to perform DNS resolutions both using the DNS
resolving server of the home network, or one of the ISP.  DNS
resolution performed via the HNA or the ISP resolver may be different
than those performed over the Internet.
As documented in sec-consequences, it is RECOMMENDED to avoid
different views.  If network administrators choose to implement
multiple views, impacts on devices' resolution SHOULD be evaluated.
As a consequence, the Homenet Zone is expected to be an exact copy of
the Public Homenet Zone.  As a result, services that are not expected
to be published on the Internet SHOULD NOT be part of the Homenet
Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone,
and when possible, the HNA SHOULD sign the Homenet Zone.
The Homenet Zone is expected to host public information only.  It is
not the scope of the DNS service to define local home network
boundaries.  Instead, local scope information is expected to be
provided to the home network using local scope naming services. mDNS
RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently
mDNS is limited to a single link network.  However, future protocols
are expected to leverage this constraint as pointed out in RFC7558.