draft-ietf-homenet-front-end-naming-delegation-10.txt   draft-ietf-homenet-front-end-naming-delegation-11.txt 
Homenet D. Migault Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational R. Weber Intended status: Informational R. Weber
Expires: September 10, 2020 Nominum Expires: October 21, 2020 Nominum
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
R. Hunter R. Hunter
Globis Consulting BV Globis Consulting BV
C. Griffiths C. Griffiths
W. Cloetens W. Cloetens
SoftAtHome SoftAtHome
March 09, 2020 April 19, 2020
Outsourcing Home Network Authoritative Naming Service Outsourcing Home Network Authoritative Naming Service
draft-ietf-homenet-front-end-naming-delegation-10 draft-ietf-homenet-front-end-naming-delegation-11
Abstract Abstract
The Homenet Naming authority is responsible for making devices within The Homenet Naming authority is responsible for making devices within
the home network accessible by name within the home network as well the home network accessible by name within the home network as well
as from outside the home network (e.g. the Internet). The names of as from outside the home network (e.g. the Internet). The names of
the devices accessible from the Internet are stored in the Public the devices accessible from the Internet are stored in the Public
Homenet Zone, served by a DNS authoritative server. It is unlikely Homenet Zone, served by a DNS authoritative server. It is unlikely
that home networks will contain sufficiently robust platforms that home networks will contain sufficiently robust platforms
designed to host a service such as the DNS on the Internet and as designed to host a service such as the DNS on the Internet and as
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 10, 2020. This Internet-Draft will expire on October 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Alternative solutions . . . . . . . . . . . . . . . . . . 5 1.1. Alternative solutions . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture Description . . . . . . . . . . . . . . . . . . 8 3. Architecture Description . . . . . . . . . . . . . . . . . . 8
3.1. Architecture Overview . . . . . . . . . . . . . . . . . . 8 3.1. Architecture Overview . . . . . . . . . . . . . . . . . . 8
3.2. Distribution Master Communication Channels . . . . . . . 10 3.2. Distribution Master Communication Channels . . . . . . . 10
4. Control Channel between HNA and DM . . . . . . . . . . . . . 11 4. Control Channel between Homenet Naming Authority (HNA) and
4.1. Information to build the Public Homenet Zone. . . . . . . 11 Distribution Master (DM) . . . . . . . . . . . . . . . . . . 11
4.1. Information to build the Public Homenet Zone. . . . . . . 12
4.2. Information to build the DNSSEC chain of trust. . . . . . 12 4.2. Information to build the DNSSEC chain of trust. . . . . . 12
4.3. Information to set the Synchronization Channel, . . . . . 12 4.3. Information to set the Synchronization Channel, . . . . . 12
4.4. Deleting the delegation . . . . . . . . . . . . . . . . . 13 4.4. Deleting the delegation . . . . . . . . . . . . . . . . . 13
4.5. Messages Exchange Description . . . . . . . . . . . . . . 13 4.5. Messages Exchange Description . . . . . . . . . . . . . . 13
4.5.1. Retrieving information for the Public Homenet Zone. . 13 4.5.1. Retrieving information for the Public Homenet Zone. . 13
4.5.2. Providing information for the DNSSEC chain of trust . 14 4.5.2. Providing information for the DNSSEC chain of trust . 14
4.5.3. Providing information for the Synchronization Channel 14 4.5.3. Providing information for the Synchronization Channel 15
4.5.4. HNA instructing deleting the delegation . . . . . . . 15 4.5.4. HNA instructing deleting the delegation . . . . . . . 15
4.6. Securing the Control Channel between HNA and DM . . . . . 15 4.6. Securing the Control Channel between Homenet Naming
Authority (HNA) and Distribution Master (DM) . . . . . . 15
4.7. Implementation Tips . . . . . . . . . . . . . . . . . . . 16 4.7. Implementation Tips . . . . . . . . . . . . . . . . . . . 16
5. DM Synchronization Channel between HNA and DM . . . . . . . . 17 5. DM Synchronization Channel between HNA and DM . . . . . . . . 17
5.1. Securing the Synchronization Channel between HNA and DM . 18 5.1. Securing the Synchronization Channel between HNA and DM . 18
6. DM Distribution Channel . . . . . . . . . . . . . . . . . . . 18 6. DM Distribution Channel . . . . . . . . . . . . . . . . . . . 18
7. HNA Security Policies . . . . . . . . . . . . . . . . . . . . 18 7. HNA Security Policies . . . . . . . . . . . . . . . . . . . . 19
8. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 19 8. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 19
9. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 19 9. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 19
10. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 21 10.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 21
10.2. Distribution Master . . . . . . . . . . . . . . . . . . 22 10.2. Distribution Master . . . . . . . . . . . . . . . . . . 22
11. Operational considerations for Offline/Disconnected 11. Operational considerations for Offline/Disconnected
resolution . . . . . . . . . . . . . . . . . . . . . . . . . 22 resolution . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. provisioning of the Homenet Naming Authority (HNA) . . . . . 22
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 23 14.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 24
13.2. Names are less secure than IP addresses . . . . . . . . 24 14.2. Names are less secure than IP addresses . . . . . . . . 24
13.3. Names are less volatile than IP addresses . . . . . . . 24 14.3. Names are less volatile than IP addresses . . . . . . . 24
13.4. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 24 14.4. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 25
13.5. Reflection Attack involving the Hidden Primary . . . . . 25 14.5. Reflection Attack involving the Hidden Primary . . . . . 25
13.6. Reflection Attacks involving the DM . . . . . . . . . . 26 14.6. Reflection Attacks involving the DM . . . . . . . . . . 26
13.7. Reflection Attacks involving the Public Authoritative 14.7. Reflection Attacks involving the Public Authoritative
Servers . . . . . . . . . . . . . . . . . . . . . . . . 27 Servers . . . . . . . . . . . . . . . . . . . . . . . . 27
13.8. Flooding Attack . . . . . . . . . . . . . . . . . . . . 27 14.8. Flooding Attack . . . . . . . . . . . . . . . . . . . . 27
13.9. Replay Attack . . . . . . . . . . . . . . . . . . . . . 27 14.9. Replay Attack . . . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 28 16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 29
16. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Envisioned deployment scenarios . . . . . . . . . . . . 29 17.1. Normative References . . . . . . . . . . . . . . . . . . 29
16.1.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . 29 17.2. Informative References . . . . . . . . . . . . . . . . . 32
16.1.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Envisioned deployment scenarios . . . . . . . . . . 34
16.2. Example: Homenet Zone . . . . . . . . . . . . . . . . . 30 A.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . . . 34
16.3. Example: HNA necessary parameters for outsourcing . . . 32 A.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . . . 34
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Example: Homenet Zone . . . . . . . . . . . . . . . 35
17.1. Normative References . . . . . . . . . . . . . . . . . . 33 Appendix C. Example: HNA necessary parameters for outsourcing . 37
17.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Homenet Naming authority is responsible for making devices within The Homenet Naming authority is responsible for making devices within
the home network accessible by name within the home network as well the home network accessible by name within the home network as well
as from outside the home network (e.g. the Internet). IPv6 as from outside the home network (e.g. the Internet). IPv6
connectivity provides the possibility of global end to end IP connectivity provides the possibility of global end to end IP
connectivity. End users will be able to transparently make use of connectivity. End users will be able to transparently make use of
this connectivity if they can use names to access the services they this connectivity if they can use names to access the services they
want from their home network. want from their home network.
skipping to change at page 5, line 23 skipping to change at page 5, line 25
signed with a secure delegation. DNSSEC key management and zone signed with a secure delegation. DNSSEC key management and zone
signing is handled by the HNA. signing is handled by the HNA.
Section 9 discusses management of one or more reverse zones. It Section 9 discusses management of one or more reverse zones. It
shows that management of the reverse zones can be entirely automated shows that management of the reverse zones can be entirely automated
and benefit from a pre-established relation between the ISP and the and benefit from a pre-established relation between the ISP and the
home network. Note that such scenarios may also be met for the home network. Note that such scenarios may also be met for the
Public Homenet Zone, but not necessarily. Public Homenet Zone, but not necessarily.
Section 10 discusses how renumbering should be handled. Finally, Section 10 discusses how renumbering should be handled. Finally,
Section 12 and Section 13 respectively discuss privacy and security Section 13 and Section 14 respectively discuss privacy and security
considerations when outsourcing the Public Homenet Zone. considerations when outsourcing the Public Homenet Zone.
The Public Homenet Zone is expected to contain public information The Public Homenet Zone is expected to contain public information
only in a single universal view. This document does not define how only in a single universal view. This document does not define how
the information required to construct this view is derived. the information required to construct this view is derived.
It is also not in the scope of this document to define names for It is also not in the scope of this document to define names for
exclusive use within the boundaries of the local home network. exclusive use within the boundaries of the local home network.
Instead, local scope information is expected to be provided to the Instead, local scope information is expected to be provided to the
home network using local scope naming services. mDNS [RFC6762] DNS-SD home network using local scope naming services. mDNS [RFC6762] DNS-SD
skipping to change at page 8, line 9 skipping to change at page 8, line 13
Servers. Servers.
o DNSSEC Resolver: a resolver that performs a DNSSEC resolution on o DNSSEC Resolver: a resolver that performs a DNSSEC resolution on
the Internet for the Public Homenet Zone. The resolution is the Internet for the Public Homenet Zone. The resolution is
performed requesting the Public Authoritative Servers. performed requesting the Public Authoritative Servers.
3. Architecture Description 3. Architecture Description
This section provides an overview of the architecture for outsourcing This section provides an overview of the architecture for outsourcing
the authoritative naming service from the HNA to the Outsourcing the authoritative naming service from the HNA to the Outsourcing
Infrastructure in Section 3.1. Section Section 16.2 and Section 16.3 Infrastructure in Section 3.1. Section Appendix B and Appendix C
illustrates this architecture with the example of a Public Homenet illustrates this architecture with the example of a Public Homenet
Zone as well as necessary parameter to configure the HNA. Zone as well as necessary parameter to configure the HNA.
3.1. Architecture Overview 3.1. Architecture Overview
Figure Figure 1 illustrates the architecture where the HNA outsources Figure 1 illustrates the architecture where the HNA outsources the
the publication of the Public Homenet Zone to the Outsourcing publication of the Public Homenet Zone to the Outsourcing
Infrastructure. Infrastructure.
The Public Homenet Zone is identified by the Registered Homenet The Public Homenet Zone is identified by the Registered Homenet
Domain Name - example.com. Domain Name - example.com.
".local" as well as ".home.arpa" are explicitly not considered as ".local" as well as ".home.arpa" are explicitly not considered as
Public Homenet zones. Public Homenet zones.
The HNA SHOULD build the Public Homenet Zone in a single view The HNA SHOULD build the Public Homenet Zone in a single view
populated with all resource records that are expected to be published populated with all resource records that are expected to be published
skipping to change at page 8, line 49 skipping to change at page 9, line 5
related keying material between the HNA and the DM. related keying material between the HNA and the DM.
Once the Public Homenet Zone has been built, the HNA outsources it to Once the Public Homenet Zone has been built, the HNA outsources it to
the Outsourcing Infrastructure as described in Figure 1. the Outsourcing Infrastructure as described in Figure 1.
The HNA acts as a hidden primary while the DM behaves as a secondary The HNA acts as a hidden primary while the DM behaves as a secondary
responsible to distribute the Public Homenet Zone to the multiple responsible to distribute the Public Homenet Zone to the multiple
Public Authoritative Servers that Outsourcing Infrastructure is Public Authoritative Servers that Outsourcing Infrastructure is
responsible for. responsible for.
The DM has 3 communication channels: * a DM Control Channel (see The DM has 3 communication channels:
section Section 4) to configure the HNA and the Outsourcing
Infrastructure, * a DM Synchronization Channel (see section Section 5 o a DM Control Channel (see section Section 4) to configure the HNA
to synchronize the Public Homenet Zone on the HNA and on the DM. * and the Outsourcing Infrastructure,
one or more Distribution Channels (see section Section 6 that
distributes the Public Homenet Zone from the DM to the Public o a DM Synchronization Channel (see section Section 5 to synchronize
Authoritative Server serving the Public Homenet Zone on the Internet. the Public Homenet Zone on the HNA and on the DM.
o one or more Distribution Channels (see section Section 6 that
distributes the Public Homenet Zone from the DM to the Public
Authoritative Server serving the Public Homenet Zone on the
Internet.
There MAY be multiple DM's, and multiple servers per DM. This text There MAY be multiple DM's, and multiple servers per DM. This text
assumes a single DM server for simplicity, but there is no reason why assumes a single DM server for simplicity, but there is no reason why
each channel need to be implemented on the same server, or indeed use each channel need to be implemented on the same server, or indeed use
the same code base. the same code base.
It is important to note that while the HNA is configured as an It is important to note that while the HNA is configured as an
authoritative server, it is not expected to answer to DNS requests authoritative server, it is not expected to answer to DNS requests
from the public Internet for the Public Homenet Zone. The function from the public Internet for the Public Homenet Zone. The function
of the HNA is limited to building the zone and synchronization with of the HNA is limited to building the zone and synchronization with
skipping to change at page 11, line 35 skipping to change at page 11, line 43
desireable. desireable.
This specification also assumes the same transport protocol and ports This specification also assumes the same transport protocol and ports
used by the DM to serve the Control Channel and by the HNA to serve used by the DM to serve the Control Channel and by the HNA to serve
the Synchronization Channel are the same. the Synchronization Channel are the same.
The Distribution Channel is internal to the Outsourcing The Distribution Channel is internal to the Outsourcing
Infrastructure and as such is not the primary concern of this Infrastructure and as such is not the primary concern of this
specification. specification.
4. Control Channel between HNA and DM 4. Control Channel between Homenet Naming Authority (HNA) and
Distribution Master (DM)
The DM Control Channel is used by the HNA and the Outsourcing The DM Control Channel is used by the HNA and the Outsourcing
Infrastructure to exchange information related to the configuration Infrastructure to exchange information related to the configuration
of the delegation which includes: of the delegation which includes:
4.1. Information to build the Public Homenet Zone. 4.1. Information to build the Public Homenet Zone.
More specifically, the Public Homenet Zone contains information that When the Homenet Naming Authority builds the public zone, it must
is related to the infrastructure serving the zone. In our case, the include information that it retrieves from the Distribution Master
infrastructure serving the Public Homenet Zone is the Outsourcing relating to how the zone is to be published.
Infrastructure, so this information MUST reflect that Outsourcing
Infrastructure and MUST be provided to the HNA.
The information includes at least names and IP addresses of the The information includes at least names and IP addresses of the
Public Authoritative Servers. In term of RRset information this Public Authoritative Name Servers. In term of RRset information:
corresponds, for the Registered Homenet Domain the MNAME of the SOA,
the NS and associated A and AAA RRsets. Optionally the Outsourcing o this includes the MNAME of the SOA,
Infrastructure MAY also provide operational parameters such as other
fields of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM). o the NS and associated A and AAA RRsets of the name servers.
As the information is necessary for the HNA to proceed and the
information is associated to the Outsourcing Infrastructure, this Optionally the Outsourcing Infrastructure MAY also provide
information exchange is mandatory. operational parameters such as other fields of SOA (SERIAL, RNAME,
REFRESH, RETRY, EXPIRE and MINIMUM). As the information is necessary
for the HNA to proceed and the information is associated to the
Outsourcing Infrastructure, this information exchange is mandatory.
4.2. Information to build the DNSSEC chain of trust. 4.2. Information to build the DNSSEC chain of trust.
The HNA SHOULD provide the hash of the KSK (DS RRset), so the that The HNA SHOULD provide the hash of the KSK (DS RRset), so the that
Outsourcing Infrastructure provides this value to the parent zone. A Outsourcing Infrastructure provides this value to the parent zone. A
common deployment use case is that the Outsourcing Infrastructure is common deployment use case is that the Outsourcing Infrastructure is
the registrar of the Registered Homenet Domain, and as such, its the registrar of the Registered Homenet Domain, and as such, its
relationship with the registry of the parent zone enables it to relationship with the registry of the parent zone enables it to
update the parent zone. When such relation exists, the HNA should be update the parent zone. When such relation exists, the HNA should be
able to request the Outsourcing Infrastructure to update the DS RRset able to request the Outsourcing Infrastructure to update the DS RRset
skipping to change at page 13, line 48 skipping to change at page 14, line 6
with a AXFR exchange. The AXFR message enables the response to with a AXFR exchange. The AXFR message enables the response to
contain any type of RRsets. The response might be extended in the contain any type of RRsets. The response might be extended in the
future if additional information will be needed. Alternatively, the future if additional information will be needed. Alternatively, the
information provided by the HNA to the DM is pushed by the HNA via a information provided by the HNA to the DM is pushed by the HNA via a
DNS update exchange. DNS update exchange.
To retrieve the necessary information to build the Public Homenet To retrieve the necessary information to build the Public Homenet
Zone, the HNA MUST send an DNS request of type AXFR associated to the Zone, the HNA MUST send an DNS request of type AXFR associated to the
Registered Homenet Domain. The DM MUST respond with a zone template. Registered Homenet Domain. The DM MUST respond with a zone template.
The zone template MUST contain a RRset of type SOA, one or multiple The zone template MUST contain a RRset of type SOA, one or multiple
RRset of type NS and at least one RRset of type A or AAAA. The SOA RRset of type NS and zero or more RRset of type A or AAAA.
RR is used to indicate to the HNA the value of the MNAME of the
Public Homenet Zone. The NAME of the SOA RR MUST be the Registered The SOA RR is used to indicate to the HNA the value of the MNAME of
Homenet Domain. The MNAME value of the SOA RDATA is the value the Public Homenet Zone. The NAME of the SOA RR MUST be the
provided by the Outsourcing Infrastructure to the HNA. Other RDATA Registered Homenet Domain. The MNAME value of the SOA RDATA is the
values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are provided by value provided by the Outsourcing Infrastructure to the HNA. Other
the Outsourcing Infrastructure as suggestions. The NS RRsets are RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are provided
by the Outsourcing Infrastructure as suggestions. The NS RRsets are
used to carry the Public Authoritative Servers of the Outsourcing used to carry the Public Authoritative Servers of the Outsourcing
Infrastructure. Their associated NAME MUST be the Registered Homenet Infrastructure. Their associated NAME MUST be the Registered Homenet
Domain. The TTL and RDATA are those expected to be published on the Domain. The TTL and RDATA are those expected to be published on the
Public Homenet Zone. The RRsets of Type A and AAAA MUST have their Public Homenet Zone. The RRsets of Type A and AAAA MUST have their
NAME matching the NSDNAME of one of the NS RRsets. NAME matching the NSDNAME of one of the NS RRsets.
Upon receiving the response, the HNA MUST validate the conditions on Upon receiving the response, the HNA MUST validate the conditions on
the SOA, NS and A or AAAA RRsets. If an error occurs, the HNA MUST the SOA, NS and A or AAAA RRsets. If an error occurs, the HNA MUST
stop proceeding and MUST report an error. Otherwise, the HNA builds stop proceeding and MUST report an error. Otherwise, the HNA builds
the Public Homenet Zone by setting the MNAME value of the SOA as the Public Homenet Zone by setting the MNAME value of the SOA as
skipping to change at page 15, line 32 skipping to change at page 15, line 44
4.5.4. HNA instructing deleting the delegation 4.5.4. HNA instructing deleting the delegation
To instruct to delete the delegation the HNA MAY send a DNS UPDATE To instruct to delete the delegation the HNA MAY send a DNS UPDATE
Delete message. The NAME in the SOA MUST be the parent zone of the Delete message. The NAME in the SOA MUST be the parent zone of the
Registered Homenet Domain. The Update section MUST be a RRset of Registered Homenet Domain. The Update section MUST be a RRset of
Type NS. The NAME associated to the NS RRSet MUST be the Registered Type NS. The NAME associated to the NS RRSet MUST be the Registered
Domain Name. As indictaed by [RFC2136] section 2.5.2 the delete Domain Name. As indictaed by [RFC2136] section 2.5.2 the delete
instruction is set by setting the TTL to 0, the CLass to ANY, the instruction is set by setting the TTL to 0, the CLass to ANY, the
RDLENGTH to 0 and the RDATA MUST be empty. RDLENGTH to 0 and the RDATA MUST be empty.
4.6. Securing the Control Channel between HNA and DM 4.6. Securing the Control Channel between Homenet Naming Authority
(HNA) and Distribution Master (DM)
The control channel between the HNA and the DM MUST be secured at The control channel between the HNA and the DM MUST be secured at
both the HNA and the DM. both the HNA and the DM.
Secure protocols (like TLS [RFC5246] / DTLS [RFC6347]) SHOULD be used Secure protocols (like TLS [RFC5246] / DTLS [RFC6347]) SHOULD be used
to secure the transactions between the DM and the HNA. to secure the transactions between the DM and the HNA.
The advantage of TLS/DTLS is that this technology is widely deployed, The advantage of TLS/DTLS is that this technology is widely deployed,
and most of the devices already embed TLS/DTLS libraries, possibly and most of the devices already embed TLS/DTLS libraries, possibly
also taking advantage of hardware acceleration. Further, TLS/DTLS also taking advantage of hardware acceleration. Further, TLS/DTLS
provides authentication facilities and can use certificates to provides authentication facilities and can use certificates to
authenticate the DM and the HNA. On the other hand, using TLS/DTLS mutually authenticate the DM and HNA at the applicationlayer,
requires implementing DNS exchanges over TLS/DTLS, as well as a new including available API. On the other hand, using TLS/DTLS requires
service port. This document RECOMMENDS this option. implementing DNS exchanges over TLS/DTLS, as well as a new service
port.
The HNA SHOULD authenticate inbound connections from the DM using The HNA SHOULD authenticate inbound connections from the DM using
standard mechanisms, such as a public certificate with baked-in root standard mechanisms, such as a public certificate with baked-in root
certificates on the HNA, or via DANE {!RFC6698}}. certificates on the HNA, or via DANE {!RFC6698}}. The HNA is expected
to be provisioned with a connection to the DM by the manufacturer, or
during some user-initiated onboarding process, see Section 12.
The DM SHOULD authenticate the HNA and check that inbound messages The DM SHOULD authenticate the HNA and check that inbound messages
are from the appropriate client. The DM MAY use a self-signed CA are from the appropriate client. The DM MAY use a self-signed CA
certificate mechanism per HNA, or public certificates for this certificate mechanism per HNA, or public certificates for this
purpose. purpose.
IPsec [RFC4301] IKEv2 [RFC7296] MAY also be used to secure IPsec [RFC4301] and IKEv2 [RFC7296] were considered. They would need
transactions between the HNA and the DM. Similarly to TLS/DTLS, most to operate in transport mode, and the authenticated end points would
HNAs already embed an IPsec stack, and IKEv2 supports multiple need to be visible to the applications, and this is not commonly
authentication mechanisms via the EAP framework. In addition, IPsec available at the time of this writing.
can be used to protect DNS exchanges between the HNA and the DM
without any modifications of the DNS server or client. DNS
integration over IPsec only requires an additional security policy in
the Security Policy Database (SPD). One disadvantage of IPsec is
that NATs and firewall traversal may be problematic. However, in our
case, the HNA is connected to the Internet, and IPsec communication
between the HNA and the DM should not be impacted by middle boxes.
How the PSK can be used by any of the TSIG, TLS/DTLS or IPsec A pure DNS solution using TSIG and/or SIG(0) to authenticate message
protocols: Authentication based on certificates implies a mutual was also considered. Section 12 envisions one mechanism would
authentication and thus requires the HNA to manage a private key, a involve the end user, with a browser, signing up to a service
public key, or certificates, as well as Certificate Authorities. provider, with a resulting OAUTH2 token to be provided to the HNA. A
This adds complexity to the configuration especially on the HNA side. way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0)
For this reason, we RECOMMEND that the HNA MAY use PSK or certificate space seems overly problematic, and so the enrollment protocol using
based authentication, and that the DM MUST support PSK and web APIs was determined to be easier to implement at scale.
certificate based authentication.
Note also that authentication of message exchanges between the HNA Note also that authentication of message exchanges between the HNA
and the DM SHOULD NOT use the external IP address of the HNA to index and the DM SHOULD NOT use the external IP address of the HNA to index
the appropriate keys. As detailed in Section 10, the IP addresses of the appropriate keys. As detailed in Section 10, the IP addresses of
the DM and the Hidden Primary are subject to change, for example the DM and the Hidden Primary are subject to change, for example
while the network is being renumbered. This means that the necessary while the network is being renumbered. This means that the necessary
keys to authenticate transaction SHOULD NOT be indexed using the IP keys to authenticate transaction SHOULD NOT be indexed using the IP
address, and SHOULD be resilient to IP address changes. address, and SHOULD be resilient to IP address changes. This should
apply to any OAUTH2 token produced as envisioned by Section 12.
4.7. Implementation Tips 4.7. Implementation Tips
The Hidden Primary Server on the HNA differs from a regular The Hidden Primary Server on the HNA differs from a regular
authoritative server for the home network due to: authoritative server for the home network due to:
o Interface Binding: the Hidden Primary Server will almost certainly o Interface Binding: the Hidden Primary Server will almost certainly
listen on the WAN Interface, whereas a regular authoritative listen on the WAN Interface, whereas a regular authoritative
server for the home network would listen on the internal home server for the home network would listen on the internal home
network interface. network interface.
skipping to change at page 19, line 41 skipping to change at page 19, line 51
DNS server may be hard to maintain with HNAs, and thus may be easier DNS server may be hard to maintain with HNAs, and thus may be easier
to establish with the Outsourcing Infrastructure. In fact, the to establish with the Outsourcing Infrastructure. In fact, the
Public Authoritative Server(s) may use Automating DNSSEC Delegation Public Authoritative Server(s) may use Automating DNSSEC Delegation
Trust Maintenance [RFC7344]. Trust Maintenance [RFC7344].
9. Homenet Reverse Zone 9. Homenet Reverse Zone
The Public Homenet Zone is associated to a Registered Homenet Domain The Public Homenet Zone is associated to a Registered Homenet Domain
and the ownership of that domain requires a specific registration and the ownership of that domain requires a specific registration
from the end user as well as the HNA being provisioned with some from the end user as well as the HNA being provisioned with some
authentication credentials . Such steps are mandatory unless the authentication credentials . Such steps are mandatory unless the
Outsourcing Infrastructure has some other means to authenticate the Outsourcing Infrastructure has some other means to authenticate the
HNA. Such situation may occur, for example, when the ISP provides HNA. Such situation may occur, for example, when the ISP provides
the Homenet Domain as well as the Outsourcing Infrastructure. In the Homenet Domain as well as the Outsourcing Infrastructure. In
this case, the HNA may be authenticated by the physical link layer, this case, the HNA may be authenticated by the physical link layer,
in which case the authentication of the HNA may be performed without in which case the authentication of the HNA may be performed without
additional provisioning of the HNA. While this may be not so common additional provisioning of the HNA. While this may be not so common
for the Public Homenet Zone, this situation is expected to be quite for the Public Homenet Zone, this situation is expected to be quite
common for the Reverse Homenet Zone. common for the Reverse Homenet Zone.
More specifically, a common case is that the upstream ISP provides More specifically, a common case is that the upstream ISP provides
skipping to change at page 20, line 19 skipping to change at page 20, line 27
between HNA and the Outsourcing infrastructure as described in between HNA and the Outsourcing infrastructure as described in
[I-D.ietf-homenet-naming-architecture-dhc-options]. [I-D.ietf-homenet-naming-architecture-dhc-options].
With this relation automatically configured, the synchronization With this relation automatically configured, the synchronization
between the Home network and the Outsourcing infrastructure happens between the Home network and the Outsourcing infrastructure happens
similarly as for the Public Homenet Zone described earlier in this similarly as for the Public Homenet Zone described earlier in this
document. document.
Note that for home networks hosted by multiple ISPs, each ISP Note that for home networks hosted by multiple ISPs, each ISP
provides only the Outsourcing Infrastructure of the reverse zones provides only the Outsourcing Infrastructure of the reverse zones
associated to the delegated prefix. associated to the delegated prefix. It is also likely that the DNS
It is also likely that the DNS exchanges will need to be performed on exchanges will need to be performed on dedicated interfaces as to be
dedicated interfaces as to be accepted by the ISP. More accepted by the ISP. More specifically, the reverse zone associated
specifically, the reverse zone associated to prefix 1 will not be to prefix 1 will not be possible to be performs by the HNA using an
possible to be performs by the HNA using an IP address that belongs IP address that belongs to prefix 2. Such constraints does not raise
to prefix 2. Such constraints does not raise major concerns either major concerns either for hot standby or load sharing configuration.
for hot standby or load sharing configuration.
With IPv6, the domain space for IP addresses is so large that reverse With IPv6, the domain space for IP addresses is so large that reverse
zone may be confronted with scalability issues. How the reverse zone zone may be confronted with scalability issues. How the reverse zone
is generated is out of scope of this document. is generated is out of scope of this document.
[I-D.howard-dnsop-ip6rdns] provides guidance on how to address [I-D.howard-dnsop-ip6rdns] provides guidance on how to address
scalability issues. scalability issues.
10. Renumbering 10. Renumbering
This section details how renumbering is handled by the Hidden Primary This section details how renumbering is handled by the Hidden Primary
skipping to change at page 22, line 42 skipping to change at page 22, line 46
for using IP addresses instead of names is generally to reach an for using IP addresses instead of names is generally to reach an
internal interface that is not designated by a FQDN, and to avoid internal interface that is not designated by a FQDN, and to avoid
potential bootstrap problems. Such scenarios are considered as out potential bootstrap problems. Such scenarios are considered as out
of scope in the case of home networks. of scope in the case of home networks.
11. Operational considerations for Offline/Disconnected resolution 11. Operational considerations for Offline/Disconnected resolution
This section is non-normative. It provides suggestions on This section is non-normative. It provides suggestions on
operational consideration. TBD. operational consideration. TBD.
12. Privacy Considerations 12. provisioning of the Homenet Naming Authority (HNA)
This document does not deal with how the HNA is provisioned with a
trusted relationship to the Distribution Master for the forward zone.
Provisioning of the relationship with an ISP-connection specific
Distribution Master for reverse zones is dealt with in
[I-D.ietf-homenet-naming-architecture-dhc-options]
This section details what needs to be provisioned into the HNA and
serves as a requirements statement for mechanisms.
13. Privacy Considerations
Outsourcing the DNS Authoritative service from the HNA to a third Outsourcing the DNS Authoritative service from the HNA to a third
party raises a few privacy related concerns. party raises a few privacy related concerns.
The Public Homenet Zone contains a full description of the services The Public Homenet Zone contains a full description of the services
hosted in the network. These services may not be expected to be hosted in the network. These services may not be expected to be
publicly shared although their names remain accessible through the publicly shared although their names remain accessible through the
Internet. Even though DNS makes information public, the DNS does not Internet. Even though DNS makes information public, the DNS does not
expect to make the complete list of services public. In fact, making expect to make the complete list of services public. In fact, making
information public still requires the key (or FQDN) of each service information public still requires the key (or FQDN) of each service
skipping to change at page 23, line 31 skipping to change at page 23, line 47
service, they also limit the scope of the scan space. service, they also limit the scope of the scan space.
In addition to the Public Homenet Zone, the third party can also In addition to the Public Homenet Zone, the third party can also
monitor the traffic associated with the Public Homenet Zone. This monitor the traffic associated with the Public Homenet Zone. This
traffic may provide an indication of the services an end user traffic may provide an indication of the services an end user
accesses, plus how and when they use these services. Although, accesses, plus how and when they use these services. Although,
caching may obfuscate this information inside the home network, it is caching may obfuscate this information inside the home network, it is
likely that outside your home network this information will not be likely that outside your home network this information will not be
cached. cached.
13. Security Considerations 14. Security Considerations
The Homenet Naming Architecture described in this document solves The Homenet Naming Architecture described in this document solves
exposing the HNA's DNS service as a DoS attack vector. exposing the HNA's DNS service as a DoS attack vector.
13.1. HNA DM channels 14.1. HNA DM channels
The HNA DM channels are specified to include their own security The HNA DM channels are specified to include their own security
mechanisms that are designed to provide the minimum attacke surface, mechanisms that are designed to provide the minimum attacke surface,
and to authenticate transactions where necessary. and to authenticate transactions where necessary.
Note that in the case of the Reverse Homenet Zone, the data is less Note that in the case of the Reverse Homenet Zone, the data is less
subject to attacks than in the Public Homenet Zone. In addition, the subject to attacks than in the Public Homenet Zone. In addition, the
HNA and the DM MAY belong to the same administrative domain, i.e. the HNA and the DM MAY belong to the same administrative domain, i.e. the
ISP. More specifically, the WAN interface is located in the ISP ISP. More specifically, the WAN interface is located in the ISP
network. As a result, if provisioned using DHCPv6, the security network. As a result, if provisioned using DHCPv6, the security
credential may not even transit in the home network. On the other credential may not even transit in the home network. On the other
hand, if the HNA is not hosted at the border of the home network, the hand, if the HNA is not hosted at the border of the home network, the
credential may rely on the security associated to DHCPv6. Even if credential may rely on the security associated to DHCPv6. Even if
HNA and DM are in the same administrative domain it is strongly HNA and DM are in the same administrative domain it is strongly
RECOMMENDED to use a secure channel. RECOMMENDED to use a secure channel.
13.2. Names are less secure than IP addresses 14.2. Names are less secure than IP addresses
This document describes how an end user can make their services and This document describes how an end user can make their services and
devices from his home network reachable on the Internet by using devices from his home network reachable on the Internet by using
names rather than IP addresses. This exposes the home network to names rather than IP addresses. This exposes the home network to
attackers, since names are expected to include less entropy than IP attackers, since names are expected to include less entropy than IP
addresses. In fact, with IP addresses, the Interface Identifier is addresses. In fact, with IP addresses, the Interface Identifier is
64 bits long leading to up to 2^64 possibilities for a given 64 bits long leading to up to 2^64 possibilities for a given
subnetwork. This is not to mention that the subnet prefix is also of subnetwork. This is not to mention that the subnet prefix is also of
64 bits long, thus providing up to 2^64 possibilities. On the other 64 bits long, thus providing up to 2^64 possibilities. On the other
hand, names used either for the home network domain or for the hand, names used either for the home network domain or for the
devices present less entropy (livebox, router, printer, nicolas, devices present less entropy (livebox, router, printer, nicolas,
jennifer, ...) and thus potentially exposes the devices to dictionary jennifer, ...) and thus potentially exposes the devices to dictionary
attacks. attacks.
13.3. Names are less volatile than IP addresses 14.3. Names are less volatile than IP addresses
IP addresses may be used to locate a device, a host or a service. IP addresses may be used to locate a device, a host or a service.
However, home networks are not expected to be assigned a time However, home networks are not expected to be assigned a time
invariant prefix by ISPs. As a result, observing IP addresses only invariant prefix by ISPs. As a result, observing IP addresses only
provides some ephemeral information about who is accessing the provides some ephemeral information about who is accessing the
service. On the other hand, names are not expected to be as volatile service. On the other hand, names are not expected to be as volatile
as IP addresses. As a result, logging names over time may be more as IP addresses. As a result, logging names over time may be more
valuable than logging IP addresses, especially to profile an end valuable than logging IP addresses, especially to profile an end
user's characteristics. user's characteristics.
PTR provides a way to bind an IP address to a name. In that sense, PTR provides a way to bind an IP address to a name. In that sense,
responding to PTR DNS queries may affect the end user's privacy. For responding to PTR DNS queries may affect the end user's privacy. For
that reason end users may choose not to respond to PTR DNS queries that reason end users may choose not to respond to PTR DNS queries
and MAY instead return a NXDOMAIN response. and MAY instead return a NXDOMAIN response.
13.4. DNS Reflection Attacks 14.4. DNS Reflection Attacks
An attacker performs a reflection attack when it sends traffic to one An attacker performs a reflection attack when it sends traffic to one
or more intermediary nodes (reflectors), that in turn send back or more intermediary nodes (reflectors), that in turn send back
response traffic to the victim. Motivations for using an response traffic to the victim. Motivations for using an
intermediary node might be anonymity of the attacker, as well as intermediary node might be anonymity of the attacker, as well as
amplification of the traffic. Typically, when the intermediary node amplification of the traffic. Typically, when the intermediary node
is a DNSSEC server, the attacker sends a DNSSEC query and the victim is a DNSSEC server, the attacker sends a DNSSEC query and the victim
is likely to receive a DNSSEC response. This section analyzes how is likely to receive a DNSSEC response. This section analyzes how
the different components may be involved as a reflector in a the different components may be involved as a reflector in a
reflection attack. Section 13.5 considers the Hidden Primary, reflection attack. Section 14.5 considers the Hidden Primary,
Section 13.6 the Synchronization Server, and Section 13.7 the Public Section 14.6 the Synchronization Server, and Section 14.7 the Public
Authoritative Server(s). Authoritative Server(s).
13.5. Reflection Attack involving the Hidden Primary 14.5. Reflection Attack involving the Hidden Primary
With the specified architecture, the Hidden Primary is only expected With the specified architecture, the Hidden Primary is only expected
to receive DNS queries of type SOA, AXFR or IXFR. This section to receive DNS queries of type SOA, AXFR or IXFR. This section
analyzes how these DNS queries may be used by an attacker to perform analyzes how these DNS queries may be used by an attacker to perform
a reflection attack. a reflection attack.
DNS queries of type AXFR and IXFR use TCP and as such are less DNS queries of type AXFR and IXFR use TCP and as such are less
subject to reflection attacks. This makes SOA queries the only subject to reflection attacks. This makes SOA queries the only
remaining practical vector of attacks for reflection attacks, based remaining practical vector of attacks for reflection attacks, based
on UDP. on UDP.
skipping to change at page 26, line 24 skipping to change at page 26, line 38
may have its legitimate query rejected is higher. If a legitimate may have its legitimate query rejected is higher. If a legitimate
SOA is discarded, the secondary will re-send SOA query every "retry SOA is discarded, the secondary will re-send SOA query every "retry
time" second until "expire time" seconds occurs, where "retry time" time" second until "expire time" seconds occurs, where "retry time"
and "expire time" have been defined in the SOA. and "expire time" have been defined in the SOA.
As a result, it is RECOMMENDED to set rate limiting policies to As a result, it is RECOMMENDED to set rate limiting policies to
protect HNA resources. If a flood lasts more than the expired time protect HNA resources. If a flood lasts more than the expired time
defined by the SOA, it is RECOMMENDED to re-initiate a defined by the SOA, it is RECOMMENDED to re-initiate a
synchronization between the Hidden Primary and the secondaries. synchronization between the Hidden Primary and the secondaries.
13.6. Reflection Attacks involving the DM 14.6. Reflection Attacks involving the DM
The DM acts as a secondary coupled with the Hidden Primary. The The DM acts as a secondary coupled with the Hidden Primary. The
secondary expects to receive NOTIFY query, SOA responses, AXFR and secondary expects to receive NOTIFY query, SOA responses, AXFR and
IXFR responses from the Hidden Primary. IXFR responses from the Hidden Primary.
Sending a NOTIFY query to the secondary generates a NOTIFY response Sending a NOTIFY query to the secondary generates a NOTIFY response
as well as initiating an SOA query exchange from the secondary to the as well as initiating an SOA query exchange from the secondary to the
Hidden Primary. As mentioned in [RFC1996], this is a known "benign Hidden Primary. As mentioned in [RFC1996], this is a known "benign
denial of service attack". As a result, the DM SHOULD enforce rate denial of service attack". As a result, the DM SHOULD enforce rate
limiting on sending SOA queries and NOTIFY responses to the Hidden limiting on sending SOA queries and NOTIFY responses to the Hidden
Primary. Most likely, when the secondary is flooded with valid and Primary. Most likely, when the secondary is flooded with valid and
signed NOTIFY queries, it is under a replay attack which is discussed signed NOTIFY queries, it is under a replay attack which is discussed
in Section 13.9. The key thing here is that the secondary is likely in Section 14.9. The key thing here is that the secondary is likely
to be designed to be able to process much more traffic than the to be designed to be able to process much more traffic than the
Hidden Primary hosted on a HNA. Hidden Primary hosted on a HNA.
This paragraph details how the secondary may limit the NOTIFY This paragraph details how the secondary may limit the NOTIFY
queries. Because the Hidden Primary may be renumbered, the secondary queries. Because the Hidden Primary may be renumbered, the secondary
SHOULD NOT perform permanent IP filtering based on IP addresses. In SHOULD NOT perform permanent IP filtering based on IP addresses. In
addition, a given secondary may be shared among multiple Hidden addition, a given secondary may be shared among multiple Hidden
Primaries which make filtering rules based on IP harder to set. The Primaries which make filtering rules based on IP harder to set. The
time at which a NOTIFY is sent by the Hidden Primary is not time at which a NOTIFY is sent by the Hidden Primary is not
predictable. However, a flood of NOTIFY messages may be easily predictable. However, a flood of NOTIFY messages may be easily
detected, as a NOTIFY originated from a given Homenet Zone is detected, as a NOTIFY originated from a given Homenet Zone is
expected to have a very limited number of unique source IP addresses, expected to have a very limited number of unique source IP addresses,
even when renumbering is occurring. As a result, the secondary, MAY even when renumbering is occurring. As a result, the secondary, MAY
rate limit incoming NOTIFY queries. rate limit incoming NOTIFY queries.
On the Hidden Primary side, it is recommended that the Hidden Primary On the Hidden Primary side, it is recommended that the Hidden Primary
sends a NOTIFY as long as the zone has not been updated by the sends a NOTIFY as long as the zone has not been updated by the
secondary. Multiple SOA queries may indicate the secondary is under secondary. Multiple SOA queries may indicate the secondary is under
attack. attack.
13.7. Reflection Attacks involving the Public Authoritative Servers 14.7. Reflection Attacks involving the Public Authoritative Servers
Reflection attacks involving the Public Authoritative Server(s) are Reflection attacks involving the Public Authoritative Server(s) are
similar to attacks on any Outsourcing Infrastructure. This is not similar to attacks on any Outsourcing Infrastructure. This is not
specific to the architecture described in this document, and thus are specific to the architecture described in this document, and thus are
considered as out of scope. considered as out of scope.
In fact, one motivation of the architecture described in this In fact, one motivation of the architecture described in this
document is to expose the Public Authoritative Server(s) to attacks document is to expose the Public Authoritative Server(s) to attacks
instead of the HNA, as it is believed that the Public Authoritative instead of the HNA, as it is believed that the Public Authoritative
Server(s) will be better able to defend itself. Server(s) will be better able to defend itself.
13.8. Flooding Attack 14.8. Flooding Attack
The purpose of flooding attacks is mostly resource exhaustion, where The purpose of flooding attacks is mostly resource exhaustion, where
the resource can be bandwidth, memory, or CPU for example. the resource can be bandwidth, memory, or CPU for example.
One goal of the architecture described in this document is to limit One goal of the architecture described in this document is to limit
the surface of attack on the HNA. This is done by outsourcing the the surface of attack on the HNA. This is done by outsourcing the
DNS service to the Public Authoritative Server(s). By doing so, the DNS service to the Public Authoritative Server(s). By doing so, the
HNA limits its DNS interactions between the Hidden Primary and the HNA limits its DNS interactions between the Hidden Primary and the
DM. This limits the number of entities the HNA interacts with as DM. This limits the number of entities the HNA interacts with as
well as the scope of DNS exchanges - NOTIFY, SOA, AXFR, IXFR. well as the scope of DNS exchanges - NOTIFY, SOA, AXFR, IXFR.
The use of an authenticated channel with SIG(0) or TSIG between the The use of an authenticated channel with SIG(0) or TSIG between the
HNA and the DM, enables detection of illegitimate DNS queries, so HNA and the DM, enables detection of illegitimate DNS queries, so
appropriate action may be taken - like dropping the queries. If appropriate action may be taken - like dropping the queries. If
signatures are validated, then most likely, the HNA is under a replay signatures are validated, then most likely, the HNA is under a replay
attack, as detailed in Section 13.9 attack, as detailed in Section 14.9
In order to limit the resource required for authentication, it is In order to limit the resource required for authentication, it is
recommended to use TSIG that uses symmetric cryptography over SIG(0) recommended to use TSIG that uses symmetric cryptography over SIG(0)
that uses asymmetric cryptography. that uses asymmetric cryptography.
13.9. Replay Attack 14.9. Replay Attack
Replay attacks consist of an attacker either resending or delaying a Replay attacks consist of an attacker either resending or delaying a
legitimate message that has been sent by an authorized user or legitimate message that has been sent by an authorized user or
process. As the Hidden Primary and the DM use an authenticated process. As the Hidden Primary and the DM use an authenticated
channel, replay attacks are mostly expected to use forged DNS queries channel, replay attacks are mostly expected to use forged DNS queries
in order to provide valid traffic. in order to provide valid traffic.
From the perspective of an attacker, using a correctly authenticated From the perspective of an attacker, using a correctly authenticated
DNS query may not be detected as an attack and thus may generate a DNS query may not be detected as an attack and thus may generate a
response. Generating and sending a response consumes more resources response. Generating and sending a response consumes more resources
than either dropping the query by the defender, or generating the than either dropping the query by the defender, or generating the
query by the attacker, and thus could be used for resource exhaustion query by the attacker, and thus could be used for resource exhaustion
attacks. In addition, as the authentication is performed at the DNS attacks. In addition, as the authentication is performed at the DNS
layer, the source IP address could be impersonated in order to layer, the source IP address could be impersonated in order to
perform a reflection attack. perform a reflection attack.
Section 13.4 details how to mitigate reflection attacks and Section 14.4 details how to mitigate reflection attacks and
Section 13.8 details how to mitigate resource exhaustion. Both Section 14.8 details how to mitigate resource exhaustion. Both
sections assume a context of DoS with a flood of DNS queries. This sections assume a context of DoS with a flood of DNS queries. This
section suggests a way to limit the attack surface of replay attacks. section suggests a way to limit the attack surface of replay attacks.
As SIG(0) and TSIG use inception and expiration time, the time frame As SIG(0) and TSIG use inception and expiration time, the time frame
for replay attack is limited. SIG(0) and TSIG recommends a fudge for replay attack is limited. SIG(0) and TSIG recommends a fudge
value of 5 minutes. This value has been set as a compromise between value of 5 minutes. This value has been set as a compromise between
possibly loose time synchronization between devices and the valid possibly loose time synchronization between devices and the valid
lifetime of the message. As a result, better time synchronization lifetime of the message. As a result, better time synchronization
policies could reduce the time window of the attack. policies could reduce the time window of the attack.
skipping to change at page 28, line 37 skipping to change at page 29, line 5
hosted data hosted data
Deploying DNSSEC is recommended, since in some cases the information Deploying DNSSEC is recommended, since in some cases the information
stored in the DNS is used by the ISP or an IT department to grant stored in the DNS is used by the ISP or an IT department to grant
access. For example some servers may perform PTR DNS queries to access. For example some servers may perform PTR DNS queries to
grant access based on host names. DNSSEC mitigates lack of trust in grant access based on host names. DNSSEC mitigates lack of trust in
DNS, and it is RECOMMENDED to deploy DNSSEC on HNAs. DNS, and it is RECOMMENDED to deploy DNSSEC on HNAs.
->) ->)
14. IANA Considerations 15. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
15. Acknowledgment 16. Acknowledgment
The authors wish to thank Philippe Lemordant for its contributions on The authors wish to thank Philippe Lemordant for its contributions on
the early versions of the draft; Ole Troan for pointing out issues the early versions of the draft; Ole Troan for pointing out issues
with the IPv6 routed home concept and placing the scope of this with the IPv6 routed home concept and placing the scope of this
document in a wider picture; Mark Townsley for encouragement and document in a wider picture; Mark Townsley for encouragement and
injecting a healthy debate on the merits of the idea; Ulrik de Bie injecting a healthy debate on the merits of the idea; Ulrik de Bie
for providing alternative solutions; Paul Mockapetris, Christian for providing alternative solutions; Paul Mockapetris, Christian
Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on
HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC
capabilities of small devices; Simon Kelley for its feedback as capabilities of small devices; Simon Kelley for its feedback as
dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael
Abrahamson, Michael Richardson and Ray Bellis for their feedback on Abrahamson, Michael Richardson and Ray Bellis for their feedback on
handling different views as well as clarifying the impact of handling different views as well as clarifying the impact of
outsourcing the zone signing operation outside the HNA; Mark Andrew outsourcing the zone signing operation outside the HNA; Mark Andrew
and Peter Koch for clarifying the renumbering. and Peter Koch for clarifying the renumbering.
16. Annex 17. References
16.1. Envisioned deployment scenarios 17.1. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<https://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644,
DOI 10.17487/RFC6644, July 2012,
<https://www.rfc-editor.org/info/rfc6644>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
DOI 10.17487/RFC7010, September 2013,
<https://www.rfc-editor.org/info/rfc7010>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-Based Service Discovery
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
DOI 10.17487/RFC7558, July 2015,
<https://www.rfc-editor.org/info/rfc7558>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
17.2. Informative References
[I-D.howard-dnsop-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-dnsop-ip6rdns-00 (work in
progress), June 2014.
[I-D.ietf-homenet-naming-architecture-dhc-options]
Migault, D., Mrugalski, T., Griffiths, C., Weber, R., and
W. Cloetens, "DHCPv6 Options for Homenet Naming
Architecture", draft-ietf-homenet-naming-architecture-dhc-
options-06 (work in progress), June 2018.
[I-D.ietf-homenet-simple-naming]
Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
and Service Discovery Architecture", draft-ietf-homenet-
simple-naming-03 (work in progress), October 2018.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
Appendix A. Envisioned deployment scenarios
A number of deployment have been envisionned, this section aims at A number of deployment have been envisionned, this section aims at
providing a brief description. The use cases are not limitatives and providing a brief description. The use cases are not limitatives and
this section is not normative. this section is not normative.
16.1.1. CPE Vendor A.1. CPE Vendor
A specific vendor with specific relations with a registrar or a A specific vendor with specific relations with a registrar or a
registry may sell a CPE that is provisioned with provisioned domain registry may sell a CPE that is provisioned with provisioned domain
name. Such domain name does not need to be necessary human readable. name. Such domain name does not need to be necessary human readable.
One possible way is that the vendor also provisions the HNA with a One possible way is that the vendor also provisions the HNA with a
private and public keys as well as a certificate. Note that these private and public keys as well as a certificate. Note that these
keys are not expected to be used for DNSSEC signing. Instead these keys are not expected to be used for DNSSEC signing. Instead these
keys are solely used by the HNA to proceed to the authentication. keys are solely used by the HNA to proceed to the authentication.
Normally the keys should be necessary and sufficient to proceed to Normally the keys should be necessary and sufficient to proceed to
the authentication. The reason to combine the domain name and the the authentication. The reason to combine the domain name and the
key is that outsourcing infrastructure are likely handle names better key is that outsourcing infrastructure are likely handle names better
than keys and that domain names might be used as a login which than keys and that domain names might be used as a login which
enables the key to be regenerated. enables the key to be regenerated.
When the home network owner plugs the CPE at home, the relation When the home network owner plugs the CPE at home, the relation
between HNA and DM is expected to work out-of-the-box. between HNA and DM is expected to work out-of-the-box.
16.1.2. Agnostic CPE A.2. Agnostic CPE
An CPE that is not preconfigured may also take advanatge to the An CPE that is not preconfigured may also take advanatge to the
protocol defined in this document but some configuration steps will protocol defined in this document but some configuration steps will
be needed. be needed.
1. The owner of the home network buys a domain name to a registrar, 1. The owner of the home network buys a domain name to a registrar,
and as such creates an account on that registrar and as such creates an account on that registrar
2. Either the registrar is also providing the outsourcing 2. Either the registrar is also providing the outsourcing
infrastructure or the home network needs to create a specific infrastructure or the home network needs to create a specific
skipping to change at page 30, line 19 skipping to change at page 35, line 13
network to provide the public key gnerated by the HNA in a CSR. network to provide the public key gnerated by the HNA in a CSR.
o If the outsourcing infrastructure is not the registrar, then the o If the outsourcing infrastructure is not the registrar, then the
proof of ownership needs to be established using protocols like proof of ownership needs to be established using protocols like
ACME for example that will end in the generation of a certificate. ACME for example that will end in the generation of a certificate.
ACME is used here to the purpose of automating the generation of ACME is used here to the purpose of automating the generation of
the certificate, the CA may be a specific CA or the outsourcing the certificate, the CA may be a specific CA or the outsourcing
infrastructure. With that being done, the outsourcing infrastructure. With that being done, the outsourcing
infrastructure has a roof of ownership and can proceed as above. infrastructure has a roof of ownership and can proceed as above.
16.2. Example: Homenet Zone Appendix B. Example: Homenet Zone
This section is not normative and intends to illustrate how the HNA This section is not normative and intends to illustrate how the HNA
builds the Homenet Zone. builds the Homenet Zone.
As depicted in Figure 1, the Public Homenet Zone is hosted on the As depicted in Figure 1, the Public Homenet Zone is hosted on the
Public Authoritative Server(s), whereas the Homenet Zone is hosted on Public Authoritative Server(s), whereas the Homenet Zone is hosted on
the HNA. This section considers that the HNA builds the zone that the HNA. This section considers that the HNA builds the zone that
will be effectively published on the Public Authoritative Server(s). will be effectively published on the Public Authoritative Server(s).
In other words "Homenet to Public Zone transformation" is the In other words "Homenet to Public Zone transformation" is the
identity also commonly designated as "no operation" (NOP). identity also commonly designated as "no operation" (NOP).
skipping to change at page 32, line 34 skipping to change at page 37, line 34
performed on all zone files, i.e. for all Registered Homenet Domains. performed on all zone files, i.e. for all Registered Homenet Domains.
To limit thees updates when multiple Registered Homenet Domains are To limit thees updates when multiple Registered Homenet Domains are
involved, the HNA MAY fill all bindings in a specific zone file and involved, the HNA MAY fill all bindings in a specific zone file and
redirect all other zones to that zone. This can be achieved with redirect all other zones to that zone. This can be achieved with
redirecting mechanisms like CNAME {{RFC2181}}, {{RFC1034}}, DNAME redirecting mechanisms like CNAME {{RFC2181}}, {{RFC1034}}, DNAME
{{RFC6672}} or CNAME+DNAME {{I-D.sury-dnsext-cname-dname}}. This is {{RFC6672}} or CNAME+DNAME {{I-D.sury-dnsext-cname-dname}}. This is
an implementation issue to determine whether redirection mechanisms an implementation issue to determine whether redirection mechanisms
MAY be preferred for large Homenet Zones, or when the number of MAY be preferred for large Homenet Zones, or when the number of
Registered Homenet Domain becomes quite large. -->> Registered Homenet Domain becomes quite large. -->>
16.3. Example: HNA necessary parameters for outsourcing Appendix C. Example: HNA necessary parameters for outsourcing
This section specifies the various parameters required by the HNA to This section specifies the various parameters required by the HNA to
configure the naming architecture of this document. This section is configure the naming architecture of this document. This section is
informational, and is intended to clarify the information handled by informational, and is intended to clarify the information handled by
the HNA and the various settings to be done. the HNA and the various settings to be done.
DM may be configured with the following parameters. These parameters DM may be configured with the following parameters. These parameters
are necessary to establish a secure channel between the HNA and the are necessary to establish a secure channel between the HNA and the
DM as well as to specify the DNS zone that is in the scope of the DM as well as to specify the DNS zone that is in the scope of the
communication: communication:
o DM: The associated FQDNs or IP addresses of the DM. IP addresses o DM: The associated FQDNs or IP addresses of the DM. IP addresses
are optional and the FQDN is sufficient. To secure the binding are optional and the FQDN is sufficient. To secure the binding
name and IP addresses, a DNSSEC exchange is required. Otherwise, name and IP addresses, a DNSSEC exchange is required. Otherwise,
the IP addresses should be entered manually. the IP addresses should be entered manually.
o Authentication Method: How the HNA authenticates itself to the DM. o Authentication Method: How the HNA authenticates itself to the DM.
This MAY depend on the implementation but this should cover at
least IPsec, DTLS and TSIG
o Authentication data: Associated Data. PSK only requires a single o Authentication data: Associated Data. PSK only requires a single
argument. If other authentication mechanisms based on argument. If other authentication mechanisms based on
certificates are used, then HNA private keys, certificates and certificates are used, then HNA private keys, certificates and
certification authority should be specified. certification authority should be specified.
o Public Authoritative Server(s): The FQDN or IP addresses of the o Public Authoritative Server(s): The FQDN or IP addresses of the
Public Authoritative Server(s). It MAY correspond to the data Public Authoritative Server(s). It MAY correspond to the data
that will be set in the NS RRsets and SOA of the Homenet Zone. IP that will be set in the NS RRsets and SOA of the Homenet Zone. IP
addresses are optional and the FQDN is sufficient. To secure the addresses are optional and the FQDN is sufficient. To secure the
skipping to change at page 33, line 43 skipping to change at page 38, line 39
associated with the Registered Homenet Domain. Multiple Public associated with the Registered Homenet Domain. Multiple Public
Authoritative Server(s) may be provided. Authoritative Server(s) may be provided.
Two possible methods of providing the required information would be: Two possible methods of providing the required information would be:
JSON for forward zones should be standardized in a similar way to JSON for forward zones should be standardized in a similar way to
zone file layout in RFC1035 zone file layout in RFC1035
DHCP for reverse zones needs a separate draft DHCP for reverse zones needs a separate draft
17. References
17.1. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, DOI 10.17487/RFC1033, November 1987,
<https://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644,
DOI 10.17487/RFC6644, July 2012,
<https://www.rfc-editor.org/info/rfc6644>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
DOI 10.17487/RFC7010, September 2013,
<https://www.rfc-editor.org/info/rfc7010>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-Based Service Discovery
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
DOI 10.17487/RFC7558, July 2015,
<https://www.rfc-editor.org/info/rfc7558>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
<https://www.rfc-editor.org/info/rfc8375>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
17.2. Informative References
[I-D.howard-dnsop-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-dnsop-ip6rdns-00 (work in
progress), June 2014.
[I-D.ietf-homenet-naming-architecture-dhc-options]
Migault, D., Mrugalski, T., Griffiths, C., Weber, R., and
W. Cloetens, "DHCPv6 Options for Homenet Naming
Architecture", draft-ietf-homenet-naming-architecture-dhc-
options-06 (work in progress), June 2018.
[I-D.ietf-homenet-simple-naming]
Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
and Service Discovery Architecture", draft-ietf-homenet-
simple-naming-03 (work in progress), October 2018.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8275 Trans Canada Route 8275 Trans Canada Route
Saint Laurent, QC 4S 0B6 Saint Laurent, QC 4S 0B6
Canada Canada
EMail: daniel.migault@ericsson.com EMail: daniel.migault@ericsson.com
Ralf Weber Ralf Weber
 End of changes. 52 change blocks. 
312 lines changed or deleted 325 lines changed or added

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