One document matched: draft-ietf-ipfix-as-06.txt
Differences from draft-ietf-ipfix-as-05.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-06.txt> Elisa Boschi
Expires: January 2006 Fraunhofer FOKUS
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
July 2005
IPFIX Applicability
draft-ietf-ipfix-as-06.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).
Zseby, Boschi, Brownlee, Claise [Page 1]
IPFIX Applicability July 2005
Abstract
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 furthermore shows how the
IPFIX framework relates to other architectures and frameworks.
Zseby, Boschi, Brownlee, Claise [Page 2]
IPFIX Applicability July 2005
Table of Contents
1. Introduction............................................4
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.....................................9
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).....................11
2.7.3 Measurement of One-way-loss (OWL)......................11
2.7.4 Measurement of IP delay variation (IPDV)...............12
2.7.5 Transport of IPPM Metrics..............................12
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 Use of a different transport protocol than SCTP........19
4.2 Push vs. pull mode.....................................19
4.3 Template ID number.....................................20
4.4 IPFIX and IPv6.........................................20
5. Security Considerations................................20
6. Normative References...................................21
7. Informative References.................................21
8. Acknowledgements.......................................23
9. Authors' Addresses.....................................23
10. Full Copyright Statement...............................24
11. Intellectual Property Statement........................24
12. Copyright Statement....................................25
13. Disclaimer.............................................25
Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability July 2005
1. Introduction
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 enable 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 to 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.
Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability July 2005
For accounting purposes, it would be advantageous to have the
ability to use IPFIX flow records as accounting input in an AAA
infrastructure. AAA servers then could provide the mapping
between user and flow information.
Note that the reliability requirements defined in [RFC3917] 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].
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:
Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability July 2005
Src. IP addr. | Dst. IP addr. | Type of service | Octets Number
--------------+---------------+-----------------+--------------
198.18.1.12 | 198.18.2.254 | 101110 | 987410
198.18.1.27 | 198.18.2.23 | 101110 | 170205
198.18.1.56 | 198.18.2.65 | 101110 | 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]
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 | 987410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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.
Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability July 2005
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 and system traffic for attacks and other
security-related events. Sensors respond to and notify the
administrator 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 (with a console)
- 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 collector has all relevant data. Getting the
information from a collector allows correlating data from
different exporting processes (e.g. from different routers) to
get a better picture of what is going on in the network.
IPFIX provides useful input data for basic intrusion detection
functions like detecting of 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 for exporting PSAMP
information.
Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability July 2005
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
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 profits greatly from the combination of
IPFIX functions with AAA functions (see section 3.1). Such an
interoperation enables further means for attacker 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
Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability July 2005
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
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 basis for business models. The
flexible flow definition allows different viewpoints on the
data. The observation of different traffic statistics (like
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.
Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability July 2005
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 because 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.
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 cannot be observed, the RTT cannot 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].
Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability July 2005
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 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 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 data records. The flow
ID then can be associated to flow properties in a data record.
With this the flow information needs to be transferred only
once. The packet information just relates to much smaller flow
IDs, without the need to transfer the whole flow information for
each packet [BoMa05].
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 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 of 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 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
Zseby, Boschi, Brownlee, Claise [Page 11]
IPFIX Applicability July 2005
(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
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
Zseby, Boschi, Brownlee, Claise [Page 12]
IPFIX Applicability July 2005
clients at access devices and AAA servers, and among AAA
servers. It is used also 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.
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 has also
high potential for intrusion and attack detection. AAA controls
network access and maintains data about users and nodes. AAA
functions can help to 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
Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability July 2005
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).
+---------+ 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 July 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 and 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
attribute values. A flow is therefore completely specified by
Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability July 2005
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 flow 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
exceeded. Flows can be read at any time. The difference between
Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability July 2005
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 overheads 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 that need those features.
A major difference between both frameworks is that RTFM works in
pull mode and IPFIX uses push mode for data collection.
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
The PSAMP group defines packet selection methods and the
reporting of packet information. It also defines the
Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability July 2005
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 of
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 in a general
way 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 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
formatted following the IDMEF rules.
Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability July 2005
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 of 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.
4.1 Use of a different transport protocol than 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.
4.2 Push vs. pull 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.
Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability July 2005
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.
Whether this is a relevant drawback depends on the flexibility
of the IPFIX configuration and how IPFIX configuration rules are
implemented.
4.3 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.4 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
Zseby, Boschi, Brownlee, Claise [Page 20]
IPFIX Applicability July 2005
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 has to be ensured that at this point the
applied 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", RFC
3917, October 2004
[IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification",
Internet Draft <draft-ietf-ipfix-protocol-16.txt>,
work in progress, June 2005
[IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model
for IP Flow Information Export", Internet Draft
<draft-ietf-ipfix-info-07>, work in progress, May
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-
08.txt>, work in progress, March 2005
[Brow00] Nevil Brownlee, "Packet Matching for NeTraMet
Distributions",http://www2.auckland.ac.nz/net//Inte
rnet/rtfm/meetings/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
Zseby, Boschi, Brownlee, Claise [Page 21]
IPFIX Applicability July 2005
Delay Variation on the Internet", INET'98, Geneva,
Switzerland, 21-24 July, 1998
[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
[BoMa05] E. Boschi, L. Mark, " Use of IPFIX for Export of
Per-Packet Information", Internet Draft <draft-
boschi-export-perpktinfo-00.txt>, work in progress,
June 2005
[RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
Packet Loss Metric for IPPM",RFC 2680, September
1999
[RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999
[RFC2722] N. Brownlee, C. Mills, 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
[RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000
[RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based
Accounting", RFC 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
Zseby, Boschi, Brownlee, Claise [Page 22]
IPFIX Applicability July 2005
[RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J.
Arkko, "Diameter Base Protocol", RFC 3588,
September 2003
[ZsZC01] T. Zseby, S. Zander, G. 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 Loewe
Reinaldo Penno
Part of the work has been developed in the research project 6QM
co-funded with support from the European Commission.
9. Authors' 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
Zseby, Boschi, Brownlee, Claise [Page 23]
IPFIX Applicability July 2005
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
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
Zseby, Boschi, Brownlee, Claise [Page 24]
IPFIX Applicability July 2005
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.
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 08:44:43 |