IPFIX Working Group A. Kobayashi Internet-Draft H. Nishida Intended status: Informational NTT PF Lab. Expires: January 1, 2009 B. Claise Cisco Systems June 30, 2008 IPFIX Mediation: Framework draft-ietf-ipfix-mediators-framework-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 1, 2009. Kobayashi, et al. Expires January 1, 2009 [Page 1] Internet-Draft IPFIX Mediation Framework June 2008 Abstract This document describes a framework for an IPFIX Mediation. An IPFIX Mediation device (IPFIX Mediator) is an intermediate device between IPFIX Exporters and IPFIX Collectors. This framework describes an architecture model, the components of the architecture, and guidelines for the IPFIX protocol specifications for the IPFIX Mediators. In addition, this document describes applicable examples for IPFIX Mediation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 6 3.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 6 3.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 7 3.3.1. Metering Process . . . . . . . . . . . . . . . . . . . 8 3.3.2. IPFIX File Writer/Reader . . . . . . . . . . . . . . . 10 4. Guideline for IPFIX Protocol for IPFIX Mediators . . . . . . . 12 4.1. Handling Delta Time Field . . . . . . . . . . . . . . . . 12 4.2. Observation Domain ID Management . . . . . . . . . . . . . 12 4.3. Template ID Management . . . . . . . . . . . . . . . . . . 13 4.4. Transport Session Management . . . . . . . . . . . . . . . 13 4.5. Option Template Management . . . . . . . . . . . . . . . . 14 4.6. Reporting Original Exporter Information . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Solution Scenarios with IPFIX Mediators . . . . . . . 19 A.1. Flexible Aggregation . . . . . . . . . . . . . . . . . . . 19 A.2. Distributed Aggregation . . . . . . . . . . . . . . . . . 19 A.3. Duplication of Flow Records . . . . . . . . . . . . . . . 20 A.4. Distribution of Flow Records . . . . . . . . . . . . . . . 21 A.5. Extraction of Suspicious Flow . . . . . . . . . . . . . . 22 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Kobayashi, et al. Expires January 1, 2009 [Page 2] Internet-Draft IPFIX Mediation Framework June 2008 1. Introduction This document describes the framework for IPFIX Mediators to reroute, filter, aggregate, correlate, or modify Flow Records/Packet Reports, and to export the output to Collectors. The motivation for the IPFIX Mediation standard comes from the need for flow-based measurement system support for large-scale networks, interdomain networks, and coexistence with traditional Exporters as described in [I-D.ietf-ipfix-mediators-ps] in detail. The standard specification requires a definition of IPFIX Mediator, and a consistency in the IPFIX protocol between Exporters and Mediators, and between Collectors and Mediators. The motivation for the IPFIX Mediation functions comes from the applications that enable a scalable and flexible measurement system. This document is organized as follows. Section 2 describes terminologies related to IPFIX Mediation. Section 3 describes the architecture model and details the components of this architecture. Section 4 describes the consideration points and guideline for the IPFIX protocol. Kobayashi, et al. Expires January 1, 2009 [Page 3] Internet-Draft IPFIX Mediation Framework June 2008 2. Terminology The basic terms related to IPFIX protocol, such as Metering Process, Exporting Process, Collecting Process and Data Record, are aligned with the definitions in [RFC5101]. The terms related to PSAMP protocol specifications like Packet Reports and Packet Interpretation, are aligned with the definitions in [I-D.ietf-psamp-protocol]. The terms related to IPFIX Device, such as Exporter, Collector, IPFIX Proxy and IPFIX Concentrator, are aligned with the definitions in [RFC3917]. The terms related to IPFIX Mediation Device, such as IPFIX Masquerading Proxy and IPFIX Distributor are aligned with the definitions in [I-D.ietf-ipfix-mediators-ps]. Other than the above terms are defined here. All these terms are capitalized in this document. Mediator Metering Process A Metering Process in IPFIX Mediators can be considered as a partial Metering Process separated from that in Original Exporters as described in [RFC3917]. The Mediator Metering Process generates new sets of Data Records/ Packet Reports from input Data Records/Packet Reports. The functionality of the Mediator Metering Process includes selecting, aggregating, and modifying Flow Records/Packet Reports, but is not limited to: selection, aggregation, modification. Flow-Based Collector Selection Function This function filters input Flow Records/Packet Reports based on the value of the specified Information Element and then selects Collectors for the filtered (classified) Flow Records/Packet Reports. Mediator Observation Domain ID An IPFIX Mediator does not host the Observation Points and Observation Domain. The Observation Domain ID in the IPFIX header sent by IPFIX Mediator also indicates the largest set of Observation Points from the viewpoint of a Collector. However this value does not indicate the physical entity of an Original Exporter. Transport Session Information 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 Kobayashi, et al. Expires January 1, 2009 [Page 4] Internet-Draft IPFIX Mediation Framework June 2008 address, Exporter transport port, Collector transport port, transport protocol}. Kobayashi, et al. Expires January 1, 2009 [Page 5] Internet-Draft IPFIX Mediation Framework June 2008 3. Architecture Model Here is the basic IPFIX Mediator architecture model. The IPFIX Mediator is formally defined to consist of one or more Collecting Processes, zero or more intermediate processes, and one or more Exporting Processes. Basically, IPFIX Mediator devices: IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor and IPFIX Concentrator are composed of these components. The following subsection describes details of each component and examples applicable to the component. .-------------------------------------------------. | .----------. .----------.| | .----------.| .------------. .----------.|| |.----------.|| .------------.| .----------.||| IPFIX ||Collecting||| |Intermediate|| |Exporting ||||IPFIX ----->||Processes ||'-->|Processes ||-->|Processes ||'|-----> || |' |(optional) |' | |' | |'----------' '------------' '----------' | '-------------------------------------------------' Figure A: Basic IPFIX Mediator Model. 3.1. Collecting Process The Collecting Process receives Data Records/Packet Reports from Original Exporters as described in [RFC5101]. The process forwards the received Data Records/Packet Reports with IPFIX header information and Transport Session Information to multiple components: Intermediate Processes and Exporting Processes. In other words, the process may duplicate received Data Records/Packet Reports and forward them to multiple components in sequence or in parallel. 3.2. Exporting Process The Exporting Process forwards Data Records/Packet Reports to one or multiple Collectors. The process manages the reporting Template and makes an IPFIX Message as described in [RFC5101]. In addition, the process carries out a Flow-based Collector Selection Function as optional. Applicable examples include exporting Flow Records/Packet Reports to a dedicated Collector on the basis of customers/peering organizations. The Exporting Process classifies Flow Records/Packet Reports on the basis of a peering AS number, as shown in the following figure. The set of classified Flow Records/Packet Reports is exported to a dedicated Collector on the basis of the peering AS number. Kobayashi, et al. Expires January 1, 2009 [Page 6] Internet-Draft IPFIX Mediation Framework June 2008 .----------------------------. | Exporting Process | | .----------------------. | | | Flow-Based Collector | | | | Selection Function | | | | | | | | Peering AS #10 | | | | +-------------------+-+---> Collector #1 | | | Peering AS #20 | | Flow --+---+--+-------------------+-+---> Collector #2 Records | | | Peering AS #30 | | | | +-------------------+-+---> Collector #3 | '----------------------' | '----------------------------' Figure B: Exporting classified Flow Records to dedicated Collector. 3.3. Intermediate Process The most generic intermediate process configuration is composed of a Metering Process, and/or an IPFIX File Reader/Writer described in [I-D.ietf-ipfix-file]. Metering Process as a typical component of IPFIX Concentrator and Remote Observation is described in [RFC5101]. A possible configuration model of these components is as follows. .----------. .------------------------------------. .---------. | | | Intermediate Process | | | | | | .-------------------------------. | | | |Collecting| | | Metering Process | | |Exporting| |Process | | |.-------. .-------. .-------.| | |Process | | |---->|sub |->|sub |->|sub |--->| | | | | ||process| |process| |process|| | | | | | |.->|#1 | |#2 | |#3 || | | | | | || |'-------' '-------' '-------'| | | | | | || '----|----------|----------|----' | | | | | || | | | | | | | | || .----\/---------\/---------\/---. | | | | | |'-| IPFIX File Reader/Writer |<--| | | |--->| |-->| | | | | '-------------------------------' | | | '----------' '------------------------------------' '---------' Figure C: Intermediate Process Component Model. Kobayashi, et al. Expires January 1, 2009 [Page 7] Internet-Draft IPFIX Mediation Framework June 2008 3.3.1. Metering Process The Metering Process generates new sets of Data Records/Packet Reports from input Data Records/Packet Reports with IPFIX header information: "Export Time" and "Observation Domain ID". The process hosts several subprocesses: the Selecting Process, Aggregating Process, and Modifying Process. These subprocesses can connect to each other in any sequence. The output of each subprocess can be inputs of other subprocesses. Subprocesses are as follows. Selecting Process A Selecting Process in IPFIX Mediators is analogous to that in PSAMP Devices described in [I-D.ietf-psamp-framework]. The Selecting Process selects input Data Records/Packet Reports matching under some filtering policy and then forwards them to the next process. Aggregating Process An Aggregating Process creates aggregated Flow Records from input Flow Records/Packet Reports in accordance with aggregation rules that are described in [I-D.dressler-ipfix-aggregation]. Modifying Process A Modifying Process comprises two different types of modification, as follows. * Adding/deleting specified Information Elements: changing data structure of Template. * Modifying the value of a specified Information Element. Each subprocess is shown in detail. 3.3.1.1. Selecting Process The Selecting Process uses several selection techniques, such as property match filtering and Flow selection techniques, which are described in [I-D.ietf-psamp-framework] and [I-D.peluso-flowselection], respectively. In property match filtering, if the value of specified Information Element equal a pre- configured value, the function selects Data Records//Packet Reports to forward them to the next process. Kobayashi, et al. Expires January 1, 2009 [Page 8] Internet-Draft IPFIX Mediation Framework June 2008 3.3.1.2. Aggregating Process The Aggregating Process gathers Flow Records/Packet Reports within a given time interval and then distinguishes Flow Records/Packet Reports that have common properties. If values of a given key field are the same, that means those Flow Records/Packet Reports have common properties. This process merges Flow Records/Packet Reports that have a common property and creates an aggregated Flow Record. For example, aggregated Flow Records have an aggregation counter that indicates the number of packets. These functions are defined in accordance with the IPFIX aggregation rules in [I-D.dressler-ipfix-aggregation]. In addition, the process can create statistical data and subsidiary information related to the aggregated Flow Records. Examples include the number of input Flow Records/Packet Reports, the given interval time, and a set of Flow Key Information Elements. 3.3.1.3. Modifying Process The Modifying Process modifies input Data Records/Packet Reports. The process can add new Information Elements, delete existing Information Elements, or modify the value of specified Information Elements. If the process modifies the data structure of an original Template, it also needs to modify the value of the "flowKeyIndicator". Adding specified Information Elements This function obtains the value of a specified Information Element, and then adds it into Data Records/Packet Reports. There are several methods to obtain the value: retrieving the value from some database or calculating the value based on the value of other Information Elements and received traffic data. Applicable examples include adding derived packet property parameters instead of Original Exporters. Doing that can compensate for traditional Exporters or probes unable to add packet property parameters. Therefore, Collectors do not need to recognize the difference between implementations of routers from several vendors or Exporter types, such as router, switch or probe. Typical derived packet property parameters include: * "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] indicates the egress router of some network domain. That is useful for making a traffic matrix that covers the whole network domain. Kobayashi, et al. Expires January 1, 2009 [Page 9] Internet-Draft IPFIX Mediation Framework June 2008 * BGP Community value indicates the same group of destination or source IP addresses. * "mplsVpnRouteDistinguisher" described in [RFC5102], which cannot be extracted from the core router in MPLS networks, indicates the VPN customer's identification. Network operators can monitor the traffic behavior of each customer by adding "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports. Deleting specified Information Elements This function deletes existing Information Elements according to instruction rules, which indicate whether an Information Element should be removed. Applicable examples include hiding network topology information and private information. In the case of interdomain IPFIX exporting, the function can avoid making a vulnerability by deleting unnecessary Information Elements. Examples of network topology information include: "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4|v6}Address", and "bgp{Next|Prev}AdjacentAsNumber" described in [RFC5102]. In addition, MPLS-related Information Elements, such as "mplsLabelStackSection", are useless for customers in the case of feeding Flow Records/Packet Reports to VPN customers. Modifying the value of specified Information Elements This function modifies the value of specified Information Elements. Applicable examples include anonymizing customers' private information, such as IP address and port number, according to a privacy protection policy. IPFIX Mediators may anonymize Data Records/Packet Reports instead of the Exporting Processes of Original Exporter as described in [RFC3917]. The function also reports anonymization methods and the part of anonymized data as subsidiary information. 3.3.2. IPFIX File Writer/Reader The process of IPFIX File Writer stores input Data Records/Packet Reports from any process in a storage system. If received Data Records/Packet Reports include uninteresting Information Elements, the Modifying Process can delete these elements before IPFIX File Writer handles them. Therefore, IPFIX File Writers can accept input from any process. In either case, input needs to include the IPFIX header information and the Transport Session Information along with Kobayashi, et al. Expires January 1, 2009 [Page 10] Internet-Draft IPFIX Mediation Framework June 2008 Flow Records/Packet Reports. On the other hand, the process of IPFIX File Reader retrieves stored Data Records/Packet Reports when operators want to retrieve past Data Records/Packet Reports on the basis of a given time period. If a data structure of output Data Records/Packet Reports from IPFIX File Reader is different from that which operators want, the Modifying Process can modify the data structure. Therefore, output of IPFIX File Readers can be input to any process except for the Collecting Process. The IPFIX File Writer/Reader are described in [I-D.ietf-ipfix-file] in detail. Kobayashi, et al. Expires January 1, 2009 [Page 11] Internet-Draft IPFIX Mediation Framework June 2008 4. Guideline for IPFIX Protocol for IPFIX Mediators This section describes consideration points and guideline for IPFIX Protocol for IPFIX Mediators. 4.1. Handling Delta Time Field IPFIX Mediators need to compensate for any delta time stamp fields, such as "flowStartDeltaMicroseconds" and "flowEndDeltaMicroseconds", if Exporting Processes write the "Export Time" field of an IPFIX Message when an IPFIX Message leaves. These Information Elements indicate the difference from "Export Time". IPFIX Mediators can carry that out in several ways: o reusing the "Export Time" of received IPFIX Messages from the Original Exporter. o rewriting the value of delta time fields based on the new value of "Export Time". o deleting the delta time fields after adding the absolute and fixed time fields. In either case, IPFIX Mediators need to guarantee the value of time stamp fields. 4.2. Observation Domain ID Management IPFIX Mediators need to guarantee a unique Observation Domain ID for an Exporting Process to comply with the IPFIX Protocol. IPFIX Mediators can carry that out in several ways: o relaying the Observation Domain ID in a received IPFIX Message. o assigning a new value to the Observation Domain ID and replacing it with the new one. o overwriting zero value of Observation Domain ID under the condition that one Transport Session has one Observation Domain ID. The method for handling Observation Domain ID also depends on the role of devices and relaying patterns for IPFIX transport sessions: o from one receiving session to one exporting session. o from one receiving session to multiple exporting sessions. Kobayashi, et al. Expires January 1, 2009 [Page 12] Internet-Draft IPFIX Mediation Framework June 2008 o from multiple receiving sessions to one exporting session. o from multiple receiving sessions to multiple exporting sessions. In the case of relaying from one session to one or more sessions, IPFIX Mediators can directly relay IPFIX Messages as an IPFIX Proxy without replacing the Observation Domain ID. In the case of other patterns, IPFIX Mediators need to replace the Observation Domain ID with the new value and manage the new and original Observation Domain ID along with the received Transport Session Information. This linkage information is available for overwriting the scope field of the Option Template. Note: To comply with the description in [RFC5101], if IPFIX Mediators aggregate the received Flow Records, the new value of an Observation Domain ID needs to be zero. However, that seems to be selectable, if IPFIX Mediator can assign the value of Observation Domain ID for a large set of Observation Points. 4.3. Template ID Management IPFIX Mediators need to guarantee the unique Template ID for an Observation Domain ID to comply with the IPFIX Protocol. IPFIX Mediators can carry that out in several ways: o relaying the Template ID in a received IPFIX Message under the condition that the Observation Domain ID is relayed. o using the fixed value under the condition that the fixed Template is applied to any input Data Records/Packet Reports/Packet Interpretation. o assigning the new value to the Template ID and replacing it with the new value. In either case, IPFIX Mediators need to manage the new value and original value of Template ID along with the received Transport Session Information and Observation Domain ID. Note that in case sending an Option Template and a Template Withdraw Message, the values of the scope field and the Template ID field are correct. 4.4. Transport Session Management IPFIX Mediators need to manage the collecting sessions and the exporting sessions. Even if one session is reset, IPFIX Mediators need to maintain the status of the other session. However, Templates for resetting the collecting session need to be withdrawn for the Kobayashi, et al. Expires January 1, 2009 [Page 13] Internet-Draft IPFIX Mediation Framework June 2008 Exporting Session under the condition that IPFIX Mediators assign the new value to the Template ID. 4.5. Option Template Management IPFIX Mediators need to guarantee the scope field to be applicable. Generally, Options Data Records include subsidiary data for Flow Records/Packet Reports, and statistics data for IPFIX protocol session. For subsidiary data, such as "samplingSize" and "systemInitTimeMilliseconds", IPFIX Mediators can carry that out in several ways: o merging the data into Flow Records/Packet Reports without exporting Options Data Records. o modifying the value in the scope fields to match the Observation Domain ID and Template ID, and exporting it. In either case, IPFIX Mediators need to report the subsidiary data to the next Collector. For statistics data, IPFIX Mediators can also carry that out in several ways: o adding the counter of the received data and that of IPFIX Mediators, and exporting it. o relaying the received data without changing the counters. o by not exporting the received data. The method also depends on the role of devices: IPFIX Proxy or other devices. 4.6. Reporting Original Exporter Information Whether to report Original Exporter information, such as Exporter IP address, or not depends on the role of the device. IPFIX Mediators may determine that based on the pre-configured rule. The reporting methods include: o merging Original Exporter Information into Flow Records/Packet Reports, and exporting them. o creating Options Data Records regarding the Original Exporter Information and exporting them. Kobayashi, et al. Expires January 1, 2009 [Page 14] Internet-Draft IPFIX Mediation Framework June 2008 5. Security Considerations IPFIX Mediators use the IPFIX protocol. Security considerations about Flow Records are described in [RFC5101]. Kobayashi, et al. Expires January 1, 2009 [Page 15] Internet-Draft IPFIX Mediation Framework June 2008 6. IANA Considerations This document has no actions for IANA. Kobayashi, et al. Expires January 1, 2009 [Page 16] Internet-Draft IPFIX Mediation Framework June 2008 7. References 7.1. Normative References [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export(IPFIX)", October 2004. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", January 2008. 7.2. Informative References [I-D.dressler-ipfix-aggregation] Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, "IPFIX Aggregation", draft-dressler-ipfix-aggregation-04.txt (work in progress) , November 2007. [I-D.ietf-ipfix-file] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "An IPFIX-Based File Format", draft-ietf-ipfix-file-01.txt(work in progress) , February 2008. [I-D.ietf-ipfix-mediators-ps] Kobayashi, A., Nishida, H., Sommer, C., Dressler, F., Stephan, E., and B. Claise, "IPFIX Mediation: Problem Statement", draft-ietf-ipfix-mediation-problem-statement-00.txt(work in progress) , May 2008. [I-D.ietf-psamp-framework] Duffield, N., "A Framework for Packet Selection and Reporting", draft-ietf-psamp-framework-12.txt , June 2007. [I-D.ietf-psamp-protocol] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", draft-ietf-psamp-protocol-09.txt , December 2007. [I-D.peluso-flowselection] Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow Kobayashi, et al. Expires January 1, 2009 [Page 17] Internet-Draft IPFIX Mediation Framework June 2008 selection Techniques", draft-peluso-flowselection-tech-01.txt(work in progress) , November 2007. Kobayashi, et al. Expires January 1, 2009 [Page 18] Internet-Draft IPFIX Mediation Framework June 2008 Appendix A. Solution Scenarios with IPFIX Mediators A.1. Flexible Aggregation An IPFIX Mediator as an IPFIX Concentrator can aggregate Flow Records and reduce the number of Flow Records received by a IPFIX Collector. The following figure indicates a cascade connection of IPFIX Mediators. If an IPFIX Collector measures a traffic matrix to obtain traffic demand, it needs Flow Records of the whole network domain, but does not need detailed Flow Records. The first level IPFIX Mediators aggregate the received Flow Records based on prefix mask aggregation. Next, the second level IPFIX Mediators aggregate them further based on the BGP next-hop address or the IPFIX router address. After this, the IPFIX Collector receives high-level aggregated Flow Records. This method enables step-by-step aggregation of Flow Records without overloading a single node. .--------. .--------. |IPFIX | |IPFIX | |router#1|---->|Mediator|---. | | |*1 | | '--------' '--------' | .--------. .---------. '--->|IPFIX | |IPFIX | .--------. .--------. .--->|Mediator|---->|Collector| |IPFIX | |IPFIX | | |*2 | | | |router#2|---->|Mediator|---' '--------' '---------' | | |*1 | '--------' '--------' Figure A.A : Flexible Aggregation with Cascading IPFIX Mediators. A.2. Distributed Aggregation In case of global ISPs, the distances between PoPs become longer, and the maintenance of a dedicated management network is very expensive. Therefore, the huge number of Flow Records has burdened management networks. An IPFIX Mediator located in each PoP can minimize the number of Flow Records exported to the Collector by aggregating or filtering. If the Collector needs detailed information, it can retrieve Flow Records from IPFIX Mediators that store original Flow Records. Kobayashi, et al. Expires January 1, 2009 [Page 19] Internet-Draft IPFIX Mediation Framework June 2008 POP#Asia .--------. .--------. | .---------. .--------. | |----->|IPFIX | |IPFIX | |------->|Mediator |----. |router |---'----->|#1 | | |#1 |-' '---------' | '--------' | | POP#North America | .--------. | .--------. | .---------. | .---------. .--------. | |----->|IPFIX | '---->|IPFIX | |IPFIX | |------->|Mediator |--------->|Collector| |router |---'----->|#2 | .---->| | |#4 |-' '---------' | '---------' '--------' | | POP#Europe | .--------. | .--------. | .---------. | .--------. | |----->|IPFIX | | |IPFIX | |------->|Mediator |----' |router |---'----->|#3 | |#7 |-' '---------' '--------' Figure A.B: Traffic Collection Architecture in Global Networks. A.3. Duplication of Flow Records An IPFIX Mediator duplicates Flow Records to achieve redundant storage or utilizes them for several purposes. Kobayashi, et al. Expires January 1, 2009 [Page 20] Internet-Draft IPFIX Mediation Framework June 2008 Several departments in an ISP want to use the same traffic data for each intended purpose. The network design department measures the traffic matrix to obtain traffic demand. The customer service division uses traffic information for performing accounting services for each customer while network operators use traffic data for trouble shooting analysis. That situation is shown in the following figure. Measurement traffic matrix. .--------. .---------. |IPFIX | |IPFIX | |router#1|----. .---->|Collector| | | | | |#1 | '--------' | | '---------' | | Using Accounting .--------. | .---------. | .---------. |IPFIX | '---->|IPFIX |----' |IPFIX | |router#2|--------->|Mediator |--------->|Collector| | | .---->| |----. |#2 | '--------' | '---------' | '---------' | | Using Trouble shooting. .--------. | | .---------. |IPFIX | | | |IPFIX | |router#3|----' '---->|Collector| | | |#3 | '--------' '---------' Figure A.C: Duplication of Flow Records. A.4. Distribution of Flow Records An IPFIX Mediator distribute Flow Records based on the value of specified Information Elements. This function enables load balancing of Collector and sorting Flow Records without extra IPFIX Collector functions. In case of using accounting, IPFIX Mediator can distribute Flow Records to the dedicated IPFIX Collector of each customer. Kobayashi, et al. Expires January 1, 2009 [Page 21] Internet-Draft IPFIX Mediation Framework June 2008 When network operators disclose traffic information to each customer, security or the privacy policy should be considered. In that case, the IPFIX Mediator hides private information about each customer. In addition, Mediator distributes traffic data based on RD (Route Distinguisher), ingress IF, peering AS number, or BGP next hop, which identify the customer. In the following figure, the IPFIX Mediator distributes Flow Records based on RD. The system securely allows each customer to access only their own records. .--------. .---------. |IPFIX | |IPFIX | |router#1|----. .---->|Collector|<===> Customer#A | | | | |#1 | '--------' | | '---------' | RD=100:1 | .---------. | .--------. '---->|IPFIX |----' .---------. |IPFIX | |Mediator | RD=100:2 |IPFIX | |router#2|--------->| |--------->|Collector|<===> Customer#B | | | | |#2 | '--------' .---->| |----. '---------' | '---------' | | RD=100:3 .--------. | | .---------. |IPFIX | | | |IPFIX | |router#3|----' '---->|Collector|<===> Customer#C | | |#3 | '--------' '---------' Figure A.E: Distribution of Flow Records. A.5. Extraction of Suspicious Flow An IPFIX Mediator performs filtering based on the value of specified Information Elements. Filter conditions are set depending on suspicious Flows as follows. The IPFIX Collector receives the specified suspicious flow and detects an anomalous Flow by simply monitoring the traffic volume of each suspicious Flow. o TCP Flow Records whose "tcpControlBits" value is set to "null" o TCP Flow Records whose "tcpControlBits" value is set to the SYN bit only and the packet counter is only 1. o ICMP Flow Records whose length is too long. Kobayashi, et al. Expires January 1, 2009 [Page 22] Internet-Draft IPFIX Mediation Framework June 2008 Appendix B. Acknowledgements The gratefully acknowledgements for the contributions: Keisuke Ishibashi, Tsuyoshi Kondoh, Daisuke Matsubara. Kobayashi, et al. Expires January 1, 2009 [Page 23] Internet-Draft IPFIX Mediation Framework June 2008 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 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 Benoit Claise Cisco Systems De Kleetlaan 6a b1 Diegem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Kobayashi, et al. Expires January 1, 2009 [Page 24] Internet-Draft IPFIX Mediation Framework June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kobayashi, et al. Expires January 1, 2009 [Page 25]