Internet Draft                                              Tanja Zseby
 Document: <draft-ietf-ipfix-as-06.txt>                     Elisa Boschi
 Expires: January 2006                                  Fraunhofer FOKUS
                                                          Nevil Brownlee
                                                           Benoit Claise
                                                           Cisco Systems
                                                               July 2005
                           IPFIX Applicability
    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
    The list of Internet-Draft Shadow Directories can be accessed at
    Copyright Notice
    Copyright (C) The Internet Society (2005).
 Zseby, Boschi, Brownlee, Claise                           [Page 1]

                      IPFIX Applicability              July 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 furthermore shows how the
    IPFIX framework relates to other architectures and frameworks.
 Zseby, Boschi, Brownlee, Claise                           [Page 2]

                      IPFIX Applicability              July 2005
 Table of Contents
    1.    Introduction............................................4
    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.....................................9
    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).....................11
    2.7.3 Measurement of One-way-loss (OWL)......................11
    2.7.4 Measurement of IP delay variation (IPDV)...............12
    2.7.5 Transport of IPPM Metrics..............................12
    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   Use of a different transport protocol than SCTP........19
    4.2   Push vs. pull mode.....................................19
    4.3   Template ID number.....................................20
    4.4   IPFIX and IPv6.........................................20
    5.    Security Considerations................................20
    6.    Normative References...................................21
    7.    Informative References.................................21
    8.    Acknowledgements.......................................23
    9.    Authors' Addresses.....................................23
    10.   Full Copyright Statement...............................24
    11.   Intellectual Property Statement........................24
    12.   Copyright Statement....................................25
    13.   Disclaimer.............................................25
 Zseby, Boschi, Brownlee, Claise                           [Page 3]

                      IPFIX Applicability              July 2005
 1. Introduction
    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 enable 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 to 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.
 Zseby, Boschi, Brownlee, Claise                           [Page 4]

                      IPFIX Applicability              July 2005
    For accounting purposes, it would be advantageous to have the
    ability to use IPFIX flow records as accounting input in an AAA
    infrastructure. AAA servers then could provide the mapping
    between user and flow information.
    Note that the reliability requirements defined in [RFC3917] are
    not sufficient to guarantee the level of reliability that is
    needed for many usage-based accounting systems. Particular
    reliability requirements for accounting systems are discussed in
 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:
 Zseby, Boschi, Brownlee, Claise                           [Page 5]

                      IPFIX Applicability              July 2005
    Src. IP addr. | Dst. IP addr. | Type of service | Octets Number
    --------------+---------------+-----------------+--------------   | |  101110         | 987410   |  |  101110         | 170205   |  |  101110         | 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]
    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          |
       |                                          |
       |                                         |
       |   101110 00   |                 987410                       |
       |               |                          |
       |               |                          |
       |               |   101110 00   |                 170205        |
       |                               |           |
       |                               |           |
       |                               |   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.
 Zseby, Boschi, Brownlee, Claise                           [Page 6]

                      IPFIX Applicability              July 2005
    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 and system traffic for attacks and other
    security-related events. Sensors respond to and notify the
    administrator 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 (with a console)
    - 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 collector has all relevant data. Getting the
    information from a collector allows correlating data from
    different exporting processes (e.g. from different routers) to
    get a better picture of what is going on in the network.
    IPFIX provides useful input data for basic intrusion detection
    functions like detecting of 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 for exporting PSAMP
 Zseby, Boschi, Brownlee, Claise                           [Page 7]

                      IPFIX Applicability              July 2005
    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
    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 profits greatly from the combination of
    IPFIX functions with AAA functions (see section 3.1). Such an
    interoperation enables further means for attacker 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
 Zseby, Boschi, Brownlee, Claise                           [Page 8]

                      IPFIX Applicability              July 2005
    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
    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 basis for business models. The
    flexible flow definition allows different viewpoints on the
    data. The observation of different traffic statistics (like
    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
 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.
 Zseby, Boschi, Brownlee, Claise                           [Page 9]

                      IPFIX Applicability              July 2005
    packet ID generation and mapping) at the exporter and/or
    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 because 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.
 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 cannot be observed, the RTT cannot be
    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
 Zseby, Boschi, Brownlee, Claise                           [Page 10]

                      IPFIX Applicability              July 2005
 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 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 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 data records. The flow
    ID then can be associated to flow properties in a data record.
    With this the flow information needs to be transferred only
    once. The packet information just relates to much smaller flow
    IDs, without the need to transfer the whole flow information for
    each packet [BoMa05].
    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 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 of 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 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
 Zseby, Boschi, Brownlee, Claise                           [Page 11]

                      IPFIX Applicability              July 2005
    (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
    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
 Zseby, Boschi, Brownlee, Claise                           [Page 12]

                      IPFIX Applicability              July 2005
    clients at access devices and AAA servers, and among AAA
    servers. It is used also 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
    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 has also
    high potential for intrusion and attack detection. AAA controls
    network access and maintains data about users and nodes. AAA
    functions can help to 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
 Zseby, Boschi, Brownlee, Claise                           [Page 13]

                      IPFIX Applicability              July 2005
    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).
           +---------+  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              July 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 and 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
    attribute values. A flow is therefore completely specified by
 Zseby, Boschi, Brownlee, Claise                           [Page 15]

                      IPFIX Applicability              July 2005
    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 flow 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
 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
    exceeded. Flows can be read at any time. The difference between
 Zseby, Boschi, Brownlee, Claise                           [Page 16]

                      IPFIX Applicability              July 2005
    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 overheads 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 that need those features.
    A major difference between both frameworks is that RTFM works in
    pull mode and IPFIX uses push mode for data collection.
 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
    The PSAMP group defines packet selection methods and the
    reporting of packet information. It also defines the
 Zseby, Boschi, Brownlee, Claise                           [Page 17]

                      IPFIX Applicability              July 2005
    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 of
    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 in a general
    way 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 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
    formatted following the IDMEF rules.
 Zseby, Boschi, Brownlee, Claise                           [Page 18]

                      IPFIX Applicability              July 2005
    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 of intrusions traffic, suspect
    events or anomalous traffic that differs from normal network
 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
 4.1 Use of a different transport protocol than 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.
 4.2 Push vs. pull 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.
 Zseby, Boschi, Brownlee, Claise                           [Page 19]

                      IPFIX Applicability              July 2005
    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.
    Whether this is a relevant drawback depends on the flexibility
    of the IPFIX configuration and how IPFIX configuration rules are
 4.3 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.4 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-
    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
    Section 3 of this document describes how IPFIX can be used in
    combination with other frameworks. New security hazards can
 Zseby, Boschi, Brownlee, Claise                           [Page 20]

                      IPFIX Applicability              July 2005
    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 has to be ensured that at this point the
    applied security mechanisms (e.g. encryption of messages) are
 6. Normative References
    [RFC3917]    J. Quittek, T. Zseby, B. Claise, S. Zander,
                  "Requirements for IP Flow Information Export", RFC
                  3917, October 2004
    [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification",
                  Internet Draft <draft-ietf-ipfix-protocol-16.txt>,
                  work in progress, June 2005
    [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model
                  for IP Flow Information Export", Internet Draft
                  <draft-ietf-ipfix-info-07>, work in progress, May
 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-
                  08.txt>, work in progress, March 2005
    [Brow00]      Nevil Brownlee, "Packet Matching for NeTraMet
    [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
 Zseby, Boschi, Brownlee, Claise                           [Page 21]

                      IPFIX Applicability              July 2005
                  Delay Variation on the Internet", INET'98, Geneva,
                  Switzerland, 21-24 July, 1998
    [PSAMP-FW]    Nick Duffield (Ed.), "A Framework for Packet
                  Selection and Reporting", Internet Draft draft-
                  ietf-psamp-framework-08, work in progress, January
    [BoMa05]      E. Boschi, L. Mark,  " Use of IPFIX for Export of
                  Per-Packet Information", Internet Draft <draft-
                  boschi-export-perpktinfo-00.txt>, work in progress,
                  June 2005
    [RFC2598]     V. Jacobson, K. Nichols, K. Poduri, "An Expedited
                  Forwarding PHB", RFC 2598, June 1999
    [RFC2679]     G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
                  Delay Metric for IPPM", RFC 2679, September 1999
    [RFC2680]     G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
                  Packet Loss Metric for IPPM",RFC 2680, September
    [RFC2681]     G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip
                  Delay Metric for IPPM", RFC 2681, September 1999
    [RFC2722]     N. Brownlee, C. Mills, 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
    [RFC2975]     B. Aboba, J. Arkko, D. Harrington, "Introduction to
                  Accounting Management", RFC 2975, October 2000
    [RFC3334]     T. Zseby, S. Zander, G. Carle, "Policy-Based
                  Accounting", RFC 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
 Zseby, Boschi, Brownlee, Claise                           [Page 22]

                      IPFIX Applicability              July 2005
    [RFC3588]     P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J.
                  Arkko, "Diameter Base Protocol", RFC 3588,
                  September 2003
    [ZsZC01]      T. Zseby, S. Zander, G. 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
    Sebastian Zander
    Robert Loewe
    Reinaldo Penno
    Part of the work has been developed in the research project 6QM
    co-funded with support from the European Commission.
 9. Authors' Addresses
    Tanja Zseby
    Fraunhofer Institute for Open Communication Systems (FOKUS)
    Kaiserin-Augusta-Allee 31
    10589 Berlin, Germany
    Phone: +49 30 3463 7153
    Elisa Boschi
    Fraunhofer Institute for Open Communication Systems (FOKUS)
    Kaiserin-Augusta-Allee 31
    10589 Berlin, Germany
    Phone: +49 30 3463 7366
    Nevil Brownlee
    9500 Gilman Drive
    La Jolla, CA 92093-0505
    Phone : +1 858 534 8338
    Email :
 Zseby, Boschi, Brownlee, Claise                           [Page 23]

                      IPFIX Applicability              July 2005
    Benoit Claise
    Cisco Systems
    De Kleetlaan 6a b1
    1831 Diegem
    Phone: +32 2 704 5622
 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
    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
 Zseby, Boschi, Brownlee, Claise                           [Page 24]

                      IPFIX Applicability              July 2005
    specification can be obtained from the IETF on-line IPR
    repository at
    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
 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
 Zseby, Boschi, Brownlee, Claise                           [Page 25]