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

2. 2 Minneapolis‘ IETF 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

3. 3 Minneapolis‘ IETF 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.

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

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

6. 6 Minneapolis‘ IETF 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

7. 7 Minneapolis‘ IETF 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

8. 8 Minneapolis‘ IETF Example Src AddrSrc PortDst AddrDst Port# of Packets 10.0.0.16423510.0.0.108010 10.0.0.16423610.0.0.258020 10.0.0.2688910.0.0.108010 10.0.0.2689010.0.0.101105 IP Flow Table: Src AddrSrc PortDst AddrDst Port# of Packets 10.0.0.108020 10.0.0.258020 10.0.0.1025 Metaflow Table: Aggregation Rules: 1.Dst Port = 80, keep Dst Addr 2.Dst Addr = 10.0.0.10

9. 9 Minneapolis‘ IETF 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

10. 10 Minneapolis‘ IETF 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

11. 11 Minneapolis‘ IETF 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

12. 12 Minneapolis‘ IETF 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.