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

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

IPFIX working group                        EDITORS:     K.C. Norseth
Internet Draft                                    Enterasys Networks
draft-ietf-ipfix-Architecture-00.txt                Ganesh Sadasivan
Expires: August 2002                              Cisco Systems, Inc
                                                       February 2002

                        IPFIX Architecture
             Architecture for IP Flow Information Export
                draft-ietf-ipfix-architecture-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 defines architecture for scalable monitoring,
   measuring and exporting IP flow information to collectors.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC-2119 [ ].


   1. Introduction                                             2
   2. Scope                                                    3
   3. Terminology                                              3
   4. IPFIX reference Model                                    4
   4.1. Exporter                                               6
   4.2. IPFIX protocol                                         6
   4.3. Observation Domain                                     7
   4.4. Collector                                              8
   4.5. Capabilities Management                                8
   4.6. Applications                                           9

IPFIX Working Group            Expires August 2002         [Page 1]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   5. IPFIX Protocol                                           9
   5.1. Selection Criteria for IPFIX Protocol                  9
   5.1.1. Common for Exporting and Collecting Device           9
   5.1.2. IPFIX Protocol on Exporting Device                   9
   5.1.3. IPFIX Protocol on Collecting Device                  9
   5.2. Export Models                                          9
   5.2.1. A Simple Export Model                                9
   5.2.2. Export Model with Reliable Control Connection        9
   5.3. Collector Crash Detection and Recovery                10
   5.3.1. Simple Export Model                                 10
   5.3.2. Export Model with Reliable Control Connection       10
   5.4. Collector Crash Detection and Recovery                11
   5.4.1. Simple Export Model                                 11
   5.4.2. Export Model with Reliable Control Connection       11
   5.5. Collector Redundancy                                  12
   5.5.1. Simple Export Model                                 12
   5.5.2. Export Model with Reliable Control Connection       12
   5.6. Security                                              12
   5.7. Capability Negotiation                                12
   5.7.1. Phase I  - Capabilities and Capabilities Management 13
   5.7.2. Phase II - Data Management and Data Transmission    14
   5.7.3. Renegotiation of Capabilities                       17
   5.7.4. Caching of Negotiated Parameters                    17
   6. Security Consideration                                  17
   6.1. Data security.                                        17
   6.1.1. No security                                         18
   6.1.2. Authentication only                                 18
   6.1.3. Encryption                                          18
   6.2. IPFIX end point authentication                        18
   6.3. Denial of service (DoS) attack prevention             19
   6.3.1. Network under attack                                19
   6.3.2. Generic DoS attack on the IPFIX system              19
   6.3.3. IPFIX Specific DoS attack                           19
   7. IANA Consideration                                      19
   8. References                                              20
   9. Acknowledgements                                        21
   10. Author's Addresses                                     22
   11. Full Copyright Statement                               23
   12. Issues                                                 23
   12.1. MIBS                                                 24
   12.2. Relationship to RTFM                                 24

1. Introduction

   Many applications e.g., Intrusion detection, traffic engineering,
   require the monitoring, measuring of IP traffic flows. It is hence
   important to have a standard way of exporting information related
   to IP flows. This document defines architecture for IP traffic
   flow monitoring, measuring and exporting. It provides a high-level
   description of the key components and their functions.


2. Scope


IPFIX Working Group            Expires August 2002         [Page 2]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   This document defines architecture for IPFIX[3]. The main objective
   of this document is to:

      *  Describe the key architectural components of IPFIX.
      *  Define the architectural requirements, e.g., Recovery,
         Security, etc for the IPFIX framework.
      *  Define the criteria to select the IPFIX Protocol.
      *  Specify the control/data message formats and handshaking
         details to pass the IP flow information.

3. Terminology
   Flow:
   A flow is defined as a set of packets passing an observation point
   in the network during a certain time interval. All packets belonging
   to a particular flow have a set of common properties. Each property
   is defined as the result of applying a function to the values of:

      1  One or more of packet header fields (e.g. destination IP
         address)
      2  One or more properties of the packet itself (e.g. packet
         length)
      3  One or more of fields derived from packet treatment (e.g. AS
         number)


   Each of the fields from 1.,2. and 3. are referred to as keys. A
   packet is defined to belong to a flow if it completely satisfies all
   the defined properties of the flow. For a more detailed explanation
   of flows, refer to [IPFIX-DATA].

   Flow Type:
   A function F that would take input as a set of keys and the output
   would be one or more flows depending on the combination of values
   for the set of keys.

   Observation Point:
   The observation point may be one or a set of interfaces (physical or
   logical) of the exporter. For a more detailed explanation of
   Observation Point, refer to [IPFIX-DATA].

   Meter Process:
   A set of actions like timestamping, sampling, filtering, performed
   on packets received at an observation point to map them to flows.
   For a more detailed explanation of Meter Process, refer to [IPFIX-
   DATA].

   Observation Domain:
   The set of observation points that is the largest aggregatable set
   of flow information at the exporter is termed as an observation
   domain. The observation domain presents itself a unique ID to the
   collector for identifying the export packets generated by it.

   Example: The observation domain could be a router line card,
   composed of several interfaces with each interface being an

IPFIX Working Group            Expires August 2002         [Page 3]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   observation point.

   Template:
   Templates is a set of {type, length} ordered pairs, used to
   completely identify the structure and semantics of a particular
   information that needs to be communicated from the exporter to the
   collector. Each template is uniquely identified by a Template ID.



4. IPFIX reference Model

   The figure below shows the reference model for IPFIX. This figure
   covers the various possible scenarios that can exist in an IPFIX
   system.


   +-------------------+     +----------------+   +----------------+
   |[Obsv Point(s)]    |     |[*Application 1]| ..|[*Application n]|
   |[Meter Process(es)]|     +--------+-------+   +-------+--------+
   +----------+--------+              ^                   ^
              ^                       !                   !
              !                       +~~~~~~~~~~+~~~~~~~~+
              !                                  !
              v                                  v
   +------------------+                 +------------------+
   |IPFIX Device(1)   |                 | Collector(1)     |
   |[Export Process]  |<--------------->|                  |
   |                  |                 |                  |
   +------------------+                 +------------------+
           ....                               ....
   +-------------------+                +------------------+
   |IPFIX Device(i)    |                | Collector(j)     |
   |[Obsv Point(s)]    |<-------------->| [*Application(s)]|
   |[Meter Process(es)]|          +---->|                  |
   |[Export Process]   |          |     +------------------+
   +-------------------+          .
          ....                    .          ....
   +-------------------+          |     +------------------+
   |IPFIX Device(m)    |          |     | Collector(n)     |
   |[Obsv Point(s)]    |<---------+---->| [*Application(s)]|
   |[Meter Process(es)]|                |                  |
   |[Export Process]   |                +------------------+
   +-------------------+

   The various functional components are indicated within []. The
   functional components within [*] are not part of the IPFIX
   framework. The interfaces shown by "<-->" are defined by the IPFIX
   framework and those shown by "<~~>" are not.

   An IPFIX device is a unit that hosts at the minimum, flow
   information export process but usually, the corresponding
   Observation points, metering processes, and exporter processes are
   co-located at this device. A group of Observation Points and their

IPFIX Working Group            Expires August 2002         [Page 4]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   corresponding meter processes form an Observation Domain. One or
   more Observation Domains can interface with the same export process.
   The figure below shows a typical IPFIX device.


   +---------------------------------------------------+
   |                  IPFIX Device                     |
   | +---------------------------------------+ +-----+ |
   | |         Capabilities Manager          | |MGMT | | Import
   | |                                       | |Prcs |<-------
   | |---------------------------------------+ +-----+ | the
   | +---------------------------------------+ +-----+ | collector
   | |         Observation Domain 1          | |  e  | |
   | |  +--------------------------+         | |     | |
   | |  | * Optional Meter Process +~~+---------> x  | |
   | |  | Flow Level ({Fi}, {Si})  |  |      | |     | |
   | |  +--------------------------+  |      | |  p  | |
   | |       ^           ^            |      | |     | |
   | |       !           !            |      | |  o  | |
   | |       +---......--+------------+      | |     | |
   | |       |                        |      | |  r  | |
   | |  +----+----+ Packet Level +----+----+ | |     | |
   | |  |Meter    | ({Fi}, {Si}) |Meter    | | |     | |
   | |  |Process 1|              |Process N| | |  t  | |
   | |  +---------+              +---------+ | |     | |
   | |       ^                       ^       | |     | |
   | |       |                       |       | |     | |
   | | +-----+------+          +-----+------+| |     | |
   | | |Obsv Point 1|  ...     |Obsv Point M|| |     | |
   | | +------------+          +------------+| |     | |
   | +---------------------------------------+ |     | |export
   |                        ....              |       ------>
   | +---------------------------------------+ |     | |towards
   | |        Observation Domain K           | |  p  | |the
   | |                                       | |     | |collector
   | |  +--------------------------+ (*)     | |  r  | |
   | |  | * Optional Meter Process +~~+--------->    | |
   | |  | Flow Level ({Fi}, {Si})  |  |      | |  o  | |
   | |  +--------------------------+  |      | |     | |
   | |       ^           ^            |      | |  c  | |
   | |       +---......--+------------+      | |     | |
   | |       |                        |      | |     | |
   | |  +----+----+ Packet Level +----+----+ | |  e  | |
   | |  |Meter    | ({Fi}, {Si}) |Meter    | | |     | |
   | |  |Process 1|              |Process N| | |  s  | |
   | |  +---------+              +---------+ | |     | |
   | |       ^                       ^       | |  s  | |
   | |       |                       |       | |     | |
   | | +-----+------+          +-----+------+| |     | |
   | | |Obsv Point 1|  ...     |Obsv Point M|| |     | |
   | | +------------+          +------------+| |     | |
   | +---------------------------------------+ +-----+ |
   +---------------------------------------------------+


IPFIX Working Group            Expires August 2002         [Page 5]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   In this figure, the functional blocks are shown in rectangular
   boxes. The interface shown by "~~" is applicable only if the
   optional Meter process at the flow level is present. Otherwise, the
   meter process(es) at the packet level interfaces directly with the
   exporting function. Note that in case of multiple observation
   domains, a unique ID per observation domain must be transmitted as
   parameters to the exporting function. For details on ({Fi}, {Si})
   which makeup a meter process, refer to [IPFIX-DATA].


4.1.Exporter








   The exporter is a subsystem that interacts with one or more
   observation points.  The functions of an exporter may include:

      * Performing Flow ID management (capabilities negotiation)
        that includes the creation of tags to refer a flow between
        Exporter and the Collector for configuration and statistical
        purpose.
      * Assembling collected information into the right format to
        be carried by the IPFIX protocol
      * Configuring observation points with flow monitoring rules
      * Measuring, aggregating and exporting IP Flow information
        to the respective collectors.
      * May perform appropriate middle-box functions to translate
        the flow information.


   The information collected can be either pushed periodically to the
   collector or pulled by the collector on demand.

   The Exporter Process is the functional block that interacts with
   observation domain(s) on one side and collector(s) on the other
   side.  The typical functions of an exporter may include:

      * Accept and separate flow records/control information from
        different observation domains into separate export packet
        streams.
      * Run the part of the IPFIX protocol, which deals with
        packetization, and transport of flow records/control
        information with the collector.


   4.2. IPFIX protocol

   The information that needs to be exported from the exporting device
   can be classified into the following categories:

IPFIX Working Group            Expires August 2002         [Page 6]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

      1 Control Information - This includes the flow type definition,
        selection criteria for packets within the flow etc.
      2 Flow record - This includes data records corresponding to
        the various observed flows at each of the observation point.

   IPFIX protocol at the exporting device does the following:


      1 Encode the control information into self-describing structures.
      2 Encode the flows measured at the exporting device into flow

        records.
      3 Packetize the flow records and/or control information into
        export packets.
      4 Use the underlying transport layer to send the export packets
        to the collector.

   IPFIX protocol at the collecting device is responsible for

      1 Receive and store the control information.
      2 Decode and store the flow records using the control
        information.

   The information that needs to be exported from the IPFIX device can
   be classified into the following categories:

      * Control Information - This includes the flow type definition,
        selection criteria for packets within the flow etc.
      * Flow records.

   At the IPFIX device, the protocol functionality may be split between
   Observation domain and exporter process. IPFIX protocol at the IPFIX
   device does the following:

      1 Encode the control information into self-describing templates.
      2 Encode the flows measured at the exporting device into flow
        records.
      3 Packetize the flow records and/or control information into
        export packets.
      4 Use the underlying transport layer to send the export packets
        to the collector.

   IPFIX protocol at the collector is responsible for
      1 Receive and store the control information.
      2 Decode and store the flow records using the control
        information.


4.3. Observation Domain

   The Observation Domain is the functional block which may be
   capable of managing the flows generated from all the valid
   {Observation Point, Meter Process} combination defined within
   itself. The typical functions of an Observation Domain may

IPFIX Working Group            Expires August 2002         [Page 7]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   include:

      * Run the part of the IPFIX protocol which deals with encoding
        flow data and control information into flow records and
        templates respectively.
      * Decide which flow records/control information to export using
        rules based on time, thresholds, configuration events etc.
      * Aggregate flow records generated by one or more meter
        processes.
      * Add non-flow specific information (in some cases fields like
        AS numbers)
      * May perform appropriate middle-box functions to translate the
        flow information.


   The functionality of Meter Process is explained at length in
   [IPFIX-DATA].


4.4. Collector

   Collector is a subsystem that interacts with one or more Exporters.
   The functions of the collector may include:

      * Performing Flow ID management (capabilities negotiation) that
        includes the creation of tags to refer a flow between Exporter
        and the Collector for configuration and statistical purpose.
      * Requesting an exporter sub-system to collect IP flows.
      * Communicating with different applications.
      * Maintaining a repository of IP flow statistics
      * Aggregating application level requests and form a template
        that will suitable for exporter.

   The application(s) and the collector may be tightly coupled in one
   system. They may also be logically or physically a separate
   subsystem from the application(s). In which case, the communication
   between them is beyond the scope of IPFIX.

   Collector is a subsystem that interacts with one or more IPFIX
   devices. The functions of the collector MAY include:

      * Identify and accept export packets from different {Export
        Process, Observation Domain} pairs.
      * Run IPFIX protocol.
      * Store the control information and flow records received from
        IPFIX device.
      * Pass capabilities information to the IPFIX device. Notify the
        IPFIX device of problems it is having


4.5. Capabilities Management

   Basic capabilities contain information about the collector. It MAY
   include:

IPFIX Working Group            Expires August 2002         [Page 8]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


      * The collector availability - is it up?
      * Maximum caching capability of the collector.


4.6.Applications

   IPFIX applications may be things such as Billing and Intrusion
   Detection sub-systems. etc.[3]. An application requests the
   Collector to gather the relevant IP Flow information.


5. IPFIX Protocol


5.1. Selection Criteria for IPFIX Protocol


5.1.1. Common for Exporting and Collecting Device

      1 Transparency over transport protocol. Ability to operate on top
        of UDP or a reliable transport like TCP/SCTP.
      2 Transparency over any underlying security protocols.


5.1.2. IPFIX Protocol on Exporting Device

      1 Ability to detect loss of connectivity with the collector and
        trigger a switch over to an alternate collector.
      2 Optionally export flow records to multiple collecting devices.
      3 Optionally perform load balancing of flow record export among
        a set of collectors based on pre-defined set of rules.
      4 Monitor control information/flow record export, detect overload
        and switch to the overload behavior.


5.1.3.IPFIX Protocol on Collecting Device

      Monitor the reception of export packets from IPFIX device.


5.2. Export Models


5.2.1. A Simple Export Model

   If the network in which the exporter and collector are located
   guarantees the security and reliability requirements, the transport
   of the export flow packets MAY do over a lightweight transport like
   UDP, for speed and simplicity.


5.2.2. Export Model with Reliable Control Connection


IPFIX Working Group            Expires August 2002         [Page 9]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   If the network in which the exporter and collector are located does
   not guarantee reliability, at least the control information SHOULD
   be exported over a reliable transport. There could be network
   security concerns between exporter and collector.  To avoid re-
   inventing the wheel, and to reduce the complexity of flow export
   protocol, one or a combination of the following methods MAY be
   adopted as a solution to achieve security:

      * IP Authentication Header MAY be used when the threat
        environment requires stronger integrity protections, but does
        not require confidentiality.
      * IP Encapsulating Security Payload (ESP) MAY be used to provide
        confidentiality and integrity.
      * If the transport protocol used is TCP, optionally TCP MD5
        signature option MAY be used to protect against spoofed TCP
        segments.

   The flow records MAY be exported over an unreliable or reliable
   transport protocol.

   As explained above the transport connection (in the case of a
   connection oriented protocol) is pre-setup between the exporter and
   the collector. Once connected, the collector side receives the
   control information and uses this information to interpret the flow
   records. The exporter SHOULD set the keepalive (in the case of TCP)
   or the HEARTBEAT interval in the case of SCTP to a sufficiently low
   value so that it can quickly detect a collector crash.


5.3. Collector Crash Detection and Recovery

   The information that needs to be exported from the IPFIX device can
   be classified into the following categories:

      * Control Information - This includes the flow type definition,
        selection criteria for packets within the flow. This is also
        called as control stream.

      * Flow record - This includes data records corresponding to the
        various observed flows at each of the observation point. This
        is also called as data stream.


5.3.1. Simple Export Model

   If the network in which the exporter and collector are located
   guarantees the security and reliability requirements, the transport
   of the export flow packets MAY do over a lightweight transport like
   UDP, for speed and simplicity. A single transport stream for control
   and data would suffice here.


5.3.2. Export Model with Reliable Control Connection


IPFIX Working Group            Expires August 2002         [Page 10]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   If the network in which the exporter and collector are located does
   not guarantee reliability, at least the control information SHOULD
   be exported over a reliable transport. There could be network
   security concerns between exporter and collector.  To avoid re-
   inventing the wheel, and to reduce the complexity of flow export
   protocol, one or a combination of the following methods MAY be
   adopted as a solution to achieve security:

      * IP Authentication Header MAY be used when the threat
        environment requires stronger integrity protections, but does
        not require confidentiality.

      * IP Encapsulating Security Payload (ESP) MAY be used to provide
     confidentiality and integrity.

   * If the transport protocol used is TCP, optionally TCP MD5
     signature option MAY be used to protect against spoofed TCP
     segments.

   The data stream MAY be exported over a reliable or unreliable
   transport protocol.

   As explained above the transport connection (in the case of a
   connection oriented protocol) is pre-setup between the exporter and
   the collector.  Once connected, the collector side receives the
   control information and uses this information to interpret the flow
   records. The exporter SHOULD set the keepalive (in the case of TCP)
   or the HEARTBEAT interval in the case of SCTP to a sufficiently low
   value so that it can quickly detect a collector crash.


5.4.Collector Crash Detection and Recovery


5.4.1. Simple Export Model

   In this model, a collector crash can be detected if there is a
   Keepalive mechanism available at the IPFIX protocol layer. On
   detecting a Keepalive timeout, the exporter SHOULD stop sending the
   flow export data to the collector but continue to send Keepalive
   requests till a Keepalive response is received.

   If there is an alternate collector which can has connectivity with
   the exporter, the exporter SHOULD start exporting to this device.


5.4.2. Export Model with Reliable Control Connection

   The collector crash is detected at the exporter by the break in
   control connection (depending on the transport protocol the

   connection timeout mechanisms differ). On detecting a Keepalive
   timeout, the exporter SHOULD stop sending the flow export data to

IPFIX Working Group            Expires August 2002         [Page 11]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   the collector and try reconnecting the transport connection. This is
   valid for a single collector scenario.

   If there are multiple collectors for the same exporter, the exporter
   opens control connections to each of the collectors. However, data
   is sent only to one of the collectors, which is chosen as the
   primary. There could be one or more collectors configured as
   secondary and a priority assigned to them. The primary collector
   crash is detected at the exporter by the break in control connection
   (depending on the transport protocol the connection timeout
   mechanisms differ). On detecting loss of connectivity, the exporter
   opens data stream with the secondary collector of the next highest
   priority. This collector now becomes the primary. The maximum export
   data loss would be the amount of data exported in the time between
   when the loss of connectivity to the collector happened, and the
   time at which this was detected by the exporter.


5.5. Collector Redundancy


5.5.1. Simple Export Model

   In case there are multiple collectors, the exporter MAY multicast
   the flow records to the set of collectors that joined the export
   multicast group, instead of sending several unicast streams towards
   the different collectors. Multicast would lower the bandwidth
   requirements on the export link in case that the collectors are on
   the same media, and could lower the internal bus utilization on the
   exporter. Using multicast session with more than one collector
   joining the flow export multicast group, redundancy of collectors
   can be easily achieved.


5.5.2. Export Model with Reliable Control Connection

   The control information is exported through a reliable transport and
   so cannot be multicast. The data stream MAY be multicast if it is
   over an unreliable transport like UDP. However, the collector SHOULD
   join the multicast group only after the control stream is
   established and it has received the control information from the
   exporter. Using multicast session with more than one collector
   joining the flow export multicast group, redundancy of collectors
   can be easily achieved.


5.6. Security

   Refer Security Consideration section for details


5.7. Capability Negotiation

   The capability negotiation is composed of two phases. In the first

IPFIX Working Group            Expires August 2002         [Page 12]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   Phase, basic capabilities regarding the exporting interface support
   are negotiated between IPFIX end-points.  If this phase fails, the
   negotiation process will terminate and status information will be
   provided to upper layers.

   In the second phase, more capabilities that are specific are
   negotiated, for instance, extended information model support,
   redundancy support, templates, and supported messages.

   One could use, for instance, a capability negotiation process
   similar to LCP [RFC 1661]. For each capability proposed by one of
   the peers in each of the phases, the answer can be a reject, ack or
   nak.

   More specifically, the system sending a Configure-Request is telling
   the peer system that it is willing to receive data sent with the
   enclosed options enabled. If the peer does not recognize (or
   administratively prohibits) one or more options in the Configure-
   Request message, it must return just these options in a Configure-
   Reject message and the original sender must then remove the options
   from a subsequent Configure-Request message.

   If some of these options were recognized but unacceptable with the
   supplied parameters, the peer would then respond with a Configure-
   Nak containing only the offending options and a suggested modified
   value for the parameters (called a hint). The receiver of the
   Configure-Nak then should decide if the hinted value is acceptable
   and, if so, send a new Configure-Request reflecting the requested
   changes plus the original values for the unchanged options. The
   sender of the Configure-Request may not send back any message other
   than Configure-Request in response to Configure-Nak, so the only
   recourses available if the hint is unreasonable are to drop the
   option from subsequent Configure-Request messages, use Protocol-
   Reject to disable the protocol, or disconnect the link entirely.

   Finally, if all options are acceptable, the peer then responds with

   Configure-Ack with the same options list as given in the Configure-
   Request to indicate that all of the enclosed options were acceptable
   and that are now enabled.


5.7.1. Phase I  - Capabilities and Capabilities Management

   In the first phase, basic capabilities regarding the exporting
   interface support are negotiated between IPFIX end-points.  If this
   phase fails, the negotiation process will terminate and status
   information will be provided to users.

   The Phase I negotiation MAY be carried over UDP, as it is a widely
   supported transport protocol.


5.7.1.1. Security support

IPFIX Working Group            Expires August 2002         [Page 13]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   The security support capability is used to negotiate which methods
   (e.g. IPSec, TLS, MD5, etc) can be used to provide confidentiality,
   integrity and protection against spoofed attacks.


5.7.1.2. IPFIX protocol

   It is possible that several protocols (e.g. LFAP, CRANE, NetFlow,
   and Diameter) meet the IPFIX requirements.  In this case, this
   capability is used to negotiate which protocol the end points will
   use.


5.7.1.3. Version of Protocol

   This capability is used to negotiate which version of the protocol
   exporter and collector will use to communicate. Agreeing on a
   specific version indicates that the end-points support all the
   semantics and dynamic procedures specified by a version of the
   protocol.

   The protocol syntax (information model, data model, coding schemes,
   etc) should be negotiated in Phase II.


5.7.1.4. Transport layer support

   This capability is used to negotiate the transport layer protocol
   used between the exporter and collector.

   As the reliability is a key requirement of an IPFIX system, the
   transport protocol should be connection oriented, congestion aware,
   reliable, and providing in-sequence data delivery (e.g. TCP, SCTP).

   Under some circumstances e.g., when the network path between
   exporter and collectors ensures abundant bandwidth and 'no' packet
   loss due to congestion, a lightweight transport protocol such as UDP
   may be employed.  In this case, the upper layer must provide
   capabilities to ensure reliability, e.g. message integrity check,
   loss detection, acknowledgment, etc.


5.7.2. Phase II - Data Management and Data Transmission

   In this phase, the IPFIX protocol initiates its own connection setup
   that involves further capability negotiation.


5.7.2.1. Data collection triggers and policies

   *Update interval [TBD]

   *Sampling [TBD]

IPFIX Working Group            Expires August 2002         [Page 14]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   *Aggregation rules[TBD]

   * Caching

   The exporter caches a certain amount of data before sending it to
   the collector. If the collector fails, the exporter will need to
   hold more data than normal while it waits for the collector to come
   back or switch to different one. In order to provide for these two
   modes of operation, the exporter could be configured with two levels
   of caching. One level when the system is operating normally and a
   second when a failure occurs. If the exporter detects that a server
   is unavailable; it should use the higher cache level that allows it
   to hold more data than it does in normal operation.


5.7.2.2. Reliability

   This capability is used to negotiate parameters related to fail-over
   support, load balancing, keepalives, etc.

   For instance, exporter and collector SHOULD set the keepalive (in
   the case of TCP) or the HEARTBEAT interval in the case of SCTP to a
   sufficiently low value so that it can quickly detect a collector
   crash. On detecting a Keepalive timeout, the exporter SHOULD stop
   sending the flow export data to the collector and bring down the
   transport connection.

   If the exporter detects that a collector is unavailable and fail-
   over was negotiated, it should try to switch to the stand-by
   collector in order to resume service. If the exporter does not keep
   a live connection to the stand-by collector, it MAY go through the
   capabilities negotiation process described in this section before it
   could export data.

   IN the case of UDP, an exporter MAY send a Collector Health request
   query.  The collector MUST reply to this request. The exporter MUST
   be able to accept a response from the collector.  If the exporter
   does not see the health query response from the collector, it
   assumes the collector is unavailable and MAY switch to another
   collector that is available.

   In the case there are multiple collectors operating redundant mode,
   the exporter MAY multicast the flow records to the set of collectors
   that joined the export multicast group, instead of sending several
   unicast streams towards the different collectors. Multicast would
   lower the bandwidth requirements on the export link in case that the
   collectors are on the same media, and could lower the internal bus
   utilization on the exporter.

   In the case there are multiple collectors operating in load-
   balancing mode, a weight number associated with each server MAY be
   used to infer the amount of exported flows each server should
   receive.

IPFIX Working Group            Expires August 2002         [Page 15]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   It should be noted that servers operating in a redundant or load-
   balancing mode could be running different version of the IPFIX
   protocol and use different capabilities.


5.7.2.3. Templates
   This capability is used to negotiate a common set of templates
   corresponding to an IPFIX session between the exporter and
   collector. A locally unique template identifier (template ID) MUST
   be assigned to each template, and carried along with IPFIX user
   messages to ensure correct decoding of IP flow information. Exporter
   and collector MUST use the same set of templates during a session.
   The templates can be renegotiated but MUST always be agreed on by
   all IPFIX end-points participated in the IPFIX session before they
   can be used.

   The exporter and collector MUST agree on a common set of templates
   before the collector can start sending data according to them.

   The template negotiation follows the LCP method described earlier.
   The collector may propose changes to the templates received from an
   exporter (e.g. enabling some keys and disabling others), or it can
   acknowledge the templates as is. In the case that a template or a
   key is not recognized by the collector (e.g. they might be added to
   the exporter after the collector configuration has completed), the
   collector MAY choose to disable each unknown key or unknown
   templates in order to avoid unnecessary traffic. A template is
   disabled when all the keys are disabled.


5.7.2.4. Extended flow type support
   Beside standardized minimum set of possible flow properties, the
   exporter should be able to classify and export flows based on
   extended information such as (but not limited to) URL, RTP Media
   type and SIP Method.

   This capability is used to negotiate what are those extended
   properties.


5.7.2.5. Messages Supported
   A particular protocol or version might have optional messages that
   are not mandatory. This capability is used to negotiate what are
   those optional messages types supported.


5.7.2.6. Overlapping flows
   This capability is used to negotiate the support of overlapping flow
   awareness, i.e., if exporter has the means of inferring if the same
   will be exported more than once and letting the collector of this
   fact.

   In the absence of explicit negotiation of this capability, the

IPFIX Working Group            Expires August 2002         [Page 16]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   collector MUST consider that all flows reported can overlap. In the
   case the device reports overlapping between certain flows, the
   collector SHOULD take this into consideration, but MUST NOT assume
   that other flows will not overlap


5.7.2.7. MIDCOM related Capabilities [TBD]

   To Be Added


5.7.3. Renegotiation of Capabilities

   Only renegotiation of capabilities agreed on phase II can be
   performed without tearing down the connection.

   The initial negotiation can deal with a wealth of settings and
   assign ID's to various capability versions.  The re-negotiation
   needs only to refer these IDs and require simple acknowledgement.


5.7.4. Caching of Negotiated Parameters

   Negotiation of parameters can be transmitted at any time by the
   exporter.

   It is also possible for the collector to request negotiation
   parameters.  The exporter MUST be able to receive a request from the
   exporter.


6. Security Consideration

   IP flow information can be used for various purposes, such as usage
   accounting, traffic profiling, traffic engineering, and intrusion
   detection. For each application, the security requirement may differ
   significantly from one to another. To be able to satisfy the
   security needs of various IPFIX users, the architecture of IPFIX
   MUST provide different levels of security protection.


6.1. Data security.

   IPFIX data consists the control stream and data stream generated by
   the IPFIX device.

   The IPFIX data may exist in both the IPFIX device and the collector.
   In addition, the data is also transferred on the wire from the
   exporter to the collector when it is reported. To provide security,
   the data SHOULD be protected from adversary.

   The protection of IPFIX data within the end system (IPFIX device and
   collector) is out of the scope. It is assumed that the end system
   operator will provide adequate security for the IPFIX data.

IPFIX Working Group            Expires August 2002         [Page 17]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   The IPFIX architecture MUST allow different levels of protection to
   the IPFIX data on the wire. Whereever security functions are
   required it is recommended to leverage to lower layers using either
   IPsec or TLS, if they can successfully satisfy the security
   requirement of IPFIX data protection.

   To protect the data on the wire, three levels of granularity SHOULD
   be supported:


6.1.1. No security

   No security is required when the transport between the IPFIX device
   and the collector is perceived as safe. This option allows the
   protocol to run most efficiently without extra overhead and an IPFIX
   solution MUST support it.


6.1.2. Authentication only

   The authentication only protection provides the IPFIX users the
   assurance of data integrity and authenticity. The data exchanged
   between the IPFIX device and the collector is protected by
   authentication signature. Any modification of the IPFIX data will be
   detected by the recipient, resulting in discarding of the received
   data. However, the authentication only option doesn't offer data
   confidentiality. The IPFIX user SHOULD avoid use this option when
   sensitive or confidential information is being exchanged. An IPFIX
   solution SHOULD support this option. The authentication only option
   SHOULD provide replay attack protection. Some means to achieve this
   level of security are:

        *  TCP with MD5 options.
        *  IP Authentication Header


6.1.3. Encryption

   Data encryption provides the best protection for IPFIX data. The
   IPFIX data is encrypted at the sender and only the intended
   recipient can decrypt and have access to the data. This option MUST
   be used when the transport between the exporter and the collector
   are unsafe and the IPFIX data needs to be protected. It is
   recommended to use the underlying security layer functions for this
   purpose. Some means to achieve this level of security are:

        *  Encapsulating Security Payload.
        *  Transport Layer Security Protocol

   The data encryption option adds overhead to the IPFIX data transfer.
   It may limit the rate that an export can report its flow to the
   collector due to the heavy resource requirement of running
   encryption.

IPFIX Working Group            Expires August 2002         [Page 18]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002



6.2. IPFIX end point authentication

   It is important to make sure that the IPFIX device is talking to the
   "right" collector instead of a masqueraded collector. The same logic
   also holds true from the collector point of view that it want to
   make sure it is collecting the flow information from the "right"
   IPFIX device. The IPFIX architecture SHOULD allow the authentication
   capability so that either one-way or mutual authentication can be
   performed between the IPFIX device and collector.

   The IPFIX architecture SHOULD use the existing transport protection
   protocols such as TLS to fulfill the authentication requirement.


6.3. Denial of service (DoS) attack prevention

   Since one of the potential usages for IPFIX is for intrusion
   detection, it is important for the IPFIX architecture to support
   some kind of DoS resistance.


6.3.1. Network under attack

   The Network itself may be under attack, resulting in an overwhelming
   number of IPFIX messages. The IPFIX SHOULD try to capture as much
   information as possible. However, when large amount IPFIX messages
   are generated in a short period of time, the IPFIX may become
   overloaded. The IPFIX system MUST provide enough performance
   assurance so that the system can still function under heavy load.
   Possible solutions include flow control and message threshold
   information.


6.3.2. Generic DoS attack on the IPFIX system

   The IPFIX system may subject to generic DoS attacks, just as any
   system on any open networks. These types of attacks are not IPFIX
   specific. Preventing and responding to such types of attacks are out
   of the scope of IPFIX WG.

6.3.3. IPFIX Specific DoS attack

   There is a specific attack on the IPFIX portion of the Exporter or
   Collector.

   (To be added and discussed on the general list).


7. IANA Consideration

   Need Port number assigned from IANA
   [more to be written]

IPFIX Working Group            Expires August 2002         [Page 19]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002





8. References

   3.   J. Quittek ,et al.," Requirements for IP Flow Information
   Export ", (work in progress) ,Internet Draft, Internet
   Engineering Task Force, <draft-ietf-ipfix-reqs-00.txt>, November
   2001

   4.   M. Wood ,et al.," Intrusion Detection Message Exchange
   Requirements",(work in progress), Internet Draft, Internet
   Engineering Task Force, draft-ietf-idwg-requirements-06,February
   2002.

   5.   Daniel O. Awduche, et. al.," Overview and Principles of
   Internet Traffic Engineering", (work in progress), Internet
   Draft, Internet Engineering Task Force, draft-ietf-tewg-
   principles-02.txt, May 2002


   [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,
   http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-
   adelaide/pp-dist/

   [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric
   for IPPM,   <draft-ietf-ippm-ipdv-08.txt>, November   2001

   [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
   Loss Metric for IPPM, September 1999

   [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun:
   Application of Sampling
   Methodologies to Network Traffic Characterization, Proceedings of
   ACM SIGCOMM'93,
   San Francisco, CA, USA,  September 13 - 17, 1993

   [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed
   MARTENS, John G. CLEARY:
   Nonintrusive and Accurate Measurement of Unidirectional Delay and
   Delay Variation on
   the Internet, INET'98, Geneva, Switzerland,  21-24 July, 1998

   [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling
   for Direct Traffic Observation",
   Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
   August 28 -  September 1, 2000.

   [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
   Metric for IPPM,
   Request for Comments: 2679, September 1999

   [ZsZC01]     Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation

IPFIX Working Group            Expires August 2002         [Page 20]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   of Building Blocks
   for Passive One-way-delay Measurements, Proceedings of Passive and
   Active Measurement
   Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
   (PAM 2001)

   [MCFW] Srisuresh, S. et al.  "Middlebox Communication Architecture
   and framework," work in progress.  October 2001.

   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
   Translator (NAT) Terminology and Considerations", RFC 2663, August
   1999.

   [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
   address Translator (Traditional NAT)", RFC 3022, January  2001.

   [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider
   Provisioned Virtual Private Networks ", work in progress, <draft-
   ietf-ppvpn-framework-03.txt>, January 2002.

   [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
   <draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.

   [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z.
   and W. Weiss, "An Architecture for Differentiated Services", RFC
   2475, December 1998.

   [1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt>
   <http://www.ietf.org/html.charters/ipfix-charter.html>

   [2] K.Zhang, et al., "Common Reliable Accounting for Network Element
   (CRANE)", <draft-kzhang-crane-protocol-02.txt>, February 2002

   [3] G. Sadasivan, et al., "Flow Export Architecture", <draft-cisco-
   ipfix-arch-00.txt>, January 2002

   [4] Carlson, James, "PPP Design, Implementation and Debugging",
   Second Edition .



9. Acknowledgements
   We like to thank all the people contributing to the requirements
   discussion on the mailing list, and the design teams for many
   valuable comments.

   George Carle
   Tanja Zseby
   Paul Calato
   Dave Plonka
   Kevin Zhang
   KC Norseth
   Benoit Claise
   Ganesh Sadasivan

IPFIX Working Group            Expires August 2002         [Page 21]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002

   Vamsi Valluri
   Ram Gopal
   Jc Martin
   Carter Bullard
   Juergen Quittek
   Reinaldo Penno
   Nevil Brownlee
   Simon Leinen

10. Author's Addresses

   Paul Calato
   Riverstone Networks, Inc.
   5200 Great America Parkway
   Santa Clara, CA 95054  USA
   Phone:  +1 (603) 557-6913
   Email:  calato@riverstonenet.com

   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium
   Phone: +32 2 704 5622
   Email: bclaise@cisco.com

   Ganesh Sadasivan
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   USA
   Phone:  +1 (408) 527-0251
   Email:  gsadasiv@cisco.com

   Ram Gopal
   Nokia
   5 Wayside Road,
   Burlington, MA 01803
   Phone:+1 781 993 3685
   Email: ram.gopal@nokia.com

   Man Li
   Nokia
   5 Wayside Road,
   Burlington, MA 01803
   Phone: +1 781 993 3923
   Email: man.m.li@nokia.com

   K.C. Norseth
   Enterasys Networks
   2691 S. Decker Lake Lane
   Salt Lake City, Utah 84119
   Phone: +1 801 887 9823
   Email: knorseth@enterasys.com

IPFIX Working Group            Expires August 2002         [Page 22]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


   Reinaldo Penno
   Nortel Networks, Inc.
   2305 Mission College Boulevard
   Building SC9-B1240
   Santa Clara, CA 95134
   Email: rpenno@nortelnetworks.com

   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   69115 Heidelberg
   Germany
   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de

   Cliff Wang
   SmartPipes Inc.
   565 metro Place
   Dublin, OH 43017
   Phone: +1 614 923 6241
   Email: cwang@smartpipes.com

   Kevin Zhang
   XACCT Technologies, Inc.
   2900 Lakeside Drive
   Santa Clara, CA 95054
   Phone +1 301 992 4697
   Email: kevin.zhang@xacct.com

   Tanja Zseby
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin, Germany
   Phone: +49 30 3463 7153
   Email: zseby@fokus.gmd.de



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

IPFIX Working Group            Expires August 2002         [Page 23]

INTERNET-DRAFT   draft-ietf-ipfix-architecture-00.txt  Feb. 22, 2002


12. Issues


12.1. MIBS

   An SNMP MIB module should be made available to monitor
   the various components and to define, if any, standard
   configuration objects (Mike Mcfadden, Dave Harrington)


12.2.Relationship to RTFM

   To be filled ouT
IPFIX Working Group            Expires August 2002         [Page 24]


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