[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-homenet-front-end-naming-delegation

HOMENET                                                  D. Migault (Ed)
Internet-Draft                                    Francetelecom - Orange
Intended status: Standards Track                             W. Cloetens
Expires: May 10, 2013                                         SoftAtHome
                                                            P. Lemordant
                                                  Francetelecom - Orange
                                                            C. Griffiths
                                            Comcast Cable Communications
                                                        November 6, 2012


             IPv6 Home Network Front End Naming Delegation
         draft-mglt-homenet-front-end-naming-delegation-01.txt

Abstract

   CPEs are designed to provide IP connectivity to the Home Network.
   Most of the CPEs are also providing the IP addresses of the nodes of
   the Home Network.  This makes CPEs good candidates for hosting the
   Naming Service that would make devices reachable from the Home
   Network but also from the Internet.

   CPEs have not been designed to host a Naming Service reachable from
   the Internet.  This would expose the CPEs and the Home Network to
   resource exhaustion which would result in making the Home Network
   unreachable, and most probably would also affect the Home Network
   inner communications.

   This document describes an Front End Naming Architecture where the
   CPEs manage the DNS(SEC) zone for its Home Network, and outsource the
   zone to Public Server for resolution coming from the Internet.

   The goal of the document is first to describe a Naming Architecture
   that fulfills Home Network Naming requirements without exposing the
   CPE to resource exhaustion.  Then we intend the CPEs to be easily
   configured by the End Users, and describe the necessary information
   the End User is expect to provide to the CPE.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.




Migault (Ed), et al.      Expires May 10, 2013                  [Page 1]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






























Migault (Ed), et al.      Expires May 10, 2013                  [Page 2]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Front End Naming Architecture Requirements . . . . . . . . . .  5
   4.  Front End Naming Architecture Presentation . . . . . . . . . .  6
   5.  Front End Naming Architecture Description  . . . . . . . . . .  8
     5.1.  Setting the Homenet Authoritative Server . . . . . . . . .  8
     5.2.  Setting the Homenet View . . . . . . . . . . . . . . . . .  8
     5.3.  Setting the Public View  . . . . . . . . . . . . . . . . .  9
     5.4.  Synchronizing the Public View  . . . . . . . . . . . . . .  9
     5.5.  Securing the Synchronization . . . . . . . . . . . . . . . 10
     5.6.  Setting the Homenet Resolution Server  . . . . . . . . . . 11
     5.7.  Additional Views . . . . . . . . . . . . . . . . . . . . . 11
   6.  CPE's interface Recommendations  . . . . . . . . . . . . . . . 11
   7.  Position toward Homenet Architecture . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     8.1.  Names are less secure than IP addresses  . . . . . . . . . 13
     8.2.  Names are less volatile than IP addresses  . . . . . . . . 13
     8.3.  DNSSEC is recommended to authenticate DNS hosted data  . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informational References . . . . . . . . . . . . . . . . . 15
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
























Migault (Ed), et al.      Expires May 10, 2013                  [Page 3]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   IPv6 provides global IP reachability to almost all nodes of the Home
   Network even outside the Home Network.  However End Users do not want
   to access to the Services hosted in the Home Network with IPv6
   addresses, but prefer to use names.

   CPEs are already providing IPv6 connectivity to the Home Network and
   generally provide IPv6 addresses or prefixes to the nodes of the Home
   Network.  This makes the CPEs a good candidate to manage binding
   between names and IP addresses of the nodes.  In other words, the CPE
   is the natural candidate for setting the DNS(SEC) zone file.

   CPEs are usually low powered devices designed for the Home Network,
   but not for heavy traffic.  CPEs can host the Naming Service for the
   Home Network but should not be exposed on the Internet.  This would
   expose the CPE to resource exhaustion.  As a consequence, it may
   isolate the Home Network from the Internet and affects the services
   hosted by the CPEs, thus affecting Home Network communications.  As a
   result, CPE SHOULD NOT host the Naming Service of the Home Network
   for resolutions coming from the Internet.

   In this document, we propose that the CPE sets the DNS(SEC) zone of
   the Home Network.  The CPE may generate different zones one for the
   queries coming from the Home Network, and one for queries coming from
   the Internet.  We respectively call these Zones Homenet View and
   Public View.  The CPE hosts the Homenet View and responds to the
   associated DNS(SEC) queries coming from the Home Network.  For
   queries coming from the Internet, the CPE outsources the Public View
   to Public DNS(SEC) Servers that responds to the queries.

   This document describes the Front End Naming Architecture where the
   CPE hosts the Naming Service for the Home Network and outsources it
   for queries from outside the Home Network.  We especially insists on
   the parameters the CPE requires to properly set up the Front End
   Naming Architecture.

   Section 3 describes the Front End Naming Architecture requirements.
   Section 4 presents the different functional entities involved in the
   Front End Naming Architecture.  Section 5 details configuration of
   the various functional entities as well as how they interact each



Migault (Ed), et al.      Expires May 10, 2013                  [Page 4]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   other.Section 6 is informative and sums up the different inputs the
   CPE requires from the End User to set up the Front End Naming
   Architecture.  Section 7 positions the described architecture toward
   the Home Network Architecture.  Finally Section 8 provides security
   considerations.


3.  Front End Naming Architecture Requirements

   This section lists and details goals and requirements of Front End
   Naming Architecture.

   - REQUIREMENT 1:   DNS(SEC) queries for subdomain of the Homenet
         Domain Name MUST be responded by the Public DNS(SEC) Servers
         when issued from outside the Home Network.  CPE could hardly
         cope with heavy traffic coming from the Internet.  To avoid
         exposing the CPE to resource exhaustion, the Naming Service is
         outsourced on the Public DNS(SEC) Servers for traffic coming
         from the Internet.

   - REQUIREMENT 2:   The CPE MUST NOT, by default, accept any DNS(SEC)
         queries from outside the Home Network.  In some aspects, it
         rewords the previous requirement.

   - REQUIREMENT 3:   The IP address of the CPE SHOULD NOT be publicly
         published.  This requirement avoids the DNS(SEC) queries
         incidentally ends up on the CPE.

   - REQUIREMENT 5:   DNS(SEC) queries for subdomain of the Homenet
         Domain Name MUST be responded by the CPE when issued from the
         Home Network.  To guarantee the Home Network independence in
         case the Home Network has no connectivity on the Internet, the
         CPE MUST respond to DNS(SEC) queries for subdomain of the
         Homenet Domain Name coming from the Home Network.

   - REQUIREMENT 6:   The CPE MUST be able to update the Home Network
         Zone hosted on the Public DNS(SEC) Servers.

   - REQUIREMENT 7:   The CPE SHOULD be able to provide different views.
         At least the CPE should be able to handle a view for the Home
         Network nodes and a view for the nodes outside the Home
         Network.  Home Network nodes that are not supposed to be
         reachable from outside the Home Network are not expected to be
         part of the latest view.







Migault (Ed), et al.      Expires May 10, 2013                  [Page 5]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


4.  Front End Naming Architecture Presentation

   This section describes the Front End Naming Architecture and defines
   the notations used in this document.

   - Home Network:   designates all devices that are behind and managed
         by the CPE.

   - Internet:   designates the network the CPE is attached to.

   The CPE connects the Home Network to the Internet.  Although the
   different functional entities listed below MUST NOT necessarily be
   hosted on the CPE, we assume in this document they are hosted on the
   CPE:

   - Homenet Resolving Server:   is the DNS Resolver Server of the Home
         Network.  Typically its IP address is announced via DHCPv6.
         Most of DNS(SEC) queries from nodes on the Home Network are
         expected to be addressed to this Homenet Resolving Server.  The
         Homenet Resolving Server is expected to receive queries only
         from the Home Network.

   - Homenet Authoritative Server:   is the Authoritative Server of the
         Home Network.  This server hosts bindings between FQDNs and IP
         addresses.  Unless cached, most of the DNS(SEC) queries sent
         from the Home Network that concerns a node in the Home Network
         are expected to be forwarded to this Homenet Authoritative
         Server.  More specifically DNS(SEC) resolutions sent from the
         Home Network are expected to be sent to the Homenet Resolving
         Server.  The Homenet Resolver Server is a forwarder and
         forwards to the Homenet Authoritative Server queries for domain
         names or subdomain of the Homenet Domain Name.  For other
         resolutions, the Homenet Resolving Server proceeds to
         traditional DNS(SEC) resolutions over the public DNS(SEC)
         infrastructure.

   - Homenet View:   is the DNS(SEC) zone that contains all bindings
         between FQDNs associated to the Homenet Domain Name and IP
         addresses.  The Home Network may have multiple views, but for
         most Home Networks, a single Homenet View is expected.
         Information of this Homenet View is only visible from the Home
         Network.

   - Public View:   is the view that contains the bindings between FQDNs
         and IP addresses.  Unlike the Homenet View, the Public View is
         expected to be publicly published.  The Public View contains
         information visible from the Internet.  It is expected that the
         Public View is constituted by a subset of the names of the



Migault (Ed), et al.      Expires May 10, 2013                  [Page 6]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


         Homenet View.  More specifically, devices that are not expected
         to be reachable from the Internet should not be part of the
         Public View.  In some implementations, the Public View may be
         equivalent to the the Homenet View.  In this latter case Public
         Views and Homenet Views will be represented by a single file.

   - Master Public Server:   is the part of the CPE that deals with the
         Public view of the Home Network.  The Master Public Server is
         in charge of providing the Public View to the Public DNS(SEC)
         Servers.  It is not necessarily a DNS(SEC) server.  However, in
         this document we are using DNS mechanisms to synchronize the
         Public View in the Public DNS(SEC) Servers and the Public View
         on the CPE.

   - WAN Interface:   the CPE Interface on the Internet.

   - Homenet Interfaces:   the CPE Interfaces on the Home Network.
         There might be a single or multiple interfaces.

   The other involved entities are:

   - Public DNS(SEC) Servers:   are the servers on the Internet hosting
         the Public View of the Home Network.

   - Homenet Node:   a Node of the Home Network

   - Node:   a Node located on the Internet.  This Node is expected to
         be in most of the cases a resolving server.

   - Homenet Domain Name:   The domain name associated to the Home
         Network.  There may be one or multiple domain names.

   Figure 1 illustrates how a DNS(SEC) resolution is performed from a
   Node in the Home Network or from a node on the Internet.

   The Homenet Node sends a DNS(SEC) query to the Homenet Resolving
   Server (1).  When the Homenet Resolving Server receives the DNS(SEC)
   it notices that query name is a subdomain of the Homenet Domain Name
   (example.com), and forwards the query to the Homenet Authoritative
   Server that hosts the Homenet View (2).  The Homenet Authoritative
   Server sends the response to the Homenet Resolving Server (3), which
   finally sends the response to the Homenet Node (4).

   For a node located on the Internet, the DNS(SEC) query is requesting
   the Public DNS infrastructure (.com) which redirects the DNS(SEC)
   query to the Public DNS(SEC) Servers (a).  The Public DNS(SEC) Server
   sends the response back to the Node (b).




Migault (Ed), et al.      Expires May 10, 2013                  [Page 7]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


                    +-------------------+  DNS(SEC) Query / Response:
                    |      CPE          |    Q: video.example.com AAAA
 +---------+        +-------------------+    R: video.example.com
 |         | Q  (1) | Homenet Resolving |W              AAAA IP6
 | Homenet | ------>| Server ....       |A   Internet
 | Node    | <------| ......     | (2)  |N                   +---------+
 |         | R  (4) |    (3) ^   v      |                    |         |
 +---------+        +-------------------+I                   |  Node   |
                    | Homenet Authorit. |n                   |         |
                  H | Server            |t                   |         |
                  o |+-----------------+|e                   +---------+
                  m || Homenet View    ||r                      |   ^
                  e ||              |  ||f.                  Q  |   |(b)
 Home Network     n ||     (.local) v  | |  Master/Slave     (a) |   | R
                  e |+-----------------+|  Synchronization      v   |
 Homenet Domain   t +-------------------+   |      +-------------------+
 Name:              | Hidden Master     |   |      | Public DNS(SEC)   |
 example.com      I | Public Server     |   |      | Servers           |
                  n |+-----------------+|   |      |+-----------------+|
                  t || Public View     ||   v      || Public View     ||
                  e ||                 ||==========||                 ||
                  r ||  (example.com)  ||          ||  (example.com)  ||
                  f.|+-----------------+|          |+-----------------+|
                    +-------------------+          +-------------------+

                    Figure 1: Front End Naming Architecture Description


5.  Front End Naming Architecture Description

   This section provides a more detailed description of the Front End
   Naming Architecture.  More specifically it shows how the entities
   described in Section 4 are organized to fulfill the requirements of
   Section 3.

5.1.  Setting the Homenet Authoritative Server

   The Homenet Authoritative MUST be configured to reject any queries
   coming from outside the Home Network, i.e. not from the Homenet
   Interface.  In other words, DNS queries related to the Homenet Domain
   Names MUST never be received from the WAN Interface.

5.2.  Setting the Homenet View

   The Homenet Authoritative Server may be authoritative for multiple
   Homenet Domain Names and each Homenet Domain Name may be associated
   with multiple views.




Migault (Ed), et al.      Expires May 10, 2013                  [Page 8]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   The CPE is expected to be provided the various Homenet Domain Names
   so it can properly generate the associated Homenet Zone files and the
   appropriate DNS(SEC) settings.

5.3.  Setting the Public View

   The Public DNS(SEC) Servers MUST handle all DNS(SEC) queries related
   to any Homenet Domain Names that are sent from outside the Home
   Network.

   The CPE MUST generate the Public View.  In the case of multiple
   Homenet Domain Names, multiple views MUST be generated, and in order
   to fill properly the SOA and NS field, the CPE must be provided for
   each Homenet Domain Name the corresponding Public DNS(SEC) name, and
   IP addresses.

5.4.  Synchronizing the Public View

   Uploading and dynamically updating the zone file on the Public
   Servers can be seen as zone provisioning between the CPE (Hidden
   Master) and the Public Server (Slave Server).  This can be handled
   either in band or out of band.  DNS dynamic update [RFC2136] may be
   used.  However, in this section we detail how to take advantage of
   the DNS slave / master architecture to deploy updates to public
   zones.

   The Public DNS Server is configured as a slave for the Homenet Domain
   Name.  This slave configuration has been previously agreed between
   the End User and the provider of the Public DNS Servers.  The CPE is
   hosting the Public Zone files associated to the various Homenet
   Domain Names and associated views.  Each of these files are
   associated a Public Server.  In order to set the master/ slave
   architecture, the CPE acts as a Hidden Master Public Server, which is
   a regular Authoritative DNS(SEC) Server listening on the WAN
   interface.

   The Hidden Master Public Server is only expected to initiate AXFR
   [RFC1034], IXFR [RFC1995] transfers to configured slave DNS servers.
   The Hidden Master Public Server should send NOTIFY messages [RFC1996]
   in order to update Public DNS server zones as updates occur.

   The CPE MUST be configured to send NOTIFY only when necessary.  It is
   recommended for example that it checks first the SOA on the Public
   DNS Server before sending a NOTIFY.  In other words, rebooting a CPE
   SHOULD NOT systematically trigger a NOTIFY message.

   Hidden Master Public Server differs from the Homenet Authoritative
   Server by:



Migault (Ed), et al.      Expires May 10, 2013                  [Page 9]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   - Interface:   the Homenet Authoritative Server listens on the
         Homenet Interface whereas the Hidden Master Public Server
         listen on the WAN Interface

   - View:   Homenet Authoritative Server hosts the names that are
         available on the Home Network, whereas the Hidden Master Public
         Server hosts the names that are publicly available.  These two
         zones may differ since some of the nodes may not be reached
         from outside the Home Network.

   - Traffic:   Homenet Authoritative Server expects traffic from the
         Home Network, whereas the Hidden Master Public Server only
         accepts traffic from the Public Servers.

   - Function:   Homenet Authoritative Servers acts as an authoritative
         DNS Server on the Home Network, whereas the Hidden Master
         Public Server only synchronizes with the Public DNS Servers.

   In this document, Master Public Server differs from the Homenet
   Authoritative Server as different functions.  Both functions may be
   implemented by a single running instance of Authoritative Servers.

5.5.  Securing the Synchronization

   Exchange between the Public Servers and the CPE MUST be secured, at
   least for integrity protection and for authentication.  This is the
   case whatever mechanism is used between the CPE and the Public
   DNS(SEC) Servers.

   TSIG [RFC2845] can be used to secure the DNS communications between
   the CPE and the Public DNS(SEC) Servers.  TKEY [RFC2931] can be used
   for re-keying the key used for TSIG.  Using TSIG and TKEY requires
   that this mechanism is implemented on the DNS(SEC) Server's
   implementation running on the CPE.  One disadvantage is that TKEY
   does not provides authentication mechanism, and the initial shared
   secret must be set manually.

   Protocols like TLS [RFC5246] / DTLS [RFC6347] can be used to secure
   the transactions between the Public Servers and the CPE.  Their use
   would require the implementations to integrate TLS/DTLS as a security
   layer.  TLS/DTLS can use certificates to authenticate the Public
   Server and the CPE.  For example, the certificates can be hosted on a
   dongle.

   IPsec [RFC4301] IKEv2 [RFC5996] can also be used to secure the
   transactions between the CPE and the Public Servers.  IKEv2 provides
   multiple authentications possibilities with its EAP framework.  Then,
   IPsec security does not require any changes of the DNS applications.



Migault (Ed), et al.      Expires May 10, 2013                 [Page 10]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   For these reasons, we recommend using IPsec.

5.6.  Setting the Homenet Resolution Server

   The Homenet Resolving Server MUST be configured as a DNS forwarder.
   When a DNS(SEC) query coming from the Home Network concerns a Homenet
   Domain Name or a Homenet Subdomain Name, the resolution MUST be
   performed with the Homenet Authoritative Server.  If the Home Network
   has multiple Homenet Domain Names, multiple forwarding rules may be
   applied.

   To properly configure a basic configuration, the Homenet Resolving
   Server needs to be informed of the Homenet Domain Names and
   associated Homenet Authoritative Server.  They may be one or multiple
   associated Homenet Authoritative Servers.  The same Authoritative
   Naming Server may be used for multiple Homenet Domain Names.

5.7.  Additional Views

   In this document, we considered the Public and Homenet View.  Each of
   these Views may have additional views.


6.  CPE's interface Recommendations

   This section describes the various objects that are required to
   properly set the Front End Naming Architecture.  This section is
   informational, and is intended to clarify the information handled by
   the CPE and the various settings to be done.

   A Public Server is defined with the following information:

   - Public Server Name:   The associated FQDN of the Public Server

   - IP addresses:   The list of IP addresses associated to the Public
         Server.  This list should not be provided by the End User.
         Instead, it should be provided by performing a DNSSEC exchange.
         If the Public Server Name DNS resolution cannot be performed
         with DNSSEC, then it is recommended to provide this field.
         This list of IP address is used to generate the Public View
         with the proper values for SOA and NS and associated AAAA
         fields.

   - Public Server Management Name:   The FQDN of the management
         interface.  This Management interface designated who the CPE is
         synchronizing its Public View with.





Migault (Ed), et al.      Expires May 10, 2013                 [Page 11]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   - Public Server Management IP addresses:   The list of IP addresses
         associated to the Public Server Management Name.  This field is
         not expected to be filled by the End User, but to be derived
         from the Public Server Management Name with a DNS(SEC) query.

   - Authentication Method:   How the CPE authenticates itself to the
         Public Server.

   - Authentication data:   Associated Data.

   To set a View one needs to have the following information:

   - Homenet Domain Name:   The Domain Name of the zone.

   - Public Server Name (optional):   The Server that are expected to
         host the View.  It is required both to field the SOA, NS and
         associated AAAA as well as to define where the View has to be
         uploaded.  If the View is the Homenet View and the Homenet
         Authoritative Server is hosted on the CPE, then, this
         information is not required.

   - Rules:   Defines specific rules for deriving the View.  Example of
         rule s may be a list of FQDNs or IP addresses that MUST be
         included or removed...

   - DNSSEC Data:  DNSSEC data required to generate the DNSSEC zone.
         This can be the various DNSSEC Keys for example.

   First the CPE MUST reject DNS queries received from the WAN
   Interface.  Then the CPE MUST list the Homenet Views and Public
   Views.  Homenet Views are those without the Public Server Name
   specified and are loaded on the Homenet Authoritative Server.  The
   Homenet Resolving Server is configured as a forwarder for these
   Views.  Public Views are loaded on the Master Public Server, the
   communications between the Master Public Server and the Public
   Servers are secured, with an IPsec authenticated and encrypted
   traffic flow for example.


7.  Position toward Homenet Architecture

   This section positions the Front End Naming Architecture toward the
   Naming recommendation of [I-D.chown-homenet-arch].

   The Front End Naming Architecture has been designed to favor
   unmanaged operations.  Naming configuration is automatically
   performed by the CPE.




Migault (Ed), et al.      Expires May 10, 2013                 [Page 12]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   The Front End Naming Architecture provides the End User a mean to
   assign names to their devices and associate these names to an
   Internet domain.  With traditional naming configuration that sets an
   "search" field for the resolvers, the Front End Naming Architecture
   provides relative naming resolution.  The search field is
   configurable on the DHCPv6 Server hosted on the CPE.

   Homenet devices can be attached in multiple local and Internet name
   spaces.  The Front End Naming Architecture works internally and
   externally depending where the End User is.  With Views, not all
   devices are visible from the Internet.

   The Front End Naming Architecture completely coexists with the
   Internet name services.

   With the Homenet View hosted on the CPE, Name resolution and service
   discovery for reachable devices must continue to function if the
   local network is disconnected from the global Internet.


8.  Security Considerations

   The Front End Naming Architecture described in this document solves
   exposing the CPE's DNS service as a DoS attack vector.

8.1.  Names are less secure than IP addresses

   This document describes how an End User can make his services and
   devices from his Home Network reachable on the Internet with Names
   rather than IP addresses.  This exposes the Home Network to attackers
   since names are expected to provide less randomness than IP
   addresses.  The naming delegation protects the End User's privacy by
   not providing the complete zone of the Home Network to the ISP.
   However, using the DNS with names for the Home Network exposes the
   Home Network and its components to dictionary attacks.  In fact, with
   IP addresses, the Interface Identifier is 64 bit length leading to
   2^64 possibilities for a given subnetwork.  This is not to mention
   that the subnet prefix is also of 64 bit length, thus providing
   another 2^64 possibilities.  On the other hand, names used either for
   the Home Network domain or for the devices present less randomness
   (livebox, router, printer, nicolas, jennifer, ...) and thus exposes
   the devices to dictionary attacks.

8.2.  Names are less volatile than IP addresses

   IP addresses may be used to locate a device, a host or a Service.
   However, Home Networks are not expected to be assigned the same
   Prefix over time.  As a result observing IP addresses provides some



Migault (Ed), et al.      Expires May 10, 2013                 [Page 13]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   ephemeral information about who is accessing the service.  On the
   other hand, Names are not expected to be has volatile as IP
   addresses.  As a result, logging Names, over time, may be more
   valuable that logging IP addresses, especially to profile End User's
   characteristics.

   PTR provides a way to bind an IP address to a Name.  In that sense
   responding to PTR DNS queries may affect the End User's Privacy.  For
   that reason we recommend that End Users may choose to respond or not
   to PTR DNS queries and may return a NXDOMAIN response.

8.3.  DNSSEC is recommended to authenticate DNS hosted data

   The document describes how the Secure Delegation can be set between
   the Delegating DNS Server and the Delegated DNS Server.

   Deploying DNSSEC is recommended since in some cases the information
   stored in the DNS is used by the ISP or an IT departments to grant
   access.  For example some Servers may performed a PTR DNS query to
   grant access based on host names.  With the described Delegating
   Naming Architecture, the ISP or the IT department MUST take into
   consideration that the CPE is outside its area of control.  As such,
   with DNS, DNS responses may be forged, resulting in isolating a
   Service, or not enabling a host to access a service.  ISPs or IT
   department may not base their access policies on PTR or any DNS
   information.  DNSSEC fulfills the DNS lack of trust, and we recommend
   to deploy DNSSEC on CPEs.


9.  IANA Considerations

   This document has no actions for IANA.


10.  Acknowledgment

   The authors wish to thank Ole Troan for pointing out issues with the
   IPv6 routed home concept and placing the scope of this document in a
   wider picture, Mark Townsley for encouragement and injecting a
   healthy debate on the merits of the idea, Ulrik de Bie for providing
   alternative solutions, Paul Mockapetris for pointing out issues of
   the trustworthiness of a reverse lookup, and Christian Jacquenet for
   seeing the value from a Service Provider point of view.


11.  References





Migault (Ed), et al.      Expires May 10, 2013                 [Page 14]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


11.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

11.2.  Informational References

   [I-D.chown-homenet-arch]
              Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
              Networking Architecture for IPv6",
              draft-chown-homenet-arch-01 (work in progress),
              October 2011.






Migault (Ed), et al.      Expires May 10, 2013                 [Page 15]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -01:

   * Added C. Griffiths as co-author.

   * Updated section 5.4 and other sections of draft to update section
   on Hidden Master / Slave functions with CPE as Hidden Master/Homenet
   Server.

   * For next version, address functions of MDNS within Homenet Lan and
   publishing details northbound via Hidden Master.

   -00: First version published.


Authors' Addresses

   Daniel Migault
   Francetelecom - Orange
   38 rue du General Leclerc
   92794 Issy-les-Moulineaux Cedex 9
   France

   Phone: +33 1 45 29 60 52
   Email: mglt.ietf@gmail.com


   Wouter Cloetens
   SoftAtHome
   vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Phone:
   Email: wouter.cloetens@softathome.com













Migault (Ed), et al.      Expires May 10, 2013                 [Page 16]


Internet-Draft  Home Network Front End Naming Delegation   November 2012


   Philippe Lemordant
   Francetelecom - Orange
   2 avenue Pierre Marzin
   22300 Lannion
   France

   Phone: +33 2 96 05 35 11
   Email: philippe.lemordant@orange.com


   Chris Griffiths
   Comcast Cable Communications
   One Comcast Center
   Philadelphia, PA  19103
   US

   Phone:
   Fax:
   Email: chris_griffiths@cable.comcast.com
   URI:   http://www.comcast.com































Migault (Ed), et al.      Expires May 10, 2013                 [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/