idnits 2.17.1 draft-stark-add-dns-forwarder-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-add-requirements], [I-D.ietf-add-dnr], [I-D.ietf-add-ddr]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 June 2021) is 1040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-01 == Outdated reference: A later version (-16) exists of draft-ietf-add-dnr-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD Working Group B. Stark 3 Internet-Draft AT&T 4 Intended status: Informational C. Box 5 Expires: 17 December 2021 BT 6 15 June 2021 8 Analysis of DNS Forwarder Scenario Relative to DDR and DNR 9 draft-stark-add-dns-forwarder-analysis-00 11 Abstract 13 This draft analyzes the behaviors that residential end users and home 14 network owners (e.g., parents of young children) might experience 15 when operating systems and clients support [I-D.ietf-add-ddr] and/or 16 [I-D.ietf-add-dnr] for discovery of encrypted DNS services and the CE 17 router of the home network offers itself as the Do53 resolver. This 18 use case is explicitly mentioned in [I-D.ietf-add-requirements] 19 Section 3.2 and has several requirements related to it. This draft 20 has two goals: determine if the analysis it provides is accurate and, 21 if it is accurate, determine if the behavior is acceptable to the WG 22 or if there should be changes to either of the discovery mechanisms. 24 Discussion Venues 26 This note is to be removed before publishing as an RFC. 28 Discussion of this document takes place on the mailing list 29 (add@ietf.org), which is archived at 30 https://mailarchive.ietf.org/arch/browse/add/. 32 Source for this draft and an issue tracker can be found at 33 https://github.com/bhstark2/dns-forwarder-analysis. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 17 December 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 69 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Scenario 1: No changes to CE router . . . . . . . . . . . 4 72 4.2. Scenario 2: CE router updated to provide DNR in DHCP/ 73 RA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.3. Scenario 3: CE router updated to support opportunistic 75 encryption to its DNS forwarder . . . . . . . . . . . . . 6 76 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Questions for the WG . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 9.2. Informative References . . . . . . . . . . . . . . . . . 7 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 This draft analyzes the behaviors that residential end users and home 89 network owners (e.g., parents of young children) might experience 90 when operating systems and clients support [I-D.ietf-add-ddr] and/or 91 [I-D.ietf-add-dnr] for discovery of encrypted DNS services and the CE 92 router of the home network offers itself as the Do53 resolver. This 93 use case is explicitly mentioned in [I-D.ietf-add-requirements] 94 Section 3.2 and has several requirements related to it. 96 This draft has two goals: 98 * determine if the analysis it provides is accurate 100 * if it is accurate, determine if the behavior is acceptable to the 101 WG or if there should be changes to either of the discovery 102 mechanisms. 104 Becoming a WG draft is _not_ a goal of this draft. There is and will 105 be no request for adoption by any WG. 107 While DNS forwarders / proxies may exist in environments other than 108 home networks (e.g., hotspots, small businesses), this draft does not 109 attempt to examine those usages. This draft is focused on home 110 networks. 112 2. Conventions and Definitions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. Background 122 Having a DNS forwarder in the CE router that is advertised to the LAN 123 using DHCP and RDNSS options is a common deployment model for many 124 ISPs and is also the default in many retail consumer routers (e.g., 125 Netgear). 127 [I-D.ietf-add-requirements] contains the following text related to 128 this use case: 130 "Many networks offer a Do53 resolver on an address that is not 131 globally meaningful, e.g. [RFC1918], link-local or unique local 132 addresses. To support the discovery of encrypted DNS in these 133 environments, a means is needed for the discovery process to work 134 from a locally-addressed Do53 resolver to an encrypted DNS resolver 135 that is accessible either at the same (local) address, or at a 136 different global address. Both options need to be supported." 138 "R4.1 If the local network resolver is a forwarder that does not 139 offer encrypted DNS service, an upstream encrypted resolver SHOULD be 140 retrievable via queries sent to that forwarder." 142 "R4.2 Achieving requirement 4.1 SHOULD NOT require any changes to DNS 143 forwarders hosted on non-upgradable legacy network devices." 144 In the context of a home network, there are several reasons why this 145 deployment model is used. Some reasons are: 147 * Provide local name resolution 149 * Captive portal (Note that [RFC8952] defines an architecture that 150 does not rely on "breaking" DNS; however, there exist many legacy 151 devices with captive portals that do rely on "breaking" DNS.} 153 * Provide filtering (aka parental controls) and DNS-based 154 vulnerability assessment in the CE router. Note that 155 [I-D.ietf-add-requirements] describes this sort of filtering and 156 monitoring behavior as an attack; nonetheless, this functionality 157 is popular with many people -- especially parents. 159 * Caching responses to improve DNS performance 161 4. Scenario Analysis 163 The following sections will analyze what behavior a user is expected 164 to see when certain conditions exist. In all cases, it's assumed the 165 CE router is advertising itself as the Do53 server (using DHCP and/or 166 RA). The clients and OSs that are of interest in these scenarios are 167 using whatever Do53 server is advertised to them by DHCP/RA. There 168 may be clients and devices that use other Do53 servers; those are out 169 of scope of this analysis. Analyzing the behavior of clients that do 170 not support either DoH or DoT, or do not support any mechanism to 171 discover encrypted servers are also out of scope. 173 Assumptions common to all scenarios are: 175 * Common OSs support both DNR and DDR 177 * Some applications (e.g., browsers) support DDR 179 * No Certificate Authority will sign a certificate with a private IP 180 address in a SAN 182 4.1. Scenario 1: No changes to CE router 184 Assumptions: 186 * The CE router (including its DNS forwarder and DHCP/RA 187 capabilities) are not updated. 189 Expected behaviors: 191 * There will be no DHCP or RA advertisement of encrypted servers. 193 * The DNS forwarder will forward DDR queries (dns://resolver.arpa) 194 to the DNS recursive resolver the CE router is configured to use. 196 * If that recursive resolver has the appropriate SVCB record, it 197 will provide that in the response that is returned. 199 * The querying OS/app will determine that the IP address of its 200 Unencrypted Resolver (the CE router) and the IP address of the 201 Unencrypted Resolver in the supplied certificate do not match and 202 will not do "authenticated discovery". 204 * The querying OS/app will determine that the IP address of its 205 Unencrypted Resolver (the CE router) does not match the IP address 206 of the Encrypted Resolver and will not do "opportunistic 207 discovery". 209 * The OS/app will not discover a local Encrypted Resolver. 211 The end result is that no Encrypted Resolver will be used by an OS or 212 app that uses DDR or DNR to discover an Encrypted Resolver, unless 213 the OS or app subsequently uses some non-standard mechanism to select 214 an Encrypted Resolver. Note that this suggests that the DDR and DNR 215 proposals in their current form do not satisfy the requirement "R4.2 216 Achieving requirement 4.1 SHOULD NOT require any changes to DNS 217 forwarders hosted on non-upgradable legacy network devices." 219 Also note that non-upgraded legacy routers will not satisfy the 220 [I-D.ietf-add-ddr] requirement that a "DNS forwarder SHOULD NOT 221 forward queries for "resolver.arpa" upstream." If the CE router were 222 updated to not forward queries for "resolver.arpa" upstream, the end 223 result would not change. Since this scenario provides the same end 224 result, it isn't broken out separately. 226 4.2. Scenario 2: CE router updated to provide DNR in DHCP/RA 228 Assumptions: 230 * The CE router is updated to provide Encrypted Resolver info in 231 DHCP/RA 233 * The CE router gets its Encrypted Resolver info from DHCP; getting 234 that was part of the update 236 * The upstream ISP has updated its core network resolver to support 237 encryption, and announces this resolver in DHCP 239 Expected behaviors: 241 * OSs will use the Encrypted Resolver 243 * Applications that try "resolver.arpa" will not do their own 244 upgrade, because that will fail 246 Additional results: 248 * Local name resolution is broken? 250 * Legacy captive portal is now broken? 252 * Filtering in the CE router (parental controls and other security 253 mechanisms enabled by the home network owner) is now broken 255 * Any filtering deployed in the core network resolver continues to 256 operate 258 * No local caching 260 4.3. Scenario 3: CE router updated to support opportunistic encryption 261 to its DNS forwarder 263 Assumptions: 265 * The CE router supports encrypted connectivity to its DNS forwarder 267 * The CE router is updated to provide Encrypted Resolver info in 268 DHCP/RA 270 * The CE router is updated to reply to "dns://resolver.arpa"; SVCB 271 record points to the CE router with a self-signed certificate 273 Note that the effort do do these upgrades is considered to be rather 274 large. 276 Expected behaviors: 278 * Some OSs and applications accept DDR Opportunistic Discovery, 279 resulting in use of the CE router's Encrypted Resolver. 281 * Some OSs and applications do not. 283 * Across a range of households, and even within a single household, 284 there is inconsistent behavior. 286 5. Conclusions 288 Since Scenario 3 is considered a large effort and the resulting 289 behavior is unpredictable, it is unlikely to be pursued. 291 Since Scenario 2 will break some of the functionality that a 292 significant number of home network owners have purposefully enabled 293 (e.g., router-based DNS-based parental controls), will break existing 294 captive portal implementations used to simplify setup of broadband 295 connections, and may break local name resolution (?) it is unlikely 296 to be pursued. 298 This leaves Scenario 1 (do nothing in routers that provide DNS 299 forwarder). 301 6. Questions for the WG 303 Are these the results we want to achieve with Encrypted Resolver 304 discovery mechanisms? 306 7. Security Considerations 308 Breaking the security mechanisms that many users currently have 309 enabled in their home network routers (e.g., DNS filtering) will 310 worsen the security of those users. While these mehanisms are not 311 perfect, and can easily be bypassed by client applications that run 312 DoH, this does not make them completely useless. 314 8. IANA Considerations 316 This document has no IANA actions. 318 9. References 320 9.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 329 May 2017, . 331 9.2. Informative References 333 [I-D.ietf-add-ddr] 334 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 335 Jensen, "Discovery of Designated Resolvers", Work in 336 Progress, Internet-Draft, draft-ietf-add-ddr-01, 14 June 337 2021, . 339 [I-D.ietf-add-dnr] 340 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 341 Jensen, "DHCP and Router Advertisement Options for the 342 Discovery of Network-designated Resolvers (DNR)", Work in 343 Progress, Internet-Draft, draft-ietf-add-dnr-02, 17 May 344 2021, . 346 [I-D.ietf-add-requirements] 347 Box, C., Pauly, T., Wood, C. A., Reddy, T., and D. 348 Migault, "Requirements for Discovering Designated 349 Resolvers", Work in Progress, Internet-Draft, draft-ietf- 350 add-requirements-00, 8 March 2021, 351 . 354 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 355 J., and E. Lear, "Address Allocation for Private 356 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 357 February 1996, . 359 [RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal 360 Architecture", RFC 8952, DOI 10.17487/RFC8952, November 361 2020, . 363 Acknowledgments 365 Thanks to ... 367 Authors' Addresses 369 Barbara Stark 370 AT&T 371 Austin, TX, 372 United States of America 374 Email: barbara.stark@att.com 375 Chris Box 376 BT 377 Bristol 378 United Kingdom 380 Email: chris.box@bt.com