One document matched: draft-ietf-ipfix-as-04.txt
Differences from draft-ietf-ipfix-as-03.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-04.txt> Elisa Boschi
Expires: August 2005 Fraunhofer FOKUS
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
February 2005
IPFIX Applicability
draft-ietf-ipfix-as-04.txt
Status of this Memo
This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667. 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 become aware
will be disclosed, in accordance with RFC 3668.
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 February 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 February 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.........................................7
2.4 Peering Agreements.......................................7
2.5 Traffic Engineering......................................7
2.6 Data Warehousing and Mining..............................8
2.7 SLA validation...........................................8
2.8 Traffic Monitoring.......................................8
2.8.1 Measurement of Round-trip-time (RTT)....................9
2.8.2 Measurement of One-way-delay (OWD)......................9
2.8.3 Measurement of One-way-loss (OWL)......................10
2.8.4 Measurement of IP delay variation (IPDV)...............10
3. Relation of IPFIX to other frameworks and protocols.....10
3.1 IPFIX and AAA...........................................10
3.1.1 Connecting via an AAA Client...........................11
3.1.2 Connecting via an Application Specific Module (ASM)....12
3.2 IPFIX and RTFM..........................................13
3.2.1 Flow Definition........................................13
3.2.2 Configuration and Management...........................13
3.2.3 Data Model Details.....................................14
3.2.4 Application/Transport Protocol.........................14
3.2.5 RTFM Summary...........................................15
3.3 IPFIX and IPPM..........................................15
3.4 IPFIX and PSAMP.........................................15
3.5 IPFIX and RMON..........................................15
3.6 IPFIX and IDMEF.........................................16
4. Limitations.............................................16
4.1 IPFIX and IPv6..........................................17
5. Security Considerations.................................17
6. Normative References....................................17
7. Informative References..................................17
8. Acknowledgements........................................19
9. Author's Addresses......................................19
10. Full Copyright Statement................................20
11. Intellectual Property Statement.........................20
12. Copyright Statement.....................................21
13. Disclaimer..............................................21
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 for various
Zseby, Boschi, Brownlee, Claise [Page 3]
IPFIX Applicability February 2005
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 customer applications. This
section describes how different applications can use IPFIX.
2.1 Accounting
Usage based accounting is one of the major applications for
which the IPFIX protocol has been developed. IPFIX data provide
fine-grained metering (for example, flow records include details
such as IP addresses, packet and byte counts, timestamps, Type
of Service (ToS), application ports, etc.) for highly flexible
and detailed resource usage accounting. 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. A
tariff can, for instance, be based on individual end-to-end
streams. In that case accounting can be realized with a flow
definition determined by the quintuple that consists of source
address, destination address, protocol and port numbers. Another
example is a class-dependent tariff (e.g. in a DiffServ
network). For this flows could be distinguished just by DiffServ
codepoint (DSCP) and source address.
The essential elements needed for accounting are the number of
transferred packets and bytes per flow which are contained in
IPFIX flow records. Furthermore IPFIX provides a very flexible
definition of flows, so arbitrary flow-based accounting models
can be realized without any extensions to the IPFIX protocol.
Nevertheless the configuration of flow definitions is out of
scope of the IPFIX definition.
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.
Zseby, Boschi, Brownlee, Claise [Page 4]
IPFIX Applicability February 2005
2.1.1 Example
Letªs suppose someone has a Service Level Agreement (SLA) in a
DiffServ network and has to be accounted based on the traffic
volume. The information to export in this case is:
- The source IP address (IPv4), so the length is 4
- Type of Service
- The number of bytes of the Flow
The template set (in case we use only IETF specified Information
Elements) will 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 = 2 | Length = 17 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_SRC_ADDR = 0x0008 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CLASS_OF_SERVICEIPv4 = 0x0005 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 0x0001 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported is listed in the following table:
Source IP address | Type of service | Bytes Number
| |
---------------------------------------------------------------
192.181.17.0 | 101110 | 8987410
192.180.17.8 | 101110 | 170205
192.129.9.2 | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zseby, Boschi, Brownlee, Claise [Page 5]
IPFIX Applicability February 2005
| Set ID = 256 | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.181.17.0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 101110 00 | 8987410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.180.17.8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 101110 00 | 170205 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.129.9.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 101110 00 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 33113 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2 Security Analysis and Intrusion Detection with IPFIX
Intrusion detection systems (IDS) monitor and control security
incidents. A typical IDS system includes components like sensor,
event collector, 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 (e.g. detecting unusually high loads) such as details
on source and destination addresses, along with the start time
Zseby, Boschi, Brownlee, Claise [Page 6]
IPFIX Applicability February 2005
of flows, TCP flags, application ports and flow volume. This
data can be used to analyze network security incidents and
identify attacks. Nevertheless, 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.
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.
2.3 Network Planning
IPFIX data 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. IPFIX data optimizes both strategic
network planning (peering, backbone upgrade planning, and
routing policy planning) as well as tactical network engineering
decisions (upgrading the router or link capacity). This helps to
minimize the total cost of network operations while maximizing
network performance, capacity, and reliability.
2.4 Peering Agreements
IPFIX data enables ISP peering partners to measure the volume
and characteristics of traffic exchanged with other ISP peers.
ISP peering partners, consortia, or business coalitions can use
IPFIX to exchange data between different domains. Having a means
to share measurement data allows for more accurate end-to-end
measurements. Through IPFIX data measured with different (often
domain specific) tools can be exchanged and compared with data
belonging to other domains.
This is especially useful for inter-domain SLA validation where,
in order to be able to provide accurate data, an ISP has to
obtain measurements from other ISPs crossed in the end-to-end
path.
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
Zseby, Boschi, Brownlee, Claise [Page 7]
IPFIX Applicability February 2005
balancing traffic across alternate paths, or for forwarding
traffic of a certain set of prefixes on a preferred route.
2.6 Data Warehousing and Mining
IPFIX data (or derived information) can be stored for later
retrieval and analysis to support proactive marketing and
customer service programs. An example of this would be 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
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.
2.8 Traffic Monitoring
IPFIX data can be used for extensive near real-time traffic
monitoring. Traffic patterns associated with routing devices and
switches on an individual or network wide basis can be displayed
enabling proactive problem detection, efficient troubleshooting,
and rapid problem resolution.
IPFIX data enables content and service providers to perform a
detailed, time-based, and application-based usage analysis of a
network. They also provide detailed information for
understanding customer or end-user usage of network and
application resources. This information can then be used to
efficiently plan and allocate access, backbone, and application
resources, as well as to detect and resolve potential security
and policy violations.
This section describes how the monitoring of different metrics
can be performed with IPFIX. All of the metrics require at least
Zseby, Boschi, Brownlee, Claise [Page 8]
IPFIX Applicability February 2005
an extension of the IPFIX information model because the
necessary information such as round-trip-time, packet Ids, etc.,
is currently not part of the model. However given the
extensibility and flexibility of IPFIX the missing attributes
can be easily defined.
2.8.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, this only works for passive measurements 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 in both directions. A classification of
the protocols mentioned above has to be done. That means parts
of the transport header are used for the classification. Since a
differentiation of flows in accordance to the transport header
is one of the requirements for IPFIX, such classification can be
performed without extensions. Nevertheless, the meter 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.8.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.
Zseby, Boschi, Brownlee, Claise [Page 9]
IPFIX Applicability February 2005
To reduce the amount of measurement data a unique packet ID can
be calculated from the header and part and/of the content e.g.
by using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. The
capability of using content information 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 packet content. 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. However, it is possible to extend IPFIX with a
scheme to export per-packet information by providing special
templates for that purpose. The one way delay metric is defined
in [RFC2679].
2.8.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.8.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.8.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 also be observed at the second point (known
routing).
The one-way loss metric is defined in [RFC2680].
2.8.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.
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. The DIAMETER
Zseby, Boschi, Brownlee, Claise [Page 10]
IPFIX Applicability February 2005
protocol is used for AAA communication for network access
services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture
[RFC2903] provides a framework for extending the AAA support
also for 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 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.
The provisioning of accounting with IPFIX can be realized
without an AAA infrastructure. The collector can directly
forward the measurement information to an accounting
application. Nevertheless, if an AAA infrastructure is in place,
IPFIX can provide the input for the generation of accounting
records and several features of the AAA architecture can be
used. Features include the mapping of a user ID to the flow
information (by using authentication information), the
generation of DIAMETER accounting records and the secure
exchange of accounting records between domains with DIAMETER.
Two possibilities to connect IPFIX and AAA can be distinguished:
3.1.1 Connecting via an AAA Client
One possibility means 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 11]
IPFIX Applicability February 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 12]
IPFIX Applicability February 2005
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 3: IPFIX connects to AAA server via ASM
3.2 IPFIX and RTFM
This section compares the Real-time Traffic Flow Measurement
(RTFM) framework with the IPFIX framework.
3.2.1 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
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
needing bidirectional flows will need to match the two
directions in post-processing.
3.2.2 Configuration and Management
In RTFM, remote configuration (using an SNMP MIB) is the only
way to configure a meter. IPFIX, however, makes no provision
for remote configuration - meters must be configured locally by
Zseby, Boschi, Brownlee, Claise [Page 13]
IPFIX Applicability February 2005
a System Administrator. IPFIX meters export their configuration,
i.e. the layout of data within their templates, from time to
time.
IPFIX collectors use that template information to determine how
they should interpret the IPFIX flow data they receive.
An IPFIX meter must normally be configured to export data to a
specified list of IPFIX collectors, i.e. data is pushed out by
the meter. In contrast, an RTFM meter reader pulls data from a
meter; SNMP security (data view) on the meter determines whether
a reader is allowed to pull data from it.
3.2.3 Data Model Details
RTFM defines all its attributes in the RTFM Meter MIB [RFC
2720], and IPFIX defines its information elements in the IPFIX
Information Model document.
In IPFIX, fields such as ToPDUs and FromPDUs are stored in 64-
bit counters. Exported flows carry such counter values as they
were after the flow's last packet. Long-running flows may be
broken into a sequence of shorter flows; in that case the flow
counters are zeroed when the flow is exported.
RTFM uses continuously-incrementing 64-bit counters, which are
never reset. Instead, flows can be read at any time; the
difference between counter readings gives the counts for
activity in the interval between readings.
3.2.4 Application/Transport Protocol
RTFM has a standards-track Meter MIB [RFC 2720], which can be
used both to configure a meter and to read flow data from it.
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. The preferred protocol is SCTP (either reliable or
partially reliable) or TCP. In addition, the IPFIX protocol
Zseby, Boschi, Brownlee, Claise [Page 14]
IPFIX Applicability February 2005
encodes data much more efficiently than does SNMP, hence IPFIX
will have lower data transport overheads than RTFM.
A need for high flow data rates highlights the need for careful
systems design when building a flow data collection system.
When data rates are high, and it is not possible to use a high
level of aggregation, then it makes sense to have the collectors
very close to their exporters. Once the data is safely on a
dedicated host machine, large volumes of it can be moved using
'background' techniques such as FTP.
3.2.5 RTFM Summary
IPFIX is designed to be a simple, high-performance system for
exporting flow data from a meter, making it highly suitable for
that purpose. RTFM provides bi-directional flows, dynamic
configuration, and the ability to work with much more general
definitions of flow end-points. It may continue to be more
suitable in 'research' situations which need those features.
Another difference between the two systems is that while RTFM
works in ªpullª mode, IPFIX uses ªpushª mode.
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.8).
3.4 IPFIX and PSAMP
There is currently a very dynamic relation between IPFIX and
PSAMP. PSAMP defines, between others, the information to be
reported on sampled packets, describes the protocol by which
this information is reported and the protocol by which the
packet reporting is configured. The major difference between
IPFIX and PSAMP protocols is that while the former exports flow
records, the latter exports packet records.
The Working Group describes in [PSAMP-FM] a set of requirements
that affect directly the export protocol. In [PSAMP-PROTOCOL]
the requirements have been analyzed with respect to IPFIX and
the conclusion is that IPFIX is an exporting protocol general
enough to be suitable for PSAMP. If needed, the information
model can be easily extended.
3.5 IPFIX and RMON
Zseby, Boschi, Brownlee, Claise [Page 15]
IPFIX Applicability February 2005
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) [CuDF04]
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.
Generally, alerts are sent when analyzers detect an event that
they have been configured to look for.
The IPFIX protocol can be used complementarily to IDMEF for
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 flow data in many applications, it still has
limitations.
SCTP is the preferred protocol for IPFIX, i.e. a conforming
implementation must work over SCTP. Although IPFIX can also work
Zseby, Boschi, Brownlee, Claise [Page 16]
IPFIX Applicability February 2005
over TCP or UDP -
- users make sure they have good reasons for
using protocols other than SCTP.
IPFIX works in ªpushª mode that is data are automatically
exported without waiting for a request. It is therefore a sub-
optimal solution when the monitoring configuration needs to be
changed often. ªPullª modewould be in that case more
appropriate.
In case of many exports, requiring many different templates, the
Template IDs could not be enough
4.1 IPFIX and IPv6
There is no problem in reporting IPv6 data with IPFIX, provided
only that the transport protocol being used to carry IPFIX (SCTP
is preferred) is running on the IPv6 network.
5. Security Considerations
This document describes the usage of IPFIX in various scenarios.
The security requirements for the IPFIX target applications are
addressed in the IPFIX requirements draft. These requirements
must 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 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 ",
October 2004
7. Informative References
[Awdu02] Daniel O. Awduche, et. al.," Overview and
Principles of Internet Traffic Engineering", (work
in progress), Internet Draft, Internet Engineering
Zseby, Boschi, Brownlee, Claise [Page 17]
IPFIX Applicability February 2005
Task Force, draft-ietf-tewg-principles-02.txt, May
2002
[Brow00] Nevil Brownlee: Packet Matching for NeTraMet
Distributions,http://www2.auckland.ac.nz/net//Inter
net/rtfm/meetings/47-adelaide/pp-dist/
[CuDF04] D.Curry, H. Debar, H. Feinstein: ªªThe Intrusion
Detection Message Exchange Formatªª,(work in
progress), Internet Draft, Internet Engineering
Task Force, <draft-ietf-idwg-idmef-xml-11.txt>,
January 2004
[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
[PSAMP-FW] Nick Duffield (Ed.): A Framework for Packet
Selection and Reporting, Internet Draft draft-ietf-
psamp-framework-08, work in progress, January 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
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, "Generic AAA Architecture", RFC 2903,
August 2000
[RFC3393] C. Demichelis, P. Cimento: IP Packet Delay
Variation Metric for IPPM, RFC 3393, November 2002
Zseby, Boschi, Brownlee, Claise [Page 18]
IPFIX Applicability February 2005
[RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch,
D.Romascanu: Introduction to the Remote Monitoring
(RMON) Family of MIB Module, RFC 3577,
[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 Loewe
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
Zseby, Boschi, Brownlee, Claise [Page 19]
IPFIX Applicability February 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 20]
IPFIX Applicability February 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 21] | PAFTECH AB 2003-2026 | 2026-04-23 05:27:52 |