Subject: [ipfix] LFAP Submission

From: [email-masked]
Date: Mon, 02 Sep 2002 10:54:02 -0400

Attached is the LFAP submission (sent to eval team yesterday).
Should be on the IETF web page shortly.

These are the relevant LFAP specifications...

http://www.ietf.org/internet-drafts/draft-riverstone-lfap-01.txt
http://www.ietf.org/internet-drafts/draft-riverstone-lfap-data-01.tx

 INTERNET-DRAFT            Expires: February 2003          INTERNET-DRAFT

 Internet Draft                                             Paul Calato
 Document: draft-ietf-ipfix-reqs-04.txt             Riverstone Networks
 Expires: January 2003                                      August 2002

           Evaluation Of Protocol LFAP Against IPFIX Requirements

                  <draft-advocate-ipfix-LFAP-eval-05.txt>

 Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of [RFC 2026]. 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

    Distribution of this document is unlimited.

 Copyright Notice

    Copyright (C) The Internet Society (2001). All Rights Reserved.

 Abstract

    This document provides an evaluation of the applicability of the
    LFAP protocol as an IPFIX protocol. It compares the properties and
    capabilities of the LFAP protocol to the IPFIX requirements version
    05 [IPFIX- REQ].

 Calato                     Informational                        [Page 1]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

                            Table of Contents

 1. INTRODUCTION ......................................................4
 2. ARCHITECTURAL CONSIDERATIONS ......................................5
   2.1 LFAP ARCHITECTURE HIGHLIGHTS ...................................6
    2.1.1. Flow Records ...............................................6
    2.1.2. Information Model ..........................................6
    2.1.3. Data Model .................................................6
    2.1.4. Scalability ................................................6
    2.1.5. Security ...................................................7
    2.1.6. Statistics .................................................7
    2.1.7. Protocol Maturity ..........................................7
   2.2 LFAP PROTOCOL OVERVIEW .........................................8
    2.2.1. LFAP Flow Ids ..............................................9
    2.2.2. Periodic reporting versus singular reporting ...............9
    2.2.3. Protocol Example ..........................................10
   2.3 GENERAL APPLICABILITY .........................................11
    2.3.1. Requirements Section 2.1 IP Traffic Flow ..................11
    2.3.2. Requirements Section 2.2 Observation Point ................11
    2.3.3. Requirements Section 2.3 Metering .........................11
    2.3.4. Requirements Section 2.5 Exporting Process ................11
    2.3.5. Requirements Section 2.4 Flow Record ......................13
    2.3.6. Requirements Section 2.6 Collecting Process ...............13
   2.4 ARCHITECTURAL DIFFERENCES .....................................14
 3. ITEM LEVEL COMPLIANCE EVALUATION .................................14
   3.1 EXTENDING LFAP ................................................14
    3.1.1. Vendor Specific ...........................................15
    3.1.2. Information Element Extension .............................15
    3.1.3. AR/ARA Message Extension ..................................15
    3.1.4. MIB Extensions ............................................15
   3.2 REQUIREMENTS SECTION 4 DISTINGUISHING FLOWS ...................15
   3.3    REQUIREMENTS SECTION 5 METERING ............................16
    3.3.1. Requirements Section 5.1 Reliability ......................16
    3.3.2. Requirements Section 5.2 Sampling .........................16
    3.3.3. Requirements Section 5.3 Overload .........................16
    3.3.4. Requirements Section 5.4 Timestamps .......................17
    3.3.5. Requirements Section 5.5 Time Synchronization .............17
    3.3.6. Requirements Section 5.6 Flow Expiration ..................17
    3.3.7. Requirements Section 5.7 Multicast ........................17
    3.3.8. Requirements Section 5.8 Ignore Port Copy .................18
    3.3.9. Requirements Section 6.1 Information Model ................18
    3.3.10. Templated Data ...........................................21
    3.3.11. Requirements Section 6.2 Data Model ......................21
    3.3.12. Requirements Section 6.3.1 Congestion Awareness ..........22
    3.3.13. Requirements Section 6.3.2 Reliability ...................22
    3.3.14. Requirements Section 6.3.3 Security ......................22

 Calato                         Informational                     [Page 2]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

    3.3.15. Requirements Section 6.4 Regular Reporting ...............22
    3.3.16. Requirements Section 6.5 Notification on Specific Events .23
    3.3.17. Requirements Section 6.6 Anonymization ...................23
    3.3.18. Requirements Section 7.1 Configuration of the Metering ...23
    5. Overload behavior .............................................23
    3.3.19. Requirements Section 7.2 Configuration of the Exporting ..23
    3.3.20. Requirements Section 8.1 Openness ........................24
    3.3.21. Requirements Section 8.2 Scalability Concerning the Number
    of Exporting Processes ...........................................24
    3.3.22. Requirements Section 8.3 Several Collecting Processes ....24
 4. SECURITY CONSIDERATIONS ..........................................24
   4.1 REQUIREMENTS SECTION 6.3.3 SECURITY ...........................24
   4.2 REQUIREMENTS SECTION 10.1 DISCLOSURE OF FLOW INFORMATION DATA .25
   4.3    REQUIREMENTS SECTION 10.2 FORGERY OF FLOW RECORDS ..........25
   4.4 REQUIREMENTS SECTION 10.3 DENIAL OF  ERVICE (D                                           S         OS) ATTACKS .....26
 5. REFERENCES .......................................................27
 6. AUTHOR'S ADDRESS .................................................27
 7. FULL COPYRIGHT STATEMENT .........................................27

 Calato                         Informational                     [Page 3]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 1. Introduction

    This document provides an evaluation of the applicability of the
    LFAP protocol as an IPFIX protocol. First, the general LFAP
    architecture is introduced and its application to the communication
    between an IPFIX exporting process and an IPFIX collecting process
    is discussed in Section 2. Section 3 discusses in detail, to which
    degree requirements stated in [IPFIX-REQ] are met.

    This document uses the terminology defined in [IPFIX-REQ].

    LFAP [1][2] was originally submitted to the IETF as RFC 2124 [3] in
    1997. Since then it has under gone a number of revisions. Revisions
    were submitted as Internet Drafts. The latest revision can be found
    at

    http://www.ietf.org/internet-drafts/draft-riverstone-lfap-01.txt
    http://www.ietf.org/internet-drafts/draft-riverstone-lfap-data-
    01.txt

    LFAP is completely unencumbered and is available for use by the
    internet community.

 Calato                         Informational                     [Page 4]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 2. Architectural Considerations

    This section introduces the architecture of the LFAP protocol and
    suggests a way of applying it to the communication between an IPFIX
    exporting process and an IPFIX collecting process.

    LFAP was developed specifically for IP flow accounting. As such it
    is well suited to support the communication between the Exporting
    Process and an IPFIX Collecting process.

    The basic architecture is depicted below:

                      +---------------------------+
                      |                           |
                      |                           |
                      |       Application         |
                      |                           |
                      +--//-----------------------+\
                       //                           \\
                     //                               \\
                   //                                   \\
               +--/--+                                 +--\--+
               |     |                                 |     |
               | C1  |                                 | C2  |
               +--|\-+                                 +-/+-\+
                 /| \\                                 // |  \
                /  |  \\                             //  |    \
              //   |    \\                         //    |     \
             /      |     \                       /      |     \
            /       |      \\                   //       |      \
           /         |       \\               //        |        \
       +--/--+    +--+--+   +--\--+       +--/--+    +--+--+   +--\--+
       |     |    |     |   |     |       |     |    |     |   |     |
       | ID1 |    | ID2 |   | ID3 |       | ID4 |    | ID5 |   | ID6 |
       +-----+    +-----+   +-----+       +-----+    +-----+   +-----+

    One Collecting process services multiple IPFIX Devices. Each IPFIX
    Device may have one or more backup Collectors. In case of failure,
    ID1 _ ID3 would also point to C2 and ID4 _ ID6 would point to C1.
    An application then retrieves the flow data from the Collecting
    devices. The LFAP protocol is used between the IPFIX Devices and
    Collecting process to exchange flow accounting data. See section
    2.3.4 of this document for a detailed view of an IPFIX device in
    both LFAP and IPFIX terms.

 Calato                         Informational                     [Page 5]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 2.1   LFAP Architecture Highlights

    This section provides an overview of the LFAP Architecture's
    highlights.

 2.1.1.   Flow Records

    LFAP splits flow records along the line of characteristic
    properties (e.g. source IP) as described in the requirements
    document section 2.4 Flow Record and measured properties (e.g.
    bytes) also described in section 2.4. This split allows lower
    memory requirements for the IPFIX Device. Since the characteristics
    properties are sent independent of measured characteristics, there
    is no need to store the characteristic properties until update
    time. This split also allows lower bandwidth consumption since only
    measured properties need to be reported with each update. See
    Section 2.2 of this document for a detailed example. If no split is
    desired information could be combined.

 2.1.2.   Information Model

    LFAP defines a very strong Information Model. Information Elements
    exchanged have a well defined meaning. LFAP itself defines very
    little in the way of new data elements. The majority of data is
    defined in such a way as to use the semantics and value range from
    the protocol being reported. For example, the Class of Service
    field is defined in terms of RFC 791 (see section 2.8 of the LFAP
    data specification [2]).

 2.1.3.   Data Model

    LFAP defines data precisely and uses a TLV format to encode
    transfer of information. Dense encoding is supported via a multi-
    record structure, which allows type and length to be provided once
    for all flows reported in the message. Semantic information still
    resides close by the data to minimize potential interpretation
    errors. The TLV format also allows extension, as unknown data
    elements can be easily skipped using the length field. Using a TLV
    format also makes debugging messages straightforward.

 2.1.4.   Scalability

    Since LFAP was designed for IP flow accounting, there is little in
    the way of non-IP-flow data being passed. Messages with Flow data
    are dense and compact. LFAP was also designed to minimize memory
    and CPU consumption on the device. Messages are simplified so that
    transfer of state information requirements is minimal. For example,
    on failover from one server to another, IP flows can continue send
    a flow's periodic updates to the new Collector with absolutely no
    extra work on the part of the IPFIX device. Also since flow data

 Calato                         Informational                     [Page 6]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

    merely needs to be encoded and sent, CPU usage is minimal.

 2.1.5.   Security

    The LFAP specification has a complete section on security. It also
    paves the way for field level security, which may reduce the CPU
    cycles needed to implement security features.

    LFAP provides multiple levels of security and it allows security to
    be handled externally (e.g. by the transport layer), via LFAP
    protocol itself or a combination. If LFAP itself is used,
    protection against any combination of these attacks are covered in
    the specification:

       1) Message altering
       2) Message replay
       3) Message Insertion
       4) Message reading (snooping)
       5) Impersonation of a CCE or FAS

 2.1.6.   Statistics

    LFAP defines a complete management plane for monitoring a running
    flow information exchange system. These statistics allow detection
    of problems and even provide a gauge on the extent of damage. For
    example, if there is loss of connectivity to the Collector for an
    extended period, a counter will indicate the number of bytes
    dropped (i.e. not counted) so the damage from loss of connectivity
    can be assessed. The protocol defines a base set of metric and
    operational state so that testing for interoperability is
    simplified.

 2.1.7.   Protocol Maturity

    LFAP was originally submitted to the IETF as RFC 2124 in 1997.
    Since then it has under gone a number of improvements. The basic
    model and design have been proven with time.

    LFAP also has working open source implementations /SDKkits freely
    available on http://www.nmops.org. The code base has been shipping
    in commercial products for several years. An LFAP API source kit is
    available from www.nmops.org. The kit can be used for building both
    client and server applications. The LFAP API was also ported to NT
    for use as a probe. LFAP servers are also freely available from
    www.nmops.org. XACCT Technologies distributes a commercial version
    of that LFAP server. lfapd written by Steven Premeau, used for
    Flowscan, is another open source server. InMon Corporation
    developed an LFAP server for use with its products. Clients and

 Calato                         Informational                     [Page 7]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

    Servers have been built on Solaris, Linux and NT.

    Lastly, over time LFAP has built up several debugging tools. The
    first is a client simulator for testing servers. The second is a
    server simulator for testing clients. Tests are written using ASCII
    files with test validation built in. A complete set of message
    dumping facilities are embedded in the LFAP API. Lastly, a load
    driver for performance testing is also available.

    The LFAP protocol is mature protocol specifically designed for the
    demands of IP accounting.

 2.2   LFAP Protocol Overview

    The LFAP message structure is relatively simple. The following
    diagram represents which messages each side of the LFAP protocol
    sends.

 ,----------------------------.         ,-----------------------------.
 |       Collector            |         |      IPFIX Device           |
 |                            |         |                             |
 `|---+--------|---|-----|----'         `---|---|------------|---+----'
  |   ^    ^   |   |   ^ |  ^               | ^ |    ^   ^   |   ^   ^
  |   |    |   |   |   | |  |               | | |    |   |   |   |   |
  |   |    |   |   |   | |  |      VR       | | |    |   |   |   |   |
  |   |    |   |   |   | |  `---------------' | |    |   |   |   |   |
  |   |    |   |   |   | |         VRA        | |    |   |   |   |   |
  |   |    |   |   |   | `--------------------' |    |   |   |   |   |
  |   |    |   |   |   |           CR           |    |   |   |   |   |
  |   |    |   |   |   `------------------------'    |   |   |   |   |
  |   |    |   |   |                                 |   |   |   |   |
  |   |    |   |   |          CAN/CRN/DR             |   |   |   |   |
  |   |    |   |   `---------------------------------'   |   |   |   |
  |   |    |   |                                         |   |   |   |
  |   |    |   |                  FER                    |   |   |   |
  |   |    |   `-----------------------------------------'   |   |   |
  |   |    |                                                 |   |   |
  |   |    |                    FAR/FUN                      |   |   |
  |   |    `-------------------------------------------------'   |   |
  |   |                                                          |   |
  |   |                         AR/ARA                           |   |
  |   `----------------------------------------------------------'   |
  |                                                                  |
  |                                KA                                |
  `------------------------------------------------------------------'

    LFAP consists of an initial handshake followed by flow export. The

 Calato                         Informational                     [Page 8]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

    handshake consists of the VR, VRA, CR, CAN/CRN/DR, AR, ARA and FER
    messages. Flow export consists of the FAR and FUN messages. The FAR
    indicates the start of a flow and contains all the requested data
    elements. The FUN provides periodic updates concerning bytes,
    packets and time. A state field in the FUN indicates the flow's
    termination.

    During the handshake the IPFIX device initiates a TCP connection to
    a Collector. Session establishment then happens in three phases
    following TCP connection establishment.

    In the first phase the LFAP version is exchanged and verified via
    the VR and VRA messages. In the second phase, the Collector allows
    or denies the connection via the CRN/CAN/DR messages. The third
    phase allows setup information to be exchanged via the AR and ARA
    messages, before flow export begins. For example, the list of
    Information Elements to be reported may be sent in this phase.
    Finally, the Collecting device sends the FER and flow export may
    begin. For more details see the state machine on session
    establishment in section 6.4 of the LFAP specification [1].

    The KA message allows the IPFIX device to quickly detect the loss
    of a Collector.

 2.2.1.   LFAP Flow Ids

    An LFAP Flow ID uniquely identifies a flow. It is used to correlate
    characteristic properties and all periodic updates.

 2.2.2.   Periodic reporting versus singular reporting

    With singular reporting, all characteristic properties and measured
    properties are reported at the same time. Each report is
    independent of other flow reports. LFAP Flow IDs in this case are
    not necessary.

    With periodic reporting, a flow is reported on more than once. Flow
    IDs are used to correlate multiple reports to the same flow.
    Periodic reporting is be more difficult because information can be
    dispersed plus possible Collector failures. LFAP has done a good
    job solving this problem with its Flow ID, message structure and
    failover design.

    If IPFIX WG determines that singular reporting must be supported
    the LFAP specification would need to be slightly modified to allow
    measured characteristics in the FAR message.

    LFAP is well positioned to handle the more complex case of periodic
    reporting in addition to the simpler singular reporting.

 Calato                         Informational                     [Page 9]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 2.2.3.   Protocol Example

    Assume F1 is a flow with a very narrow flow key, which is to be
    updated once per minute. Assume F2 is a flow with a very coarse
    flow key and is to be updated once every 15 minutes. For the sake
    of example, assume F1 uses cumulative bytes value and F2 uses delta
    byte values. For simplicity time calculations will not be shown,
    but are similar to processing for cumulative and delta byte
    calculations. The message structure and processing would be as
    follows.

    Time  Message             Processing

    ----  --------------      ----------------------------------------

    T1    FAR                 The first packet for F1 is seen at T1. A
                              FAR message is sent with the requested
                              characteristic properties at T1.

    T2    FAR                 The first packet for F2 is seen at T2. A
                              FAR message is sent with the requested
                              characteristic properties at T2

    T3    F1 FUN              T3 is time to update F1. Current
                              statistics S1 are retrieved.

                              Since the statistics are cumulative the
                              Collector uses S1 _ 0 (zero) to calculate
                              the statistics for this interval.

    T4    F1 FUN              T3 is time to update F1 again. Current
                              statistics S2 are retrieved.

                              Since the statistics are cumulative the
                              Collector uses S2 _ S1 to calculate the
                              statistics for this interval.

                              Several more updates for happen before F2
                              is updated

    T17   F2 FUN              T17 is time to update F2. Current delta
                              statistics DS1 are retrieved.

                              Since the statistics are in delta form
                              the Collector uses DS1 statistics for
                              this interval.

 Calato                         Informational                    [Page 10]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 2.3   General Applicability

 2.3.1.   Requirements Section 2.1 IP Traffic Flow

       LFAP is compatible with the flow definition described.

 2.3.2.   Requirements Section 2.2 Observation Point
 2.3.3.   Requirements Section 2.3 Metering
 2.3.4.   Requirements Section 2.5 Exporting Process

       These 3 items map to the Connection Control Entity (CCE) in the
       LFAP specifications. A detailed view of a CCE and how it maps to
       IPFIX is provided below.

 Calato                         Informational                    [Page 11]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 +--------------------------------------------------------------------+
 |                                      ^                             |
 |                                      | Send Message to Collector   |
 |         +----------+ Remove  +-------+------------+      +-------+ |
 |         | Msg Queue|<--------| LFAP Processing API|<-----+Timers | |
 |         +----------+         |                    |      +-------+ |
 |              ^               +--+------------+----+                |
 |              |                  |Lookup      |Flow Update          |
 |              |                  |            |     Exporting Process
 +---------------------------------|------------|---------------------+
 |              |                  v            |                     |
 |              |  +--------------------------+-|                     |
 |              |  |Flow ID -> Flow table key | |                     |
 |              |  +--------------------------- |                     |
 |              |      ^                        |                     |
 |              |      |                        |                     |
 |              | Add  |                        |                     |
 |         +----+------+---+                    |                     |
 |         | LFAP Flow API |Get stats           |                     |
 |         |               +-------------+      |                     |
 |         +---------------+             |      |                     |
 |              ^                        |      |                     |
 |              | Flow Start             |      |                     |
 |              | Flow End               |      |                     |
 |        +-----+---------+              |      |                     |
 |        | Flow Mgt      |              |      |                     |
 |  +-----> Flow Key      |              |      |                     |
 |  |     |      Forward* |------>Packet |      |                     |
 |  |     +---------------+              |      |                     |
 |  |           | Create - forward/filter|      |                     |
 |  |           | Delete                 |      |      Metering Process
 +--|-----------|------------------------|------|---------------------+
 |  |     +-----v--------------+         |      |                     |
 |  |     | Flow Table    Stats|<--------+      |                     |
 |  |     |                    |<---------------+                     |
 |  |     +--------------------+                                      |
 |  |           ^                                                     |
 |  |           |                                                     |
 |  |           | Lookup                                              |
 |  |     +-----+------+                                              |
 |  |     | Forward ---+--------> Packet                              |
 |  |     | Filter-----+-----+                                        |
 |  +-----+ Not Found  |     |                                        |
 |Packet  +------------+   -----                                      |
 |             ^            ---                                       |
 |             |             -                                        |
 |    Packet---+                                      Observation Point
 +--------------------------------------------------------------------+
                 Figure 1 - CCE ==> IPFIX Arcitecture

 Calato                         Informational                    [Page 12]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

    This diagram assumes the device performs some function besides
    Metering. In a pure passive probe environment some of the device
    functions would be deleted.

    A packet arrives at the Observation point and a lookup is done in
    the flow table. If an entry is found the packet will either be
    forwarded or dropped. If no entry is found it is sent to the Flow
    Management system.

    Flow Management in the diagram includes both device functions (e.g.
    router functions) and IPFIX Metering functions. In Flow Management
    the flow key is determined and the flow table is programmed (device
    functions). IPFIX Metering is notified a flow has been created.
    Current implementations of LFAP use the device's flow key as the IP
    flow key. However, for IPFIX purposes this is where the flow would
    be distinguished based on current IPFIX configuration along with
    IPFIX Flow Filtering. A message with the characteristic properties
    is created and sent (usually just added to a queue to be sent in
    batches). Also the LFAP Flow ID to device flow key is maintained.
    This is the only piece of state needed for reporting periodic
    updates. System timers notify LFAP Processing of flow update
    intervals. Flow timeouts are based on inactivity (not shown in
    diagram) and Flow management is notified of the event which
    triggers an LFAP delete notification.

    The LFAP Processing sends the messages in the queue in addition to
    sending periodic updates. The Flow ID is used to lookup the
    matching device flow table key and retrieve statistics.

 2.3.5.   Requirements Section 2.4 Flow Record

       In LFAP a flow record maps to 2 messages. The FAR message
       contains all the characteristic properties such as Source IP,
       Destination IP, etc_. The FUN message maps to the measured
       properties such as bytes and packets.

       This split allows lower memory requirements for the IPFIX
       Device. Since the characteristics properties are sent
       independent of measured characteristics, there is no need to
       store the characteristic properties until update time. This also
       allows LFAP to report regular updates for a flow without
       repeating the flow characteristics. Thereby minimizing what is
       transferred over the network at the expense of keeping minimal
       state in the CCE for microflow or flow aggregates being
       reported.

 2.3.6.   Requirements Section 2.6 Collecting Process

       The Collecting process maps directly to the Flow Accounting
       Server (FAS) in the LFAP specification.

 Calato                         Informational                    [Page 13]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 2.4   Architectural Differences

    LFAP was designed specifically for IP flow information export and
    defines the data and transfer protocol whereas IPFIX so far has
    focused on the architectural constructs of IP flow collection
    requirements/semantics and processing. Specific differences between
    LFAP and IPFIX requirements are described under the compliance
    section.

 3. Item Level Compliance Evaluation

 This section evaluates the compliance of the LFAP protocol with the
 IPFIX requirements item by item. Requirements are addressed by their
 section numbers and item numbers in [IPFIX-REQ]. For each requirement
 it is explained to what degree the LFAP protocol meets the requirement
 and how this is achieved. The degree of compliancy is explicitly
 stated using five grades:

    -T  Total compliance: The requirement is met completely by the
        protocol specification without any extensions required.

     -E  Extension required for total compliance: The protocol is
        prepared to be extended and it is possible to extend it in a
        way that it meets the requirement. This grade is only
        applicable to protocols that are explicitly open to externally
        defined extensions, such as SNMP is extended by MIB modules or
        DIAMETER is extended by application modules. It is not
        applicable to protocols, where the protocol specification
        itself needs to be extended in order to comply with the
        requirement.

     -P  Partial compliance: The requirement is met partially by the
        protocol specification.

     -U  Upcoming compliance: The requirement is not met or met
        partially by the protocol specification, but there is a
        concrete plan for an upcoming version of the protocol.

    -F  Failed compliance: The requirement is not met by the protocol
        specification.

 3.1   Extending LFAP

    LFAP can be extended in 4 ways. In general extensions can be made
    without breaking existing Collectors. Each method is described
    below.

 Calato                         Informational                    [Page 14]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 3.1.1.   Vendor Specific

    The Vendor Specific Information Element allows individual vendors
    to send extra information in any message without modifying the LFAP
    specification or breaking existing Collectors. The specification
    states that any information supplied in the Vendor Specific IE MUST
    be able to be safely ignored. See section 2.45 in the LFAP data
    specification [2] for a detailed description of the IE.

 3.1.2.   Information Element Extension

    The LFAP data specification can be modified with new Information
    Elements. The LFAP message structure and data semantics will remain
    the same. The LFAP specification indicates that unknown IE's are to
    be ignored so compatibility with existing Collectors is maintained.

    Adding a new element merely involves allocating the next
    Information Element number and adding the necessary text to the
    specification.

 3.1.3.   AR/ARA Message Extension

    These message are intended to contain control information which
    needs to be exchanged between the IPFIX Device and the Collecting
    process. The basic choice here is whether the information is better
    suited to the MIB or an outside configuration mechanism.

    Once the decision is made to use the AR/ARA messages, a new command
    value is allocated along with allocating any supporting Information
    Elements. Unknown commands are ignored by both the IPFIX device and
    the Collecting Device. If the command is not optional, the LFAP
    version number would need to be incremented resulting in an
    incompatibility for existing Collector and IPFIX Devices.

 3.1.4.   MIB Extensions

    New objects may be added for configuration or monitoring.

 3.2   Requirements Section 4 Distinguishing Flows

       Requirements Section 4.1 Interfaces
       Requirements Section 4.2 IP Header
       Requirements Section 4.3 Transport Header Fields
       Requirements Section 4.4 MPLS
       Requirements Section 4.5 DiffServ Code
       Requirements Section 4.6 Header Compression and Encryption

 Calato                         Informational                    [Page 15]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

       Compliance = T

       Any combination of attributes and/or functions may be used to
       distinguish flows. The resulting flow may then be exported using
       LFAP.

 3.3      Requirements Section 5 Metering

 3.3.1.   Requirements Section 5.1 Reliability

          Compliance = T

          LFAP has the following statistics defined.

          Dropped messages
              A count of the number of FAR or FUN messages the CCE
              could not be transmitted to the FAS while not in Send
              State.

          Dropped messages while connected
             A count of the number of FAR or FUN messages the CCE could
             not be transmitted to the FAS while in Send State.

          Number of bytes not accounted for due to dropped messages
             A count of the number of bytes accounted for in FUN
             messages being dropped that CCE could not transmit to the
             FAS while in Send State.

          Number of packets not accounted for due to dropped messages
             A count of the number of packets accounted for on the wire
             that CCE could not transmit to the FAS while in Send
             State.

 3.3.2.   Requirements Section 5.2 Sampling

          Compliance = F

          LFAP does not have any support for sampling. However, it is
          certainly possible to extend it to contain the necessary
          support. For example, LFAP already has the notion of multiple
          types of flows. In this case extending LFAP to allow a FAR
          with a flow type of _sampled_ may be sufficient.

 3.3.3.   Requirements Section 5.3 Overload

          Compliance = T

 Calato                         Informational                    [Page 16]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

          LFAP indicates that flows may be dropped and keeps statistics
          on this behavior. However, this should be stated more
          explicitly in the specification. Since the overload behavior
          is to stop reporting, there is no need to distinguish the
          flows from before and after the event. There is also no need
          to terminate all existing flows when this event occurs.

          The MUSTs in the requirements, I believe, do not apply to all
          overload behaviors.

 3.3.4.   Requirements Section 5.4 Timestamps

          Compliance = T*

          * - The LFAP specification indicates the start time is when
              the flow was created. This generally coincides with the
              first packet, but the specification does not mandate it.
              Furthermore, the end time is when the statistics were
              gathered. This generally coincides with the flow being
              timed out or the last packet. But again the specification
              does not mandate it.

 3.3.5.   Requirements Section 5.5 Time Synchronization

          Compliance = T

          LFAP provides a way to obtain time information from the IPFIX
          device. See sections 3.3 and 3.4 in the LFAP data
          specification [2] for the AR and ARA messages concerning the
          RETURN_TIME command.

 3.3.6.   Requirements Section 5.6 Flow Expiration

          Compliance = P

          LFAP provides a way to close a flow via a state field. The
          state field can be extended to indicate why the flow was
          close (e.g. timeout, FIN/RST TCP bits). However, LFAP does
          not clearly define the flow timeout procedure. This can be
          rectified in a subsequent revision. See section 2.16 of the
          LFAP data specification [2] concerning Flow State.

 3.3.7.   Requirements Section 5.7 Multicast

          Compliance = T

          LFAP can of course report the individual multicast flows. It
          can also report multiple output interfaces. See section 2.24
          and section 3.1 of the LFAP data specification [2] for a
          description of multiple egress interfaces.

 Calato                         Informational                    [Page 17]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 3.3.8.   Requirements Section 5.8 Ignore Port Copy

          Compliance = F

          LFAP does not support reporting flows resulting from a port
          copy. Thus there is no way to distinguish them from normal
          flows.

 3.3.9.   Requirements Section 6.1 Information Model

          1. IP version number

             Compliance = T*

             * - The address IE contains an address family field which
             will indicate IP V4 or IP V6. If address family is not
             sufficient then IP version number will need a new IE
             element.

          2. source IP address

             Compliance = T

             LFAP also supports reporting the address mask.

          3. destination IP address

             Compliance = T

             LFAP also supports reporting the address mask.

          4. IP protocol type (TCP,UDP,ICMP,...)

             Compliance = T

          5. source TCP/UDP port number

             Compliance = T

          6. destination TCP/UDP port number

             Compliance = T

          7. input interface (ifIndex)

             Compliance = T

 Calato                         Informational                    [Page 18]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

          8. output interface (ifIndex) )

             Compliance = T

          9. packet counter

             Compliance = T

          10. byte counter

              Compliance = T*

              * - The LFAP counter definition could be better expressed
              in the specification.

          11. in case of IPv4: Type of Service

              Compliance = T

          12. in case of IPv6: Flow Label

              Compliance = T

          13. if BGP is supported at the observation point: BGP AS
              number

              Compliance = T

          14. if MPLS is supported at the observation point: MPLS label

              Compliance = T

          15. if DiffServ is supported at the observation point: DSCP

              Compliance = T

          16. timestamp of the first packet of the flow

              Compliance = T*

              * - The LFAP specification indicates the start time is
              when the flow was created. This generally coincides with
              the first packet, but the specification does not mandate
              it.

          17. timestamp of the last packet of the flow

              Compliance = T*

 Calato                         Informational                    [Page 19]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

              The end time is when the statistics were gathered. This
              generally coincides with the flow being timed out or the
              last packet. But the specification does not mandate it.

          18. if sampling is used: sampling configuration

              Compliance = F

             If the choice was to configure this via the protocol, LFAP
             could be extended by allowing the sampling configuration
             to be provided in the AR/ARA message pair or the in LFAP
             MIB.

          19. unique identifier of the observation point

              Compliance = T*

              * - The identifier is an IP address. If the observation
              point is not IP addressable, a different mechanism would
              be needed. The issue here is how to obtain a unique ID
              that can also be traced back to a specific IPFIX
              observation point.

          20. unique identifier of the exporting process

              Compliance = F

             This would require just the definition of one additional
             information element.

          21. multicast replication factor

              Compliance = F

             This would require just the definition of one additional
              information element.

          22. Time To Live

              Compliance = F

             This would require just the definition of one additional
              information element.

          23. IP header flags

              Compliance = F

             This would require just the definition of one additional

 Calato                         Informational                    [Page 20]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

              information element.

          24. TCP header flags

              Compliance = T

          25. dropped packet counter at the observation point

              Compliance = F

             This would require just the definition of one additional
              information element.

          26. fragmented packet counter

              Compliance = F

             This would require just the definition of one additional
              information element.

 3.3.10.  Templated Data

          If templated data passing is needed, LFAP defines a multi-
          record IE where the record format is given once in the
          message and then just values are listed for each flow
          reported. This provides a good amount of data reduction. If
          further reduction is mandated via a session wide template,
          additional work would need to be done in LFAP. However, this
          extra level of reduction, in my view, is only an incremental
          reduction. The amount of data reduction from a coarser
          grained flow definition would dwarf any reduction from
          sending type information per session instead of per message.
          Thus if bandwidth is an issue, a coarser flow definition is
          the likely solution.

 3.3.11.  Requirements Section 6.2 Data Model

          Compliance = T & F

          Since LFAP uses a TLV format, unknown IE's are simply skipped
          over. Thus new attributes can be added without affecting
          existing Collectors. LFAP also allows, via the protocol, the
          configuration of the set of data elements to be exported.

          In some cases LFAP depends on messages coming in order. For
          example, if cumulative byte counts are used (as opposed to
          delta byte counts which is also available), out of sequence

 Calato                         Informational                    [Page 21]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

          update messages would cause a problem. At the moment TCP is
          used to solve this problem. If an unreliable transport is
          needed, LFAP would need to be extended with a message
          sequence number to ensure ordering at the application layer.
          There already exists a message ID but it is only a 16 bit
          value which may not be large enough. The other option is to
          remove the alternative features that have ordering issues.

 3.3.12.  Requirements Section 6.3.1 Congestion Awareness

          Compliance = T

          LFAP uses TCP. If an unreliable congestion aware protocol is
          used instead, LFAP would need a larger message ID field (32
          bits instead of 16) to solve any ordering issues.

 3.3.13.  Requirements Section 6.3.2 Reliability

          Compliance = T

          LFAP uses TCP which is a reliable transport. LFAP also
          defines statistics for tracking reliability parameters.

          Application level reliability is not supported. However,
          there is enough information in the LFAP messages to provide
          such support. For example, the FLOW_ID, TIMESTAMP, MESSAGE_ID
          3-tuple uniquely identifies all messages. Thus duplicates may
          be weeded out.

          However, sending duplicate data records has design and
          implementation issues associated with it. The design issue is
          developing a procedure where duplicate records are always
          eliminated. It seems there exist failure combinations that
          poke holes in any design. Whether or not those holes are
          acceptable is an issue for the market place.  Furthermore,
          high volume situations cause practical implementation
          problems in searching for duplicate records.

 3.3.14.  Requirements Section 6.3.3 Security

          See section 4 Security in this document.

 3.3.15.  Requirements Section 6.4 Regular Reporting

          Compliance = T

          LFAP's message structure is ideally suited for regular
          reporting. Update information may be sent without repeating
          characteristics. Update intervals can also vary for different
          flows.

 Calato                         Informational                    [Page 22]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 3.3.16.  Requirements Section 6.5 Notification on Specific Events

          Compliance = P & F

          The 2 events mentioned are handled by the FAR/FUN messages.
          The MIB also defined several events. If other events are
          needed, the AR/ARA messages could be extended or additional
          MIB events can be provided.

 3.3.17.  Requirements Section 6.6 Anonymization

          Compliance = F

          If all data is anonymzed an AR/ARA exchange or MIB changes
          could provide the indication. If it is per message, there is
          room in the message header to provide the indication. If
          field level is needed, there is room in the IE type for this
          indication. However, further review needs to be done as there
          may be other ways to accomplish this at the field level.

 3.3.18.  Requirements Section 7.1 Configuration of the Metering

          1. Specification of the observation point
          2. Specifications of flows to be metered
          3. Flow timeouts
          4. Sampling method and parameters, if feature is supported
  5. Overload behavior

             Compliance = F

             LFAP does not define these configuration parameters. LFAP
             can be extended to provide configuration information via
             the MIB or AR/ARA exchange. How far we go in the
             configuration area is another matter.

 3.3.19.  Requirements Section 7.2 Configuration of the Exporting

          1. reporting data format

             Compliance = T

          2. the collecting process(es) to which flows are reported

             Compliance = T

             The LFAP MIB allows this to be configured.

          3. notifications to be sent to the collecting process(es)

 Calato                         Informational                    [Page 23]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

             Compliance = P

             The LFAP MIB defines traps which may be sent.

          4. flow anonymization

             Compliance = F

             This configuration be can handled via the LFAP MIB or the
             AR/ARA exchange.

 3.3.20.  Requirements Section 8.1 Openness

          Compliance = T*

          The LFAP Information Model and Data Model were designed for
          easy extension and flexibility. Configuration extension is
          possible through MIB and AR/ARA message exchange.

 3.3.21.  Requirements Section 8.2 Scalability Concerning the Number of
          Exporting Processes

          Compliance = T*

          LFAP places no limits on the number of Exporting Processes.
          LFAP distinguishes Exporting Processes by address.

          * - If distinguishing by address is deemed insufficient, an
          additional Information Element will need to be defined.

 3.3.22.  Requirements Section 8.3 Several Collecting Processes

          Compliance = F

          LFAP would need to define this procedure and add the
          necessary elements to the MIB module for configuration.

 4. Security Considerations

    Security considerations for the IPFIX protocol are covered by the
    comparison against the specific Security requirements in the IPFIX
    requirements document [IPFIX-REQ] where they are specifically
    addressed by sections 6.3.3 and 10.

 4.1   Requirements Section 6.3.3 Security

          Compliance = T

 Calato                         Informational                    [Page 24]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

          LFAP specifies security mechanisms to achieve the elements
          listed below. The security mechanisms can be external to the
          protocol (e.g. provided by the transport layer) or via the
          LFAP protocol itself. A combination may be also be used.

          LFAP provides mechanisms in the protocol to allow for
          lightweight simple mechanisms when needed. It also paves the
          way for field level security, which may reduce the CPU cycles
          needed to implement security features.

          Confidentiality
             If LFAP is used a bit in the message header indicates the
             message is encrypted. The encryption mechanisms are well
             defined.

          Integrity
             If LFAP is used a bit in the message header indicates the
             message is authenticated. The authentication procedure
             covers Integrity. If only Integrity is desired, simply
             defining one additional bit is all that is necessary.

          Authenticity
             If LFAP is used a bit in the message header indicates the
             message is authenticated. Authentication procedures are
             well defined.

          Push

             Compliance = T

          Pull

             Compliance = F

             LFAP does not support pull mode. Additional work would
             need to support this mode.

 4.2   Requirements Section 10.1 Disclosure of Flow Information Data

          Compliance = T

          LFAP defines encryption procedures.

 4.3      Requirements Section 10.2 Forgery of Flow Records

          Compliance = T

          LFAP defines Authentication and Integrity procedures.

 Calato                         Informational                    [Page 25]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 4.4   Requirements Section 10.3 Denial of Service (DoS) Attacks

          Compliance = T

          The LFAP specification describes procedures to mitigate DoS
          attacks on the IPFIX device and the Collecting device. For
          example, see the following paragraph in section 5.2 _Version
          Request Acknowledge (VRA) Message_ of the LFAP specification
          [1].

             _The CCE MUST NOT request a version higher than the one
               returned in the VRA otherwise the FAS MUST disconnect the
               TCP session and the counter Session Establishment Errors
               will be incremented._

           This is intended to keep the FAS (Collecting Process) from
          being bombarded with VR requests as a DoS Attack against the
          FAS.

 Calato                         Informational                    [Page 26]

 INTERNET-DRAFT         IPFIX LFAP Protocol Evaluation        August 2002

 5. References
 [1]    "Light-weight Flow Accounting Protocol Specification Version
           5.0" draft-riverstone-lfap-01.txt, June 2002

 [2]    "LFAP Data Definition Specification",
         draft-riverstone-lfap-data-01.txt. June 2002

 [3]    _Cabletron's Light-weight Flow Admission Protocol
         Specification version 1.0_. Informational RFC 2124 March 1997

 [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information
             Export", draft-ietf-ipfix-reqs-05.txt, work in progress,
             August 2002.

 6. Author's Address

      Paul Calato
      Riverstone Networks
      5200 Great America Pkwy.
      Santa Clara, CA 95054

 7. Full Copyright Statement

    Copyright (C) The Internet Society (2001). 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 languages
    other than English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on
    an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
    IMPLIED, INCLUDIN   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 Calato                         Informational                    [Page 27]