One document matched: draft-ietf-ipfix-as-05.txt
Differences from draft-ietf-ipfix-as-04.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-05.txt> Elisa Boschi
Expires: November 2005 Fraunhofer FOKUS
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
May 2005
IPFIX Applicability
draft-ietf-ipfix-as-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Zseby, Boschi, Brownlee, Claise [Page 1]
IPFIX Applicability May 2005
This document describes what type of applications can use the IP
Flow Information Export (IPFIX) protocol and how they can use
the information provided by IPFIX. It also shows how the IPFIX
framework relates to other architectures and frameworks.
Zseby, Boschi, Brownlee, Claise [Page 2]
IPFIX Applicability May 2005
Table of Contents
1. Introduction.............................................3
2. Applications of IPFIX....................................4
2.1 Accounting...............................................4
2.1.1 Example.................................................5
2.2 Security Analysis and Intrusion Detection with IPFIX.....6
2.3 Network Planning.........................................8
2.4 Peering Agreements.......................................8
2.5 Traffic Engineering......................................8
2.6 Trend Analysis...........................................9
2.7 SLA Validation and QoS Measurements......................9
2.7.1 Measurement of Round-trip-time (RTT)...................10
2.7.2 Measurement of One-way-delay (OWD).....................10
2.7.3 Measurement of One-way-loss (OWL)......................11
2.7.4 Measurement of IP delay variation (IPDV)...............11
2.7.5 Transport of IPPM Metrics..............................11
2.7.6 Other Applications.....................................12
3. Relation of IPFIX to other frameworks and protocols.....12
3.1 IPFIX and AAA...........................................12
3.1.1 Connecting via an AAA Client...........................13
3.1.2 Connecting via an Application Specific Module (ASM)....14
3.2 IPFIX and RTFM..........................................15
3.2.1 Architecture...........................................15
3.2.2 Flow Definition........................................15
3.2.3 Configuration and Management...........................16
3.2.4 Data Collection........................................16
3.2.5 Data Model Details.....................................16
3.2.6 Application/Transport Protocol.........................17
3.2.7 RTFM Summary...........................................17
3.3 IPFIX and IPPM..........................................17
3.4 IPFIX and PSAMP.........................................17
3.5 IPFIX and RMON..........................................18
3.6 IPFIX and IDMEF.........................................18
4. Limitations.............................................19
4.1 IPFIX and IPv6..........................................20
5. Security Considerations.................................20
6. Normative References....................................21
7. Informative References..................................21
8. Acknowledgements........................................23
9. Author's Addresses......................................23
10. Full Copyright Statement................................24
11. Intellectual Property Statement.........................24
12. Copyright Statement.....................................25
13. Disclaimer..............................................25
1. Introduction
Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability May 2005
The IPFIX protocol defines how IP Flow information can be
exported from routers, measurement probes or other devices. It
is intended to provide this information as input to various
applications. IPFIX is a general data transport protocol, easily
extensible to suit the needs of different applications. This
document describes what applications can use the IPFIX protocol
and how they can use it. Furthermore, the relationship of IPFIX
to other frameworks and architectures is described.
2. Applications of IPFIX
IPFIX data enables several critical applications. This section
describes how different applications can use the IPFIX protocol.
2.1 Accounting
Usage-based accounting is one of the major applications for
which the IPFIX protocol has been developed. IPFIX data records
provide fine-grained measurement results for highly flexible and
detailed resource usage accounting. Internet Service Providers
(ISPs) can use this information to migrate from single fee,
flat-rate billing to more flexible charging mechanisms based on
time of day, bandwidth usage, application usage, quality of
service, etc. Enterprise customers can use this information for
departmental chargeback or cost allocation for resource usage.
In order to realize usage-based accounting with IPFIX the flow
definition has to be chosen in accordance with the tariff model.
IPFIX allows a very flexible flow definition that can be adapted
to the need of different tariff models. Arbitrary flow-based
accounting models can be realized without any extensions to the
IPFIX protocol.
A tariff can, for instance, be based on individual end-to-end
flows, in which case accounting can be realized with a flow
definition determined by the quintuple consisting of source
address, destination address, protocol and port numbers. Another
example is a class-dependent tariff (e.g. in a DiffServ
network). In this case, flows could be distinguished just by the
DiffServ codepoint (DSCP) and source IP address.
The essential elements needed for accounting are the number of
transferred packets and bytes per flow which are contained in
IPFIX flow records.
For accounting purposes, it would be advantageous to have the
ability to use IPFIX flow records as accounting input in an AAA
Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability May 2005
infrastructure. AAA servers then could provide the mapping
between user and flow information.
2.1.1 Example
Let's suppose someone has a Service Level Agreement (SLA) in a
DiffServ network requiring accounting based on traffic volume.
The information to export in this case is:
- The IPv4 source IP address: sourceIPv4Address in [IPFIX-
INFO] with a length of 4 octets
- The IPv4 destination IP address: destinationIPv4Address in
[IPFIX-INFO] with a length of 4 octets
- Type of Service: classOfServiceIPv4 in [IPFIX-INFO] with a
length of 1 octet
- The number of octets of the flow: inOctetDeltaCount in
[IPFIX-INFO] with a length of 4 octets
The template set (in case we use only IETF-specified Information
Elements) will look like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| classOfServiceIPv4 = 5 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported might be as listed in the
following example table:
Src. IP addr. | Dst. IP addr. | Type of service | Octets Number
--------------+---------------+-----------------+--------------
198.18.1.12 | 198.18.2.254 | 101110xx | 987410
198.18.1.27 | 198.18.2.23 | 101110xx | 170205
198.18.1.56 | 198.18.2.65 | 101110xx | 33113
The field "Type of service" contains the DiffServ Codepoint in
the first six bits while the last two are currently unused. In
the example we use Codepoint 101110, recommended for the EF PHB
(Expedited Forwarding Per Hop Behavior)[RFC2598]
Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability May 2005
The Flow Records will then look like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 198.18.1.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 198.18.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 101110 00 | 8987410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 198.18.1.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 198.18.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 101110 00 | 170205 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 198.18.1.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 198.18.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 101110 00 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 33113 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2 Security Analysis and Intrusion Detection with IPFIX
IPFIX provides information about the traffic in a network.
Therefore it is very well suited to take a key role in the
detection of network threats such as intrusions, propagation of
viruses and worms, port scanning and other network attacks.
Intrusion detection systems (IDS) monitor and control security
incidents. A typical IDS system includes several components
including sensors, event collectors, and management stations.
Sensors monitor network traffic for attacks and other security-
related events. Sensors respond to and notify the administrator
via the event collector about these events as they occur. Event
collectors are a middle-tier component responsible for
transmitting events from sensors to the console and database.
The management component serves the following purposes:
- visually monitors events (via a console)
Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability May 2005
- collects data from sensors (with one or more event collectors)
- stores data from sensors (in a database)
IPFIX can report events of interest to the sensor either by the
collecting process or directly by the exporting process. Which
approach is best depends on the scenario and the events of
interest. Getting information directly from the exporting
process has the advantage that the sensor gets the information
faster. It does not need to wait for collector processing time
or until the collecting process has all relevant data. Getting
the information from a collecting process enables correlation of
data from different exporting processes (e.g. from different
routers) to get a better picture of what is happening in the
network.
IPFIX provides useful input data for basic intrusion detection
functions such as reporting unusually high loads, number of
flows, number of packets of a specific type, etc. It can provide
details on source and destination addresses, along with the
start time of flows, TCP flags, application ports and flow
volume. This data can be used to analyze network security
incidents and identify attacks. Further data analysis and post-
processing functions may be needed to generate the metric of
interest for specific attack types. The integration of previous
measurement results helps to assess traffic changes over time
for detection of traffic anomalies. A combination with results
from other observation points allows assessing the propagation
of the attack and can help locate the source of an attack.
For some scenarios, intrusion detection may require further
insight into packet content. Since IPFIX allows a flexible
report definition, the metering process and the IPFIX report
format could be extended to support other data needed for
intrusion detection systems. Furthermore, it is possible to get
per packet information by using IPFIX to export PSAMP
information.
Detecting security incidents in real-time would require the pre-
processing of data already at the measurement device and
immediate data export in case a possible incident has been
identified. This means that IPFIX reports must be generated upon
incident detection events and not only upon flow end or fixed
time intervals.
Furthermore, security incidents can become a threat to IPFIX
processes themselves (see also security considerations in
[IPFIX-PROTO]. If an attack generates a large amount of flows
(e.g. by sending packets with spoofed addresses or simulating
flow termination) exporting and collecting process may get
Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability May 2005
overloaded by the immense amount of data records that are
exported. A flexible deployment of packet or flow sampling
methods can prevent the exhaustion of resources.
Intrusion detection can profit greatly from the combination of
IPFIX and AAA functions (see section 3.1). Such an
interoperation enables further means of attack detection,
advanced defense strategies and secure inter-domain cooperation.
2.3 Network Planning
IPFIX data records captured over a long period of time can be
used to track and anticipate network growth and plan upgrades to
increase the number of routing devices, ports, or higher-
bandwidth interfaces. Flow information as provided by IPFIX data
records optimizes both strategic network planning (peering,
backbone upgrade planning, routing policy planning), and
tactical network engineering decisions (upgrading the router or
link capacity). This helps to minimize the total cost of network
operations through effective capacity planning, while maximizing
network performance and reliability.
2.4 Peering Agreements
IPFIX provides a common data format for the reporting of
measurement results. Therefore it is very well suited to share
information with neighbor ISPs. If measurement tools in
different domains export the data in the same format and
collectors at different domains understand this format, IPFIX
data records could be directly forwarded to neighbor providers.
This can be done either by the IPFIX protocol itself or by
converting or encapsulating data records into commonly used
protocols for inter-domain data exchange like DIAMETER.
Some ISPs are still reluctant to share information due to
concerns that competing ISPs might exploit network information
from neighbor providers to strengthen their own position in the
market. Nevertheless, technical needs have already triggered the
exchange of data in the past (e.g. exchange of routing
information by BGP). The need to provide inter-domain guarantees
is one big incentive to increase inter-domain cooperation.
Furthermore, the necessity to defend networks against current
and future threats (denial of service attacks, worm
distributions, etc.) will further increase the willingness to
exchange measurement data between providers.
2.5 Traffic Engineering
Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability May 2005
IPIFX data provides traffic engineering details for a set of
prefixes. This data can be used in network optimization for load
balancing traffic across alternate paths, or for forwarding
traffic of a certain set of prefixes on a preferred route.
2.6 Trend Analysis
IPFIX data records are well suited to perform traffic profiling
for trend analysis and as a basis for business models. The
flexible flow definition allows different viewpoints on the
data. The observation of different traffic statistics (e.g.
number of flows, transmitted volume, etc.) over time provides
valuable input on the usage of existing services or the planning
of future services.
IPFIX data records (or information derived from them) can be
stored for later retrieval and analysis to support proactive
marketing and customer service programs. An example of this is
to determine which applications and services are being used by
internal and external users and then target them for improved
services such as advertising. This is especially useful for ISPs
because IPFIX data enables them to create better service
packaging.
2.7 SLA Validation and QoS Measurements
Performing QoS monitoring is one target application of the IPFIX
protocol. QoS monitoring is the passive observation of
transmission quality for single flows or traffic aggregates in
the network. One example of its usefulness is the validation of
QoS guarantees in service level agreements (SLAs). Some QoS
metrics require the correlation of data from multiple
measurement points. For this, the clocks of the involved
exporting devices must be synchronized. Furthermore, such
measurements would benefit from post-processing functions (e.g.
packet ID generation and mapping) at the exporter and/or
collector.
This section describes how the measurement of different metrics
can be performed with IPFIX. All of the metrics require at least
an extension of the IPFIX information model since the necessary
information such as round-trip-time, packet IDs, etc., is not
part of the current model. However given the extensibility and
flexibility of IPFIX the missing attributes can be easily
defined. The direct reporting of IPPM metrics with the IPIFX
protocol is addressed in section 3.3.
Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability May 2005
2.7.1 Measurement of Round-trip-time (RTT)
The passive measurement of round-trip-times (RTT) can be
performed by using packet pair matching techniques as described
in [Brow00]. For the measurements, request/response packet pairs
from protocols such as DNS, ICMP, SNMP or TCP (syn/syn-ack,
data/ack) are utilized to passively observe the RTT [Brow00]. As
always for passive measurements, this only works if the required
traffic of interest is actually present in the network.
Furthermore, if the observed protocol supports retransmissions
(e.g. TCP), the RTT is not the network RTT, but rather the RTT
of the network and the protocol stack of the receiver. In case
the reply packet is lost or can not be observed, the RTT can not
be calculated.
In order to use this measurement technique, the IPFIX metering
process needs to measure packets from both directions. A
classification of the protocols mentioned above has to be done.
This means that parts of the transport header are used for the
classification. Since a differentiation of flows based on
information in the transport header is one of the requirements
for IPFIX, such classification can be performed without
extensions to the protocol. Nevertheless, the metering process
also needs to recognize request and response packets for the
given protocols and therefore needs to look further into the
packets. The capability to do this analysis is not part of the
IPFIX requirements but can be achieved by optional extensions to
the classification process. The exporting device needs to assign
a timestamp for the arrival of the packets. The calculation of
the RTT can be done directly at the exporter or at the
collector. In the first case, IPFIX would transfer the
calculated RTT to the collector. In the second case, IPFIX needs
to send the observed packet types and the timestamps to the
collector. The round-trip-time-delay metric is defined in
[RFC2681].
2.7.2 Measurement of One-way-delay (OWD)
Passive one-way-delay measurements require the collection of
data at two measurement points. It is necessary to recognize
packets at the second measurement point to correlate packet
arrival events from both points. This can be done by capturing
packet header and parts of the packet that can be used to
recognize the same packet at the subsequent measurement point.
To reduce the amount of measurement data, a unique packet ID can
be calculated from the header and all, or part of the content
e.g. by using a CRC or hash function [GrDM98, DuGr00, ZsZC01].
The capability of using parts of the payload is out of scope of
Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability May 2005
IPFIX but can be achieved by an optional extension.
Nevertheless, in some scenarios it might even be sufficient to
calculate a packet ID based on header fields (including datagram
ID and maybe sequence numbers from transport protocols) without
looking at parts of the payload. If packet IDs need to be unique
only for a certain time interval, or a certain amount of packet
ID collisions is tolerable, this is a sufficient solution. The
second issue is the export of packet IDs. IPFIX exports per-flow
information. The export of packet IDs is possible by introducing
a new information element (packet ID).
In order to provide a more efficient data export, one can export
the packet information with a flow ID in the data records. The
flow ID then can be associated with flow properties in a data
record. In this way the flow information only needs to be
transferred once. The packet information relates to much smaller
flow IDs, without the need to transfer all of the flow
information for each packet [PoMB05].
The one way delay metric is defined in [RFC2679]. The export of
whole packets, or parts of packets is addressed by the PSAMP
working group [PSAMP]. PSAMP uses IPFIX as its export protocol.
2.7.3 Measurement of One-way-loss (OWL)
Passive loss measurements for single flows can be performed at
one measurement point by using sequence numbers that are present
in protocols (e.g. IP identification, TCP sequence numbers)
similar to the approach described in section 2.7.1. This
requires the capturing of the sequence numbers of subsequent
packets in the observed flow by the IPFIX metering process.
An alternative to this is to perform a two-point measurement as
described in section 2.7.2, and to consider packets as lost that
do not arrive at the second measurement point in a given time
frame. This approach assumes that a packet observed at the first
point should be also observed at the second observation point
(e.g. measurement should be done close to end-points or border
routers). The one-way loss metric is defined in [RFC2680].
2.7.4 Measurement of IP delay variation (IPDV)
IP delay variation is defined as the difference of one-way-delay
values for selected packets [RFC3393]. Therefore, this metric
can be calculated by performing passive measurement of one-way-
delay for subsequent packets (e.g. of a flow) and then
calculating the differences.
2.7.5 Transport of IPPM Metrics
Zseby, Boschi, Brownlee, Claise [Page 11]
IPFIX Applicability May 2005
The IPFIX protocol can be used to transport not only input for
the calculation of IPPM metrics, but also for transporting the
metrics themselves. For this, additional information elements
need to be defined.
2.7.6 Other Applications
IPFIX is a quite generic and powerful protocol. It provides a
generic export mechanism that might be useful also for many
further applications. Apart from sending raw flow information it
also can be used to send further aggregated or post-processed
data. For this new templates and information elements can be
defined if needed.
Due to the push mode operation it is also suited to send network
initiated events like alarms and other notifications. It also
could be used for exchanging information among network nodes to
autonomously improve network operation.
Nevertheless, IPFIX was designed with respect to the
requirements documented in [RFC3917]. Therefore the capabilities
of IPFIX have to be carefully checked against requirements of
new applications before using it for other purposes than
addressed in [RFC3917].
3. Relation of IPFIX to other frameworks and protocols
3.1 IPFIX and AAA
AAA defines a protocol and architecture for authentication,
authorization and accounting for service usage [RFC2903]. The
DIAMETER protocol [RFC3588] is used for AAA communication, which
is needed for network access services (Mobile IP, NASREQ, and
ROAMOPS). The AAA architecture [RFC2903] provides a framework
for extending AAA support to other services. DIAMETER defines
the exchange of messages between AAA entities, e.g. between AAA
clients at access devices and AAA servers, and among AAA
servers. It is also used for the transfer of accounting records.
Usage-based accounting requires measurement data from the
network. IPFIX defines a protocol to export such data from
routers, measurement probes and other devices.
Accounting functions can be realized without an AAA
infrastructure as shown in section 2.1. Accounting applications
can directly incorporate an IPFIX collecting process to receive
IPFIX data records with information about the transmitted
volume.
Zseby, Boschi, Brownlee, Claise [Page 12]
IPFIX Applicability May 2005
Nevertheless, if an AAA infrastructure is in place, the
cooperation between IPFIX and AAA provides many valuable
synergistic benefits.
IPFIX data records can provide the input for AAA accounting
functions and provide the basis for the generation of DIAMETER
accounting records. Further potential features include the
mapping of a user ID to flow information (by using
authentication information) or facilitating the secure
authorized exchange of DIAMETER accounting records with neighbor
domains. The last feature is especially useful in roaming
scenarios where the user connects to a foreign network and the
home provider generates the invoice.
Coupling an IPFIX collecting process with AAA functions also has
high potential for intrusion and attack detection. AAA controls
network access and maintains data about users and nodes. AAA
functions can help identify the source of malicious traffic.
They are able to deny access to suspicious users or nodes.
Therefore coupling those functions with an IPFIX collecting
process can provide an efficient defense against network
attacks. Furthermore, sharing IPFIX data records (either
directly or encapsulated in DIAMETER) with neighbor providers
allows an efficient inter-domain attack detection. The AAA
infrastructure can also be used to configure measurement
functions in the network as proposed in [RFC3334].
Two possibilities exist to connect IPFIX and AAA:
- Connecting via an AAA Client
- Connecting via an Application Specific Module (ASM)
Both are explained in the following sections.
3.1.1 Connecting via an AAA Client
One possibility of connecting IPFIX and AAA is to run an AAA
client on the IPFIX collector. This client can generate DIAMETER
accounting messages and send them to an AAA server. The mapping
of the flow information to a user ID can be done in the AAA
server by using data from the authentication process. DIAMETER
accounting messages can be sent to the accounting application or
to other AAA servers (e.g. in roaming scenarios).
Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability May 2005
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX collector connects to AAA server via AAA client
3.1.2 Connecting via an Application Specific Module (ASM)
Another possibility is to directly connect the IPFIX collector
with the AAA server via an application specific module (ASM).
Application specific modules have been proposed by the IRTF AAA
architecture research group (AAARCH) in [RFC2903]. They act as
an interface between AAA server and service equipment. In this
case the IPFIX collector is part of the ASM. The ASM acts as an
interface between the IPFIX protocol and the input interface of
the AAA server. The ASM translates the received IPFIX data into
an appropriate format for the AAA server. The AAA server then
can add information about the user ID and generate a DIAMETER
accounting record. This accounting record can be sent to an
accounting application or to other AAA servers.
Zseby, Boschi, Brownlee, Claise [Page 14]
IPFIX Applicability May 2005
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 3: IPFIX connects to AAA server via ASM
3.2 IPFIX and RTFM
The Real-time Traffic Flow Measurement (RTFM) working group
defined an architecture for flow measurement [RFC2722]. This
section compares the Real-time Traffic Flow Measurement (RTFM)
framework with the IPFIX framework.
3.2.1 Architecture
The RTFM consists of meter, meter reader and a manager that
communicate via SNMP. The manager configures the meter, and the
meter reader collects data from the meter.
The IPFIX architecture [IPFIX-ARCH] defines metering, exporting
and collecting processes.
The RTFM architecture is very similar to the IPFIX architecture.
One could see the metering process as part of the meter and the
collecting process as part of the meter reader. IPFIX speaks
about processes instead of devices to clarify that multiple of
those processes be collocated on the same machine. Nevertheless,
IPFIX currently does not define a managing process, because
remote configuration is, at this time, out of scope for the
working group.
3.2.2 Flow Definition
RTFM and IPFIX both use the same definition of flow; a flow is a
set of packets which share a common set of end-point address
Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability May 2005
attribute values. A flow is therefore completely specified by
that set of values, together with an inactivity timeout. A flow
is considered to have ended when no packets are seen for at
least the inactivity time.
RTFM flows, however, are bidirectional, i.e. an RTFM meter
matches packets from B to A and A to B as separate parts of a
single flow, and maintains two sets of packet and byte counters,
one for each direction. IPFIX flows are unidirectional. Users
that require bidirectional flows have to match the two
directions in post-processing.
3.2.3 Configuration and Management
In RTFM, remote configuration (using an SNMP MIB) is the only
way to configure a meter. IPFIX metering processes can be
configured locally by a system administrator. The IPFIX group
currently does not address IPFIX remote configuration.
IPFIX metering processes export their configuration, i.e. the
layout of data within their templates, from time to time.
IPFIX collecting processes use that template information to
determine how they should interpret the IPFIX flow data they
receive.
3.2.4 Data Collection
One major difference between IPFIX and RTFM is that RTFM uses a
pull model whereas IPFIX uses a push model for the data
collection. An IPFIX exporting process is configured to export
data records to a specified list of IPFIX collecting processes.
The data records are pushed to the colleting process. The
condition when to send data records (e.g. flow termination) can
be configured in the exporting or metering process.
In contrast to this, an RTFM meter reader pulls data from a
meter by using SNMP. SNMP security on the meter determines
whether a reader is allowed to pull data from it.
3.2.5 Data Model Details
RTFM defines all its attributes in the RTFM Meter MIB [RFC
2720]. IPFIX information elements are defined in [IPFIX-INFO].
RTFM uses continuously-incrementing 64-bit counters for the
storage of the number of packets of a flow. The counters are
never reset and just wrap back to zero if the maximum value is
Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability May 2005
exceeded. Flows can be read at any time. The difference between
counter readings gives the counts for activity in the interval
between readings.
IPFIX allows absolute (totalCounter) and relative counters
(deltaCounter) [IPFIX-INFO]. The totalCounter are never reset
and just wrap to zero if values are too large, exactly as the
counters used in RTFM. The deltaCounter are reset to zero when
the associated flow record is exported.
3.2.6 Application/Transport Protocol
RTFM has a standards-track Meter MIB [RFC 2720], which is used
both to configure a meter and to store metering results. The
MIB provides a way to read lists of attributes with a single
Object Identifier (called a 'package'), which dramatically
reduces the SNMP overhead for flow data collection. SNMP, of
course, normally uses UDP as its transport protocol. Since RTFM
requires a reliable flow data transport system, an RTFM meter
reader must time out and resend unanswered SNMP requests. Apart
from being clumsy, this can limit the maximum data transfer rate
from meter to meter reader.
IPFIX is designed to work over a variety of different transport
protocols. SCTP and SCTP-PR (partially reliable) are mandatory.
UDP and TCP are optional. In addition, the IPFIX protocol
encodes data much more efficiently than does SNMP, hence IPFIX
will have lower data transport overhead than RTFM.
3.2.7 RTFM Summary
IPFIX provides a simple, powerful protocol for exporting flow
data from a metering process. RTFM provides bi-directional
flows and explicitly addresses dynamic configuration with a very
flexible flow definition. It may continue to be more suitable
in research situations where those features are needed.
A major difference between both frameworks is that RTFM works in
a pull mode for data collection, while IPFIX uses a push mode
for data export.
3.3 IPFIX and IPPM
The IPFIX protocol can be used to carry IPPM network performance
metrics or information that can be used to calculate those
metrics (see section 2.7).
3.4 IPFIX and PSAMP
Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability May 2005
The PSAMP group defines packet selection methods and the
reporting of whole packet or partial packet information. It also
defines the configuration of packet selection methods. The major
difference between IPFIX and PSAMP is that while the former
addresses the export of flow records, the latter addresses the
export's packet records.
The PSAMP group has decided to use IPIFX as its export protocol
for packet information. The Working Group describes a set of
requirements in [PSAMP-FM] that directly affect the export
protocol. In [PSAMP-PROTOCOL] the requirements have been
analyzed with respect to IPFIX. The conclusion was that IPFIX is
a general enough export protocol to be suitable for PSAMP
export. If needed, the information model can be easily extended.
PSAMP defines a PSAMP MIB for the configuration of packet
selection processes. One could consider extending this MIB to
allow configuration of IPFIX processes.
3.5 IPFIX and RMON
RMON [RFC 3577] is a widely used monitoring system that gathers
traffic data from RMON Agents in network devices using SNMP. The
RMON MIB is divided into sections, each section providing
different monitoring functions. For example, the 'Hosts'
section gathers statistics for hosts which are active on the
network and being monitored.
RMON does not cover flow measurement at all. To do so, one would
need to extend RMON by adding a MIB module to handle flows.
Further, one would need to devise a scheme for exporting high
volumes of flow data. In short, IPFIX is designed to provide
effective flow export; RMON is not.
3.6 IPFIX and IDMEF
The Intrusion Detection Message Exchange Format (IDMEF) [CuDF05]
is a standard data format developed within the IDWG Working
Group to exchange data alerts between automated Intrusion
Detection Systems (IDS). IDMEF provides a standard
representation of the alert information that an intrusion
detection analyzer reports when a suspicious event is detected.
These alerts may be simple or complex depending on analyzers'
capabilities, commercial vendor objectives, and intrusion
detection environments. IDMEF messages are implemented in XML
and composed by a basic schema and extension modules to define
alerts that are more complex. Once the kind of alert that should
be sent has been determined by the analyzer, it must be
Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability May 2005
formatted following the IDMEF rules. Generally, alerts are sent
when analyzers detect an event that they have been configured to
look for. The IPFIX protocol can be used to provide input for
intrusion detection systems, but also complementarily to IDMEF
by providing detailed information on intrusions traffic, suspect
events or anomalous traffic that differs from normal network
behavior.
4. Limitations
The goal of this section is to give recommendations where not to
use IPFIX. While the protocol is general enough to be adequate
for exporting data records for many applications, it still has
limitations.
Use of SCTP:
SCTP is the preferred protocol for IPFIX, i.e. a conforming
implementation must work over SCTP. Although IPFIX can also work
over TCP or UDP, users should make sure they have good reasons
for using protocols other than SCTP.
Push mode:
IPFIX works in push mode. That means data records are
automatically exported without waiting for a request.
The responsibility for initiating a data export is at the
exporting process. Exporting criteria are part of the
configuration of the exporting process.
Traffic characteristics are quite dynamic. Therefore the amount
of data (e.g. data records) that has to be exported can vary
over time. Push mode has more benefits if the trigger for data
export is related to events at the exporting process (e.g. flow
termination, memory shortage due to large amount of flows,
etc.). If the protocol used pull mode, the exporting process
would need to wait for a request to send the data. With push
mode it can send data immediately e.g. before memory shortage
would require a discarding of data.
Pull mode has advantages if the trigger for data export is
related to events at the collecting process (e.g. a specific
application requests immediate input).
In a pull mode, a request could simply be forwarded to the
exporting process. In a push mode, the exporting configuration
must be changed to trigger the export of the requested data.
Furthermore, with pull mode it can be prevented that the
collecting process is overloaded by the arrival of more data
records than it can process.
Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability May 2005
Whether this is a relevant drawback depends on the flexibility
of the IPFIX configuration and how IPFIX configuration rules are
implemented.
Template ID number:
The IPFIX specification limits the different template ID numbers
that can be assigned to the newly generated template records in
an Observation domain. In particular, template IDs up to 255 are
reserved for Template or option sets (or other sets to be
created) and template IDs from 256 to 65535 are assigned to data
sets. In the case of many exports requiring many different
templates, the set of Template IDs could be exhausted.
4.1 IPFIX and IPv6
There are two issues to consider:
- Generation and reporting of data records about IPv6 traffic
- Exporting data records over IPv6
The generation and reporting of data records about IPv6 traffic
is possible as appropriate information elements exist in [IPFIX-
INFO].
Exporting data records over IPv6 is not explicitly addressed in
[IPFIX-PROTO]. Nevertheless, since IPFIX runs over SCTP, SCTP-
PR, UDP or TCP, it is trivial to run IPFIX over IPv6 networks,
provided that the transport protocol being used to carry IPFIX
is running on the IPv6 network.
5. Security Considerations
This document describes the usage of IPFIX in various scenarios.
Security requirements for IPFIX target applications and security
considerations for IPFIX are addressed in [RFC3917] and [IPFIX-
PROTO]. These requirements had to be considered for the
specification of the IPFIX protocol. The IPFIX extensions
proposed in this document do not induce further security
hazards.
Section 3 of this document describes how IPFIX can be used in
combination with other frameworks. New security hazards can
arise when two individually secure frameworks are combined. For
the combination of AAA with IPFIX an application specific module
(ASM) or an IPFIX collector can function as transit point for
the messages. It must be ensured that at this point the applied
Zseby, Boschi, Brownlee, Claise [Page 20]
IPFIX Applicability May 2005
security mechanisms (e.g. encryption of messages) are
maintained.
6. Normative References
[RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander,
Requirements for IP Flow Information Export,
October 2004
[IPFIX-PROTO] B. Claise (Editor), IPFIX Protocol Specification,
Internet Draft <draft-ietf-ipfix-protocol-14.txt>,
work in progress, May 2005
[IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, Information Model
for IP Flow Information Export, Internet Draft
<draft-ietf-ipfix-info-06>, work in progress,
February 2005
7. Informative References
[IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek,
Architecture for IP Flow Information Export,
Internet Draft <draft-ietf-ipfix-architecture-
07.txt>, work in progress, March 2005
[Brow00] Nevil Brownlee, Packet Matching for NeTraMet
Distributions,
http://www2.auckland.ac.nz/net//Internet/rtfm/meeti
ngs/47-adelaide/pp-dist/
[CuDF05] D.Curry, H. Debar, H. Feinstein, The Intrusion
Detection Message Exchange Format, work in
progress, Internet Draft <draft-ietf-idwg-idmef-
xml-14.txt>, January 2005
[DuGr00] Nick Duffield, Matthias Grossglauser, Trajectory
Sampling for Direct Traffic Observation,
Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
August 28 - September 1, 2000.
[GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin,
Jed Martens, John G. Cleary, Nonintrusive and
Accurate Measurement of Unidirectional Delay and
Delay Variation on the Internet, INET'98, Geneva,
Switzerland, 21-24 July, 1998
Zseby, Boschi, Brownlee, Claise [Page 21]
IPFIX Applicability May 2005
[PSAMP] http://www.ietf.org/html.charters/psamp-
charter.html
[PSAMP-FW] Nick Duffield (Ed.), A Framework for Packet
Selection and Reporting, Internet Draft draft-ietf-
psamp-framework-08, work in progress, January 2005
[PoMB05] G. Pohl, L. Mark, E. Boschi, Use of IPFIX for
Export of Per-Packet Information, Internet Draft
<draft-pohl-perpktinfo-02.txt>, work in progress,
February 2005
[RFC2598] V. Jacobson, K. Nichols, K. Poduri, An Expedited
Forwarding PHB, Request for Comments: 2598, June
1999
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, A One-way
Delay Metric for IPPM, Request for Comments: 2679,
September 1999
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, A One-way
Packet Loss Metric for IPPM, September 1999
[RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, A Round-trip
Delay Metric for IPPM, RFC 2681, September 1999
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, Traffic Flow
Measurement: Architecture, RFC 2722, October 1999.
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, Generic AAA Architecture, RFC 2903, August
2000
[RFC3334] T. Zseby, S. Zander, G. Carle, Policy-Based
Accounting, Request for Comments: 3334, October
2002
[RFC3393] C. Demichelis, P. Cimento, IP Packet Delay
Variation Metric for IPPM, RFC 3393, November 2002
[RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch,
D.Romascanu, Introduction to the Remote Monitoring
(RMON) Family of MIB Module, RFC 3577,August 2003
[RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J.
Arkko, Diameter Base Protocol, Request for Comments
3588, September 2003
Zseby, Boschi, Brownlee, Claise [Page 22]
IPFIX Applicability May 2005
[ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle,
Evaluation of Building Blocks for Passive One-way-
delay Measurements, Proceedings of Passive and
Active Measurement Workshop (PAM 2001), Amsterdam,
The Netherlands, April 23-24, 2001
8. Acknowledgements
We would like to thank the following persons for their
contribution, discussion on the mailing list and valuable
comments:
Sebastian Zander
Robert Lowe
Reinaldo Penno
Part of the work has been developed in the research project 6QM
co-funded with support from the European Commission.
9. Author's Addresses
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
Elisa Boschi
Fraunhofer Institute for Open Communication Systems (FOKUS)
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Phone: +49 30 3463 7366
Email: boschi@fokus.fhg.de
Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Phone : +1 858 534 8338
Email : nevil@caida.org
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Zseby, Boschi, Brownlee, Claise [Page 23]
IPFIX Applicability May 2005
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
10. Full Copyright Statement
"Copyright (C) The Internet Society (2005). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into.
11. Intellectual Property Statement
The IETF has been notified by Cisco of intellectual property
rights claimed in regard to some or all of the specification
contained in this document. For more information, see
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix-as-
02.txt
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 procedures with
respect to rights in RFC 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.
Zseby, Boschi, Brownlee, Claise [Page 24]
IPFIX Applicability May 2005
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.
12. Copyright Statement
Copyright (C) The Internet Society (2005). 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.
13. Disclaimer
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.
Zseby, Boschi, Brownlee, Claise [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 21:08:20 |