Diameter Maintenance and Extensions                             L. Bertz
Internet-Draft                                                    Sprint
Intended status: Standards Track                            July 6, 2016
Expires: January 7, 2017


               Diameter Domain and Arbitrary Mask Filters
                    draft-bertz-dime-domainmasks-00

Abstract

   This document defines optional Diameter attributes to specify filters
   by hosts/domains and attributes required by Software Defined
   Networking (SDN) enabled enforcement points.

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 http://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 January 7, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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.





Bertz                    Expires January 7, 2017                [Page 1]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  DNS-Filters and ArbitraryMasks Attributes . . . . . . . . . .   3
     3.1.  DNS-Filters AVP . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Software Defined Network (SDN) Attributes . . . . . . . .   3
       3.2.1.  IP-Address-Mask-Pattern AVP . . . . . . . . . . . . .   3
       3.2.2.  Flow-Label AVP  . . . . . . . . . . . . . . . . . . .   4
       3.2.3.  Flow-Label-Mask-Pattern AVP . . . . . . . . . . . . .   4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  DNS Filter  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  SDN Related AVP application . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  DNS-Filters Usage . . . . . . . . . . . . . . . . . . . .   7
     6.2.  SDN AVP Usage . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   An optional Diameter Attribute Value Pair (AVP) is defined in this
   document for DNS support.  It is the DNS-Filters AVP which contains a
   list of DNS query names that follow the registered name QNAME format
   defined in [RFC1034], Section 3.7.1 and subsequent updates, notably
   [RFC4592].

   DNS Filter AVPs are used in various operator policy enforcement
   applications such as child protections, parental controls and flow
   based rating.

   Current practices require any updates to these applications to be
   sideloaded, i.e. updated via a file, on the enforcement points or



Bertz                    Expires January 7, 2017                [Page 2]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


   proprietary mechanism.  As an AVP, the list of entries in the AVP may
   be dynamically updated per current Diameter application
   specifications, e.g.  [RFC7155].

   The second AVP, ArbitraryMask-AVP, defines an arbitrary bitmask for
   various maskable AVPs used in Classifiers [RFC5777].

   Prefix based masks are present in [RFC5777] but the technologies such
   as Software Defined Networking (SDN) introduce new arbitrary bitmasks
   on multiple data types in the various protocol headers.

2.  Terminology

   In this document, the key words "MAY", "MUST", "MUST NOT",
   "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [RFC2119].

3.  DNS-Filters and ArbitraryMasks Attributes

3.1.  DNS-Filters AVP

   The DNS-Filters AVP (AVP Code TBD1) is of type Grouped and specifies
   the list of QNAMES [RFC1034] that restrict ip flows (5-tuples) that
   match the Classifier.

    DNS-Filters ::= < AVP Header: TBD1 >
                            1*{ <QNAMES> }
                            * [ AVP ]


   QNAMES are defined in [RFC1034], Section 3.7.1.

   When this AVP is used for classification in the Filter-Rule, it MUST
   be part of the Classifier Grouped AVP as defined in [RFC5777].

3.2.  Software Defined Network (SDN) Attributes

3.2.1.  IP-Address-Mask-Pattern AVP

   The IP-Address-Mask-Pattern AVP (AVP Code TBD2) is of type
   OctetString.  The value is 4 octets specifying the bit positions of a
   IP address that are taken for matching.

   When this AVP is used for classification in the Filter-Rule, it MUST
   be part of the Classifier Grouped AVP as defined in [RFC5777].






Bertz                    Expires January 7, 2017                [Page 3]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


3.2.2.  Flow-Label AVP

   The Flow-Label AVP (AVP Code TBD3) is of type Unsigned32.  This field
   identifies the Flow Label value to be matched.

   According to [RFC2460], the flow label is 20 bits long.  For the
   purpose of this specification, the sender of this option MUST prefix
   the flow label value with 12 bits of "0" before inserting it in the
   Flow-Label AVP.  The receiver SHOULD ignore the first 12 bits of this
   field before using it in comparisons with flow labels in packets.

   When this AVP is used for classification in the Filter-Rule, it MUST
   be part of the Classifier Grouped AVP as defined in [RFC5777].

3.2.3.  Flow-Label-Mask-Pattern AVP

   The Flow-Label-Mask-Pattern AVP (AVP Code TBD3) is of type
   OctetString.  The value is 4 octets specifying the bit positions of a
   Flow Label that are taken for matching.

   According to [RFC2460], the flow label is 20 bits long.  For the
   purpose of this specification, the sender of this option MUST prefix
   the flow label value with 12 bits of "0" before inserting it in the
   Flow Label Mask Pattern AVP.  The receiver SHOULD ignore the first 12
   bits of this field before using it as a mask.

   When this AVP is used for classification in the Filter-Rule, it MUST
   be part of the Classifier Grouped AVP as defined in [RFC5777].

4.  Examples

4.1.  DNS Filter

   The Classifier AVP (AVP Code 511) specified in [RFC5777] is a grouped
   AVP that consists of a set of attributes that specify how to match a
   packet.  The addition of the DNS-Filter AVP is shown here.















Bertz                    Expires January 7, 2017                [Page 4]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


         Classifier ::= < AVP Header: 511 >
                        { Classifier-ID }
                        [ Protocol ]
                        [ Direction ]
                        [ DNS-Filters ]
                      * [ From-Spec ]
                      * [ To-Spec ]
                      * [ Diffserv-Code-Point ]
                        [ Fragmentation-Flag ]
                      * [ IP-Option ]
                      * [ TCP-Option ]
                        [ TCP-Flags ]
                      * [ ICMP-Type ]
                      * [ ETH-Option ]
                      * [ AVP ]

   Setting the DNS-Filter value would specify the capture flows whose
   DNS related communications match the QUERY values specified in the
   Classifier.

   DNS related communications are those DNS queries which have valid DNS
   responses for scope implied by the container of the Classifier, i.e.
   if the Classifer is contained by a Filter-Rule installed during a
   mobility session then only resulting IP addresses conatined in DNS
   traffic for the mobility session is used in the selection of flows.

   The use of the DNS-Filters AVP implies that the following conditions
   exist:

   o  The related DNS traffic is known by the enforcement point

   o  The related DNS traffic is viewable by the enforcement point

   Such conditions are met in network services related to child
   protections and parental controls.

   Use of secured DNS communications [RFC4033] is recommended.  In such
   a case the enforemcent point may be a DNS relay used, as part of the
   network access service, to enforce or report generate Diameter events
   in applications such as Application Detection and Charging [TGPPCC]
   using DNS-Filters.

4.2.  SDN Related AVP application

   The From-Spec AVP (AVP Code 515) and To-Spec AVP (AVP Code 516)
   specified in [RFC5777] are grouped AVPs that consist of a set of
   attributes that specify how to match a packet in the From/To




Bertz                    Expires January 7, 2017                [Page 5]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


   direction (respectively).  The addition of the SDN related AVPs are
   shown here.

      From-Spec ::= < AVP Header: 515 >
                  * [ IP-Address ]
                  * [ IP-Address-Range ]
                  * [ IP-Address-Mask ]
                  * [ MAC-Address ]
                  * [ MAC-Address-Mask]
                  * [ EUI64-Address ]
                  * [ EUI64-Address-Mask]
                  * [ Port ]
                  * [ Port-Range ]
                    [ Negated ]
                    [ Use-Assigned-Address ]
                  * [ IP-Address-Mask-Pattern ]
                  * [ Flow-Label ]
                  * [ Flow-Label-Mask-Pattern ]
                  * [ AVP ]

      To-Spec ::= < AVP Header: 516 >
                * [ IP-Address ]
                * [ IP-Address-Range ]
                * [ IP-Address-Mask ]
                * [ MAC-Address ]
                * [ MAC-Address-Mask]
                * [ EUI64-Address ]
                * [ EUI64-Address-Mask]
                * [ Port ]
                * [ Port-Range ]
                  [ Negated ]
                  [ Use-Assigned-Address ]
                * [ IP-Address-Mask-Pattern ]
                * [ Flow-Label ]
                * [ Flow-Label-Mask-Pattern ]
                * [ AVP ]

   Setting the IP-Address-Mask-Pattern value would permit the capture of
   an arbitrarily masked IP pattern the flow, e.g.  192.0.22.0 with an
   arbitraty mask of 255.0.255.0.  NOTE that if the value of this AVP is
   only '1' starting from the least significant bit it is no different
   than the IP-Address-Mask which could be used instead.  For example,
   an arbitrary mask of 255.255.255.0 applied to 192.168.5.0 is no
   different than the prefix notation 192.168.5.0/24.

   Setting the Flow-Label value would permit capture of IPv6 packets
   with a specific Flow Label.  Setting the Flow-Label-Mask-Pattern




Bertz                    Expires January 7, 2017                [Page 6]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


   permits the capture of flows that match the appropriate mask pattern
   applied to the Flow Label.

5.  IANA Considerations

   IANA allocated AVP codes in the IANA-controlled namespace registry
   specified in Section 11.1.1 of [RFC6733] for the following AVPs that
   are defined in this document.

   +-------------------------+---------+-----------------+-------------+
   | AVP                     | AVP     | Section Defined | Data Type   |
   |                         | Code    |                 |             |
   +-------------------------+---------+-----------------+-------------+
   | DNS-Filters             | TBD1    | Section 3.1     | GROUPED     |
   | IP-Address-Mask-Pattern | TBD2    | Section 3.2.1   | OctetString |
   | Flow-Label              | TBD3    | Section 3.2.2   | Unsigned32  |
   | Flow-Label-Mask-Pattern | TBD4    | Section 3.2.3   | OctetString |
   +-------------------------+---------+-----------------+-------------+

6.  Security Considerations

6.1.  DNS-Filters Usage

   The use of DNS-Filters AVP implies visible access to DNS traffic
   associated with the containing rule's, e.g.  Filter-Rule [RFC5777].
   It does not imply a specific design for DNS communications but it is
   strongly recommended that secured DNS communciations [RFC4033] are
   used.

   In other words, it is NOT recommended to turn off secured DNS
   communications if this value is present.  Rather, a Diameter
   application appropriate error should be thrown to indicate the rule
   cannot be enforced.

   An operator that can accomplish the same use cases, e.g. child
   protection or parental control, without the need to see customer DNS
   traffic is encouraged to do so.

6.2.  SDN AVP Usage

   This document describes SDN related attributes an extension of
   [RFC5777].

   It introduces a new to/from arbitraty mask for IP addresses.  As this
   is an extension to [RFC5777], which already has an IP-Address-Mask
   defined it does not raise new security concerns.





Bertz                    Expires January 7, 2017                [Page 7]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


   This document does introduce the ability to filter upon the IPv6 Flow
   Labels [RFC2460].  Even though this is a visible IP header it was not
   previously defined in Diameter related filters but has been used for
   activities such as Traffic Selection [RFC6088].

   Per [RFC2460] the flow label is used by a source to request special
   handling by routers.  If a specific type of host has known flow label
   usage, i.e. signature, inspection of this field over one or more
   flows may yield information.  However, the flow label is visible in
   the IPv6 header and thus this information is discernable by any
   device with access to the IPv6 packet.  Recommendations on the
   security considerations of IPv6 flow usage is outside of the scope of
   this document.

7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC5777]  Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
              Ed., and A. Lior, "Traffic Classification and Quality of
              Service (QoS) Attributes for Diameter", RFC 5777,
              DOI 10.17487/RFC5777, February 2010,
              <http://www.rfc-editor.org/info/rfc5777>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

   [TGPPCC]   3rd Generation Partnership Project, "Policy Charging and
              Control (PCC); Reference Points, (release 13), 3GPP TS
              29.212 v. 13.5.0", 2016-04.






Bertz                    Expires January 7, 2017                [Page 8]

Internet-Draft Diameter Domain and Arbitrary Mask Filters      July 2016


7.2.  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
              <http://www.rfc-editor.org/info/rfc4592>.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              DOI 10.17487/RFC6088, January 2011,
              <http://www.rfc-editor.org/info/rfc6088>.

   [RFC7155]  Zorn, G., Ed., "Diameter Network Access Server
              Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
              <http://www.rfc-editor.org/info/rfc7155>.

Author's Address

   Lyle Bertz
   Sprint
   6220 Sprint Parkway
   Overland Park, KS  66251
   United States

   Email: lylebe551144@gmail.com






















Bertz                    Expires January 7, 2017                [Page 9]