[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5472

 Internet Draft                                              Tanja Zseby
 Document: <draft-ietf-ipfix-as-03.txt>                     Elisa Boschi
 Expires: April 2005                                    Fraunhofer FOKUS
                                                          Reinaldo Penno
                                                         Nortel Networks
                                                          Nevil Brownlee
                                                                   CAIDA
                                                           Benoit Claise
                                                           Cisco Systems
 
                                                            October 2004
 
 
                           IPFIX Applicability
                        draft-ietf-ipfix-as-03.txt
 
 Status of this Memo
 
    This document is an Internet-Draft and is subject to all
    provisions of section 3 of RFC 3667. 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 become aware
    will be disclosed, in accordance with RFC 3668.
 
    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 (2004).
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 1]
 

                      IPFIX Applicability
 
 
 
 
 
    Abstract
 
    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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 2]
 

                      IPFIX Applicability
 
 
 
 
 Table of Contents
    1.   Introduction.............................................3
    2.   Applications of IPFIX....................................4
    2.1  Accounting...............................................4
    2.2  Security Analysis and Intrusion Detection with IPFIX.....4
    2.3  Network Planning.........................................5
    2.4  Peering Agreements.......................................6
    2.5  Traffic Engineering......................................6
    2.6  Data Warehousing and Mining..............................6
    2.7  SLA validation...........................................6
    2.8  Traffic Monitoring.......................................7
    2.8.1 Measurement of Round-trip-time (RTT)....................7
    2.8.2 Measurement of One-way-delay (OWD)......................8
    2.8.3 Measurement of One-way-loss (OWL).......................8
    2.8.4 Measurement of IP delay variation (IPDV)................9
    3.   Relation of IPFIX to other frameworks and protocols......9
    3.1  IPFIX and AAA............................................9
    3.1.1 Connecting via an AAA Client...........................10
    3.1.2 Connecting via an Application Specific Module (ASM)....11
    3.2  IPFIX and RTFM..........................................12
    3.2.1 Definition of 'flow'...................................12
    3.2.2 Configuration and Management...........................13
    3.2.3 Data Model Details.....................................14
    3.2.4 Application/Transport Protocol.........................15
    3.3  IPFIX and IPPM..........................................15
    3.4  IPFIX and PSAMP.........................................16
    3.4.1 Export using one-packet flow records...................16
    3.4.2 Export using flow and packet properties templates......16
    3.5  IPFIX and IDMEF.........................................17
    4.   IPFIX and Ipv6..........................................17
    5.   Where not to use IPFIX..................................17
    6.   Security Considerations.................................18
    7.   Normative References....................................18
    8.   Informative References..................................18
    9.   Acknowledgements........................................19
    10.  Author's Addresses......................................19
    11.  Copyright Statement.....................................20
    12.  Intellectual Property Statement.........................21
    13.  Disclaimer..............................................21
 
 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 for various
    applications. This document describes what applications can use
    the IPFIX protocol and how they can use it. Furthermore, the
 
 
 
 
 
 
                        Expires April 2005              [Page 3]
 

                      IPFIX Applicability
 
 
 
 
    relationship of IPFIX to other frameworks and architectures is
    described.
 
 2. Applications of IPFIX
 
    IPFIX data enables several critical customer applications. This
    section describes how different applications can use IPFIX.
 
 2.1 Accounting
 
    Usage based accounting is one of the major applications for
    which the IPFIX protocol has been developed. IPFIX data provide
    fine-grained metering (for example, flow records include details
    such as IP addresses, packet and byte counts, timestamps, Type
    of Service (ToS), application ports, etc.) for highly flexible
    and detailed resource usage accounting. 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. A
    tariff can, for instance, be based on individual end-to-end
    streams. In that case accounting can be realized with a flow
    definition determined by the quintuple that consists of source
    address, destination address, protocol and port numbers. Another
    example is a class-dependent tariff (e.g. in a DiffServ
    network). For this flows could be distinguished just by DiffServ
    codepoint (DSCP) and source address.
 
    The essential elements needed for accounting are the number of
    transferred packets and bytes per flow which are contained in
    IPFIX flow records. Furthermore IPFIX provides a very flexible
    definition of flows, so arbitrary flow-based accounting models
    can be realized without any extensions to the IPFIX protocol.
    Nevertheless the configuration of flow definitions is out of
    scope of the IPFIX definition.
 
    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.
 
 2.2 Security Analysis and Intrusion Detection with IPFIX
 
 
 
 
 
 
 
                        Expires April 2005              [Page 4]
 

                      IPFIX Applicability
 
 
 
 
    Intrusion detection systems (IDS) monitor and control security
    incidents. A typical IDS system includes components like sensor,
    event collector, 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 (e.g. detecting unusually high loads) such as 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. Nevertheless, 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.
 
    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.
 
 2.3 Network Planning
 
    IPFIX data captured over a long period of time can be used to
    track and anticipate network growth and plan upgrades to
 
 
 
 
 
                        Expires April 2005              [Page 5]
 

                      IPFIX Applicability
 
 
 
 
    increase the number of routing devices, ports, or higher-
    bandwidth interfaces. IPFIX data optimizes both strategic
    network planning (peering, backbone upgrade planning, and
    routing policy planning) as well as tactical network engineering
    decisions (upgrading the router or link capacity). This helps to
    minimize the total cost of network operations while maximizing
    network performance, capacity, and reliability.
 
 2.4 Peering Agreements
 
    IPFIX data enables ISP peering partners to measure the volume
    and characteristics of traffic exchanged with other ISP peers.
    ISP peering partners, consortia, or business coalitions can use
    IPFIX to exchange data between different domains. Having a means
    to share measurement data allows for more accurate end-to-end
    measurements. Through IPFIX data measured with different (often
    domain specific) tools can be exchanged and compared with data
    belonging to other domains.
    This is especially useful for inter-domain SLA validation where,
    in order to be able to provide accurate data, an ISP has to
    obtain measurements from other ISPs crossed in the end-to-end
    path.
 
 
 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 Data Warehousing and Mining
 
    IPFIX data (or derived information) can be stored for later
    retrieval and analysis to support proactive marketing and
    customer service programs. An example of this would be 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
 
    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
 
 
 
 
 
                        Expires April 2005              [Page 6]
 

                      IPFIX Applicability
 
 
 
 
    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.
 
 2.8 Traffic Monitoring
 
    IPFIX data can be used for extensive near real-time traffic
    monitoring. Traffic patterns associated with routing devices and
    switches on an individual or network wide basis can be displayed
    enabling proactive problem detection, efficient troubleshooting,
    and rapid problem resolution.
 
    IPFIX data enables content and service providers to perform a
    detailed, time-based, and application-based usage analysis of a
    network. They also provide detailed information for
    understanding customer or end-user usage of network and
    application resources. This information can then be used to
    efficiently plan and allocate access, backbone, and application
    resources, as well as to detect and resolve potential security
    and policy violations.
 
 
    This section describes how the monitoring 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 currently not part of the model. However given the
    extensibility and flexibility of IPFIX the missing attributes
    can be easily defined.
 
 2.8.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, this only works for passive measurements 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.
 
 
 
 
 
                        Expires April 2005              [Page 7]
 

                      IPFIX Applicability
 
 
 
 
 
    In order to use this measurement technique, the IPFIX metering
    process needs to measure in both directions. A classification of
    the protocols mentioned above has to be done. That means parts
    of the transport header are used for the classification. Since a
    differentiation of flows in accordance to the transport header
    is one of the requirements for IPFIX, such classification can be
    performed without extensions. Nevertheless, the meter 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.8.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 part and/of the content e.g.
    by using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. The
    capability of using content information 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 packet content. 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. However, it is possible to extend IPFIX with a
    scheme to export per-packet information by providing special
    templates for that purpose. The one way delay metric is defined
    in [RFC2679].
 
 2.8.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
 
 
 
 
 
                        Expires April 2005              [Page 8]
 

                      IPFIX Applicability
 
 
 
 
    in protocols (e.g. IP identification, TCP sequence numbers)
    similar to the approach described in section 2.8.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.8.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 also be observed at the second point (known
    routing).
 
    The one-way loss metric is defined in [RFC2680].
 
 2.8.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.
 
 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. The DIAMETER
    protocol is used for AAA communication for network access
    services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture
    [RFC2903] provides a framework for extending the AAA support
    also for 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 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.
 
    The provisioning of accounting with IPFIX can be realized
    without an AAA infrastructure. The collector can directly
    forward the measurement information to an accounting
    application. Nevertheless, if an AAA infrastructure is in place,
    IPFIX can provide the input for the generation of accounting
    records and several features of the AAA architecture can be
    used. Features include the mapping of a user ID to the flow
    information (by using authentication information), the
    generation of DIAMETER accounting records and the secure
 
 
 
 
 
                        Expires April 2005              [Page 9]
 

                      IPFIX Applicability
 
 
 
 
    exchange of accounting records between domains with DIAMETER.
    Two possibilities to connect IPFIX and AAA can be distinguished:
 
 3.1.1 Connecting via an AAA Client
 
    One possibility means 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).
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 10]
 

                      IPFIX Applicability
 
 
 
 
 
           +---------+  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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 11]
 

                      IPFIX Applicability
 
 
 
 
 
           +---------+  DIAMETER    +---------+
           |  AAA-S  |------------->|  AAA-S  |
           +---------+              +---------+
                ^
                |
        +------------------+
        |     ASM          |
        |  +------------+  |
        |  |  Collector |  |
        +------------------+
                ^
                | IPFIX
                |
          +------------+
          |  Exporter  |
          +------------+
 
    Figure 3: IPFIX connects to AAA server via ASM
 
 3.2 IPFIX and RTFM
 
    This section compares the Real-time Traffic Flow Measurement
    (RTFM) framework with the IPFIX framework.
 
 3.2.1 Definition of 'flow'
 
    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
    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 are bidirectional, which has given rise to some
    confusion.
    At the simplest level, a flow information exporter may achieve
    this by maintaining two unidirectional flows, one for each
    direction.  To export bidirectional flow information, e.g. to-
    and from- packet counts, for a flow from A to B, the exporter
    has only to search its flow table to find the matching flow from
    B to A.
 
    RTFM, however, takes bi-directionality a step further, by
    including in the RTFM architecture [RFC 2722] a fully-detailed
    algorithm for real-time matching of the two directions of a
    flow.  This was done for two reasons: to reduce the memory
    required to store each flow (common address attributes for each
 
 
 
 
 
                        Expires April 2005              [Page 12]
 

                      IPFIX Applicability
 
 
 
 
    direction), and to allow for attributes which required fine
    detail for the two directions, e.g. short-term bit rate
    distributions [RFC 2724].
    ** So far there has been no suggestion that IPFIX should do
    this.
 
 3.2.2 Configuration and Management
 
    The RTFM architecture specifies a complete system for gathering
    flow information.  It defines three entities,
     - Meters are very similar to IPFIX exporters.
     - Meter Readers are very similar to IPFIX collectors.
     - Managers coordinate the activities of meters and meter
    readers, and download configuration to them.
 
    Note that the whole RTFM system is asynchronous; many readers
    may collector flow data from a meter, and any reader may collect
    flow data from many meters.
 
    Rulesets allow the user to specify which flows are of interest,
    which are the source and destination ends of each flow, and what
    level of address granularity is required in the metered flows.
    For example, one may select all packets from 192.168/16, but
    build flow information for 192.168/24.  RTFM selection is done
    by testing under masks, and the masks do not have to use
    consecutive ones from the left.  Non-contiguous masks were
    considered important for handling some OSI protocols, but the
    need for that has diminished considerably.
 
    The RTFM approach is based on RMON, in that if a user wants to
    collect flow data for some particular set of flows, this can be
    achieved by writing a ruleset, i.e. an SRL program [RFC 2723],
    to specify what flows are of interest, requesting a manager to
    download that ruleset to a meter, and requesting the manager to
    have a meter reader collect the flow data at specified
    intervals.
 
    The details of how the manager communicates this information to
    meters and meter readers are not specified in the architecture.
    RTFM has a Meter MIB [RFC 2720], which is a standard which can
    be used to configure a meter, but nothing is said about how to
    configure a meter reader.
 
    The extent to which IPFIX should specify how meters or exporters
    should be configured is, at this stage, an open question.
    Clearly a collector needs some way to be sure of what it's
    collecting, e.g. by receiving 'templates' from the meter.
 
 
 
 
 
 
                        Expires April 2005              [Page 13]
 

                      IPFIX Applicability
 
 
 
 
    RTFM and IPFIX both leave parts of the system unspecified.  For
    RTFM flow data to be useful one must know the ruleset used to
    configure the meter, but a user can specify the ruleset.  For
    IPFIX one knows what the data is from the templates, but we have
    yet to determine whether in-band configuration will be
    supported.
 
 3.2.3 Data Model Details
 
 3.2.3.1  Count in One Bucket
 
    Within a ruleset, a packet may only be counted in one bucket,
    i.e. it may only be included in one flow.  This means that the
    meter does not have to keep track of overlapping flows - if such
    aggregation is required, it must be done after the raw flow data
    has been read by a meter reader.
 
    From time to time one may wish to collect flow data for
    different levels of aggregation at the same time.  RTFM allows a
    meter to run several rulesets at the same time, and meter
    readers must specify which rulesets they are collecting data
    from.
 
    The 'count in one bucket' rule, together with the ability to run
    multiple rulesets, has proved very simple and effective in
    practice.
 
 3.2.3.2  Counter Wrapping
 
    For its packet- and byte-count attributes RTFM uses
    continuously-incrementing 64-bit counters, which are never
    reset.  This makes asynchronous meter reading easy, any reader
    simply has to remember its previous reading and compute the
    difference.  The only caveat is that the meter should be read
    often enough to avoid situations when the counter has cycled
    more than once between readings.
 
 3.2.3.3  Sampling Issues
 
    RTFM provides 1 out of N sampling as a configuration option, so
    that some metering interfaces may only process every Nth packet.
    The RTFM Architecture [RFC 2722] does not discuss the
    statistical implications of this, merely saying that users will
    need to satisfy themselves that sampling makes sense in their
    environment.
 
    RTFM makes no provision for flow sampling.  Recently there has
    been a lot of interest in flow sampling schemes which favour the
 
 
 
 
 
                        Expires April 2005              [Page 14]
 

                      IPFIX Applicability
 
 
 
 
    'most important' flows. Perhaps we need to consider this for
    IPFIX.
 
 3.2.4 Application/Transport Protocol
 
    RTFM has a standards-track Meter MIB [RFC 2720], which can be
    used both to configure a meter and to read flow data from it.
    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.  NeTraMet, a
    widely-used open-source RTFM implementation, uses SNMPv2C for
    configuration and 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.  SNMP over TCP
    would be a better approach, but that is currently an IRTF
    project.
 
    On the other hand, RTFM does not specify an application protocol
    in its architecture, leaving this as an implementation issue.
    For example, a team at IBM Research implemented a RTFM meter and
    meter reader in a single host, with the reader storing the flow
    data directly into a large database system [reference].
    Similarly, many NeTraMet users run the meter and meter reader on
    the same host system.
 
    A need for high flow data rates highlights the need for careful
    systems design when building a flow data collection system.
    When data rates are high, and it is not possible to use a high
    level of aggregation, then it makes sense to have the collectors
    very close to their exporters.  Once the data is safely on a
    dedicated host machine, large volumes of it can be moved using
    'background' techniques such as FTP.
 
    The RTFM architecture only specifies a pull model for getting
    data out of a meter.  To implement push mode data transfer would
    require specification of triggers to indicate when data should
    be sent for each flow.
 
 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 section2.8).
 
 
 
 
 
 
                        Expires April 2005              [Page 15]
 

                      IPFIX Applicability
 
 
 
 
 3.4 IPFIX and PSAMP
 
    There is currently a very dynamic relation between IPFIX and
    PSAMP. PSAMP defines, between others, the information to be
    reported on sampled packets, describes the protocol by which
    this information is reported and the protocol by which the
    packet reporting is configured. The Working Group describes in
    [PSAMP-FRAMEWORK] a set of requirements that affect directly the
    export protocol. In [PSAMP-PROTOCOL] the requirements have been
    analyzed with respect to IPFIX and the conclusion is that IPFIX
    is an exporting protocol general enough to be suitable for
    PSAMP.
    The major difference between IPFIX and PSAMP protocols is that
    while the former exports flow records, the latter exports packet
    records. The following sections describe two different ways to
    export sampled packets using IPFIX.
 
 3.4.1 Export using one-packet flow records
 
    A single packet can be considered a special case of a flow. So,
    a PSAMP export would be a special IPFIX flow record containing
    information about a flow composed of a single packet. Using this
    method, no modifications would be required for IPFIX at the
    actual stage, but flow information would be repeated for every
    packet introducing a high degree of redundancy.
 
 
    +------+------+------------+---------+
    | srcA | dstA | packet info|   ...   |
    +------+------+------------+---------+
    | srcA | dstA | packet info|   ...   |
    +------+------+------------+---------+
    | srcB | dstB | packet info|   ...   |
    +------+------+------------+---------+
    | srcA | dstA | packet info|   ...   |
    +------+------+------------+---------+
 
    Figure 3: Exporting One-packet flows
 
 
 
 3.4.2 Export using flow and packet properties templates
 
    Packet information can be exported using two templates: a Packet
    Properties Template containing the information related to the
    sampled packet and a Flow Property Template summarizing flow
    information. The relation between the two templates is kept by
    using indices that link a packet to the flow it belongs to. This
    method is shown in the following figure.
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 16]
 

                      IPFIX Applicability
 
 
 
 
 
                                  Packet Properties
                                 +-----+------------+---------+
    Flow Properties              |idxA | packet info|   ...   |
    +------+------+-----+        +-----+------------+---------+
    | srcA | dstA |idxA |        |idxA | packet info|   ...   |
    +------+------+-----+        +-----+------------+---------+
    | srcB | dstB |idxB <-------->idxB | packet info|   ...   |
    +------+------+-----+        +-----+------------+---------+
                                 |idxB | packet info|   ...   |
                                 +-----+------------+---------+
 
    Figure 4: Packet Properties and Flow Properties templates for
    PSAMP export
 
 3.5 IPFIX and IDMEF
 
    The Intrusion Detection Message Exchange Format (IDMEF) [CuDF04]
    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.
    Generally, alerts are sent when analyzers detect an event that
    they have been configured to look for.
    The IPFIX protocol can be used complementarily to IDMEF for
    providing detailed information of intrusions traffic, suspect
    events or anomalous traffic that differs from normal network
    behavior.
 
 4. IPFIX and Ipv6
 
 5. Where not to use IPFIX
 
    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 flow data in many applications, it still has
    limitations.
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 17]
 

                      IPFIX Applicability
 
 
 
 
 6. Security Considerations
 
    This document describes the usage of IPFIX in various scenarios.
    The security requirements for the IPFIX target applications are
    addressed in the IPFIX requirements draft. These requirements
    must 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 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 maintained.
 
 7. Normative References
 
    [QuZC03] J. Quittek ,et. al "Requirements for IP Flow
             Information Export ", Request for Comments: RFC 3917,
             October 2004
 
 8. Informative References
 
    [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of
             Internet Traffic Engineering", (work in progress),
             Internet Draft, Internet Engineering Task Force, draft-
             ietf-tewg-principles-02.txt, May 2002
 
    [Brow00] Nevil Brownlee: Packet Matching for NeTraMet
             Distributions,http://www2.auckland.ac.nz/net//Internet/r
             tfm/meetings/47-adelaide/pp-dist/
 
    [CuDF04] D.Curry, H. Debar, H. Feinstein: ææThe Intrusion
             Detection Message Exchange FormatÆÆ,(work in progress),
             Internet Draft, Internet Engineering Task Force, <draft-
             ietf-idwg-idmef-xml-11.txt>, January 2004
 
    [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
 
 
 
 
 
 
                        Expires April 2005              [Page 18]
 

                      IPFIX Applicability
 
 
 
 
             on the Internet, INET'98, Geneva, Switzerland,  21-24
             July, 1998
 
    [PSAMP-FRAMEWORK] N. Duffield, D. Chiou, B. Claise, A. Greenber,
             M. Grossglauser "A Framework for Passive Packet
             Measurement" (work in progress), Internet draft <draft-
             ietf-psamp-framework-04.txt>,
 
    [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
 
    [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
             Spence, "Generic AAA Architecture", RFC 2903, August
             2000
 
    [RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation
             Metric for IPPM, RFC 3393, November 200
 
    [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
 
 
 9. Acknowledgements
 
    We would like to thank the following persons for their
    contribution, discussion on the mailing list and valuable
    comments:
 
    - Sebastian Zander
    - Robert Loewe
 
    Part of the work has been developed in the research project 6QM
    co-funded with support from the European Commission.
 
 10.Author's Addresses
 
    Tanja Zseby
 
 
 
 
 
 
                        Expires April 2005              [Page 19]
 

                      IPFIX Applicability
 
 
 
 
    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
 
    Reinaldo Penno
    Nortel Networks, Inc.
    2305 Mission College Boulevard
    Building SC9-B1240, Santa Clara, CA 95134
    Email: rpenno@nortelnetworks.com
 
    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
    Belgium
    Phone: +32 2 704 5622
    Email: bclaise@cisco.com
 
 
 
 
 
 
 
 11. Copyright Statement
 
    Copyright (C) The Internet Society (2004). 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.
 
 
 
 
 
 
 
                        Expires April 2005              [Page 20]
 

                      IPFIX Applicability
 
 
 
 
 12. 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-
    protocol.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.
 
    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.
 
 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.
 
 
 
 
 
 
 
 
 
 
 
 
                        Expires April 2005              [Page 21]
 

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/