Hosting Encrypted DNS Forwarders on CPEs
draft-rbw-add-encrypted-dns-forwarders-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Mohamed Boucadair , Dan Wing | ||
| Last updated | 2024-11-04 | ||
| Replaces | draft-reddy-add-delegated-credentials | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rbw-add-encrypted-dns-forwarders-02
Adaptive DNS Discovery T. Reddy
Internet-Draft Nokia
Intended status: Informational M. Boucadair
Expires: 8 May 2025 Orange
D. Wing
Cloud Software Group
4 November 2024
Hosting Encrypted DNS Forwarders on CPEs
draft-rbw-add-encrypted-dns-forwarders-02
Abstract
Typical connectivity service offerings based upon on Customer Premise
Equipment (CPEs) involve DNS forwarders on the CPE for various
reasons (offer local services, control the scope/content of
information in DNS, ensure better dependability for local service,
provide control to users, etc.). Upgrading DNS to use encrypted
transports introduces deployment complications as to how to sustain
current offerings with local services. Solutions are needed to ease
operating DNS forwarders in CPEs while allowing to make use of
encrypted DNS capabilities.
This document describes the problem and to what extent existing
solutions can or can't be used for these deployments. For example,
Star certificates and name constraints extension suffer from the
problem of deploying a new feature to CAs, TLS clients, and servers.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Adaptive DNS Discovery
Working Group mailing list (add@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/add/.
Source for this draft and an issue tracker can be found at
https://github.com/boucadair/encrypted-dns-forwarders.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Reddy, et al. Expires 8 May 2025 [Page 1]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
4. Proxied DNS In Local Networks . . . . . . . . . . . . . . . . 4
5. Deploying Encrypted DNS Forwarder in Local Networks . . . . . 5
5.1. Discovery of Designated Resolvers (DDR) . . . . . . . . . 5
5.2. Discovery of Network-designated Resolvers (DNR) . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Example of Delegated Certificate Issuance . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Reddy, et al. Expires 8 May 2025 [Page 2]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
1. Introduction
Customer Premises Equipment (CPEs, also called Home Routers) are a
critical component of the home network, and their security is
essential to protecting the devices and data that are connected to
them. For example, the prpl Foundation [prpl] has developed a number
of initiatives to promote home router security and hardening. The
prplWrt project [prplwrt] is an initiative in prpl Foundation that
aims to improve the security and performance of open-source router
firmware, such as OpenWrt [openwrt]. OpenWrt is an open-source
operating system that is designed to run on a wide range of routers
and embedded devices. It now includes support for containerization
technology such as Docker, making it possible to run containerized
applications on a home router. Further, DNS providers have optimized
the encrypted DNS forwarder to run in a container in home routers.
However, upgrading DNS to use encrypted transports (e.g., DNS over
HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], and DNS over
QUIC (DoQ) [RFC9250]) introduces deployment complications as to how
to sustain current offerings with local services.
This document describes the problem encountered to host encrypted DNS
resolvers in managed CPEs. It also identifies a set of requirements
and discusses to what extent existing solutions can (or can't) meet
these requirements.
2. Scope
This document describes the current state of the art for deploying
encrypted DNS on customer premise equipment. New mechanisms should
be described in separate documents.
The document does not focus on generic considerations related to
deploying DNS proxies. The reader may refer to [RFC5625] for such
matters.
The mechanism for the client to authenticate the local encrypted DNS
server is out of scope of this draft (see [I-D.rbw-home-servers]).
This draft details how such an authenticated local encrypted DNS
server would be used.
3. Conventions and Definitions
This document makes use of the terms defined in [RFC9499].
The following additional terms are used:
DHCP: refers to both DHCPv4 and DHCPv6.
Reddy, et al. Expires 8 May 2025 [Page 3]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
Do53: refers to unencrypted DNS.
DNR: refers to the Discovery of Network-designated Resolvers
procedure defined in [RFC9463].
DDR: refers to the Discovery of Designated Resolvers procedure
defined in [RFC9462].
Encrypted DNS: refers to a scheme where DNS exchanges are
transported over an encrypted channel. Examples of encrypted DNS
are DoH [RFC8484], DoT [RFC7858], and DoQ [RFC9250].
Managed CPE: refers to a CPE that is managed by an ISP or CPE vendor
or Security Service Provider.
4. Proxied DNS In Local Networks
Figure 1 shows various network setups where the CPE embeds a caching
encrypted DNS forwarder.
(a)
.--------------. .-------------.
| | | ISP |
Host---| LAN CPE------| DNS Resolver |
| | | |'-------------'
| '--------------'| | |
| |<=DNR=>| |
|<========DNR========>| | |
|<===Encrypted DNS===>|<=Encrypted DNS=>|
| | |
(b)
.--------------. .------------.
| | | | 3rd Party
Host---| LAN CPE------| ISP |------DNS Resolver
| | | | | |
| '--------------'| |'------------' |
| |<=DNR=>| |
|<========DNR========>| | |
|<===Encrypted DNS===>|<========Encrypted DNS========>|
| | |
Figure 1: Proxied Encrypted DNS Sessions
For all the cases shown in Figure 1, the CPE advertises itself as the
default DNS server to the hosts it serves in the LAN. The CPE relies
upon DHCP or RA to advertise itself to internal hosts as the default
encrypted DNS forwarder using DNR. When receiving a DNS request that
Reddy, et al. Expires 8 May 2025 [Page 4]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
a CPE cannot handle locally, the CPE forwards the request to an
upstream encrypted DNS. The upstream encrypted DNS can be hosted by
the ISP or provided by a third party.
Such a forwarder presence is required for (but not limuted to):
* IPv4 service continuity purposes (e.g., Section 3.1 of [RFC8585]).
* Supporting advanced services within a local network such as:
- malware filtering,
- parental control,
- Manufacturer Usage Description (MUD) [RFC8520] to only allow
intended communications to and from an IoT device, and
- offer multicast DNS proxy service for the ".local" domain
[RFC6762].
When the CPE behaves as a DNS forwarder, DNS communications can be
decomposed into two legs to resolve queries:
* The leg between an internal host and the CPE.
* The leg between the CPE and an upstream DNS resolver.
5. Deploying Encrypted DNS Forwarder in Local Networks
This section discusses some deployment challenges to host an
encrypted DNS forwarder within a local network.
5.1. Discovery of Designated Resolvers (DDR)
DDR requires proving possession of an IP address, as the DDR
certificate contains the server's IPv4 and IPv6 addresses and is
signed by a Certification Authority (CA). DDR is constrained to
public IP addresses because (WebPKI) CAs will not sign special-
purpose IP addresses [RFC6890], most notably IPv4 private-use
[RFC1918], IPv4 shared address [RFC6598], or IPv6 Unique-Local
[RFC8190] address space.
A tempting solution for enabling an encrypted DNS forwarder with DDR
is to use the CPE's WAN IP address for DDR and prove possession of
that IP address. However, the CPE's WAN IPv4 address will not be a
public IPv4 address if the CPE is behind another layer of NAT (either
Carrier Grade NAT (CGN) or another on-premise NAT), reducing the
success of this mechanism to CPE's WAN IPv6 address.
Reddy, et al. Expires 8 May 2025 [Page 5]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
Also, if the ISP renumbers the subscriber's network suddenly (rather
than slow IPv6 renumbering described in [RFC4192]), encrypted DNS
service will be delayed until that new certificate is acquired.
5.2. Discovery of Network-designated Resolvers (DNR)
DNR requires proving possession of a domain name as the encrypted
resolver's certificate contains the FQDN. For example, the entity
(e.g., ISP or network administrator) managing the CPE would assign a
unique FQDN to the CPE. There are two mechanisms for the CPE to
obtain the certificate for the FQDN: using one of its WAN IP
addresses or requesting its signed certificate from an Internet-
facing server used for remote CPE management (e.g., the Auto
Configuration Server (ACS) in the CPE WAN Management Protocol
[TR-069]).
If the CPE's WAN IP address is used, the CPE needs a public IPv4 or a
global unicast IPv6 address together with DNS A or AAAA records
pointing to that CPE's WAN address to prove possession of the DNS
name to obtain a (WebPKI) CA-signed certificate. That is, the CPE
fulfills the DNS or HTTP challenge discussed in Automatic Certificate
Management Environment (ACME) [RFC8555]. However, a CPE's WAN
address will not be a public IPv4 address if the CPE is behind
another layer of NAT (either a CGN or another on-premise NAT),
reducing the success of this mechanism to a CPE's WAN IPv6 address.
If the ISP renumbers the subscriber's network, the DNS record will
also need to expire and changed to reflect the new IP address.
6. Security Considerations
DNR-related security considerations are discussed in Section 7 of
[RFC9463]. Likewise, DDR-related security considerations are
discussed in Section 7 of [RFC9462].
The communication between the CPE and endpoints is encrypted using
mechanisms such as WPA2/3, and any communication with the DNS server
co-located on the CPE is also protected. However, the client does
not know whether the DNS server is co-located on the CPE or not. If
the client uses clear text DNS (i.e., Do53), it will assume that the
DNS messages are susceptible to pervasive monitoring. For instance,
in an Enterprise deployment, multiple network devices could exist
between an endpoint and the CPE; hosting an encrypted DNS server on
the CPE minimizes the impact of a breach, which is an essential zero
trust principle. Furthermore, the client and user would be able to
identify the entity hosting the encrypted DNS server using the ADN
assigned to it.
Reddy, et al. Expires 8 May 2025 [Page 6]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/rfc/rfc9462>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/rfc/rfc9463>.
8.2. Informative References
[I-D.rbw-home-servers]
Reddy.K, T., Boucadair, M., and D. Wing, "Identifying and
Authenticating Home Servers: Requirements and Solution
Analysis", Work in Progress, Internet-Draft, draft-rbw-
home-servers-00, 19 September 2024,
<https://datatracker.ietf.org/doc/html/draft-rbw-home-
servers-00>.
[I-D.reddy-add-delegated-credentials]
Reddy.K, T., Boucadair, M., Wing, D., and S. Jain,
"Delegated Credentials to Host Encrypted DNS Forwarders on
CPEs", Work in Progress, Internet-Draft, draft-reddy-add-
delegated-credentials-03, 1 December 2023,
<https://datatracker.ietf.org/doc/html/draft-reddy-add-
delegated-credentials-03>.
[openwrt] OpenWrt, "OpenWrt Project", <https://openwrt.org/>.
[prpl] Prpl Foundation, "Prpl Foundation",
<https://prplfoundation.org/>.
[prplwrt] Prpl Foundation, "Prpl WRT",
<https://prplfoundation.org/project/prplwrt/>.
Reddy, et al. Expires 8 May 2025 [Page 7]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[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/rfc/rfc4192>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/rfc/rfc5625>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <https://www.rfc-editor.org/rfc/rfc6598>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/rfc/rfc6890>.
[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/rfc/rfc7858>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/rfc/rfc8190>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/rfc/rfc8520>.
Reddy, et al. Expires 8 May 2025 [Page 8]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/rfc/rfc8585>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/rfc/rfc9250>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>.
[TR-069] The Broadband Forum, "CPE WAN Management Protocol",
December 2018, <https://www.broadband-
forum.org/technical/download/TR-069.pdf>.
Appendix A. Example of Delegated Certificate Issuance
Let's consider that the encrypted DNS forwarder is hosted on a CPE
and provisioned by a service (e.g., ACS) in the operator's network.
Also, let's assume that each CPE is assigned a unique FQDN (e.g.,
"cpe-12345.example.com" where 12345 is a unique number).
It is best to ensure that such an FQDN does not carry any
Personally Identifiable Information (PII) or device identification
details like the customer number or device's serial number.
The CPE generates a public and private key-pair, builds a certificate
signing request (CSR), and sends the CSR to a service in the operator
managing the CPE. Upon receipt of the CSR, the operator's service
can utilize certificate management protocols like ACME [RFC8555] to
automate certificate management functions such as domain validation
procedure, certificate issuance, and certificate revocation.
The challenge with this technique is that the service will have to
communicate with the CA to issue certificates for millions of CPEs.
If an external CA is unable to issue a certificate in time or replace
an expired certificate, the service would no longer be able to
present a valid certificate to a CPE. When the service requests
certificate issuance for a large number of subdomains (e.g., millions
of CPEs), it may be treated as an attacker by the CA to overwhelm it.
Reddy, et al. Expires 8 May 2025 [Page 9]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
Furthermore, the short-lived certificates (e.g., certificates that
expire after 90 days) issued by the CA will have to be renewed
frequently. With short-lived certificates, there is a smaller time
window to renew a certificate and, therefore, a higher risk that a CA
outage will negatively affect the uptime of the encrypted DNS
forwarders on CPEs (and the services offered via these CPEs).
These challenges can be addressed by using protocols like ACME to
automate the certificate renewal process, ensuring certificates are
renewed well before expiration. Additionally, incorporating another
CA as a backup can provide redundancy and further mitigate the risk
of outages. By having a secondary CA, the service can switch to the
backup CA in case the primary CA is unavailable, thus maintaining
continuous service availability and reducing the risk of service
disruption.
It offers the additional advantage of improving the security of
Browser and CPE interactions. This ensures that HTTPS access to the
CPE is possible, allowing the device administrator to securely
communicate with and manage the CPE.
Acknowledgments
This draft is triggered by the discussion that occured at IETF#119
(Brisbane) about the need to frame the problem to be solved. Thanks
to all the participants to that discussion.
Acknowledgements from [I-D.reddy-add-delegated-credentials]: Thanks
to Neil Cook, Martin Thomson, Tommy Pauly, Benjamin Schwartz, and
Michael Richardson for the discussion and comments.
Authors' Addresses
Tirumaleswar Reddy
Nokia
Bangalore
Karnataka
India
Email: kondtir@gmail.com
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Reddy, et al. Expires 8 May 2025 [Page 10]
Internet-Draft Encrypted DNS Forwarders on CPEs November 2024
Dan Wing
Cloud Software Group Holdings, Inc.
Email: danwing@gmail.com
Reddy, et al. Expires 8 May 2025 [Page 11]