doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc3917.txt b/doc/rfc/rfc3917.txt
new file mode 100644
index 0000000..f71e517
--- /dev/null
+++ b/doc/rfc/rfc3917.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                         J. Quittek
+Request for Comments: 3917                               NEC Europe Ltd.
+Category: Informational                                         T. Zseby
+                                                        Fraunhofer FOKUS
+                                                               B. Claise
+                                                           Cisco Systems
+                                                               S. Zander
+                                                    Swinburne University
+                                                            October 2004
+
+
+          Requirements for IP Flow Information Export (IPFIX)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This memo defines requirements for the export of measured IP flow
+   information out of routers, traffic measurement probes, and
+   middleboxes.
+
+Table of Contents
+
+   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
+        2.1.   IP Traffic Flow. . . . . . . . . . . . . . . . . . . .  3
+        2.2.   Observation Point. . . . . . . . . . . . . . . . . . .  4
+        2.3.   Metering Process . . . . . . . . . . . . . . . . . . .  4
+        2.4.   Flow Record. . . . . . . . . . . . . . . . . . . . . .  5
+        2.5.   Exporting Process. . . . . . . . . . . . . . . . . . .  5
+        2.6.   Collecting Process . . . . . . . . . . . . . . . . . .  5
+   3.   Applications Requiring IP Flow Information Export . . . . . .  6
+        3.1.   Usage-based Accounting . . . . . . . . . . . . . . . .  6
+        3.2.   Traffic Profiling. . . . . . . . . . . . . . . . . . .  7
+        3.3.   Traffic Engineering. . . . . . . . . . . . . . . . . .  7
+        3.4.   Attack/Intrusion Detection . . . . . . . . . . . . . .  7
+        3.5.   QoS Monitoring . . . . . . . . . . . . . . . . . . . .  8
+   4.   Distinguishing Flows. . . . . . . . . . . . . . . . . . . . .  8
+        4.1.   Encryption . . . . . . . . . . . . . . . . . . . . . .  9
+        4.2.   Interfaces . . . . . . . . . . . . . . . . . . . . . .  9
+
+
+
+Quittek, et al.              Informational                      [Page 1]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+        4.3.   IP Header Fields . . . . . . . . . . . . . . . . . . .  9
+        4.4.   Transport Header Fields. . . . . . . . . . . . . . . . 10
+        4.5.   MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
+        4.6.   DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
+   5.   Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
+        5.1.   Reliability. . . . . . . . . . . . . . . . . . . . . . 10
+        5.2.   Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
+        5.3.   Overload Behavior. . . . . . . . . . . . . . . . . . . 11
+        5.4.   Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
+        5.5.   Time Synchronization . . . . . . . . . . . . . . . . . 12
+        5.6.   Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
+        5.7.   Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
+        5.8.   Packet Fragmentation . . . . . . . . . . . . . . . . . 13
+        5.9.   Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
+   6.   Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
+        6.1.   Information Model. . . . . . . . . . . . . . . . . . . 14
+        6.2.   Data Model . . . . . . . . . . . . . . . . . . . . . . 16
+        6.3.   Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
+               6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
+               6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
+               6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
+        6.4.   Push and Pull Mode Reporting . . . . . . . . . . . . . 18
+        6.5.   Regular Reporting Interval . . . . . . . . . . . . . . 18
+        6.6.   Notification on Specific Events. . . . . . . . . . . . 18
+        6.7.   Anonymization. . . . . . . . . . . . . . . . . . . . . 18
+   7.   Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
+        7.1.   Configuration of the Metering Process. . . . . . . . . 19
+        7.2.   Configuration of the Exporting Process . . . . . . . . 19
+   8.   General Requirements. . . . . . . . . . . . . . . . . . . . . 20
+        8.1.   Openness . . . . . . . . . . . . . . . . . . . . . . . 20
+        8.2.   Scalability. . . . . . . . . . . . . . . . . . . . . . 20
+        8.3.   Several Collecting Processes . . . . . . . . . . . . . 20
+   9.   Special Device Considerations . . . . . . . . . . . . . . . . 20
+   10.  Security Considerations . . . . . . . . . . . . . . . . . . . 23
+        10.1.  Disclosure of Flow Information Data. . . . . . . . . . 23
+        10.2.  Forgery of Flow Records. . . . . . . . . . . . . . . . 24
+        10.3.  Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
+   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
+   12.  Appendix: Derivation of Requirements from Applications. . . . 26
+   13.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 31
+        13.1.  Normative References . . . . . . . . . . . . . . . . . 31
+        13.2.  Informative References . . . . . . . . . . . . . . . . 31
+   14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
+   15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+Quittek, et al.              Informational                      [Page 2]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+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 [RFC3234], 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.  They serve as input to the standardization of the IPFIX
+   protocol specifications.
+
+   In section 3, a selection of such applications is presented.  The
+   following sections list requirements derived from these applications.
+
+   In its early discussions the IPFIX Working Group chose to evaluate
+   existing flow export protocols at the same time it was developing
+   this 'requirements' document.
+
+   Flow export, however, is not performed by a protocol acting alone, it
+   also requires a system of co-operating processes.  In producing IPFIX
+   requirements, therefore, the Working Group decided to specify what
+   was required by these various processes - the metering process, the
+   exporting process, etc.  In these specifications we use lower-case
+   for the words must, may, and should, to indicate that IPFIX
+   implementors have some freedom as to how to meet the requirements.
+
+   The Working Group's goal is to produce standards-track RFCs
+   describing the IPFIX information model and export protocol RFCs.  As
+   well as meeting the requirements set out in this document, the
+   information model and protocol documents will provide a full
+   specification of the IPFIX system, and will use uppercase keywords as
+   in [RFC 2119].
+
+2.  Terminology
+
+   The following terminology is used in this document:
+
+2.1.  IP Traffic Flow
+
+   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 defined as a set of IP 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:
+
+
+
+
+
+Quittek, et al.              Informational                      [Page 3]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+      1. one or more packet header field (e.g., destination IP address),
+         transport header field (e.g., destination port number), or
+         application header field (e.g., RTP header fields [RFC3550])
+
+      2. one or more characteristics of the packet itself (e.g., number
+         of MPLS labels, etc.)
+
+      3. one or more of fields derived from packet treatment (e.g., next
+         hop IP address, the output interface, etc.)
+
+   A packet is defined to belong to a flow if it completely satisfies
+   all the defined properties of the flow.
+
+   This 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.
+   Please note that the flow definition does not necessarily match a
+   general application-level end-to-end stream.  However, an application
+   may derive properties of application-level streams by processing
+   measured flow data.  Also, please note that although packet
+   properties may depend on application headers, there is no requirement
+   defined in this document related to application headers.
+
+2.2.  Observation Point
+
+   The observation point is a location in the network where IP packets
+   can be observed.  Examples are a line to which a probe is attached, a
+   shared medium such as an Ethernet-based LAN, a single port of a
+   router, or a set of interfaces (physical or logical) of a router.
+
+   Note that one observation point may be a superset of several other
+   observation points.  For example one observation point can be an
+   entire line card.  This would be the superset of the individual
+   observation points at the line card's interfaces.
+
+2.3.  Metering Process
+
+   The metering process generates flow records.  Input to the process
+   are packet headers observed at an observation point and packet
+   treatment at the observation point, for example the selected output
+   interface.  The metering process consists of a set of functions that
+   includes packet header capturing, timestamping, sampling,
+   classifying, and maintaining flow records.
+
+   The maintenance of flow records may include creating new records,
+   updating existing ones, computing flow statistics, deriving further
+   flow properties, detecting flow expiration, passing flow records to
+   the exporting process, and deleting flow records.
+
+
+
+Quittek, et al.              Informational                      [Page 4]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   The sampling function and the classifying function may be applied
+   more than once with different parameters.  Figure 1 shows the
+   sequence in which the functions are applied.  Sampling is not
+   illustrated in the figure; it may be applied before any other
+   function.
+
+                           packet header capturing
+                                     |
+                                timestamping
+                                     |
+                                     v
+                              +----->+
+                              |      |
+                              | classifying
+                              |      |
+                              +------+
+                                     |
+                          maintaining flow records
+                                     |
+                                     v
+
+                 Figure 1: Functions of the metering process
+
+2.4.  Flow Record
+
+   A flow record contains information about a specific flow that was
+   metered at an observation point.  A flow record contains measured
+   properties of the flow (e.g., the total number of bytes of all
+   packets of the flow) and usually characteristic properties of the
+   flow (e.g., source IP address).
+
+2.5.  Exporting Process
+
+   The exporting process sends flow records to one or more collecting
+   processes.  The flow records are generated by one or more metering
+   processes.
+
+2.6.  Collecting Process
+
+   The collecting process receives flow records from one or more
+   exporting processes.  The collecting process might store received
+   flow records or further process them, but these actions are out of
+   the scope of this document.
+
+
+
+
+
+
+
+
+Quittek, et al.              Informational                      [Page 5]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+3.  Applications Requiring IP Flow Information Export
+
+   This section describes 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
+   requirements, but to cover applications which are considered to be of
+   significant importance in today's and/or future IP networks, and for
+   which requirements can be met with reasonable technical effort.
+
+   The list of applications should lead to a better understanding of the
+   requirements which is particularly important when designing or
+   implementing traffic flow metering functions.  A detailed overview of
+   which requirement was derived from which application(s) is given in
+   the appendix.
+
+   Please note that the described applications can have a large number
+   of differing implementations.  Requirement details or requirement
+   significance (required (must), recommended (should), optional (may))
+   could differ for specific implementations and/or for specific
+   application scenarios.  Therefore we derive the requirements from the
+   general functionality of the selected applications.  Some particular
+   cases will even mandate more stringent requirements than the ones
+   defined in this document.  For example, usage-based accounting is
+   certainly the application that will probably mandate the highest
+   degree of reliability amongst the applications discussed below.  The
+   reliability requirements defined in sections 5.1 and 6.3.2. are not
+   sufficient to guarantee the level of reliability that is needed for
+   many usage-based accounting systems.  Particular reliability
+   requirements for accounting systems are discussed in [RFC2975].
+
+3.1.  Usage-based Accounting
+
+   Several new business models for selling IP services and IP-based
+   services are currently under investigation.  Beyond flat rate
+   services which do not need accounting, accounting 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 (label switched) path used, etc.
+
+
+
+
+
+
+
+
+Quittek, et al.              Informational                      [Page 6]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+3.2.  Traffic Profiling
+
+   Traffic profiling is the process of characterizing IP flows by using
+   a model that represents key parameters of the flows such as flow
+   duration, volume, time, and burstiness.  It is a prerequisite for
+   network planning, network dimensioning, trend analysis, business
+   model development, and other activities.  It depends heavily on the
+   particular traffic profiling objective(s), which statistics, and
+   which accuracy are required from the measurements.  Typical
+   information needed for traffic profiling is 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.
+
+3.3.  Traffic Engineering
+
+   Traffic Engineering (TE) comprises methods for measurement,
+   modelling, 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.
+
+3.4.  Attack/Intrusion Detection
+
+   Capturing 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 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 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.
+
+
+
+Quittek, et al.              Informational                      [Page 7]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+3.5.  QoS Monitoring
+
+   QoS monitoring is the passive measurement of quality parameters for
+   IP flows.  In contrast to active measurements, passive measurements
+   utilize the existing traffic in the network for QoS analysis.  Since
+   no test traffic is sent, passive 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.  Note that
+   passive/active measurement is also referred to as non-
+   intrusive/intrusive measurement or as measurement of
+   observed/synthetic traffic.
+
+   Passive measurements cannot provide the kind of controllable
+   experiments that can be achieved with active measurements.  On the
+   other hand passive measurements do not suffer from undesired side
+   effects caused by sending test traffic (e.g., additional load,
+   potential differences in treatment of test traffic and real customer
+   traffic).
+
+   QoS monitoring often requires the correlation of data from multiple
+   observation points (e.g., for measuring one-way metrics).  This
+   requires proper clock synchronization of the involved metering
+   processes.  For some measurements, flow records and/or notifications
+   on specific events at the different observation points must be
+   correlated, for example the arrival of a certain packet.  For this,
+   the provisioning of post-processing functions (e.g., the generation
+   of packet IDs) at the metering processes would be useful.  Since QoS
+   monitoring can lead to a huge amount of measurement result data, it
+   would highly benefit from mechanisms to reduce the measurement data,
+   like aggregation of results and sampling.
+
+   Please note that not all requirements for QoS monitoring are covered
+   by the IPFIX requirements specified in the following sections.  The
+   IPFIX requirements are targeted at per flow information including
+   summaries of per-packet properties for packets within a flow, but not
+   per-packet information itself.  For example jitter measurement
+   requires timestamping each packet and reporting of all timestamps of
+   a flow, but the IPFIX requirements only cover timestamps of first and
+   last packet of a flow.
+
+4.  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.
+
+
+
+
+Quittek, et al.              Informational                      [Page 8]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   The following subsections list a set of properties which a metering
+   process 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.  In other words, meeting the IPFIX requirements
+   means that the metering process in general must be able, via its
+   configuration, to somehow support to distinguish flows via all the
+   must fields, even if in certain circumstances/for certain
+   applications, only a subset of the must fields is needed and
+   effectively used to distinguish flows.
+
+   Which combination of properties is used for distinguishing flows and
+   how these properties are evaluated depends on the configuration of
+   the metering process.  The configured choice of evaluated properties
+   strongly depends on the environment and purpose of the measurement
+   and on the information required by the collecting process.  But in
+   any case, a collecting process must be able to clearly identify, for
+   each received flow record, which set of properties was used for
+   distinguishing this flow from other ones.
+
+   For specific deployments, only a subset of the required properties
+   listed below can be used to distinguish flows. For example, in order
+   to aggregate the flow records and reduce the number of flow records
+   exported.  On the other hand, some other deployments will require
+   distinguishing flows by some extra parameters, such as the TTL field
+   of the IP header or the BGP Autonomous System number [RFC1771] of the
+   IP destination address.
+
+4.1.  Encryption
+
+   If encryption is used, the metering process might not be able to
+   access all header fields.  A metering process must meet the
+   requirements stated in this section 4 only for packets that have the
+   relevant header fields not encrypted.
+
+4.2.  Interfaces
+
+   The metering process must be able to separate flows by the incoming
+   interface or by the outgoing interface or by both of them.
+
+4.3.  IP Header Fields
+
+   The metering process must be able to separate flows by the following
+   fields of the IP header:
+
+      1. source IP address
+
+      2. destination IP address
+
+
+
+Quittek, et al.              Informational                      [Page 9]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+      3. protocol type (TCP, UDP, ICMP, ...)
+
+   For source address and destination address, separating by full match
+   must be supported as well as separation by prefix match.
+
+   The metering process should be able to separate flows by the IP
+   version number if the observation point is located at a device that
+   is supporting more than one IP version.
+
+4.4.  Transport Header Fields
+
+   The metering process 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.  The metering process should be able to separate
+   flows by the port numbers of the transport header in case of SCTP
+   [RFC2960].
+
+   For separation, both, source and destination port number must be
+   supported for distinguishing flows, individually as well as in
+   combination.
+
+4.5.  MPLS Label
+
+   If the observation point is located at a device supporting
+   Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering
+   process must be able to separate flows by the MPLS label.
+
+4.6.  DiffServ Code Point
+
+   If the observation point is located at a device supporting
+   Differentiated Services (DiffServ) then the metering process must be
+   able to separate flows by the DiffServ Code Point (DSCP, see
+   [RFC2474]).
+
+5.  Metering Process
+
+   The following are requirements for the metering process.  All
+   measurements must be conducted from the point of view of the
+   observation point.
+
+5.1.  Reliability
+
+   The metering process must either be reliable or the absence of
+   reliability must be known and indicated.  The metering process is
+   reliable if each packet passing the observation point is metered
+   according to the configuration of the metering process.  If, e.g.,
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 10]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   due to some overload, not all passing packets can be included into
+   the metering process, then the metering process must be able to
+   detect this failure and to report it.
+
+5.2.  Sampling
+
+   Sampling describes the systematic or random selection of a subset of
+   elements (the sample) out of a set of elements (the parent
+   population).  Usually the purpose of applying sampling techniques is
+   to estimate a parameter of the parent population by using only the
+   elements of the subset.  Sampling techniques can be applied for
+   instance to select a subset of packets out of all packets of a flow
+   or to select a subset of flows out of all flows on a link.  Sampling
+   methods differ in their sampling strategy (e.g., systematic or
+   random) and in the event that triggers the selection of an element.
+   The selection of one packet can for instance be triggered by its
+   arrival time (time-based sampling), by its position in the flow
+   (count-based sampling) or by the packet content (content-based
+   sampling).
+
+   The metering process may support packet sampling.  If sampling is
+   supported, the sampling configuration must be well defined.  The
+   sampling configuration includes the sampling method and all its
+   parameters.
+
+   If the sampling configuration is changed during operation, the new
+   sampling configuration with its parameters must be indicated to all
+   collecting processes receiving the affected flow records.  Changing
+   the sampling configuration includes: adding a sampling function to
+   the metering process, removing a sampling function from the metering
+   process, change sampling method, and change sampling parameter(s).
+
+   In case of any change in the sampling configuration, all flow records
+   metered by the previous sampling configuration must be terminated and
+   exported according to the export configuration.  The metering process
+   must not merge the flow records generated with the new sampling
+   configuration with the flow records generated with the previous
+   sampling configuration.
+
+5.3.  Overload Behavior
+
+   In case of an overload, for example lack of memory or processing
+   power, the metering process may change its behavior in order to cope
+   with the lack of resources.  Possible reactions include:
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 11]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+         -  Reduce the number of flows to be metered.  This can be
+            achieved by more coarse-grained flow measurement or by a
+            restriction of the flow records to a subset of the set of
+            original ones.
+
+         -  Start sampling packets before they are processed by the
+            metering process or - if sampling is already performed -
+            reduce the sampling frequency.
+
+         -  Stop metering.
+
+         -  Reducing the resource usage of competing processes on the
+            same device.  Example: reducing the packet forwarding
+            throughput
+
+   Overload behavior is not restricted to the four options listed above.
+   But in case the overload behavior induces a change of the metering
+   process behavior, the overload behavior must be clearly defined.
+
+   For some flows, the change of behavior might have an impact on the
+   data that would be stored in the associated flow records after the
+   change, for example if the packet classification is changed or the
+   sampling frequency.  These flows must be considered as terminated and
+   the associated flow records must be exported separately from new ones
+   generated after the behavior change.  The terminated flow records and
+   new ones generated after the behavior change must not be merged by
+   the metering process.  The collecting process must be able to
+   distinguish the affected flow records generated before and after the
+   change of behavior.  This requirement does not apply to flows and
+   associated flow records not affected by the change of metering
+   process behavior.
+
+5.4.  Timestamps
+
+   The metering process must be able to generate timestamps for the
+   first and the last observation of a packet of a flow at the
+   observation point.  The timestamp resolution must be at least the one
+   of the sysUpTime [RFC3418], which is one centisecond.
+
+5.5.  Time Synchronization
+
+   It must be possible to synchronize timestamps generated by a metering
+   process with Coordinated Universal Time (UTC).
+
+   Note that the possibility of synchronizing timestamps of each single
+   metering process with UTC implies the possibility of synchronizing
+   timestamps generated by different metering processes.
+
+
+
+
+Quittek, et al.              Informational                     [Page 12]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   Note that this does not necessarily imply that timestamps generated
+   by the metering process are UTC timestamps.  For example, this
+   requirement can be met by using local system clock values as
+   timestamps and adding an additional timestamp when exporting a report
+   to a collecting process.  Then the collecting process can synchronize
+   the timestamps by calculating the offset between UTC and the system
+   clock of the metering process.
+
+5.6.  Flow Expiration
+
+   The metering process must be able to detect flow expirations.  A flow
+   is considered to be expired if no packet of this flow has been
+   observed for a given timeout interval.  The metering process may
+   support means for detecting the expiration of a flow before a timeout
+   occurs, for example by detecting the FIN or RST bits in a TCP
+   connection.  The procedure for detecting a flow expiration must be
+   clearly defined.
+
+5.7.  Multicast Flows
+
+   For multicast flows containing packets replicated to multiple output
+   interfaces, the metering process should be able to maintain discrete
+   flow records per different output interface.  For example, the
+   metering process should be able to report an incoming multicast
+   packet that is replicated to four output interfaces in four different
+   flow records that differ by the output interface.
+
+5.8.  Packet Fragmentation
+
+   In case of IP packet fragmentation and depending on the
+   classification scheme, only the zero-offset fragment of a single
+   initial packet might contain sufficient information to classify the
+   packet.  Note that this fragment should be the first one generated by
+   the router imposing the fragmentation [RFC791], but might not be the
+   first one observed by the IPFIX device, due to reordering reasons.
+   The metering process may keep state of IP packet fragmentation in
+   order to map fragments that do not contain sufficient header
+   information correctly to flows.
+
+5.9.  Ignore Port Copy
+
+   The metering process may be able to ignore packets which are
+   generated by a port copy function acting at the device where the
+   observation point of a flow is located.
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 13]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+6.  Data Export
+
+   The following are requirements for exporting flow records out of the
+   exporting process.  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 notification on specific events,
+   and on anonymization of flow records.
+
+6.1.  Information Model
+
+   The information model for the flow information export is the list of
+   attributes of a flow to be contained in the report (including the
+   semantics of the attributes).
+
+   This section lists attributes an exporting process must, should or
+   may be able to report.  This does not imply that each exported flow
+   record must contain all required attributes.  But it implies that it
+   must be possible to configure the exporting process in a way that the
+   information of all required attributes can be transmitted from the
+   exporting process to the receiving collecting process(es) for each
+   exported flow.
+
+   In other words, meeting the IPFIX requirements means that the
+   exporting process in general must be able, via its configuration, to
+   somehow support to report all the must fields, even if in certain
+   circumstances or for certain applications, only a subset of the set
+   of all must fields is needed and effectively reported.
+
+   Beyond that, the exporting process might offer to report further
+   attributes not mentioned here.  A particular flow record may contain
+   some of the "required" attributes as well as some additional ones,
+   for example covering future technologies.
+
+   This document does not impose that the following attributes are
+   reported for every single flow record, especially for repetitive
+   attributes.  For example, if the observation point is the incoming
+   packet stream at the IP interface with the ifIndex value 3, then this
+   observation point does not have to be exported as part of every
+   single flow record.  Exporting it just once might give sufficient
+   information to the collecting process.
+
+   The exporting process must be able to report the following attributes
+   for each metered flow:
+
+      1.  IP version number
+          This requirement only applies if the observation point is
+          located at a device supporting more than one version of IP.
+
+
+
+Quittek, et al.              Informational                     [Page 14]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+      2.  source IP address
+      3.  destination IP address
+      4.  IP protocol type (TCP,UDP,ICMP,...)
+      5.  if protocol type is TCP or UDP: source TCP/UDP port number
+      6.  if protocol type is TCP or UDP: destination TCP/UDP port
+          number
+      7.  packet counter
+          If a packet is fragmented, each fragment is counted as an
+          individual packet.
+      8.  byte counter
+          The sum of the total length in bytes of all IP packets
+          belonging to the flow.  The total length of a packet covers IP
+          header and IP payload.
+      9.  type of service octet (in case of IPv4), traffic class octet
+          (in case of IPv6).  According to [RFC2474], these octets
+          include the DiffServ Code Point that has a length of 6 bits.
+      10. in case of IPv6: Flow Label
+      11. if MPLS is supported at the observation point: the top MPLS
+          label or the corresponding forwarding equivalence class (FEC,
+          [RFC3031]) bound to that label.  The FEC is typically defined
+          by an IP prefix.
+      12. timestamp of the first packet of the flow
+      13. timestamp of the last packet of the flow
+      14. if sampling is used: sampling configuration
+      15. unique identifier of the observation point
+      16. unique identifier of the exporting process
+
+   The exporting process should be able to report the following
+   attributes for each metered flow:
+
+      17. if protocol type is ICMP: ICMP type and code
+      18. input interface (ifIndex)
+          This requirement does not apply if the observation point is
+          located at a probe device.
+      19. output interface (ifIndex)
+          This requirement does not apply if the observation point is
+          located at a probe device.
+      20. multicast replication factor
+          the number of outgoing packets originating from a single
+          incoming multicast packet.  This is a dynamic property of
+          multicast flows, that may change over time.  For unicast flows
+          it has the constant value 1.  The reported value must be the
+          value of the factor at the time the flow record is exported.
+
+   The exporting process may be able to report the following attributes
+   for each metered flow:
+
+      21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)
+
+
+
+Quittek, et al.              Informational                     [Page 15]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+      22. IP header flags
+      23. TCP header flags
+      24. dropped packet counter at the observation point
+          If a packet is fragmented, each fragment must be counted as an
+          individual packet.
+      25. fragmented packet counter
+          counter of all packets for which the fragmented bit is set in
+          the IP header
+      26. next hop IP address
+      27. source BGP Autonomous System number (see [RFC1771])
+      28. destination BGP Autonomous System number
+      29. next hop BGP Autonomous System number
+
+6.2.  Data Model
+
+   The data model describes how information is represented in flow
+   records.
+
+   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
+   for certain implementations.
+
+   The data model used for exporting flow information must be flexible
+   concerning the flow attributes contained in flow records.  A flexible
+   record format would offer the possibility of defining records in a
+   flexible (customizable) way regarding the number and type of
+   contained attributes.
+
+   The data model should be independent of the underlying transport
+   protocol, i.e., the data transfer.
+
+6.3.  Data Transfer
+
+   Requirements for the data transfer include reliability, congestion
+   awareness, and security requirements.  For meeting these requirements
+   the exporting process can utilize existing security features provided
+   by the device hosting the process and/or provided by the transport
+   network.  For example it can use existing security technologies for
+   authentication and encryption or it can rely on physical protection
+   of a separated network for transferring flow information.
+
+6.3.1.  Congestion Awareness
+
+   For the data transfer, a congestion aware protocol must be supported.
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 16]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+6.3.2.  Reliability
+
+   Loss of flow records during the data transfer from the exporting
+   process to the collecting process must be indicated at the collecting
+   process.  This indication must allow the collecting process to gauge
+   the number of flow records lost.  Possible reasons for flow records
+   loss include but are not limited to:
+
+      1. Metering process limitations: lack of memory, processing power,
+         etc.  These limitations are already covered in section 5.1.
+
+      2. Exporting process limitations: lack of memory, processing
+         power, etc.
+
+      3. Data transfer problems: packets that carry flow records sent
+         from the exporting process to the collecting process, are
+         dropped by the network.  Examples are connection failures and
+         losses by a transport protocol that specifically offers
+         congestion avoidance without persistent transport-level
+         reliability.
+
+      4. Collecting process limitations: it may be experiencing
+         congestion and not able to buffer new flows records.
+
+      5. Operation and Maintenance: the collecting process is taken down
+         for maintenance or other administrative purposes.
+
+   Please note that if an unreliable transport protocol is used,
+   reliability can be provided by higher layers.  If reliability is
+   provided by higher layers, only lack of overall reliability must be
+   indicated.  For example reordering could be dealt with by adding a
+   sequence number to each packet.
+
+   The data transfer between exporting process and collecting process
+   must be open to reliability extensions including at least
+
+      - retransmission of lost flow records,
+      - detection of disconnection and fail-over, and
+      - acknowledgement of flow records by the collecting process.
+
+   This extensibility may be used to provide additional reliability.
+   The extended protocol must still meet the requirements described in
+   this section, particularly, it must still be congestion aware.
+   Therefore, extensions using retransmissions must use exponential
+   backoff.
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 17]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+6.3.3.  Security
+
+   Confidentiality of IPFIX data transferred from an exporting process
+   to a collecting process must be ensured.
+
+   Integrity of IPFIX data transferred from an exporting process to a
+   collecting process must be ensured.
+
+   Authenticity of IPFIX data transferred from an exporting process to a
+   collecting process must be ensured.
+
+   The security requirements have been derived from an analysis of
+   potential security threads.  The analysis is summarized in Section
+   10.
+
+6.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 exporting process decides
+   without an external trigger when to send flow records.  In pull mode,
+   sending flow records is triggered by an explicit request from a
+   collecting process.  The exporting process must support push mode
+   reporting, it may support pull mode reporting.
+
+6.5.  Regular Reporting Interval
+
+   The exporting process should be capable of reporting measured traffic
+   data regularly according to a given interval length.
+
+6.6.  Notification on Specific Events
+
+   The exporting process may be capable of sending notifications to a
+   collecting process, if a specific event occurs.  Such an event can
+   be, for instance, the arrival of the first packet of a new flow, or
+   the termination of a flow after flow timeout.
+
+6.7.  Anonymization
+
+   The exporting process 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 measured traffic
+   data within a network.
+
+   For several applications anonymization cannot be applied, for example
+   for accounting and traffic engineering.  However, for protecting the
+   network user's privacy, anonymization should be applied whenever
+
+
+
+Quittek, et al.              Informational                     [Page 18]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   possible.  In many cases it is sufficient if anonymization is
+   performed at the collecting process after flow information has been
+   exported.  This provides a reasonable protection of privacy as long
+   as confidentiality of the export is provided.
+
+   It would be desirable to request that all IPFIX exporters provide
+   anonymization of flow records, but algorithms for anonymization are
+   still a research issue.  Several are known but the security they
+   provide and their other properties are not yet studied sufficiently.
+   Also, there is no standardized method for anonymization.  Therefore,
+   the requirement for the exporting process supporting anonymization is
+   qualified with 'may' and not with 'must'.
+
+   If anonymized flow data is exported, this must be clearly indicated
+   to all receiving collecting processes, such that they can distinguish
+   anonymized data from non-anonymized data.
+
+7.  Configuration
+
+   If configuration is done remotely, security should be provided for
+   the configuration process covering confidentiality, integrity, and
+   authenticity.  The means used for remote configuration are out of the
+   scope of this document.
+
+7.1.  Configuration of the Metering Process
+
+   The metering process must provide a way of configuring traffic
+   measurement.  The following parameters of the metering process should
+   be configurable:
+
+         1. specification of the observation point
+            e.g., an interface or a list of interfaces to be monitored.
+         2. specifications of flows to be metered
+         3. flow timeouts
+
+   The following parameters may be configurable:
+
+         4. sampling method and parameters, if feature is supported
+         5. overload behavior, if feature is supported
+
+7.2.  Configuration of the Exporting Process
+
+   The exporting process must provide a way of configuring the data
+   export.  The following parameters of the exporting process should be
+   configurable:
+
+         1. reporting data format
+            Specifying the reporting data format must include a
+
+
+
+Quittek, et al.              Informational                     [Page 19]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+            selection of attributes to be reported for each flow.
+         2. the collecting process(es) to which flows are reported
+         3. the reporting interval
+            This requirement only applies if the exporting process
+            supports reporting in regular intervals.
+         4. notifications to be sent to the collecting process(es)
+            This requirement only applies if the exporting process
+            supports notifications.
+         5. flow anonymization
+            This requirement only applies if the exporting process
+            supports flow anonymization.
+
+8.  General Requirements
+
+8.1.  Openness
+
+   IPFIX specifications should be open to future technologies.  This
+   includes extensibility of configuration of the metering process and
+   the exporting process.
+
+   Openness is also required concerning the extensibility of the data
+   model, as stated in section 6.2.
+
+8.2.  Scalability
+
+   Data collection from hundreds of different exporting processes must
+   be supported.  The collecting process must be able to distinguish
+   several hundred exporting processes by their identifiers.
+
+8.3.  Several Collecting Processes
+
+   The exporting process may be able to export flow information to more
+   than one collecting process.  If an exporting process is able to
+   export flow records to multiple collecting processes then it must be
+   able to ensure that the flow records can be identified so that
+   duplicates can be detected between different collecting processes and
+   double counting problems can be avoided.
+
+9.  Special Device Considerations
+
+   This document intends to avoid constraining the architecture of
+   probes, routers, and other devices hosting observation points,
+   metering processes, exporting processes, and/or collecting processes.
+   It can be expected that typically observation point, metering
+   process, and exporting process are co-located at a single device.
+   However, the requirements defined in this document do not exclude
+   devices that derive from this configuration.  Figure 2 shows some
+   examples.
+
+
+
+Quittek, et al.              Informational                     [Page 20]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   All examples are composed of one or more of the following elements:
+   observation point (O), metering process (M), exporting process (E),
+   and collecting process (C).  The observation points shown in the
+   figure are always the most fine-granular ones supported by the
+   respective device.
+
+         +---+     +-----+     +---------+       +---------+
+         | E-+->   |  E--+->   |    E----+->   <-+--E   E--+->
+         | | |     |  |  |     |   / \   |       |  |   |  |
+         | M |     |  M  |     |  M   M  |       |  M   M  |
+         | | |     | /|\ |     | /|\ /|\ |       | /|\ /|\ |
+         | O |     | OOO |     | OOO OOO |       | OOO OOO |
+         +---+     +-----+     +---------+       +---------+
+         Probe      Basic        Complex          Multiple
+                    Router       Router           Exporting
+                                                  Processes
+
+       +---+     +---+     +---+
+       | E-+->   | E-+->   | E-+------------->---+
+       | | |     | | |     | | | +---+         +-+-----+
+       +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
+         |       | | |     | | | | | | +---+   +-+-----+
+       +-+-+     +-+-+     | O | | M | | E-+->---+
+       | | |       |       +---+ | | | | | |
+       | M |     +-+-+           | O | | M |
+       | | |     | | |           +---+ | | |           +-----+
+       | O |     | O |                 | O |        ->-+-C-E-+->
+       +---+     +---+                 +---+           +-----+
+
+      Protocol   Remote             Concentrator        Proxy
+      Converter  Observation
+
+                   Figure 2: IPFIX-related Devices
+
+   A very simple device is a probe.  A typical probe contains a single
+   observation point, a single metering process, and a single exporting
+   process.
+
+   A basic router extends this structure by multiple observation points.
+   Here, the observation point of a particular flow may be one of the
+   displayed most fine-granular observation points, but also it may be a
+   set of them.
+
+   A more complex router may host more than one metering process, for
+   example one per line card.  Please note that here, the observation
+   point of a single flow cannot exceed the set of most fine-granular
+   observation points linked to a single metering process, because only
+   the metering process can merge packets observed at different fine-
+
+
+
+Quittek, et al.              Informational                     [Page 21]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   granular observation points to a joint flow.  An observation point
+   containing all most fine-granular observation points of this router
+   is not possible with this structure.  Alternatively, a complex router
+   may host different exporting processes for flow records generated by
+   different metering processes.
+
+   A protocol converter makes use of a metering process that can be
+   accessed only by protocol(s) other than the one defined for IPFIX,
+   for example, the SNMP and the Meter MIB module [RFC2720].  Then the
+   exporting process receives flow records from a remote metering
+   process and exports these records using the IPFIX protocol.  Please
+   note that this document does not make any particular assumption on
+   how metering processes and export processes exchange information, as
+   long as all individual requirements for these processes are met.
+   Also the locations of metering processes are not of any relevance for
+   this document (in contrast to the locations of observation points and
+   the exporting processes).
+
+   In the example of remote packet observation in Figure 2 the metering
+   process and the observation point are not co-located.  Packet headers
+   captured at an observation point may be exported as raw data to a
+   device hosting metering process and exporting process.  Again, this
+   document does not make any particular assumption on how packet
+   headers are transferred from observation points to metering
+   processes, as long as all requirements for the metering processes are
+   met.
+
+   An intermediate structure between protocol converter and remote
+   observation (not shown in the Figure) would be a split metering
+   process, for example performing timestamping and sampling at the
+   device hosting the observation point and performing packet
+   classification at another device hosting the exporting process.
+
+   A concentrator receives flow records via the IPFIX protocol, merges
+   them into more aggregated flow records, and exports them again using
+   the IPFIX protocol.  Please note that for the final flow records the
+   resulting observation point may be a superset of the more fine-
+   granular observation points at the first level devices.  The metering
+   process of the final flow records is composed by the (partial)
+   metering processes at the first level devices and the partial
+   metering process at the concentrator.
+
+   Finally, a very simple IPFIX-related device is a proxy.  It just
+   receives flow records using the IPFIX protocol and sends them further
+   using the same protocol.  A proxy might be useful for traversing
+   firewalls or other gateways.
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 22]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+10.  Security Considerations
+
+   An IPFIX protocol must be capable of transporting data over the
+   public Internet.  Therefore it cannot be excluded that an attacker
+   captures or modifies packets or inserts additional packets.
+
+   This section describes security requirements for IPFIX.  Like other
+   requirements, the security requirements differ among the considered
+   applications.  The incentive to modify collected data for accounting
+   or intrusion detection for instance is usually higher than the
+   incentive to change data collected for traffic profiling.  A detailed
+   list of the required security features per application can be found
+   in the appendix.
+
+   The suggestion of concrete solutions for achieving the required
+   security properties should be part of an IPFIX architecture and
+   protocol.  It is out of scope of this document.  Also methods for
+   remote configuration of the metering processes and exporting
+   processes are out of scope.  Therefore, threats that are caused by
+   data exchange for remote configuration are not considered here.
+
+   The following potential security hazards for an IPFIX protocol have
+   been identified: disclosure of IP flow information, forgery of flow
+   records, and Denial of Service (DoS) attacks.
+
+10.1.  Disclosure of Flow Information Data
+
+   The content of data exchanged by an IPFIX protocol (for example IPFIX
+   flow records) should be kept confidential between the involved
+   parties (exporting process and collecting process).  Observation of
+   IPFIX flow records gives an attacker information about the active
+   flows in the network, communication endpoints and traffic patterns.
+   This information cannot only be used to spy on user behavior but also
+   to plan and conceal future attacks.  Therefore, the requirements
+   specified in section 6.3.3. include confidentiality of the
+   transferred data.  This can be achieved for instance by encryption.
+
+   Also the privacy of users acting as sender or receiver of the
+   measured traffic needs to be protected when they use the Internet.
+   In many countries the right to store user-specific data (including
+   the user's traffic profiles) is restricted by law or by regulations.
+
+   In addition to encryption, this kind of privacy can also be protected
+   by anonymizing flow records.  For many traffic flow measurements,
+   anonymized data is as useful as precise data.  Therefore, it is
+   desirable to support anonymization in IPFIX implementations.  It is
+   beyond the scope of the IPFIX Working Group to develop and
+
+
+
+
+Quittek, et al.              Informational                     [Page 23]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   standardize anonymization methods.  However, the requirements for
+   extensibility of the IPFIX protocol are sufficient to support
+   anonymized flow records when appropriate methods are standardized.
+
+10.2.  Forgery of Flow Records
+
+   If flow records are used in accounting and/or security applications,
+   there are potentially strong incentives to forge exported IPFIX flow
+   records (for example, to save money or prevent the detection of an
+   attack).  This can be done either by altering flow records on the
+   path or by injecting forged flow records that pretend to be
+   originated by the original exporting process.
+
+   Special caution is required if security applications rely on flow
+   measurements.  With forged flow records it is possible to trick
+   security applications.  For example, an application may be lead to
+   falsely conclude that a DoS attack is in progress.  If such an
+   injection of IPFIX traffic flow records fools the security
+   application, causing it to erroneously conclude that a DoS attack is
+   underway, then the countermeasures employed by the security
+   application may actually deny useful non-malicious services.
+
+   In order to make an IPFIX protocol resistant against such attacks,
+   authentication and integrity must be provided, as specified in
+   section 6.3.3.
+
+10.3.  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.
+
+   However, IPFIX itself also causes potential hazards for DoS attacks.
+   All processes that expect the reception of traffic can be target of a
+   DoS attack.  With the exporting process this is only the case if it
+   supports the pull mode (which can be an optional feature of the IPFIX
+   protocol according to this document).  The collecting process always
+   expects data and therefore can be flooded by flow records.
+
+
+
+
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 24]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+11.  Acknowledgments
+
+   Many thanks to Georg Carle for contributing to the application
+   analysis, to K.C. Norseth for several fine-tunings, to Sandra
+   Tartarelli for checking the appendix, and to a lot of people on the
+   mailing list for providing valuable comments and suggestions
+   including Nevil Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal
+   Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen,
+   David Plonka, Ganesh Sadasivan, Kevin Zhang, and many more.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 25]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+12.  Appendix: Derivation of Requirements from 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                                                               |
+----------------------------------------------------------------.      |
+E: QoS Monitoring                                               |      |
+----------------------------------------------------------.     |      |
+D: Attack/Intrusion Detection                             |     |      |
+----------------------------------------------------.     |     |      |
+C: Traffic Engineering                              |     |     |      |
+----------------------------------------------.     |     |     |      |
+B: Traffic Profiling                          |     |     |     |      |
+----------------------------------------.     |     |     |     |      |
+A: Usage-based Accounting               |     |     |     |     |      |
+----------------------------------.     |     |     |     |     |      |
+                                  |     |     |     |     |     |      |
+| Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.    | DISTINGUISHING FLOWS                                         |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.    | Combination of          |  M  |  M  |  M  |  M  |  M  |  M   |
+|       | required attributes     |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.1.  | in/out IF               |  S  |  M  |  M  |  S  |  S  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.2.  | src/dst address         |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.2.  | Masking of IP addresses |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.2.  | transport protocol      |  M  |  M  |  -  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.2.  | version field           |  -  |  S  |  S  |  O  |  O  |  S   |
+|       |                         |     |     | (b) |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 26]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.3.  | src/dst port            |  M  |  M  |  -  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.4.  | MPLS label (a)          |  S  |  S  |  M  |  O  |  S  |  M   |
+|       |                         |     |     | (c) |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 4.5.  | DSCP (a)                |  M  |  S  |  M  |  O  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.    | METERING PROCESS                                             |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.1.  | Reliability             |  M  |  S  |  S  |  S  |  S  |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+  M   |
+| 5.1.  | Indication of           |  -  |  M  |  M  |  M  |  M  |      |
+|       | missing reliability     |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.2.  | Sampling (d,e)          |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.3.  | Overload Behavior (f)   |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.4.  | Timestamps              |  M  |  O  |  O  |  S  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.5.  | Time synchronization    |  M  |  S  |  S  |  S  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.6.  | Flow timeout            |  M  |  S  |  -  |  O  |  O  |  M   |
+|       |                         | (g) |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.7.  | Multicast flows         |  S  |  O  |  O  |  O  |  S  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.8.  | Packet fragmentation    |  O  |  O  |  -  |  -  |  -  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 5.9.  | Ignore port copy        |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.    | DATA EXPORT                                                  |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | INFORMATION MODEL                                            |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | IP Version              |  -  |  M  |  M  |  O  |  O  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | src/dst address         |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | transport protocol      |  M  |  M  |  -  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | src/dst port            |  M  |  M  |  -  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Packet counter (h)      |  S  |  M  |  M  |  S  |  S  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+
+
+
+Quittek, et al.              Informational                     [Page 27]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Byte counter            |  M  |  M  |  M  |  S  |  S  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | ToS (IPv4) or traffic   |  M  |  S  |  M  |  O  |  M  |  M   |
+|       | class octet (IPv6)      |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Flow Label (IPv6)       |  M  |  S  |  M  |  O  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | MPLS label (a)          |  S  |  S  |  M  |  O  |  S  |  M   |
+|       |                         |     |     | (c) |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Timestamps for          |  M  |  O  |  O  |  S  |  S  |  M   |
+|       | first/last packet       |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Sampling configuration  |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | observation point       |  M  |  M  |  M  |  M  |  M  |  M   |
+|       | identifier              |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | export process          |  M  |  M  |  M  |  M  |  M  |  M   |
+|       | identifier              |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | ICMP type and code (i)  |  S  |  S  |  -  |  S  |  S  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | input/output interface  |  S  |  S  |  S  |  S  |  S  |  S   |
+|       | (j)                     |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Multicast               |  O  |  S  |  S  |  -  |  S  |  S   |
+|       | replication factor      |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | TTL                     |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | IP header flags         |  -  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | TCP header flags        |  -  |  O  |  O  |  O  |  -  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Dropped Packet          |  O  |  O  |  O  |  O  |  O  |  O   |
+|       | Counter (h,k)           |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | Fragment counter        |  -  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | next hop IP address     |  O  |  O  |  O  |  O  |  -  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.1.  | src / dst / next hop    |  -  |  O  |  O  |  -  |  -  |  O   |
+|       | BGP AS #                |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+
+
+
+Quittek, et al.              Informational                     [Page 28]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.2.  | DATA MODEL                                                   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.2.  | Flexibility             |  M  |  S  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.2.  | Extensibility           |  M  |  S  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.  | DATA TRANSFER                                                |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.1.| Congestion aware        |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.2.| Reliability             |  M  |  S  |  S  |  S  |  S  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.3.| Confidentiality         |  M  |  S  |  S  |  M  |  S  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.4.| Integrity               |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.3.5.| Authenticity            |  M  |  M  |  M  |  M  |  M  |  M   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.4.  | REPORTING TIMES                                              |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.4.  | Push mode               |  M  |  O  |  O  |  M  |  S  |  M   |
+|       |                         |     | (l) | (l) |     |(l,m)|      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.4.  | Pull mode               |  O  |  O  |  O  |  O  |  O  |  O   |
+|       |                         |     | (l) | (l) |     | (l) |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.4.1.| Regular interval        |  S  |  S  |  S  |  S  |  S  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.6.  | Notifications           |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 6.7.  | Anonymization (n)       |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.    | CONFIGURATION                                                |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.    | Secure remote           |  S  |  S  |  S  |  S  |  S  |  S   |
+|       | configuration (a)       |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.1.  | Config observation point|  S  |  S  |  S  |  S  |  S  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.1.  | Config flow             |  S  |  S  |  S  |  S  |  S  |  S   |
+|       | specifications          |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.1.  | Config flow timeouts    |  S  |  S  |  S  |  S  |  O  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+
+
+
+
+Quittek, et al.              Informational                     [Page 29]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.1.  | Config sampling         |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.1.  | Config overload         |  O  |  O  |  O  |  O  |  O  |  O   |
+|       | behavior (a)            |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.2.  | Config report           |  S  |  S  |  S  |  S  |  S  |  S   |
+|       | data format             |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 7.2.  | Config                  |  S  |  S  |  S  |  S  |  S  |  S   |
+|       | notifications           |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 8.    | GENERAL REQUIREMENTS                                         |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 8.1.  | Openness                |  S  |  S  |  S  |  S  |  S  |  S   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 8.2.  | Scalability:            |     |     |     |     |     |      |
+|       | data collection         |  M  |  S  |  M  |  O  |  S  |  M   |
+|       | from hundreds of        |     |     |     |     |     |      |
+|       | measurement devices     |     |     |     |     |     |      |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+| 8.3.  | Several collectors      |  O  |  O  |  O  |  O  |  O  |  O   |
+|-------+-------------------------+-----+-----+-----+-----+-----+------|
+
+   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 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) If sampling is supported, the methods and parameters must be
+          well defined.
+      (e) If sampling is supported, sampling configuration changes must
+          be indicated to all collecting processes.
+      (f) If overload behavior is supported and it induces changes in
+          the metering process behavior, the overload behavior must be
+          clearly defined.
+      (g) Precise time-based accounting requires reaction to a flow
+          timeout.
+      (h) If a packet is fragmented, each fragment is counted as an
+          individual packet.
+      (i) If protocol type is ICMP.
+
+
+
+
+Quittek, et al.              Informational                     [Page 30]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+      (j) This requirement does not apply if the observation point is
+          located at a probe device.
+      (k) Only if measurement is done on data path i.e., has access to
+          forwarding decision.
+      (l) Either push or pull has to be supported.
+      (m) Required, in order to immediately report drop indications for
+          SLA validation.
+      (n) Anonymization must be clearly indicated to all receiving
+          collecting processes.
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC2960]   Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+               Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
+               Zhang, L., and V. Paxson, "Stream Control Transmission
+               Protocol", RFC 2960, October 2000.
+
+   [RFC3031]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+               Label Switching Architecture", RFC 3031, January 2001.
+
+   [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black,
+               "Definition of the Differentiated Services Field (DS
+               Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+               1998.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+13.2.  Informative References
+
+   [RFC3234]   Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+               Issues", RFC 3234, February 2002.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3550]   Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+               Jacobson, "RTP: A Transport Protocol for Real-Time
+               Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC2975]   Aboba, B., Arkko, J., and D. Harrington, "Introduction to
+               Accounting Management", RFC 2975, October 2000.
+
+   [RFC2702]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
+               McManus, "Requirements for Traffic Engineering Over
+               MPLS", RFC 2702, September 1999.
+
+
+
+Quittek, et al.              Informational                     [Page 31]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+   [RFC1771]   Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
+               (BGP-4)", RFC 1771, March 1995.
+
+   [RFC3418]   Presuhn, R., "Management Information Base (MIB) for the
+               Simple Network Management Protocol (SNMP)", STD 62, RFC
+               3418, December 2002.
+
+   [RFC2720]   Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
+               2720, October 1999.
+
+14.  Authors' Addresses
+
+   Juergen Quittek
+   NEC Europe Ltd., Network Laboratories
+   Kurfuersten-Anlage 36
+   69115 Heidelberg
+   Germany
+
+   Phone: +49 6221 90511 15
+   EMail: quittek@netlab.nec.de
+
+   Tanja Zseby
+   Fraunhofer Institute for Open Communication Systems (FOKUS)
+   Kaiserin-Augusta-Allee 31
+   10589 Berlin
+   Germany
+
+   Phone: +49 30 3463 7153
+   EMail: zseby@fokus.fhg.de
+
+   Benoit Claise
+   Cisco Systems
+   De Kleetlaan 6a b1
+   1831 Diegem
+   Belgium
+
+   Phone: +32 2 704 5622
+   EMail: bclaise@cisco.com
+
+   Sebastian Zander
+   Centre for Advanced Internet Architectures, Mail H31
+   Swinburne University of Technology
+   PO Box 218
+   John Street, Hawthorn
+   Victoria 3122, Australia
+
+   Phone: +61 3 9214 8089
+   EMail: szander@swin.edu.au
+
+
+
+Quittek, et al.              Informational                     [Page 32]
+
+RFC 3917                   IPFIX Requirements               October 2004
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Quittek, et al.              Informational                     [Page 33]
+