| | | | | | | / \ | | | | |
| 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-
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.
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
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.
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.
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) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 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 |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 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 # | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 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 |