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
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.,
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:
- 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.
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.
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.
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)
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.
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.
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
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
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.
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--+->