Internet Draft                                              Tanja Zseby
 Document: <draft-ietf-ipfix-as-00.txt>                 Fraunhofer FOKUS
 Expires: December 2003                                   Reinaldo Penno
                                                         Nortel Networks
                                                          Nevil Brownlee
                                                           Benoit Claise
                                                           Cisco Systems
                                                               June 2003
                           IPFIX Applicability
    Status of this Memo
    This document is an Internet-Draft and is in full conformance
    with all provisions of Section 10 of RFC2026.
    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
    This document describes how various applications can use the IP
    Flow Information Export (IPFIX) protocol. It furthermore shows
    how the IPFIX framework relates to other architectures and
                         Expires December 2003                [Page 1]

                          IPFIX Applicability                June 2003
 Table of Contents
    1.   Introduction................................................3
    2.   Applications of IPFIX.......................................3
    2.1  Accounting..................................................3
    2.2  Peering Agreements..........................................4
    2.3  Traffic Engineering.........................................4
    2.4  Data Warehousing and Mining.................................4
    2.5  Network Monitoring..........................................4
    2.5.1 Application Monitoring and Profiling.......................5
    2.5.2 User Monitoring and Profiling..............................5
    2.5.3 QoS Monitoring.............................................5
    2.5.4 Measurement of delay variation with IPFIX..................6
    2.5.5 Sampling for QoS Monitoring................................6
    3.   Relation of IPFIX to other frameworks and protocols.........7
    3.1  IPFIX and AAA...............................................7
    3.1.1 Connecting via an AAA Client...............................7
    3.1.2 Connecting via an Application Specific Module (ASM)........7
    3.2  IPFIX and RTFM..............................................8
    3.2.1 Definition of 'flow'.......................................8
    3.2.2 Configuration and Management...............................8
    3.2.3 Data Model details.........................................9
    3.2.4 Application/transport protocol.............................10
    3.3  IPFIX Considerations for Middleboxes........................10
    3.3.1 Firewall...................................................11
    3.3.2 Network Address Translation................................11
    3.3.3 Traffic Conditioners.......................................12
    3.3.4 Tunneling..................................................13
    3.3.5 VPNs.......................................................13
    4.   Security Consideration......................................15
    5.   References..................................................15
                          Expires December 2003                [Page 2]

                          IPFIX Applicability                June 2003
 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 input for various applications. This
    document describes how applications can use the IPFIX protocol.
    Furthermore, the relationship of IPFIX to other frameworks and
    architectures are 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 provides
    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.
    The essential elements needed for this are the number of
    transferred packets and bytes per flow. IPFIX flow records
    contain this information together with the flow identification.
    With this the essential input for usage-based accounting is
    provided by IPFIX.
    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. Accounting in such a scenario can be realized for
    instance with a flow definition determined by the quintuple that
    consists of source address, destination address, protocol and
    portnumbers. Another example is a class-dependent tariff (e.g.
    in a DiffServ networks). For this flows could be distinguished
    just by DiffServ codepoint (DSCP) and source address.
    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 a AAA
    infrastructure. AAA servers then could provide the mapping
    between user and flow information.
    Security Analysis and Intrusion detection with IPFIX
    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)
                          Expires December 2003                [Page 3]

                          IPFIX Applicability                June 2003
    _ - collects data from sensors (with one or more event
    _ - stores data from sensors (in a database)
    With IPFIX, events of interest can be reported to the sensor
    either by the collecting process or directly by the exporting
    process. It depends on the scenario and the events of interest
    which solution is better. 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 about what is going on in the network.
    IPFIX can provide useful input data for basic intrusion
    detection functions (e.g. detecting unusual high loads). IPFIX
    data provides details on source and destination addresses, along
    with the start time of flows and application ports. This data
    can be used to analyze network security and identify
    attacks. Nevertheless, for some scenarios intrusion detection
    may require further insight into packet content. In other
    scenarios, a preprocessing of data already at the measurement
    device is desirable. IPFIX allows a flexible report definition.
    Therefore, extensions to the metering process and the IPFIX
    report format could improve the IPFIX support for intrusion
    detection systems.
    Network Planning
    IPFIX data 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. 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.2     Peering Agreements
    IPFIX data enables ISP peering partners to measure the volume
    and characteristics of traffic exchanged with other ISP peers.
 2.3     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.4     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
 2.5     Network Monitoring
     IPFIX data enables extensive near real-time network monitoring
     capabilities. IPFIX data analysis can be used to display traffic
                          Expires December 2003                [Page 4]

                          IPFIX Applicability                June 2003
     patterns associated with routing devices and switches on an
     individual or network wide basis. This can display traffic or
     application-based views and therefore provide proactive problem
     detection, efficient troubleshooting, and rapid problem
 2.5.1   Application Monitoring and Profiling
     IPFIX data enables content and service providers to view
     detailed, time-based, and application-based usage of a network.
     This information allows planning and allocation of network and
     application resources (such as Web server, gaming or
 2.5.2   User Monitoring and Profiling
    IPFIX data provides a detailed understanding of 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.
 2.5.3   QoS Monitoring
    The performance of QoS monitoring is one target application for
    using 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 need to be synchronized. Furthermore, such
    measurements would benefit from post-processing functions (e.g.
    packet ID generation) at the exporter and/or collector. This
    section describes how the monitoring of different metrics can be
    performed with IPFIX. The following metrics are considered:
    round trip time, one-way-delay, loss and delay variation. 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 like 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. In order
    to use this measurement technique, the IPFIX metering process
    needs to measure 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. Measurement of One-way-delay (OWD)
                          Expires December 2003                [Page 5]

                          IPFIX Applicability                June 2003
    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 of the content e.g. by
    using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. Since
    IPFIX is not targeted at packet capturing these functionalities,
    do not need to be supported by a standard IPFIX meter.
    Nevertheless, in some scenarios it might be sufficient to
    calculate a packet ID under consideration of 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 can
    be a sufficient solution.
    The second issue here is the transfer of packet IDs. IPFIX
    transfers per flow information. Since the flow definition is
    very flexible, one could define flows that consist only of one
    packet and with this allow the transfer of per packet
    information. Nevertheless, this approach would be very
    inefficient, since flow records also contain further
    information. A more efficient scheme could be defined by
    modifying the flow record format and provide templates
    especially for that purpose.
    Measurement of Loss
    Passive loss measurements for single flows can be performed at
    one measurement point by using sequence numbers that are present
    in higher layer protocols. 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 above and just consider
    packets as lost that do not arrive at the second measurement
    point in a given maximum time frame.
 2.5.4   Measurement of delay variation with IPFIX
    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.5.5   Sampling for QoS Monitoring
    Since QoS monitoring can produce an overwhelming amount of
    measurement data, methods such as aggregation of results, and
    sampling would greatly increase the efficiency of the collection
    and analysis process. Sampling methods can be grouped according
    to the sampling strategy (systematic, random or stratified) and
    the trigger that starts a sampling interval (count-based, time-
    based or packet-content-based) [ClPB93]. Sampling can also be
    used as a method to dynamically reduce resource consumption if
    the meter is overloaded. Then the IPFIX meter can switch to a
    sampling method if too many packets have to be observed. Since
    the expected estimation error heavily depends on the deployed
    sampling strategy, the application that receives the data needs
    to be aware of the sampling scheme and the parameters in use.
    Therefore, it is important that the IPFIX exporter informs the
    collector precisely about the used sampling strategy. This is
    especially important if the metering process dynamically invokes
    sampling. The configuration and reporting of sampling methods is
    addressed in the PSAMP group.
                          Expires December 2003                [Page 6]

                          IPFIX Applicability                June 2003
 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
    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 to connect 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).
           +---------+  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
                          Expires December 2003                [Page 7]

                          IPFIX Applicability                June 2003
 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.
           +---------+  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
    At the simplest level, a flow information exporter may achieve
    this by maintaining two unidirectional flows, one for each
    direcion.  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 stage further, by
    including in the RTFM architecture [RFC 2722] a fully-detailed
    algorithm for realtime 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 direction),
    and to allow for attributes which required fine detail for the
    two directions, e.g. short-term bit rate distributions [RFC
    ** So far there has been no suggestion that IPFIX should do
 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.
                          Expires December 2003                [Page 8]

                          IPFIX Applicability                June 2003
     - Meter Readers are very similar to IPFIX collectors.
     - Managers co-ordinate 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
    consective 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
    The details of how the manager communicates this information to
    meters and meter readers is 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.
    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
 3.2.3   Data Model details  Count in one bucket
    Within a ruleset, a packet may only be counted on 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 aggreation 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
    The 'count in one bucket' rule, together with the ability to run
    multiple rulesets, has proved very simple and effective in
    practice.  Counter wrapping
                          Expires December 2003                [Page 9]

                          IPFIX Applicability                June 2003
    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.  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 Arcitecture [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
    RTFM makes no provision for flow sampling.  Recently there has
    been a lot of interest in flow sampling schemes which favour the
    'most important' flows, perhaps we need to consider this for
 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
    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
    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.  Simlarly, many
    NeTraMet user run the meter and meter reader on the same host
    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 Considerations for Middleboxes
    A Middlebox is a network intermediate device that implements one
    or more of the middlebox services. Policy based packet filtering
    (a.k.a. firewall), Network address translation (NAT), Intrusion
                          Expires December 2003               [Page 10]

                          IPFIX Applicability                June 2003
    detection, Load balancing, Policy based tunneling and IPsec
    security are all examples of a middlebox function (or service).
    [MCFW]. For instance, a NAT middlebox is a middlebox
    implementing NAT service and a firewall middlebox is a middlebox
    implementing firewall service. It is expected that the exporter
    in the IPFIX architecture will probably implement some form of
    middlebox service given its ubiquity today. Since some of these
    middlebox services might affect flow exportation and how the
    collector interprets them, there is a need to provide an
    analysis of these implications in relation to the IPFIX
    architecture and a set of recommendations. The following
    sections provide a non-exhaustive analysis of middlebox
    services, its implications on the IPFIX architecture and a
    corresponding set of recommendations.
 3.3.1   Firewall
    Firewall is a policy based packet filtering middlebox function,
    typically used for restricting access to/from specific devices
    and applications. The policies are often termed Access Control
    Lists (ACLs)[MCFW].  The firewall middlebox service allows the
    exporter to explicitly drop packets based on some administrative
    policy. In this case, the exporter can take one of the following
    actions that will have a direct impact on the information
    provided by the collector to the user.
    * Silently Discard
    In this case the packet is discarded and no flow information
    record is sent to the collector.
    * Discard and export flow
    In this case the packet is discarded, and the flow information
    record is sent to the collector.
    * Discard and export flow with discard notification
    In this case the packet is discarded, and the flow information
    record is sent to the collector with an indication that the
    packet was discarded.
 3.3.2   Network Address Translation
    Network Address Translation is a method by which IP addresses
    are mapped from one address realm to another, providing
    transparent routing to end hosts. Transparent routing here
    refers to modifying end-node addresses en-route and maintaining
    state for these updates so that when a datagram leaves one realm
    and enters another, datagrams pertaining to a session are
    forwarded to the right end-host in either realm [NAT-TERM].
    >From an exporter (middlebox) perspective, a NAT is composed of
    two flows, one from the client to the NAT middlebox and another
    from the NAT middlebox to the destination. Based on this fact,
    the exporter has several modes of operation, i.e., it can export
    the private realm flow, the public realm, or both. This is
    further constrained by the flavor of NAT implemented, meaning
    that in order for the exported information to be useful for the
    collector, sometimes the associated flows on the two realms need
    to be exported in the same flow record. Although there are many
    flavors of address translation that lend themselves to different
    applications, this section will only address the IPFIX
    architecture implications of traditional NAT, bi-
    directional NAT and twice NAT.  Traditional NAT
                          Expires December 2003               [Page 11]

                          IPFIX Applicability                June 2003
    Traditional NAT would allow hosts within a private network to
    transparently access hosts in the external network, in most
    cases. In a traditional NAT, sessions are unidirectional,
    outbound from the private network. This is in contrast with bi-
    directional NAT, which permits sessions in both inbound and
    outbound directions. A detailed description of traditional NAT
    may be found in section [NAT-TERM].
    If the exporter is providing traditional NAT service and only
    the private realm flow is exported, only destination based
    information can be inferred from the collector. The reason for
    this is twofold. First, the collector will not be able to find
    the reverse flow (when applicable) associated with a private
    realm flow record, and second is that in the more general
    scenario the collector can be connected to several exporters
    providing NAT service and there might be overlapping private
    realm addresses between the networks connected to these
    In a traditional NAT scenario the exporter SHOULD export private
    and public realm information in the same flow record or provide
    the collector with a unique key to associate the two if exported
    on different flow records.  Bi-Directional NAT
    With a bi-directional NAT, sessions can be initiated from hosts
    in the public network as well as the private network. Private
    network addresses are bound to globally unique addresses,
    statically or dynamically as connections are established in
    either direction.  Detailed description of Bi-Directional may be
    found in section [NAT-
    TERM].  Twice NAT
    Twice NAT is a variation of NAT in that both the source and
    destination addresses are modified by NAT as a datagram crosses
    address realms. This is in contrast to Traditional-NAT and Bi-
    Directional NAT, where only one of the addresses (either source
    or destination) is translated. Note, there is no such term as
    NAT'. Detailed description of Bi-Directional may be found in
    section [NAT-TERM].
    In the case of twice NAT the exporter MUST export private and
    public realm information in the same flow record or provide the
    collector with a unique key to associate the two if exported on
    different flow records.
 3.3.3   Traffic Conditioners
    A traffic conditioner may contain the following elements: meter,
    marker, shaper, and dropper.  A traffic stream is selected by a
    classifier, which steers the packets to a logical instance of a
    traffic conditioner[DIFF-ARCH].
    From an IPFIX architecture perspective we are going to address
    marking, shaping and dropping services.
    Diffserv packet markers set the DS field of a packet to a
    particular codepoint, adding the marked packet to a particular
    DS behavior aggregate.  The marker may be configured to mark all
    packets which are steered to it to a single codepoint, or may be
    configured to mark a packet to one of a set of codepoints used
    to select a PHB in a PHB group, according to the state of a
                          Expires December 2003               [Page 12]

                          IPFIX Applicability                June 2003
    meter.  When the marker changes the codepoint in a packet it is
    said to have "re-marked" the packet [DIFF-ARCH].
    From and IPFIX architecture perspective, the exporter can take
    one of the following actions when it needs to remark a packet.
    * Unmarked flow
    The exporter can export the flow before it was remarked. This
    mode of operation is strongly discouraged.
    * Remarked flow
    The exporter can export the flow after it was remarked.
    * Unmarked and remarked flow.
    The exporter can export the flow before and after it was
    remarked or export the flow before it was remarked and an
    indication of what was the DSCP after it was remarked.  Shapers
    Shapers delay some or all of the packets in a traffic stream in
    Order to bring the stream into compliance with a traffic
    profile.  A shaper usually has a finite-size buffer, and packets
    may be discarded if there is not sufficient buffer space to hold
    the delayed packets.
    For an IPFIX perspective, since the discard of a packet by a
    shaper is not voluntary, no indication should be sent to the
    collector.  Droppers
    Droppers discard some or all of the packets in a traffic stream
    in order to bring the stream into compliance with a traffic
    profile. This process is known as "policing" the stream.  Note
    that a dropper can be implemented as a special case of a shaper
    by setting the shaper buffer size to zero (or a few) packets.
    In a manner analogous to the middlebox firewall service,
    middlebox policing services also allow the exporter to
    explicitly drop packets based on some administrative policy.
    The three possible export behaviors described for the firewall
    service when a packet needs to be dropped are also applicable to
    here, i.e., silent discard, discard and export flow, discard and
    export flow with discard notification.
 3.3.4   Tunneling
    The exporter can export the flows before and/or after they get
    tunneled. In the later case the encapsulated flow information
    might not be available due to confidentiality precautions such
    as those used by IPsec, or due to the fact the exporter lacks
    the necessary intelligence to inspect the encapsulated packet.
    Moreover, depending on where in the network the exporter is
    located, it might only be able to export flows associated with
    the tunnel, without visibility into the encapsulated packet.
    Apart from what was said above, it should also be factored in
    the fact that flows exported before they get tunneled, will
    provide information about the private network sites, but not
    necessarily about the backbone, since the route taken by the
    packet it's now know at that point in time (and vice-versa).
 3.3.5   VPNs
                          Expires December 2003               [Page 13]

                          IPFIX Applicability                June 2003
    The term "Virtual Private Network" (VPN) refers to the
    communication between a set of sites, making use of a shared
    network  infrastructure.  Multiple sites of a private network
    may therefore communicate via the public infrastructure, in
    order to facilitate the operation of the private network.  The
    logical structure of the VPN, such as addressing, topology,
    connectivity, reachability, and access control, is equivalent to
    part of or all of a conventional private network using private
    facilities [RFC2764] [VPN-2547BIS].
    There are multiple flavors of VPNs, the one with more relevance
    to the IPFIX architecture is the PE-based-VPN. A PE-based VPN
    (or Provider Edge-based Virtual Private Network) is one in which
    PE devices in the SP network provide the VPN.  This allows the
    existence of the VPN to be hidden from the CE devices, which can
    operate as if part of a normal customer network. A detailed
    discussion of VPNs can be found in [PPVPN-FR].  Layer 3 PE-based VPN
    A layer 3 PE-based VPN is one in which the SP takes part in IP
    level forwarding based on the customer network's IP address
    space.  In general, the customer network is likely to make use
    of private and/or non-unique IP addresses.  This implies that at
    least some devices in the provider network needs to understand
    the IP address space as used in the customer network.  Typically
    this knowledge is limited to the PE device [PPVPN-FR] which is
    directly attached to the customer.
    In a layer 3 PE-based VPN the provider will need to participate
    in some aspects of management and provisioning of the VPNs, such
    as ensuring that the PE devices are configured to support the
    correct VPNs.  This implies that layer 3 PE-based VPNs are by
    definition provider provisioned VPNs [PPVPN-FR].
    In order to connect the different VPN sites belonging to the
    same VPN the SP uses a tunneling technique such as MPLS, L2TP or
    IPsec. These tunnels originate and terminate on PE devices.
    One of the characteristics of a layer 3 PE-based VPNs is that
    they offload some aspects of VPN management from the customer
    network. From an IPFIX architecture perspective, this means that
    the SP is the one that potentially will be providing the IPFIX
    service for the VPNs that it provides connectivity.
    The exporter in Layer 3 PE-based VPN can be located on the
    customer's network, on the SP's backbone (P Router) or on the
    edge (PE router). The premise of this discussion is that the
    exporter is the one providing middlebox services, so in the case
    of VPNs we assume that the exporter is located in a PE device.
    Overlapping Address Realms
    In the case the exporter plays the role of a PE router [VPN-
    2547BIS] in a provider provisioned VPN scenario and has VPNs
    with overlapping private address realms, it can only provide
    useful non-conflicting information to the provider for intra-VPN
    traffic if it uses a technique that allows the collector to
    uniquely identify to which VPN the flow belongs.
    Several techniques could be used to accomplish this goal. One of
    these techniques is to include the VPN Global unique identifier
    [VPN-ID] as one of the keys in the flow record.
    In the case the exporter supports VPNs with overlapping private
    address realms, it MUST include the VPN-ID [VPN-ID] in the
    exported flow record.
                          Expires December 2003               [Page 14]

                          IPFIX Applicability                June 2003  Layer 2 PE-based VPN [TBD]
    A layer 2 PE-based VPN is one in which the network is aware of
    the VPN, but does only layer 2 forwarding and signaling.  This
    implies that the SP provisions and maintains layer 2
    connectivity between CE devices [VPN-L2].
    Forwarding options include MAC addresses (such as LAN
    emulation), use of point-to-point link layer connections (FR or
    ATM), multipoint-to-point (using MPLS multipoint to point LSPs),
    and point-to-multipoint (e.g., ATM VCCs).
    For a layer 2 PE-based VPN, the PE device may be a router, LSR,
    or IP switch.  From the CE's perspective, the PE will be
    operating as a switch.
 4. Security Consideration
    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.
    The second section 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.
 5. References
    [QuZC03] J. Quittek ,et. Al "Requirements for IP Flow
    Information Export ", (work in progress) ,Internet Draft,
    Internet Engineering Task Force, <draft-ietf-ipfix-reqs-10.txt>,
    June 2003
    [Wood02] M. Wood ,et al.," Intrusion Detection Message Exchange
    Requirements",(work in progress), Internet Draft, Internet
    Engineering Task Force, draft-ietf-idwg-requirements-06,
    February 2002.
    [MaPZ03] L. Mark, G. Pohl, T. Zseby, K. Sugauchi: Passive One-
    way Delay Measurements, (work in progress), Internet Draft
    <draft-mark-powd-00.txt>, June 2003
    [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
    [RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation
    Metric for IPPM, RFC 3393, November 2002
    [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
    Loss Metric for IPPM, September 1999
    [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun:
    Application of Sampling Methodologies to Network Traffic
                          Expires December 2003               [Page 15]

                          IPFIX Applicability                June 2003
    Characterization, Proceedings of ACM SIGCOMM'93, San Francisco,
    CA, USA, September 13 - 17, 1993
    [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed
    MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement
    of Unidirectional Delay and Delay Variation on the Internet,
    INET'98, Geneva, Switzerland,  21-24 July, 1998
    [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory
    Sampling for Direct Traffic Observation", Proceedings of ACM
    SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
    [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
    Metric for IPPM, Request for Comments: 2679, September 1999
    [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
    [MCFW] Srisuresh, S. et al.  "Middlebox Communication
    Architecture and framework," work in progress.  October 2001.
    [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
    Translator (NAT) Terminology and Considerations", RFC 2663,
    August 1999.
    [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
    Address Translator (Traditional NAT)", RFC 3022, January  2001.
    [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for
    Provider Provisioned Virtual Private Networks ", work in
    progress, <draft-
    ietf-ppvpn-framework-03.txt>, January 2002.
    [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
    <draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.
    [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang,
    Z. and W. Weiss, "An Architecture for Differentiated Services",
    RFC 2475, December 1998.
    [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
    Spence, "Generic AAA Architecture", RFC 2903, August 2000
    7. Acknowledgements
    We would like to thank the following persons for their
    contribution, discussion on the mailing list and valuable
    Robert Loewe
    8. Author's Addresses
    Tanja Zseby
    Fraunhofer Institute for Open Communication Systems(FOKUS)
    Kaiserin-Augusta-Allee 31  10589 Berlin  Germany  Phone: +49 30
    3463 7153  Email:
    Reinaldo Penno
    Nortel Networks, Inc. 2305 Mission College Boulevard
    Building SC9-B1240  Santa Clara, CA 95134
    Nevil Brownlee
    9500 Gilman Drive
    La Jolla, CA 92093-0505
                          Expires December 2003               [Page 16]

                          IPFIX Applicability                June 2003
    Phone : +1 858 534 8338
    Email :
    Benoit Claise
    Cisco Systems
    De Kleetlaan 6a b1
    1831 Diegem
    Phone: +32 2 704 5622
    9. Full Copyright Statement
    "Copyright (C) The Internet Society (date). 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.
                          Expires December 2003               [Page 17]