Signaling resolver's filtering policies
draft-mglt-add-signaling-filtering-policies-00

Versions: 00                                                            
add                                                           D. Migault
Internet-Draft                                                  Ericsson
Intended status: Standards Track                          March 09, 2020
Expires: September 10, 2020


                Signaling resolver's filtering policies
             draft-mglt-add-signaling-filtering-policies-00

Abstract

   This document defines one mechanism that enables a DNS resolver to
   inform a DNS client that filtering policies are in place and what
   their concern is.  The second mechanism describes how a DNS client
   can request a resolver whether filtering policies are in place and
   what their concern is.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 10, 2020.

Copyright Notice

   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Migault                Expires September 10, 2020               [Page 1]


Internet-Draft     filtering policies by the resolver         March 2020


Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Filtering semantics . . . . . . . . . . . . . . . . . . . . .   3
   4.  DNS resolver advertising filtering status . . . . . . . . . .   4
   5.  Requesting DNS resolver filtering status  . . . . . . . . . .   5
   6.  Blocking traffic under the policy . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   9.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described BCP 14
   [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
   as shown here.

2.  Introduction

   This document defines mechanisms that enable a DNSSEC resolver to
   signal that filtering policies are enabled by the DNSSEC resolver.
   There are two distinct mechanisms.  The first mechanism enables a
   resolver to advertise policies that are enabled/disabled without any
   explicit request from the DNS client.  The second mechanism enables a
   DNS client to request the status of the resolver.  Such consideration
   may be used, by a stub resolver for example to select an appropriated
   resolver.

   The ability for a resolver to provide such information to a DNS
   client will help a DNS client to appropriately chose its resolver.

   The ability to request or signal configuration information has
   already been done in the past for the TA.  [RFC8145] enables a
   resolver to advertise an authoritative server via an EDNS option in
   the OPT RR which TA is used for the DNSSEC validation.  The RR is
   inserted when DNSKEY RRsets are requested.  In addition, the resolver
   may also request the appropriated TA with a specific DNS query.  The
   RRsets are stored in the authoritative zone.





Migault                Expires September 10, 2020               [Page 2]


Internet-Draft     filtering policies by the resolver         March 2020


   [RFC8509] describes a sentinel mechanism where the resolver has a
   specific behavior based on the left side label.  This mechanism
   enable a user to evaluate which KSK the resolver provisioned with.

   [RFC6975] describes how resolvers can indicate the supported
   cryptographic primitives.  These are advertised though EDNS0 options
   in OPT RR.

3.  Filtering semantics

   Filtering can be enforced in various ways, and the resolver should be
   able to provide some insight of the filtering policies in place.
   This document considers various filtering policies that may be
   extended in the future.  The filtering policies are informative and
   are expected to provide a good understanding to the DNS client of the
   status of the filtering policies.  The filtering policy enforced by
   the resolver may result in a combination of various filtering
   policies.

   Values   | Name
   ------------------------
    0       | no_filetring
    1       | undefined
    2       | malware
    3       | illegal
    4       | child
    200-255 | unassigned

   no_filetring  indicates no filtering is performed by the resolver.
      This policy is incompatible with other policies.

   undefined  indicates a filtering policy but does not provide
      indications on the policies.  When used in combination of other
      filtering policies, it indicates additional filtering policies are
      considered.

   malware  sites that are security risks or sources of malware, or that
      allow users to circumvent policies.

   illegal  Users may be committing crimes or exposing the organization
      to legal liability with these sites.

   child  sites that can be seen by kids.

   source: https://campus.barracuda.com/product/campus/doc/5472264/web-
   use-categories
   https://campus.barracuda.com/product/ContentShield/doc/77401148/how-
   to-configure-dns-filtering-policies/



Migault                Expires September 10, 2020               [Page 3]


Internet-Draft     filtering policies by the resolver         March 2020


   Note that the client should consider information related to the
   filtering policies enforced by the resolver cautiously and
   interpretation of the policies will depend on the trust as well as
   additional knowledge of the resolver.  Typically, illegal categories
   result in the enforcement of the local jurisdiction which could
   results in site not being blocked within other jurisdictions.

4.  DNS resolver advertising filtering status

   The resolver MAY advertise its filtering policy to the DNS client
   using an OPT RR in an EDNS0 option [RFC6891].  The variable part of
   the RDATA to define filtering status is defined below:

   0                       8                      16
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                  OPTION-CODE                  |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                                               |
   /                   DATA                        /
   |                                               |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   and DATA defined as

   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    LENGTH                     |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |   filtering_policy    |           ...         |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                      ...                      /
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   OPTION-CODE  The EDNS0 option code assigned to filtering-policies
      (TBD1).

   LENGTH  The length in octets of the filtering policies, that is the
      number of filtering policies that apply.  When RDATA is used in
      conjunction of EDNS0, LENGTH corresponds to teh OPTION-LENGTH
      field as defined in [RFC6891].

   filtering policies  the list of filtering policies coded over one
      octet that apply.  When RDATA is used in conjunction of EDNS0, the
      filtering_policies corresponds to OPTION-DATA.

   The filtering status may be placed by the DNS resolver as an
   indication to the DNS client.  It is recommended the DNS resolve



Migault                Expires September 10, 2020               [Page 4]


Internet-Draft     filtering policies by the resolver         March 2020


   place the indication in the first response it provides to the DNS
   client.  When the DNS exchanges are protected by TLS or DTLS, the OPT
   RR SHOULD be provided in the first DNS response provided after the
   (D)TLS session establishment.  When exchanges are not protected over
   (D)TLS the resolver MAY insert it at regular time interval.  The
   resolver could also maintain a list of seen IP addresses, and provide
   the OPT RR anytime a new IP address is noticed.

   As EDNS0 is not protected by DNSSEC, it is RECOMMENDED to consider
   such signaling when the exchanges are protected by (D)TLS.

5.  Requesting DNS resolver filtering status

   This section describes a mechanism that enables the DNS client to
   request the resolver policies.  Policies will be retrieve via a DNS
   exchange.

   The DNS resolver is usually designated by an IP address rather than a
   name as to get the IP address from a name would involve a DNS
   resolution.  As a result, the DNS client may not necessarily be
   configured with the associated name of the resolver and a reverse
   resolution may be required to receive to get this name.  In the
   remaining of the section, the resolver is designated by example.com

   The policies are indicated by the RRset with QTYPE=NULL, QCLASS=IN,
   QNAME=_filtering_policies.example.com.  The associated RDATA as
   defined in Section 4.

   The resolver supporting this mechanisms is provisioned with the this
   record and responds to the query.  By this way, the DNS client is
   aware of the filtering policies implemented.  A resolver not
   supporting this mechanism will return an error (NXDOMAIN) thus
   informing the DNS client that filtering policies are not provided.
   The RRsets SHOULD be signed by DNSSEC.

   The resolution service is often seen by the end user as a service
   that may involve multiple parties.  How the different parties
   collaborate is usually out of the DNS client perspective.  Typically
   the downstream point must ensure the provided filtering policies
   reflects the filtering policies of the upstream parties.  In some
   cases discovery policies of the upstream resolvers might be performed
   and the response may result in the aggregation of multiple RRSets.
   At least any party MUST ensure the filtering policies responded
   reflects the actual the enforced filtering policies.  The entry point
   of a resolving service SHOULD provide its corresponding
   _filtering_policies RRsets as well as RRsets associated to upstream
   resolvers.  These RRSets MAY be added in the additional section or
   the resolver MAY built its filtering policies according to the



Migault                Expires September 10, 2020               [Page 5]


Internet-Draft     filtering policies by the resolver         March 2020


   upstream filtering policies.  If an upstream resolver does not
   provide filtering policies, the resolver SHOULD include an undefined
   filtering p policies.

6.  Blocking traffic under the policy

   When a resolution fails because of the filtering policy, the error
   code returned can be Blocked, Censored or Filtered
   [I-D.ietf-dnsop-extended-error].  When filtering policies are
   requested by the DNS client - such a parental control for example -
   Filtered SHOULD be returned.  When blocking results from a legal
   enforcement Censored SHOULD be returned.  When bocking is performed
   by the operator's intelligence - such as malware related traffic for
   example - Blocked SHOULD be returned.

7.  Security Considerations

   Informative only! the DNS client can hardly check. sensitive to chain
   of resolvers.

8.  Privacy Considerations

9.  IANA considerations

   IANA has assigned an EDNS0 option code for the filtering option in
   the "DNS EDNS0 Option Codes (OPT)" registry as follows:

   +-------+--------------------+----------+-----------+
   | Value | Name               | Status   | Reference |
   +-------+--------------------+----------+-----------+
   | TBD1  | filtering-policies | Optional | RFC-TBD   |
   +-------+--------------------+----------+-----------+

   https://www.iana.org/assignments/dns-parameters/dns-
   parameters.xhtml#dns-parameters-14

   DNS Filtering Policies

   Values   | Name         | Description             |  Reference
   --------------------------------------------------+-----------
    0       | no_filetring | no filtering performed  | RFC-TBD
    1       | undefined    | undefined filtering     | RFC-TBD
    2       | malware      | malware related traffic | RFC-TBD
    3       | illegal      | legal enforcement       | RFC-TBD
    4       | child        | unappropritaed for kids | RFC-TBD
    200-255 | unassigned   |                         | RFC-TBD

   Underscored and Globally Scoped DNS Node Names



Migault                Expires September 10, 2020               [Page 6]


Internet-Draft     filtering policies by the resolver         March 2020


   RR Type | _NODE NAME         | Reference
   --------+--------------------+----------
   NULL    |_filetring_policies | RFC-TBD

10.  Acknowledgment

11.  References

11.1.  Normative References

   [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>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

   [RFC6975]  Crocker, S. and S. Rose, "Signaling Cryptographic
              Algorithm Understanding in DNS Security Extensions
              (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
              <https://www.rfc-editor.org/info/rfc6975>.

   [RFC8145]  Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
              Anchor Knowledge in DNS Security Extensions (DNSSEC)",
              RFC 8145, DOI 10.17487/RFC8145, April 2017,
              <https://www.rfc-editor.org/info/rfc8145>.

   [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>.

   [RFC8509]  Huston, G., Damas, J., and W. Kumari, "A Root Key Trust
              Anchor Sentinel for DNSSEC", RFC 8509,
              DOI 10.17487/RFC8509, December 2018,
              <https://www.rfc-editor.org/info/rfc8509>.

11.2.  Informative References

   [I-D.ietf-dnsop-extended-error]
              Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
              Lawrence, "Extended DNS Errors", draft-ietf-dnsop-
              extended-error-14 (work in progress), January 2020.






Migault                Expires September 10, 2020               [Page 7]


Internet-Draft     filtering policies by the resolver         March 2020


Author's Address

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com










































Migault                Expires September 10, 2020               [Page 8]