Network Working Group A. Lior Internet-Draft Bridgewater Systems Intended status: Standards Track June 27, 2007 Expires: December 29, 2007 Diameter Claissifier draft-lior-diameter-classifier-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lior Expires December 29, 2007 [Page 1] Internet-Draft Diameter Classifier June 2007 Abstract Many Diameter applications require to classify packets. Diameter base protocols provides an IP Filter Rule type and a QoS Filter Rule type that is being used to classify packets. However, because these types were defined for specific uses and defined in ways that are hard to extend and therefore are not generally applicable for those applications that require packet classifiers. This document describes a set of Diameter types that are useful to create packet classifiers. The packet classier type can be used by various applications to express packet classifiers that best match the application's specific needs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Classifier Attribute Overview . . . . . . . . . . . . . . . . 5 4. Classifier AVP . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Source and Destination Attributes . . . . . . . . . . . . 9 5.1.1. Inverted AVP . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. IPAddress AVP . . . . . . . . . . . . . . . . . . . . 9 5.1.3. Port AVP . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.4. IPAddressRange AVP . . . . . . . . . . . . . . . . . . 9 5.1.5. IPAddressMask AVP . . . . . . . . . . . . . . . . . . 10 5.1.6. PortRange AVP . . . . . . . . . . . . . . . . . . . . 10 5.1.7. Assigned AVP . . . . . . . . . . . . . . . . . . . . . 10 5.2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. FragFlag AVP . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. IPOptions AVP . . . . . . . . . . . . . . . . . . . . 10 5.2.3. TCPOptions AVP . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Established AVP . . . . . . . . . . . . . . . . . . . 11 5.2.5. Setup AVP . . . . . . . . . . . . . . . . . . . . . . 11 5.2.6. TCPFlags AVP . . . . . . . . . . . . . . . . . . . . . 11 5.2.7. ICMPTypes . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Lior Expires December 29, 2007 [Page 2] Internet-Draft Diameter Classifier June 2007 1. Introduction The Diameter base protocol [2] defines two data formats, IPFilterRule and QoSFilterRule. IPFilterRule is designed to implement packet filters and QoSFilterRule tagging and metering of packets. Both of these data formats are expressed as an ASCII string which makes it impossible to extend and also makes it difficult to parse and thus equipment suffer a performance hit. Many applications require to express packet classifiers. QoS based applications need to be able to express which packets to apply a certain QoS treatment. Charging applications need to be able to express which packets should be have certain charging rules applied to them. Some applications need to be able to redirect certain packets. The packet classifiers need to be able to classify packets at the various layers and various protocols. For example, it should be possible to build a classifier to work on layer 2 protocols and build another classifier that works on layer 3 protocols such as IPv4 or IPv6. Classifiers must also be able to utilize various attributes that are utilized in these layers and protocols. Lior Expires December 29, 2007 [Page 3] Internet-Draft Diameter Classifier June 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Lior Expires December 29, 2007 [Page 4] Internet-Draft Diameter Classifier June 2007 3. Classifier Attribute Overview Classifiers are used in many applications to specify how to classify packets. For example in a QoS application, if a packet matches a classifier then that packet will be treated in accordance with a QoS specification associated with that classifier. The Classifiers are sent to on on-path element (e.g. a router) which uses the classifier to match packets. Figure 1 shows a typical deployement. +-----------+ +-----------+| +--------+ +-------------+ +------------+|| | | IN | | | ||| | +--------->| +------------->| ||| |Managed | | Classifier | | Unmanaged ||| |Terminal| OUT | Entity | | Terminal ||| | |<---------+ |<-------------+ ||+ | | | | | |+ +--------+ +-------------+ +------------+ ^ | Classifiers | +------+-------+ | | | AAA | | | +--------------+ Figure 1: Example of a Classifier Architecture The managed terminal, the terminal for which the classifiers are being specified is located on the left of the Classifer Entity. The unmanged terminal, the terminal that recieves packets from the Managed terminal or sends packets to the managed terminal is located to the right side of the Classifier Entity. The Classifier Entity is reponsible for classifying packets that are incoming (IN) from the Managed Terminal or packets outgoing (OUT) to the Managed Terminal. A Classifier consists of a group of attributes that specify how to match a packet. Each attributes expresses values about aspects of the packet - typically the packet header. Different protocols therefore would use different attributes. In general a Classifier consists of the following: Lior Expires December 29, 2007 [Page 5] Internet-Draft Diameter Classifier June 2007 Identifier: The identifier uniquely identifies this classifier and maybe used to reference the classifier from another structure. From: Specifies the rule for matching the source part of the packet. To: Specifies the rule for matching the destination part of the packet. Protocol Specifies the matching protocol of the packet. Direction: Specifies whether the classifier is to apply to packets flowing from the Managed Terminal (IN) or to packets flowing to the Managed Terminal (OUT), or packets flowing in both direction. Options: Associated with each protocol or layer, or various values specific to the header of the protocol or layer. Options allow matching on those values. Each protocol type will have a specific set of attributes that can be used to specify a classifier for that protocol. These attributes will be grouped under a grouped AVP called a Classifier AVP. Lior Expires December 29, 2007 [Page 6] Internet-Draft Diameter Classifier June 2007 4. Classifier AVP The Classifier AVP is a grouped AVP that consists of the following: ClassifierID AVP: The ClassifierID AVP is of type OctetString that uniquely identifies the classifier. Each Classifier MUST have a single instance of the attribute. Each application will define whether this identifier is unique per terminal or globally unique. Exactly one ClassierID AVP MUST be contained within a Classifier AVP. Protocol AVP The Protocol AVP is of type enumeration that specifies the protocol being matched. The attributes included in the Classifier AVP must be consistant with this value of the Protocol AVP. Exactly one of Protocol AVP MUST be contained within a Classifier AVP. Direction AVP: The Direction AVP is of type enumeration that pecifies in which direction to apply the Classifier. The values of the enumeration are: "IN","OUT","INOUT". In the "IN" and "INOUT" directions, the From-Spec refers to the address of the Managed Terminal and the To-Spec refers to the unmanaged terminal. In the "OUT" direction, the From-Spec refers to the Unmanaged Terminal whereas the To-Spec refers to the Managed Terminal. From-Spec AVP: This grouped AVP specifies the Source Specification used to match the packet. Zero or more of these attributes may appear in the classifier. If the attribute is absent from the classifier then the source address is not being matched (wild card). If more then one attribute of this type appears in the Classifier then the attributes are used in the order specified. The contents of this AVP are protocol specific. To-Spec: This grouped AVP specifies the Destination Specification used to match the packet. Zero or more of these attributes may appear in the classifier. If the attribute is absent from the classifier then the destination address is not being matched (wild card). If more then one attribute of this type appears in the Classifier Lior Expires December 29, 2007 [Page 7] Internet-Draft Diameter Classifier June 2007 then the attributes are used in the order specified. The contents of this AVP are protocol specific. Lior Expires December 29, 2007 [Page 8] Internet-Draft Diameter Classifier June 2007 5. IP Classifiers The following specifies the attribute types that can be used to build classifiers for IP based protocols. 5.1. Source and Destination Attributes For IP classification the contents of the From-Spec and To-Spec can contain the following attributes. Combinging several of this attributes within a From-Spec and To-Spec and using more then one From-Spec and To-Spec AVP one can express many different types IP address pools. 5.1.1. Inverted AVP This attribute is of Enumerated [2] contianing the values of True or False. Exactly zero or one of these attributes may appear in a From- Spec of a To-Spec. When set to True the meaning of the match in the To-Spec and From-Spec are inverted, causing all other addresses to be matched instead. When set to False, or when the attribute is not included in the From- Spec and To-Spec then the meaning of the match is not inverted, causing only the addresses specified to be matched. This is equivalent to the '!' character of the IPFilterRule. Note that inversion does not impact the ports matchers. 5.1.2. IPAddress AVP The IPAddress AVP is of type Address [2] and specifies an exactly IP address (IPv4 or IPv6) address to match. Zero or more of these attributes may appear in the From-Spec and the To-Spec grouped AVP. 5.1.3. Port AVP The Port AVP is of type Integer32 and has a maximum value of 65535 and specifies the port to match. Note the port attribute is not impacted by the Invertion AVP. 5.1.4. IPAddressRange AVP The IPAddressRange is a grouped AVP containing an IPAddressStart and IPAddressStop AVP of type Address that specifies an inclusive IP address range. Lior Expires December 29, 2007 [Page 9] Internet-Draft Diameter Classifier June 2007 If the IPAddressStart is not included then the address range starts from the first valid IP address to and including the specified IPAddressStop address. If the IPAddressStop is not included then the address range starts at the address specified by the IPAddressStart AVP and includes all the remaining valid IP addresses. 5.1.5. IPAddressMask AVP The IPAddressMask AVP is ag grouped AVP expressing an IP address range using a base IP address and a bit-mask as in: 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit-mask width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the bit-mask. 5.1.6. PortRange AVP The PortRange is a grouped AVP containing an PortStart and PortEnd AVPs of type Integer32 which specify an inclusive range of ports. If the PortStart range is omitted then port 0 is assumed. If PortEnd is omitted then port 65535 is assumed. Port Range is not impacted by the Inversion AVP. 5.1.7. Assigned AVP Often, the AAA does not know the IP address assigned to the Managed Terminal. The Assigned AVP is of type Enumeration and consist of the value "Assigned". When present, it represents the IP address assigned to the Managed Terminal. 5.2. IP Options The Classifer Grouped AVP may contain one or of the following AVP used to match on the various possible IP options. 5.2.1. FragFlag AVP Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. 5.2.2. IPOptions AVP Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source Lior Expires December 29, 2007 [Page 10] Internet-Draft Diameter Classifier June 2007 route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'. 5.2.3. TCPOptions AVP Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. 5.2.4. Established AVP TCP packets only. Match packets that have the RST or ACK bits set. 5.2.5. Setup AVP TCP packets only. Match packets that have the SYN bit set but no ACK bit. 5.2.6. TCPFlags AVP TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. 5.2.7. ICMPTypes ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). Lior Expires December 29, 2007 [Page 11] Internet-Draft Diameter Classifier June 2007 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Lior Expires December 29, 2007 [Page 12] Internet-Draft Diameter Classifier June 2007 Author's Address Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario Canada K2K 3J1 Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Lior Expires December 29, 2007 [Page 13] Internet-Draft Diameter Classifier June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lior Expires December 29, 2007 [Page 14]