idnits 2.17.1 draft-mglt-add-signaling-filtering-policies-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 125 has weird spacing: '...letring indic...' == Line 128 has weird spacing: '...defined indic...' == Line 133 has weird spacing: '...malware sites...' == Line 139 has weird spacing: '... child sites...' == Line 187 has weird spacing: '...olicies the l...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 09, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-extended-error-14 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: Standards Track March 09, 2020 5 Expires: September 10, 2020 7 Signaling resolver's filtering policies 8 draft-mglt-add-signaling-filtering-policies-00 10 Abstract 12 This document defines one mechanism that enables a DNS resolver to 13 inform a DNS client that filtering policies are in place and what 14 their concern is. The second mechanism describes how a DNS client 15 can request a resolver whether filtering policies are in place and 16 what their concern is. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Filtering semantics . . . . . . . . . . . . . . . . . . . . . 3 55 4. DNS resolver advertising filtering status . . . . . . . . . . 4 56 5. Requesting DNS resolver filtering status . . . . . . . . . . 5 57 6. Blocking traffic under the policy . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 61 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 11.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Requirements Notation 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 71 "OPTIONAL" in this document are to be interpreted as described BCP 14 72 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 73 as shown here. 75 2. Introduction 77 This document defines mechanisms that enable a DNSSEC resolver to 78 signal that filtering policies are enabled by the DNSSEC resolver. 79 There are two distinct mechanisms. The first mechanism enables a 80 resolver to advertise policies that are enabled/disabled without any 81 explicit request from the DNS client. The second mechanism enables a 82 DNS client to request the status of the resolver. Such consideration 83 may be used, by a stub resolver for example to select an appropriated 84 resolver. 86 The ability for a resolver to provide such information to a DNS 87 client will help a DNS client to appropriately chose its resolver. 89 The ability to request or signal configuration information has 90 already been done in the past for the TA. [RFC8145] enables a 91 resolver to advertise an authoritative server via an EDNS option in 92 the OPT RR which TA is used for the DNSSEC validation. The RR is 93 inserted when DNSKEY RRsets are requested. In addition, the resolver 94 may also request the appropriated TA with a specific DNS query. The 95 RRsets are stored in the authoritative zone. 97 [RFC8509] describes a sentinel mechanism where the resolver has a 98 specific behavior based on the left side label. This mechanism 99 enable a user to evaluate which KSK the resolver provisioned with. 101 [RFC6975] describes how resolvers can indicate the supported 102 cryptographic primitives. These are advertised though EDNS0 options 103 in OPT RR. 105 3. Filtering semantics 107 Filtering can be enforced in various ways, and the resolver should be 108 able to provide some insight of the filtering policies in place. 109 This document considers various filtering policies that may be 110 extended in the future. The filtering policies are informative and 111 are expected to provide a good understanding to the DNS client of the 112 status of the filtering policies. The filtering policy enforced by 113 the resolver may result in a combination of various filtering 114 policies. 116 Values | Name 117 ------------------------ 118 0 | no_filetring 119 1 | undefined 120 2 | malware 121 3 | illegal 122 4 | child 123 200-255 | unassigned 125 no_filetring indicates no filtering is performed by the resolver. 126 This policy is incompatible with other policies. 128 undefined indicates a filtering policy but does not provide 129 indications on the policies. When used in combination of other 130 filtering policies, it indicates additional filtering policies are 131 considered. 133 malware sites that are security risks or sources of malware, or that 134 allow users to circumvent policies. 136 illegal Users may be committing crimes or exposing the organization 137 to legal liability with these sites. 139 child sites that can be seen by kids. 141 source: https://campus.barracuda.com/product/campus/doc/5472264/web- 142 use-categories 143 https://campus.barracuda.com/product/ContentShield/doc/77401148/how- 144 to-configure-dns-filtering-policies/ 145 Note that the client should consider information related to the 146 filtering policies enforced by the resolver cautiously and 147 interpretation of the policies will depend on the trust as well as 148 additional knowledge of the resolver. Typically, illegal categories 149 result in the enforcement of the local jurisdiction which could 150 results in site not being blocked within other jurisdictions. 152 4. DNS resolver advertising filtering status 154 The resolver MAY advertise its filtering policy to the DNS client 155 using an OPT RR in an EDNS0 option [RFC6891]. The variable part of 156 the RDATA to define filtering status is defined below: 158 0 8 16 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 | OPTION-CODE | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | | 163 / DATA / 164 | | 165 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 and DATA defined as 169 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 170 | LENGTH | 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 172 | filtering_policy | ... | 173 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 174 | ... / 175 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 177 where: 179 OPTION-CODE The EDNS0 option code assigned to filtering-policies 180 (TBD1). 182 LENGTH The length in octets of the filtering policies, that is the 183 number of filtering policies that apply. When RDATA is used in 184 conjunction of EDNS0, LENGTH corresponds to teh OPTION-LENGTH 185 field as defined in [RFC6891]. 187 filtering policies the list of filtering policies coded over one 188 octet that apply. When RDATA is used in conjunction of EDNS0, the 189 filtering_policies corresponds to OPTION-DATA. 191 The filtering status may be placed by the DNS resolver as an 192 indication to the DNS client. It is recommended the DNS resolve 193 place the indication in the first response it provides to the DNS 194 client. When the DNS exchanges are protected by TLS or DTLS, the OPT 195 RR SHOULD be provided in the first DNS response provided after the 196 (D)TLS session establishment. When exchanges are not protected over 197 (D)TLS the resolver MAY insert it at regular time interval. The 198 resolver could also maintain a list of seen IP addresses, and provide 199 the OPT RR anytime a new IP address is noticed. 201 As EDNS0 is not protected by DNSSEC, it is RECOMMENDED to consider 202 such signaling when the exchanges are protected by (D)TLS. 204 5. Requesting DNS resolver filtering status 206 This section describes a mechanism that enables the DNS client to 207 request the resolver policies. Policies will be retrieve via a DNS 208 exchange. 210 The DNS resolver is usually designated by an IP address rather than a 211 name as to get the IP address from a name would involve a DNS 212 resolution. As a result, the DNS client may not necessarily be 213 configured with the associated name of the resolver and a reverse 214 resolution may be required to receive to get this name. In the 215 remaining of the section, the resolver is designated by example.com 217 The policies are indicated by the RRset with QTYPE=NULL, QCLASS=IN, 218 QNAME=_filtering_policies.example.com. The associated RDATA as 219 defined in Section 4. 221 The resolver supporting this mechanisms is provisioned with the this 222 record and responds to the query. By this way, the DNS client is 223 aware of the filtering policies implemented. A resolver not 224 supporting this mechanism will return an error (NXDOMAIN) thus 225 informing the DNS client that filtering policies are not provided. 226 The RRsets SHOULD be signed by DNSSEC. 228 The resolution service is often seen by the end user as a service 229 that may involve multiple parties. How the different parties 230 collaborate is usually out of the DNS client perspective. Typically 231 the downstream point must ensure the provided filtering policies 232 reflects the filtering policies of the upstream parties. In some 233 cases discovery policies of the upstream resolvers might be performed 234 and the response may result in the aggregation of multiple RRSets. 235 At least any party MUST ensure the filtering policies responded 236 reflects the actual the enforced filtering policies. The entry point 237 of a resolving service SHOULD provide its corresponding 238 _filtering_policies RRsets as well as RRsets associated to upstream 239 resolvers. These RRSets MAY be added in the additional section or 240 the resolver MAY built its filtering policies according to the 241 upstream filtering policies. If an upstream resolver does not 242 provide filtering policies, the resolver SHOULD include an undefined 243 filtering p policies. 245 6. Blocking traffic under the policy 247 When a resolution fails because of the filtering policy, the error 248 code returned can be Blocked, Censored or Filtered 249 [I-D.ietf-dnsop-extended-error]. When filtering policies are 250 requested by the DNS client - such a parental control for example - 251 Filtered SHOULD be returned. When blocking results from a legal 252 enforcement Censored SHOULD be returned. When bocking is performed 253 by the operator's intelligence - such as malware related traffic for 254 example - Blocked SHOULD be returned. 256 7. Security Considerations 258 Informative only! the DNS client can hardly check. sensitive to chain 259 of resolvers. 261 8. Privacy Considerations 263 9. IANA considerations 265 IANA has assigned an EDNS0 option code for the filtering option in 266 the "DNS EDNS0 Option Codes (OPT)" registry as follows: 268 +-------+--------------------+----------+-----------+ 269 | Value | Name | Status | Reference | 270 +-------+--------------------+----------+-----------+ 271 | TBD1 | filtering-policies | Optional | RFC-TBD | 272 +-------+--------------------+----------+-----------+ 274 https://www.iana.org/assignments/dns-parameters/dns- 275 parameters.xhtml#dns-parameters-14 277 DNS Filtering Policies 279 Values | Name | Description | Reference 280 --------------------------------------------------+----------- 281 0 | no_filetring | no filtering performed | RFC-TBD 282 1 | undefined | undefined filtering | RFC-TBD 283 2 | malware | malware related traffic | RFC-TBD 284 3 | illegal | legal enforcement | RFC-TBD 285 4 | child | unappropritaed for kids | RFC-TBD 286 200-255 | unassigned | | RFC-TBD 288 Underscored and Globally Scoped DNS Node Names 289 RR Type | _NODE NAME | Reference 290 --------+--------------------+---------- 291 NULL |_filetring_policies | RFC-TBD 293 10. Acknowledgment 295 11. References 297 11.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 305 for DNS (EDNS(0))", STD 75, RFC 6891, 306 DOI 10.17487/RFC6891, April 2013, 307 . 309 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 310 Algorithm Understanding in DNS Security Extensions 311 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 312 . 314 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 315 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 316 RFC 8145, DOI 10.17487/RFC8145, April 2017, 317 . 319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 321 May 2017, . 323 [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust 324 Anchor Sentinel for DNSSEC", RFC 8509, 325 DOI 10.17487/RFC8509, December 2018, 326 . 328 11.2. Informative References 330 [I-D.ietf-dnsop-extended-error] 331 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 332 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 333 extended-error-14 (work in progress), January 2020. 335 Author's Address 337 Daniel Migault 338 Ericsson 339 8275 Trans Canada Route 340 Saint Laurent, QC 4S 0B6 341 Canada 343 EMail: daniel.migault@ericsson.com