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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 3917

Internet Draft                                                J. Quittek
<draft-ietf-ipfix-reqs-00.txt>                          NEC Europe Ltd.
Expires: May 2002
                                                                T. Zseby
                                                                G. Carle
                                                               S. Zander
                                                               GMD FOKUS

                                                               B. Claise
                                                           Cisco Systems

                                                           November 2001

              Requirements for IP Flow Information Export
                     <draft-ietf-ipfix-reqs-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.

   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 memo defines requirements for the export of measured IP flow
   information out of routers, traffic measurement probes and
   middleboxes.

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.



Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 1]

Internet Draft             IPFIX Requirements               October 2001


Table of Content

   1. Introduction
   1.1. IP Flows
   2. Applications Requiring IP Flow Information Export
   2.1 Usage-based Accounting
   2.2 Traffic Profiling
   2.3 Traffic Engineering
   2.4 Attack/Intrusion Detection
   2.5 Network Surveillance
   2.6 QoS Monitoring
   3. Distinguishing Flows
   3.1. Interfaces
   3.2. IP Header Fields
   3.3. Transport Header Fields
   3.4. MPLS Label
   3.5. DiffServ Code Point
   3.6. Header Compression and Encryption
   4. Metering Process
   4.1. Reliability
   4.2. Sampling
   4.3. Timestamps
   4.4. Time Synchronization
   4.5. Timeout
   4.6. Ignore Port Copy
   5. Data Export
   5.1. Information Model
   5.2. Data Model
   5.3. Data Transfer
   5.3.1. Congestion Awareness
   5.3.2. Reliability
   5.3.3. Security
   5.4. Push and Pull Mode Reporting
   5.5. Regular Reporting Interval
   5.6. Notification on Specific Events
   5.7. Anonymization
   6. Configuration
   7. General Requirements
   7.1. Openness
   7.2. Scalability concerning measuring devices
   7.3. Several Data Collectors
   8. Security Considerations
   9. Acknowledgements
   10. References
   11. Authors' Addresses
   Appendix: Derivation of Requirements form Target Applications





Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 2]

Internet Draft             IPFIX Requirements               October 2001


1. Introduction

   There are several applications that require flow-based IP traffic
   measurements.  Such measurements could be performed by a router while
   forwarding the traffic, by a middlebox [MIDBOXTAX], or by a traffic
   measurement probe attached to a line or a monitored port. This memo
   defines requirements for exporting traffic flow information out of
   these boxes for further processing by applications located on other
   devices. In section 2 a selection of such applications is presented.
   The following sections list requirements derived from these
   applications.

1.1 IP Flows

   There are several definitions of the term 'flow' being used by the
   Internet community. Within this document we use the following one:

      A flow is 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 derived from the
      data contained in the packet and from the packet treatment at the
      observation point.

   The observation point may be a network interface of a device or an
   entire router, a probe, or a middlebox with several interfaces.
   Properties derived from packet treatment include for example the
   interface at which the packet arrived, the interface the packet will
   be forwarded to and potentially some other information.

   Which flow properties are considered for distinguishing flows is part
   of the requirements definition and will be addressed below. The above
   definition covers the range from a flow containing all packets
   observed at a network interface to a flow consisting of just a single
   packet between two applications with a specific sequence number. We
   do not constrain the definition of a flow in terms of unidirectional
   or bidirectional traffic at this point. Please note that our flow
   definition does not match a general application-level end-to-end
   stream. However, an application may derive properties of application-
   level streams by processing measured flow data.


2. Applications Requiring IP Flow Information Export

   The following list contains a selection of applications requiring IP
   flow information export. Because requirements for flow export listed
   in further sections below are derived from these applications, their
   selection is crucial. The goal of this requirements document is not
   to cover all possible applications with all their flow export



Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 3]

Internet Draft             IPFIX Requirements               October 2001


   requirements, but to cover applications which are considered to be of
   significant importance in today's or future IP networks, and for
   which requirements can be met with reasonable technical effort.

   Please note, that the described applications can have a large number
   of differing implementations. Requirement details or the weighting of
   requirements could differ for specific implementations. Therefore we
   derive the requirements from the general functionality of the
   selected applications. Furthermore, the list of applications should
   lead to a better understanding of the requirements which is
   particularly important when designing or implementing a traffic flow
   measuring device.

2.1 Usage-based Accounting

   Several new business models for selling IP service and IP-based
   services are currently under investigation. Beyond flat rate services
   which do not need accounting, accounting for these models can be
   based on time or volume. Accounting data can serve as input for
   billing systems. Accounting can be performed per user or per user
   group, it can be performed just for basic IP service or individually
   per high-level service and/or per content type delivered. For
   advanced/future services, accounting may also be performed per class
   of service, per application, per time of day, per used (label
   switched) path, etc.

2.2 Traffic Profiling

   Traffic profiling is a process of characterizing IP flows and flow
   aggregates by using a model that represents key parameters of the
   flow such as flow duration, volume, time and burstiness. It is a
   prerequisite for network planning, network dimensioning, trend
   analysis, developing business models, and other activities. It
   heavily depends on the particular traffic profiling objective(s) what
   statistics and accuracy are required from the measurements. Typical
   information needed for traffic profiling are the distribution of used
   services and protocols in the network, the amount of packets of a
   specific type (e.g. percentage of IPv6 packets) and specific flow
   profiles.

   Since objectives for traffic profiling can vary, this application
   requires a high flexibility of the measurement infrastructure,
   especially regarding the options for measurement configuration and
   packet classification.

2.3 Traffic Engineering

   Traffic Engineering (TE) comprises methods for measurement, modeling,



Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 4]

Internet Draft             IPFIX Requirements               October 2001


   characterization and control of a network. The goal of TE is the
   optimization of network resource utilization and traffic performance
   [RFC2702].  Since control and administrative reaction to measurement
   results requires access to the involved network nodes, TE mechanisms
   and the required measurement function usually are performed within
   one administrative domain.  Typical parameters required for TE are
   link utilization, load between specific network nodes, number, size
   and entry/exit points of the active flows and routing information.

2.4 Attack/Intrusion Detection

   Capturing of flow information plays an important role for network
   security, both for detection of security violation, and for
   subsequent defense. In case of a Denial of Service (DOS) attack, flow
   monitoring can allow detection of unusual load situations or
   suspicious flows. In a second step, flow analysis can be performed in
   order to gather information about the attacking flows, and for
   deriving a defense strategy.

   Intrusion detection is a potentially more demanding application which
   would not only look at specific characteristics of flows, but that
   may also use a stateful packet flow analysis for detecting specific,
   suspicious activities, or unusually frequent activities. Such
   activities may be characterized by specific communication patterns,
   detectable by characteristic sequences of certain packet types.

2.5 Network Surveillance

   This application class requires collection and storage of information
   that characterizes flows, and possibly also the collection and
   storage of selected packets. One obvious use for network surveillance
   is the collection of evidence of illegal activities for the purpose
   of law enforcement. As the data collected for the purpose of network
   surveillance contains sensitive information, adequate security
   mechanisms are required in order to avoid misuse of the sensitive
   information.

2.6 QoS Monitoring

   QoS monitoring is the non-intrusive (passive) measurement of quality
   parameters for single flows or traffic aggregates.  In contrast to
   intrusive (active) measurements, non-intrusive measurements utilize
   the existing traffic in the network for QoS analysis. Since no test
   traffic is sent, non-intrusive measurements can only be applied in
   situations where the traffic of interest is already present in the
   network. One example application is the validation of QoS parameters
   negotiated in a service level specification (SLS).




Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 5]

Internet Draft             IPFIX Requirements               October 2001


   Non-intrusive measurements cannot provide the kind of controllable
   experiments that can be achieved with active measurements. On the
   other hand non-intrusive measurements do not suffer from undesired
   side effects caused by sending test traffic (e.g. additional load,
   "Heisenberg" effects, potential differences in treatment of test
   traffic and real customer traffic)

   QoS monitoring often requires the correlation of data from multiple
   measurement instances  (e.g. for measuring one-way metrics). This
   requires proper clock synchronization of the involved measurement
   instances. For some measurements packet events at the different
   measurement points must be correlated. For this, the provisioning of
   post-processing functions (e.g. the generation of packet IDs) at the
   measurement instances would be useful.  Furthermore, QoS monitoring
   can lead to a huge amount of measurement result data. Therefore it
   would highly benefit from mechanisms to reduce the measurement data,
   like aggregation of results and flow sampling.


3. Distinguishing Flows

   Packets are mapped to flows by evaluating their properties. Packets
   with common properties are considered to belong to the same flow. A
   packet showing at least one difference in the set of properties is
   considered to belong to a different flow.

   The following subsections list a set of properties which a measuring
   device MUST, SHOULD, or MAY be able to evaluate for mapping packets
   to flows. Please note that requiring the ability to evaluate a
   certain property does not imply that this property must be evaluated
   for each packet.

   Which combination of properties is evaluated for a particular
   measurement and how these properties are evaluated depends on the
   capabilities of the measuring device and on its configuration. The
   configured choice of evaluated properties strongly depends on the
   environment and purpose of the measurement and on the information
   required by the data collector.

   For specific deployments, only a subset of the REQUIRED properties
   listed below could be used to distinguish flows, in order to
   aggregate the flow records and reduce the number of flow records
   exported. On the other hand, some other deployments will require to
   distinguish flows by some extra parameters, like for example the TTL
   field of the IP header or the BGP Autonomous Systems.






Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 6]

Internet Draft             IPFIX Requirements               October 2001


3.1. Interfaces

   The measuring device MUST be able to separate flows by the incoming
   interface or by the outgoing interface or by both of them.

3.2. IP Header Fields

   The measuring device MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address (MUST)
      2. destination IP address (MUST)
      3. transport protocol type (MUST)
      4. IP version number (SHOULD)
         This requirement only applies if the device is supporting
         more than one version of IP.

   For source address and destination address separating by full match
   MUST be supported as well as separation by a partial match (for
   example subnet masking).

3.3. Transport Header Fields

   The measuring device MUST be able to separate flows by the port
   numbers of the transport header in case of TCP or UDP being used as
   transport protocol. Both, source and destination port number MUST be
   supported for distinguishing flows, individually as well as in
   combination.

3.4. MPLS Label

   If the measuring device supports Multiprotocol Label Switching (MPLS,
   see [RFC3031]), then the measuring device MUST be able to separate
   flows by the MPLS label.

3.5. DiffServ Code Point

   If the measuring device supports Differentiated Services (DiffServ),
   then the measuring device MUST be able to separate flows by the
   DiffServ Code Point (DSCP, see [RFC2474]).

3.6. Header Compression and Encryption

   If header compression or encryption is used, the measuring device
   might not be able to access all header fields. In such a case only
   end points of header compression or of packet encryption are expected
   to meet the requirements stated in this section 3.




Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 7]

Internet Draft             IPFIX Requirements               October 2001


4. Metering Process

   The following are requirements for the metering process. They
   describe the requirements for the process at the measurement
   instance. All measurements MUST be conducted from the point of view
   of the observation point.

4.1. Reliability

   The measurement process MUST either be reliable or missing
   reliability MUST be known and indicated. The measurement process is
   reliable, if each packet passing the observation point is measured
   according to the configuration of the measuring device. If, e.g. due
   to some overload, not all passing packets can be included into the
   measurement process, then it SHOULD be stored at the measuring
   device, that flows might be measured inaccurately.

4.2. Sampling

   The measuring device MAY support measuring traffic by packet
   sampling. If sampling is supported the sampling method and its
   parameters MUST be well defined. The device MAY offer a mechanism for
   automatically switching to sampling (or to a more coarse flow
   definition) in case of certain events, such as device overloaded. If
   automatic switch to sampling or automated switch of the sampling rate
   is supported, the events triggering a switch and the chosen sampling
   method and parameters after a switch MUST be well defined.

4.3. Timestamps

   The measuring device MUST be able to generate a timestamp for each
   observed packet. Please note that section 5.1 requires to offer
   reporting a timestamp for the first and the last observed packet of a
   flow. Therefore, the measuring device MUST be able to store at least
   two timestamps per flow.

4.4. Time Synchronization

   Different measuring device(s) and data collector(s) SHOULD be time
   synchronized between each other. NTP is a possible way of achieving
   this. Where there are so many types of synchronization between
   devices and collectors, the synchronization of the devices and
   collectors cannot be defined as part of IPFIX. The method for time
   synchronization is not in the scope of IPFIX.







Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 8]

Internet Draft             IPFIX Requirements               October 2001


4.5. Timeout

   The measuring device MUST be able to detect flow timeout. A flow is
   considered to be timed out if no packet of this flow has been
   observed for a given timeout interval. The measuring device MAY
   support means for detecting the end of a flow before a time out
   occurs, for example by detecting the FIN or RST bits in a TCP
   connection.

4.6. Ignore Port Copy

   The measuring device MAY be able to ignore packets which are
   generated by a port copy function acting at the same device.


5. Data Export

   The following are requirements for exporting measured flow data out
   of the measuring device. Beside requirements on the data transfer, we
   separate requirements concerning the information model from
   requirements concerning the data model.  Furthermore, we list
   requirements on reporting times and events and on anonymization of
   records.

5.1. Information Model

   The information model for a flow measurement report is the list of
   attributes of a flow to be contained in the report (including the
   semantics of the attributes).

   This section lists attributes a measuring device MUST or MAY be able
   to report. This does not imply that a report MUST contain all
   REQUIRED attributes, but that it MUST be possible to configure the
   device in a way that all of the REQUIRED attributes are contained in
   a report for each measured flow.

   Beyond that, the device might offer to report also further attributes
   not mentioned here. A particular report may contain some of the
   "REQUIRED" attributes as well as some additional ones, for example
   covering future technologies.

   The measuring device MUST be able to report the following attributes
   for each measured flow:

      1. IP version number
         This requirement only applies if the device is supporting more
         than one version of IP.
      2. source IP address



Quittek et al.        draft-ietf-ipfix-reqs-00.txt              [Page 9]

Internet Draft             IPFIX Requirements               October 2001


      3. destination IP address
      4. transport type
      5. source port number
      6. destination port number
      7. packet counter
         If a packet is fragmented, each fragment is counted as an
         individual packet.
      8. observed byte counter
      9. in case of IPv4: Type of Service
     10. in case of IPv6: Flow Label
     11. if BGP is supported: BGP AS#
     12. if MPLS is supported: MPLS label
     13. if DiffServ is supported: DSCP
     14. timestamp of the first packet observed
     15. timestamp of the last packet observed
     16. if sampling is used: sampling method
     17. if sampling is used: sampling parameters
     18. unique identifier of the observation point
     19. unique identifier of the measuring device

   The measuring device MAY be able to report the following attributes
   for each measured flow:
     20. Time To Live
     21. IP header flags
     22. TCP header flags
     23. dropped packet counter
         If a packet is fragmented, each fragment is counted as an
         individual packet. This requirements does not apply to probes where
         the value of this counter is always zero.
     24. fragmented packet counter
         counter of all packets for which the fragmented bit is set in
         the IP header
     25. multicast replication factor
         the number of outgoing packets originating from a single
         incoming multicast packet

5.2 Data Model

   The data model describes how information is represented in flow
   records. The data model used for exporting flow data MAY be flexible
   concerning the flow attributes contained in reports. A flexible
   record format would offer the possibility of defining records in a
   flexible (customizable) way regarding the number and type of report
   attributes.

   The data model MUST be extensible for future attributes to be added.
   Even if a set of attributes is fixed in the flow record, the data
   model MUST provide a way of extending the record by configuration or



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 10]

Internet Draft             IPFIX Requirements               October 2001


   for certain implementations.

   The Data Model SHOULD be independent of the underlying transport
   protocol, i.e. the data transfer.

5.3. Data Transfer

   Requirements for the data transfer include reliability and security
   requirements. These requirements do not apply to the measuring device
   alone, but also to the transport network. Consequently, the
   measurement device does not necessarily have to guarantee that all
   requirements are met. Particularly if the security requirements are
   already guaranteed by the network used for data transfer, then these
   requirements do not have to be considered anymore by the measuring
   device. Therefore, these requirements are OPTIONAL for the measuring
   device, although they may be REQUIRED for the data transfer as
   specified in the appendix.

5.3.1. Congestion Awareness

   For the data transfer a congestion aware protocol MUST be supported.

5.3.2. Reliability

   Absence of reliability of the data transfer MUST be indicated
   covering packet loss and packet reordering.

   Please note that if an unreliable transport protocol is used,
   reliability can be provided by higher layers. In such a case only
   lack of overall reliability MUST be indicated. For example reordering
   could be dealt with by adding a sequence number to each packet.

5.3.3. Security

   Confidentiallity of transferred IPFIX data SHOULD be ensured.

   Integrity of transferred IPFIX data MUST be ensured.

   Authenticity of transferred IPFIX data MUST be ensured.












Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 11]

Internet Draft             IPFIX Requirements               October 2001


5.4. Push and Pull Mode Reporting

   In general, there are two ways of deciding on reporting times: push
   mode and pull mode. In push mode, the measuring device decides
   without an external trigger on when to send a report on measured
   flows.  In pull mode, sending a report is triggered by an explicit
   request from a data collector or some other receiver of flow records.
   The measuring device MUST support push mode reporting, it MAY support
   pull mode reporting.

5.5. Regular Reporting Interval

   The measuring device SHOULD be capable of reporting measured traffic
   data regularly according to a given interval length.

5.6. Notification on Specific Events

   The measuring device MAY be capable of sending notifications to a
   consumer of measure data, if a specific event occurs. Such an event
   might be the arrival of the first packet of a new flow, or the
   termination of a flow after flow timeout.

5.7. Anonymization

   The measuring device MAY be capable of anonymizing source and
   destination IP addresses in flow data before exporting them. It MAY
   support anonymization of port numbers and other fields. Please note
   that anonymization is not originally an application requirement, but
   derived from general requirements for treatment of traffic within a
   network.


6. Configuration

   The measuring device MUST provide a way of configuring the traffic
   measurement and the traffic data export remotely. The following
   parameters SHOULD be configurable:

      1. specification of the observation point, e.g. a list of
         interfaces to be monitored.
      2. specifications of flows to be measured
      3. reporting data format
         Specifying the reporting data format SHOULD include a selection
         of attributes to be reported for each flow.

   The following parameters MAY be configurable:

      4. notifications



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 12]

Internet Draft             IPFIX Requirements               October 2001


      5. flow timeouts
      6. sampling method and parameters, if feature is supported
      7. flow anonymization, if feature is supported

   The measuring device SHOULD support security of remote configuration
   including confidentiality, integrity and authenticity.


7. General Requirements

7.1. Openness

   IPFIX specifications SHOULD be open to future technologies. This
   includes extensibility of configuration of measurement and reporting
   as well as extensibility of the reporting information model and data
   model.

7.2. Scalability concerning measuring devices

   Data collection from hundreds of different measuring devices MUST be
   supported. The data collector MUST be able to distinguish several
   hundred measuring devices by their identifiers.

7.3. Several Data Collectors

   The measuring device MAY be able to export flow information to more
   than one data collector.


8. Security Considerations

   This document describes requirements for IP Flow Information Export
   (IPFIX). It therefore also states the required security features for
   a future IPFIX protocol. Nevertheless, the suggestion of solutions
   for achieving the security properties is out of scope of this
   document and will be part of future IPFIX documents that specify
   IPFIX architecture and protocol.

   Like other requirements, the security requirements differ for the
   considered applications. The incentive to modify data collected for
   accounting or intrusion detection for instance is usually higher than
   the incentive to change data collected for traffic profiling.
   Therefore the required security features are listed per application.
   Furthermore, the security requirements also differ with regard to the
   environment in which an IPFIX protocol is used (e.g. intra- or inter-
   domain). Some of these issues are part of the IPFIX architecture and
   with this out of scope of this document. Therefore this document also
   tries to consider security threats that can only occur in an insecure



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 13]

Internet Draft             IPFIX Requirements               October 2001


   environment (e.g. where it can not be excluded, that an attacker
   might gain access to the network).

   Several security hazards also occur if the measurement process is
   configured remotely (e.g. access to the measurement process, forgery
   of configuration information, etc.). Nevertheless, this document
   specifies only what parameters SHOULD or MAY be configurable for the
   measurement process. It does not deal with requirements for a
   protocol for measurement configuration. Therefore security
   considerations regarding the measurement configuration are out of
   scope of this document.

   The following potential security hazards for an IPFIX protocol can be
   identified:

       - Disclosure of IP flow information data
         It may be required to keep measurement records confidential
         between the involved parties. Observation of IP flow
         information data gives an attacker information about the active
         flows in the network, communication endpoints and traffic
         patterns. This information can not only be used to spy out user
         behavior but also to plan and conceal future attacks. Therefore
         the requirements document recommends to ensure the
         confidentiality of the transferred data. This can be done for
         instance by encryption.

         Furthermore, features for anonymization may be provided by the
         future IPFIX protocol. With this communication endpoints can be
         kept confidential. Anonymization is also a useful feature to
         allow measurements (e.g. by a third party) without violating
         privacy protection.

       - Forgery of exported IP flow information data
         Especially for applications like accounting or intrusion
         detection there are strong incentives (e.g. save money or
         prevent detection of an attack) to forge exported IP flow
         information records. This can be done either by altering data
         on the path or by sending records from a device that pretends
         to be the measurement device. In order to make the IPFIX
         protocol resistant against such attacks this document requires
         to ensure authenticity and integrity of the data for the IPFIX
         data transfer.

         Special caution is required if security applications rely on
         IPFIX data With forgery of exported IP flow information data it
         is possible to trick on security applications. With this it can
         be for instance possible to pretend that a DoS attack happens
         without even launching a real attack.



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 14]

Internet Draft             IPFIX Requirements               October 2001


       - Denial of Service (DoS) attacks
         DoS attacks on routers or other middleboxes that have the IPFIX
         protocol implemented would also affect the IPFIX protocol and
         impair the sending of IPFIX records. Nevertheless, since such
         hazards are not induced specifically by the IPFIX protocol the
         prevention of such attacks is out of scope of this document.

         IPFIX itself causes the following potential hazards for DoS
         attacks. It is always possible to overload the measurement
         device if it expects the reception of traffic. For IPFIX this
         can occur in two cases. First, if the protocol supports the
         pull mode (which is one option in this document) and expects
         requests. Secondly, if data is expected for remote measurement
         configuration. The first case could be prevented by ensuring
         authenticity for IPFIX requests. The second case should be
         addressed for the specification of an IPFIX configuration
         protocol and therefore is out of scope of this document.

         Also IPFIX collectors can become  target of an DoS attack. This
         can be done by sending IPFIX data from a malicious device that
         pretends to be an IPFIX source. This can be  prevented by
         ensuring authenticity of IPFIX data as stated in this document.
         It is also possible that collectors are flooded with IPFIX
         record from an authorized IPFIX devices for which the
         configuration was altered. Furthermore, malicious configuration
         or forgery of exported data can cause a loss or re-direction of
         IPFIX data (e.g. if destination addresses for flow records are
         modified). This can lead to a disruption of upper layer
         services (accounting, intrusion detection, etc.)  due to lack
         of IPFIX records. This can be prevented by controlling
         configuration access and by ensuring the integrity of exported
         data.


9. Acknowledgements

   We like to thank all the people contributing to the requirements
   discussion on the mailing list, particularly K.C. Norseth from
   Enterasys for a lot of valuable comments and for suggesting several
   last minute edits of this document.


10. References

   [MIDBOXTAX] B. Carpenter, "Middleboxes: taxonomy and issues",
             draft-carpenter-midtax-01.txt, work in progress.





Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 15]

Internet Draft             IPFIX Requirements               October 2001


   [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
             Switching Architecture", RFC 3031, January 2001.

   [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition
             of the Differentiated Services Field (DS Field) in the IPv4
             and IPv6 Headers", RFC 2474, December 1998.

   [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
              "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC2274] U. Blumenthal, B. Wijnen "User-based Security Model (USM)
             for version 3 of the Simple Network Management Protocol
             (SNMPv3), RFC 2274, January 1998.


11. Authors' Addresses

   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   69115 Heidelberg
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de


   Tanja Zseby
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7153
   Email: zseby@fokus.gmd.de


   Georg Carle
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7149
   Email: carle@fokus.gmd.de





Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 16]

Internet Draft             IPFIX Requirements               October 2001


   Sebastian Zander
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin
   Germany

   Phone: +49 30 3463 7287
   Email: zander@fokus.gmd.de


   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com


Appendix: Derivation of Requirements form Target Applications

   The following table documents, how the requirements stated in
   sections 3-7 are derived from requirements of the applications listed
   in section 2.

   Used abbreviations:
      M = MUST
      S = SHOULD
      O = MAY (OPTIONAL)
      - = DONT CARE

   -----------------------------------------------------------------------.
      IPFIX                                                               |
   ----------------------------------------------------------------.      |
   F: QoS Monitoring                                               |      |
   ----------------------------------------------------------.     |      |
   E: Network Surveillance                                   |     |      |
   ----------------------------------------------------.     |     |      |
   D: Attack/Intrusion Detection                       |     |     |      |
   ----------------------------------------------.     |     |     |      |
   C: Traffic Engineering                        |     |     |     |      |
   ----------------------------------------.     |     |     |     |      |
   B: Traffic Profiling                    |     |     |     |     |      |
   ----------------------------------.     |     |     |     |     |      |
   A: Usage-based Accounting         |     |     |     |     |     |      |
   ----------------------------.     |     |     |     |     |     |      |
                               |     |     |     |     |     |     |      |



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 17]

Internet Draft             IPFIX Requirements               October 2001


   | Sect. |    Requirement    |  A  |  B  |  C  |  D  |  E  |  F  | IPFIX|
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.    | DISTINGUISHING FLOWS                                         |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.    |Combination of     |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |required attributes|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.1.  |in/out IF          |  S  |  M  |  M  |  S  |  S  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.2.  |src/dst address    |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.2.  |Masking of IP      |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |adresses           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.2.  |transport protocol |  M  |  M  |  -  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.2.  |version field      |  -  |  S  |  S  |  O  |  O  |  O  |  S   |
   |       |                   |     |     | (b) |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.3.  |src/dst port       |  M  |  M  |  -  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.4.  |MPLS label (a)     |  S  |  S  |  M  |  O  |  -  |  S  |  M   |
   |       |                   |     |     | (c) |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 3.5.  |DSCP (a)           |  M  |  S  |  M  |  O  |  -  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.    |METERING PROCESS                                              |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.1.  |Reliability        |  M  |  S  |  S  |  S  |  M  |  S  |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+  M   |
   | 4.1.  |Indication of      |  -  |  M  |  M  |  M  |  -  |  M  |      |
   |       |missing reliability|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.2.  |Sampling (g)       |  O  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.2.  |Dynamic sampling   |  O  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.3.  |Timestamping at    |  M  |  O  |  O  |  S  |  S  |  M  |  M   |
   |       |measurement device |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.4.  |Time synchroniz.   |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.5.  |Flow timeout       |  M  |  S  |  -  |  O  |  O  |  O  |  M   |
   |       |                   | (d) |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 4.6.  |Ignore port copy   |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|




Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 18]

Internet Draft             IPFIX Requirements               October 2001


   | Sect. |    Requirement    |  A  |  B  |  C  |  D  |  E  |  F  | IPFIX|
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.    |DATA EXPORT                                                   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |INFORMATION MODEL                                             |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |IP Version         |  -  |  M  |  M  |  O  |  O  |  O  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |src/dst address    |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |transport protocol |  M  |  M  |  -  |  M  |  O  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |src/dst transport  |  M  |  M  |  -  |  M  |  O  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Packet counter (h) |  S  |  M  |  M  |  S  |  -  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Byte counter       |  M  |  M  |  M  |  S  |  -  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Dropped Packet     |  O  |  M  |  M  |  S  |  -  |  M  |  M   |
   |       |Counter (h,i)      |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |ToS Byte           |  M  |  S  |  M  |  O  |  O  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Flow Label         |  M  |  S  |  M  |  O  |  O  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |BGP AS#            |  -  |  S  |  M  |  -  |  -  |  -  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |MPLS label (a)     |  S  |  S  |  M  |  O  |  -  |  S  |  M   |
   |       |                   |     |     | (c) |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |DSCP (a)           |  M  |  S  |  M  |  O  |  -  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Timestamps for     |  M  |  O  |  O  |  S  |  O  |  S  |  M   |
   |       |first/last packet  |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Sampling methods   |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |& parameters (k)   |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |observation point  |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |identifier         |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |measuring device   |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |identity           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |TTL                |  O  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |IP header flags    |  -  |  O  |  O  |  O  |  -  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 19]

Internet Draft             IPFIX Requirements               October 2001


   | Sect. |    Requirement    |  A  |  B  |  C  |  D  |  E  |  F  | IPFIX|
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |TCP header flags   |  -  |  O  |  O  |  O  |  -  |  -  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Fragment counter   |  -  |  O  |  O  |  O  |  _  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Multicast          |  O  |  O  |  O  |  -  |  -  |  -  |  O   |
   |       |replication factor |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.1.  |Flow configuration |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.2.  |DATA MODEL                                                    |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.2.  |Flexibility        |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.2.  |Extensibility      |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.  |DATA TRANSFER                                                 |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.1.|Congestion aware   |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.2.|Reliability        |  M  |  S  |  S  |  S  |  M  |  S  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.3.|Confidentiality    |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.4.|Integrity          |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.3.5.|Authenticity       |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.  |REPORTING TIMES                                               |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.  |Push mode          |  M  |  O  |  O  |  M  |  O  |  S  |  M   |
   |       |                   |     | (e) | (e) |     | (e) |(e,f)|      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.  |Pull mode          |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |                   |     | (e) | (e) |     | (e) | (e) |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.4.1.|Regular Interval   |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.6.  |Notifications      |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 5.7.  |Anonymization      |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|








Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 20]

Internet Draft             IPFIX Requirements               October 2001


   | Sect. |    Requirement    |  A  |  B  |  C  |  D  |  E  |  F  | IPFIX|
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |CONFIGURATION                                                 |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Measurement |  M  |  M  |  M  |  M  |  M  |  M  |  M   |
   |       |& Data Export      |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Observation |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |       |Point              |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Flow        |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |       |Specifications     |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Report      |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |       |Data Format        |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config             |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |Notifications      |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Flow        |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |Timeouts           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config Sampling    |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |                   |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config             |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |Anonymization      |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 6.    |Config             |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |Security           |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 7.    |GENERAL REQREQUIREMENTS                                       |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 7.1.  |Openness           |  S  |  S  |  S  |  S  |  S  |  S  |  S   |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 7.2.  |Scalability:       |     |     |     |     |     |     |      |
   |       |data collection    |  M  |  S  |  M  |  O  |  M  |  S  |  M   |
   |       |from hundreds of   |     |     |     |     |     |     |      |
   |       |measurement devices|     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|
   | 7.3.  |Several Data       |  O  |  O  |  O  |  O  |  O  |  O  |  O   |
   |       |Collectors         |     |     |     |     |     |     |      |
   |-------+-------------------+-----+-----+-----+-----+-----+-----+------|

   Remarks:
     (a) If feature is supported.
     (b) The differentiation of IPv4 and IPv6 is for TE of importance.
         So we tended to make this a MUST. Nevertheless, a SHOULD seems



Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 21]

Internet Draft             IPFIX Requirements               October 2001


         to be sufficient to perform most TE tasks and allows us to have
         a SHOULD for IPFIX instead of a MUST.
     (c) For TE in an MPLS network the label is essential. Therefore a
         MUST is given here leading to a MUST in IPFIX.
     (d) Precise time-based accounting requires reaction to a flow
         timeout.
     (e) Either push or pull has to be supported.
     (f) Required, in order to immediately report drop indications for
         SLA validation.
     (g) If sampling is supported the parameters and methods MUST be
         well defined.
     (h) If a packet is fragmented, each fragment is counted as an
         individual packet.
     (i) Only if measurement is done on data path i.e. has access to
         forwarding decission.
     (k) If sampling is used.



































Quittek et al.        draft-ietf-ipfix-reqs-00.txt             [Page 22]


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