IPFIX Working Group A. Kobayashi Internet-Draft NTT PF Lab. Intended status: Informational B. Claise Expires: October 22, 2010 Cisco Systems, Inc. G. Muenz TU Muenchen K. Ishibashi NTT PF Lab. April 20, 2010 IPFIX Mediation: Framework draft-ietf-ipfix-mediators-framework-06 Abstract This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components. 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 October 22, 2010. Copyright Notice Copyright (c) 2010 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 Kobayashi, et al. Expires October 22, 2010 [Page 1] Internet-Draft IPFIX Mediation Framework April 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 3. IPFIX/PSAMP Documents Overview . . . . . . . . . . . . . . . . 7 3.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 7 3.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 7 4. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 8 5. IPFIX Mediation Functional Blocks . . . . . . . . . . . . . . 13 5.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 13 5.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 14 5.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 14 5.3.1. Data Record Expiration . . . . . . . . . . . . . . . . 15 5.3.2. Specific Intermediate Processes . . . . . . . . . . . 16 6. Component Combination . . . . . . . . . . . . . . . . . . . . 21 6.1. Data-based Collector Selection . . . . . . . . . . . . . . 21 6.2. Flow Selection and Aggregation . . . . . . . . . . . . . . 22 6.3. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 23 7. Encoding for IPFIX Message Header . . . . . . . . . . . . . . 24 8. Information Model . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Kobayashi, et al. Expires October 22, 2010 [Page 2] Internet-Draft IPFIX Mediation Framework April 2010 1. Introduction The IPFIX architectural components in [RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol. Due to the sustained growth of IP traffic in heterogeneous network environments, this Exporter-Collector architecture may lead to scalability problems. In addition, it does not provide the flexibility required by a wide variety of measurement applications. A detailed descriptions of these problems is given in [IPFIX-MD-PS]. To fulfill application requirements with limited system resources, IPFIX architecture needs to introduce an intermediate entity between Exporters and Collectors. From a data manipulation point of view, this intermediate entity provides the aggregation, correlation, filtering, and modification of Flow Records and/or PSAMP Packet Reports to save measurement system resources and to perform preprocessing tasks for the Collector. From a protocol conversion point of view, this intermediate entity provides conversion into IPFIX, or conversion of IPFIX transport protocols (e.g., from UDP to SCTP) to improve the export reliability. This document introduces a generalized concept for such intermediate entities and describes the high-level architecture of IPFIX Mediation, key IPFIX Mediation architectural components, and characteristics of IPFIX Mediation. This document is structured as follows: section 2 describes the terminology used in this document, section 3 gives an IPFIX/PSAMP document overview, section 4 describes a high-level reference model, section 5 describes functional features related to IPFIX Mediation, section 6 describes combinations of components along with some application examples, section 7 describes consideration points of the encoding for IPFIX Message headers, and section 8 describes the Information Elements used in an IPFIX Mediator. Kobayashi, et al. Expires October 22, 2010 [Page 3] Internet-Draft IPFIX Mediation Framework April 2010 2. Terminology and Definitions The IPFIX-specific and PSAMP-specific terminology used in this document is defined in [RFC5101] and [RFC5476], respectively. The IPFIX Mediation-specific terminology used in this document is defined in [IPFIX-MD-PS]. However, as reading the problem statements document is not a prerequisite to reading this framework document, the definitions have been reproduced here along with additional definitions. In this document, as in [RFC5101] and [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific term defined here. The use of the terms "must", "should", and "may" in this document are informational only. In this document, we call "record stream" a stream of records carrying flow- or packet-based information. The records may be encoded as IPFIX Data Records or in any other format. Transport Session Information The Transport Session is specified in [RFC5101]. In SCTP, the Transport Session Information is the SCTP association. In TCP and UDP, the Transport Session Information corresponds to a 5-tuple {Exporter IP address, Collector IP address, Exporter transport port, Collector transport port, transport protocol}. Original Exporter An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed. IPFIX Mediation IPFIX Mediation is the manipulation and conversion of a record stream for subsequent export using the IPFIX protocol. The following terms are used in this document to describe the architectural entities used by IPFIX Mediation. Intermediate Process An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream, based upon the content of each record, states maintained across multiple records, or other data sources; and passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Kobayashi, et al. Expires October 22, 2010 [Page 4] Internet-Draft IPFIX Mediation Framework April 2010 Intermediate Processes, in order to perform IPFIX Mediation. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Specific Intermediate Processes are described below. However, this is not an exhaustive list. Intermediate Conversion Process An Intermediate Conversion Process is an Intermediate Process that transforms non IPFIX into IPFIX, or manages the relation among Templates and states of incoming/outgoing transport sessions in the case of transport protocol conversion (e.g., from UDP to SCTP). Intermediate Aggregation Process An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a set of Flow Keys or functions applied to fields from the record (e.g., binning and subnet aggregation). Intermediate Correlation Process An Intermediate Correlation Process is an Intermediate Process that adds information to records, noting correlations among them, or generates new records with correlated data from multiple records (e.g., the production of bidirectional flow records from unidirectional flow records). Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., filtering only records from a given network to a given Collector). Intermediate Anonymization Process An Intermediate Anonymization Process is an Intermediate Process that transforms records in order to anonymize them, to protect the identity of the entities described by the records (e.g., by applying prefix-preserving pseudonymization of IP addresses). Kobayashi, et al. Expires October 22, 2010 [Page 5] Internet-Draft IPFIX Mediation Framework April 2010 IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation by receiving a record stream from some data sources, hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives a record stream from a Collecting Process, but it could also receive a record stream from data sources not encoded using IPFIX, e.g., in the case of conversion from the NetFlow V9 protocol [RFC3954] to IPFIX protocol. Note that the IPFIX Mediator is a generalization of the concentrator and proxy elements envisioned in the IPFIX requirements [RFC3917]. IPFIX Mediators running appropriate Intermediate Processes provide the functionality specified therein. Kobayashi, et al. Expires October 22, 2010 [Page 6] Internet-Draft IPFIX Mediation Framework April 2010 3. IPFIX/PSAMP Documents Overview IPFIX Mediation can be applied to flow- or packet-based information. The flow-based information is encoded by IPFIX protocol, and the packet-based information is extracted by some sampling techniques and then encoded by PSAMP protocol. Thus, this section describes relevant documents for both protocols. 3.1. IPFIX Documents Overview The IPFIX protocol [RFC5101] provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their names, types, and additional semantic information, as specified in [RFC5102]. [IPFIX-MIB] specifies the IPFIX Management Information Base. Finally, [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. The storage of IPFIX Messages in a file is specified in [RFC5655]. 3.2. PSAMP Documents Overview The framework for packet selection and reporting [RFC5474] enables network elements to select subsets of packets by statistical and other methods and to export a stream of reports on the selected packets to a Collector. The set of packet selection techniques (sampling and filtering) standardized by PSAMP is described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a Collector. Like IPFIX, PSAMP has a formal description of its Information Elements, their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477]. [PSAMP-MIB] describes the PSAMP Management Information Base. Kobayashi, et al. Expires October 22, 2010 [Page 7] Internet-Draft IPFIX Mediation Framework April 2010 4. IPFIX Mediation Reference Model Figure A shows the high-level IPFIX Mediation reference model as an extension of the IPFIX reference model presented in [RFC5470]. This figure covers the various possible scenarios that can exist in an IPFIX measurement system. +----------------+ +---------------+ +---------------+ | Collector 1 | | Collector 2 | | Collector N | |[Collecting | |[Collecting | |[Collecting | | Process(es)] | | Process(es)] |... | Process(es)] | +----^-----------+ +---^--------^--+ +--------^------+ | / \ | | / \ | Flow Records Flow Records Flow Records Flow Records | / \ | +------+-------------+------+ +------+-----------+--------+ |IPFIX Mediator M | |IPFIX Mediator Z | |[Exporting Process(es)] | |[Exporting Process(es)] | |[Intermediate Process(es)] | |[Intermediate Process(es)] | |[Collecting Process(es)] |... |[Collecting Process(es)] | +----^----------------^-----+ +------^----------------^---+ | | | | Flow Records Flow Records Packet Reports record stream | | | | +------+------+ +------+-------+ +------+-------+ +-----+-----+ |IPFIX | |IPFIX Original| |PSAMP Original| |Other | | Mediator 1 | | Exporter 1 | | Exporter 1 | | Source 1 | |+-------------+ |+--------------+ |+--------------+ |+-----------+ +|IPFIX | +|IPFIX Original| +|PSAMP Original| +|Other | | Mediator N | | Exporter N | | Exporter N | | Source N | |[Exporting | |[Exporting | |[Exporting | | | | Process(es)]| | Process(es)]| | Process(es)]| | | |[Intermediate| |[Metering | |[Metering | | | | Process(es)]| | Process(es)]| | Process(es)]| | | |[Collecting | |[Observation | |[Observation | | | | Process(es)]| | Point(s)]| | Point(s)]| | | +------^------+ +-----^-^------+ +-----^-^------+ +-----------+ | | | | | Flow Records Packets coming Packets coming into Observation into Observation Points Points Figure A: IPFIX Mediation Reference Model Overview. The functional components within each entity are indicated within brackets []. An IPFIX Mediator receives IPFIX Flow Records or PSAMP Kobayashi, et al. Expires October 22, 2010 [Page 8] Internet-Draft IPFIX Mediation Framework April 2010 Packet Records from other IPFIX Mediators, IPFIX Flow Records from IPFIX Original Exporters, PSAMP Packet Reports from PSAMP Original Exporters, and/or a record stream from other sources. The IPFIX Mediator then exports IPFIX Flow Records and/or PSAMP Packet Reports to one or multiple Collectors and/or other IPFIX Mediators. Figure B shows the basic IPFIX Mediator component model. An IPFIX Mediator contains one or more Intermediate Processes and one or more Exporting Processes. In typical case, it contains a Collecting Process, as described in Figure B below. IPFIX (Data Records) ^ ^ | +------------------------|-|---------------------+ | IPFIX Mediator | | | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Exporting Process(es) |' | | '----------------------^--------------------' | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Intermediate Process(es) |' | | '----------------------^--------------------' | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Collecting Process(es) |' | | '----------------------^--------------------' | +------------------------|-|---------------------+ | IPFIX (Data Records) Figure B: Basic IPFIX Mediator Component Model. Kobayashi, et al. Expires October 22, 2010 [Page 9] Internet-Draft IPFIX Mediation Framework April 2010 However, other data sources are also possible: an IPFIX Mediator can receive a record stream from non-IPFIX protocols such as NetFlow [RFC3954] exporter(s). This document does not make any particular assumption on how a record stream is transferred to an IPFIX Mediator. Figure C below shows the IPFIX Mediator component model in the case of IPFIX protocol conversion from non-IPFIX exporters, so receiving a record stream. IPFIX (Data Records) ^ ^ | +------------------------|-|---------------------+ | IPFIX Mediator | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Exporting Process(es) |' | | '----------------------^--------------------' | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Intermediate Process(es) |' | | '----------------------^--------------------' | +------------------------|-----------------------+ | record stream +------------------------|-----------------------+ | Non-IPFIX exporter | | | +-------------+----------+ | | | | | +----------|------------------------|------------+ | | Packets coming into observation points Figure C: IPFIX Mediator Component Model in IPFIX Protocol Conversion. Kobayashi, et al. Expires October 22, 2010 [Page 10] Internet-Draft IPFIX Mediation Framework April 2010 Alternatively, an Original Exporter may provide IPFIX Mediation by hosting one or more Intermediate Processes. The component model in Figure D adds Intermediate Process(es) to the IPFIX Device model illustrated in [RFC5470]. In comparison with Figure 1 or 2 in [RFC5470], the Intermediate Process is located between IPFIX Metering Process(es), or PSAMP Metering Process(es) and Exporting Process(es). IPFIX (Data Records) ^ ^ +---------------------------|-|------------------------+ | Original Exporter | | | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Exporting Process(es) |' | | '----------------------^--------------------' | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Intermediate Process(es) |' | | '---------^-----------------------^---------' | | | Data Records | | | .----------+---------. .---------+----------. | | | Metering Process 1 |...| Metering Process N | | | '----------^---------' '---------^----------' | | | | | | .-----------+---------. .---------+-----------. | | | Observation Point 1 |...| Observation Point N | | | '-----------^---------' '---------^-----------' | +--------------|-----------------------|---------------+ | | Packets coming into Observation Points Figure D: IPFIX Mediation Component Model at Original Exporter. Kobayashi, et al. Expires October 22, 2010 [Page 11] Internet-Draft IPFIX Mediation Framework April 2010 In addition, an Intermediate Process may be collocated with an IPFIX File Reader and/or Writer. Figure E shows an IPFIX Mediation component model with an IPFIX File Writer and/or Reader. IPFIX (Data Records) ^ ^ | .----------------------|-+--------------------. .-----------------------+---------------------.| | IPFIX File Writer |' '-----------------------^---------------------' | | .----------------------|-+--------------------. .-----------------------+---------------------.| | Intermediate Process(es) |' '-----------------------^---------------------' | | .----------------------|-+--------------------. .-----------------------+---------------------.| | IPFIX File Reader |' '-----------------------^---------------------' | IPFIX (Data Records) Figure E: IPFIX Mediation Component Model collocated with IPFIX File Writer/Reader. Kobayashi, et al. Expires October 22, 2010 [Page 12] Internet-Draft IPFIX Mediation Framework April 2010 5. IPFIX Mediation Functional Blocks Figure F shows a functional block diagram example in an IPFIX Mediator, having different Intermediate Process types. IPFIX IPFIX IPFIX ^ ^ ^ | | | .------------. .-----+-------. .-----+-------. .------+------. | IPFIX File | | Exporting | | Exporting | | Exporting | | Writer | | Process 1 | | Process 2 |....| Process N | '-----^-^----' '-----^-------' '-----^-------' '------^------' | | | | | | +-------------+ | | : Flow Records / Packet Reports : .------+-------. .-----+--------. .----+---------. .--------------. | Intermediate | | Intermediate | | Intermediate | | Intermediate | | Anonymization| | Correlation | | Aggregation | | Selection | | Process N | | Process N | | Process N | | Process N | '------|-------' '------|-------' '-----|-|------' '-------|------' | +---------------+ | | : : : : .------+-------. .------+-------. .-------+------. .-------+------. | Intermediate | | Intermediate | | Intermediate | | Intermediate | | Selection | | Selection | | Selection | | Selection | | Process 1 | | Process 2 | | Process 3 | | Process 4 | '------|-|-----' '------|-------' '-----|--------' '-------|------' | +--------------+ | +----------------+ | | | | | : Flow Records / Packet Reports : .------+------. .-------+-----. .-----+-+-----. .-----+------. | Collecting | | Collecting | | Collecting | | IPFIX File | | Process 1 | | Process 2 |...| Process N | | Reader | '------^------' '------^------' '------^------' '------------' | | | Flow Records Flow Records Flow Records Figure F: IPFIX Mediation Functional Block. 5.1. Collecting Process A Collecting Process in an IPFIX Mediator is not different from the Collecting Process described in [RFC5101]. Additional functions in an IPFIX Mediator include transmitting the set of Data Records and Control Information to one or more components, i.e., Intermediate Processes and other applications. In other words, a Collecting Process may duplicate the set and transmit it to one or more components in sequence or in parallel. In the case of an IPFIX Kobayashi, et al. Expires October 22, 2010 [Page 13] Internet-Draft IPFIX Mediation Framework April 2010 Mediator, the Control Information described in [RFC5470] includes IPFIX Message header information and Transport Session Information along with information about the Metering Process and the Exporting Process in an Original Exporter, e.g., sampling parameters. 5.2. Exporting Process An Exporting Process in an IPFIX Mediator is not different from the Exporting Process described in [RFC5101]. Additional functions in an IPFIX Mediator may include the following. o Receiving the trigger to transmit the Template Withdrawal Messages from Intermediate Process(es) when relevant Templates become invalid due to, for example, incoming session failure. o Transmitting the origin (e.g., Observation Point, Observation Domain ID, Original Exporter IP address, etc.) of the data in additional Data Record fields or additional Data Records. This function must be configurable. 5.3. Intermediate Process An Intermediate Process is a key functional block for IPFIX Mediation. Its typical functions include the following: o Generating a new record stream from an input record stream including context information (e.g., "Export Time", "Observation Domain ID", and Transport Session Information), and transmitting it to other components. o Reporting statistics and interpretations for IPFIX Metering Processes, PSAMP Metering Processes, and Exporting Processes from an Original Exporter. See section 4 of [RFC5101] and section 6 of [RFC5476] for relevant statistics data structures and interpretations, respectively. This function must be configurable. o Maintaining the configurable relation between Collecting Process(es)/Metering Process(es) and Exporting Process(es)/other Intermediate Process(es). A Collecting Process or Metering Process participating in IPFIX Mediation is associated with at least one Intermediate Process. Furthermore, an Intermediate Process is associated with at least one Exporting Process or another Intermediate Process. This relation can be configurable. Kobayashi, et al. Expires October 22, 2010 [Page 14] Internet-Draft IPFIX Mediation Framework April 2010 o Maintaining database(s) of all the Data Records in the case of an Intermediate Aggregation Process and an Intermediate Correlation Process. The function has the Data Record expiration rules described in the next subsection. o Maintaining statistics on the Intermediate Process itself, such as the number of input/output Data Records, etc. o Maintaining additional information about output record streams, which includes information related to Original Exporter, Observation Domain, and administrative domain and some configuration parameters related to each function. In the case of an Intermediate Aggregation Process, Intermediate Anonymization Process, and Intermediate Correlation Process, the value of the "flowKeyIndicator" needs to be modified when modifying the data structure defined by an original Template. 5.3.1. Data Record Expiration An Intermediate Aggregation Process and Intermediate Correlation Process need to have expiration conditions to export cached Data Records. In the case of the Metering Process in an Original Exporter, these conditions are described in [RFC5470]. In the case of the Intermediate Process, these conditions are as follows: o If there are no input Data Records belonging to a cached Flow for a certain time period, aggregated Flow Records will expire. This time period should be configurable at the Intermediate Process. o If the Intermediate Process experiences resource constraints, aggregated Flow Records may prematurely expire (e.g., lack of memory to store Flow Records). o For long-running Flows, the Intermediate Process should cause the Flow to expire on a regular basis or on the basis of an expiration policy. This periodicity or expiration policy should be configurable at the Intermediate Process. In the case of an Intermediate Correlation Process, a cached Data Record may be prematurely expired (and discarded) when no correlation can be computed with newly received Data Records. For example, an Intermediate Correlation Process computing one way delay may discard the cached Packet Report when no other matching packet Report are observed within a certain time period. Kobayashi, et al. Expires October 22, 2010 [Page 15] Internet-Draft IPFIX Mediation Framework April 2010 5.3.2. Specific Intermediate Processes This section describes the functional blocks of specific Intermediate Processes. 5.3.2.1. Intermediate Conversion Process When receiving a non-IPFIX record stream, the Intermediate Conversion Process covers the following functions: o Determining the IPFIX Information Element identifiers which correspond to the fields of the non-IPFIX records (e.g., converting NetFlow V9 protocol [RFC3954] to IPFIX Information Model [RFC5102]). o Transforming the non-IPFIX records into Data Records, (Options) Template Records, and/or Data Records defined by Options Templates. o Converting additional information (e.g., Sampling rate, Sampling algorithm, and observation information) into appropriate fields in the existing Data Records or into Data Records defined by new Option Templates. IPFIX transport protocol conversion can be used to enhance the export reliability, for example for data retention and accounting. In this case, the Intermediate Conversion Process covers the following functions: o Relaying Data Records, (Options) Template Records, and Data Records defined by Options Templates. o Setting the trigger for the Exporting Process in order to export IPFIX Template Withdrawal Messages relevant to the Templates when Templates becomes invalid due to, for example, incoming session failure. This case applies to SCTP and TCP Transport Sessions on the outgoing side, only. o Maintaining the mapping information about Transport Sessions, Observation Domain IDs, and Template IDs on the incoming and outgoing sides to ensure the appropriateness of the scope field values in Data Records defined by Options Templates and of IPFIX Template Withdrawal Messages. Kobayashi, et al. Expires October 22, 2010 [Page 16] Internet-Draft IPFIX Mediation Framework April 2010 5.3.2.2. Intermediate Selection Process An Intermediate Selection Process has analogous functions to the PSAMP Selection Process described in [RFC5475]. The difference is that the Intermediate Selection Process takes a record stream, e.g., Flow Records or Packet Reports, instead of observed packets. The typical function is property match filtering that retrieves a record stream of interest. The function selects a Data Record if the value of a specific field in the Data Record equals a configured value or falls within a configured range. 5.3.2.3. Intermediate Aggregation Process An Intermediate Aggregation Process covers the following functions: o Merging a set of Data Records within a certain time period into one Flow Record by summing up the counters where appropriate. o Maintaining statistic and additional information about aggregated Flow Records. The statistics for an aggregated Flow Record may include the number of original Data Records and the maximum and minimum values of per-flow counters. Additional information may include an aggregation time period, a new set of Flow Keys, and observation location information involved in the Flow aggregation. Observation location information can be tuples of (Observation Point, Observation Domain ID, Original Exporter IP address) or another identifier indicating the location where the measured traffic has been observed. o Aggregation of Data Records, which can be done in the following ways: * Spatial composition With spatial composition, Data Records sharing common properties are merged into one Flow Record within a certain time period. One typical aggregation can be based on a new set of Flow Keys. Generally, a smaller set of common properties than an original set of Flow Keys results in a higher level of aggregation. Another aggregation can be based on a set of Observation Points within an Observation Domain, on a set of Observation Domains within an Exporter, or on a set of Exporters. Kobayashi, et al. Expires October 22, 2010 [Page 17] Internet-Draft IPFIX Mediation Framework April 2010 If some fields do not serve as Flow Keys or per-Flow counters, and their values may change from Data Records to Data Records within an aggregated Flow Record, the Intermediate Aggregation Process determines their values by the first Data Record received, a specific Exporter IP address, or other appropriate decisions. Furthermore, a new identifier indicating a group of observation locations can be introduced, for example, to indicate PoP (Points of Presence) in a large network, or a logical interface composed of physical interfaces with link aggregation. * Temporal composition With temporal composition, multiple consecutive Flow Records with identical Flow Key values are merged into a single Flow Record of longer Flow duration if they arrive within a certain time interval. The main difference to spatial composition is that Flow Records are only merged if they originate from the same Observation Point and if the Flow Key values are identical. For example, multiple Flow Records with a Flow duration of less than one minute can be merged into a single Flow Record with more than ten minutes Flow duration. In addition, the Intermediate Aggregation Process with temporal composition produces aggregated counters while reducing the number of Flow Records on a Collector. Some specific non Flow Key fields, such as the minimumIpTotalLength/ maximumIpTotalLength or minimumTTL/maximumTTL, will contain the minimum and maximum for the new aggregated Flow. The Intermediate Aggregation Process can be combined with the Intermediate Selection Process in order to aggregate only a subset of the original Flow Records, for example Flow Records with small numbers of packets as describied in section 6.2. 5.3.2.4. Intermediate Anonymization Process An Intermediate Anonymization Process covers the following typical functions. o Deleting specified fields The function deletes existing fields in accordance with some instruction rules. Examples include hiding network topology information and private information. In the case of feeding Data Records to end customers, disclosing vulnerabilities is avoided by deleting fields, e.g., "ipNextHopIP{v4|v6}Address", Kobayashi, et al. Expires October 22, 2010 [Page 18] Internet-Draft IPFIX Mediation Framework April 2010 "bgpNextHopIP{v4|v6}Address", "bgp{Next|Prev}AdjacentAsNumber", and "mplsLabelStackSection", described in [RFC5102]. o Anonymizing values of specified fields The function modifies the values of specified fields. Examples include anonymizing customers' private information, such as IP address and port number, in accordance with a privacy protection policy. The Intermediate Anonymization Process may also report anonymized fields and the anonymization method as additional information. 5.3.2.5. Intermediate Correlation Process An Intermediate Correlation Process can be viewed as a special case of the Intermediate Aggregation Process, covering the following typical functions: o Producing new information including metrics, counters, attributes, or packet property parameters by evaluating the correlation among sets of Data Records or among Data Records and other meta data after gathering sets of Data Records within a certain time period. o Adding new fields into a Data Record or creating a new Data Record. A correlation of Data Records can be done in the following ways. o One-to-one correlation between Data Records, with the following examples: * One-way delay, Packet delay variation in [RFC5481] The metrics come from the correlation of the timestamp value on a pair of Packet Reports indicating an identical packet from different Exporters. * Packet inter-arrival time or jitter The metrics come from the correlation of the timestamp value on consecutive Packet Reports from a single Exporter. * Rate-limiting ratio, compression ratio, optimization ratio, etc. The data values come from the correlation of Data Records indicating an identical Flow observed on the incoming/outgoing points of a WAN interface. Kobayashi, et al. Expires October 22, 2010 [Page 19] Internet-Draft IPFIX Mediation Framework April 2010 o Correlation amongst Data Records, with the following examples: * Bidirectional Flow composition The method of exporting and representing a bidirectional flow (Biflow) is described in [RFC5103]. The bidirectional flow composition is a special case of Flow Key aggregation. The Flow Records are merged into one Flow Record as Biflow, if Non- directional Key Fields matches and the Directional Key Field matches their reverse direction counterparts. The direction assignment method to assign the Biflow Source and Destination as additional information may be reported. In the case of an Intermediate Aggregation Process, the direction may be assigned as "arbitrary". * Average/maximum/minimum for packets, bytes, one-way delay, packet loss, etc. The data values come from the correlation of multiple Data Records while the Intermediate Aggregation Process executes. o Correlation between Data Record and other meta data Typical examples are derived packet property parameters described in [RFC5102]. The parameters are retrieved based on the value of the specified field in an input Data Record, compensating for traditional exporting devices or probes that are unable to add packet property parameters. Typical derived packet property parameters are as follows: * "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102], which indicates the egress router of a network domain. It is useful for making a traffic matrix that covers the whole network domain. * BGP Communities attribute This attribute indicates tagging for routes of geographical and topological information and source types (e.g., transit, peer, or customer) as described in [RFC4384]. Therefore, network administrators can monitor the geographically-based or source type-based traffic volume by correlating the attribute. * "mplsVpnRouteDistinguisher" described in [RFC5102] This value indicates the VPN customer's identification, which cannot be extracted from the core router in MPLS networks. Therefore, network administrators can monitor the customer- based traffic volume on even core routers. Kobayashi, et al. Expires October 22, 2010 [Page 20] Internet-Draft IPFIX Mediation Framework April 2010 6. Component Combination An IPFIX Mediator may be able to simultaneously support more than one Intermediate Process. Multiple Intermediate Processes generally are configured in the following ways. o Parallel Intermediate Processes A record stream is processed by multiple Intermediate Processes in parallel to fulfill the requirements of different applications. In this setup, every Intermediate Process receives a copy of the entire record stream as its input. o Serial Intermediate Processes To execute flexible manipulation of a record stream, the Intermediate Processes are connected serially. In that case, an output record stream from one Intermediate Process forms an input record stream for a succeeding Intermediate Process. In addition to the combination of Intermediate Processes, the combination of some components (Exporting Process, Collecting Process, IPFIX File Writer and Reader) can be applied to provide various data reduction techniques. This section shows some combinations along with examples. 6.1. Data-based Collector Selection The combination of one or more Intermediate Selection Processes and Exporting Processes can determine to which Collector input Data Records are exported. Applicable examples include exporting Data Records to a dedicated Collector on the basis of a customer or an organization. For example, an Intermediate Selection Process selects Data Records from record stream duplicated in a Collecting Process on the basis of the peering autonomous system number, and an Exporting Process sends them to a dedicated Collector, as shown in the Figure G. Kobayashi, et al. Expires October 22, 2010 [Page 21] Internet-Draft IPFIX Mediation Framework April 2010 .----------------------. .------------. | Intermediate | | Exporting | | Selection Process 1 | | Process 1 | +--+--- Peering AS #10 ---+-->| +--> Collector 1 | '----------------------' '------------' | .----------------------. .------------. record | | Intermediate | | Exporting | stream | | Selection Process 2 | | Process 2 | -------+--+--- Peering AS #20 ---+-->| +--> Collector 2 | '----------------------' '------------' | .----------------------. .------------. | | Intermediate | | Exporting | | | Selection Process 3 | | Process 3 | +--+--- Peering AS #30 ---+-->| +--> Collector 3 '----------------------' '------------' Figure G: Data-based Collector Selection. 6.2. Flow Selection and Aggregation The combination of one or more Intermediate Selection Processes and Intermediate Aggregation Processes can efficiently reduce the amount of Flow Records. The combination structure is similar to the concept of the Composite Selector described in [RFC5474]. For example, an Intermediate Selection Process selects Flows consisting of a small number of packets and then transmits them to an Intermediate Aggregation Process. Another Intermediate Selection Process selects other Flow Records and then transmits them to an Exporting Process, as shown in Figure H. This results in aggregation on the basis of the distribution of the number of packets per Flow. .------------------. .--------------. .------------. | Intermediate | | Intermediate | | Exporting | | Selection | | Aggregation | | Process | | Process 1 | | Process | | | +-+ packetDeltaCount +->| +->| | | | <= 5 | | | | | record | '------------------' '--------------' | | stream | .------------------. | | -------+ | Intermediate | | | | | Selection | | | | | Process 2 | | | +-+ packetDeltaCount +------------------->| | | > 5 | | | '------------------' '------------' Figure H: Flow Selection and Aggregation Example. Kobayashi, et al. Expires October 22, 2010 [Page 22] Internet-Draft IPFIX Mediation Framework April 2010 6.3. IPFIX File Writer/Reader An IPFIX File Writer [RFC5655] stores Data Records in a file system. When Data Records include problematic Information Elements, an Intermediate Anonymization Process can delete these fields before the IPFIX File Writer handles them, as shown in Figure I. .---------------. .---------------. .-------------. | Collecting | | Intermediate | | IPFIX | IPFIX | Process | | Anonymization | | File | ----->| +->| Process +->| Writer | '---------------' '---------------' '-------------' Figure I: IPFIX Mediation Example with IPFIX File Writer. In contrast, an IPFIX File Reader [RFC5655] retrieves stored Data Records when administrators want to retrieve past Data Records from a given time period. If the data structure of the Data Records from the IPFIX File Reader is different from what administrators want, an Intermediate Anonymization Process and Intermediate Correlation Process can modify the data structure, as shown in Figure J. .-------------. .---------------. .---------------. .-----------. | IPFIX | | Intermediate | | Intermediate | | Exporting | | File | | Anonymization | | Correlation | | Process | | Reader +->| Process +->| Process +->| | '-------------' '---------------' '---------------' '-----------' Figure J: IPFIX Mediation Example with IPFIX File Reader. In the case where distributed IPFIX Mediators enable on-demand export of Data Records which have been previously stored by a File Writer, a collecting infrastructure with huge storage capacity for data retention can be set up. Kobayashi, et al. Expires October 22, 2010 [Page 23] Internet-Draft IPFIX Mediation Framework April 2010 7. Encoding for IPFIX Message Header The IPFIX Message Header [RFC5101] includes Export Time, Sequence Number, and Observation Domain ID fields. This section describes some consideration points for the IPFIX Message header encoding in the context of IPFIX Mediation. Export Time An IPFIX Mediator can set the Export Time in two ways. * Case 1: keeping the field value of incoming Transport Sessions * Case 2: setting the time at which an IPFIX Message leaves the IPFIX Mediator Case 1 can be applied to the case where an IPFIX Mediator operates the IPFIX Message level rather than Data Records as a proxy. In case 2, the IPFIX Mediator needs to handle any delta time stamp fields, such as "flowStartDeltaMicroseconds" and "flowEndDeltaMicroseconds", described in [RFC5102]. Sequence Number In the case where an IPFIX Mediator relays a one-to-one Transport Session, the IPFIX Mediator needs to handle the Sequence Number value when the incoming Transport Session shuts down and starts. Observation Domain ID According to [RFC5101], the Observation Domain ID in the IPFIX Message header from an IPFIX Mediator is locally unique per Exporting Process. However, the Observation Domain ID from an IPFIX Mediator does not represent the largest set of Observation Points in an Original Exporter, even if the Observation Domain ID is kept. Apart from Observation Domain ID in IPFIX Message header, the IPFIX Mediator should have a function to export the observation location information regarding the Original Exporter. The information contains its IP address, Observation Domain ID from Original Exporter, and some information about the Transport Session, for example, the source port number, so that different Exporting Processes on the same Original Exporter might be identified. As far as privacy policy permits, an IPFIX Medaitor reports the information to an IPFIX Collector. In the case where an IPFIX Medaitor does not report the Kobayashi, et al. Expires October 22, 2010 [Page 24] Internet-Draft IPFIX Mediation Framework April 2010 information, for example, an IPFIX Mediator relays an incoming Observation Domain ID or relays an IPFIX Message after replacing each incoming Observation Domain ID with a new value, an IPFIX Mediator should set the appropriate scope fields in Data Records defined in Options Template Records. In the case where an IPFIX Medaitor reports the information, the information can be composed of multiple values of (original Exporter IP address, Observation Observation ID, and source port number) with commonPropertiesID [RFC5473]. An IPFIX Mediator puts into commonPropertiesID value into relevant Data Record, and uses commonPropertiesID value as scope, and should manage commonPropertiesID value, for example, should export a Common Properties Withdrawal message when an incoming Transport Session failure happens. Kobayashi, et al. Expires October 22, 2010 [Page 25] Internet-Draft IPFIX Mediation Framework April 2010 8. Information Model IPFIX Mediation reuses the general information models from [RFC5102] and [RFC5477]. However, several Intermediate Processes would potentially require additional Information Elements as follows: o Original Exporter IP address, Observation Domain ID, and source port number about the Transport Session at Original Exporter, in the case where an IPFIX Mediator reports original observation location information in section 7. The Information Elements contained in Export Session Details Options Template in [RFC5655] may be utilized. o Report on the applied treatment items in IPFIX Mediation as described in section 6.7. in [IPFIX-MD-PS]. o Certificate of an Original Exporter in section 9. Relevant Information Element exporterCertificate in [RFC5655] may be utilized. Kobayashi, et al. Expires October 22, 2010 [Page 26] Internet-Draft IPFIX Mediation Framework April 2010 9. Security Considerations An IPFIX measurement system must prevent the security threats related to IPFIX Mediation that follow as well as the security threats described in the security consideration section in [RFC5101]. o Incoming packets from unknown sources The processing of incoming packets by the IPFIX Mediators must be restricted to packets from authenticated and authorized Original Exporters. One solution is to use a packet filter function which rejects packets from any other sources. o Man-in-the-middle attacks by untrusted IPFIX Mediators The Exporter-Mediator-Collector structure model increases the risk of man-in-the-middle attacks. One solution is usage of Transport Layer Security (TLS) [RFC4346] or Datagram Transport Layer Security (DTLS) [RFC4347] with mutual authentication between Exporter/Collector and Mediator. An IPFIX Collector and Exporter must verify trusted IPFIX Mediators to prevent connection to untrusted IPFIX Mediators. o Configuration of IPFIX Mediation An accidental misconfiguration and unauthorized access to configuration data could lead to the crucial problem of disclosure of confidential traffic data. To manage these risks, an IPFIX Mediator must provide functions for the authentication and authorization of network administrators who access the configuration file. o Unintentional exposure of end user information The probability to collect fine-grained information on one arbitrary end-user increases with the number of Observation Points. An IPFIX Mediator facing such situation may have to apply appropriate Intermediate Processes (e.g. anonymization or aggregation) to the Data Records it produces. o Multiple-tenancy policy on an IPFIX Mediator An IPFIX Mediator handling traffic data from multiple tenants or customers needs to protect from one another traffic data. For example, an IPFIX Mediator needs to identify the customer's identifier, e.g., ingress interface index, network address range, VLAN ID, MAC address, and etc., when feeding customer's traffic data to a customer own dedicated IPFIX Collector. If the IPFIX Kobayashi, et al. Expires October 22, 2010 [Page 27] Internet-Draft IPFIX Mediation Framework April 2010 Mediator can not identify each customer's traffic data, it may need to drop the Data Records. In addition, another technique to keep track of customer's identifier may be required when customer site are movable, e.g., in the case of virtual machine moving to another physical machine. o Confidentiality protection via IPFIX Mediator To ensure security of Data Records in transit, transport of Data Records should be confidentiality and integrity-protected, e.g. by using TLS or DTLS. An IPFIX Mediator is recommended to use TLS or DTLS, when it encodes Data Records received by using TLS or DTLS. However, an IPFIX Collector can not know whether received Data Records are transported as encrypted data between an Original Exporter and an IPFIX Mediator. If this information is required on the IPFIX Collector, an IPFIX Mediator must be able to report about the confidentiality of incoming session to an IPFIX Collector. For example, if an IPFIX Mediator uses TLS or TLS for the outgoing Transport Session only, must be able to report to the IPFIX Collector that the incoming Transport Session has not been encrypted. o Certification for an Original Exporter An IPFIX Collector communicating via an IPFIX Mediator can not verify an Original Exporter directly. If an Original Exporter and an IPFIX Collector are located in different administrative domains, an IPFIX Collector can not trust its Data Records. Therefore, an IPFIX Mediator is recommended to exports the Original Exporter X.509 certificate [RFC3280] in addition to its own certificate and then an IPFIX Collector verifies the identities of both devices. On the other hand, if an IPFIX Mediator has a role as proxy, it does not need to export Original Exporter X.509 certificate. Kobayashi, et al. Expires October 22, 2010 [Page 28] Internet-Draft IPFIX Mediation Framework April 2010 10. IANA Considerations This document has no actions for IANA. Kobayashi, et al. Expires October 22, 2010 [Page 29] Internet-Draft IPFIX Mediation Framework April 2010 11. References 11.1. Normative References [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008. [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", March 2009. 11.2. Informative References [IPFIX-MD-PS] Kobayashi, A., Claise, B., Nishida, H., Sommer, C., Dressler, F., and E. Stephan, "IPFIX Mediation: Problem Statement", draft-ietf-ipfix-mediators-problem-statement-08 (work in progress) , February 2010. [IPFIX-MIB] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", draft-ietf-ipfix-mib-10 (work in progress) , January 2010. [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", draft-ietf-ipfix-psamp-mib-00 (work in progress) , March 2010. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", October 2004. [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", October 2004. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", April 2006. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", April 2006. Kobayashi, et al. Expires October 22, 2010 [Page 30] Internet-Draft IPFIX Mediation Framework April 2010 [RFC4384] Meyer, D., "BGP Communities for Data Collection", February 2006. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", January 2008. [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", January 2008. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", March 2009. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", March 2009. [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", March 2009. [RFC5474] Duffield, N., "A Framework for Packet Selection and Reporting", March 2009. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", March 2009. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", March 2009. [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "An IPFIX-Based File Format", October 2009. Kobayashi, et al. Expires October 22, 2010 [Page 31] Internet-Draft IPFIX Mediation Framework April 2010 Appendix A. Acknowledgements We would like to thank the following persons: Daisuke Matsubara, Tsuyoshi Kondoh, Hiroshi Kurakami, Haruhiko Nishida for contribution during the initial phases of the document; Brian Trammell for contribution regarding the improvement of terminologies section; Nevil Brownlee, Juergen Quittek for the technical reviews and feedback. Kobayashi, et al. Expires October 22, 2010 [Page 32] Internet-Draft IPFIX Mediation Framework April 2010 Authors' Addresses Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3978 Email: akoba@nttv6.net Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Gerhard Muenz Technische Universitaet Muenchen Boltzmannstr. 3 Garching 85748 Germany Phone: +49 89 289-18008 Email: muenz@net.in.tum.de URI: http://www.net.in.tum.de/~muenz Keisuke Ishibashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi 180-8585 Japan Phone: +81-422-59-3978 Email: ishibashi.keisuke@lab.ntt.co.jp Kobayashi, et al. Expires October 22, 2010 [Page 33]