draft-ietf-homenet-naming-architecture-dhc-options-01.txt   draft-ietf-homenet-naming-architecture-dhc-options-02.txt 
HOMENET D. Migault (Ed) HOMENET D. Migault (Ed)
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track W. Cloetens Intended status: Standards Track W. Cloetens
Expires: August 21, 2015 SoftAtHome Expires: November 20, 2015 SoftAtHome
C. Griffiths C. Griffiths
Dyn Dyn
R. Weber R. Weber
Nominum Nominum
February 17, 2015 May 19, 2015
DHCP Options for Homenet Naming Architecture DHCP Options for Homenet Naming Architecture
draft-ietf-homenet-naming-architecture-dhc-options-01.txt draft-ietf-homenet-naming-architecture-dhc-options-02.txt
Abstract Abstract
CPEs are usually constraint devices with reduced network and CPU CPEs are usually constraint devices with reduced network and CPU
capacities. As such, a CPE hosting on the Internet the authoritative capacities. As such, a CPE hosting on the Internet the authoritative
naming service for its home network may become vulnerable to resource naming service for its home network may become vulnerable to resource
exhaustion attacks. One way to avoid exposing CPE is to outsource exhaustion attacks. One way to avoid exposing CPE is to outsource
the authoritative service to a third party. This third party can be the authoritative service to a third party. This third party can be
the ISP or any other independent third party. the ISP or any other independent third party.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2015. This Internet-Draft will expire on November 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Architecture and DHCP Options Overview . . . . . . . . . 7 4.1. Architecture and DHCP Options Overview . . . . . . . . . 7
4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 10 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 10
4.3. Master / Slave Synchronization versus DNS Update . . . . 11 4.3. Primary / Secondary Synchronization versus DNS Update . . 11
5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11 5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11
5.1. CPE Master / Slave Synchronization Configurations . . . . 11 5.1. CPE Primary / Secondary Synchronization Configurations . 11
5.1.1. CPE / Public Authoritative Name Server Set . . . . . 12 5.1.1. CPE / Public Authoritative Name Server Set . . . . . 12
5.1.2. CPE / Reverse Public Authoritative Name Server Set . 12 5.1.2. CPE / Reverse Public Authoritative Name Server Set . 12
5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12 5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12
5.2.1. DNS Homenet Zone Template . . . . . . . . . . . . . . 12 5.2.1. DNS Homenet Zone Template . . . . . . . . . . . . . . 12
5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 13 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 13
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13
6.1. Security Field . . . . . . . . . . . . . . . . . . . . . 14 6.1. Security Field . . . . . . . . . . . . . . . . . . . . . 14
6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14
6.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 15 6.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 15
6.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 15 6.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 16
6.5. DHCP Public Authoritative Name Server Set Option . . . . 16 6.5. DHCP Public Authoritative Name Server Set Option . . . . 16
6.6. DHCP Reverse Public Authoritative Name Server Set Option 17 6.6. DHCP Reverse Public Authoritative Name Server Set Option 17
7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 18 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 18
7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 19 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 19
7.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 19 7.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19 9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19
9.2. Channel between the CPE and ISP DHCP Server MUST be 9.2. Channel between the CPE and ISP DHCP Server MUST be
skipping to change at page 3, line 46 skipping to change at page 3, line 46
home network. home network.
- DNS Homenet Zone: is the DNS zone associated to the home network. - DNS Homenet Zone: is the DNS zone associated to the home network.
This zone is set by the CPE and essentially contains the This zone is set by the CPE and essentially contains the
bindings between names and IP addresses of the nodes of the bindings between names and IP addresses of the nodes of the
home network. In this document, the CPE does neither perform home network. In this document, the CPE does neither perform
any DNSSEC management operations such as zone signing nor any DNSSEC management operations such as zone signing nor
provide an authoritative service for the zone. Both are provide an authoritative service for the zone. Both are
delegated to the Public Authoritative Server. The CPE delegated to the Public Authoritative Server. The CPE
synchronizes the DNS Homenet Zone with the Public Authoritative synchronizes the DNS Homenet Zone with the Public Authoritative
Server via a hidden master / slave architecture. The Public Server via a hidden primary / secondary architecture. The
Authoritative Server might use specific servers for the Public Authoritative Server might use specific servers for the
synchronization of the DNS Homenet Zone: the Public synchronization of the DNS Homenet Zone: the Public
Authoritative Name Server Set. Authoritative Name Server Set.
- DNS Homenet Zone Template: The template used as a basis to - DNS Homenet Zone Template: The template used as a basis to
generate the DNS Homenet Zone. generate the DNS Homenet Zone.
- DNS Template Server: The DNS server that hosts the DNS Homenet - DNS Template Server: The DNS server that hosts the DNS Homenet
Zone Template. Zone Template.
- DNS Homenet Reverse Zone: The reverse zone file associated to the - DNS Homenet Reverse Zone: The reverse zone file associated to the
DNS Homenet Zone. DNS Homenet Zone.
- Public Authoritative Master(s): are the visible name server - Public Authoritative Primary(ies): are the visible name server
hosting the DNS Homenet Zone. End users' resolutions for the hosting the DNS Homenet Zone. End users' resolutions for the
Homenet Domain are sent to this server, and this server is a Homenet Domain are sent to this server, and this server is a
master for the zone. primary for the zone.
- Public Authoritative Name Server Set: is the server the CPE - Public Authoritative Name Server Set: is the server the CPE
synchronizes the DNS Homenet Zone. It is configured as a slave synchronizes the DNS Homenet Zone. It is configured as a
and the CPE acts as master. The CPE sends information so the secondary and the CPE acts as primary. The CPE sends
DNSSEC zone can be set and served. information so the DNSSEC zone can be set and served.
- Reverse Public Authoritative Master(s): are the visible name - Reverse Public Authoritative Primary(ies): are the visible name
server hosting the DNS Homenet Reverse Zone. End users' server hosting the DNS Homenet Reverse Zone. End users'
resolutions for the Homenet Domain are sent to this server, and resolutions for the Homenet Domain are sent to this server, and
this server is a master for the zone. this server is a primary for the zone.
- Reverse Public Authoritative Name Server Set: is the server the - Reverse Public Authoritative Name Server Set: is the server the
CPE synchronizes the DNS Homenet Reverse Zone. It is CPE synchronizes the DNS Homenet Reverse Zone. It is
configured as a slave and the CPE acts as master. The CPE configured as a secondary and the CPE acts as primary. The CPE
sends information so the DNSSEC zone can be set and served. sends information so the DNSSEC zone can be set and served.
3. Introduction 3. Introduction
CPEs are usually constraint devices with reduced network and CPU CPEs are usually constraint devices with reduced network and CPU
capacities. As such, a CPE hosting on the Internet the authoritative capacities. As such, a CPE hosting on the Internet the authoritative
naming service for its home network may become vulnerable to resource naming service for its home network may become vulnerable to resource
exhaustion attacks. One way to avoid exposing CPE is to outsource exhaustion attacks. One way to avoid exposing CPE is to outsource
the authoritative service to a third party. This third party can be the authoritative service to a third party. This third party can be
the ISP or any other independent third party. the ISP or any other independent third party.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
When the CPE is plugged, the DHCP Options described in the document When the CPE is plugged, the DHCP Options described in the document
enable the CPE: enable the CPE:
- 1. To build the DNS Homenet Zone: Building the DNS Homenet Zone - 1. To build the DNS Homenet Zone: Building the DNS Homenet Zone
requires filling the zone with appropriated bindings likes name requires filling the zone with appropriated bindings likes name
/ IP addresses of the different devices in the home networks. / IP addresses of the different devices in the home networks.
Such information can be provided for example by the DHCP Server Such information can be provided for example by the DHCP Server
hosted on the CPE. On the other hand, it also requires hosted on the CPE. On the other hand, it also requires
configuration parameters like the name of the Registered Domain configuration parameters like the name of the Registered Domain
Name associated to the home network or the Public Authoritative Name associated to the home network or the Public Authoritative
Master(s) the DNS Homenet Zone is outsourced to. These Primary(ies) the DNS Homenet Zone is outsourced to. These
configuration parameters are stored in the DNS Homenet Zone configuration parameters are stored in the DNS Homenet Zone
Template. This document describes the DHCP Zone Template Template. This document describes the DHCP Zone Template
Option. This option carries a DNS Homenet Zone Template FQDN. Option. This option carries a DNS Homenet Zone Template FQDN.
In order to retrieve the DNS Homenet Zone Template, the CPE In order to retrieve the DNS Homenet Zone Template, the CPE
sends a query of type AXFR [RFC1034] [RFC5936]for the DNS sends a query of type AXFR [RFC1034] [RFC5936]for the DNS
Homenet Zone Template FQDN. Homenet Zone Template FQDN.
- 2. To upload the DNS(SEC) Homenet Zone to the appropriated server: - 2. To upload the DNS(SEC) Homenet Zone to the appropriated server:
This server is designated as the Public Authoritative Name This server is designated as the Public Authoritative Name
Server Set. It is in charge of publishing the DNS(SEC) Homenet Server Set. It is in charge of publishing the DNS(SEC) Homenet
Zone on the Public Authoritative Master(s). This document Zone on the Public Authoritative Primary(ies). This document
describes the DHCP Public Authoritative Name Server Set Option describes the DHCP Public Authoritative Name Server Set Option
that provides the FQDN of the appropriated server. Note that, that provides the FQDN of the appropriated server. Note that,
in the document we do not consider whether the DNS(SEC) Homenet in the document we do not consider whether the DNS(SEC) Homenet
Zone is signed or not and if signed who signs it. Such Zone is signed or not and if signed who signs it. Such
questions are out of the scope of the current document. questions are out of the scope of the current document.
- 3. To upload the DNS Homenet Reverse Zone to the appropriated - 3. To upload the DNS Homenet Reverse Zone to the appropriated
server: This server is designated as the Reverse Public server: This server is designated as the Reverse Public
Authoritative Name Server Set. It is in charge of publishing Authoritative Name Server Set. It is in charge of publishing
the DNS Homenet Reverse Zone on the Reverse Public the DNS Homenet Reverse Zone on the Reverse Public
Authoritative Master(s). This document describes the DHCP Authoritative Primary(ies). This document describes the DHCP
Reverse Public Authoritative Name Server Set Option that Reverse Public Authoritative Name Server Set Option that
provides the FQDN of the appropriated server. Similarly to provides the FQDN of the appropriated server. Similarly to
item 2., we do not consider in this document if the DNS Homenet item 2., we do not consider in this document if the DNS Homenet
Reverse Zone is signed or not, and if signed who signs it. Reverse Zone is signed or not, and if signed who signs it.
- 4. To provide authentication credential (a public key) to the DHCP - 4. To provide authentication credential (a public key) to the DHCP
Server: Information stored in the DNS Homenet Zone Template, Server: Information stored in the DNS Homenet Zone Template,
the DNS(SEC) Homenet Zone and DNS Homenet Reverse Zone belongs the DNS(SEC) Homenet Zone and DNS Homenet Reverse Zone belongs
to the CPE, and only the CPE should be able to update or upload to the CPE, and only the CPE should be able to update or upload
these zones. To authenticate the CPE, this document defines these zones. To authenticate the CPE, this document defines
skipping to change at page 9, line 35 skipping to change at page 9, line 35
+--------------------------------+ +--------------------------------+
Figure 1: Protocol Overview Figure 1: Protocol Overview
As described above, the CPE is likely to interact with various DNS As described above, the CPE is likely to interact with various DNS
content. This section is focused on DNS Data the CPE is likely to content. This section is focused on DNS Data the CPE is likely to
update. More specifically, the CPE is likely to update the: update. More specifically, the CPE is likely to update the:
- DNS Homenet Zone Template: may be updated by the CPE if the - DNS Homenet Zone Template: may be updated by the CPE if the
configuration of the zone may be changed. This can include configuration of the zone may be changed. This can include
additional Public Authoritative Master(s), a different additional Public Authoritative Primary(ies), a different
Registered Homenet Domain as the one initially proposed, or a Registered Homenet Domain as the one initially proposed, or a
redirection to another domain. redirection to another domain.
- DNS Homenet Reverse Zone: may be updated every time a new device - DNS Homenet Reverse Zone: may be updated every time a new device
is connected or dis-connected. is connected or dis-connected.
- DNS Homenet Zone: may be updated every time a new device is - DNS Homenet Zone: may be updated every time a new device is
connected, dis-connected. connected, dis-connected.
In fact, the CPE must be able to perform these updates in a secure In fact, the CPE must be able to perform these updates in a secure
manner. There are multiple ways to secure a DNS transaction and this manner. There are multiple ways to secure a DNS transaction and this
document considers two mechanisms to update a DNS Data (nsupdate and document considers two mechanisms to update a DNS Data (nsupdate and
master/slave synchronization). Which security mechanism to use to primary/secondary synchronization). Which security mechanism to use
secure a DNS transaction depends on the expected security to secure a DNS transaction depends on the expected security
(authentication of the authoritative server, mutual authentication, (authentication of the authoritative server, mutual authentication,
confidentiality...). The expected security may also depends on the confidentiality...). The expected security may also depends on the
kind of transaction performed by the CPE. Section 4.2 describes the kind of transaction performed by the CPE. Section 4.2 describes the
different security mechanisms considered in the document as well as different security mechanisms considered in the document as well as
their respective goals. Which mechanism to use to update the DNS their respective goals. Which mechanism to use to update the DNS
Data depends on the kind of update. Frequency of the update, size of Data depends on the kind of update. Frequency of the update, size of
the DNS Data to update may be some useful criteria. Section 4.3 the DNS Data to update may be some useful criteria. Section 4.3
positions the nsupdate and master/slave synchronization mechanisms. positions the nsupdate and primary/secondary synchronization
mechanisms.
4.2. Mechanisms Securing DNS Transactions 4.2. Mechanisms Securing DNS Transactions
Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] /
[RFC6347] may be used to secure DNS transactions between the CPE and [RFC6347] may be used to secure DNS transactions between the CPE and
the DNS servers. This document restricts the scope of security the DNS servers. This document restricts the scope of security
protocols to those that have been designed specifically for DNS. protocols to those that have been designed specifically for DNS.
This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that
authenticates and provides integrity protection of DNS data, TSIG authenticates and provides integrity protection of DNS data, TSIG
[RFC2845], [RFC2930] that use a shared secret to secure a transaction [RFC2845], [RFC2930] that use a shared secret to secure a transaction
skipping to change at page 11, line 8 skipping to change at page 11, line 10
the DNSSEC signature checks. If signature check fails, it MUST the DNSSEC signature checks. If signature check fails, it MUST
reject the response. If the signature check succeeds, the CPE reject the response. If the signature check succeeds, the CPE
removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before
building the DNS Homenet Zone. In fact, these DNSSEC related fields building the DNS Homenet Zone. In fact, these DNSSEC related fields
are associated to the DNS Homenet Zone Template and not the DNS are associated to the DNS Homenet Zone Template and not the DNS
Homenet Zone. Homenet Zone.
Any update exchange should use SIG(0) or TSIG to authenticate the Any update exchange should use SIG(0) or TSIG to authenticate the
exchange. exchange.
4.3. Master / Slave Synchronization versus DNS Update 4.3. Primary / Secondary Synchronization versus DNS Update
As updates only concern DNS zones, this document only considers DNS As updates only concern DNS zones, this document only considers DNS
update mechanisms such as DNS update [RFC2136] [RFC3007] or a master update mechanisms such as DNS update [RFC2136] [RFC3007] or a
/ slave synchronization. primary / secondary synchronization.
The DNS Homenet Zone Template can only be updated with DNS update. The DNS Homenet Zone Template can only be updated with DNS update.
The reason is that the DNS Homenet Zone Template contains static The reason is that the DNS Homenet Zone Template contains static
configuration data that is not expected to evolve over time. configuration data that is not expected to evolve over time.
The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated
either with DNS update or using a master / slave synchronization. As either with DNS update or using a primary / secondary
these zones may be large, with frequent updates, we recommend to use synchronization. As these zones may be large, with frequent updates,
the master / slave architecture as described in we recommend to use the primary / secondary architecture as described
[I-D.ietf-homenet-front-end-naming-delegation]. The master / slave in [I-D.ietf-homenet-front-end-naming-delegation]. The primary /
mechanism is preferred as it better scales and avoids DoS attacks: secondary mechanism is preferred as it better scales and avoids DoS
First the master notifies the slave the zone must be updated, and attacks: First the primary notifies the secondary the zone must be
leaves the slave to proceed to the update when possible. Then, the updated, and leaves the secondary to proceed to the update when
NOTIFY message sent by the master is a small packet that is less possible. Then, the NOTIFY message sent by the primary is a small
likely to load the slave. At last, the AXFR query performed by the packet that is less likely to load the secondary. At last, the AXFR
slave is a small packet sent over TCP (section 4.2 [RFC5936]) which query performed by the secondary is a small packet sent over TCP
makes unlikely the slave to perform reflection attacks with a forged (section 4.2 [RFC5936]) which makes unlikely the secondary to perform
NOTIFY. On the other hand, DNS updates can use UDP, packets require reflection attacks with a forged NOTIFY. On the other hand, DNS
more processing then a NOTIFY, and they do not provide the server the updates can use UDP, packets require more processing then a NOTIFY,
opportunity to post-pone the update. and they do not provide the server the opportunity to post-pone the
update.
5. CPE Configuration 5. CPE Configuration
5.1. CPE Master / Slave Synchronization Configurations 5.1. CPE Primary / Secondary Synchronization Configurations
The master / slave architecture is described in The primary / secondary architecture is described in
[I-D.ietf-homenet-front-end-naming-delegation]. The CPE is [I-D.ietf-homenet-front-end-naming-delegation]. The CPE is
configured as a master whereas the DNS Server is configured as a configured as a primary whereas the DNS Server is configured as a
slave. The DNS Server represents the Public Authoritative Name secondary. The DNS Server represents the Public Authoritative Name
Server Set or the Reverse Public Authoritative Name Server Set. Server Set or the Reverse Public Authoritative Name Server Set.
When the CPE is plugged its IP address may be unknown to the slave. When the CPE is plugged its IP address may be unknown to the
The section details how the CPE or master communicate the necessary secondary. The section details how the CPE or primary communicate
information to set up the slave. the necessary information to set up the secondary.
In order to set the master / slave configuration, both master and In order to set the primary / secondary configuration, both primary
slaves must agree on 1) the zone to be synchronized, 2) the IP and secondaries must agree on 1) the zone to be synchronized, 2) the
address and ports used by both master and slave. IP address and ports used by both primary and secondary.
5.1.1. CPE / Public Authoritative Name Server Set 5.1.1. CPE / Public Authoritative Name Server Set
The CPE knows the zone to be synchronized by reading the Registered The CPE knows the zone to be synchronized by reading the Registered
Homenet Domain in the DNS Homenet Zone Template provided by the DHCP Homenet Domain in the DNS Homenet Zone Template provided by the DHCP
Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of
the slave is provided by the DHCP Public Authoritative Name Server the secondary is provided by the DHCP Public Authoritative Name
Set Option (OPTION_NAME_SERVER_SET). Server Set Option (OPTION_NAME_SERVER_SET).
The Public Authoritative Name Server Set has been configured with the The Public Authoritative Name Server Set has been configured with the
Registered Homenet Domain and the Public Key that identifies the CPE. Registered Homenet Domain and the Public Key that identifies the CPE.
The only thing missing is the IP address of the CPE. This IP address The only thing missing is the IP address of the CPE. This IP address
is provided by the CPE by sending a NOTIFY [RFC1996]. is provided by the CPE by sending a NOTIFY [RFC1996].
When the CPE has built its DNS Homenet Zone, it sends a NOTIFY When the CPE has built its DNS Homenet Zone, it sends a NOTIFY
message to the Public Authoritative Name Server Sets. Upon receiving message to the Public Authoritative Name Server Sets. Upon receiving
the NOTIFY message, the slave reads the Registered Homenet Domain and the NOTIFY message, the secondary reads the Registered Homenet Domain
checks the NOTIFY is sent by the authorized master. This can be done and checks the NOTIFY is sent by the authorized primary. This can be
using the shared secret (TSIG) or the public key (SIG(0)). Once the done using the shared secret (TSIG) or the public key (SIG(0)). Once
NOTIFY has been authenticated, the Public Authoritative Name Server the NOTIFY has been authenticated, the Public Authoritative Name
Sets might consider the source IP address of the NOTIFY query to Server Sets might consider the source IP address of the NOTIFY query
configure the masters attributes. to configure the primaries attributes.
5.1.2. CPE / Reverse Public Authoritative Name Server Set 5.1.2. CPE / Reverse Public Authoritative Name Server Set
The CPE knows the zone to be synchronized by looking at its assigned The CPE knows the zone to be synchronized by looking at its assigned
prefix. The IP address of the slave is provided by the DHCP Reverse prefix. The IP address of the secondary is provided by the DHCP
Public Authoritative Name Server Set Option Reverse Public Authoritative Name Server Set Option
(OPTION_REVERSE_NAME_SERVER_SET). (OPTION_REVERSE_NAME_SERVER_SET).
Configuration of the slave is performed as illustrated in Configuration of the secondary is performed as illustrated in
Section 5.1.1. Section 5.1.1.
5.2. CPE DNS Data Handling and Update Policies 5.2. CPE DNS Data Handling and Update Policies
5.2.1. DNS Homenet Zone Template 5.2.1. DNS Homenet Zone Template
The DNS Homenet Zone Template contains at least the related fields of The DNS Homenet Zone Template contains at least the related fields of
the Public Authoritative Master(s) as well as the Homenet Registered the Public Authoritative Primary(ies) as well as the Homenet
Domain, that is SOA, and NS fields. This template might be generated Registered Domain, that is SOA, and NS fields. This template might
automatically by the owner of the DHCP Server. For example, an ISP be generated automatically by the owner of the DHCP Server. For
might provide a default Homenet Registered Domain as well as default example, an ISP might provide a default Homenet Registered Domain as
Public Authoritative Master(s). This default settings should provide well as default Public Authoritative Primary(ies). This default
the CPE the necessary pieces of information to set the homenet naming settings should provide the CPE the necessary pieces of information
architecture. to set the homenet naming architecture.
If the DNS Homenet Zone Template is not subject to modifications or If the DNS Homenet Zone Template is not subject to modifications or
updates, the owner of the template might only use DNSSEC to enable updates, the owner of the template might only use DNSSEC to enable
integrity check. integrity check.
The DNS Homenet Zone Template might be subject to modification by the The DNS Homenet Zone Template might be subject to modification by the
CPE. The advantage of using the standard DNS zone format is that CPE. The advantage of using the standard DNS zone format is that
standard DNS update mechanism can be used to perform updates. These standard DNS update mechanism can be used to perform updates. These
updates might be accepted or rejected by the owner of the DNS Homenet updates might be accepted or rejected by the owner of the DNS Homenet
Zone Template. Policies that defines what is accepted or rejected is Zone Template. Policies that defines what is accepted or rejected is
skipping to change at page 15, line 13 skipping to change at page 15, line 13
Section 4.3 for more details. Section 4.3 for more details.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Update | | Update |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: Update Field Figure 3: Update Field
- Master / Slave (Bit 0): indicates, when set to 1, that DNS Server - Primary / Secondary (Bit 0): indicates, when set to 1, that DNS
supports data synchronization using a Master / Slave mechanism. Server supports data synchronization using a Primary /
Secondary mechanism.
- DNS Update (Bit 1): indicates, when set to 1, that DNS Server - DNS Update (Bit 1): indicates, when set to 1, that DNS Server
supports data synchronization using DNS Updates. supports data synchronization using DNS Updates.
- Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and
ignored by the DHCP Client. ignored by the DHCP Client.
6.3. DHCP Public Key Option 6.3. DHCP Public Key Option
The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public
skipping to change at page 16, line 48 skipping to change at page 17, line 5
- Zone Template FQDN FQDN (variable): the FQDN of the DNS server - Zone Template FQDN FQDN (variable): the FQDN of the DNS server
hosting the DNS Homenet Zone Template. hosting the DNS Homenet Zone Template.
6.5. DHCP Public Authoritative Name Server Set Option 6.5. DHCP Public Authoritative Name Server Set Option
The DHCP Public Authoritative Name Server Set Option The DHCP Public Authoritative Name Server Set Option
(OPTION_NAME_SERVER_SET) provides information so the CPE can upload (OPTION_NAME_SERVER_SET) provides information so the CPE can upload
the DNS Homenet Zone to the Public Authoritative Name Server Set. the DNS Homenet Zone to the Public Authoritative Name Server Set.
Finally, the option provides the security mechanisms that are Finally, the option provides the security mechanisms that are
available to perform the upload. The upload is performed via a DNS available to perform the upload. The upload is performed via a DNS
master / slave architecture or DNS updates. primary / secondary architecture or DNS updates.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NAME_SERVER_SET | option-len | | OPTION_NAME_SERVER_SET | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | Update | Server / | Security | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+ |
skipping to change at page 17, line 45 skipping to change at page 17, line 47
- Public Authoritative Name Server Set FQDN (variable): the FQDN of - Public Authoritative Name Server Set FQDN (variable): the FQDN of
the Public Authoritative Name Server Set. the Public Authoritative Name Server Set.
6.6. DHCP Reverse Public Authoritative Name Server Set Option 6.6. DHCP Reverse Public Authoritative Name Server Set Option
The DHCP Reverse Public Authoritative Name Server Set Option The DHCP Reverse Public Authoritative Name Server Set Option
(OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can (OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can
upload the DNS Homenet Zone to the Public Authoritative Name Server upload the DNS Homenet Zone to the Public Authoritative Name Server
Set. The option provides the security mechanisms that are available Set. The option provides the security mechanisms that are available
to perform the upload. The upload is performed via a DNS master / to perform the upload. The upload is performed via a DNS primary /
slave architecture or DNS updates. secondary architecture or DNS updates.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REVERSE_NAME_SERVER_SET| option-len | | OPTION_REVERSE_NAME_SERVER_SET| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | Update | Server / | Security | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+ |
skipping to change at page 22, line 15 skipping to change at page 22, line 15
11.2. Informational References 11.2. Informational References
[I-D.andrews-dnsop-pd-reverse] [I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd- zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013. reverse-02 (work in progress), November 2013.
[I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Cloetens, W., Griffiths, C., and R. Weber, Migault, D., Cloetens, W., Griffiths, C., and R. Weber,
"Outsourcing Home Network Authoritative Naming Service", "Outsourcing Home Network Authoritative Naming Service",
draft-ietf-homenet-front-end-naming-delegation-00 (work in draft-ietf-homenet-front-end-naming-delegation-02 (work in
progress), September 2014. progress), May 2015.
[I-D.sury-dnsext-cname-dname] [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury- Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010. dnsext-cname-dname-00 (work in progress), April 2010.
Appendix A. Scenarios and impact on the End User Appendix A. Scenarios and impact on the End User
This section details various scenarios and discuss their impact on This section details various scenarios and discuss their impact on
the end user. the end user.
A.1. Base Scenario A.1. Base Scenario
The base scenario is the one described in Section 4. It is typically The base scenario is the one described in Section 4. It is typically
the one of an ISP that manages the DHCP Server, and all DNS servers. the one of an ISP that manages the DHCP Server, and all DNS servers.
The end user subscribes to the ISP (foo), and at subscription time The end user subscribes to the ISP (foo), and at subscription time
registers for example.foo as its Registered Homenet Domain registers for example.foo as its Registered Homenet Domain
example.foo. Since the ISP knows the Registered Homenet Domain and example.foo. Since the ISP knows the Registered Homenet Domain and
the Public Authoritative Master(s) the ISP is able to build the DNS the Public Authoritative Primary(ies) the ISP is able to build the
Homenet Zone Template. DNS Homenet Zone Template.
The ISP manages the DNS Template Server, so it is able to load the The ISP manages the DNS Template Server, so it is able to load the
DNS Homenet Zone Template on the DNS Template Server. DNS Homenet Zone Template on the DNS Template Server.
When the CPE is plugged (at least the first time), it provides its When the CPE is plugged (at least the first time), it provides its
Public Key to the DHCP Server. In this scenario, the DHCP Server and Public Key to the DHCP Server. In this scenario, the DHCP Server and
the DNS Servers are managed by the ISP so the DHCP Server can provide the DNS Servers are managed by the ISP so the DHCP Server can provide
authentication credentials of the CPE to enable secure authenticated authentication credentials of the CPE to enable secure authenticated
transaction between the CPE and these DNS servers. More transaction between the CPE and these DNS servers. More
specifically, credentials are provided to: specifically, credentials are provided to:
- Public Authoritative Name Server Set - Public Authoritative Name Server Set
- Reverse Public Authoritative Name Server Set - Reverse Public Authoritative Name Server Set
- DNS Template Server - DNS Template Server
The CPE can update the zone using DNS update or a master / slave The CPE can update the zone using DNS update or a primary / secondary
configuration in a secure way. configuration in a secure way.
The main advantage of this scenario is that the naming architecture The main advantage of this scenario is that the naming architecture
is configured automatically and transparently for the end user. is configured automatically and transparently for the end user.
The drawbacks are that the end user uses a Registered Homenet Domain The drawbacks are that the end user uses a Registered Homenet Domain
managed by the ISP and that it relies on the ISP naming managed by the ISP and that it relies on the ISP naming
infrastructure. infrastructure.
A.2. Third Party Registered Homenet Domain A.2. Third Party Registered Homenet Domain
skipping to change at page 24, line 6 skipping to change at page 24, line 6
inconvenient is when the DNS Servers provided by the ISPs results in inconvenient is when the DNS Servers provided by the ISPs results in
high latency. high latency.
A.3. Third Party DNS Infrastructure A.3. Third Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario considers that the end user uses example.com as a
Registered Homenet Domain, and does not want to rely on the Registered Homenet Domain, and does not want to rely on the
authoritative servers provided by the ISP. authoritative servers provided by the ISP.
In this section we limit the outsourcing to the Public Authoritative In this section we limit the outsourcing to the Public Authoritative
Name Server Set and Public Authoritative Master(s) to a third party. Name Server Set and Public Authoritative Primary(ies) to a third
All other DNS Servers DNS Template Server, Reverse Public party. All other DNS Servers DNS Template Server, Reverse Public
Authoritative Master(s) and Reverse Public Authoritative Name Server Authoritative Primary(ies) and Reverse Public Authoritative Name
Set remain managed by the ISP. The reason we consider that Reverse Server Set remain managed by the ISP. The reason we consider that
Public Authoritative Masters(s) and Reverse Public Authoritative Name Reverse Public Authoritative Primary(ies) and Reverse Public
Server Set remains managed by the ISP are that the prefix is managed Authoritative Name Server Set remains managed by the ISP are that the
by the ISP, so outsourcing these resources requires some redirection prefix is managed by the ISP, so outsourcing these resources requires
agreement with the ISP. More specifically the ISP will need to some redirection agreement with the ISP. More specifically the ISP
configure the redirection on one of its Reverse DNS Servers. That will need to configure the redirection on one of its Reverse DNS
said, outsourcing these resources is similar as outsourcing Public Servers. That said, outsourcing these resources is similar as
Authoritative Name Server Set and Public Authoritative Master(s) to a outsourcing Public Authoritative Name Server Set and Public
third party. Similarly, the DNS Template Server can be easily Authoritative Primary(ies) to a third party. Similarly, the DNS
outsourced as detailed in this section Template Server can be easily outsourced as detailed in this section
Outsourcing Public Authoritative Name Server Set and Public Outsourcing Public Authoritative Name Server Set and Public
Authoritative Master(s) requires: Authoritative Primary(ies) requires:
- 1) Updating the DNS Homenet Zone Template: this can be easily done - 1) Updating the DNS Homenet Zone Template: this can be easily done
as detailed in Section 4.3 as the DNS Template Server is still as detailed in Section 4.3 as the DNS Template Server is still
managed by the ISP. Such modification can be performed once by managed by the ISP. Such modification can be performed once by
any CPE. Once this modification has been performed, the CPE any CPE. Once this modification has been performed, the CPE
can be changed, the Public Key of the CPE may be changed, this can be changed, the Public Key of the CPE may be changed, this
does not need to be done another time. One can imagine a GUI does not need to be done another time. One can imagine a GUI
on the CPE asking the end user to fill the field with on the CPE asking the end user to fill the field with
Registered Homenet Domain, optionally Public Authoritative Registered Homenet Domain, optionally Public Authoritative
Master(s), with a button "Configure DNS Homenet Zone Template". Primary(ies), with a button "Configure DNS Homenet Zone
Template".
- 2) Updating the DHCP Server Information. In fact the Reverse - 2) Updating the DHCP Server Information. In fact the Reverse
Public Authoritative Name Server Set returned by the ISP is Public Authoritative Name Server Set returned by the ISP is
modified. One can imagine a GUI interface that enables the end modified. One can imagine a GUI interface that enables the end
user to modify its profile parameters. Again, this user to modify its profile parameters. Again, this
configuration update is done once-for-ever. configuration update is done once-for-ever.
- 3) Upload the authentication credential of the CPE, that is the - 3) Upload the authentication credential of the CPE, that is the
Public Key of the CPE, to the third party. Unless we use Public Key of the CPE, to the third party. Unless we use
specific mechanisms, like communication between the DHCP Server specific mechanisms, like communication between the DHCP Server
skipping to change at page 25, line 50 skipping to change at page 25, line 50
to provide naming resolution in case of network disruption. to provide naming resolution in case of network disruption.
Secondly, suppose the CPE is connected to multiple ISP with a single Secondly, suppose the CPE is connected to multiple ISP with a single
Registered Homenet Domain. In this case, the one party is chosen to Registered Homenet Domain. In this case, the one party is chosen to
host the Registered Homenet Domain. This entity may be one of the host the Registered Homenet Domain. This entity may be one of the
ISP or a third party. Note that having multiple ISPs can be ISP or a third party. Note that having multiple ISPs can be
motivated for bandwidth aggregation, or connectivity fail-over. In motivated for bandwidth aggregation, or connectivity fail-over. In
the case of connectivity fail-over, the fail-over concerns the access the case of connectivity fail-over, the fail-over concerns the access
network and a failure of the access network may not impact the core network and a failure of the access network may not impact the core
network where the Public Authoritative Name Server Set and Public network where the Public Authoritative Name Server Set and Public
Masters are hosted. In that sense, choosing one of the ISP even in a Authoritative Primaries are hosted. In that sense, choosing one of
scenario of multiple ISPs may make sense. However, for sake of the ISP even in a scenario of multiple ISPs may make sense. However,
simplicity, this scenario assumes that a third party has be chosen to for sake of simplicity, this scenario assumes that a third party has
host the Registered Homenet Domain. The DNS settings for each ISP is be chosen to host the Registered Homenet Domain. The DNS settings
described in Appendix A.2 and Appendix A.3. With the configuration for each ISP is described in Appendix A.2 and Appendix A.3. With the
described in Appendix A.2, the CPE is expect to be able to handle configuration described in Appendix A.2, the CPE is expect to be able
multiple Homenet Registered Domain, as the third party redirect to to handle multiple Homenet Registered Domain, as the third party
one of the ISPs Servers. With the configuration described in redirect to one of the ISPs Servers. With the configuration
Appendix A.3, DNS zone are hosted and maintained by the third party. described in Appendix A.3, DNS zone are hosted and maintained by the
A single DNS(SEC) Homenet Zone is built and maintained by the CPE. third party. A single DNS(SEC) Homenet Zone is built and maintained
This latter configuration is likely to match most CPE by the CPE. This latter configuration is likely to match most CPE
implementations. implementations.
The protocol and DHCP Options described in this document are fully The protocol and DHCP Options described in this document are fully
compatible with a CPE connected to multiple ISPs. To configure or compatible with a CPE connected to multiple ISPs. To configure or
not and how to configure the CPE depends on the CPE facilities. not and how to configure the CPE depends on the CPE facilities.
Appendix A.1 and Appendix A.2 require the CPE to handle multiple Appendix A.1 and Appendix A.2 require the CPE to handle multiple
Registered Homenet Domain, whereas Appendix A.3 does not have such Registered Homenet Domain, whereas Appendix A.3 does not have such
requirement. requirement.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-05: changing Master to Primary, Slave to Secondary
-04: Working Version Major modifications are: -04: Working Version Major modifications are:
- Re-structuring the draft: description and comparison of update and - Re-structuring the draft: description and comparison of update and
security mechanisms have been intergrated into the Overview security mechanisms have been intergrated into the Overview
section. a Configuration section has been created to describe section. a Configuration section has been created to describe
both configuration and corresponding behavior of the CPE. both configuration and corresponding behavior of the CPE.
- Adding Ports parameters: Server Set can configure a port. The - Adding Ports parameters: Server Set can configure a port. The
Port Server parameter have been added in the DHCP Option Port Server parameter have been added in the DHCP Option
payloads because middle boxes may not be configured to let port payloads because middle boxes may not be configured to let port
skipping to change at page 27, line 35 skipping to change at page 27, line 39
-00: First version published in dhc WG. -00: First version published in dhc WG.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Email: mglt.ietf@gmail.com Email: daniel.migault@ericsson.com
Wouter Cloetens Wouter Cloetens
SoftAtHome SoftAtHome
vaartdijk 3 701 vaartdijk 3 701
3018 Wijgmaal 3018 Wijgmaal
Belgium Belgium
Email: wouter.cloetens@softathome.com Email: wouter.cloetens@softathome.com
Chris Griffiths Chris Griffiths
Dyn Dyn
 End of changes. 45 change blocks. 
106 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/