Internet Draft Tanja Zseby Document: <draft-ietf-ipfix-as-05.txt> Elisa Boschi Expires: November 2005 Fraunhofer FOKUS Nevil Brownlee CAIDA Benoit Claise Cisco Systems May 2005 IPFIX Applicability draft-ietf-ipfix-as-05.txt 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. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Zseby, Boschi, Brownlee, Claise [Page 1]
IPFIX Applicability May 2005 This document describes what type of applications can use the IP Flow Information Export (IPFIX) protocol and how they can use the information provided by IPFIX. It also shows how the IPFIX framework relates to other architectures and frameworks. Zseby, Boschi, Brownlee, Claise [Page 2]
IPFIX Applicability May 2005 Table of Contents 1. Introduction.............................................3 2. Applications of IPFIX....................................4 2.1 Accounting...............................................4 2.1.1 Example.................................................5 2.2 Security Analysis and Intrusion Detection with IPFIX.....6 2.3 Network Planning.........................................8 2.4 Peering Agreements.......................................8 2.5 Traffic Engineering......................................8 2.6 Trend Analysis...........................................9 2.7 SLA Validation and QoS Measurements......................9 2.7.1 Measurement of Round-trip-time (RTT)...................10 2.7.2 Measurement of One-way-delay (OWD).....................10 2.7.3 Measurement of One-way-loss (OWL)......................11 2.7.4 Measurement of IP delay variation (IPDV)...............11 2.7.5 Transport of IPPM Metrics..............................11 2.7.6 Other Applications.....................................12 3. Relation of IPFIX to other frameworks and protocols.....12 3.1 IPFIX and AAA...........................................12 3.1.1 Connecting via an AAA Client...........................13 3.1.2 Connecting via an Application Specific Module (ASM)....14 3.2 IPFIX and RTFM..........................................15 3.2.1 Architecture...........................................15 3.2.2 Flow Definition........................................15 3.2.3 Configuration and Management...........................16 3.2.4 Data Collection........................................16 3.2.5 Data Model Details.....................................16 3.2.6 Application/Transport Protocol.........................17 3.2.7 RTFM Summary...........................................17 3.3 IPFIX and IPPM..........................................17 3.4 IPFIX and PSAMP.........................................17 3.5 IPFIX and RMON..........................................18 3.6 IPFIX and IDMEF.........................................18 4. Limitations.............................................19 4.1 IPFIX and IPv6..........................................20 5. Security Considerations.................................20 6. Normative References....................................21 7. Informative References..................................21 8. Acknowledgements........................................23 9. Author's Addresses......................................23 10. Full Copyright Statement................................24 11. Intellectual Property Statement.........................24 12. Copyright Statement.....................................25 13. Disclaimer..............................................25 1. Introduction Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability May 2005 The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. It is intended to provide this information as input to various applications. IPFIX is a general data transport protocol, easily extensible to suit the needs of different applications. This document describes what applications can use the IPFIX protocol and how they can use it. Furthermore, the relationship of IPFIX to other frameworks and architectures is described. 2. Applications of IPFIX IPFIX data enables several critical applications. This section describes how different applications can use the IPFIX protocol. 2.1 Accounting Usage-based accounting is one of the major applications for which the IPFIX protocol has been developed. IPFIX data records provide fine-grained measurement results for highly flexible and detailed resource usage accounting. Internet Service Providers (ISPs) can use this information to migrate from single fee, flat-rate billing to more flexible charging mechanisms based on time of day, bandwidth usage, application usage, quality of service, etc. Enterprise customers can use this information for departmental chargeback or cost allocation for resource usage. In order to realize usage-based accounting with IPFIX the flow definition has to be chosen in accordance with the tariff model. IPFIX allows a very flexible flow definition that can be adapted to the need of different tariff models. Arbitrary flow-based accounting models can be realized without any extensions to the IPFIX protocol. A tariff can, for instance, be based on individual end-to-end flows, in which case accounting can be realized with a flow definition determined by the quintuple consisting of source address, destination address, protocol and port numbers. Another example is a class-dependent tariff (e.g. in a DiffServ network). In this case, flows could be distinguished just by the DiffServ codepoint (DSCP) and source IP address. The essential elements needed for accounting are the number of transferred packets and bytes per flow which are contained in IPFIX flow records. For accounting purposes, it would be advantageous to have the ability to use IPFIX flow records as accounting input in an AAA Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability May 2005 infrastructure. AAA servers then could provide the mapping between user and flow information. 2.1.1 Example Let's suppose someone has a Service Level Agreement (SLA) in a DiffServ network requiring accounting based on traffic volume. The information to export in this case is: - The IPv4 source IP address: sourceIPv4Address in [IPFIX- INFO] with a length of 4 octets - The IPv4 destination IP address: destinationIPv4Address in [IPFIX-INFO] with a length of 4 octets - Type of Service: classOfServiceIPv4 in [IPFIX-INFO] with a length of 1 octet - The number of octets of the flow: inOctetDeltaCount in [IPFIX-INFO] with a length of 4 octets The template set (in case we use only IETF-specified Information Elements) will look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 24 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| classOfServiceIPv4 = 5 | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| inOctetDeltaCount = 1 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The information to be exported might be as listed in the following example table: Src. IP addr. | Dst. IP addr. | Type of service | Octets Number --------------+---------------+-----------------+-------------- 198.18.1.12 | 198.18.2.254 | 101110xx | 987410 198.18.1.27 | 198.18.2.23 | 101110xx | 170205 198.18.1.56 | 198.18.2.65 | 101110xx | 33113 The field "Type of service" contains the DiffServ Codepoint in the first six bits while the last two are currently unused. In the example we use Codepoint 101110, recommended for the EF PHB (Expedited Forwarding Per Hop Behavior)[RFC2598] Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability May 2005 The Flow Records will then look like: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 256 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 101110 00 | 8987410 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 198.18.1.27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 198.18.2.23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 101110 00 | 170205 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 198.18.1.56 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 198.18.2.65 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 101110 00 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 33113 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2 Security Analysis and Intrusion Detection with IPFIX IPFIX provides information about the traffic in a network. Therefore it is very well suited to take a key role in the detection of network threats such as intrusions, propagation of viruses and worms, port scanning and other network attacks. Intrusion detection systems (IDS) monitor and control security incidents. A typical IDS system includes several components including sensors, event collectors, and management stations. Sensors monitor network traffic for attacks and other security- related events. Sensors respond to and notify the administrator via the event collector about these events as they occur. Event collectors are a middle-tier component responsible for transmitting events from sensors to the console and database. The management component serves the following purposes: - visually monitors events (via a console) Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability May 2005 - collects data from sensors (with one or more event collectors) - stores data from sensors (in a database) IPFIX can report events of interest to the sensor either by the collecting process or directly by the exporting process. Which approach is best depends on the scenario and the events of interest. Getting information directly from the exporting process has the advantage that the sensor gets the information faster. It does not need to wait for collector processing time or until the collecting process has all relevant data. Getting the information from a collecting process enables correlation of data from different exporting processes (e.g. from different routers) to get a better picture of what is happening in the network. IPFIX provides useful input data for basic intrusion detection functions such as reporting unusually high loads, number of flows, number of packets of a specific type, etc. It can provide details on source and destination addresses, along with the start time of flows, TCP flags, application ports and flow volume. This data can be used to analyze network security incidents and identify attacks. Further data analysis and post- processing functions may be needed to generate the metric of interest for specific attack types. The integration of previous measurement results helps to assess traffic changes over time for detection of traffic anomalies. A combination with results from other observation points allows assessing the propagation of the attack and can help locate the source of an attack. For some scenarios, intrusion detection may require further insight into packet content. Since IPFIX allows a flexible report definition, the metering process and the IPFIX report format could be extended to support other data needed for intrusion detection systems. Furthermore, it is possible to get per packet information by using IPFIX to export PSAMP information. Detecting security incidents in real-time would require the pre- processing of data already at the measurement device and immediate data export in case a possible incident has been identified. This means that IPFIX reports must be generated upon incident detection events and not only upon flow end or fixed time intervals. Furthermore, security incidents can become a threat to IPFIX processes themselves (see also security considerations in [IPFIX-PROTO]. If an attack generates a large amount of flows (e.g. by sending packets with spoofed addresses or simulating flow termination) exporting and collecting process may get Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability May 2005 overloaded by the immense amount of data records that are exported. A flexible deployment of packet or flow sampling methods can prevent the exhaustion of resources. Intrusion detection can profit greatly from the combination of IPFIX and AAA functions (see section 3.1). Such an interoperation enables further means of attack detection, advanced defense strategies and secure inter-domain cooperation. 2.3 Network Planning IPFIX data records captured over a long period of time can be used to track and anticipate network growth and plan upgrades to increase the number of routing devices, ports, or higher- bandwidth interfaces. Flow information as provided by IPFIX data records optimizes both strategic network planning (peering, backbone upgrade planning, routing policy planning), and tactical network engineering decisions (upgrading the router or link capacity). This helps to minimize the total cost of network operations through effective capacity planning, while maximizing network performance and reliability. 2.4 Peering Agreements IPFIX provides a common data format for the reporting of measurement results. Therefore it is very well suited to share information with neighbor ISPs. If measurement tools in different domains export the data in the same format and collectors at different domains understand this format, IPFIX data records could be directly forwarded to neighbor providers. This can be done either by the IPFIX protocol itself or by converting or encapsulating data records into commonly used protocols for inter-domain data exchange like DIAMETER. Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g. exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. Furthermore, the necessity to defend networks against current and future threats (denial of service attacks, worm distributions, etc.) will further increase the willingness to exchange measurement data between providers. 2.5 Traffic Engineering Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability May 2005 IPIFX data provides traffic engineering details for a set of prefixes. This data can be used in network optimization for load balancing traffic across alternate paths, or for forwarding traffic of a certain set of prefixes on a preferred route. 2.6 Trend Analysis IPFIX data records are well suited to perform traffic profiling for trend analysis and as a basis for business models. The flexible flow definition allows different viewpoints on the data. The observation of different traffic statistics (e.g. number of flows, transmitted volume, etc.) over time provides valuable input on the usage of existing services or the planning of future services. IPFIX data records (or information derived from them) can be stored for later retrieval and analysis to support proactive marketing and customer service programs. An example of this is to determine which applications and services are being used by internal and external users and then target them for improved services such as advertising. This is especially useful for ISPs because IPFIX data enables them to create better service packaging. 2.7 SLA Validation and QoS Measurements Performing QoS monitoring is one target application of the IPFIX protocol. QoS monitoring is the passive observation of transmission quality for single flows or traffic aggregates in the network. One example of its usefulness is the validation of QoS guarantees in service level agreements (SLAs). Some QoS metrics require the correlation of data from multiple measurement points. For this, the clocks of the involved exporting devices must be synchronized. Furthermore, such measurements would benefit from post-processing functions (e.g. packet ID generation and mapping) at the exporter and/or collector. This section describes how the measurement of different metrics can be performed with IPFIX. All of the metrics require at least an extension of the IPFIX information model since the necessary information such as round-trip-time, packet IDs, etc., is not part of the current model. However given the extensibility and flexibility of IPFIX the missing attributes can be easily defined. The direct reporting of IPPM metrics with the IPIFX protocol is addressed in section 3.3. Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability May 2005 2.7.1 Measurement of Round-trip-time (RTT) The passive measurement of round-trip-times (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively observe the RTT [Brow00]. As always for passive measurements, this only works if the required traffic of interest is actually present in the network. Furthermore, if the observed protocol supports retransmissions (e.g. TCP), the RTT is not the network RTT, but rather the RTT of the network and the protocol stack of the receiver. In case the reply packet is lost or can not be observed, the RTT can not be calculated. In order to use this measurement technique, the IPFIX metering process needs to measure packets from both directions. A classification of the protocols mentioned above has to be done. This means that parts of the transport header are used for the classification. Since a differentiation of flows based on information in the transport header is one of the requirements for IPFIX, such classification can be performed without extensions to the protocol. Nevertheless, the metering process also needs to recognize request and response packets for the given protocols and therefore needs to look further into the packets. The capability to do this analysis is not part of the IPFIX requirements but can be achieved by optional extensions to the classification process. The exporting device needs to assign a timestamp for the arrival of the packets. The calculation of the RTT can be done directly at the exporter or at the collector. In the first case, IPFIX would transfer the calculated RTT to the collector. In the second case, IPFIX needs to send the observed packet types and the timestamps to the collector. The round-trip-time-delay metric is defined in [RFC2681]. 2.7.2 Measurement of One-way-delay (OWD) Passive one-way-delay measurements require the collection of data at two measurement points. It is necessary to recognize packets at the second measurement point to correlate packet arrival events from both points. This can be done by capturing packet header and parts of the packet that can be used to recognize the same packet at the subsequent measurement point. To reduce the amount of measurement data, a unique packet ID can be calculated from the header and all, or part of the content e.g. by using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. The capability of using parts of the payload is out of scope of Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability May 2005 IPFIX but can be achieved by an optional extension. Nevertheless, in some scenarios it might even be sufficient to calculate a packet ID based on header fields (including datagram ID and maybe sequence numbers from transport protocols) without looking at parts of the payload. If packet IDs need to be unique only for a certain time interval, or a certain amount of packet ID collisions is tolerable, this is a sufficient solution. The second issue is the export of packet IDs. IPFIX exports per-flow information. The export of packet IDs is possible by introducing a new information element (packet ID). In order to provide a more efficient data export, one can export the packet information with a flow ID in the data records. The flow ID then can be associated with flow properties in a data record. In this way the flow information only needs to be transferred once. The packet information relates to much smaller flow IDs, without the need to transfer all of the flow information for each packet [PoMB05]. The one way delay metric is defined in [RFC2679]. The export of whole packets, or parts of packets is addressed by the PSAMP working group [PSAMP]. PSAMP uses IPFIX as its export protocol. 2.7.3 Measurement of One-way-loss (OWL) Passive loss measurements for single flows can be performed at one measurement point by using sequence numbers that are present in protocols (e.g. IP identification, TCP sequence numbers) similar to the approach described in section 2.7.1. This requires the capturing of the sequence numbers of subsequent packets in the observed flow by the IPFIX metering process. An alternative to this is to perform a two-point measurement as described in section 2.7.2, and to consider packets as lost that do not arrive at the second measurement point in a given time frame. This approach assumes that a packet observed at the first point should be also observed at the second observation point (e.g. measurement should be done close to end-points or border routers). The one-way loss metric is defined in [RFC2680]. 2.7.4 Measurement of IP delay variation (IPDV) IP delay variation is defined as the difference of one-way-delay values for selected packets [RFC3393]. Therefore, this metric can be calculated by performing passive measurement of one-way- delay for subsequent packets (e.g. of a flow) and then calculating the differences. 2.7.5 Transport of IPPM Metrics Zseby, Boschi, Brownlee, Claise [Page 11]
IPFIX Applicability May 2005 The IPFIX protocol can be used to transport not only input for the calculation of IPPM metrics, but also for transporting the metrics themselves. For this, additional information elements need to be defined. 2.7.6 Other Applications IPFIX is a quite generic and powerful protocol. It provides a generic export mechanism that might be useful also for many further applications. Apart from sending raw flow information it also can be used to send further aggregated or post-processed data. For this new templates and information elements can be defined if needed. Due to the push mode operation it is also suited to send network initiated events like alarms and other notifications. It also could be used for exchanging information among network nodes to autonomously improve network operation. Nevertheless, IPFIX was designed with respect to the requirements documented in [RFC3917]. Therefore the capabilities of IPFIX have to be carefully checked against requirements of new applications before using it for other purposes than addressed in [RFC3917]. 3. Relation of IPFIX to other frameworks and protocols 3.1 IPFIX and AAA AAA defines a protocol and architecture for authentication, authorization and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g. between AAA clients at access devices and AAA servers, and among AAA servers. It is also used for the transfer of accounting records. Usage-based accounting requires measurement data from the network. IPFIX defines a protocol to export such data from routers, measurement probes and other devices. Accounting functions can be realized without an AAA infrastructure as shown in section 2.1. Accounting applications can directly incorporate an IPFIX collecting process to receive IPFIX data records with information about the transmitted volume. Zseby, Boschi, Brownlee, Claise [Page 12]
IPFIX Applicability May 2005 Nevertheless, if an AAA infrastructure is in place, the cooperation between IPFIX and AAA provides many valuable synergistic benefits. IPFIX data records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. Further potential features include the mapping of a user ID to flow information (by using authentication information) or facilitating the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice. Coupling an IPFIX collecting process with AAA functions also has high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help identify the source of malicious traffic. They are able to deny access to suspicious users or nodes. Therefore coupling those functions with an IPFIX collecting process can provide an efficient defense against network attacks. Furthermore, sharing IPFIX data records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter-domain attack detection. The AAA infrastructure can also be used to configure measurement functions in the network as proposed in [RFC3334]. Two possibilities exist to connect IPFIX and AAA: - Connecting via an AAA Client - Connecting via an Application Specific Module (ASM) Both are explained in the following sections. 3.1.1 Connecting via an AAA Client One possibility of connecting IPFIX and AAA is to run an AAA client on the IPFIX collector. This client can generate DIAMETER accounting messages and send them to an AAA server. The mapping of the flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g. in roaming scenarios). Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability May 2005 +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | DIAMETER | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 2: IPFIX collector connects to AAA server via AAA client 3.1.2 Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case the IPFIX collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers. Zseby, Boschi, Brownlee, Claise [Page 14]
IPFIX Applicability May 2005 +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 3: IPFIX connects to AAA server via ASM 3.2 IPFIX and RTFM The Real-time Traffic Flow Measurement (RTFM) working group defined an architecture for flow measurement [RFC2722]. This section compares the Real-time Traffic Flow Measurement (RTFM) framework with the IPFIX framework. 3.2.1 Architecture The RTFM consists of meter, meter reader and a manager that communicate via SNMP. The manager configures the meter, and the meter reader collects data from the meter. The IPFIX architecture [IPFIX-ARCH] defines metering, exporting and collecting processes. The RTFM architecture is very similar to the IPFIX architecture. One could see the metering process as part of the meter and the collecting process as part of the meter reader. IPFIX speaks about processes instead of devices to clarify that multiple of those processes be collocated on the same machine. Nevertheless, IPFIX currently does not define a managing process, because remote configuration is, at this time, out of scope for the working group. 3.2.2 Flow Definition RTFM and IPFIX both use the same definition of flow; a flow is a set of packets which share a common set of end-point address Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability May 2005 attribute values. A flow is therefore completely specified by that set of values, together with an inactivity timeout. A flow is considered to have ended when no packets are seen for at least the inactivity time. RTFM flows, however, are bidirectional, i.e. an RTFM meter matches packets from B to A and A to B as separate parts of a single flow, and maintains two sets of packet and byte counters, one for each direction. IPFIX flows are unidirectional. Users that require bidirectional flows have to match the two directions in post-processing. 3.2.3 Configuration and Management In RTFM, remote configuration (using an SNMP MIB) is the only way to configure a meter. IPFIX metering processes can be configured locally by a system administrator. The IPFIX group currently does not address IPFIX remote configuration. IPFIX metering processes export their configuration, i.e. the layout of data within their templates, from time to time. IPFIX collecting processes use that template information to determine how they should interpret the IPFIX flow data they receive. 3.2.4 Data Collection One major difference between IPFIX and RTFM is that RTFM uses a pull model whereas IPFIX uses a push model for the data collection. An IPFIX exporting process is configured to export data records to a specified list of IPFIX collecting processes. The data records are pushed to the colleting process. The condition when to send data records (e.g. flow termination) can be configured in the exporting or metering process. In contrast to this, an RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. 3.2.5 Data Model Details RTFM defines all its attributes in the RTFM Meter MIB [RFC 2720]. IPFIX information elements are defined in [IPFIX-INFO]. RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a flow. The counters are never reset and just wrap back to zero if the maximum value is Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability May 2005 exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings. IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [IPFIX-INFO]. The totalCounter are never reset and just wrap to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter are reset to zero when the associated flow record is exported. 3.2.6 Application/Transport Protocol RTFM has a standards-track Meter MIB [RFC 2720], which is used both to configure a meter and to store metering results. The MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which dramatically reduces the SNMP overhead for flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader. IPFIX is designed to work over a variety of different transport protocols. SCTP and SCTP-PR (partially reliable) are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than does SNMP, hence IPFIX will have lower data transport overhead than RTFM. 3.2.7 RTFM Summary IPFIX provides a simple, powerful protocol for exporting flow data from a metering process. RTFM provides bi-directional flows and explicitly addresses dynamic configuration with a very flexible flow definition. It may continue to be more suitable in research situations where those features are needed. A major difference between both frameworks is that RTFM works in a pull mode for data collection, while IPFIX uses a push mode for data export. 3.3 IPFIX and IPPM The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see section 2.7). 3.4 IPFIX and PSAMP Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability May 2005 The PSAMP group defines packet selection methods and the reporting of whole packet or partial packet information. It also defines the configuration of packet selection methods. The major difference between IPFIX and PSAMP is that while the former addresses the export of flow records, the latter addresses the export's packet records. The PSAMP group has decided to use IPIFX as its export protocol for packet information. The Working Group describes a set of requirements in [PSAMP-FM] that directly affect the export protocol. In [PSAMP-PROTOCOL] the requirements have been analyzed with respect to IPFIX. The conclusion was that IPFIX is a general enough export protocol to be suitable for PSAMP export. If needed, the information model can be easily extended. PSAMP defines a PSAMP MIB for the configuration of packet selection processes. One could consider extending this MIB to allow configuration of IPFIX processes. 3.5 IPFIX and RMON RMON [RFC 3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices using SNMP. The RMON MIB is divided into sections, each section providing different monitoring functions. For example, the 'Hosts' section gathers statistics for hosts which are active on the network and being monitored. RMON does not cover flow measurement at all. To do so, one would need to extend RMON by adding a MIB module to handle flows. Further, one would need to devise a scheme for exporting high volumes of flow data. In short, IPFIX is designed to provide effective flow export; RMON is not. 3.6 IPFIX and IDMEF The Intrusion Detection Message Exchange Format (IDMEF) [CuDF05] is a standard data format developed within the IDWG Working Group to exchange data alerts between automated Intrusion Detection Systems (IDS). IDMEF provides a standard representation of the alert information that an intrusion detection analyzer reports when a suspicious event is detected. These alerts may be simple or complex depending on analyzers' capabilities, commercial vendor objectives, and intrusion detection environments. IDMEF messages are implemented in XML and composed by a basic schema and extension modules to define alerts that are more complex. Once the kind of alert that should be sent has been determined by the analyzer, it must be Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability May 2005 formatted following the IDMEF rules. Generally, alerts are sent when analyzers detect an event that they have been configured to look for. The IPFIX protocol can be used to provide input for intrusion detection systems, but also complementarily to IDMEF by providing detailed information on intrusions traffic, suspect events or anomalous traffic that differs from normal network behavior. 4. Limitations The goal of this section is to give recommendations where not to use IPFIX. While the protocol is general enough to be adequate for exporting data records for many applications, it still has limitations. Use of SCTP: SCTP is the preferred protocol for IPFIX, i.e. a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, users should make sure they have good reasons for using protocols other than SCTP. Push mode: IPFIX works in push mode. That means data records are automatically exported without waiting for a request. The responsibility for initiating a data export is at the exporting process. Exporting criteria are part of the configuration of the exporting process. Traffic characteristics are quite dynamic. Therefore the amount of data (e.g. data records) that has to be exported can vary over time. Push mode has more benefits if the trigger for data export is related to events at the exporting process (e.g. flow termination, memory shortage due to large amount of flows, etc.). If the protocol used pull mode, the exporting process would need to wait for a request to send the data. With push mode it can send data immediately e.g. before memory shortage would require a discarding of data. Pull mode has advantages if the trigger for data export is related to events at the collecting process (e.g. a specific application requests immediate input). In a pull mode, a request could simply be forwarded to the exporting process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode it can be prevented that the collecting process is overloaded by the arrival of more data records than it can process. Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability May 2005 Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented. Template ID number: The IPFIX specification limits the different template ID numbers that can be assigned to the newly generated template records in an Observation domain. In particular, template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different templates, the set of Template IDs could be exhausted. 4.1 IPFIX and IPv6 There are two issues to consider: - Generation and reporting of data records about IPv6 traffic - Exporting data records over IPv6 The generation and reporting of data records about IPv6 traffic is possible as appropriate information elements exist in [IPFIX- INFO]. Exporting data records over IPv6 is not explicitly addressed in [IPFIX-PROTO]. Nevertheless, since IPFIX runs over SCTP, SCTP- PR, UDP or TCP, it is trivial to run IPFIX over IPv6 networks, provided that the transport protocol being used to carry IPFIX is running on the IPv6 network. 5. Security Considerations This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [IPFIX- PROTO]. These requirements had to be considered for the specification of the IPFIX protocol. The IPFIX extensions proposed in this document do not induce further security hazards. Section 3 of this document describes how IPFIX can be used in combination with other frameworks. New security hazards can arise when two individually secure frameworks are combined. For the combination of AAA with IPFIX an application specific module (ASM) or an IPFIX collector can function as transit point for the messages. It must be ensured that at this point the applied Zseby, Boschi, Brownlee, Claise [Page 20]
IPFIX Applicability May 2005 security mechanisms (e.g. encryption of messages) are maintained. 6. Normative References [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, Requirements for IP Flow Information Export, October 2004 [IPFIX-PROTO] B. Claise (Editor), IPFIX Protocol Specification, Internet Draft <draft-ietf-ipfix-protocol-14.txt>, work in progress, May 2005 [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, Information Model for IP Flow Information Export, Internet Draft <draft-ietf-ipfix-info-06>, work in progress, February 2005 7. Informative References [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, Architecture for IP Flow Information Export, Internet Draft <draft-ietf-ipfix-architecture- 07.txt>, work in progress, March 2005 [Brow00] Nevil Brownlee, Packet Matching for NeTraMet Distributions, http://www2.auckland.ac.nz/net//Internet/rtfm/meeti ngs/47-adelaide/pp-dist/ [CuDF05] D.Curry, H. Debar, H. Feinstein, The Intrusion Detection Message Exchange Format, work in progress, Internet Draft <draft-ietf-idwg-idmef- xml-14.txt>, January 2005 [DuGr00] Nick Duffield, Matthias Grossglauser, Trajectory Sampling for Direct Traffic Observation, Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000. [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, Jed Martens, John G. Cleary, Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 Zseby, Boschi, Brownlee, Claise [Page 21]
IPFIX Applicability May 2005 [PSAMP] http://www.ietf.org/html.charters/psamp- charter.html [PSAMP-FW] Nick Duffield (Ed.), A Framework for Packet Selection and Reporting, Internet Draft draft-ietf- psamp-framework-08, work in progress, January 2005 [PoMB05] G. Pohl, L. Mark, E. Boschi, Use of IPFIX for Export of Per-Packet Information, Internet Draft <draft-pohl-perpktinfo-02.txt>, work in progress, February 2005 [RFC2598] V. Jacobson, K. Nichols, K. Poduri, An Expedited Forwarding PHB, Request for Comments: 2598, June 1999 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, A One-way Delay Metric for IPPM, Request for Comments: 2679, September 1999 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, A One-way Packet Loss Metric for IPPM, September 1999 [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, A Round-trip Delay Metric for IPPM, RFC 2681, September 1999 [RFC2722] Brownlee, N., Mills, C., and G. Ruth, Traffic Flow Measurement: Architecture, RFC 2722, October 1999. [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, Generic AAA Architecture, RFC 2903, August 2000 [RFC3334] T. Zseby, S. Zander, G. Carle, Policy-Based Accounting, Request for Comments: 3334, October 2002 [RFC3393] C. Demichelis, P. Cimento, IP Packet Delay Variation Metric for IPPM, RFC 3393, November 2002 [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, D.Romascanu, Introduction to the Remote Monitoring (RMON) Family of MIB Module, RFC 3577,August 2003 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, Diameter Base Protocol, Request for Comments 3588, September 2003 Zseby, Boschi, Brownlee, Claise [Page 22]
IPFIX Applicability May 2005 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle, Evaluation of Building Blocks for Passive One-way- delay Measurements, Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 8. Acknowledgements We would like to thank the following persons for their contribution, discussion on the mailing list and valuable comments: Sebastian Zander Robert Lowe Reinaldo Penno Part of the work has been developed in the research project 6QM co-funded with support from the European Commission. 9. Author's Addresses Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.fhg.de Elisa Boschi Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7366 Email: boschi@fokus.fhg.de Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Phone : +1 858 534 8338 Email : nevil@caida.org Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Zseby, Boschi, Brownlee, Claise [Page 23]
IPFIX Applicability May 2005 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com 10. Full Copyright Statement "Copyright (C) The Internet Society (2005). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. 11. Intellectual Property Statement The IETF has been notified by Cisco of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, see http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix-as- 02.txt 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. Zseby, Boschi, Brownlee, Claise [Page 24]
IPFIX Applicability May 2005 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. 12. Copyright Statement Copyright (C) The Internet Society (2005). 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. 13. Disclaimer 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 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. Zseby, Boschi, Brownlee, Claise [Page 25]
