Subject: [ipfix-as] new version of applicability draft

From: Tanja Zseby <[email-masked]>
Date: Mon, 12 Jul 2004 14:47:37 +0200

Hi all,

we submitted a new version of the applicability draft (attached). It 
contains only minor changes, some more text on intrusion detection and a 
section on IPFIX and IDMEF (Intrusion Detection Message Exchange Format).

Regards,
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: [email-masked]	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

 Internet Draft                                              Tanja Zseby 
 Document: <draft-ietf-ipfix-as-02.txt>                     Elisa Boschi 
 Expires:  January 2005                                 Fraunhofer FOKUS 
                                                          Reinaldo Penno 
                                                         Nortel Networks 
                                                          Nevil Brownlee 
                                                                   CAIDA 
                                                           Benoit Claise 
                                                           Cisco Systems 
                                                                         
                                                               July 2004 

                           IPFIX Applicability 
                        draft-ietf-ipfix-as-02.txt 
  
    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 
    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. 
  
    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 January 2005              [Page 1] 
                      IPFIX Applicability               July 2004 

 Table of Contents 
    1.   Introduction.............................................2 
    2.   Applications of IPFIX....................................2 
    2.1  Accounting...............................................3 
    2.2  Security Analysis and Intrusion detection with IPFIX.....3 
    2.3  Network Planning.........................................4 
    2.4  Peering Agreements.......................................5 
    2.5  Traffic Engineering......................................5 
    2.6  Data Warehousing and Mining..............................5 
    2.7  SLA validation...........................................5 
    2.8  Traffic Monitoring.......................................5 
    2.8.1 Measurement of Round-trip-time (RTT)....................6 
    2.8.2 Measurement of One-way-delay (OWD)......................7 
    2.8.3 Measurement of One-way-loss (OWL).......................7 
    2.8.4 Measurement of IP delay variation (IPDV)................8 
    3.   Relation of IPFIX to other frameworks and protocols......8 
    3.1  IPFIX and AAA............................................8 
    3.1.1 Connecting via an AAA Client............................8 
    3.1.2 Connecting via an Application Specific Module (ASM).....9 
    3.2  IPFIX and RTFM..........................................10 
    3.2.1 Definition of 'flow'...................................10 
    3.2.2 Configuration and Management...........................11 
    3.2.3 Data Model details.....................................12 
    3.2.4 Application/transport protocol.........................13 
    3.3  IPFIX and IPPM..........................................13 
    3.4  IPFIX and IDMEF.........................................14 
    4.   Security Consideration..................................14 
    5.   References..............................................14 
    6.   Acknowledgements........................................16 
    7.   Author's Addresses......................................16 
    8.   Full Copyright Statement................................17 
     
 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 
    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.  

                        Expires January 2005              [Page 2] 
                      IPFIX Applicability               July 2004 

 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 portnumbers. 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 a AAA 
    infrastructure. AAA servers then could provide the mapping 
    between user and flow information. 
  
 2.2 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: 

                        Expires January 2005              [Page 3] 
                      IPFIX Applicability               July 2004 

    _ - 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. 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 provides useful input data for basic intrusion detection 
    functions (e.g. detecting unusual 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 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 a 
    preprocessing 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 
    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. 

                        Expires January 2005              [Page 4] 
                      IPFIX Applicability               July 2004 

 2.4 Peering Agreements 
     
    IPFIX data enables ISP peering partners to measure the volume 
    and characteristics of traffic exchanged with other ISP peers. 
    Different domains often have different tools. In order to 
    achieve interoperability in such heterogeneous environment, it 
    becomes necessary to have a common format to share measurement 
    data. IPFIX provides the format through which data can be 
    exchanged and consequently compared, between different ISPs. 
    This makes also possible to provide End-to-End (E2E) 
    measurements spanning multiple domains. 
     
 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 
     
    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 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 

                        Expires January 2005              [Page 5] 
                      IPFIX Applicability               July 2004 

    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 currently 
    the necessary information such as e.g. round-trip-time, packet 
    IDs etc. is 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 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. 
    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 network stack of the receiver. In case the 
    reply packet is lost or can not be observed the RTT can not be 
    calculated. 
     
    In order to use this measurement technique, the IPFIX metering 
    process needs to measure 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 

                        Expires January 2005              [Page 6] 
                      IPFIX Applicability               July 2004 

    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 
    [MaPZ03]. 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) only 
    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 
    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).  

                        Expires January 2005              [Page 7] 
                      IPFIX Applicability               July 2004 

    The one-way loss metric is defined in [RFC2680]. 
     
 2.8.4Measurement 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 
    exchange of accounting records between domains with DIAMETER. 
    Two possibilities to connect IPFIX and AAA can be distinguished:  
     
 3.1.1Connecting 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). 

                        Expires January 2005              [Page 8] 
                      IPFIX Applicability               July 2004 

           +---------+  DIAMETER    +---------+ 
           |  AAA-S  |------------->|  AAA-S  | 
           +---------+              +---------+ 
                ^ 
                | DIAMETER 
                | 
                | 
         +--+--------+--+ 
         |  |  AAA-C |  | 
         +  +--------+  | 
         |              | 
         |  Collector   | 
         +--------------+   
                ^ 
                | IPFIX 
                | 
          +------------+ 
          |  Exporter  | 
          +------------+    
     
    Figure 2: IPFIX collector connects to AAA server via AAA client  
     
 3.1.2Connecting 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 January 2005              [Page 9] 
                      IPFIX Applicability               July 2004 

           +---------+  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.1Definition 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 stage 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 January 2005              [Page 10] 
                      IPFIX Applicability               July 2004 

    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.2Configuration 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 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 
    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 January 2005              [Page 11] 
                      IPFIX Applicability               July 2004 

    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.3Data Model details 
     
 3.2.3.1  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 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 January 2005              [Page 12] 
                      IPFIX Applicability               July 2004 

    'most important' flows, perhaps we need to consider this for 
    IPFIX.   
     
 3.2.4Application/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. 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 section 2.7). 

                        Expires January 2005              [Page 13] 
                      IPFIX Applicability               July 2004 

 3.4 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 the normal network 
    behavior. 
     
 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. 
     
    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. 
     
 5. 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  

                        Expires January 2005              [Page 14] 
                      IPFIX Applicability               July 2004 

    [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 
             on the Internet, INET'98, Geneva, Switzerland,  21-24 
             July, 1998 
     
    [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 
  
    [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 
  
    [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 

                        Expires January 2005              [Page 15] 
                      IPFIX Applicability               July 2004 

             Measurements, Proceedings of Passive and Active 
             Measurement Workshop (PAM 2001), Amsterdam, The 
             Netherlands, April 23-24, 2001  

 6. 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.   

 7. 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: [email-masked] 
     
    Elisa Boschi 
    Fraunhofer Institute for Open Communication Systems (FOKUS)  
    Kaiserin-Augusta-Allee 31   
    10589 Berlin, Germany   
    Phone: +49 30 3463 7366   
    Email: [email-masked] 
     
    Reinaldo Penno 
    Nortel Networks, Inc.  
    2305 Mission College Boulevard 
    Building SC9-B1240, Santa Clara, CA 95134 
    Email: [email-masked]  
     
    Nevil Brownlee 
    CAIDA (UCSD/SDSC) 
    9500 Gilman Drive 
    La Jolla, CA 92093-0505 
    Phone : +1 858 534 8338 
    Email : [email-masked] 
  
    Benoit Claise 

                        Expires January 2005              [Page 16] 
                      IPFIX Applicability               July 2004 

    Cisco Systems 
    De Kleetlaan 6a b1 
    1831 Diegem 
    Belgium 
    Phone: +32 2 704 5622 
    Email: [email-masked] 
     
 8. 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 January 2005              [Page 17]

---

From: Robert Lowe <[email-masked]>
Date: Mon, 12 Jul 2004 12:01:46 -0500

Tanja Zseby wrote:

Hi Tanja,

> section on IPFIX and IDMEF (Intrusion Detection Message Exchange Format).

I imported the text into Word to make it easier to spot my suggestions/
changes, and have attached the result.  If there's another approach you'd
rather have me use, just let me know.

Under section 3, the relationship of IPFIX to other frameworks and protocols,
gave me the most pause.  With the exception of section 3.1 on AAA, very, very
little was said about IPFIX and how it might complement or integrate, making
the text not much more than a description of existing frameworks.  I'm not
sure what to make of that, particularily the long section on RTFM.  The
'perhaps we ought to include this in IPFIX' issue(s) need to be addressed, or
removed.  Hopefully I've helped a bit...

-Robert

---

From: Simon Leinen <[email-masked]>
Date: Mon, 12 Jul 2004 21:47:46 +0200

Robert Lowe writes:
> I imported the text into Word to make it easier to spot my
> suggestions/ changes, and have attached the result.  If there's
> another approach you'd rather have me use, just let me know.

If I may comment, there are two approaches that I personally prefer to
posting a complete copy with marked changes (in a proprietary format )-:

1.) Copy those sections that you suggest to change, along with your
    modified versions, into an e-mail message.

This is the preferred approach, because it lends itself best to
follow-on discussion.

2.) Make changes in the plain-ASCII draft, then use the "htmlwdiff"
    tool to generate visual diffs from the original version, put the
    output on a Web server and send a link to the mailing list.

Htmlwdiff is a simple shell script that front-ends the GNU wdiff
command.  For an example of its output, see
http://www.switch.ch/misc/leinen/ietf/ipfix/draft-leinen-ipfix-eval-contrib-02-03-diff.html

I don't know where the canonical source is, so I'm attaching my
slightly modified copy of `htmlwdiff'.  I believe the original author
is Bill Fenner.
-- 
Simon.

---

From: Tanja Zseby <[email-masked]>
Date: Tue, 13 Jul 2004 14:32:50 +0200

Hi Robert,

thanks for the comments. We will include them in the next version.
Will you attend the next IETF ?  Then we could discuss open issues in 
San Diego.

Regards
Tanja

Robert Lowe wrote:

>> contains only minor changes, some more text on intrusion detection 
>> and a section on IPFIX and IDMEF (Intrusion Detection Message 
>> Exchange Format).
>
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/