idnits 2.17.1 draft-mglt-add-rdp-isp-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC3646], [RFC3315]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 17 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the CPE can be upgraded, it is expected that it implements a DoH resolver as well as a DNS client that implement this document. Since the DNS client of the CPE supports this specification, it is expected that the CPE will send its traffic only to doh.isp.net. Since the CPE is also being upgraded to provide a DoH resolving service, OS and application are expected to be connected to the CPE using the DoH resolving service using the mechanism described in this document or other appropriated mechanism. Note that such communication while encrypted MAY NOT be authenticated. Authentication MAY be provided is the homenetwork enables DNSSEC ( and the distribution of the Trust Anchor) or the certificate. -- The document date (July 28, 2020) is 1368 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-03) exists of draft-mglt-add-rdp-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 add D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational July 28, 2020 5 Expires: January 29, 2021 7 DNS Resolver Discovery Protocol (DRDP) 8 draft-mglt-add-rdp-isp-00 10 Abstract 12 The DNS Resolving service Discovery Protocol (DRDP) enables to 13 discover resolving services available and eventually upgrade to an 14 encrypted resolving service. 16 DRDP requires a resolving domain or a pointer to a list of resolving 17 domains. Currently ISP or CPEs do not advertise resolving domain or 18 pointers to resolving domains which does not make possible for a DNS 19 client to discover potential resolving services - such as encrypted 20 DNS for example - made available by the ISP. 22 Instead, ISPs or CPE advertise via DHCP the IP address of the host 23 with a IA Address Option [RFC3315] and the IP addresses of the 24 resolver provided by the ISP with Recursive Name Server option 25 [RFC3646]. 27 This document describes a procedure for a DNS client to derive 28 resolving domains from the legacy configuration of the host. 30 This is expected to ease the deployment of encrypted DNS from ISP as 31 it will enable OS, applications to discover resolving service put in 32 place by the ISP even though the CPE has not been upgraded. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 29, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 3. IP to Pointers . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. RD Pointer from Interface Address (IA) . . . . . . . . . 5 71 3.2. RD Pointer from Resolver IP address . . . . . . . . . . . 5 72 3.3. Cross Verification . . . . . . . . . . . . . . . . . . . 6 73 3.4. Configuration expected by the network operator . . . . . 6 74 4. Security Consideration . . . . . . . . . . . . . . . . . . . 6 75 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 5.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 2. Introduction 90 This document describes how a DNS client can discover resolving 91 services made available by a network operator. The procedure 92 requires minimal changes from the network operator and results in the 93 encryption of a significant portion of the DNS traffic. The 94 limitation relies on the CPE being upgraded to support encrypted DNS 95 to resolve local scope names. 97 The considered architecture that is currently deployed is represented 98 below. 100 In most architecture, the CPE co-hosts an authoritative server for 101 the local zones (such as .home.arpa or .local) that are not 102 represented in the global DNS architecture. The CPE in most common 103 deployment works as a forwarder, that is, it responds to a query when 104 it is either authoritative for the answer or the answer is in its 105 cache. In any other case, the CPE resolves the query to the resolver 106 of the ISP represented as (do53.isp.net). 108 In most architecture, OS and CPE are provisioned IP addresses via 109 DHCP IA Address Option [RFC3315]. This IP address is used for the 110 connectivity purpose. Similarly, OS and CPE are provisioned IP 111 addresses that are used to reach the resolving service provided by 112 the network operator via the DHCP Recursive Name Server option 113 [RFC3646]. These IP addresses may be local scope or global. 115 The application - such as a web browser - does not get provisioned 116 via DHCP but is supposed to be able to access the IP addresses 117 provisioned on the OS. 119 (proxied) 120 +------------------+ +-----+ +------------------+ 121 | OS / application +-------+ CPE +------+ ISP do53.isp.net | 122 | | +-----+ | | 123 | +--------------------+ | 124 +------------------+ (direct) +------------------+ 126 When the network operator introduces a new resolving service such as 127 providing a DoH resolving service for example, the network operator 128 would like to make that server available to the OS, application and 129 the CPE. In the figure below, the new introduced service is 130 designated as doh.isp.net and is expected to implement DoH. 132 (proxied) 133 +------------------+ +-----+ +------------------+ 134 | OS / application +-------+ CPE +------+ ISP do53.isp.net | 135 | | +-----+ | | 136 | +--------------------+ | 137 +------------------+ (direct) +------------------+ 139 +------------------+ 140 | ISP doh.isp.net | 141 +------------------+ 143 Because not all DNS clients will be upgraded at the same time and 144 that DNS client, the network operator will need to support both 145 do53.isp.net and doh.isp.net. 146 One possibility would be to co-host do53.isp.net and doh.isp.net with 147 the same IP address. Such alternative is not considered in this 148 document as in the long term it would require the network operator to 149 co-host under the same IP address all different variant of the 150 resolving services. This provides a to high contrail on the 151 infrastructure. 153 Having the DNS client try and test what is actually supported is also 154 not considered in this document either. 156 When the CPE cannot be upgraded, only the OS or application can 157 discover and upgrade to the doh.isp.net. Only application/OS that 158 support the DRDP and this document will benefit from such upgrade. 159 Maximization of encrypted DNS traffic is performed if the OS/ 160 application 1) sends the DNS queries that are resolved globally to 161 doh.isp.net 2) limiting the DNS traffic to the CPE to the one 162 associated to the local network. 164 (proxied) 165 +------------------+ +-----+ +------------------+ 166 | OS / application +-------+ CPE + (----+ ISP do53.isp.net | ) 167 | | +-----+ +------------------+ 168 | +====================+ ISP doh.isp.net | 169 +------------------+ (direct) +------------------+ 171 When the CPE can be upgraded, it is expected that it implements a DoH 172 resolver as well as a DNS client that implement this document. Since 173 the DNS client of the CPE supports this specification, it is expected 174 that the CPE will send its traffic only to doh.isp.net. Since the 175 CPE is also being upgraded to provide a DoH resolving service, OS and 176 application are expected to be connected to the CPE using the DoH 177 resolving service using the mechanism described in this document or 178 other appropriated mechanism. Note that such communication while 179 encrypted MAY NOT be authenticated. 180 Authentication MAY be provided is the homenetwork enables DNSSEC ( 181 and the distribution of the Trust Anchor) or the certificate. 183 (proxied) 184 +------------------+ +-----+ +------------------+ 185 | OS / application +=======+ CPE +==+ (-+ ISP do53.isp.net | ) 186 | | +-----+ || +------------------+ 187 | +====================+ ISP doh.isp.net | 188 +------------------+ (direct) +------------------+ 190 3. IP to Pointers 192 This document describe how to generate a pointer to resolving domains 193 (Pointer) from the Interface address (IA) (Section 3.1 ) as well as 194 from the IP address of the resolvers Section 3.2 when these IP 195 addresses are global. 197 3.1. RD Pointer from Interface Address (IA) 199 This section describes the procedure to derive resolving domains (RD) 200 or RD Pointers from an Interface Address (IA), that is the IP or 201 network assigned by the network operator to provide connectivity to 202 the host. 204 1. Get a global IA: If the IA IP address is an IPv4 address of local 205 scope, the DNS client establish the public IP address used by the 206 network operator using appropriated mechanisms such as STUN 207 [RFC3489] for example. The exchange SHOULD be protected by 208 (D)TLS and the DNS client considers the mapped IP address as it 209 global IA IP address. In any other case, the IA IP address is 210 global. 212 2. Proceed to a reverse resolution and consider the resulting domain 213 (IA Pointer) as a Pointer 215 3. DRDP [I-D.mglt-add-rdp] MAY be started from the resulting 216 pointer. Optionally the DNS client MAY retrieve the RD to 217 proceed to additional verifications - see Section 3.3. Note that 218 such conversion places a lot of trust into the STUN resolution 219 when such resolution is required. 221 3.2. RD Pointer from Resolver IP address 223 This section describes the procedure to derive RD from the IP address 224 of the resolving service. The procedure only works when the resolver 225 is provisioned with a global IP address and MAY not be applicable for 226 some DNS client. 228 1. Proceed to a reverse resolution and consider the resulting domain 229 (Resolver Pointer) as a Pointer. 231 2. DRDP [I-D.mglt-add-rdp] MAY be started from the resulting 232 pointer, however, it is recommended to retrieve the RD and 233 proceed to additional steps described in Section 3.3. Note that 234 such conversion places a lot of trust into the DHCP provisioning. 236 3.3. Cross Verification 238 When the discovery of the public IA involves a third party (or is not 239 sufficiently protected), it is RECOMMENDED to derive the Pointer from 240 Resolvers IP as described in Section 3.2 - when that is possible. 242 In that case, the following steps SHOULD be performed: 244 1. Retrieve RD (RD_IA) from the IA Pointer. 246 2. Retrieve RD (RD_Resolver) from the Resolver Pointer. 248 3. Consider the resolving domains shared by the two Pointers as 249 provided by your network operator and other as independent 250 resolving domains. 252 3.4. Configuration expected by the network operator 254 The network operator is expected to update the forward zone of the 255 CPE as follows: 257 b._dns.cpe_isp_fqdn.isp.net PTR resolver.isp.net 258 b._dns.cpe_isp_fqdn.isp.net PTR third_party_delegated_resolver.isp.net 260 The network operator is expected to update the zone that corresponds 261 to the resolving domains as follws: 263 b._dns.resolver.isp.net PTR resolver.isp.net 264 b._dns.resolver.isp.net PTR third_party_delegated_resolver.isp.net 266 4. Security Consideration 268 Rough STUN server 270 Rough DHCP 272 5. References 274 5.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 282 C., and M. Carney, "Dynamic Host Configuration Protocol 283 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 284 2003, . 286 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 287 "STUN - Simple Traversal of User Datagram Protocol (UDP) 288 Through Network Address Translators (NATs)", RFC 3489, 289 DOI 10.17487/RFC3489, March 2003, 290 . 292 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 293 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 294 DOI 10.17487/RFC3646, December 2003, 295 . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 5.2. Informative References 303 [I-D.mglt-add-rdp] 304 Migault, D., "DNS Resolver Discovery Protocol (DRDP)", 305 draft-mglt-add-rdp-02 (work in progress), May 2020. 307 Author's Address 309 Daniel Migault 310 Ericsson 311 8275 Trans Canada Route 312 Saint Laurent, QC 4S 0B6 313 Canada 315 EMail: daniel.migault@ericsson.com