Diameter Maintenance and Extensions L. Bertz
Internet-Draft Sprint
Intended status: Standards Track July 8, 2016
Expires: January 9, 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 9, 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.

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

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

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.

      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:

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 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 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 Code Section Defined Data Type
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.

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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M. and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012.
[TGPPCC] 3rd Generation Partnership Project, "Policy Charging and Control (PCC); Reference Points, (release 13), 3GPP TS 29.212 v. 13.5.0", 2016-04.

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.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H. and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011.
[RFC7155] Zorn, G., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014.

Author's Address

Lyle Bertz Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States EMail: lylebe551144@gmail.com