Requirements for Content Information Export in IP Flow Information Export (IPFIX)
draft-fan-ipfix-content-info-req-00

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]