| 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 06, 2012 |
IPv6 Home Network Front End Naming Delegation
draft-mglt-homenet-front-end-naming-delegation-01.txt
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.
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/⁠.
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 (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.
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].
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 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.
This section lists and details goals and requirements of Front End Naming Architecture.
This section describes the Front End Naming Architecture and defines the notations used in this document.
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:
The other involved entities are:
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).
+-------------------+ 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
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.
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.
The Homenet Authoritative Server may be authoritative for multiple Homenet Domain Names and each Homenet Domain Name may be associated with multiple views.
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.
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.
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:
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.
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. For these reasons, we recommend using IPsec.
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.
In this document, we considered the Public and Homenet View. Each of these Views may have additional views.
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:
To set a View one needs to have the following information:
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.
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.
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.
The Front End Naming Architecture described in this document solves exposing the CPE's DNS service as a DoS attack vector.
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.
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 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.
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.
This document has no actions for IANA.
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.
| [I-D.chown-homenet-arch] | Arkko, J, Chown, T, Weil, J and O Troan, "Home Networking Architecture for IPv6", Internet-Draft draft-chown-homenet-arch-01, October 2011. |
[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.