IPFIX Working Group A. Kobayashi
Internet-Draft H. Nishida
Intended status: Informational NTT PF Lab.
Expires: January 1, 2009 B. Claise
Cisco Systems
June 30, 2008
IPFIX Mediation: Framework
draft-ietf-ipfix-mediators-framework-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2009.
Kobayashi, et al. Expires January 1, 2009 [Page 1]
Internet-Draft IPFIX Mediation Framework June 2008
Abstract
This document describes a framework for an IPFIX Mediation. An IPFIX
Mediation device (IPFIX Mediator) is an intermediate device between
IPFIX Exporters and IPFIX Collectors. This framework describes an
architecture model, the components of the architecture, and
guidelines for the IPFIX protocol specifications for the IPFIX
Mediators. In addition, this document describes applicable examples
for IPFIX Mediation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 6
3.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 6
3.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 7
3.3.1. Metering Process . . . . . . . . . . . . . . . . . . . 8
3.3.2. IPFIX File Writer/Reader . . . . . . . . . . . . . . . 10
4. Guideline for IPFIX Protocol for IPFIX Mediators . . . . . . . 12
4.1. Handling Delta Time Field . . . . . . . . . . . . . . . . 12
4.2. Observation Domain ID Management . . . . . . . . . . . . . 12
4.3. Template ID Management . . . . . . . . . . . . . . . . . . 13
4.4. Transport Session Management . . . . . . . . . . . . . . . 13
4.5. Option Template Management . . . . . . . . . . . . . . . . 14
4.6. Reporting Original Exporter Information . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Solution Scenarios with IPFIX Mediators . . . . . . . 19
A.1. Flexible Aggregation . . . . . . . . . . . . . . . . . . . 19
A.2. Distributed Aggregation . . . . . . . . . . . . . . . . . 19
A.3. Duplication of Flow Records . . . . . . . . . . . . . . . 20
A.4. Distribution of Flow Records . . . . . . . . . . . . . . . 21
A.5. Extraction of Suspicious Flow . . . . . . . . . . . . . . 22
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Kobayashi, et al. Expires January 1, 2009 [Page 2]
Internet-Draft IPFIX Mediation Framework June 2008
1. Introduction
This document describes the framework for IPFIX Mediators to reroute,
filter, aggregate, correlate, or modify Flow Records/Packet Reports,
and to export the output to Collectors.
The motivation for the IPFIX Mediation standard comes from the need
for flow-based measurement system support for large-scale networks,
interdomain networks, and coexistence with traditional Exporters as
described in [I-D.ietf-ipfix-mediators-ps] in detail. The standard
specification requires a definition of IPFIX Mediator, and a
consistency in the IPFIX protocol between Exporters and Mediators,
and between Collectors and Mediators. The motivation for the IPFIX
Mediation functions comes from the applications that enable a
scalable and flexible measurement system.
This document is organized as follows. Section 2 describes
terminologies related to IPFIX Mediation. Section 3 describes the
architecture model and details the components of this architecture.
Section 4 describes the consideration points and guideline for the
IPFIX protocol.
Kobayashi, et al. Expires January 1, 2009 [Page 3]
Internet-Draft IPFIX Mediation Framework June 2008
2. Terminology
The basic terms related to IPFIX protocol, such as Metering Process,
Exporting Process, Collecting Process and Data Record, are aligned
with the definitions in [RFC5101]. The terms related to PSAMP
protocol specifications like Packet Reports and Packet
Interpretation, are aligned with the definitions in
[I-D.ietf-psamp-protocol]. The terms related to IPFIX Device, such
as Exporter, Collector, IPFIX Proxy and IPFIX Concentrator, are
aligned with the definitions in [RFC3917]. The terms related to
IPFIX Mediation Device, such as IPFIX Masquerading Proxy and IPFIX
Distributor are aligned with the definitions in
[I-D.ietf-ipfix-mediators-ps]. Other than the above terms are
defined here. All these terms are capitalized in this document.
Mediator Metering Process
A Metering Process in IPFIX Mediators can be considered as a
partial Metering Process separated from that in Original Exporters
as described in [RFC3917].
The Mediator Metering Process generates new sets of Data Records/
Packet Reports from input Data Records/Packet Reports. The
functionality of the Mediator Metering Process includes selecting,
aggregating, and modifying Flow Records/Packet Reports, but is not
limited to: selection, aggregation, modification.
Flow-Based Collector Selection Function
This function filters input Flow Records/Packet Reports based on
the value of the specified Information Element and then selects
Collectors for the filtered (classified) Flow Records/Packet
Reports.
Mediator Observation Domain ID
An IPFIX Mediator does not host the Observation Points and
Observation Domain. The Observation Domain ID in the IPFIX header
sent by IPFIX Mediator also indicates the largest set of
Observation Points from the viewpoint of a Collector. However
this value does not indicate the physical entity of an Original
Exporter.
Transport Session Information
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
Kobayashi, et al. Expires January 1, 2009 [Page 4]
Internet-Draft IPFIX Mediation Framework June 2008
address, Exporter transport port, Collector transport port,
transport protocol}.
Kobayashi, et al. Expires January 1, 2009 [Page 5]
Internet-Draft IPFIX Mediation Framework June 2008
3. Architecture Model
Here is the basic IPFIX Mediator architecture model. The IPFIX
Mediator is formally defined to consist of one or more Collecting
Processes, zero or more intermediate processes, and one or more
Exporting Processes. Basically, IPFIX Mediator devices: IPFIX Proxy,
IPFIX Masquerading Proxy, IPFIX Distributor and IPFIX Concentrator
are composed of these components. The following subsection describes
details of each component and examples applicable to the component.
.-------------------------------------------------.
| .----------. .----------.|
| .----------.| .------------. .----------.||
|.----------.|| .------------.| .----------.|||
IPFIX ||Collecting||| |Intermediate|| |Exporting ||||IPFIX
----->||Processes ||'-->|Processes ||-->|Processes ||'|----->
|| |' |(optional) |' | |' |
|'----------' '------------' '----------' |
'-------------------------------------------------'
Figure A: Basic IPFIX Mediator Model.
3.1. Collecting Process
The Collecting Process receives Data Records/Packet Reports from
Original Exporters as described in [RFC5101]. The process forwards
the received Data Records/Packet Reports with IPFIX header
information and Transport Session Information to multiple components:
Intermediate Processes and Exporting Processes. In other words, the
process may duplicate received Data Records/Packet Reports and
forward them to multiple components in sequence or in parallel.
3.2. Exporting Process
The Exporting Process forwards Data Records/Packet Reports to one or
multiple Collectors. The process manages the reporting Template and
makes an IPFIX Message as described in [RFC5101]. In addition, the
process carries out a Flow-based Collector Selection Function as
optional.
Applicable examples include exporting Flow Records/Packet Reports to
a dedicated Collector on the basis of customers/peering
organizations. The Exporting Process classifies Flow Records/Packet
Reports on the basis of a peering AS number, as shown in the
following figure. The set of classified Flow Records/Packet Reports
is exported to a dedicated Collector on the basis of the peering AS
number.
Kobayashi, et al. Expires January 1, 2009 [Page 6]
Internet-Draft IPFIX Mediation Framework June 2008
.----------------------------.
| Exporting Process |
| .----------------------. |
| | Flow-Based Collector | |
| | Selection Function | |
| | | |
| | Peering AS #10 | |
| | +-------------------+-+---> Collector #1
| | | Peering AS #20 | |
Flow --+---+--+-------------------+-+---> Collector #2
Records | | | Peering AS #30 | |
| | +-------------------+-+---> Collector #3
| '----------------------' |
'----------------------------'
Figure B: Exporting classified Flow Records to dedicated Collector.
3.3. Intermediate Process
The most generic intermediate process configuration is composed of a
Metering Process, and/or an IPFIX File Reader/Writer described in
[I-D.ietf-ipfix-file]. Metering Process as a typical component of
IPFIX Concentrator and Remote Observation is described in [RFC5101].
A possible configuration model of these components is as follows.
.----------. .------------------------------------. .---------.
| | | Intermediate Process | | |
| | | .-------------------------------. | | |
|Collecting| | | Metering Process | | |Exporting|
|Process | | |.-------. .-------. .-------.| | |Process |
| |---->|sub |->|sub |->|sub |--->| |
| | | ||process| |process| |process|| | | |
| | |.->|#1 | |#2 | |#3 || | | |
| | || |'-------' '-------' '-------'| | | |
| | || '----|----------|----------|----' | | |
| | || | | | | | |
| | || .----\/---------\/---------\/---. | | |
| | |'-| IPFIX File Reader/Writer |<--| |
| |--->| |-->| |
| | | '-------------------------------' | | |
'----------' '------------------------------------' '---------'
Figure C: Intermediate Process Component Model.
Kobayashi, et al. Expires January 1, 2009 [Page 7]
Internet-Draft IPFIX Mediation Framework June 2008
3.3.1. Metering Process
The Metering Process generates new sets of Data Records/Packet
Reports from input Data Records/Packet Reports with IPFIX header
information: "Export Time" and "Observation Domain ID". The process
hosts several subprocesses: the Selecting Process, Aggregating
Process, and Modifying Process. These subprocesses can connect to
each other in any sequence. The output of each subprocess can be
inputs of other subprocesses. Subprocesses are as follows.
Selecting Process
A Selecting Process in IPFIX Mediators is analogous to that in
PSAMP Devices described in [I-D.ietf-psamp-framework]. The
Selecting Process selects input Data Records/Packet Reports
matching under some filtering policy and then forwards them to the
next process.
Aggregating Process
An Aggregating Process creates aggregated Flow Records from input
Flow Records/Packet Reports in accordance with aggregation rules
that are described in [I-D.dressler-ipfix-aggregation].
Modifying Process
A Modifying Process comprises two different types of modification,
as follows.
* Adding/deleting specified Information Elements: changing data
structure of Template.
* Modifying the value of a specified Information Element.
Each subprocess is shown in detail.
3.3.1.1. Selecting Process
The Selecting Process uses several selection techniques, such as
property match filtering and Flow selection techniques, which are
described in [I-D.ietf-psamp-framework] and
[I-D.peluso-flowselection], respectively. In property match
filtering, if the value of specified Information Element equal a pre-
configured value, the function selects Data Records//Packet Reports
to forward them to the next process.
Kobayashi, et al. Expires January 1, 2009 [Page 8]
Internet-Draft IPFIX Mediation Framework June 2008
3.3.1.2. Aggregating Process
The Aggregating Process gathers Flow Records/Packet Reports within a
given time interval and then distinguishes Flow Records/Packet
Reports that have common properties. If values of a given key field
are the same, that means those Flow Records/Packet Reports have
common properties. This process merges Flow Records/Packet Reports
that have a common property and creates an aggregated Flow Record.
For example, aggregated Flow Records have an aggregation counter that
indicates the number of packets. These functions are defined in
accordance with the IPFIX aggregation rules in
[I-D.dressler-ipfix-aggregation].
In addition, the process can create statistical data and subsidiary
information related to the aggregated Flow Records. Examples include
the number of input Flow Records/Packet Reports, the given interval
time, and a set of Flow Key Information Elements.
3.3.1.3. Modifying Process
The Modifying Process modifies input Data Records/Packet Reports.
The process can add new Information Elements, delete existing
Information Elements, or modify the value of specified Information
Elements. If the process modifies the data structure of an original
Template, it also needs to modify the value of the
"flowKeyIndicator".
Adding specified Information Elements
This function obtains the value of a specified Information
Element, and then adds it into Data Records/Packet Reports. There
are several methods to obtain the value: retrieving the value from
some database or calculating the value based on the value of other
Information Elements and received traffic data.
Applicable examples include adding derived packet property
parameters instead of Original Exporters. Doing that can
compensate for traditional Exporters or probes unable to add
packet property parameters. Therefore, Collectors do not need to
recognize the difference between implementations of routers from
several vendors or Exporter types, such as router, switch or
probe. Typical derived packet property parameters include:
* "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] indicates
the egress router of some network domain. That is useful for
making a traffic matrix that covers the whole network domain.
Kobayashi, et al. Expires January 1, 2009 [Page 9]
Internet-Draft IPFIX Mediation Framework June 2008
* BGP Community value indicates the same group of destination or
source IP addresses.
* "mplsVpnRouteDistinguisher" described in [RFC5102], which
cannot be extracted from the core router in MPLS networks,
indicates the VPN customer's identification. Network operators
can monitor the traffic behavior of each customer by adding
"mplsVpnRouteDistinguisher" to Flow Records/Packet Reports.
Deleting specified Information Elements
This function deletes existing Information Elements according to
instruction rules, which indicate whether an Information Element
should be removed.
Applicable examples include hiding network topology information
and private information. In the case of interdomain IPFIX
exporting, the function can avoid making a vulnerability by
deleting unnecessary Information Elements. Examples of network
topology information include: "ipNextHopIP{v4|v6}Address",
"bgpNextHopIP{v4|v6}Address", and "bgp{Next|Prev}AdjacentAsNumber"
described in [RFC5102]. In addition, MPLS-related Information
Elements, such as "mplsLabelStackSection", are useless for
customers in the case of feeding Flow Records/Packet Reports to
VPN customers.
Modifying the value of specified Information Elements
This function modifies the value of specified Information
Elements.
Applicable examples include anonymizing customers' private
information, such as IP address and port number, according to a
privacy protection policy. IPFIX Mediators may anonymize Data
Records/Packet Reports instead of the Exporting Processes of
Original Exporter as described in [RFC3917]. The function also
reports anonymization methods and the part of anonymized data as
subsidiary information.
3.3.2. IPFIX File Writer/Reader
The process of IPFIX File Writer stores input Data Records/Packet
Reports from any process in a storage system. If received Data
Records/Packet Reports include uninteresting Information Elements,
the Modifying Process can delete these elements before IPFIX File
Writer handles them. Therefore, IPFIX File Writers can accept input
from any process. In either case, input needs to include the IPFIX
header information and the Transport Session Information along with
Kobayashi, et al. Expires January 1, 2009 [Page 10]
Internet-Draft IPFIX Mediation Framework June 2008
Flow Records/Packet Reports.
On the other hand, the process of IPFIX File Reader retrieves stored
Data Records/Packet Reports when operators want to retrieve past Data
Records/Packet Reports on the basis of a given time period. If a
data structure of output Data Records/Packet Reports from IPFIX File
Reader is different from that which operators want, the Modifying
Process can modify the data structure. Therefore, output of IPFIX
File Readers can be input to any process except for the Collecting
Process. The IPFIX File Writer/Reader are described in
[I-D.ietf-ipfix-file] in detail.
Kobayashi, et al. Expires January 1, 2009 [Page 11]
Internet-Draft IPFIX Mediation Framework June 2008
4. Guideline for IPFIX Protocol for IPFIX Mediators
This section describes consideration points and guideline for IPFIX
Protocol for IPFIX Mediators.
4.1. Handling Delta Time Field
IPFIX Mediators need to compensate for any delta time stamp fields,
such as "flowStartDeltaMicroseconds" and "flowEndDeltaMicroseconds",
if Exporting Processes write the "Export Time" field of an IPFIX
Message when an IPFIX Message leaves. These Information Elements
indicate the difference from "Export Time". IPFIX Mediators can
carry that out in several ways:
o reusing the "Export Time" of received IPFIX Messages from the
Original Exporter.
o rewriting the value of delta time fields based on the new value of
"Export Time".
o deleting the delta time fields after adding the absolute and fixed
time fields.
In either case, IPFIX Mediators need to guarantee the value of time
stamp fields.
4.2. Observation Domain ID Management
IPFIX Mediators need to guarantee a unique Observation Domain ID for
an Exporting Process to comply with the IPFIX Protocol. IPFIX
Mediators can carry that out in several ways:
o relaying the Observation Domain ID in a received IPFIX Message.
o assigning a new value to the Observation Domain ID and replacing
it with the new one.
o overwriting zero value of Observation Domain ID under the
condition that one Transport Session has one Observation Domain
ID.
The method for handling Observation Domain ID also depends on the
role of devices and relaying patterns for IPFIX transport sessions:
o from one receiving session to one exporting session.
o from one receiving session to multiple exporting sessions.
Kobayashi, et al. Expires January 1, 2009 [Page 12]
Internet-Draft IPFIX Mediation Framework June 2008
o from multiple receiving sessions to one exporting session.
o from multiple receiving sessions to multiple exporting sessions.
In the case of relaying from one session to one or more sessions,
IPFIX Mediators can directly relay IPFIX Messages as an IPFIX Proxy
without replacing the Observation Domain ID. In the case of other
patterns, IPFIX Mediators need to replace the Observation Domain ID
with the new value and manage the new and original Observation Domain
ID along with the received Transport Session Information. This
linkage information is available for overwriting the scope field of
the Option Template.
Note:
To comply with the description in [RFC5101], if IPFIX Mediators
aggregate the received Flow Records, the new value of an Observation
Domain ID needs to be zero. However, that seems to be selectable, if
IPFIX Mediator can assign the value of Observation Domain ID for a
large set of Observation Points.
4.3. Template ID Management
IPFIX Mediators need to guarantee the unique Template ID for an
Observation Domain ID to comply with the IPFIX Protocol. IPFIX
Mediators can carry that out in several ways:
o relaying the Template ID in a received IPFIX Message under the
condition that the Observation Domain ID is relayed.
o using the fixed value under the condition that the fixed Template
is applied to any input Data Records/Packet Reports/Packet
Interpretation.
o assigning the new value to the Template ID and replacing it with
the new value.
In either case, IPFIX Mediators need to manage the new value and
original value of Template ID along with the received Transport
Session Information and Observation Domain ID. Note that in case
sending an Option Template and a Template Withdraw Message, the
values of the scope field and the Template ID field are correct.
4.4. Transport Session Management
IPFIX Mediators need to manage the collecting sessions and the
exporting sessions. Even if one session is reset, IPFIX Mediators
need to maintain the status of the other session. However, Templates
for resetting the collecting session need to be withdrawn for the
Kobayashi, et al. Expires January 1, 2009 [Page 13]
Internet-Draft IPFIX Mediation Framework June 2008
Exporting Session under the condition that IPFIX Mediators assign the
new value to the Template ID.
4.5. Option Template Management
IPFIX Mediators need to guarantee the scope field to be applicable.
Generally, Options Data Records include subsidiary data for Flow
Records/Packet Reports, and statistics data for IPFIX protocol
session. For subsidiary data, such as "samplingSize" and
"systemInitTimeMilliseconds", IPFIX Mediators can carry that out in
several ways:
o merging the data into Flow Records/Packet Reports without
exporting Options Data Records.
o modifying the value in the scope fields to match the Observation
Domain ID and Template ID, and exporting it.
In either case, IPFIX Mediators need to report the subsidiary data to
the next Collector. For statistics data, IPFIX Mediators can also
carry that out in several ways:
o adding the counter of the received data and that of IPFIX
Mediators, and exporting it.
o relaying the received data without changing the counters.
o by not exporting the received data.
The method also depends on the role of devices: IPFIX Proxy or other
devices.
4.6. Reporting Original Exporter Information
Whether to report Original Exporter information, such as Exporter IP
address, or not depends on the role of the device. IPFIX Mediators
may determine that based on the pre-configured rule. The reporting
methods include:
o merging Original Exporter Information into Flow Records/Packet
Reports, and exporting them.
o creating Options Data Records regarding the Original Exporter
Information and exporting them.
Kobayashi, et al. Expires January 1, 2009 [Page 14]
Internet-Draft IPFIX Mediation Framework June 2008
5. Security Considerations
IPFIX Mediators use the IPFIX protocol. Security considerations
about Flow Records are described in [RFC5101].
Kobayashi, et al. Expires January 1, 2009 [Page 15]
Internet-Draft IPFIX Mediation Framework June 2008
6. IANA Considerations
This document has no actions for IANA.
Kobayashi, et al. Expires January 1, 2009 [Page 16]
Internet-Draft IPFIX Mediation Framework June 2008
7. References
7.1. Normative References
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export(IPFIX)",
October 2004.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
January 2008.
7.2. Informative References
[I-D.dressler-ipfix-aggregation]
Dressler, F., Sommer, C., Munz, G., and A. Kobayashi,
"IPFIX Aggregation",
draft-dressler-ipfix-aggregation-04.txt (work in
progress) , November 2007.
[I-D.ietf-ipfix-file]
Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
Wagner, "An IPFIX-Based File Format",
draft-ietf-ipfix-file-01.txt(work in progress) ,
February 2008.
[I-D.ietf-ipfix-mediators-ps]
Kobayashi, A., Nishida, H., Sommer, C., Dressler, F.,
Stephan, E., and B. Claise, "IPFIX Mediation: Problem
Statement",
draft-ietf-ipfix-mediation-problem-statement-00.txt(work
in progress) , May 2008.
[I-D.ietf-psamp-framework]
Duffield, N., "A Framework for Packet Selection and
Reporting", draft-ietf-psamp-framework-12.txt , June 2007.
[I-D.ietf-psamp-protocol]
Claise, B., Quittek, J., and A. Johnson, "Packet Sampling
(PSAMP) Protocol Specifications",
draft-ietf-psamp-protocol-09.txt , December 2007.
[I-D.peluso-flowselection]
Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow
Kobayashi, et al. Expires January 1, 2009 [Page 17]
Internet-Draft IPFIX Mediation Framework June 2008
selection Techniques",
draft-peluso-flowselection-tech-01.txt(work in progress) ,
November 2007.
Kobayashi, et al. Expires January 1, 2009 [Page 18]
Internet-Draft IPFIX Mediation Framework June 2008
Appendix A. Solution Scenarios with IPFIX Mediators
A.1. Flexible Aggregation
An IPFIX Mediator as an IPFIX Concentrator can aggregate Flow Records
and reduce the number of Flow Records received by a IPFIX Collector.
The following figure indicates a cascade connection of IPFIX
Mediators. If an IPFIX Collector measures a traffic matrix to obtain
traffic demand, it needs Flow Records of the whole network domain,
but does not need detailed Flow Records. The first level IPFIX
Mediators aggregate the received Flow Records based on prefix mask
aggregation. Next, the second level IPFIX Mediators aggregate them
further based on the BGP next-hop address or the IPFIX router
address. After this, the IPFIX Collector receives high-level
aggregated Flow Records. This method enables step-by-step
aggregation of Flow Records without overloading a single node.
.--------. .--------.
|IPFIX | |IPFIX |
|router#1|---->|Mediator|---.
| | |*1 | |
'--------' '--------' | .--------. .---------.
'--->|IPFIX | |IPFIX |
.--------. .--------. .--->|Mediator|---->|Collector|
|IPFIX | |IPFIX | | |*2 | | |
|router#2|---->|Mediator|---' '--------' '---------'
| | |*1 |
'--------' '--------'
Figure A.A : Flexible Aggregation with Cascading IPFIX Mediators.
A.2. Distributed Aggregation
In case of global ISPs, the distances between PoPs become longer, and
the maintenance of a dedicated management network is very expensive.
Therefore, the huge number of Flow Records has burdened management
networks. An IPFIX Mediator located in each PoP can minimize the
number of Flow Records exported to the Collector by aggregating or
filtering. If the Collector needs detailed information, it can
retrieve Flow Records from IPFIX Mediators that store original Flow
Records.
Kobayashi, et al. Expires January 1, 2009 [Page 19]
Internet-Draft IPFIX Mediation Framework June 2008
POP#Asia
.--------.
.--------. | .---------.
.--------. | |----->|IPFIX |
|IPFIX | |------->|Mediator |----.
|router |---'----->|#1 | |
|#1 |-' '---------' |
'--------' |
|
POP#North America |
.--------. |
.--------. | .---------. | .---------.
.--------. | |----->|IPFIX | '---->|IPFIX |
|IPFIX | |------->|Mediator |--------->|Collector|
|router |---'----->|#2 | .---->| |
|#4 |-' '---------' | '---------'
'--------' |
|
POP#Europe |
.--------. |
.--------. | .---------. |
.--------. | |----->|IPFIX | |
|IPFIX | |------->|Mediator |----'
|router |---'----->|#3 |
|#7 |-' '---------'
'--------'
Figure A.B: Traffic Collection Architecture in Global Networks.
A.3. Duplication of Flow Records
An IPFIX Mediator duplicates Flow Records to achieve redundant
storage or utilizes them for several purposes.
Kobayashi, et al. Expires January 1, 2009 [Page 20]
Internet-Draft IPFIX Mediation Framework June 2008
Several departments in an ISP want to use the same traffic data for
each intended purpose. The network design department measures the
traffic matrix to obtain traffic demand. The customer service
division uses traffic information for performing accounting services
for each customer while network operators use traffic data for
trouble shooting analysis. That situation is shown in the following
figure.
Measurement traffic matrix.
.--------. .---------.
|IPFIX | |IPFIX |
|router#1|----. .---->|Collector|
| | | | |#1 |
'--------' | | '---------'
| | Using Accounting
.--------. | .---------. | .---------.
|IPFIX | '---->|IPFIX |----' |IPFIX |
|router#2|--------->|Mediator |--------->|Collector|
| | .---->| |----. |#2 |
'--------' | '---------' | '---------'
| | Using Trouble shooting.
.--------. | | .---------.
|IPFIX | | | |IPFIX |
|router#3|----' '---->|Collector|
| | |#3 |
'--------' '---------'
Figure A.C: Duplication of Flow Records.
A.4. Distribution of Flow Records
An IPFIX Mediator distribute Flow Records based on the value of
specified Information Elements. This function enables load balancing
of Collector and sorting Flow Records without extra IPFIX Collector
functions. In case of using accounting, IPFIX Mediator can
distribute Flow Records to the dedicated IPFIX Collector of each
customer.
Kobayashi, et al. Expires January 1, 2009 [Page 21]
Internet-Draft IPFIX Mediation Framework June 2008
When network operators disclose traffic information to each customer,
security or the privacy policy should be considered. In that case,
the IPFIX Mediator hides private information about each customer. In
addition, Mediator distributes traffic data based on RD (Route
Distinguisher), ingress IF, peering AS number, or BGP next hop, which
identify the customer. In the following figure, the IPFIX Mediator
distributes Flow Records based on RD. The system securely allows
each customer to access only their own records.
.--------. .---------.
|IPFIX | |IPFIX |
|router#1|----. .---->|Collector|<===> Customer#A
| | | | |#1 |
'--------' | | '---------'
| RD=100:1
| .---------. |
.--------. '---->|IPFIX |----' .---------.
|IPFIX | |Mediator | RD=100:2 |IPFIX |
|router#2|--------->| |--------->|Collector|<===> Customer#B
| | | | |#2 |
'--------' .---->| |----. '---------'
| '---------' |
| RD=100:3
.--------. | | .---------.
|IPFIX | | | |IPFIX |
|router#3|----' '---->|Collector|<===> Customer#C
| | |#3 |
'--------' '---------'
Figure A.E: Distribution of Flow Records.
A.5. Extraction of Suspicious Flow
An IPFIX Mediator performs filtering based on the value of specified
Information Elements. Filter conditions are set depending on
suspicious Flows as follows. The IPFIX Collector receives the
specified suspicious flow and detects an anomalous Flow by simply
monitoring the traffic volume of each suspicious Flow.
o TCP Flow Records whose "tcpControlBits" value is set to "null"
o TCP Flow Records whose "tcpControlBits" value is set to the SYN
bit only and the packet counter is only 1.
o ICMP Flow Records whose length is too long.
Kobayashi, et al. Expires January 1, 2009 [Page 22]
Internet-Draft IPFIX Mediation Framework June 2008
Appendix B. Acknowledgements
The gratefully acknowledgements for the contributions:
Keisuke Ishibashi,
Tsuyoshi Kondoh,
Daisuke Matsubara.
Kobayashi, et al. Expires January 1, 2009 [Page 23]
Internet-Draft IPFIX Mediation Framework June 2008
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
Haruhiko Nishida
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: nishida.haruhiko@lab.ntt.co.jp
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
Diegem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Kobayashi, et al. Expires January 1, 2009 [Page 24]
Internet-Draft IPFIX Mediation Framework June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kobayashi, et al. Expires January 1, 2009 [Page 25]
