IPFIX Working Group A. Kobayashi
Internet-Draft NTT PF Lab.
Intended status: Informational B. Claise
Expires: January 12, 2011 Cisco Systems, Inc.
G. Muenz
TU Muenchen
K. Ishibashi
NTT PF Lab.
July 11, 2010
IPFIX Mediation: Framework
draft-ietf-ipfix-mediators-framework-07
Abstract
This document describes a framework for IPFIX Mediation. This
framework extends the IPFIX reference model by defining the IPFIX
Mediator components.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 12, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Kobayashi, et al. Expires January 12, 2011 [Page 1]
Internet-Draft IPFIX Mediation Framework July 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. IPFIX/PSAMP Documents Overview . . . . . . . . . . . . . . . . 7
3.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 7
3.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 7
4. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 8
5. IPFIX Mediation Functional Blocks . . . . . . . . . . . . . . 13
5.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 13
5.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 14
5.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 14
5.3.1. Data Record Expiration . . . . . . . . . . . . . . . . 15
5.3.2. Specific Intermediate Processes . . . . . . . . . . . 16
6. Component Combination . . . . . . . . . . . . . . . . . . . . 21
6.1. Data-based Collector Selection . . . . . . . . . . . . . . 21
6.2. Flow Selection and Aggregation . . . . . . . . . . . . . . 22
6.3. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 23
7. Encoding for IPFIX Message Header . . . . . . . . . . . . . . 24
8. Information Model . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Avoiding Security Level Downgrade . . . . . . . . . . . . 27
9.2. Avoiding Security Level Upgrade . . . . . . . . . . . . . 28
9.3. Approximating End-to-End Assertions for IPFIX Mediators . 28
9.4. Multiple Tenancy . . . . . . . . . . . . . . . . . . . . . 29
9.5. Configuration Protection . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Kobayashi, et al. Expires January 12, 2011 [Page 2]
Internet-Draft IPFIX Mediation Framework July 2010
1. Introduction
The IPFIX architectural components in [RFC5470] consist of IPFIX
Devices and IPFIX Collectors communicating using the IPFIX protocol.
Due to the sustained growth of IP traffic in heterogeneous network
environments, this Exporter-Collector architecture may lead to
scalability problems. In addition, it does not provide the
flexibility required by a wide variety of measurement applications.
A detailed descriptions of these problems is given in [IPFIX-MD-PS].
To fulfill application requirements with limited system resources,
IPFIX architecture needs to introduce an intermediate entity between
Exporters and Collectors. From a data manipulation point of view,
this intermediate entity provides the aggregation, correlation,
filtering, and modification of Flow Records and/or PSAMP Packet
Reports to save measurement system resources and to perform
preprocessing tasks for the Collector. From a protocol conversion
point of view, this intermediate entity provides conversion into
IPFIX, or conversion of IPFIX transport protocols (e.g., from UDP to
SCTP) to improve the export reliability.
This document introduces a generalized concept for such intermediate
entities and describes the high-level architecture of IPFIX
Mediation, key IPFIX Mediation architectural components, and
characteristics of IPFIX Mediation.
This document is structured as follows: section 2 describes the
terminology used in this document, section 3 gives an IPFIX/PSAMP
document overview, section 4 describes a high-level reference model,
section 5 describes functional features related to IPFIX Mediation,
section 6 describes combinations of components along with some
application examples, section 7 describes consideration points of the
encoding for IPFIX Message headers, and section 8 describes the
Information Elements used in an IPFIX Mediator.
Kobayashi, et al. Expires January 12, 2011 [Page 3]
Internet-Draft IPFIX Mediation Framework July 2010
2. Terminology and Definitions
The IPFIX-specific and PSAMP-specific terminology used in this
document is defined in [RFC5101] and [RFC5476], respectively. The
IPFIX Mediation-specific terminology used in this document is defined
in [IPFIX-MD-PS]. However, as reading the problem statements
document is not a prerequisite to reading this framework document,
the definitions have been reproduced here along with additional
definitions. In this document, as in [RFC5101] and [RFC5476], the
first letter of each IPFIX-specific and PSAMP-specific term is
capitalized along with the IPFIX Mediation-specific term defined
here. The use of the terms "must", "should", and "may" in this
document are informational only.
In this document, we call "record stream" a stream of records
carrying flow- or packet-based information. The records may be
encoded as IPFIX Data Records or in any other format.
Transport Session Information
The Transport Session is specified in [RFC5101]. In SCTP, the
Transport Session Information is the SCTP association. In TCP and
UDP, the Transport Session Information corresponds to a 5-tuple
{Exporter IP address, Collector IP address, Exporter transport
port, Collector transport port, transport protocol}.
Original Exporter
An Original Exporter is an IPFIX Device that hosts the Observation
Points where the metered IP packets are observed.
IPFIX Mediation
IPFIX Mediation is the manipulation and conversion of a record
stream for subsequent export using the IPFIX protocol.
The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.
Intermediate Process
An Intermediate Process takes a record stream as its input from
Collecting Processes, Metering Processes, IPFIX File Readers,
other Intermediate Processes, or other record sources; performs
some transformations on this stream, based upon the content of
each record, states maintained across multiple records, or other
data sources; and passes the transformed record stream as its
output to Exporting Processes, IPFIX File Writers, or other
Kobayashi, et al. Expires January 12, 2011 [Page 4]
Internet-Draft IPFIX Mediation Framework July 2010
Intermediate Processes, in order to perform IPFIX Mediation.
Typically, an Intermediate Process is hosted by an IPFIX Mediator.
Alternatively, an Intermediate Process may be hosted by an
Original Exporter.
Specific Intermediate Processes are described below. However, this
is not an exhaustive list.
Intermediate Conversion Process
An Intermediate Conversion Process is an Intermediate Process that
transforms non IPFIX into IPFIX, or manages the relation among
Templates and states of incoming/outgoing transport sessions in
the case of transport protocol conversion (e.g., from UDP to
SCTP).
Intermediate Aggregation Process
An Intermediate Aggregation Process is an Intermediate Process
that aggregates records based upon a set of Flow Keys or functions
applied to fields from the record (e.g., binning and subnet
aggregation).
Intermediate Correlation Process
An Intermediate Correlation Process is an Intermediate Process
that adds information to records, noting correlations among them,
or generates new records with correlated data from multiple
records (e.g., the production of bidirectional flow records from
unidirectional flow records).
Intermediate Selection Process
An Intermediate Selection Process is an Intermediate Process that
selects records from a sequence based upon criteria-evaluated
record values and passes only those records that match the
criteria (e.g., filtering only records from a given network to a
given Collector).
Intermediate Anonymization Process
An Intermediate Anonymization Process is an Intermediate Process
that transforms records in order to anonymize them, to protect the
identity of the entities described by the records (e.g., by
applying prefix-preserving pseudonymization of IP addresses).
Kobayashi, et al. Expires January 12, 2011 [Page 5]
Internet-Draft IPFIX Mediation Framework July 2010
IPFIX Mediator
An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation
by receiving a record stream from some data sources, hosting one
or more Intermediate Processes to transform that stream, and
exporting the transformed record stream into IPFIX Messages via an
Exporting Process. In the common case, an IPFIX Mediator receives
a record stream from a Collecting Process, but it could also
receive a record stream from data sources not encoded using IPFIX,
e.g., in the case of conversion from the NetFlow V9 protocol
[RFC3954] to IPFIX protocol.
Note that the IPFIX Mediator is a generalization of the concentrator
and proxy elements envisioned in the IPFIX requirements [RFC3917].
IPFIX Mediators running appropriate Intermediate Processes provide
the functionality specified therein.
Kobayashi, et al. Expires January 12, 2011 [Page 6]
Internet-Draft IPFIX Mediation Framework July 2010
3. IPFIX/PSAMP Documents Overview
IPFIX Mediation can be applied to flow- or packet-based information.
The flow-based information is encoded by IPFIX protocol, and the
packet-based information is extracted by some sampling techniques and
then encoded by PSAMP protocol. Thus, this section describes
relevant documents for both protocols.
3.1. IPFIX Documents Overview
The IPFIX protocol [RFC5101] provides network administrators with
access to IP flow information. The architecture for the export of
measured IP flow information from an IPFIX Exporting Process to a
Collecting Process is defined in [RFC5470], per the requirements
defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how
IPFIX Data Records and Templates are carried via a number of
transport protocols from IPFIX Exporting Processes to IPFIX
Collecting Processes. IPFIX has a formal description of IPFIX
Information Elements, their names, types, and additional semantic
information, as specified in [RFC5102]. The IPFIX Management
Information Base is defined in [RFC5815]. Finally, [RFC5472]
describes what types of applications can use the IPFIX protocol and
how they can use the information provided. It furthermore shows how
the IPFIX framework relates to other architectures and frameworks.
The storage of IPFIX Messages in a file is specified in [RFC5655].
3.2. PSAMP Documents Overview
The framework for packet selection and reporting [RFC5474] enables
network elements to select subsets of packets by statistical and
other methods and to export a stream of reports on the selected
packets to a Collector. The set of packet selection techniques
(sampling and filtering) standardized by PSAMP is described in
[RFC5475]. The PSAMP protocol [RFC5476] specifies the export of
packet information from a PSAMP Exporting Process to a Collector.
Like IPFIX, PSAMP has a formal description of its Information
Elements, their names, types, and additional semantic information.
The PSAMP information model is defined in [RFC5477]. The PSAMP
Management Information Base is described in [PSAMP-MIB].
Kobayashi, et al. Expires January 12, 2011 [Page 7]
Internet-Draft IPFIX Mediation Framework July 2010
4. IPFIX Mediation Reference Model
Figure A shows the high-level IPFIX Mediation reference model as an
extension of the IPFIX reference model presented in [RFC5470]. This
figure covers the various possible scenarios that can exist in an
IPFIX measurement system.
+----------------+ +---------------+ +---------------+
| Collector 1 | | Collector 2 | | Collector N |
|[Collecting | |[Collecting | |[Collecting |
| Process(es)] | | Process(es)] |... | Process(es)] |
+----^-----------+ +---^--------^--+ +--------^------+
| / \ |
| / \ |
Flow Records Flow Records Flow Records Flow Records
| / \ |
+------+-------------+------+ +------+-----------+--------+
|IPFIX Mediator 3 | |IPFIX Mediator N |
|[Exporting Process(es)] | |[Exporting Process(es)] |
|[Intermediate Process(es)] | |[Intermediate Process(es)] |
|[Collecting Process(es)] |... |[Collecting Process(es)] |
+----^----------------^-----+ +------^----------------^---+
| | | |
Flow Records Flow Records Packet Reports record stream
| | | |
+------+------+ +------+-------+ +------+-------+ +-----+-----+
|IPFIX | |IPFIX Original| |PSAMP Original| |Other |
| Mediator 1 | | Exporter 1 | | Exporter 1 | | Source 1 |
|+-------------+ |+--------------+ |+--------------+ |+-----------+
+|IPFIX | +|IPFIX Original| +|PSAMP Original| +|Other |
| Mediator 2 | | Exporter N | | Exporter N | | Source N |
|[Exporting | |[Exporting | |[Exporting | | |
| Process(es)]| | Process(es)]| | Process(es)]| | |
|[Intermediate| |[Metering | |[Metering | | |
| Process(es)]| | Process(es)]| | Process(es)]| | |
|[Collecting | |[Observation | |[Observation | | |
| Process(es)]| | Point(s)]| | Point(s)]| | |
+------^------+ +-----^-^------+ +-----^-^------+ +-----------+
| | | | |
Flow Records Packets coming Packets coming
into Observation into Observation
Points Points
Figure A: IPFIX Mediation Reference Model Overview.
The functional components within each entity are indicated within
brackets []. An IPFIX Mediator receives IPFIX Flow Records or PSAMP
Kobayashi, et al. Expires January 12, 2011 [Page 8]
Internet-Draft IPFIX Mediation Framework July 2010
Packet Records from other IPFIX Mediators, IPFIX Flow Records from
IPFIX Original Exporters, PSAMP Packet Reports from PSAMP Original
Exporters, and/or a record stream from other sources. The IPFIX
Mediator then exports IPFIX Flow Records and/or PSAMP Packet Reports
to one or multiple Collectors and/or other IPFIX Mediators.
Figure B shows the basic IPFIX Mediator component model. An IPFIX
Mediator contains one or more Intermediate Processes and one or more
Exporting Processes. In typical case, it contains a Collecting
Process, as described in Figure B below.
IPFIX (Data Records)
^
^ |
+------------------------|-|---------------------+
| IPFIX Mediator | | |
| | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Exporting Process(es) |' |
| '----------------------^--------------------' |
| | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Intermediate Process(es) |' |
| '----------------------^--------------------' |
| | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Collecting Process(es) |' |
| '----------------------^--------------------' |
+------------------------|-|---------------------+
|
IPFIX (Data Records)
Figure B: Basic IPFIX Mediator Component Model.
Kobayashi, et al. Expires January 12, 2011 [Page 9]
Internet-Draft IPFIX Mediation Framework July 2010
However, other data sources are also possible: an IPFIX Mediator can
receive a record stream from non-IPFIX protocols such as NetFlow
[RFC3954] exporter(s). This document does not make any particular
assumption on how a record stream is transferred to an IPFIX
Mediator. Figure C below shows the IPFIX Mediator component model in
the case of IPFIX protocol conversion from non-IPFIX exporters, so
receiving a record stream.
IPFIX (Data Records)
^
^ |
+------------------------|-|---------------------+
| IPFIX Mediator | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Exporting Process(es) |' |
| '----------------------^--------------------' |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Intermediate Process(es) |' |
| '----------------------^--------------------' |
+------------------------|-----------------------+
| record stream
+------------------------|-----------------------+
| Non-IPFIX exporter | |
| +-------------+----------+ |
| | | |
+----------|------------------------|------------+
| |
Packets coming into observation points
Figure C: IPFIX Mediator Component Model in IPFIX Protocol
Conversion.
Kobayashi, et al. Expires January 12, 2011 [Page 10]
Internet-Draft IPFIX Mediation Framework July 2010
Alternatively, an Original Exporter may provide IPFIX Mediation by
hosting one or more Intermediate Processes. The component model in
Figure D adds Intermediate Process(es) to the IPFIX Device model
illustrated in [RFC5470]. In comparison with Figure 1 or 2 in
[RFC5470], the Intermediate Process is located between IPFIX Metering
Process(es), or PSAMP Metering Process(es) and Exporting Process(es).
IPFIX (Data Records)
^ ^
+---------------------------|-|------------------------+
| Original Exporter | | |
| | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Exporting Process(es) |' |
| '----------------------^--------------------' |
| | | |
| .---------------------|-+-------------------. |
| .----------------------+--------------------.| |
| | Intermediate Process(es) |' |
| '---------^-----------------------^---------' |
| | Data Records | |
| .----------+---------. .---------+----------. |
| | Metering Process 1 |...| Metering Process N | |
| '----------^---------' '---------^----------' |
| | | |
| .-----------+---------. .---------+-----------. |
| | Observation Point 1 |...| Observation Point N | |
| '-----------^---------' '---------^-----------' |
+--------------|-----------------------|---------------+
| |
Packets coming into Observation Points
Figure D: IPFIX Mediation Component Model at Original Exporter.
Kobayashi, et al. Expires January 12, 2011 [Page 11]
Internet-Draft IPFIX Mediation Framework July 2010
In addition, an Intermediate Process may be collocated with an IPFIX
File Reader and/or Writer. Figure E shows an IPFIX Mediation
component model with an IPFIX File Writer and/or Reader.
IPFIX (Data Records)
^
^ |
.----------------------|-+--------------------.
.-----------------------+---------------------.|
| IPFIX File Writer |'
'-----------------------^---------------------'
| |
.----------------------|-+--------------------.
.-----------------------+---------------------.|
| Intermediate Process(es) |'
'-----------------------^---------------------'
| |
.----------------------|-+--------------------.
.-----------------------+---------------------.|
| IPFIX File Reader |'
'-----------------------^---------------------'
|
IPFIX (Data Records)
Figure E: IPFIX Mediation Component Model collocated with IPFIX File
Writer/Reader.
Kobayashi, et al. Expires January 12, 2011 [Page 12]
Internet-Draft IPFIX Mediation Framework July 2010
5. IPFIX Mediation Functional Blocks
Figure F shows a functional block diagram example in an IPFIX
Mediator, having different Intermediate Process types.
IPFIX IPFIX IPFIX
^ ^ ^
| | |
.------------. .-----+-------. .-----+-------. .------+------.
| IPFIX File | | Exporting | | Exporting | | Exporting |
| Writer | | Process 1 | | Process 2 |....| Process N |
'-----^-^----' '-----^-------' '-----^-------' '------^------'
| | | | |
| +-------------+ | |
: Flow Records / Packet Reports :
.------+-------. .-----+--------. .----+---------. .--------------.
| Intermediate | | Intermediate | | Intermediate | | Intermediate |
| Anonymization| | Correlation | | Aggregation | | Selection |
| Process N | | Process N | | Process N | | Process N |
'------|-------' '------|-------' '-----|-|------' '-------|------'
| +---------------+ | |
: : : :
.------+-------. .------+-------. .-------+------. .-------+------.
| Intermediate | | Intermediate | | Intermediate | | Intermediate |
| Selection | | Selection | | Selection | | Selection |
| Process 1 | | Process 2 | | Process 3 | | Process 4 |
'------|-|-----' '------|-------' '-----|--------' '-------|------'
| +--------------+ | +----------------+
| | | | |
: Flow Records / Packet Reports :
.------+------. .-------+-----. .-----+-+-----. .-----+------.
| Collecting | | Collecting | | Collecting | | IPFIX File |
| Process 1 | | Process 2 |...| Process N | | Reader |
'------^------' '------^------' '------^------' '------------'
| | |
Flow Records Flow Records Flow Records
Figure F: IPFIX Mediation Functional Block.
5.1. Collecting Process
A Collecting Process in an IPFIX Mediator is not different from the
Collecting Process described in [RFC5101]. Additional functions in
an IPFIX Mediator include transmitting the set of Data Records and
Control Information to one or more components, i.e., Intermediate
Processes and other applications. In other words, a Collecting
Process may duplicate the set and transmit it to one or more
components in sequence or in parallel. In the case of an IPFIX
Kobayashi, et al. Expires January 12, 2011 [Page 13]
Internet-Draft IPFIX Mediation Framework July 2010
Mediator, the Control Information described in [RFC5470] includes
IPFIX Message header information and Transport Session Information
along with information about the Metering Process and the Exporting
Process in an Original Exporter, e.g., sampling parameters.
5.2. Exporting Process
An Exporting Process in an IPFIX Mediator is not different from the
Exporting Process described in [RFC5101]. Additional functions in an
IPFIX Mediator may include the following.
o Receiving the trigger to transmit the Template Withdrawal Messages
from Intermediate Process(es) when relevant Templates become
invalid due to, for example, incoming session failure.
o Transmitting the origin (e.g., Observation Point, Observation
Domain ID, Original Exporter IP address, etc.) of the data in
additional Data Record fields or additional Data Records. This
function must be configurable.
5.3. Intermediate Process
An Intermediate Process is a key functional block for IPFIX
Mediation. Its typical functions include the following:
o Generating a new record stream from an input record stream
including context information (e.g., "Export Time", "Observation
Domain ID", and Transport Session Information), and transmitting
it to other components.
o Reporting statistics and interpretations for IPFIX Metering
Processes, PSAMP Metering Processes, and Exporting Processes from
an Original Exporter. See section 4 of [RFC5101] and section 6 of
[RFC5476] for relevant statistics data structures and
interpretations, respectively. This function must be
configurable.
o Maintaining the configurable relation between Collecting
Process(es)/Metering Process(es) and Exporting Process(es)/other
Intermediate Process(es).
A Collecting Process or Metering Process participating in IPFIX
Mediation is associated with at least one Intermediate Process.
Furthermore, an Intermediate Process is associated with at least
one Exporting Process or another Intermediate Process. This
relation can be configurable.
Kobayashi, et al. Expires January 12, 2011 [Page 14]
Internet-Draft IPFIX Mediation Framework July 2010
o Maintaining database(s) of all the Data Records in the case of an
Intermediate Aggregation Process and an Intermediate Correlation
Process. The function has the Data Record expiration rules
described in the next subsection.
o Maintaining statistics on the Intermediate Process itself, such as
the number of input/output Data Records, etc.
o Maintaining additional information about output record streams,
which includes information related to Original Exporter,
Observation Domain, and administrative domain and some
configuration parameters related to each function.
In the case of an Intermediate Aggregation Process, Intermediate
Anonymization Process, and Intermediate Correlation Process, the
value of the "flowKeyIndicator" needs to be modified when
modifying the data structure defined by an original Template.
5.3.1. Data Record Expiration
An Intermediate Aggregation Process and Intermediate Correlation
Process need to have expiration conditions to export cached Data
Records. In the case of the Metering Process in an Original
Exporter, these conditions are described in [RFC5470]. In the case
of the Intermediate Process, these conditions are as follows:
o If there are no input Data Records belonging to a cached Flow for
a certain time period, aggregated Flow Records will expire. This
time period should be configurable at the Intermediate Process.
o If the Intermediate Process experiences resource constraints,
aggregated Flow Records may prematurely expire (e.g., lack of
memory to store Flow Records).
o For long-running Flows, the Intermediate Process should cause the
Flow to expire on a regular basis or on the basis of an expiration
policy. This periodicity or expiration policy should be
configurable at the Intermediate Process.
In the case of an Intermediate Correlation Process, a cached Data
Record may be prematurely expired (and discarded) when no correlation
can be computed with newly received Data Records. For example, an
Intermediate Correlation Process computing one way delay may discard
the cached Packet Report when no other matching packet Report are
observed within a certain time period.
Kobayashi, et al. Expires January 12, 2011 [Page 15]
Internet-Draft IPFIX Mediation Framework July 2010
5.3.2. Specific Intermediate Processes
This section describes the functional blocks of specific Intermediate
Processes.
5.3.2.1. Intermediate Conversion Process
When receiving a non-IPFIX record stream, the Intermediate Conversion
Process covers the following functions:
o Determining the IPFIX Information Element identifiers which
correspond to the fields of the non-IPFIX records (e.g.,
converting NetFlow V9 protocol [RFC3954] to IPFIX Information
Model [RFC5102]).
o Transforming the non-IPFIX records into Data Records, (Options)
Template Records, and/or Data Records defined by Options
Templates.
o Converting additional information (e.g., sampling rate, sampling
algorithm, and observation information) into appropriate fields in
the existing Data Records or into Data Records defined by new
Option Templates.
IPFIX transport protocol conversion can be used to enhance the export
reliability, for example for data retention and accounting. In this
case, the Intermediate Conversion Process covers the following
functions:
o Relaying Data Records, (Options) Template Records, and Data
Records defined by Options Templates.
o Setting the trigger for the Exporting Process in order to export
IPFIX Template Withdrawal Messages relevant to the Templates when
Templates becomes invalid due to, for example, incoming session
failure. This case applies to SCTP and TCP Transport Sessions on
the outgoing side, only.
o Maintaining the mapping information about Transport Sessions,
Observation Domain IDs, and Template IDs on the incoming and
outgoing sides to ensure the appropriateness of the scope field
values in Data Records defined by Options Templates and of IPFIX
Template Withdrawal Messages.
Kobayashi, et al. Expires January 12, 2011 [Page 16]
Internet-Draft IPFIX Mediation Framework July 2010
5.3.2.2. Intermediate Selection Process
An Intermediate Selection Process has analogous functions to the
PSAMP Selection Process described in [RFC5475]. The difference is
that the Intermediate Selection Process takes a record stream, e.g.,
Flow Records or Packet Reports, instead of observed packets.
The typical function is property match filtering that retrieves a
record stream of interest. The function selects a Data Record if the
value of a specific field in the Data Record equals a configured
value or falls within a configured range.
5.3.2.3. Intermediate Aggregation Process
An Intermediate Aggregation Process covers the following functions:
o Merging a set of Data Records within a certain time period into
one Flow Record by summing up the counters where appropriate.
o Maintaining statistic and additional information about aggregated
Flow Records.
The statistics for an aggregated Flow Record may include the
number of original Data Records and the maximum and minimum values
of per-flow counters. Additional information may include an
aggregation time period, a new set of Flow Keys, and observation
location information involved in the Flow aggregation.
Observation location information can be tuples of (Observation
Point, Observation Domain ID, Original Exporter IP address) or
another identifier indicating the location where the measured
traffic has been observed.
o Aggregation of Data Records, which can be done in the following
ways:
* Spatial composition
With spatial composition, Data Records sharing common
properties are merged into one Flow Record within a certain
time period. One typical aggregation can be based on a new set
of Flow Keys. Generally, a smaller set of common properties
than an original set of Flow Keys results in a higher level of
aggregation. Another aggregation can be based on a set of
Observation Points within an Observation Domain, on a set of
Observation Domains within an Exporter, or on a set of
Exporters.
Kobayashi, et al. Expires January 12, 2011 [Page 17]
Internet-Draft IPFIX Mediation Framework July 2010
If some fields do not serve as Flow Keys or per-Flow counters,
and their values may change from Data Records to Data Records
within an aggregated Flow Record, the Intermediate Aggregation
Process determines their values by the first Data Record
received, a specific Exporter IP address, or other appropriate
decisions.
Furthermore, a new identifier indicating a group of observation
locations can be introduced, for example, to indicate PoP
(Points of Presence) in a large network, or a logical interface
composed of physical interfaces with link aggregation.
* Temporal composition
With temporal composition, multiple consecutive Flow Records
with identical Flow Key values are merged into a single Flow
Record of longer Flow duration if they arrive within a certain
time interval. The main difference to spatial composition is
that Flow Records are only merged if they originate from the
same Observation Point and if the Flow Key values are
identical. For example, multiple Flow Records with a Flow
duration of less than one minute can be merged into a single
Flow Record with more than ten minutes Flow duration.
In addition, the Intermediate Aggregation Process with temporal
composition produces aggregated counters while reducing the
number of Flow Records on a Collector. Some specific non Flow
Key fields, such as the minimumIpTotalLength/
maximumIpTotalLength or minimumTTL/maximumTTL, will contain the
minimum and maximum for the new aggregated Flow.
The Intermediate Aggregation Process can be combined with the
Intermediate Selection Process in order to aggregate only a subset
of the original Flow Records, for example Flow Records with small
numbers of packets as describied in section 6.2.
5.3.2.4. Intermediate Anonymization Process
An Intermediate Anonymization Process covers the following typical
functions.
o Deleting specified fields
The function deletes existing fields in accordance with some
instruction rules. Examples include hiding network topology
information and private information. In the case of feeding Data
Records to end customers, disclosing vulnerabilities is avoided by
deleting fields, e.g., "ipNextHopIP{v4|v6}Address",
Kobayashi, et al. Expires January 12, 2011 [Page 18]
Internet-Draft IPFIX Mediation Framework July 2010
"bgpNextHopIP{v4|v6}Address", "bgp{Next|Prev}AdjacentAsNumber",
and "mplsLabelStackSection", described in [RFC5102].
o Anonymizing values of specified fields
The function modifies the values of specified fields. Examples
include anonymizing customers' private information, such as IP
address and port number, in accordance with a privacy protection
policy. The Intermediate Anonymization Process may also report
anonymized fields and the anonymization method as additional
information.
5.3.2.5. Intermediate Correlation Process
An Intermediate Correlation Process can be viewed as a special case
of the Intermediate Aggregation Process, covering the following
typical functions:
o Producing new information including metrics, counters, attributes,
or packet property parameters by evaluating the correlation among
sets of Data Records or among Data Records and other meta data
after gathering sets of Data Records within a certain time period.
o Adding new fields into a Data Record or creating a new Data
Record.
A correlation of Data Records can be done in the following ways.
o One-to-one correlation between Data Records, with the following
examples:
* One-way delay, Packet delay variation in [RFC5481]
The metrics come from the correlation of the timestamp value on
a pair of Packet Reports indicating an identical packet from
different Exporters.
* Packet inter-arrival time or jitter
The metrics come from the correlation of the timestamp value on
consecutive Packet Reports from a single Exporter.
* Rate-limiting ratio, compression ratio, optimization ratio,
etc.
The data values come from the correlation of Data Records
indicating an identical Flow observed on the incoming/outgoing
points of a WAN interface.
Kobayashi, et al. Expires January 12, 2011 [Page 19]
Internet-Draft IPFIX Mediation Framework July 2010
o Correlation amongst Data Records, with the following examples:
* Bidirectional Flow composition
The method of exporting and representing a bidirectional flow
(Biflow) is described in [RFC5103]. The bidirectional flow
composition is a special case of Flow Key aggregation. The
Flow Records are merged into one Flow Record as Biflow, if Non-
directional Key Fields matches and the Directional Key Field
matches their reverse direction counterparts. The direction
assignment method to assign the Biflow Source and Destination
as additional information may be reported. In the case of an
Intermediate Aggregation Process, the direction may be assigned
as "arbitrary".
* Average/maximum/minimum for packets, bytes, one-way delay,
packet loss, etc.
The data values come from the correlation of multiple Data
Records while the Intermediate Aggregation Process executes.
o Correlation between Data Record and other meta data
Typical examples are derived packet property parameters described
in [RFC5102]. The parameters are retrieved based on the value of
the specified field in an input Data Record, compensating for
traditional exporting devices or probes that are unable to add
packet property parameters. Typical derived packet property
parameters are as follows:
* "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102], which
indicates the egress router of a network domain. It is useful
for making a traffic matrix that covers the whole network
domain.
* BGP Communities attribute
This attribute indicates tagging for routes of geographical and
topological information and source types (e.g., transit, peer,
or customer) as described in [RFC4384]. Therefore, network
administrators can monitor the geographically-based or source
type-based traffic volume by correlating the attribute.
* "mplsVpnRouteDistinguisher" described in [RFC5102]
This value indicates the VPN customer's identification, which
cannot be extracted from the core router in MPLS networks.
Therefore, network administrators can monitor the customer-
based traffic volume on even core routers.
Kobayashi, et al. Expires January 12, 2011 [Page 20]
Internet-Draft IPFIX Mediation Framework July 2010
6. Component Combination
An IPFIX Mediator may be able to simultaneously support more than one
Intermediate Process. Multiple Intermediate Processes generally are
configured in the following ways.
o Parallel Intermediate Processes
A record stream is processed by multiple Intermediate Processes in
parallel to fulfill the requirements of different applications.
In this setup, every Intermediate Process receives a copy of the
entire record stream as its input.
o Serial Intermediate Processes
To execute flexible manipulation of a record stream, the
Intermediate Processes are connected serially. In that case, an
output record stream from one Intermediate Process forms an input
record stream for a succeeding Intermediate Process.
In addition to the combination of Intermediate Processes, the
combination of some components (Exporting Process, Collecting
Process, IPFIX File Writer and Reader) can be applied to provide
various data reduction techniques. This section shows some
combinations along with examples.
6.1. Data-based Collector Selection
The combination of one or more Intermediate Selection Processes and
Exporting Processes can determine to which Collector input Data
Records are exported. Applicable examples include exporting Data
Records to a dedicated Collector on the basis of a customer or an
organization. For example, an Intermediate Selection Process selects
Data Records from record stream duplicated in a Collecting Process on
the basis of the peering autonomous system number, and an Exporting
Process sends them to a dedicated Collector, as shown in the Figure
G.
Kobayashi, et al. Expires January 12, 2011 [Page 21]
Internet-Draft IPFIX Mediation Framework July 2010
.----------------------. .------------.
| Intermediate | | Exporting |
| Selection Process 1 | | Process 1 |
+--+--- Peering AS #10 ---+-->| +--> Collector 1
| '----------------------' '------------'
| .----------------------. .------------.
record | | Intermediate | | Exporting |
stream | | Selection Process 2 | | Process 2 |
-------+--+--- Peering AS #20 ---+-->| +--> Collector 2
| '----------------------' '------------'
| .----------------------. .------------.
| | Intermediate | | Exporting |
| | Selection Process 3 | | Process 3 |
+--+--- Peering AS #30 ---+-->| +--> Collector 3
'----------------------' '------------'
Figure G: Data-based Collector Selection.
6.2. Flow Selection and Aggregation
The combination of one or more Intermediate Selection Processes and
Intermediate Aggregation Processes can efficiently reduce the amount
of Flow Records. The combination structure is similar to the concept
of the Composite Selector described in [RFC5474]. For example, an
Intermediate Selection Process selects Flows consisting of a small
number of packets and then transmits them to an Intermediate
Aggregation Process. Another Intermediate Selection Process selects
other Flow Records and then transmits them to an Exporting Process,
as shown in Figure H. This results in aggregation on the basis of the
distribution of the number of packets per Flow.
.------------------. .--------------. .------------.
| Intermediate | | Intermediate | | Exporting |
| Selection | | Aggregation | | Process |
| Process 1 | | Process | | |
+-+ packetDeltaCount +->| +->| |
| | <= 5 | | | | |
record | '------------------' '--------------' | |
stream | .------------------. | |
-------+ | Intermediate | | |
| | Selection | | |
| | Process 2 | | |
+-+ packetDeltaCount +------------------->| |
| > 5 | | |
'------------------' '------------'
Figure H: Flow Selection and Aggregation Example.
Kobayashi, et al. Expires January 12, 2011 [Page 22]
Internet-Draft IPFIX Mediation Framework July 2010
6.3. IPFIX File Writer/Reader
An IPFIX File Writer [RFC5655] stores Data Records in a file system.
When Data Records include problematic Information Elements, an
Intermediate Anonymization Process can delete these fields before the
IPFIX File Writer handles them, as shown in Figure I.
.---------------. .---------------. .-------------.
| Collecting | | Intermediate | | IPFIX |
IPFIX | Process | | Anonymization | | File |
----->| +->| Process +->| Writer |
'---------------' '---------------' '-------------'
Figure I: IPFIX Mediation Example with IPFIX File Writer.
In contrast, an IPFIX File Reader [RFC5655] retrieves stored Data
Records when administrators want to retrieve past Data Records from a
given time period. If the data structure of the Data Records from
the IPFIX File Reader is different from what administrators want, an
Intermediate Anonymization Process and Intermediate Correlation
Process can modify the data structure, as shown in Figure J.
.-------------. .---------------. .---------------. .-----------.
| IPFIX | | Intermediate | | Intermediate | | Exporting |
| File | | Anonymization | | Correlation | | Process |
| Reader +->| Process +->| Process +->| |
'-------------' '---------------' '---------------' '-----------'
Figure J: IPFIX Mediation Example with IPFIX File Reader.
In the case where distributed IPFIX Mediators enable on-demand export
of Data Records which have been previously stored by a File Writer, a
collecting infrastructure with huge storage capacity for data
retention can be set up.
Kobayashi, et al. Expires January 12, 2011 [Page 23]
Internet-Draft IPFIX Mediation Framework July 2010
7. Encoding for IPFIX Message Header
The IPFIX Message Header [RFC5101] includes Export Time, Sequence
Number, and Observation Domain ID fields. This section describes
some consideration points for the IPFIX Message header encoding in
the context of IPFIX Mediation.
Export Time
An IPFIX Mediator can set the Export Time in two ways.
* Case 1: keeping the field value of incoming Transport Sessions
* Case 2: setting the time at which an IPFIX Message leaves the
IPFIX Mediator
Case 1 can be applied to the case where an IPFIX Mediator operates
IPFIX Message level rather than Data Records as a proxy. In case
2, the IPFIX Mediator needs to handle any delta time stamp fields,
such as "flowStartDeltaMicroseconds" and
"flowEndDeltaMicroseconds", described in [RFC5102].
Sequence Number
In the case where an IPFIX Mediator relays a one-to-one Transport
Session and operates only IPFIX Message level, the IPFIX Mediator
needs to handle the Sequence Number properly. In particular, the
Sequence Number in outgoing session is not allowed to be
initialized, even when the incoming session shuts down and re-
starts.
Observation Domain ID
According to [RFC5101], the Observation Domain ID in the IPFIX
Message header from an IPFIX Mediator is locally unique per
Exporting Process. However, the Observation Domain ID from an
IPFIX Mediator does not represent the largest set of Observation
Points in an Original Exporter, even if the Observation Domain ID
is kept.
Apart from Observation Domain ID in IPFIX Message header, the
IPFIX Mediator should have a function to export the observation
location information regarding the Original Exporter. The
information contains its IP address, Observation Domain ID from
Original Exporter, and some information about the Transport
Session, for example, the source port number, so that different
Exporting Processes on the same Original Exporter might be
identified. As far as privacy policy permits, an IPFIX Medaitor
Kobayashi, et al. Expires January 12, 2011 [Page 24]
Internet-Draft IPFIX Mediation Framework July 2010
reports the information to an IPFIX Collector.
In the case where an IPFIX Medaitor does not report the
information, for example, an IPFIX Mediator relays an incoming
Observation Domain ID or relays an IPFIX Message after replacing
each incoming Observation Domain ID with a new value, an IPFIX
Mediator should set the appropriate scope fields in Data Records
defined in Options Template Records.
In the case where an IPFIX Medaitor reports the information, the
information can be composed of multiple values of (original
Exporter IP address, Observation Observation ID, and source port
number) with commonPropertiesID [RFC5473]. An IPFIX Mediator puts
into commonPropertiesID value into relevant Data Record, and uses
commonPropertiesID value as scope, and should manage
commonPropertiesID value, for example, should export a Common
Properties Withdrawal message when an incoming Transport Session
failure happens.
Kobayashi, et al. Expires January 12, 2011 [Page 25]
Internet-Draft IPFIX Mediation Framework July 2010
8. Information Model
IPFIX Mediation reuses the general information models from [RFC5102]
and [RFC5477]. However, several Intermediate Processes would
potentially require additional Information Elements as follows:
o Original Exporter IP address, Observation Domain ID, and source
port number about the Transport Session at Original Exporter, in
the case where an IPFIX Mediator reports original observation
location information in section 7. The Information Elements
contained in Export Session Details Options Template in [RFC5655]
may be utilized.
o Report on the applied treatment items in IPFIX Mediation as
described in section 6.7. in [IPFIX-MD-PS].
o Certificate of an Original Exporter in section 9. Relevant
Information Element exporterCertificate in [RFC5655] may be
utilized.
Kobayashi, et al. Expires January 12, 2011 [Page 26]
Internet-Draft IPFIX Mediation Framework July 2010
9. Security Considerations
As they act as both IPFIX Collecting Processes and Exporting
Processes, the Security Considerations for IPFIX [RFC5101] apply as
well to Mediators. The Security Considerations for IPFIX Files
[RFC5655] apply as well to IPFIX Mediators that write IPFIX Files or
use them for internal storage. However, there are a few specific
considerations that IPFIX Mediator implementations must take into
account in addition.
By design, IPFIX Mediators are "men-in-the-middle": they intercede in
the communication between an Original Exporter (or another upstream
Mediator) and a downstream Collecting Process. TLS provides no way
to connect the session between the Mediator and the Original Exporter
to the session between the Mediator and the downstream Collecting
Process; indeed, this is by design. This has important implications
for the level of confidentiality provided across an IPFIX Mediator,
and the ability to protect data integrity and Original Exporter
authenticity across a Mediator. In general, a Mediator SHOULD
maintain the same level of integrity and confidentiality protection
on both sides of the mediation operation, except in situations where
the Mediator is explicitly deployed as a gateway between trusted and
untrusted networks.
Subsequent subsections deal with specific security issues raised by
mediation.
9.1. Avoiding Security Level Downgrade
An IPFIX Mediator that accepts IPFIX Messages over a Transport
Session protected by TLS [RFC4346] or DTLS [RFC4347], and which then
exports IPFIX Messages derived therefrom in cleartext, is a
potentially serious vulnerability in an IPFIX infrastructure.
An IPFIX Mediator may export records derived from protected records
in cleartext, but only in the case that it acts as a proxy between an
external (untrusted) network and an internal (trusted) network, when
the path to the downstream collector is on a physically protected,
separated network (e.g., in the same locked equipment rack) such that
the additional overhead of a TLS session is unnecessary.
In other words, an IPFIX Mediator that receives IPFIX Messages from
an upstream Exporting Process protected using TLS or DTLS must
provide for sending of IPFIX Messages resulting from the operation of
the Intermediate Process(es) to a downstream Collecting Process using
TLS or DTLS. It may allow for the configuration of unprotected
export of such IPFIX Messages, but in this case it must warn the
administrator that the exported IPFIX Messages will not be protected,
Kobayashi, et al. Expires January 12, 2011 [Page 27]
Internet-Draft IPFIX Mediation Framework July 2010
and that this could result in the leakage of information deemed by
the Original Exporter to be worth protecting.
9.2. Avoiding Security Level Upgrade
There is a similar problem in the opposite direction: as an IPFIX
Mediator's signature on a TLS session to a downstream Collecting
Process acts as an implicit assertion of the trustworthiness of the
data within the session, a poorly deployed IPFIX Mediator could be
used to "legitimize" records derived from untrusted sources.
Unprotected sessions from the Original Exporter are in the general
case untrusted, because they could have been tampered with or forged
by an unauthorized third party.
An IPFIX Mediator may export signed IPFIX Messgaes containing records
derived from records received in cleartext, but only in the case that
it acts as a proxy between an internal (trusted) and an external
(untrusted) network, when the path from the Original Exporter is on a
physically protected, separated network, such that the additional
overhead of an TLS session is unnecessary.
In other words, an IPFIX Mediator that receives IPFIX Messages from
an upstream Exporting Process in cleartext must default to sending
IPFIX Messages resulting from the operation of the Intermediate
Process(es) to the downstream Collecting Process in cleartext. It
should allow for the configuration of export of such IPFIX Messages
protected by TLS or DTLS, but in this case it MUST warn the
administrator that the exported IPFIX Messages will be signed as
trusted by the Mediator, and that this could result in downstream
Collecting Process trusting data derived from unprotected sources.
9.3. Approximating End-to-End Assertions for IPFIX Mediators
Because the Transport Session between an IPFIX Mediator and an
Original Exporter is independent from the Transport Session between
the Mediator and the downstream Collecting Process, there exists no
method via TLS to assert the identity of the original Exporting
Process downstream. However, an IPFIX Mediator, which modifies the
stream of IPFIX Messages sent to it, is by definition a trusted
entity in the infrastructure. Therefore, the IPFIX Mediator's
signature on an outgoing Transport Session can be treated as an
implicit assertion that the Original Exporter was positively
identified by the Mediator and that the source information it
received was trustworthy. However, IPFIX Mediators must in this
circumstance take care not to provide an inappropriate upgrade of
trust.
Therefore, an IPFIX Mediator should not sign a Transport Session to a
Kobayashi, et al. Expires January 12, 2011 [Page 28]
Internet-Draft IPFIX Mediation Framework July 2010
downstream Collector unless all the Original Exporters from which the
information to be exported is derived were positively identified by
the Mediator by its certificate. An exception to this case is the
reverse of the special case in the previous subsection: an IPFIX
Mediator that accepts information from within a trusted domain via an
internal network protected by other means may use TLS or DTLS to
protect the Transport Session to a downstream Collector outside the
domain.
If the X.509 certificates [RFC3280] used to protect a Transport
Session between an Original Exporter and an IPFIX Mediator are
required downstream, an IPFIX Mediator may use the
exporterCertificate and the collectorCertificate Information Elements
with the Export Session Details Options Template defined in Section
8.1.3 of [RFC5655] or the Message Details Options Template defined in
Section 8.1.4 of [RFC5655] in order to export this information
downstream. However, in this case, the IPFIX Mediator is making an
implicit assertion that the upstream Session was properly protected
and therefore trustworthy, and as such must protect the Transport
Session to the downstream Collector using TLS or DTLS, as well.
9.4. Multiple Tenancy
An IPFIX Mediator handling traffic data from multiple separate
sources or for multiple separate purposes must provide for keeping
these data separate. Though the details of this are application-
specific, this generally entails separating Transport Sessions within
the Mediator, and associating them with information related to the
source or purpose, e.g., network or hardware address range, virtual
LAN tag, interface identifiers, and so on. Information from multiple
sources may only be combined within a Mediator when that Mediator is
applied for that specific purpose (e.g., aggregation or concentration
of records).
9.5. Configuration Protection
Due to their trusted position within the infrastructure, IPFIX
Mediators must provide for the protection of their configuration
information, requiring positive authentication and authorization of
administrators for configuration tasks.
Kobayashi, et al. Expires January 12, 2011 [Page 29]
Internet-Draft IPFIX Mediation Framework July 2010
10. IANA Considerations
This document has no actions for IANA.
Kobayashi, et al. Expires January 12, 2011 [Page 30]
Internet-Draft IPFIX Mediation Framework July 2010
11. References
11.1. Normative References
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", January 2008.
[RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling
(PSAMP) Protocol Specifications", March 2009.
11.2. Informative References
[IPFIX-MD-PS]
Kobayashi, A., Claise, B., Nishida, H., Sommer, C.,
Dressler, F., and E. Stephan, "IPFIX Mediation: Problem
Statement",
draft-ietf-ipfix-mediators-problem-statement-09 (work in
progress) , March 2010.
[PSAMP-MIB]
Dietz, T., Claise, B., and J. Quittek, "Definitions of
Managed Objects for Packet Sampling",
draft-ietf-ipfix-psamp-mib-00 (work in progress) ,
March 2010.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", April 2002.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
October 2004.
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version
9", October 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", April 2006.
[RFC4384] Meyer, D., "BGP Communities for Data Collection",
February 2006.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
Kobayashi, et al. Expires January 12, 2011 [Page 31]
Internet-Draft IPFIX Mediation Framework July 2010
January 2008.
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export
Using IP Flow Information Export (IPFIX)", January 2008.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", March 2009.
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX
Applicability", March 2009.
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
in IP Flow Information Export (IPFIX) and Packet Sampling
(PSAMP) Reports", March 2009.
[RFC5474] Duffield, N., "A Framework for Packet Selection and
Reporting", March 2009.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", March 2009.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
March 2009.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", March 2009.
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
Wagner, "An IPFIX-Based File Format", October 2009.
[RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
"Definitions of Managed Objects for IP Flow Information
Export", April 2010.
Kobayashi, et al. Expires January 12, 2011 [Page 32]
Internet-Draft IPFIX Mediation Framework July 2010
Appendix A. Acknowledgements
We would like to thank the following persons: Brian Trammell for
contribution regarding the improvement of terminologies section and
security consideration section; Daisuke Matsubara, Tsuyoshi Kondoh,
Hiroshi Kurakami, Haruhiko Nishida for contribution during the
initial phases of the document; Nevil Brownlee, Juergen Quittek for
the technical reviews and feedback.
Kobayashi, et al. Expires January 12, 2011 [Page 33]
Internet-Draft IPFIX Mediation Framework July 2010
Authors' Addresses
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Gerhard Muenz
Technische Universitaet Muenchen
Boltzmannstr. 3
Garching 85748
Germany
Phone: +49 89 289-18008
Email: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz
Keisuke Ishibashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi 180-8585
Japan
Phone: +81-422-59-3978
Email: ishibashi.keisuke@lab.ntt.co.jp
Kobayashi, et al. Expires January 12, 2011 [Page 34]
