Network Working Group P. Fan Internet-Draft China Mobile Intended status: Informational July 15, 2013 Expires: January 16, 2014 Requirements for Content Information Export in IP Flow Information Export (IPFIX) draft-fan-ipfix-content-info-req-00 Abstract This document specifies requirements for exporting content related information using IPFIX. 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 16, 2014. Copyright Notice Copyright (c) 2013 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. Fan Expires January 16, 2014 [Page 1] Internet-Draft Content Information Requirements July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Content Information . . . . . . . . . . . . . . . . . . . . . 3 3. Purpose of Exporting Content Information . . . . . . . . . . 3 3.1. Analyzing Purpose . . . . . . . . . . . . . . . . . . . . 4 3.2. Optimizing Purpose . . . . . . . . . . . . . . . . . . . 4 3.3. Business Purpose . . . . . . . . . . . . . . . . . . . . 4 3.4. Security Purpose . . . . . . . . . . . . . . . . . . . . 5 4. Distinguishing Flows with Content Properties . . . . . . . . 5 4.1. Locating the Content Properties . . . . . . . . . . . . . 5 4.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Tunnels and Bearers . . . . . . . . . . . . . . . . . . . 6 4.4. Protocol Fields . . . . . . . . . . . . . . . . . . . . . 6 4.5. Application and Service Information . . . . . . . . . . . 7 5. Content Aware Metering Process . . . . . . . . . . . . . . . 7 5.1. Traffic Handling . . . . . . . . . . . . . . . . . . . . 7 5.2. Instantaneity . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Our internet today employs a large and increasing number of devices with content aware ability. These devices can be traditional routing boxes, middleboxes [RFC3234] performing specialized functions, or monitoring probes placed in the network or on a specific link. No matter in the form of service line card or independent box, content aware function is implemented based on payload information of IP flows other than layer 3 or layer 4 information, and is widely used for different purposes: traffic analyzing, filtering, policy control and charging, security, etc. The IPFIX protocol provides us with ways to give network administrators flow information. A series of standards have been defined by IPFIX WG, including requirements [RFC3917], architecture [RFC5470], protocol specification [I-D.ietf-ipfix-protocol- rfc5101bis], and information model [I-D.ietf-ipfix-information-model- rfc5102bis]. IPFIX already provides Information Elements for every common Layer 4 and Layer 3 packet header field in the IETF protocol suite, basic Layer 2 information, basic counters, timestamps and time ranges, and so on, according to [I-D.draft-ietf-ipfix-ie-doctors]. However, higher-layer content related information export is not yet well standardized. Although [RFC6759] specifies a Cisco extension to Fan Expires January 16, 2014 [Page 2] Internet-Draft Content Information Requirements July 2013 the IPFIX information model to export application information after running application recognition procedure, more granular, well- defined information models that can be used in a universal, interoperable way to gather content information have not been specified. This memo describes requirements for exporting content information of traffic flows, and intends to update [RFC3917]. 2. Content Information Content information tells network administrators what exactly is carried by the flow rather than just flow properties. Compared with traditional IP flow information usually derived from layer 2 to layer 4 header fields, content information focuses on layers above layer 4, and requires deep parse or comprehensive analysis of a packet or an IP flow. The content information commonly expected can be a specific header field, part of the details within the payload a packet, or the application generating the IP flow characterized by an assigned application identifier. Content information covers a wide range of messages revealed from sections encapsulated above transport layer in a packet. The following are 2 categories content information can be briefly divided into. Note that this classification is for illustration purpose, while not meant to come to a strict, academic guidance. In practical use a piece of content information may have multiple characteristics that cannot be fit neatly into a single category. Application information: Application information describes the application or service that is currently carried by the monitored IP flow. This kind of information provides direct clue to the exact content that is transported on the network: a pointer indicating the resource (e.g. URL), a recognized application name (e.g. abc web site) or category (e.g. web browsing). Network information: Network information is closely related with status and statistics of a protocol. It often gives the idea about how a session is established, maintained and torn down, for example HTTP request method, web page download duration, PDP context create latency, etc. 3. Purpose of Exporting Content Information This section describes in what ways content information is used. The following is a selection of reasons of exporting content information and abilities enabled by it. Fan Expires January 16, 2014 [Page 3] Internet-Draft Content Information Requirements July 2013 3.1. Analyzing Purpose Content information helps network administrators make intelligent and synthetic analysis on traffic. Angle of analysis can be application usage, traffic distribution, network performance, or any combination of them. Analyzing purpose is regarded as a basic need for content information, and the results after content analysis are often used for other purposes. Traffic visualizing and mobile network signaling analysis system are typical service for this purpose. Examples of content analysis include: o The traffic volume distribution of a certain application among selected locations. o The success rate and average duration of loading a specific web page. o Average PDP context create times, success rate, and online duration in each PDP connection within a time period. 3.2. Optimizing Purpose By utilizing content information, a variety of optimization functions can be fulfilled, such as policy based traffic control, better resource distribution and improved user experience. The following are some of the examples. o Policy and Charging Control (PCC, see [TS23.203]) and Policy Control Framework (PCF, see [WT-134]) are architectures defined to achieve policy based control functions. The architecture can look into the content and make decisions based on it, e.g. QoS assignment. o CDN or cache systems are used to redistribute resources for better user access. Content information such as requested domain name and URL is basic for normal function of those systems. o Traffic control systems for purpose like restricting P2P traffic is another example. 3.3. Business Purpose Content information helps network administrators provide better services to subscribers, no matter in marketing or operation field. The following are some of the examples. o Content charging is a fresh charging model that performs according to application, service type, etc. Compared with traditional flat Fan Expires January 16, 2014 [Page 4] Internet-Draft Content Information Requirements July 2013 rate or time/volume based charging, it offers customized, differentiated charging strategy. Content charging is also part of the functions of PCC. o Internet usage query with the help of content information is essential when solving customer complaints regarding internet access. 3.4. Security Purpose Security related functions such as application-based firewall, parental control, intrusion detection and abnormal flow detection also require content information. 4. Distinguishing Flows with Content Properties Traffic flows are distinguished by properties in the flows as described in [RFC3917]. Packets with the same properties in the predefined property set are considered to be within the same flow, while packets with one or more different properties are mapped into different flows. A metering process with content awareness must also meet the fundamental packet evaluation ability requirement in section 4 of [RFC3917], as those basic properties (e.g. IP header fields, transport header fields, MPLS label, etc.) serve as fundamental marks of flows. A traffic flow can also be distinguished with content information properties by a metering process with content awareness, though the approaches of evaluating content information and distinguishing flows by it require special abilities. The following subsections describe a list of considerations of content aware flow distinguishing and content properties used for evaluation. 4.1. Locating the Content Properties A significant difference regarding content information evaluation is that it is not performed on the basis of signal packets but frequently on a series of packets related with each other forming a traffic "stream" (e.g. a session, a five-tuple defined flow, etc.). The properties of a flow may not exist in every packet, for example: o Properties only exist in certain position(s) of a stream, e.g. the target URL of an HTTP transaction exists in the request message. Fan Expires January 16, 2014 [Page 5] Internet-Draft Content Information Requirements July 2013 o Properties do not exist in the stream to be metered and have to be associated to the stream by the metering process. For example, the network information of a mobile core network can be retrieved in different stages in GTP-C protocol, while service traffic is carried by GTP-U protocol. o Properties are the overall characteristic of the stream, e.g. the application identifier that describes the entire traffic. So in case of content aware flow distinguishing, the procedure is more like evaluating the properties of flows and identifying them, than evaluating the properties of packets and map them to flows. A metering process with content awareness must be able to evaluate content properties retrieved from traffic. 4.2. Encryption If the traffic containing content properties is encrypted, metering process requiring direct access to those properties is likely to be affected. This kind of metering process must meet the requirements in this section for traffic that have the properties required by the process unencrypted. Compared with metering process requiring direct access to certain information, there is another kind of metering process based on statistic features or connection behaviors of traffic, which is able to identify applications in case of encryption. This kind of metering process must meet the requirement in subsection 4.5 despite of encryption. 4.3. Tunnels and Bearers Many applications run over a tunneling protocol or a protocol acting as a session or presentation bearer. Content information may be carried in the tunnel, bearer and the application traffic that runs above them. A metering process must be able to comprehend the encapsulation and separate flows by information properties in the encapsulation or the encapsulated section. 4.4. Protocol Fields The metering process must be able to separate flows by examining the content properties contained in protocol fields, for example: o An HTTP browsing transaction characterized by the resource URL in the Request-URI field of the request message. Fan Expires January 16, 2014 [Page 6] Internet-Draft Content Information Requirements July 2013 o A DNS query transaction characterized by the domain name in the Question section of the query message. 4.5. Application and Service Information If the metering process is equipped with the function of classifying the application, service or their category traffic belongs to, the metering process must be able to separate flows by application/ service information, e.g. skype, VoIP, etc. 5. Content Aware Metering Process This section describes requirements for the content aware metering process, and is meant to complement and update section 5 of [RFC3917]. 5.1. Traffic Handling The metering process must be able to handle the traffic as a whole and evaluate content information in a global perspective, in addition to the traditional packet header based metering approach. The following is a few specific requirements for the metering process. o The metering process must be able to deal with required traffic granularity based on needs. For example, a stream of application traffic consisting of several TCP flows, or a specific TCP transaction in a large GTP tunnel. o Many applications and protocols work on a bidirectional session, transaction, or dialog mode. The metering process must be able to associate related packet streams to correctly interpret content information in them. o Many protocols are implemented on separated planes, e.g. FTP, GTP, etc. The metering process must be able to associate and comprehend information on different planes. 5.2. Instantaneity The content information may be used by other systems or applications for purposes described in section 3. Some systems may use it for offline analysis, while some may perform real-time feedback onto the traffic (e.g. rate limiting). The metering process must meet the instantaneity requirements based on needs of the systems. 6. Security Considerations TBD. Fan Expires January 16, 2014 [Page 7] Internet-Draft Content Information Requirements July 2013 7. IANA Considerations This memo includes no request to IANA. 8. References 8.1. Normative References [I-D.draft-ietf-ipfix-ie-doctors] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IPFIX Information Elements", draft-ietf- ipfix-ie-doctors-07 (Work in Progress), October 2012. [I-D.ietf-ipfix-information-model-rfc5102bis] Claise, B. and B. Trammell, "Information Model for IP Flow Information eXport (IPFIX)", draft-ietf-ipfix-information- model-rfc5102bis-10 (Work in Progress), February 2013. [I-D.ietf-ipfix-protocol-rfc5101bis] Claise, B., Trammell, B., Aitken, P., Bryant, S., Leinen, S., and T. Dietz, "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-08 (Work in Progress), June 2013. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. [RFC6957] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", RFC 6957, November 2012. 8.2. Informative References [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [TS23.203] 3GPP Technical Specification 23.203, ., "Policy and charging control architecture", March 2012. [WT-134] BBF STRAW BALLOT WT-134, ., "Broadband Policy Control Framework (PCF)", February 2012. Fan Expires January 16, 2014 [Page 8] Internet-Draft Content Information Requirements July 2013 Author's Address Peng Fan China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: fanpeng@chinamobile.com Fan Expires January 16, 2014 [Page 9]