1 / 12

IPFIX Aggregation

IPFIX Aggregation. draft-dressler-ipfix-aggregation-00.txt. Motivation. Reduction of monitoring data Bandwidth savings and performance savings at the collector Speed-up of netflow accounting Reduction of concurrent active streams in a monitor Concentrating multiple IPFIX streams

ericyarbrough
Download Presentation

IPFIX Aggregation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPFIX Aggregation draft-dressler-ipfix-aggregation-00.txt Minneapolis‘ IETF

  2. Motivation • Reduction of monitoring data • Bandwidth savings and performance savings at the collector • Speed-up of netflow accounting • Reduction of concurrent active streams in a monitor • Concentrating multiple IPFIX streams • Definition of concentrator functionality • Transport of information about the aggregation rules • For improved processing of IPFIX data Minneapolis‘ IETF

  3. Application Examples • Accounting and charging • Monitoring and accounting for charging applications requires to save information about each individual end system. Further information about each particular flow is not required. Therefore, aggregation rules are appropriate if the address of the end system is retained. • Intrusion detection • If monitoring is employed for further analysis in terms of intrusion detection, i.e. anomaly detection, rule-based intrusion detection, etc, information about used protocols at transport layer as well as at application layer are mostly required. On the other hand, the analysis will typically work on the basis of sub-networks instead of single hosts because of the amount of data to process. Information about the traffic between individual end systems is required if suspicious transmissions were already detected. Minneapolis‘ IETF

  4. Architecture (I) exported monitoring data (IPFIX Protocol) EP EP AP MP MP MP EP: Exporting Process AP: Aggregation Process MP: Metering Process Minneapolis‘ IETF

  5. Architecture (II) exported monitoring data (IPFIX Protocol) EP AP CP CP exported monitoring data (IPFIX Protocol) EP: Exporting Process AP: Aggregation Process CP: Collector Process Minneapolis‘ IETF

  6. Aggregation Rules (I) • Explicit rules • Triple consisting of • IPFIX type field, e.g. destination IP • Matching pattern, e.g. 10.10.0.0/16 • Granularity modifier, keep field or discard field • Implicit definition of • Minimal set of IPFIX fields required in each incoming record • Template for data export • Special fields • Special treatment of the following fields to keep semantics • # packets, # bytes, # flows: aggregation by summation • Timestamps: aggregation by keeping min and max Minneapolis‘ IETF

  7. Aggregation Rules (II) • Application of aggregation rules leads to shared properties • Example: Match Source Port 80 Match Destination IPs in 10.10.0.0/16, apply mask /24 Aggregate # packets • This rule creates multiple meta flows with the same source port (80) and destination network (one in 10.10.x.0/24) • Can be transmitted in a standard IPFIX record • We suggest a new template type: data template Minneapolis‘ IETF

  8. Example IP Flow Table: • Aggregation Rules: • Dst Port = 80,keep Dst Addr • Dst Addr = 10.0.0.10 Metaflow Table: Minneapolis‘ IETF

  9. Data Export (I) • New data type PrecedingRule: based on unsigned16 • If aggregation is done using a first match algorithm, the order of the rules must be clear at the collector • Implicit transmission of rule set Minneapolis‘ IETF

  10. Data Export (II) • New data type PortRanges: based on unsigned16 • Allows aggregation of flows for multiple transport protocol ports, e.g. 80,443 or 1:1023 • Definition • unsigned16: start port • unsigned16: end port • May appear multiple times to define disjoint port ranges • May be casted down to one unsigned16 Minneapolis‘ IETF

  11. Data Export (III) • New template type Data Template • Allows to transport syntax information AND data • Combination of Data Set and Template Set 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field 1 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field N Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data 1 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data M Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data 1 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data M Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minneapolis‘ IETF

  12. Conclusions • Reduction of monitoring data • Bandwidth savings and performance savings at the collector • Speed-up of netflow accounting • Reduction of concurrent active streams in a monitor • Concentrating multiple IPFIX streams • Definition of concentrator functionality • Transport of information about the aggregation rules • For improved processing of IPFIX data • Thus, the scalability of IPFIX monitoring will be increased by enabling IPFIX aggregation / concentration. Minneapolis‘ IETF

More Related