One document matched: draft-ietf-ipfix-as-00.txt
Internet Draft Tanja Zseby
Document: <draft-ietf-ipfix-as-00.txt> Fraunhofer FOKUS
Expires: December 2003 Reinaldo Penno
Nortel Networks
Nevil Brownlee
CAIDA
Benoit Claise
Cisco Systems
June 2003
IPFIX Applicability
draft-ietf-ipfix-as-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes how various applications can use the IP
Flow Information Export (IPFIX) protocol. It furthermore shows
how the IPFIX framework relates to other architectures and
frameworks.
Expires December 2003 [Page 1]
IPFIX Applicability June 2003
Table of Contents
1. Introduction................................................3
2. Applications of IPFIX.......................................3
2.1 Accounting..................................................3
2.2 Peering Agreements..........................................4
2.3 Traffic Engineering.........................................4
2.4 Data Warehousing and Mining.................................4
2.5 Network Monitoring..........................................4
2.5.1 Application Monitoring and Profiling.......................5
2.5.2 User Monitoring and Profiling..............................5
2.5.3 QoS Monitoring.............................................5
2.5.4 Measurement of delay variation with IPFIX..................6
2.5.5 Sampling for QoS Monitoring................................6
3. Relation of IPFIX to other frameworks and protocols.........7
3.1 IPFIX and AAA...............................................7
3.1.1 Connecting via an AAA Client...............................7
3.1.2 Connecting via an Application Specific Module (ASM)........7
3.2 IPFIX and RTFM..............................................8
3.2.1 Definition of 'flow'.......................................8
3.2.2 Configuration and Management...............................8
3.2.3 Data Model details.........................................9
3.2.4 Application/transport protocol.............................10
3.3 IPFIX Considerations for Middleboxes........................10
3.3.1 Firewall...................................................11
3.3.2 Network Address Translation................................11
3.3.3 Traffic Conditioners.......................................12
3.3.4 Tunneling..................................................13
3.3.5 VPNs.......................................................13
4. Security Consideration......................................15
5. References..................................................15
Expires December 2003 [Page 2]
IPFIX Applicability June 2003
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 input for various applications. This
document describes how applications can use the IPFIX protocol.
Furthermore, the relationship of IPFIX to other frameworks and
architectures are 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 provides
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.
The essential elements needed for this are the number of
transferred packets and bytes per flow. IPFIX flow records
contain this information together with the flow identification.
With this the essential input for usage-based accounting is
provided by IPFIX.
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. Accounting in such a scenario can be realized for
instance with a flow definition determined by the quintuple that
consists of source address, destination address, protocol and
portnumbers. Another example is a class-dependent tariff (e.g.
in a DiffServ networks). For this flows could be distinguished
just by DiffServ codepoint (DSCP) and source address.
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 a AAA
infrastructure. AAA servers then could provide the mapping
between user and flow information.
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)
Expires December 2003 [Page 3]
IPFIX Applicability June 2003
_ - collects data from sensors (with one or more event
collectors)
_ - stores data from sensors (in a database)
With IPFIX, events of interest can be reported to the sensor
either by the collecting process or directly by the exporting
process. It depends on the scenario and the events of interest
which solution is better. 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 about what is going on in the network.
IPFIX can provide useful input data for basic intrusion
detection functions (e.g. detecting unusual high loads). IPFIX
data provides details on source and destination addresses, along
with the start time of flows and application ports. This data
can be used to analyze network security and identify
attacks. Nevertheless, for some scenarios intrusion detection
may require further insight into packet content. In other
scenarios, a preprocessing of data already at the measurement
device is desirable. IPFIX allows a flexible report definition.
Therefore, extensions to the metering process and the IPFIX
report format could improve the IPFIX support for intrusion
detection systems.
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.2 Peering Agreements
IPFIX data enables ISP peering partners to measure the volume
and characteristics of traffic exchanged with other ISP peers.
2.3 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.4 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.5 Network Monitoring
IPFIX data enables extensive near real-time network monitoring
capabilities. IPFIX data analysis can be used to display traffic
Expires December 2003 [Page 4]
IPFIX Applicability June 2003
patterns associated with routing devices and switches on an
individual or network wide basis. This can display traffic or
application-based views and therefore provide proactive problem
detection, efficient troubleshooting, and rapid problem
resolution.
2.5.1 Application Monitoring and Profiling
IPFIX data enables content and service providers to view
detailed, time-based, and application-based usage of a network.
This information allows planning and allocation of network and
application resources (such as Web server, gaming or
multimedia).
2.5.2 User Monitoring and Profiling
IPFIX data provides a detailed understanding of 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.
2.5.3 QoS Monitoring
The performance of QoS monitoring is one target application for
using 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 need to be synchronized. Furthermore, such
measurements would benefit from post-processing functions (e.g.
packet ID generation) at the exporter and/or collector. This
section describes how the monitoring of different metrics can be
performed with IPFIX. The following metrics are considered:
round trip time, one-way-delay, loss and delay variation.
2.5.3.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 like 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. In order
to use this measurement technique, the IPFIX metering process
needs to measure 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.
2.5.3.2 Measurement of One-way-delay (OWD)
Expires December 2003 [Page 5]
IPFIX Applicability June 2003
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
[MaPZ03].
To reduce the amount of measurement data a unique packet ID can
be calculated from the header and part of the content e.g. by
using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. Since
IPFIX is not targeted at packet capturing these functionalities,
do not need to be supported by a standard IPFIX meter.
Nevertheless, in some scenarios it might be sufficient to
calculate a packet ID under consideration of 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 can
be a sufficient solution.
The second issue here is the transfer of packet IDs. IPFIX
transfers per flow information. Since the flow definition is
very flexible, one could define flows that consist only of one
packet and with this allow the transfer of per packet
information. Nevertheless, this approach would be very
inefficient, since flow records also contain further
information. A more efficient scheme could be defined by
modifying the flow record format and provide templates
especially for that purpose.
Measurement of Loss
Passive loss measurements for single flows can be performed at
one measurement point by using sequence numbers that are present
in higher layer protocols. 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 above and just consider
packets as lost that do not arrive at the second measurement
point in a given maximum time frame.
2.5.4 Measurement of delay variation with IPFIX
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.5.5 Sampling for QoS Monitoring
Since QoS monitoring can produce an overwhelming amount of
measurement data, methods such as aggregation of results, and
sampling would greatly increase the efficiency of the collection
and analysis process. Sampling methods can be grouped according
to the sampling strategy (systematic, random or stratified) and
the trigger that starts a sampling interval (count-based, time-
based or packet-content-based) [ClPB93]. Sampling can also be
used as a method to dynamically reduce resource consumption if
the meter is overloaded. Then the IPFIX meter can switch to a
sampling method if too many packets have to be observed. Since
the expected estimation error heavily depends on the deployed
sampling strategy, the application that receives the data needs
to be aware of the sampling scheme and the parameters in use.
Therefore, it is important that the IPFIX exporter informs the
collector precisely about the used sampling strategy. This is
especially important if the metering process dynamically invokes
sampling. The configuration and reporting of sampling methods is
addressed in the PSAMP group.
Expires December 2003 [Page 6]
IPFIX Applicability June 2003
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
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 to connect 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).
+---------+ 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
Expires December 2003 [Page 7]
IPFIX Applicability June 2003
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.
+---------+ 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 Definition of 'flow'
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 are bidirectional, which has given rise to some
confusion.
At the simplest level, a flow information exporter may achieve
this by maintaining two unidirectional flows, one for each
direcion. To export bidirectional flow information, e.g. to-
and from- packet counts, for a flow from A to B, the exporter
has only to search its flow table to find the matching flow from
B to A.
RTFM, however, takes bi-directionality a stage further, by
including in the RTFM architecture [RFC 2722] a fully-detailed
algorithm for realtime matching of the two directions of a flow.
This was done for two reasons, to reduce the memory required to
store each flow (common address attributes for each direction),
and to allow for attributes which required fine detail for the
two directions, e.g. short-term bit rate distributions [RFC
2724].
** So far there has been no suggestion that IPFIX should do
this.
3.2.2 Configuration and Management
The RTFM architecture specifies a complete system for gathering
flow information. It defines three entities,
- Meters are very similar to IPFIX exporters.
Expires December 2003 [Page 8]
IPFIX Applicability June 2003
- Meter Readers are very similar to IPFIX collectors.
- Managers co-ordinate the activities of meters and meter
readers, and download configuration to them.
Note that the whole RTFM system is asynchronous, many readers
may collector flow data from a meter, and any reader may collect
flow data from many meters.
Rulesets allow the user to specify which flows are of interest,
which are the source and destination ends of each flow, and what
level of address granularity is required in the metered flows.
For example, one may select all packets from 192.168/16, but
build flow information for 192.168/24. RTFM selection is done
by testing under masks, and the masks do not have to use
consective ones from the left. Non-contiguous masks were
considered important for handling some OSI protocols, but the
need for that has diminished considerably.
The RTFM approach is based on RMON, in that if a user wants to
collect flow data for some particular set of flows, this can be
achieved by writing a ruleset, i.e. an SRL program [RFC 2723],
to specify what flows are of interest, requesting a manager to
download that ruleset to a meter, and requesting the manager to
have a meter reader collect the flow data at specified
intervals.
The details of how the manager communicates this information to
meters and meter readers is not specified in the architecture.
RTFM has a Meter MIB [RFC 2720], which is a standard which can
be used to configure a meter, but nothing is said about how to
configure a meter reader.
The extent to which IPFIX should specify how meters or exporters
should be configured is, at this stage, an open question.
Clearly a collector needs some way to be sure of what it's
collecting, e.g. by receiving 'templates' from the meter.
RTFM and IPFIX both leave parts of the system unspecified. For
RTFM flow data to be useful one must know the ruleset used to
configure the meter, but a user can specify the ruleset. For
IPFIX one knows what the data is from the templates, but we have
yet to determine whether in-band configuration will be
supported.
3.2.3 Data Model details
3.2.3.1 Count in one bucket
Within a ruleset, a packet may only be counted on one bucket,
i.e. it may only be included in one flow. This means that the
meter does not have to keep track of overlapping flows - if such
aggregation is required, it must be done after the raw flow data
has been read by a meter reader.
From time to time one may wish to collect flow data for
different levels of aggreation at the same time. RTFM allows a
meter to run several rulesets at the same time, and meter
readers must specify which rulesets they are collecting data
from.
The 'count in one bucket' rule, together with the ability to run
multiple rulesets, has proved very simple and effective in
practice.
3.2.3.2 Counter wrapping
Expires December 2003 [Page 9]
IPFIX Applicability June 2003
For its packet- and byte-count attributes RTFM uses
continuously-incrementing 64-bit counters, which are never
reset. This makes asynchronous meter reading easy, any reader
simply has to remember its previous reading and compute the
difference. The only caveat is that the meter should be read
often enough to avoid situations when the counter has cycled
more than once between readings.
3.2.3.3 Sampling issues
RTFM provides 1 out of N sampling as a configuration option, so
that some metering interfaces may only process every Nth packet.
The RTFM Arcitecture [RFC 2722] does not discuss the statistical
implications of this, merely saying that users will need to
satisfy themselves that sampling makes sense in their
environment.
RTFM makes no provision for flow sampling. Recently there has
been a lot of interest in flow sampling schemes which favour the
'most important' flows, perhaps we need to consider this for
IPFIX.
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. NeTraMet, a widely-used
open-source RTFM implementation, uses SNMPv2C for configuration
and 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. SNMP over TCP would
be a better approach, but that is currently an IRTF project.
On the other hand, RTFM does not specify an application protocol
in its architecture, leaving this as an implementation issue.
For example, a team at IBM Research implemented a RTFM meter and
meter reader in a single host, with the reader storing the flow
data directly into a large database system. Simlarly, many
NeTraMet user run the meter and meter reader on the same host
system.
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.
The RTFM architecture only specifies a pull model for getting
data out of a meter. To implement push mode data transfer would
require specification of triggers to indicate when data should
be sent for each flow.
3.3 IPFIX Considerations for Middleboxes
A Middlebox is a network intermediate device that implements one
or more of the middlebox services. Policy based packet filtering
(a.k.a. firewall), Network address translation (NAT), Intrusion
Expires December 2003 [Page 10]
IPFIX Applicability June 2003
detection, Load balancing, Policy based tunneling and IPsec
security are all examples of a middlebox function (or service).
[MCFW]. For instance, a NAT middlebox is a middlebox
implementing NAT service and a firewall middlebox is a middlebox
implementing firewall service. It is expected that the exporter
in the IPFIX architecture will probably implement some form of
middlebox service given its ubiquity today. Since some of these
middlebox services might affect flow exportation and how the
collector interprets them, there is a need to provide an
analysis of these implications in relation to the IPFIX
architecture and a set of recommendations. The following
sections provide a non-exhaustive analysis of middlebox
services, its implications on the IPFIX architecture and a
corresponding set of recommendations.
3.3.1 Firewall
Firewall is a policy based packet filtering middlebox function,
typically used for restricting access to/from specific devices
and applications. The policies are often termed Access Control
Lists (ACLs)[MCFW]. The firewall middlebox service allows the
exporter to explicitly drop packets based on some administrative
policy. In this case, the exporter can take one of the following
actions that will have a direct impact on the information
provided by the collector to the user.
* Silently Discard
In this case the packet is discarded and no flow information
record is sent to the collector.
* Discard and export flow
In this case the packet is discarded, and the flow information
record is sent to the collector.
* Discard and export flow with discard notification
In this case the packet is discarded, and the flow information
record is sent to the collector with an indication that the
packet was discarded.
3.3.2 Network Address Translation
Network Address Translation is a method by which IP addresses
are mapped from one address realm to another, providing
transparent routing to end hosts. Transparent routing here
refers to modifying end-node addresses en-route and maintaining
state for these updates so that when a datagram leaves one realm
and enters another, datagrams pertaining to a session are
forwarded to the right end-host in either realm [NAT-TERM].
>From an exporter (middlebox) perspective, a NAT is composed of
two flows, one from the client to the NAT middlebox and another
from the NAT middlebox to the destination. Based on this fact,
the exporter has several modes of operation, i.e., it can export
the private realm flow, the public realm, or both. This is
further constrained by the flavor of NAT implemented, meaning
that in order for the exported information to be useful for the
collector, sometimes the associated flows on the two realms need
to be exported in the same flow record. Although there are many
flavors of address translation that lend themselves to different
applications, this section will only address the IPFIX
architecture implications of traditional NAT, bi-
directional NAT and twice NAT.
3.3.2.1 Traditional NAT
Expires December 2003 [Page 11]
IPFIX Applicability June 2003
Traditional NAT would allow hosts within a private network to
transparently access hosts in the external network, in most
cases. In a traditional NAT, sessions are unidirectional,
outbound from the private network. This is in contrast with bi-
directional NAT, which permits sessions in both inbound and
outbound directions. A detailed description of traditional NAT
may be found in section [NAT-TERM].
If the exporter is providing traditional NAT service and only
the private realm flow is exported, only destination based
information can be inferred from the collector. The reason for
this is twofold. First, the collector will not be able to find
the reverse flow (when applicable) associated with a private
realm flow record, and second is that in the more general
scenario the collector can be connected to several exporters
providing NAT service and there might be overlapping private
realm addresses between the networks connected to these
exporters.
In a traditional NAT scenario the exporter SHOULD export private
and public realm information in the same flow record or provide
the collector with a unique key to associate the two if exported
on different flow records.
3.3.2.2 Bi-Directional NAT
With a bi-directional NAT, sessions can be initiated from hosts
in the public network as well as the private network. Private
network addresses are bound to globally unique addresses,
statically or dynamically as connections are established in
either direction. Detailed description of Bi-Directional may be
found in section [NAT-
TERM].
3.3.2.3 Twice NAT
Twice NAT is a variation of NAT in that both the source and
destination addresses are modified by NAT as a datagram crosses
address realms. This is in contrast to Traditional-NAT and Bi-
Directional NAT, where only one of the addresses (either source
or destination) is translated. Note, there is no such term as
'Once-
NAT'. Detailed description of Bi-Directional may be found in
section [NAT-TERM].
In the case of twice NAT the exporter MUST export private and
public realm information in the same flow record or provide the
collector with a unique key to associate the two if exported on
different flow records.
3.3.3 Traffic Conditioners
A traffic conditioner may contain the following elements: meter,
marker, shaper, and dropper. A traffic stream is selected by a
classifier, which steers the packets to a logical instance of a
traffic conditioner[DIFF-ARCH].
From an IPFIX architecture perspective we are going to address
marking, shaping and dropping services.
Marking
Diffserv packet markers set the DS field of a packet to a
particular codepoint, adding the marked packet to a particular
DS behavior aggregate. The marker may be configured to mark all
packets which are steered to it to a single codepoint, or may be
configured to mark a packet to one of a set of codepoints used
to select a PHB in a PHB group, according to the state of a
Expires December 2003 [Page 12]
IPFIX Applicability June 2003
meter. When the marker changes the codepoint in a packet it is
said to have "re-marked" the packet [DIFF-ARCH].
From and IPFIX architecture perspective, the exporter can take
one of the following actions when it needs to remark a packet.
* Unmarked flow
The exporter can export the flow before it was remarked. This
mode of operation is strongly discouraged.
* Remarked flow
The exporter can export the flow after it was remarked.
* Unmarked and remarked flow.
The exporter can export the flow before and after it was
remarked or export the flow before it was remarked and an
indication of what was the DSCP after it was remarked.
3.3.3.1 Shapers
Shapers delay some or all of the packets in a traffic stream in
Order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-size buffer, and packets
may be discarded if there is not sufficient buffer space to hold
the delayed packets.
For an IPFIX perspective, since the discard of a packet by a
shaper is not voluntary, no indication should be sent to the
collector.
3.3.3.2 Droppers
Droppers discard some or all of the packets in a traffic stream
in order to bring the stream into compliance with a traffic
profile. This process is known as "policing" the stream. Note
that a dropper can be implemented as a special case of a shaper
by setting the shaper buffer size to zero (or a few) packets.
In a manner analogous to the middlebox firewall service,
middlebox policing services also allow the exporter to
explicitly drop packets based on some administrative policy.
The three possible export behaviors described for the firewall
service when a packet needs to be dropped are also applicable to
here, i.e., silent discard, discard and export flow, discard and
export flow with discard notification.
3.3.4 Tunneling
The exporter can export the flows before and/or after they get
tunneled. In the later case the encapsulated flow information
might not be available due to confidentiality precautions such
as those used by IPsec, or due to the fact the exporter lacks
the necessary intelligence to inspect the encapsulated packet.
Moreover, depending on where in the network the exporter is
located, it might only be able to export flows associated with
the tunnel, without visibility into the encapsulated packet.
Apart from what was said above, it should also be factored in
the fact that flows exported before they get tunneled, will
provide information about the private network sites, but not
necessarily about the backbone, since the route taken by the
packet it's now know at that point in time (and vice-versa).
3.3.5 VPNs
Expires December 2003 [Page 13]
IPFIX Applicability June 2003
The term "Virtual Private Network" (VPN) refers to the
communication between a set of sites, making use of a shared
network infrastructure. Multiple sites of a private network
may therefore communicate via the public infrastructure, in
order to facilitate the operation of the private network. The
logical structure of the VPN, such as addressing, topology,
connectivity, reachability, and access control, is equivalent to
part of or all of a conventional private network using private
facilities [RFC2764] [VPN-2547BIS].
There are multiple flavors of VPNs, the one with more relevance
to the IPFIX architecture is the PE-based-VPN. A PE-based VPN
(or Provider Edge-based Virtual Private Network) is one in which
PE devices in the SP network provide the VPN. This allows the
existence of the VPN to be hidden from the CE devices, which can
operate as if part of a normal customer network. A detailed
discussion of VPNs can be found in [PPVPN-FR].
3.3.5.1 Layer 3 PE-based VPN
A layer 3 PE-based VPN is one in which the SP takes part in IP
level forwarding based on the customer network's IP address
space. In general, the customer network is likely to make use
of private and/or non-unique IP addresses. This implies that at
least some devices in the provider network needs to understand
the IP address space as used in the customer network. Typically
this knowledge is limited to the PE device [PPVPN-FR] which is
directly attached to the customer.
In a layer 3 PE-based VPN the provider will need to participate
in some aspects of management and provisioning of the VPNs, such
as ensuring that the PE devices are configured to support the
correct VPNs. This implies that layer 3 PE-based VPNs are by
definition provider provisioned VPNs [PPVPN-FR].
In order to connect the different VPN sites belonging to the
same VPN the SP uses a tunneling technique such as MPLS, L2TP or
IPsec. These tunnels originate and terminate on PE devices.
One of the characteristics of a layer 3 PE-based VPNs is that
they offload some aspects of VPN management from the customer
network. From an IPFIX architecture perspective, this means that
the SP is the one that potentially will be providing the IPFIX
service for the VPNs that it provides connectivity.
The exporter in Layer 3 PE-based VPN can be located on the
customer's network, on the SP's backbone (P Router) or on the
edge (PE router). The premise of this discussion is that the
exporter is the one providing middlebox services, so in the case
of VPNs we assume that the exporter is located in a PE device.
Overlapping Address Realms
In the case the exporter plays the role of a PE router [VPN-
2547BIS] in a provider provisioned VPN scenario and has VPNs
with overlapping private address realms, it can only provide
useful non-conflicting information to the provider for intra-VPN
traffic if it uses a technique that allows the collector to
uniquely identify to which VPN the flow belongs.
Several techniques could be used to accomplish this goal. One of
these techniques is to include the VPN Global unique identifier
[VPN-ID] as one of the keys in the flow record.
In the case the exporter supports VPNs with overlapping private
address realms, it MUST include the VPN-ID [VPN-ID] in the
exported flow record.
Expires December 2003 [Page 14]
IPFIX Applicability June 2003
3.3.5.2 Layer 2 PE-based VPN [TBD]
A layer 2 PE-based VPN is one in which the network is aware of
the VPN, but does only layer 2 forwarding and signaling. This
implies that the SP provisions and maintains layer 2
connectivity between CE devices [VPN-L2].
Forwarding options include MAC addresses (such as LAN
emulation), use of point-to-point link layer connections (FR or
ATM), multipoint-to-point (using MPLS multipoint to point LSPs),
and point-to-multipoint (e.g., ATM VCCs).
For a layer 2 PE-based VPN, the PE device may be a router, LSR,
or IP switch. From the CE's perspective, the PE will be
operating as a switch.
4. Security Consideration
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.
The second section 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.
5. References
[QuZC03] J. Quittek ,et. Al "Requirements for IP Flow
Information Export ", (work in progress) ,Internet Draft,
Internet Engineering Task Force, <draft-ietf-ipfix-reqs-10.txt>,
June 2003
[Wood02] M. Wood ,et al.," Intrusion Detection Message Exchange
Requirements",(work in progress), Internet Draft, Internet
Engineering Task Force, draft-ietf-idwg-requirements-06,
February 2002.
[MaPZ03] L. Mark, G. Pohl, T. Zseby, K. Sugauchi: Passive One-
way Delay Measurements, (work in progress), Internet Draft
<draft-mark-powd-00.txt>, June 2003
[Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of
Internet Traffic Engineering", (work in progress), Internet
Draft, Internet Engineering Task Force, draft-ietf-tewg-
principles-02.txt, May 2002
[Brow00] Nevil Brownlee: Packet Matching for NeTraMet
Distributions,
http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-
adelaide/pp-dist/
[RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation
Metric for IPPM, RFC 3393, November 2002
[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
Loss Metric for IPPM, September 1999
[ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun:
Application of Sampling Methodologies to Network Traffic
Expires December 2003 [Page 15]
IPFIX Applicability June 2003
Characterization, Proceedings of ACM SIGCOMM'93, San Francisco,
CA, USA, September 13 - 17, 1993
[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
[DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory
Sampling for Direct Traffic Observation", Proceedings of ACM
SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
Metric for IPPM, Request for Comments: 2679, September 1999
[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
[MCFW] Srisuresh, S. et al. "Middlebox Communication
Architecture and framework," work in progress. October 2001.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001.
[PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for
Provider Provisioned Virtual Private Networks ", work in
progress, <draft-
ietf-ppvpn-framework-03.txt>, January 2002.
[VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
<draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.
[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
Spence, "Generic AAA Architecture", RFC 2903, August 2000
7. Acknowledgements
We would like to thank the following persons for their
contribution, discussion on the mailing list and valuable
comments:
Robert Loewe
8. 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
Reinaldo Penno
Nortel Networks, Inc. 2305 Mission College Boulevard
Building SC9-B1240 Santa Clara, CA 95134
Email: rpenno@nortelnetworks.com
Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Expires December 2003 [Page 16]
IPFIX Applicability June 2003
Phone : +1 858 534 8338
Email : nevil@caida.org
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
9. Full Copyright Statement
"Copyright (C) The Internet Society (date). 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.
Expires December 2003 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 04:09:41 |