draft-ietf-homenet-naming-architecture-dhc-options-00.txt   draft-ietf-homenet-naming-architecture-dhc-options-01.txt 
HOMENET D. Migault (Ed) HOMENET D. Migault (Ed)
Internet-Draft Orange Internet-Draft Ericsson
Intended status: Standards Track W. Cloetens Intended status: Standards Track W. Cloetens
Expires: March 22, 2015 SoftAtHome Expires: August 21, 2015 SoftAtHome
C. Griffiths C. Griffiths
Dyn Dyn
R. Weber R. Weber
Nominum Nominum
September 18, 2014 February 17, 2015
DHCP Options for Homenet Naming Architecture DHCP Options for Homenet Naming Architecture
draft-ietf-homenet-naming-architecture-dhc-options-00.txt draft-ietf-homenet-naming-architecture-dhc-options-01.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 March 22, 2015. This Internet-Draft will expire on August 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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
5. Securing the exchanges . . . . . . . . . . . . . . . . . . . 8 4.1. Architecture and DHCP Options Overview . . . . . . . . . 7
6. DNS Zones Update Mechanisms . . . . . . . . . . . . . . . . . 9 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 10
6.1. Data subjected to update . . . . . . . . . . . . . . . . 9 4.3. Master / Slave Synchronization versus DNS Update . . . . 11
6.2. Master / Slave Synchronization versus DNS Update . . . . 9 5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Setting Master / Slave Synchronization . . . . . . . . . 10 5.1. CPE Master / Slave Synchronization Configurations . . . . 11
6.4. Master / Slave Synchronization: CPE / Public 5.1.1. CPE / Public Authoritative Name Server Set . . . . . 12
Authoritative Name Server Set . . . . . . . . . . . . . . 10 5.1.2. CPE / Reverse Public Authoritative Name Server Set . 12
6.5. Master / Slave Synchronization: CPE / Reverse Public 5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12
Authoritative Name Server Set . . . . . . . . . . . . . . 11 5.2.1. DNS Homenet Zone Template . . . . . . . . . . . . . . 12
7. DNS Zone Update Data . . . . . . . . . . . . . . . . . . . . 11 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 13
7.1. DNS Homenet Zone Template . . . . . . . . . . . . . . . . 11 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13
7.2. DNS Homenet Zone . . . . . . . . . . . . . . . . . . . . 12 6.1. Security Field . . . . . . . . . . . . . . . . . . . . . 14
8. Payload Description . . . . . . . . . . . . . . . . . . . . . 12 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Security Field . . . . . . . . . . . . . . . . . . . . . 12 6.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 15
8.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 13 6.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 15
8.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 14 6.5. DHCP Public Authoritative Name Server Set Option . . . . 16
8.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 14 6.6. DHCP Reverse Public Authoritative Name Server Set Option 17
8.5. DHCP Public Authoritative Name Server Set Option . . . . 15 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. DHCP Reverse Public Authoritative Name Server Set Option 16 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 18
9. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 19
9.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 7.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 19
9.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.2. Channel between the CPE and ISP DHCP Server MUST be
11.1. DNSSEC is recommended to authenticate DNS hosted data . 18 secured . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Channel between the CPE and ISP DHCP Server MUST be 9.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . . 20
secured . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20
11.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.2. Informational References . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Scenarios and impact on the End User . . . . . . . . 22
13.2. Informational References . . . . . . . . . . . . . . . . 20 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Scenarios and impact on the End User . . . . . . . . 20 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23
A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23
A.2. Third Party Registered Homenet Domain . . . . . . . . . . 21 A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25
A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 22 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
- Customer Premises Equipment: (CPE) is the router providing - Customer Premises Equipment: (CPE) is the router providing
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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
the DHCP Public Key Option. This option is sent by the CPE to the DHCP Public Key Option. This option is sent by the CPE to
the DHCP Server and provides the Public Key the CPE uses to the DHCP Server and provides the Public Key the CPE uses to
authenticate itself. The DHCP Server is then responsible to authenticate itself. The DHCP Server is then responsible to
provide the Public Key to the various DNS servers. provide the Public Key to the various DNS servers.
As a result, the DHCP Options described in this document enable an As a result, the DHCP Options described in this document enable an
agnostic CPE to outsource its naming infrastructure without any agnostic CPE to outsource its naming infrastructure without any
configuration from the end user. The main reason no configuration is configuration from the end user. The main reason no configuration is
required by the end user is that there are privilege links first required by the end user is that there are privileged links: first
between the CPE and the DHCP Server and then between the DHCP Server between the CPE and the DHCP Server and then between the DHCP Server
and the various DNS servers (DNS Homenet Zone Server, the Reverse and the various DNS servers (DNS Homenet Zone Server, the Reverse
Public Authoritative Name Server Set, Public Authoritative Name Public Authoritative Name Server Set, Public Authoritative Name
Server Set). This enables the CPE to send its authentication Server Set). This enables the CPE to send its authentication
credentials (a Public Key) to the DHCP Server that in turn forward it credentials (a Public Key) to the DHCP Server that in turn forward it
to the various DNS servers. With the authentication credential on to the various DNS servers. With the authentication credential on
the DNS servers set, the CPE is able to update the various zones in a the DNS servers set, the CPE is able to update the various zones in a
secure way. secure way.
If the DHCP Server cannot provide the public key to one of these If the DHCP Server cannot provide the public key to one of these
servers (most likely the Public Authoritative Name Server Set) and servers (most likely the Public Authoritative Name Server Set) and
the CPE needs to interact with the server, then, the end user is the CPE needs to interact with the server, then, the end user is
expected to provide it manually or using other mechanisms. Such expected to provide the CPE's public key to these servers (the
mechanisms are outside the scope of this document. In that case, the Reverse Public Authoritative Name Server Set or the Public
authentication credentials need to be provided every time the key is Authoritative Name Server Set) either manually or using other
modified. Appendix A provides more details on how different mechanisms. Such mechanisms are outside the scope of this document.
scenarios impact the end users. In that case, the authentication credentials need to be provided
every time the key is modified. Appendix A provides more details on
how different scenarios impact the end users.
The remaining of this document is as follows. Section 4 provides an
overview of the DHCP Options as well as the expected interactions
between the CPE and the various involved entities. This section also
provides an overview of available mechanisms to secure DNS
transactions and update DNS Data. Section 5 describes how the CPE
may securely synchronize and update DNS data. Section 6 describes
the payload of the DHCP Options and Section 7 details how DHCP Client
DHCP Server and DHCP Relay behave. Section 8 lists the new
parameters to be registered at the IANA, Section 9 provides security
considerations. Finally, Appendix A describes how the CPE may behave
and be configured regarding various scenarios.
4. Protocol Overview 4. Protocol Overview
This section provides an overview of the how the CPE is expect to
interact with various entities, as well as how the CPE is expected to
be configured via DHCP Options. Section 4.1 describes the entities
the CPE is expected to interact with. Interaction with each entities
is defined via DHCP Options that are expected to configure the CPE.
Once configured, the CPE is expected to be able to update some DNS
Data hosted by the different entities. As a result security and
updating mechanisms play an important role in the specification.
Section 4.2 provides an overview of the different security mechanisms
considered for securing the CPE transactions and Section 4.3
considers the different update mechanisms considered for the CPE to
update the DNS Data.
4.1. Architecture and DHCP Options Overview
This section illustrates how a CPE configures its naming This section illustrates how a CPE configures its naming
infrastructure to outsource its authoritative naming service. All infrastructure to outsource its authoritative naming service. All
configurations and settings are performed using DHCP Options. In configurations and settings are performed using DHCP Options. This
this section, for the sake of simplicity, we consider that the DHCP section, for the sake of simplicity, assumes that the DHCP Server is
Server is able to communicate to the various DNS servers and provide able to communicate to the various DNS servers and to provide them
them them the public key associated to the CPE. Once each server got the public key associated to the CPE. Once each server got the
the credentials, the CPE can proceed to updates in a authenticated public key, the CPE can proceed to updates in a authenticated and
and secure way. secure way.
This scenario has been chosen as it is believed to be the most This scenario has been chosen as it is believed to be the most
popular scenario. This document does not ignore that scenarios where popular scenario. This document does not ignore that scenarios where
the DHCP Server does not have privilege relations with the Public the DHCP Server does not have privileged relations with the Public
Authoritative Name Server Set must be considered. These cases are Authoritative Name Server Set must be considered. These cases are
discussed latter in Appendix A. Such scenario does not necessarily discussed latter in Appendix A. Such scenario does not necessarily
require configuration for the end user and can also be Zero Config. require configuration for the end user and can also be Zero Config.
The scenario is represented in Figure 1. The scenario is represented in Figure 1.
- 1: The CPE provides its Public Key to the DHCP Server using a DHCP - 1: The CPE provides its Public Key to the DHCP Server using a DHCP
Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP Option Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP Option
Request Option (ORO) for the DHCP Zone Template Option Request Option (ORO) for the DHCP Zone Template Option
(OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name (OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name
skipping to change at page 8, line 29 skipping to change at page 9, line 29
| |<---------->| Name Server Set | | |<---------->| Name Server Set |
| | | +--------------------------------+ | | | +--------------------------------+
-------| |-------|-------------------------------------- -------| |-------|--------------------------------------
| | | +--------------------------------+ | | | +--------------------------------+
+------+ +--->| Public Authoritative | +------+ +--->| Public Authoritative |
| Name Server Set | | Name Server Set |
+--------------------------------+ +--------------------------------+
Figure 1: Protocol Overview Figure 1: Protocol Overview
5. Securing the exchanges 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
update. More specifically, the CPE is likely to update the:
- DNS Homenet Zone Template: may be updated by the CPE if the
configuration of the zone may be changed. This can include
additional Public Authoritative Master(s), a different
Registered Homenet Domain as the one initially proposed, or a
redirection to another domain.
- DNS Homenet Reverse Zone: may be updated every time a new device
is connected or dis-connected.
- DNS Homenet Zone: may be updated every time a new device is
connected, dis-connected.
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
document considers two mechanisms to update a DNS Data (nsupdate and
master/slave synchronization). Which security mechanism to use to
secure a DNS transaction depends on the expected security
(authentication of the authoritative server, mutual authentication,
confidentiality...). The expected security may also depends on the
kind of transaction performed by the CPE. Section 4.2 describes the
different security mechanisms considered in the document as well as
their respective goals. Which mechanism to use to update the DNS
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
positions the nsupdate and master/slave synchronization mechanisms.
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
between two end points and SIG(0) [RFC2931] authenticates the DNS between two end points and SIG(0) [RFC2931] authenticates the DNS
packet exchanged. packet exchanged.
The key issue with TSIG is that a shared secret must be negotiated The key issue with TSIG is that a shared secret must be negotiated
between the CPE and the server. On the other end, TSIG performs between the CPE and the server. On the other hand, TSIG performs
symmetric cryptography which is light in comparison with asymmetric symmetric cryptography which is light in comparison with asymmetric
cryptography used by SIG(0). As a result, over large zone transfer, cryptography used by SIG(0). As a result, over large zone transfer,
TSIG may be preferred to SIG(0). TSIG may be preferred to SIG(0).
This document does not provides means to distribute shared secret for This document does not provides means to distribute shared secret for
example using a specific DHCP Option. The only assumption made is example using a specific DHCP Option. The only assumption made is
that the CPE generates or is assigned a public key. that the CPE generates or is assigned a public key.
As a result, when the document specifies the transaction is secured As a result, when the document specifies the transaction is secured
with TSIG, it means that either the CPE and the DNS Server have been with TSIG, it means that either the CPE and the DNS Server have been
manually configured with a shared secret, or the shared secret has manually configured with a shared secret, or the shared secret has
been negotiated using TKEY [RFC2930], and the TKEY exchanged are been negotiated using TKEY [RFC2930], and the TKEY exchanged are
secured with SIG(0). secured with SIG(0).
Exchange with the DNS Template Server to retrieve the DNS Homenet Exchange with the DNS Template Server to retrieve the DNS Homenet
Zone Template may be protected by SIG(0), TSIG or DNSSEC. When Zone Template may be protected by SIG(0), TSIG or DNSSEC. When
DNSSEC is used, it means the DNS Template Server only provides DNSSEC is used, it means the DNS Template Server only provides
integrity protection, and does not necessarily prevents someone else integrity protection, and does not necessarily prevents someone else
to query the DNS Homenet Zone Template. In addition, DNSSEC is only to query the DNS Homenet Zone Template. In addition, DNSSEC is only
a way to protect the communication of AXFR queries, in other words, a way to protect the AXFR queries transaction, in other words, DNSSEC
DNSSEC cannot be used to secure updates. If DNSSEC is used to cannot be used to secure updates. If DNSSEC is used to provide
provide integrity protection for the AXFR response, the CPE should integrity protection for the AXFR response, the CPE should proceed to
proceed to the DNSSEC signature checks. If signature check fails, it the DNSSEC signature checks. If signature check fails, it MUST
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
as 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.
6. DNS Zones Update Mechanisms 4.3. Master / Slave Synchronization versus DNS Update
6.1. Data subjected to update
The CPE is likely to update various DNS contents:
- DNS Homenet Zone Template: may be updated by the CPE if the
configuration of the zone may be changed. This can include
additional Public Authoritative Master(s), a different
Registered Homenet Domain as the one initially proposed, or a
redirection to another domain.
- DNS Homenet Reverse Zone: may be updated every time a new device
is connected or dis-connected.
- DNS Homenet Zone: may be updated every time a new device is
connected, dis-connected.
6.2. Master / Slave 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 master
/ slave synchronization. / slave 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 master / slave synchronization. As
these zones may be large, with frequent updates, we recommend to use these zones may be large, with frequent updates, we recommend to use
the master / slave architecture as described in the master / slave architecture as described in
[I-D.mglt-homenet-front-end-naming-delegation]. The master / slave [I-D.ietf-homenet-front-end-naming-delegation]. The master / slave
mechanism is preferred as it better scales and avoids DoS attacks: mechanism is preferred as it better scales and avoids DoS attacks:
First the master notifies the slave the zone must be updated, and First the master notifies the slave the zone must be updated, and
leaves the slave to proceed to the update when possible. Then, the leaves the slave to proceed to the update when possible. Then, the
NOTIFY message sent by the master is a small packet that is less NOTIFY message sent by the master is a small packet that is less
likely to load the slave. At last, the AXFR query performed by the likely to load the slave. At last, the AXFR query performed by the
slave is a small packet sent over TCP (section 4.2 [RFC5936]) which slave is a small packet sent over TCP (section 4.2 [RFC5936]) which
makes unlikely the slave to perform reflection attacks with a forged makes unlikely the slave to perform reflection attacks with a forged
NOTIFY. On the other hand, DNS updates can use UDP, packets require NOTIFY. On the other hand, DNS updates can use UDP, packets require
more processing then a NOTIFY, and they do not provide the server the more processing then a NOTIFY, and they do not provide the server the
opportunity to post-pone the update. opportunity to post-pone the update.
6.3. Setting Master / Slave Synchronization 5. CPE Configuration
5.1. CPE Master / Slave Synchronization Configurations
The master / slave architecture is described in The master / slave architecture is described in
[I-D.mglt-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 master whereas the DNS Server is configured as a
slave. The DNS Server represents the Public Authoritative Name slave. 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 slave.
The section details how the CPE or master communicate the necessary The section details how the CPE or master communicate the necessary
information to set up the slave. information to set up the slave.
In order to set the master / slave configuration, both master and In order to set the master / slave configuration, both master and
slaves must agree on 1) the zone to be synchronized, 2) the IP slaves must agree on 1) the zone to be synchronized, 2) the IP
address used by both master and slave. In this document we assume address and ports used by both master and slave.
that synchronization is performed on both side on port 53.
[QUESTION Do we have to consider different port of port 53 is fine.
I guess it is fine.]
6.4. Master / Slave Synchronization: CPE / Public Authoritative Name 5.1.1. CPE / Public Authoritative Name Server Set
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 slave is provided by the DHCP Public Authoritative Name Server
Set Option (OPTION_NAME_SERVER_SET). 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
skipping to change at page 11, line 19 skipping to change at page 12, line 27
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 slave reads the Registered Homenet Domain and
checks the NOTIFY is sent by the authorized master. This can be done checks the NOTIFY is sent by the authorized master. This can be done
using the shared secret (TSIG) or the public key (SIG(0)). Once the using the shared secret (TSIG) or the public key (SIG(0)). Once the
NOTIFY has been authenticated, the Public Authoritative Name Server NOTIFY has been authenticated, the Public Authoritative Name Server
Sets might consider the source IP address of the NOTIFY query to Sets might consider the source IP address of the NOTIFY query to
configure the masters attributes. configure the masters attributes.
6.5. Master / Slave Synchronization: CPE / Reverse Public Authoritative 5.1.2. CPE / Reverse Public Authoritative Name Server Set
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 slave is provided by the DHCP Reverse
Public Authoritative Name Server Set Option 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 slave is performed as illustrated in
Section 6.4. Section 5.1.1.
7. DNS Zone Update Data 5.2. CPE DNS Data Handling and Update Policies
7.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 Master(s) as well as the Homenet Registered
Domain, that is SOA, and NS fields. This template might be generated Domain, that is SOA, and NS fields. This template might be generated
automatically by the owner of the DHCP Server. For example, an ISP automatically by the owner of the DHCP Server. For example, an ISP
might provide a default Homenet Registered Domain as well as default might provide a default Homenet Registered Domain as well as default
Public Authoritative Master(s). This default settings should provide Public Authoritative Master(s). This default settings should provide
the CPE the necessary pieces of information to set the homenet naming the CPE the necessary pieces of information to set the homenet naming
architecture. architecture.
skipping to change at page 12, line 10 skipping to change at page 13, line 17
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
out of scope of this document. However, in this document we assume out of scope of this document. However, in this document we assume
the Registered Homenet Domain is used as an index by the Public the Registered Homenet Domain is used as an index by the Public
Authoritative Name Server Set, and SIG(0), TSIG are used to Authoritative Name Server Set, and SIG(0), TSIG are used to
authenticate the CPE. As a result, the Registered Homenet Domain authenticate the CPE. As a result, the Registered Homenet Domain
should not be modified unless the Public Authoritative Name Server should not be modified unless the Public Authoritative Name Server
Set can handle with it. Set can handle with it.
7.2. DNS Homenet Zone 5.2.2. DNS (Reverse) Homenet Zone
The DNS Homenet Zone might be generated from the DNS Homenet Zone The DNS Homenet Zone might be generated from the DNS Homenet Zone
Template. How the DNS Homenet Zone is generated is out of scope of Template. How the DNS Homenet Zone is generated is out of scope of
this document. In some cases, the DNS Homenet Zone might be the this document. In some cases, the DNS Homenet Zone might be the
exact copy of the DNS Homenet Zone Template. In other cases, it exact copy of the DNS Homenet Zone Template. In other cases, it
might be generated from the DNS Homenet Zone Template with additional might be generated from the DNS Homenet Zone Template with additional
RRsets. In some other cases, the DNS Homenet Zone might be generated RRsets. In some other cases, the DNS Homenet Zone might be generated
without considering the DNS Homenet Zone Template, but only without considering the DNS Homenet Zone Template, but only
considering specific configuration rules. considering specific configuration rules.
In the current document the CPE only sets a single zone that is In the current document the CPE only sets a single zone that is
associated with one single Homenet Registered Domain. The domain associated with one single Homenet Registered Domain. The domain
might be assigned by the owner of the DNS Homenet Zone Template. might be assigned by the owner of the DNS Homenet Zone Template.
This constrain does not prevent the CPE to use multiple domain names. This constrain does not prevent the CPE to use multiple domain names.
How additional domains are considered is out of scope of this How additional domains are considered is out of scope of this
document. One way to handle these additional zones is to configure document. One way to handle these additional zones is to configure
static redirections to the DNS Homenet Zone using CNAME [RFC2181], static redirections to the DNS Homenet Zone using CNAME [RFC2181],
[RFC1034], DNAME [RFC6672] or CNAME+DNAME [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
8. Payload Description 6. Payload Description
8.1. Security Field This section details the payload of the DHCP Options. A few DHCP
Options are used to advertise a server the CPE may be expect to
interact with. Interaction may require to define how the update is
expected to be performed as well as how the communication is secured.
Security and Update are shared by multiple DHCP Options and are
described in separate sections. Section 6.1 describes the security
field, Section 6.2 describes the update fields, the remaining
sections Section 6.3, Section 6.4, Section 6.5, Section 6.6 describe
the DHCP Options.
6.1. Security Field
The Security Field of the DHCP Option is represented in Figure 2. It The Security Field of the DHCP Option is represented in Figure 2. It
indicates the security mechanism supported by the DNS Server. One of indicates the security mechanism supported by the DNS Server. One of
these mechanism MUST be chosen by the CPE in order to perform a these mechanism MUST be chosen by the CPE in order to perform a
transaction with the DNS server. See Section 5 for more details. transaction with the DNS server. See Section 4.2 for more details.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | | Security |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Security Field Figure 2: Security Field
- DNS (Bit 0): indicates, when set to 1, that DNS without any - DNS (Bit 0): indicates, when set to 1, that DNS without any
skipping to change at page 13, line 26 skipping to change at page 14, line 44
with SIG(0) even though SIG(0) is not supported. with SIG(0) even though SIG(0) is not supported.
- Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server
and ignored by the DHCP Client. and ignored by the DHCP Client.
A Security field with all bits set to zero indicates the operation is A Security field with all bits set to zero indicates the operation is
not permitted. The Security field may be set to zero when updates not permitted. The Security field may be set to zero when updates
operations are not permitted for the DNS Homenet Template. In any operations are not permitted for the DNS Homenet Template. In any
other case this is an error. other case this is an error.
8.2. Update Field 6.2. Update Field
The Update Field of the DHCP Option is represented in Figure 3. It The Update Field of the DHCP Option is represented in Figure 3. It
indicates the update mechanism supported by the DNS server. See indicates the update mechanism supported by the DNS server. See
Section 6 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 - Master / Slave (Bit 0): indicates, when set to 1, that DNS Server
supports data synchronization using a Master / Slave mechanism. supports data synchronization using a Master / Slave 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.
8.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
Key that is used to authenticate the CPE. Key that is used to authenticate the CPE.
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_PUBLIC_KEY | option-len | | OPTION_PUBLIC_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 14, line 31 skipping to change at page 15, line 48
- OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public - OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public
Key Option. Key Option.
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Public Key Data: contains the Public Key. The format is the DNSKEY - Public Key Data: contains the Public Key. The format is the DNSKEY
RDATA format as defined in [RFC4034]. RDATA format as defined in [RFC4034].
8.4. DHCP Zone Template Option 6.4. DHCP Zone Template Option
The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option
indicates the CPE how to retrieve the DNS Homenet Zone Template. It indicates the CPE how to retrieve the DNS Homenet Zone Template. It
provides a FQDN the CPE SHOULD query with a DNS query of type AXFR. provides a FQDN the CPE SHOULD query with a DNS query of type AXFR.
The option also specifies which security protocols are available on The option also specifies which security protocols are available on
the authoritative server. DNS Homenet Zone Template update, if the authoritative server. DNS Homenet Zone Template update, if
permitted MUST use the DNS Update mechanism. permitted MUST use the DNS Update mechanism.
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_DNS_ZONE_TEMPLATE | option-len | | OPTION_DNS_ZONE_TEMPLATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security (axfr) | Security | | Security (axfr) | Security |
skipping to change at page 15, line 13 skipping to change at page 16, line 31
Figure 5: DHCP Zone Template Option Figure 5: DHCP Zone Template Option
- OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP - OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP
Zone Template Option. Zone Template Option.
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (axfr) (16 bits): defines which security protocols are - Security (axfr) (16 bits): defines which security protocols are
supported by the DNS server. This field concerns the AXFR and supported by the DNS server. This field concerns the AXFR and
consultation queries, not the update queries. See Section 8.1 consultation queries, not the update queries. See Section 6.1
for more details. for more details.
- Security (16 bits): defines which security protocols are supported - Security (16 bits): defines which security protocols are supported
by the DNS server. This field concerns the update. See by the DNS server. This field concerns the update. See
Section 8.1 for more details. Section 6.1 for more details.
- 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.
8.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. master / slave 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 | | | Security | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | |
+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Public Authoritative Name Server Set FQDN / / Public Authoritative Name Server Set FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCP Public Authoritative Name Server Set Option Figure 6: DHCP Public Authoritative Name Server Set Option
- OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP - OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP
Public Authoritative Name Server Set Option. Public Authoritative Name Server Set Option.
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (16 bits): defines which security protocols are supported - Security (16 bits): defines which security protocols are supported
by the DNS server. See Section 8.1 for more details. by the DNS server. See Section 6.1 for more details.
- Update (8 bits): defines which update mechanisms are supported by - Update (8 bits): defines which update mechanisms are supported by
the DNS server. See Section 6 for more details. the DNS server. See Section 4.3 for more details.
- Server Port (16 bits): defines the port the Public Authoritative
Name Server Set is listening.
- 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.
8.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 master /
slave architecture or DNS updates. slave 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 | | | Security | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | |
+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Public Authoritative Name Server Set FQDN / / Reverse Public Authoritative Name Server Set FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCP Reverse Public Authoritative Name Server Set Option Figure 7: DHCP Reverse Public Authoritative Name Server Set Option
- OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the - OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the
DHCP Reverse Public Authoritative Name Server Set Option. DHCP Reverse Public Authoritative Name Server Set Option.
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (16 bits): defines which security protocols are supported - Security (16 bits): defines which security protocols are supported
by the DNS server. See Section 8.1 for more details. by the DNS server. See Section 6.1 for more details.
- Update (8 bits): defines which update mechanisms are supported by - Update (8 bits): defines which update mechanisms are supported by
the DNS server. See Section 6 for more details. the DNS server. See Section 4.3 for more details.
- Server Port (16 bits): defines the port the Public Authoritative
Name Server Set is listening.
- Reverse Public Authoritative Name Server Set FQDN (variable): The - Reverse Public Authoritative Name Server Set FQDN (variable): The
FQDN of the Reverse Public Authoritative Name Server Set. FQDN of the Reverse Public Authoritative Name Server Set.
9. DHCP Behavior 7. DHCP Behavior
9.1. DHCPv6 Server Behavior 7.1. DHCPv6 Server Behavior
The DHCP Server sends the DHCP Zone Template Option The DHCP Server sends the DHCP Zone Template Option
(OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set
Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative
Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request
by the DHCP Client. by the DHCP Client.
The DHCP Server MAY receive a DHCP Public Key Option The DHCP Server MAY receive a DHCP Public Key Option
(OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option, (OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option,
the DHCP Sever is expect to communicate this credential to the the DHCP Sever is expect to communicate this credential to the
available DNS Servers like the DNS Template Server, the Public available DNS Servers like the DNS Template Server, the Public
Authoritative Name Server Set and the Reverse Public Authoritative Authoritative Name Server Set and the Reverse Public Authoritative
Name Server Set. Name Server Set.
9.2. DHCPv6 Client Behavior 7.2. DHCPv6 Client Behavior
The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY) The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY)
to the DHCP Server. This Public Key authenticates the CPE. to the DHCP Server. This Public Key authenticates the CPE.
The DHCP Client sends a DHCP Option Request Option (ORO) with the The DHCP Client sends a DHCP Option Request Option (ORO) with the
necessary DHCP options. necessary DHCP options.
A CPE SHOULD only send the an ORO request for DHCP Options it needs A CPE SHOULD only send the an ORO request for DHCP Options it needs
or for information that needs to be up-to-date. or for information that needs to be up-to-date.
Upon receiving a DHCP option described in this document, the CPE Upon receiving a DHCP option described in this document, the CPE
SHOULD retrieve or update DNS zones using the associated security and SHOULD retrieve or update DNS zones using the associated security and
update protocols. update protocols.
9.3. DHCPv6 Relay Behavior 7.3. DHCPv6 Relay Behavior
DHCP Relay behavior are not modified by this document. DHCP Relay behavior are not modified by this document.
10. IANA Considerations 8. IANA Considerations
The DHCP options detailed in this document is: The DHCP options detailed in this document is:
- OPTION_DNS_ZONE_TEMPLATE: TBD - OPTION_DNS_ZONE_TEMPLATE: TBD
- OPTION_NAME_SERVER_SET: TBD - OPTION_NAME_SERVER_SET: TBD
- OPTION_REVERSE_NAME_SERVER_SET: TBD - OPTION_REVERSE_NAME_SERVER_SET: TBD
- OPTION_PUBLIC_KEY: TBD - OPTION_PUBLIC_KEY: TBD
11. Security Considerations 9. Security Considerations
11.1. DNSSEC is recommended to authenticate DNS hosted data 9.1. DNSSEC is recommended to authenticate DNS hosted data
It is recommended that the (Reverse) DNS Homenet Zone is signed with It is recommended that the (Reverse) DNS Homenet Zone is signed with
DNSSEC. The zone may be signed by the CPE or by a third party. We DNSSEC. The zone may be signed by the CPE or by a third party. We
recommend the zone to be signed by the CPE, and that the signed zone recommend the zone to be signed by the CPE, and that the signed zone
is uploaded. is uploaded.
11.2. Channel between the CPE and ISP DHCP Server MUST be secured 9.2. Channel between the CPE and ISP DHCP Server MUST be secured
The document considers that the channel between the CPE and the ISP The document considers that the channel between the CPE and the ISP
DHCP Server is trusted. More specifically, the CPE is authenticated DHCP Server is trusted. More specifically, the CPE is authenticated
and the exchanged messages are protected. The current document does and the exchanged messages are protected. The current document does
not specify how to secure the channel. [RFC3315] proposes a DHCP not specify how to secure the channel. [RFC3315] proposes a DHCP
authentication and message exchange protection, [RFC4301], [RFC5996] authentication and message exchange protection, [RFC4301], [RFC7296]
propose to secure the channel at the IP layer. propose to secure the channel at the IP layer.
In fact, the channel MUST be secured because the CPE provides In fact, the channel MUST be secured because the CPE provides
authentication credentials. Unsecured channel may result in CPE authentication credentials. Unsecured channel may result in CPE
impersonation attacks. impersonation attacks.
11.3. CPEs are sensitive to DoS 9.3. CPEs are sensitive to DoS
CPE have not been designed for handling heavy load. The CPE are CPE have not been designed for handling heavy load. The CPE are
exposed on the Internet, and their IP address is publicly published exposed on the Internet, and their IP address is publicly published
on the Internet via the DNS. This makes the Home Network sensitive on the Internet via the DNS. This makes the Home Network sensitive
to Deny of Service Attacks. The resulting outsourcing architecture to Deny of Service Attacks. The resulting outsourcing architecture
is described in [I-D.mglt-homenet-front-end-naming-delegation]. This is described in [I-D.ietf-homenet-front-end-naming-delegation]. This
document shows how the outsourcing architecture can be automatically document shows how the outsourcing architecture can be automatically
set. set.
12. Acknowledgment 10. Acknowledgment
We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie
Volz for their comments on the design of the DHCP Options. We would Volz for their comments on the design of the DHCP Options. We would
also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti
for their remarks on the architecture design. The designed solution for their remarks on the architecture design. The designed solution
has been largely been inspired by Mark Andrews's document has been largely been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark.
13. References 11. References
13.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 20, line 8 skipping to change at page 21, line 43
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010. (AXFR)", RFC 5936, June 2010.
[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 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012. DNS", RFC 6672, June 2012.
13.2. Informational References [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014.
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.mglt-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-mglt-homenet-front-end-naming-delegation-04 (work in draft-ietf-homenet-front-end-naming-delegation-00 (work in
progress), July 2014. progress), September 2014.
[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.
skipping to change at page 22, line 35 skipping to change at page 24, line 24
configure the redirection on one of its Reverse DNS Servers. That configure the redirection on one of its Reverse DNS Servers. That
said, outsourcing these resources is similar as outsourcing Public said, outsourcing these resources is similar as outsourcing Public
Authoritative Name Server Set and Public Authoritative Master(s) to a Authoritative Name Server Set and Public Authoritative Master(s) to a
third party. Similarly, the DNS Template Server can be easily third party. Similarly, the DNS Template Server can be easily
outsourced as detailed in this section 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 Master(s) 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 6 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". Master(s), 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
skipping to change at page 23, line 14 skipping to change at page 25, line 5
and the third party, or a specific token that is plugged into and the third party, or a specific token that is plugged into
the CPE, this operation is likely to be performed every time the CPE, this operation is likely to be performed every time
the CPE is changed, and every time the Public Key generated by the CPE is changed, and every time the Public Key generated by
the CPE is changed. the CPE is changed.
The main advantage of this scenario is that the DNS infrastructure is The main advantage of this scenario is that the DNS infrastructure is
completely outsourced to the third party. Most likely the Public Key completely outsourced to the third party. Most likely the Public Key
that authenticate the CPE need to be configured for every CPE. that authenticate the CPE need to be configured for every CPE.
Configuration is expected to be CPE live-long. Configuration is expected to be CPE live-long.
A.4. Multiple ISPs
This scenario considers a CPE connected to multiple ISPs.
Firstly, suppose the CPE has been configured with the based scenarios
exposed in Appendix A.1. The CPE has multiple interfaces, one for
each ISP, and each of these interface is configured using DHCP. The
CPE sends to each ISP its DHCP Public Key Option as well as a request
for a DHCP Zone Template Option, a DHCP Public Authoritative Name
Server Set Option and a DHCP Reverse Public Authoritative Name Server
Set Option. Each ISP provides the requested DHCP options, with
different values. Note that this scenario assumes, the home network
has a different Registered Homenet Domain for each ISP as it is
managed by the ISP. On the other hand, the CPE Public Key may be
shared between the CPE and the multiple ISPs. The CPE builds the
associate DNS(SEC) Homenet Zone, and proceeds to the various settings
as described in Appendix A.1.
The protocol and DHCP Options described in this document are fully
compatible with a CPE connected to multiple ISPs with multiple
Registered Homenet Domains. However, the CPE should be able to
handle different Registered Homenet Domains. This is an
implementation issue which is outside the scope of the current
document. More specifically, multiple Registered Homenet Domains
leads to multiple DNS(SEC) Homenet Zones. A basic implementation may
erase the DNS(SEC) Homenet Zone that exists when it receives DHCP
Options, and rebuild everything from scratch. This will work for an
initial configuration but comes with a few drawbacks. First, updates
to the DNS(SEC) Homenet Zone may only push to one of the multiple
Registered Homenet Domain, the latest Registered Homenet Domain that
has been set, and this is most likely expected to be almost randomly
chosen as it may depend on the latency on each ISP network at the
boot time. As a results, this leads to unsynchronized Registered
Homenet Domains. Secondly, if the CPE handles in some ways
resolution, only the latest Registered Homenet Domain set may be able
to provide naming resolution in case of network disruption.
Secondly, suppose the CPE is connected to multiple ISP with a single
Registered Homenet Domain. In this case, the one party is chosen to
host the Registered Homenet Domain. This entity may be one of the
ISP or a third party. Note that having multiple ISPs can be
motivated for bandwidth aggregation, or connectivity fail-over. In
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 where the Public Authoritative Name Server Set and Public
Masters are hosted. In that sense, choosing one of the ISP even in a
scenario of multiple ISPs may make sense. However, for sake of
simplicity, this scenario assumes that a third party has be chosen to
host the Registered Homenet Domain. The DNS settings for each ISP is
described in Appendix A.2 and Appendix A.3. With the configuration
described in Appendix A.2, the CPE is expect to be able to handle
multiple Homenet Registered Domain, as the third party redirect to
one of the ISPs Servers. With the configuration described in
Appendix A.3, DNS zone are hosted and maintained by the third party.
A single DNS(SEC) Homenet Zone is built and maintained by the CPE.
This latter configuration is likely to match most CPE
implementations.
The protocol and DHCP Options described in this document are fully
compatible with a CPE connected to multiple ISPs. To configure or
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
Registered Homenet Domain, whereas Appendix A.3 does not have such
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]
-04: Working Version Major modifications are:
- Re-structuring the draft: description and comparison of update and
security mechanisms have been intergrated into the Overview
section. a Configuration section has been created to describe
both configuration and corresponding behavior of the CPE.
- Adding Ports parameters: Server Set can configure a port. The
Port Server parameter have been added in the DHCP Option
payloads because middle boxes may not be configured to let port
53 packets and it may also be useful to split servers among
different ports, assigning each end user a different port.
- Multiple ISP scenario: In order to address comments, the multiple
ISPs scenario has been described to explicitly show that the
protocol and DHCP Options do not prevent a CPE connected to
multiple independent ISPs.
-03: Working Version Major modifications are: -03: Working Version Major modifications are:
- Redesigning options/scope: according to feed backs received from - Redesigning options/scope: according to feed backs received from
the IETF89 presentation in the dhc WG. the IETF89 presentation in the dhc WG.
- Redesigning architecture: according to feed backs received from - Redesigning architecture: according to feed backs received from
the IETF89 presentation in the homenet WG, discussion with Mark the IETF89 presentation in the homenet WG, discussion with Mark
and Lorenzo. and Lorenzo.
-02: Working Version Major modifications are: -02: Working Version Major modifications are:
skipping to change at page 24, line 8 skipping to change at page 27, line 30
- DHCPv6 Client behavior: Following options guide lines - DHCPv6 Client behavior: Following options guide lines
- DHCPv6 Server behavior: Following options guide lines - DHCPv6 Server behavior: Following options guide lines
-00: First version published in dhc WG. -00: First version published in dhc WG.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Orange Ericsson
38 rue du General Leclerc 8400 boulevard Decarie
92794 Issy-les-Moulineaux Cedex 9 Montreal, QC H4P 2N2
France Canada
Phone: +33 1 45 29 60 52 Email: mglt.ietf@gmail.com
Email: daniel.migault@orange.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
150 Dow Street 150 Dow Street
Manchester, NH 03101 Manchester, NH 03101
US US
Email: cgriffiths@dyn.com Email: cgriffiths@dyn.com
URI: http://dyn.com URI: http://dyn.com
Ralf Weber Ralf Weber
 End of changes. 69 change blocks. 
150 lines changed or deleted 288 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/