IPFIX Working Group A. Kobayashi, Ed. Internet-Draft NTT PF Lab. Intended status: Informational B. Claise, Ed. Expires: January 14, 2010 Cisco Systems, Inc. July 13, 2009 IPFIX Mediation: Problem Statement draft-ietf-ipfix-mediators-problem-statement-04 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 January 14, 2010. Kobayashi, et al. Expires January 14, 2010 [Page 1] Internet-Draft Mediation Problem Statement July 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kobayashi, et al. Expires January 14, 2010 [Page 2] Internet-Draft Mediation Problem Statement July 2009 Abstract Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. IPFIX Mediation covers two classes of mediation: content mediation for traffic data and transport mediation for transport protocols. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. Kobayashi, et al. Expires January 14, 2010 [Page 3] Internet-Draft Mediation Problem Statement July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 3. IPFIX/PSAMP Documents Overview . . . . . . . . . . . . . . . . 8 3.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 8 3.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 8 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Coping with IP Traffic Growth . . . . . . . . . . . . . . 9 4.2. Coping with Multipurpose Traffic Measurement . . . . . . . 10 4.3. Coping with Heterogeneous Environments . . . . . . . . . . 10 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Mediation Applicability Examples . . . . . . . . . . . . . . . 11 5.1. Adjusting Flow Granularity . . . . . . . . . . . . . . . . 11 5.2. Hierarchical Collecting Infrastructure . . . . . . . . . . 11 5.3. Correlation for Data Records . . . . . . . . . . . . . . . 12 5.4. Time Composition . . . . . . . . . . . . . . . . . . . . . 12 5.5. Spatial Composition . . . . . . . . . . . . . . . . . . . 13 5.6. Data Record Anonymization . . . . . . . . . . . . . . . . 14 5.7. Data Retention . . . . . . . . . . . . . . . . . . . . . . 14 5.8. IPFIX Export from a Branch Office . . . . . . . . . . . . 15 5.9. Distributing Data Records . . . . . . . . . . . . . . . . 16 5.10. Flow-based Sampling and Selection . . . . . . . . . . . . 17 5.11. Interoperability between Legacy Protocols and IPFIX . . . 18 6. IPFIX Mediators Implementation Specific Problems . . . . . . . 19 6.1. Loss of Original Exporter Information . . . . . . . . . . 19 6.2. Loss of Base Time Information . . . . . . . . . . . . . . 19 6.3. Transport Sessions Management . . . . . . . . . . . . . . 20 6.4. Loss of Option Template Information . . . . . . . . . . . 20 6.5. Template ID Management . . . . . . . . . . . . . . . . . . 20 6.6. Consideration for Network Topology . . . . . . . . . . . . 21 6.7. Exporting the Function Item . . . . . . . . . . . . . . . 21 6.8. Consideration for Aggregation . . . . . . . . . . . . . . 22 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Kobayashi, et al. Expires January 14, 2010 [Page 4] Internet-Draft Mediation Problem Statement July 2009 1. Introduction One advantage of Flow-based measurement results from easily offering the traffic monitoring of a huge amount of traffic. While the usage is applied to any networks and to multiple measurement applications, network administrators need to optimize the resource of metering devices and of multiple measurement applications. IP traffic growth and a wide variety of measurement application make the optimization further difficult. To achieve system optimization, an intermediate device can generally be applied to the system platform. The IPFIX requirements defined in [RFC3917] mention examples of intermediate devices, such as IPFIX Proxies or Concentrators, there are no documents defining a generalized concept for such intermediate devices. This document addresses that issue by defining IPFIX Mediation, a generalized intermediate device concept for IPFIX, and examining in detail the motivations behind its application. 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 introduces general problems related to flow-based measurement, section 5 describes some applicability examples where IPFIX Mediations would be beneficial, and, finally, section 6 describes some problems an IPFIX Mediation implementation might face. Kobayashi, et al. Expires January 14, 2010 [Page 5] Internet-Draft Mediation Problem Statement July 2009 2. Terminology and Definitions The terms in this section are in line with those in the IPFIX Protocol specifications [RFC5101] and the PSAMP specification document [RFC5476]. The terms Observation Point, Observation Domain, Flow Key, Flow Record, Data Record, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering Process, Transport Session, Information Element, and Template Withdrawal Message, are defined in the IPFIX protocol specifications [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP Device, and Configured Selection Fraction are defined in the PSAMP specification document [RFC5476]. Furthermore, new terminology to be used in the context of IPFIX Mediation is defined in this section. All the words in these terms are started with a capital letter in this document. In this document, we use the generic term "Data Records" for IPFIX Flow Records, PSAMP Packet Reports, and Data Records defined by Options Templates, unless an explicit distinction is required. 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 records for subsequent export using IPFIX, by applying mediation functions to a stream of records. The following terms are used in this document to describe the architectural entities used by IPFIX Mediation. Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of the records themselves, keeps state across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Kobayashi, et al. Expires January 14, 2010 [Page 6] Internet-Draft Mediation Problem Statement July 2009 IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives records from a Collecting Process but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Specific types of IPFIX Mediators are defined below. IPFIX Proxy An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX Messages or messages in other protocols to one or more Collectors. It can provide transport protocol mediation and re-encoding. IPFIX Concentrator An IPFIX Distributor is an IPFIX Mediator that receives data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Process. IPFIX Distributor An IPFIX Distributor is an IPFIX Mediator that receives data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Process. IPFIX Masquerading Proxy An IPFIX Masquerading Proxy is an IPFIX Mediator that receives data from one or more Exporters and sends them to a single Collector, using one or more Intermediate Processes to screen out parts of records according to configured policies, in order to protect the privacy of the network's end users or sensitive data of the exporting organization. Kobayashi, et al. Expires January 14, 2010 [Page 7] Internet-Draft Mediation Problem Statement July 2009 3. IPFIX/PSAMP Documents Overview 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 out of 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]. [I-D.ietf-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 [I-D.ietf-ipfix-file]. 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, Filtering, and Hashing) standardized by PSAMP are 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]. [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base. Kobayashi, et al. Expires January 14, 2010 [Page 8] Internet-Draft Mediation Problem Statement July 2009 4. Problem Statement Network administrators generally face the problems of measurement system scalability, flow-based measurement flexibility, and export reliability, even if some techniques, such as Sampling, Filtering, Data Records aggregation and export replication, have already been developed. The problems consist of optimizing the resources of the measurement system while fulfilling appropriate conditions: data accuracy, flow granularity, and export reliability. These conditions depend on two factors. o measurement systems capacity: This consists of the bandwidth of the management network, the storage capacity, and the performances of the collecting devices and exporting devices. o applications requirements: Different applications, such as traffic engineering, detecting traffic anomalies, and accounting, etc., impose different Flow Record granularity, and data accuracy. The sustained growth of IP traffic has been overwhelming the measurement system capacities. Furthermore, a large variety of applications (e.g., QoS measurement, traffic engineering, security monitoring) and the deployment of IP traffic measurements in heterogeneous environments have been increasing the demand and complexity of IP traffic measurements. 4.1. Coping with IP Traffic Growth Enterprise or service provider networks already have multiple 10 Gb/s links, their total traffic exceeding 100 Gb/s. In the near future, broadband users' traffic will increase by approximately 40% every year according to [TRAFGRW]. When operators monitor traffic of 500 Gb/s with a packet sampling rate of 1/1000, the amount of exported Flow Records from Exporters could exceed 50 kFlows/s. This value is beyond the ability of a single Collector. To deal with this problem, current data reduction techniques (Sampling and Filtering in [RFC5475], and aggregation of measurement data) have been generally implemented on Exporters. Note that Sampling technique leads to potential loss of small Flows. With both Sampling and aggregation techniques, administrators might no longer be able to detect and investigate subtle traffic changes and anomalies as this requires detailed flow information. With Filtering, only a subset of the Data Records are exported. Considering the potential drawbacks of Sampling, Filtering, and Data Kobayashi, et al. Expires January 14, 2010 [Page 9] Internet-Draft Mediation Problem Statement July 2009 Records aggregation, there is a need for a large-scale collecting infrastructure that does not rely on data reduction techniques. 4.2. Coping with Multipurpose Traffic Measurement Different monitoring applications impose different requirements on the monitoring infrastructure. Some of them require traffic monitoring at a flow level while others need information about individual packets or just flow aggregates. To fulfill these divers requirements, an Exporter would need to perform various complex metering tasks in parallel, which is a problem due to limited resources. Hence, it can be advantageous to run the Exporter with a much simpler setup and to perform appropriate post-processing of the exported Data Records at a later stage. 4.3. Coping with Heterogeneous Environments Network administrators use IPFIX Devices and PSAMP Devices from various vendors, various software versions, various device types (router, switch, or probe) in a single network domain. Even legacy flow export protocols are still deployed in current network. This heterogeneous environment leads to differences in Metering Process capabilities, Exporting Process capacity (export rate, cache memory, etc.), and data format. For example, probes and switches cannot retrieve some derived packet properties in [RFC5102] from a routing table. To deal with this problem, the collecting infrastructure needs to mediate the differences. However, equipping all collecting devices with this absorption function is difficult. 4.4. Summary In optimizing the resources of a measurement system, it is important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. However, this implementation is made difficult by heterogeneous environment of exporting devices. This implies that a new Mediation function is required in typical Exporter-Collector architectures. Based on some applicability examples, the next section shows the limitation of the typical Exporter-Collector architecture model and the IPFIX Mediation benefits. Kobayashi, et al. Expires January 14, 2010 [Page 10] Internet-Draft Mediation Problem Statement July 2009 5. Mediation Applicability Examples 5.1. Adjusting Flow Granularity A set of common properties of simplest Flow type is a fixed 5-tuple of protocol, source and destination IP addresses, and source and destination port numbers. A shorter set of common properties, such as a triple, a double, or a single property, (for example network prefix, peering autonomous system number, or BGP Next-Hop fields), creates more aggregated Flow Records. This is especially useful for measuring traffic exchange in an entire network domain and for easily adjusting the performance of Exporters and Collectors. Implementation analysis: Implementations for this case depend on where Flow granularity is adjusted. More suitable implementations use configurable Metering Processes in Original Exporters. The cache in the Metering Process can specify its own set of common properties (Flow Keys) and extra fields. The Original Exporter thus creates directly aggregated Flow Records. In the case where the Original Exporter contains a Metering Process that creates fixed tuple Flow Records (no ability to change the Flow Keys), or PSAMP Packet Reports, an IPFIX Concentrator can aggregate Data Records based on a new set of Flow Keys. Even in the case where the Original Exporter contains a Metering Process for which the Flow Keys can be configured, an IPFIX Concentrator can further aggregate the Flow Records. 5.2. Hierarchical Collecting Infrastructure The increase of IPFIX Exporters, the increase of the traffic, and the variety of treatments expected to be performed over the Data Records is more and more difficult to handle within a single Collector. Hence to increase the collecting (e.g., the bandwidth capacity) and processing capacity, distributed Collectors must be deployed. As a possible approach, a hierarchical structure is useful for increasing the measurement systems capacity, both in export bandwidth capacity and in collecting capacity. Implementation analysis: To cope with the increase of IPFIX Exporters and traffic, one possible implementation uses IPFIX Concentrators to build a hierarchical collection system. To cope with the variety of treatments, one possible implementation uses IPFIX Distributors to build a distributed collection system. More specific cases are Kobayashi, et al. Expires January 14, 2010 [Page 11] Internet-Draft Mediation Problem Statement July 2009 described in section 5.9. 5.3. Correlation for Data Records The correlation amongst Data Records or between Data Record and meta data provides new metrics or information, including the following. o One-to-one correlation between Data Records * One way delay and packet inter-arrival time etc. One way delay from the correlation of PSAMP Packet Reports from different Exporters along a specific path. * Treatment from the correlation of Data Records with the common properties, observed at incoming/outgoing interfaces. Examples are the rate-limiting ratio, the compression ratio, the optimization ratio, etc. o Correlation amongst Data Records Average/maximum/minimum values from correlating multiple Data Records. Examples are the average/maximum/minimum number of packets of the measured Flows, the average/maximum/minimum one way delay, the average/maximum/minimum number of lost packets, etc. o Correlation between Data Record and other meta data Examples are some BGP attributes associated with Data Record by looking up the routing table. Implementation analysis: One possible implementation for this case uses an IPFIX Concentrator located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Concentrator located between the Original Exporters and IPFIX Collectors. 5.4. Time Composition Time composition is defined as the aggregation of consecutive Data Records with common properties. It leads to the same output as setting a longer active interval timer on Original Exporters with one advantage: the creation of new metrics such as average, maximum and minimum values from Flow Records with a shorter time interval enables administrators to keep track of changes that might have happened during the time interval. Kobayashi, et al. Expires January 14, 2010 [Page 12] Internet-Draft Mediation Problem Statement July 2009 Implementation analysis: One possible implementation for this case uses an IPFIX Concentrator located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Concentrator located between the Original Exporters and IPFIX Collectors. 5.5. Spatial Composition Spatial composition is defined as the aggregation of Data Records in a set of Observation Points within an Observation Domain, across multiple Observation Domains from a single Exporter, or even across multiple Exporters. The spatial composition is divided into four types. o Case 1: Spatial Composition within one Observation Domain For example, in the case where a link aggregation exists, Data Records measured at physical interfaces belonging to the same trunk can be merged. o Case 2: Spatial Composition across Observation Domains, but within a single Exporter For example, in the case where a link aggregation exists, Data Records measured at physical interfaces belonging to a same trunk grouping beyond the line interface module can be merged. o Case 3: Spatial Composition across Exporters Data Records measured within an administrative domain, such as the west area and east area of an ISP network, can be merged. o Case 4: Spatial Composition across administrative domains Data Records measured across administrative domains, such as across different customer networks or different ISP networks, can be merged. Implementation analysis: One possible implementation for the cases 1 and 2 uses an IPFIX Concentrator located between the Metering Processes and Exporting Processes on the Original Exporter. A separate IPFIX Concentrator located between the Original Exporters and IPFIX Collector is a valid solution for the cases 1, 2, 3, and 4. Kobayashi, et al. Expires January 14, 2010 [Page 13] Internet-Draft Mediation Problem Statement July 2009 5.6. Data Record Anonymization IPFIX exports across administrative domains can be used to measure traffic for wide-area traffic engineering or to analyze Internet traffic trends, as described in the spatial composition across administrative domains in the previous subsection. In such a case, administrators need to adhere to privacy protection policies and prevent access to confidential traffic measurements by other people. Typically, anonymization techniques enables the provision of traffic data to other people without violating these policies. As another example, when ISP provides a traffic monitoring service to end customers by their own Exporters, even in case of exporting interface index fields, network administrators take care of anonymizing its fields to avoid disclosing the vulnerability. Generally, anonymization modifies a data set to protect the identity of the people or entities described by the data set from being disclosed. It also attempts to preserve sets of network traffic properties useful for a given analysis while ensuring the data cannot be traced back to the specific networks, hosts, or users generating the traffic. For example, IP address anonymization is particularly important for avoiding the identification of the users, hosts, and routers. Implementation analysis: One possible implementation for this case uses an anonymization function at the Original Exporter. However, this increases the load on the Original Exporter. A more flexible implementation uses a separate IPFIX Masquerading Proxy between the Original Exporter and Collector. 5.7. Data Retention Data retention refers to the storage of traffic data by service providers and commercial organizations. Legislative regulations often require that network operators retain both IP traffic data and call detail records, in wired and wireless networks, generated by end users while using a service provider's services. The traffic data is required for the purpose of the investigation, detection and prosecution of serious crime, if necessary. Data retention services examples are the following: o Fixed telephony (includes fixed voice calls, voicemail, and conference and data calls) Kobayashi, et al. Expires January 14, 2010 [Page 14] Internet-Draft Mediation Problem Statement July 2009 o Mobile telephony (includes mobile voice calls, voicemail, conference and data calls, SMS, and MMS) o Internet telephony (includes every multimedia session associated with IP multimedia services) o Internet e-mail o Internet access Data retention for Internet access services in particular requires a measurement system with reliable export and huge storage as the data must be available for a long period of time, typically at least six months. Implementation analysis: Regarding export reliability requirement, the most suitable implementation uses the SCTP transport protocol between the Original Exporter and Collector. If an unreliable transport protocol such as UDP is used, a legacy exporting device exports Data Records to a nearby IPFIX Proxy through UDP, and then an IPFIX Proxy could reliably export them to the IPFIX Collector through SCTP. If an unreliable transport protocol such as UDP is used and if there is no IPFIX Proxy, the legacy exporting device must duplicate the exports to several Collectors. But, it might result in network congestion. Regarding huge storage requirement, one possible implementation adopts a distributed collection system to increase the storage capacity. Example is a parallel structure in which Collectors are located near Exporters. If some application servers need to communicate with these Collectors, these Collectors would have an Exporting Process as an IPFIX Mediator. 5.8. IPFIX Export from a Branch Office Generally, in large enterprise networks, Data Records from branch offices are gathered in a central office. However, in the long distance branch office case, the bandwidth for transport IPFIX is limited. Therefore, even if multiple Data Record types should be of interest to the Collector (e.g., IPFIX Flow Records in both directions, IPFIX Flow Records before and after WAN optimization techniques, performance metrics associated with the IPFIX Flow Records exported on regular interval, etc.), the export bandwidth limitation is an important factor to pay attention to. Kobayashi, et al. Expires January 14, 2010 [Page 15] Internet-Draft Mediation Problem Statement July 2009 Implementation analysis: One possible implementation for this case uses an IPFIX Concentrator located in a branch office. The IPFIX Concentrator would aggregate and correlate Data Records to cope with the export bandwidth limitation. 5.9. Distributing Data Records Recently, several networks have shifted towards integrated networks, such as the pure IP and MPLS networks, which includes IPv4, IPv6, and VPN traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to be analyzed separately and from different perspectives for different organizations. A single Collector handling all Data Record types might become a bottleneck in the collecting infrastructure. Data Records distributed based on their respective types can be exported to the appropriate Collector, resulting in the load distribution amongst multiple Collectors. Implementation analysis: One possible implementation for this case uses the replications of the IPFIX Message in an Original Exporter for multiple IPFIX Collectors. Each Collector then extracts the Data Record required by its own applications. However, the replication increases the load of the Exporting Process and the waste of the bandwidth between the Exporter and Collector. A more sophisticated implementation uses an IPFIX Distributor located between the Metering Processes and Exporting Processes in an Original Exporter. The IPFIX Distributor determines to which Collector a Data Record is exported depending on certain field values. If a Original Exporter does not have IPFIX Distributor capability, it exports Data Records to a nearby separate IPFIX Distributor, and then the IPFIX Distributor could distribute them to the appropriate IPFIX Collectors. For example, in the case of distributing a specific customer's Data Records, an IPFIX Distributor needs to identify the customer networks. The Route Distinguisher (RD), ingress interface, peering AS number, or BGP Next-Hop, or simply the network prefix may be evaluated to distinguish different customer networks. In the following figure, the IPFIX Distributor reroutes Data Records on the basis of the RD value. This system enables each customer's traffic to be inspected independently. Kobayashi, et al. Expires January 14, 2010 [Page 16] Internet-Draft Mediation Problem Statement July 2009 .---------. |Traffic | .---->|Collector|<==>Customer#A | |#1 | | '---------' RD=100:1 .----------. .-----------. | |IPFIX | |IPFIX |----' .---------. |Exporter#1| |Distributor| RD=100:2 |Traffic | | |------->| |--------->|Collector|<==>Customer#B | | | | |#2 | | | | |----. '---------' '----------' '-----------' | RD=100:3 | .---------. | |Traffic | '---->|Collector|<==>Customer#C |#3 | '---------' Figure A: Distributing Data Records to Collectors using IPFIX Distributor 5.10. Flow-based Sampling and Selection Generally, the distribution of the number of packets per Flow seems to be heavy-tailed. Most types of Flow Records are likely to be small Flows consisting of a small number of packets. The measurement system is overwhelmed with a huge amount of these small Flows. If statistics information of small Flows is exported as merged data by applying a policy or threshold, the load on the Exporter is reduced. Furthermore, if the flow distribution is known, exporting only a subset of the Data Records might be sufficient. Implementation analysis: One possible implementation for this case uses an IPFIX Concentrator located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Concentrator located between the Original Exporters and IPFIX Collectors. A set of IPFIX Mediation functions, such as filtering, selecting and aggregation is used in the IPFIX Concentrator. Kobayashi, et al. Expires January 14, 2010 [Page 17] Internet-Draft Mediation Problem Statement July 2009 5.11. Interoperability between Legacy Protocols and IPFIX During the migration process from a legacy protocol such as NetFlow [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX Exporters are likely to coexist in the same network. Operators need to continue measuring the traffic data from legacy exporting devices, even after introducing IPFIX Collectors. Implementation analysis: One possible implementation for this case uses an IPFIX Proxy that converts a legacy protocol to IPFIX. Kobayashi, et al. Expires January 14, 2010 [Page 18] Internet-Draft Mediation Problem Statement July 2009 6. IPFIX Mediators Implementation Specific Problems 6.1. Loss of Original Exporter Information Both the Exporter IP address indicated by the source IP address of the IPFIX Transport Session and the Observation Domain ID included in the IPFIX Message header are likely to be lost during IPFIX Mediation. In some cases, a IPFIX Masquerading Proxy might drop the information deliberately. In general, however, the Collector must recognize the origin of the measurement information, such as the IP address of the Original Exporter, the Observation Domain ID, or even the Observation Point ID. Note that, if an IPFIX Mediator can not communicate the Original Exporter IP address, then the IPFIX Collector will wrongly deduce that the IP address of the IPFIX Mediator is that of the Original Exporter. In the following figure, a Collector can identify two IP addresses: 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. The Collector, however, needs to somehow recognize both Exporter#1 and Exporter#2, which are the Original Exporters. The IPFIX Mediator must be able to notify the Collector about the IP address of the Original Exporter. .----------. .--------. |IPFIX | |IPFIX | |Exporter#1|--------->|Mediator|---+ | | | | | '----------' '--------' | .---------. IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | ODID:10 ODID:0 |Collector| +----->| | .----------. | '---------' |IPFIX | | |Exporter#2|-----------------------' | | '----------' IP:10.1.1.2 ODID:20 Figure B: Loss of Original Exporter Information. 6.2. Loss of Base Time Information The Export Time field included in the IPFIX Message header represents a reference timestamp for Data Records. Some IPFIX Information Elements, described in [RFC5102], carry delta timestamps that indicate the time difference from the value of the Export Time field. If the Data Records include any delta time fields and the IPFIX Kobayashi, et al. Expires January 14, 2010 [Page 19] Internet-Draft Mediation Problem Statement July 2009 Mediator overwrites the Export Time field when sending IPFIX Messages, the delta time fields become meaningless and, because Collectors cannot recognize this situation, wrong time values are propagated. 6.3. Transport Sessions Management Maintaining relationships between the incoming Transport Sessions and the outgoing ones depends on the Mediator's implementation. If an IPFIX Mediator relays multiple incoming Transport Sessions to a single outgoing Transport Session, and if the IPFIX Mediators shuts down its outgoing Transport Session, Data Records of the incoming Transport Sessions would not be relayed any more. In the case of resetting an incoming session, the behavior of the IPFIX Mediator needs to be specified. 6.4. Loss of Option Template Information In some cases, depending on the implementation of the IPFIX Mediators, the information reported in the Data Records defined by Option Templates could also be lost. If, for example, the Sampling rate is not communicated from the Mediator to the Collector, the Collector would miscalculate the traffic volume. This might lead to crucial problems. Even if an IPFIX Mediator was to simply relay received Data Records defined by Options Templates, the values of its scope fields could become meaningless in the content of a different Transport Sessions. The minimal information to be communicated by an IPFIX Mediator must be specified. 6.5. Template ID Management The Template ID is unique on the basis of the Transport Session and Observation Domain ID. If IPFIX Mediation is not able to manage the relations amongst the Template IDs and the incoming Transport Session information, and if the Template ID is used in the Options Template scope, IPFIX Mediators would, for example, relay wrong values in the scope field and in the Template Withdrawal Message. The Collector would thus not be able to interpret the Template ID in the Template Withdrawal Message and in the Options Template scope. As a consequence, there is a risk that the Collector would then shut down the IPFIX Transport Session. For example, an IPFIX Distributor must maintain the state of the incoming Transport Sessions in order to manage the Template ID on its outgoing Transport Session correctly. Even if the Transport Session from Exporter re-initializes, the IPFIX Distributor must manage the association of Template IDs in specific Transport Session. In the following figure, the IPFIX Distributor exports three Templates (256, Kobayashi, et al. Expires January 14, 2010 [Page 20] Internet-Draft Mediation Problem Statement July 2009 257, and 258) kept the values of Template ID of incoming Transport Sessions. Even when the Exporter#1 is re-initialized and the Template ID value 258 is replaced with 256, the IPFIX Distributor must avoid the duplication of Template ID values without the shutdown of outgoing Transport Session. .----------. OLD: Template ID 258 |IPFIX | NEW: Template ID 256 |Exporter#1|----+ | | | '----------' X .----------. | .-----------. .----------. |IPFIX | '---------->| | | | |Exporter#2|--------------->|IPFIX |-------------->|IPFIX | | |Template ID 257 |Distributor|Template ID 258| Collector| '----------' +---------->| |Template ID 257| | .----------. | '-----------'Template ID 256'----------' |IPFIX | | |Exporter#3|----' | | Template ID 256 '----------' Figure C: Relaying from Multiple Transport Sessions to Single Transport Session. 6.6. Consideration for Network Topology While IPFIX Mediation can be applied anywhere, caution should be taken as how to aggregate the counters, as there is a potential risk of double-counting. For example, if three Exporters export PSAMP Packet Reports related to the same Flow, the one-way delay can be calculated, while summing up the number of packets and bytes does not make sense. Alternatively, if three Exporters export Flow Records entering an administrative domain, then the sum of the packets and bytes is a valid operation. Therefore, the possible function to be applied to Flow Records must take into consideration the measurement topology. The information such as the network topology, or at least the Observation Point and measurement direction, is required for IPFIX Mediation. 6.7. Exporting the Function Item In some case, the IPFIX Collector needs to recognize which specific function(s) the IPFIX Mediation has executed on the Data Records. The IPFIX Collector cannot distinguish between time composition, spatial composition, and Flow Key aggregation, if the IPFIX Mediator does not export the applied function. Some parameters related to the Kobayashi, et al. Expires January 14, 2010 [Page 21] Internet-Draft Mediation Problem Statement July 2009 function also would need to be exported. For example, in case of time composition, the active time of original Flow Records is required to interpret the minimum/maximum counter correctly. In case of spatial composition, spatial area information on which Data Records is aggregated is required. 6.8. Consideration for Aggregation In case of Flow Key aggregation, time composition, and spatial composition, there is a consideration regarding Configured Selection Fraction. There is no obvious rules of how to compute Configured Selection Fraction, an IPFIX Mediator should report Configured Selection Fraction, when aggregating IPFIX Flow Records of sampled packets. For example, special care must be taken in the following: aggregation resulting from the different Configured Selection Fraction, aggregation resulting from different Sampling techniques, such as Systematic Count-Based Sampling and Random n-out-of-N Sampling etc. Kobayashi, et al. Expires January 14, 2010 [Page 22] Internet-Draft Mediation Problem Statement July 2009 7. Summary and Conclusion This document described the problems that network administrators have been facing, the applicability of IPFIX Mediation to these problems, and the problems related to the implementation of IPFIX Mediators. To assist the operations of the Exporters and Collectors, there are various IPFIX Mediations from which the administrators may select. Examples of the applicability of IPFIX Mediation are as follows. o Regarding large-scale measurement system, IPFIX Concentrators or IPFIX Distributors help to achieve traffic analysis with high data accuracy and fine flow granularity even as IP traffic grows. As IPFIX Mediation capabilities, flow sampling, aggregation, and composition are effective. o Regarding data retention, IPFIX Mediators enhance the export reliability, and the storage of the measurement system. o Regarding the distribution of Data Records, IPFIX Distributors help to achieve multipurpose traffic analysis for different organizations, or help to achieve respective traffic analysis based on Data Record types(IPv4, IPv6, MPLS, and VPN). o Regarding IPFIX exporting across domains, IPFIX Masquerading Proxies help administrators to anonymize or filter Data Records, preventing privacy violations. o Regarding interoperability, IPFIX Proxies provide interoperability between legacy protocols and IPFIX, even during the migration period to IPFIX. As a result, the IPFIX Mediation benefits become apparent. However, there are still some open issues with the use of IPFIX Mediators. o Both Observation Point and IPFIX Message header information, such as the Exporter IP address, Observation Domain ID, and Export Time field, might be lost. This data should therefore be communicated between the Original Exporter and Collector via the IPFIX Mediator. o IPFIX Mediators are required to manage Transport Sessions, Template IDs, and Observation Domain IDs. Otherwise, anomalous IPFIX Messages could be created. o Data Records defined by Options Templates, such as those reporting the Sampling rate and Sampling algorithm used, might be lost during IPFIX Mediation. If a Collector is not informed of current Sampling rates, traffic information might become worthless. Kobayashi, et al. Expires January 14, 2010 [Page 23] Internet-Draft Mediation Problem Statement July 2009 These problems stem from the fact that no standards regarding IPFIX Mediation have been set. In particular, the minimum set of information that should be communicated between Original Exporters and Collectors, the management between different IPFIX Transport Sessions, and the internal components of IPFIX Mediators should be standardized. Kobayashi, et al. Expires January 14, 2010 [Page 24] Internet-Draft Mediation Problem Statement July 2009 8. Security Considerations A flow-based measurement system must prevent potential security threats: the disclosure of confidential traffic data, injection of incorrect data, and unauthorized access to traffic data. These security threats of the IPFIX protocol are covered by the security considerations section in [RFC5101] and are still valid for IPFIX Mediators. And a measurement system must also prevent the following security threats related to IPFIX Mediation: o Attacks against IPFIX Mediator IPFIX Mediators can be considered as a prime target for attacks, as an alternative to IPFIX Exporters and Collectors. IPFIX Proxies or Masquerading Proxies need to prevent unauthorized access or denial-of-service (DoS) attacks from untrusted public networks. o Man-in-the-middle attack by untrusted IPFIX Mediator The Collector-Mediator-Exporter structure model would increase the risk of the man-in-the-middle attack. o Configuration on IPFIX Mediation In the case of IPFIX Distributors and IPFIX Masquerading Proxies, an accidental misconfiguration and unauthorized access to configuration data could lead to the crucial problem of disclosure of confidential traffic data. Kobayashi, et al. Expires January 14, 2010 [Page 25] Internet-Draft Mediation Problem Statement July 2009 9. IANA Considerations This document has no actions for IANA. Kobayashi, et al. Expires January 14, 2010 [Page 26] Internet-Draft Mediation Problem Statement July 2009 10. Acknowledgements We would like to thank the following persons: Gerhard Muenz for the thorough detail review and significant contribution regarding the improvement of whole sections; Keisuke Ishibashi for contribution during the initial phases of the document; Brian Trammel for contribution regarding the improvement of terminologies section; Nevil Brownlee, Juergen Schoenwaelder, Motonori Shindo for the technical reviews and feedback. Kobayashi, et al. Expires January 14, 2010 [Page 27] Internet-Draft Mediation Problem Statement July 2009 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., "Packet Sampling (PSAMP) Protocol Specifications", March 2009. 11.2. Informative References [I-D.ietf-ipfix-file] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IPFIX File Format", draft-ietf-ipfix-file-04 (work in progress) , July 2009. [I-D.ietf-ipfix-mib] Dietz, T., Claise, B., and A. Kobayashi, "Definitions of Managed Objects for IP Flow Information Export", draft-ietf-ipfix-mib-06 (work in progress) , March 2009. [I-D.ietf-psamp-mib] Dietz, T. and B. Claise, "Definitions of Managed Objects for Packet Sampling", draft-ietf-psamp-mib-06 (work in progress) , June 2006. [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. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", 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, "IP Flow Information Export (IPFIX) Applicability", March 2009. [RFC5474] Duffield, N., "A Framework for Packet Selection and Reporting", March 2009. Kobayashi, et al. Expires January 14, 2010 [Page 28] Internet-Draft Mediation Problem Statement July 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. [TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact and Implications of the Growth in Residential User-to-User Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September 2006. . Kobayashi, et al. Expires January 14, 2010 [Page 29] Internet-Draft Mediation Problem Statement July 2009 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 Haruhiko Nishida NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3978 Email: nishida.haruhiko@lab.ntt.co.jp Christoph Sommer University of Erlangen-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27993 Email: christoph.sommer@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~sommer/ Kobayashi, et al. Expires January 14, 2010 [Page 30] Internet-Draft Mediation Problem Statement July 2009 Falko Dressler University of Erlangen-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27914 Email: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~dressler/ Stephan Emile France Telecom 2 avenue Pierre Marzin Lannion, F-22307 Fax: +33 2 96 05 18 52 Email: emile.stephan@orange-ftgroup.com Kobayashi, et al. Expires January 14, 2010 [Page 31]