RFC 6183

IP Flow Information Export (IPFIX) Mediation: Framework

📅 published April 2011, from ietf

IP Flow Information Export (IPFIX) Mediation: Framework 🦋

Okay bestie, let's get the basics down first 🎀. This is RFC 6183, published in April 2011. It's Informational, so it's not a Standards Track spec 💅. The authors are A. Kobayashi (NTT), B. Claise (Cisco Systems, Inc.), G. Muenz (TU Muenchen), and K. Ishibashi (NTT). It's got ISSN 2070-1721, and it updates RFC 5470. Nothing gets obsoleted here 🌸.

Abstract 💜

Okay so the abstract is giving: this doc describes a framework for IP Flow Information Export (IPFIX) Mediation. It extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components ✨.

Status of This Memo 🧚

This doc is not an Internet Standards Track spec. It's published just for info, not to be a standard 🌈.

It's still a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). But not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6183 🔗.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components extracted from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🫶.

Table of Contents 🍓

1. Introduction ....................................................3
2. Terminology and Definitions .....................................3
3. IPFIX/PSAMP Documents Overview ..................................6
   3.1. IPFIX Documents Overview ...................................6
   3.2. PSAMP Documents Overview ...................................6
4. IPFIX Mediation Reference Model .................................7
5. IPFIX Mediation Functional Blocks ..............................12
   5.1. Collecting Process ........................................12
   5.2. Exporting Process .........................................13
   5.3. Intermediate Process ......................................13
        5.3.1. Data Record Expiration .............................14
        5.3.2. Specific Intermediate Processes ....................14
6. Component Combination ..........................................20
   6.1. Data-Based Collector Selection ............................20
   6.2. Flow Selection and Aggregation ............................21
   6.3. IPFIX File Writer/Reader ..................................22
7. Encoding for IPFIX Message Header ..............................22
8. Information Model ..............................................24
9. Security Considerations ........................................24
   9.1. Avoiding Security Level Downgrade .........................25
   9.2. Avoiding Security Level Upgrade ...........................25
   9.3. Approximating End-to-End Assertions for IPFIX Mediators ...26
   9.4. Multiple Tenancy ..........................................26
10. References ....................................................27
   10.1. Normative References .....................................27
   10.2. Informative References ...................................27
11. Acknowledgements ..............................................29

1. Introduction ✨

Okay, so the IPFIX architectural components in [RFC5470] are IPFIX Devices and IPFIX Collectors, and they talk to each other using the IPFIX protocol. IP traffic keeps growing across all these heterogeneous network environments, so that Exporter-Collector setup can run into scalability problems 😭. It also doesn't give you the flexibility that a wide variety of measurement applications need. A detailed description of these problems is in [RFC5982] 🙈.

To get application requirements done with limited system resources, the IPFIX architecture needs an intermediate entity sitting between Exporters and Collectors 🧚. From a data manipulation point of view, that middle entity can handle aggregation, correlation, filtering, and modification of Flow Records and/or Packet Sampling (PSAMP) Packet Reports. That saves measurement system resources and does preprocessing for the Collector 💅. From a protocol conversion point of view, it can convert data into IPFIX, or convert IPFIX transport protocols (e.g., from UDP to the Stream Control Transmission Protocol (SCTP)) to improve export reliability 🔥.

This doc introduces a generalized concept for these intermediate entities. It describes the high-level architecture of IPFIX Mediation, the key IPFIX Mediation architectural components, and the characteristics of IPFIX Mediation 🌸.

Here's the layout: Section 2 covers the terminology, Section 3 gives an IPFIX/PSAMP document overview, Section 4 describes a high-level reference model, and Section 5 describes functional features related to IPFIX Mediation. Section 6 describes combinations of components along with some application examples. Section 7 covers consideration points for the encoding of IPFIX Message Headers, Section 8 describes the Information Elements used in an IPFIX Mediator, and Section 9 describes the security issues raised by IPFIX Mediation 👑.

2. Terminology and Definitions 📖

The IPFIX-specific and PSAMP-specific terminology used here is defined in [RFC5101] and [RFC5476], respectively. The IPFIX-Mediation-specific terminology is defined in [RFC5982]. But reading the problem statements doc isn't a prerequisite for this framework doc, so the definitions are reproduced here along with some extra ones 🎀. Like in [RFC5101] and [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific term gets capitalized, and so do the IPFIX-Mediation-specific terms defined here. The use of the terms "must", "should", and "may" in this document is informational only 💖.

In this doc, "record stream" means a stream of records carrying flow-based or packet-based information. The records may be encoded as IPFIX Data Records or in any other format 🦋.

Transport Session Information

The Transport Session Information contains info that lets you identify an individual Transport Session, as defined in [RFC5101] ✨. If SCTP is the transport protocol, the Transport Session Information identifies the SCTP association. If TCP or UDP is the transport protocol, the Transport Session Information corresponds to the 5-tuple {Exporter IP address, Collector IP address, Exporter transport port, Collector transport port, transport protocol}. It may also include more details about how Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347] is used for encryption and authentication 🔐.

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 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. It performs some transformations on this stream based upon the content of each record, states maintained across multiple records, or other data sources. Then it passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other 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. But this isn't an exhaustive list, so there's more out there 🌈.

Intermediate Conversion Process

An Intermediate Conversion Process is an Intermediate Process that transforms non-IPFIX into IPFIX. Or it manages the relation among Templates and the states of incoming/outgoing transport sessions when transport protocol conversion happens (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., data binning and subnet aggregation) 📊.

Intermediate Correlation Process

An Intermediate Correlation Process is an Intermediate Process that adds information to records, noting correlations among them. It can also generate new records with correlated data from multiple records (e.g., producing 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. It passes only the 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, protecting the identity of the entities the records describe (e.g., by applying prefix-preserving pseudonymization of IP addresses) 🙈.

IPFIX Mediator

An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation. It receives a record stream from some data sources, hosts one or more Intermediate Processes to transform that stream, and exports 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 the 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 💜.

3. IPFIX/PSAMP Documents Overview ✨

okay so IPFIX Mediation can work on flow-based info OR packet-based info 🦋 Flow-based info gets encoded as IPFIX Flow Records by the IPFIX protocol. Packet-based info gets pulled out by some packet selection techniques and then encoded as PSAMP Packet Reports by the PSAMP protocol. So this section is basically a cheat sheet for the docs behind BOTH protocols 💅

3.1. IPFIX Documents Overview

the IPFIX protocol [RFC5101] gives network admins access to IP Flow info 🌸 the architecture for exporting measured IP Flow info from an IPFIX Exporting Process to a Collecting Process is in [RFC5470], following the requirements in [RFC3917] 📋 [RFC5101] also explains how IPFIX Data Records and Templates get carried over a bunch of transport protocols, from IPFIX Exporting Processes to IPFIX Collecting Processes 🚚

IPFIX has a formal description of its Information Elements (names, types, and extra semantic info), and that's written up in [RFC5102] 🧠 The IPFIX Management Information Base is defined in [RFC5815] 💜 And [RFC5472] is the one that covers what kinds of applications can use IPFIX and how they can use the info it gives them. It also shows how the IPFIX framework fits in with other architectures and frameworks, so it's lowkey the big-picture doc 🗺️ Last but not least, storing IPFIX Messages in a file is specified in [RFC5655] 🗂️

3.2. PSAMP Documents Overview

the framework for packet selection and reporting [RFC5474] lets network elements select subsets of packets using statistical and other methods, then export a stream of reports on the selected packets to a Collector 🎀 The packet selection techniques PSAMP standardizes (Sampling and Filtering) are described in [RFC5475] ✨ The PSAMP protocol [RFC5476] specifies how packet info gets exported from a PSAMP Exporting Process to a Collector 📦

Just like IPFIX, PSAMP has a formal description of its Information Elements (names, types, and extra semantic info) 🫶 The PSAMP information model is defined in [RFC5477], and the PSAMP Management Information Base is described in [PSAMP-MIB] 🌈

4. IPFIX Mediation Reference Model

okay so Figure A is the high-level IPFIX Mediation reference model 🧚 It's an extension of the IPFIX reference model from [RFC5470], and it covers all the different scenarios that can show up 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 N+1         |    |IPFIX Mediator Z           |
  |[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 N |  |   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 inside each entity are marked in brackets [] 🎀 An IPFIX Mediator can receive IPFIX Flow Records or PSAMP Packet Reports 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 🌊 Then the IPFIX Mediator exports IPFIX Flow Records and/or PSAMP Packet Reports to one or multiple Collectors and/or other IPFIX Mediators 💖

Figure B is the basic IPFIX Mediator component model 💅 An IPFIX Mediator has one or more Intermediate Processes and one or more Exporting Processes. Usually it also has a Collecting Process, but it might have several Collecting Processes, as described in Figure B 🫶

                IPFIX (Data Records)
                            ^
                          ^ |
 +------------------------|-|---------------------+
 | IPFIX Mediator         | |                     |
 |                        | |                     |
 |  .---------------------|-+-------------------. |
 | .----------------------+--------------------.| |
 | |          Exporting Process(es)            |' |
 | '----------------------^--------------------'  |
 |                        | |                     |
 |  .---------------------|-+-------------------. |
 | .----------------------+--------------------.| |
 | |          Intermediate Process(es)         |' |
 | '----------------------^--------------------'  |
 |                        | |                     |
 |  .---------------------|-+-------------------. |
 | .----------------------+--------------------.| |
 | |          Collecting Process(es)           |' |
 | '----------------------^--------------------'  |
 +------------------------|-|---------------------+
                          |
                IPFIX (Data Records)

Figure B: Basic IPFIX Mediator Component Model

but wait, there are other data sources too 👀 An IPFIX Mediator can take a record stream from non-IPFIX protocols, like NetFlow [RFC3954] exporter(s) 🌻 This document doesn't make any particular assumption about how a record stream gets transferred to an IPFIX Mediator 🤷‍♀️ Figure C shows the IPFIX Mediator component model for IPFIX protocol conversion from non-IPFIX exporters 🦄

                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

or, alternatively, an Original Exporter can do IPFIX Mediation itself by hosting one or more Intermediate Processes 🧠 Figure D adds Intermediate Process(es) to the IPFIX Device model from [RFC5470] 💫 Compared to Figures 1 or 2 in [RFC5470], the Intermediate Process sits between the Exporting Process(es) and the IPFIX or PSAMP Metering 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

last one for this section: an Intermediate Process can also 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

5. IPFIX Mediation Functional Blocks ✨

okay so bestie, this is where the mediator gets its whole personality 💅 Figure F shows a functional block diagram example of an IPFIX Mediator with 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 Diagram

5.1. Collecting Process

a Collecting Process in an IPFIX Mediator is basically the same as the one in [RFC5101] 🫶 The extra stuff it does is send the set of Data Records and Control Information to one or more components, i.e., Intermediate Processes and other applications. So a Collecting Process can duplicate the set and send it to one or more components in sequence or in parallel. ✨ In the IPFIX Mediator case, the Control Information described in [RFC5470] includes IPFIX Message Header information and Transport Session Information, plus info 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 also not different from the one in [RFC5101] 🎀 The additional functions in an IPFIX Mediator may include the following:

  • 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.
  • 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. The parameters that represent the origin should be configurable.

5.3. Intermediate Process

the Intermediate Process is a key functional block for IPFIX Mediation, no cap 👑 Its typical functions include the following:

  • Generating a new record stream from an input record stream, including context information (e.g., Observation Domain ID and Transport Session Information), and sending it to other components.
  • 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. Activating this function should be configurable.
  • Maintaining the configurable relation between Collecting Process(es)/Metering Process(es) and Exporting Process(es)/other Intermediate Process(es).
  • Maintaining database(s) of Data Records in the case of an Intermediate Aggregation Process and an Intermediate Correlation Process. This function has the Data Record expiration rules described in the next subsection 🌸
  • Maintaining statistics on the Intermediate Process itself, such as the number of input/output Data Records, etc.
  • Maintaining additional information about output record streams, which includes information related to the Original Exporters, Observation Domain, and administrative domain, as well as 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. ✨

For example, an Intermediate Aggregation Process aggregating incoming Flow Records composed of the sourceIPv4Address and destinationIPv4Address Flow Keys into outgoing Flow Records with the destinationIPv4Address Flow Key must modify the incoming flowKeyIndicator to contain only the destinationIPv4Address 🙈

5.3.1. Data Record Expiration

an Intermediate Aggregation Process and an Intermediate Correlation Process need expiration conditions to export cached Data Records 🧚 In the case of the Metering Process in an Original Exporter, these conditions are described in [RFC5470]. For the Intermediate Process, the conditions are as follows:

  • 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.
  • If the Intermediate Process experiences resource constraints (e.g., lack of memory to store Flow Records), aggregated Flow Records may prematurely expire.
  • 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 is observed within a certain time period 🥺

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:

  • Determining the IPFIX Information Element identifiers that correspond to the fields of the non-IPFIX records (e.g., converting the NetFlow V9 protocol [RFC3954] to the IPFIX Information Model [RFC5102]).
  • Transforming the non-IPFIX records into Data Records, (Options) Template Records, and/or Data Records defined by Options Templates.
  • 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 Options 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:

  • Relaying Data Records, (Options) Template Records, and Data Records defined by Options Templates.
  • Setting the trigger for the Exporting Process in order to export IPFIX Template Withdrawal Messages relevant to the Templates when Templates become invalid due to, for example, incoming session failure. This case applies to SCTP and TCP Transport Sessions on the outgoing side only.
  • Maintaining the mapping information about Transport Sessions, Observation Domain IDs, and Template IDs on the incoming and outgoing sides, in order to ensure the consistency of scope field values of incoming and outgoing Data Records defined by Options Templates and of Template IDs of incoming and outgoing IPFIX Template Withdrawal Messages. 🦋

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 as its input 🍓

The typical function is property match filtering, which 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 ✨

okay so the Intermediate Aggregation Process is the one that squishes a bunch of Data Records from a time window into ONE Flow Record 🫶 it covers these functions:

  • Merging a set of Data Records within a certain time period into one Flow Record by summing up the counters where appropriate. 💖
  • Maintaining statistics 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.

  • 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 set of common properties smaller 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.

If some fields do not serve as Flow Keys or per-Flow counters, 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 PoPs (Points of Presence) in a large network, or a logical interface composed of physical interfaces with link aggregation. 🦋

  • Temporal composition

With temporal composition, multiple 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-key fields, such as the minimumIpTotalLength/maximumIpTotalLength or minimumTTL/maximumTTL, will contain the minimum and maximum values for the new aggregated Flow. 🧚

Spatial and temporal composition can be combined in a single Intermediate Aggregation Process. 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 described in Section 6.2. 🎀

5.3.2.4. Intermediate Anonymization Process

okay now we're in privacy-protection mode 🙈 an Intermediate Anonymization Process covers the following typical functions:

  • 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", "bgpNextHopIP{v4|v6}Address", "bgp{Next|Prev}AdjacentAsNumber", and "mplsLabelStackSection", as described in [RFC5102]. 🔒

  • 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

this one is giving detective 🕵️‍♀️ an Intermediate Correlation Process can be viewed as a special case of the Intermediate Aggregation Process, covering the following typical functions:

  • 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.
  • 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, which can be implemented individually or in combinations. 💜

  • 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 at different Observation Points in the network.

  • Packet inter-arrival time

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.

  • 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 match and the Directional Key Fields match 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 arbitrarily (see [RFC5103], Section 5.3). ↔️

  • Average/maximum/minimum for packets, bytes, one-way delay, packet loss, etc.

The data values come from the correlation of multiple Data Records gathered in a certain time interval.

  • 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]

This value indicates the egress router of a network domain. It is useful for making a traffic matrix that covers the whole network domain.

  • BGP community attributes

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. Thanks to this correlation, network administrators can monitor the customer-based traffic volume even on core routers. 👑

6. Component Combination

okay bestie, the IPFIX Mediator is a multitasker 💅 it may be able to simultaneously support more than one Intermediate Process. Multiple Intermediate Processes generally are configured in the following ways.

  • 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. 👯

  • 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 combo of one or more Intermediate Selection Processes and Exporting Processes can decide which Collector gets which input Data Records 🎯 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 a record stream 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. 🦋

          .----------------------.   .------------.
          | 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 ✨

okay so combining one or more Intermediate Selection Processes with Intermediate Aggregation Processes can seriously shrink the amount of Flow Records 📉💖 the structure is giving the same energy as the Composite Selector from [RFC5474] 🦋 for example, one Intermediate Selection Process picks out Flows made of just a few packets and sends them to an Intermediate Aggregation Process. another Intermediate Selection Process grabs the rest and sends those straight to an Exporting Process, as shown in Figure H 🌸 the end result is aggregation based on how the number of packets per Flow is distributed 🧚

            .------------------.  .--------------.  .------------.
            | 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

6.3. IPFIX File Writer/Reader 💜

okay so an IPFIX File Writer [RFC5655] stores Data Records in a file system 💾 if Data Records have problematic Information Elements in them, an Intermediate Anonymization Process can delete those fields before the IPFIX File Writer gets its hands on them 🙈 see Figure I

          .---------------.  .---------------.  .-------------.
          | Collecting    |  | Intermediate  |  | IPFIX       |
    IPFIX |      Process  |  | Anonymization |  |   File      |
    ----->|               +->|       Process +->|      Writer |
          '---------------'  '---------------'  '-------------'

Figure I: IPFIX Mediation Example with IPFIX File Writer

the IPFIX File Reader [RFC5655] is the opposite vibe 🔄 it pulls stored Data Records back out when administrators want past Data Records from a given time period 🕰️ and if the data structure coming out of the IPFIX File Reader isn't what the administrators want, an Intermediate Anonymization Process and an Intermediate Correlation Process can reshape it, 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

and in the case where distributed IPFIX Mediators make on-demand export of Data Records that a File Writer stored earlier possible, you can set up a collecting infrastructure with huge storage capacity for data retention 🗄️👑

7. Encoding for IPFIX Message Header 🎀

the IPFIX Message Header [RFC5101] includes the Export Time, Sequence Number, and Observation Domain ID fields 📦 this section covers some things to think about when encoding the IPFIX Message Header 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 when an IPFIX Mediator operates as a proxy at the IPFIX Message level rather than the Data Record level 🔁 in case 2, the IPFIX Mediator needs to handle any delta timestamp fields described in [RFC5102], such as flowStartDeltaMicroseconds and flowEndDeltaMicroseconds ⏱️

Sequence Number 🔢

in the case where an IPFIX Mediator relays IPFIX Messages from one Transport Session to another Transport Session, the IPFIX Mediator needs to handle the Sequence Number properly 💅 in particular, the Sequence Number in the outgoing session is not allowed to be re-initialized, even when the incoming session shuts down and restarts 🚫

Observation Domain ID 🌍

according to [RFC5101], the Observation Domain ID in the IPFIX Message Header is locally unique per Exporting Process 🪪 compared to the Observation Domain ID used by an Original Exporter, the Observation Domain ID used by an IPFIX Mediator does not necessarily represent a set of Observation Points located at the IPFIX Mediator itself 🤷‍♀️

an IPFIX Mediator may act as a proxy by relaying entire IPFIX Messages 🎁 in this case, it may report information about the Original Exporters by using the Observation Domain ID of the outgoing Messages as the scope field in an Options Template Record 🧾

otherwise, the IPFIX Mediator should have a function to export the observation location information regarding the Original Exporter 📍 that information contains the IP addresses and Observation Domain IDs used by the Original Exporters, plus some details about the Transport Session, for example the source port number, so that different Exporting Processes on the same Original Exporter can be told apart 🕵️‍♀️ as far as privacy policy permits, an IPFIX Mediator reports this information to an IPFIX Collector 🔐

if information about a set of Original Exporters needs to be reported, it can be useful to export it as Common Properties as specified in [RFC5473] 🫧 the commonPropertiesID may then serve as a scope for that set of Original Exporters 🎯 the Common Properties Withdrawal Message [RFC5473] can be used to indicate that an incoming Transport Session from one of the Original Exporters was closed 👋

8. Information Model 📚

IPFIX Mediation reuses the general information models from [RFC5102] and [RFC5477] 💫 and, depending on the type of Intermediate Processes, it could potentially use Information Elements such as:

  • Original Exporter IP address, Observation Domain ID, and source port number about the Transport Session at the Original Exporter, in the case where an IPFIX Mediator reports original observation location information in Section 7. The Information Elements contained in the Export Session Details Options Template in [RFC5655] may be utilized for this purpose.
  • Report on the applied IPFIX Mediation functions as described in Section 6.7. in [RFC5982].
  • Certificate of an Original Exporter in Section 9. The Information Element exporterCertificate in [RFC5655] may be utilized for this purpose.

9. Security Considerations 🔒💀

okay this part is SERIOUS bestie 😭🔥 as Mediators act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for IPFIX [RFC5101] also apply to Mediators 🛡️ the Security Considerations for IPFIX Files [RFC5655] also apply to IPFIX Mediators that write IPFIX Files or use them for internal storage 📁 and on top of that, there are a few specific considerations that IPFIX Mediator implementations must take into account ⚠️

by design, IPFIX Mediators are "men-in-the-middle" 🕴️ they step into 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, and yes, that is by design 🙃 this has big implications for the level of confidentiality provided across an IPFIX Mediator, and for 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 the specific security issues raised by IPFIX Mediation 👇

9.1. Avoiding Security Level Downgrade 📉🚨

an IPFIX Mediator that accepts IPFIX Messages over a Transport Session protected by TLS [RFC5246] or DTLS [RFC4347], and then exports IPFIX Messages derived from them in cleartext, is a potentially serious vulnerability in an IPFIX infrastructure 😱 the concern is that confidentiality protection may be lost across a Mediator 🫠

so, an IPFIX Mediator that receives IPFIX Messages from an upstream Exporting Process protected using TLS or DTLS must provide for sending the IPFIX Messages resulting from the operation of the Intermediate Process(es) to a downstream Collecting Process using TLS or DTLS by default 🔐 it may be configurable to export records derived from protected records in cleartext, but only when application requirements allow 🎀

there are two common use cases for this 🧠 first, a Mediator performing a transformation that leads to a reduction in the required level of security (e.g., by removing all information requiring confidentiality from the output records) may export records downstream without confidentiality protection 🧹 second, a mediator that acts as a proxy between an external (untrusted) network and an internal (trusted) network may export records without TLS when the additional overhead of TLS is unnecessary (e.g., on a physically protected network in the same locked equipment rack) 🗝️

9.2. Avoiding Security Level Upgrade 📈🧐

there's a similar problem in the opposite direction 🙃 an IPFIX Mediator's signature on a TLS session to a downstream Collecting Process acts as an implicit assertion that the data within the session is trustworthy, so a poorly deployed IPFIX Mediator could be used to "legitimize" records derived from untrusted sources 😤 unprotected sessions from the Original Exporter are generally untrusted, because they could have been tampered with or forged by an unauthorized third party 🕵️ the concern is that a Mediator could be used to add inappropriate trust to external information whose integrity cannot be guaranteed 🚩

when specific deployment requirements allow, an IPFIX Mediator may export signed IPFIX Messages containing records derived from records received without integrity protection via TLS 🖋️ one such deployment consideration would be the reverse of the second case above: when the Mediator acts as a proxy between an internal (trusted) and an external (untrusted) network, when the path from the Original Exporter is protected using some other method, and when the overhead of a TLS session is unnecessary 🌿

in such cases, the IPFIX Mediator should notify the downstream Collector about the missing protection of all or part of the original record stream, as part of the Transport Session Information 📣💜

9.3. Approximating End-to-End Assertions for IPFIX Mediators

okay so here's the tea 🍵 The Transport Session between an IPFIX Mediator and an Original Exporter is totally independent from the Transport Session between the Mediator and the downstream Collecting Process. That means there's no existing method via TLS to assert the identity of the original Exporting Process downstream 😭 But wait, an IPFIX Mediator modifies the stream of IPFIX Messages sent to it, so it's by definition a trusted entity in the infrastructure ✨ So the 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, as noted in the previous section, IPFIX Mediators must in this circumstance take care not to provide an inappropriate upgrade of trust 🚨

Bestie, this is the part to screenshot. The Mediator's signature is basically a vouch, so don't vouch for something you didn't actually verify 💅

If the X.509 certificates [RFC5280] used to protect a Transport Session between an Original Exporter and an IPFIX Mediator are required downstream, an IPFIX Mediator may export Transport Session Information, including 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, or that the Mediator has otherwise been configured to trust the information from the Original Exporter. As such, it must protect the Transport Session to the downstream Collector using TLS or DTLS as well 🔐 It's giving "if you're gonna vouch, lock it down too" 💜

9.4. Multiple Tenancy

Information from multiple sources may only be combined within a Mediator when that Mediator is applied for that specific purpose (e.g., spatial aggregation or concentration of records) 🌸 In all other cases, an IPFIX Mediator must provide for keeping traffic data from multiple sources separate. The details are application-specific, but this generally means 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 🧚 Basically, keep everybody's tea in their own cup ☕✨

10. References 📚

10.1. Normative References

  • [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
  • [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
  • [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
  • [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.

10.2. Informative References

  • [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", Work in Progress, March 2011.
  • [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
  • [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
  • [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
  • [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, February 2006.
  • [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
  • [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
  • [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
  • [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
  • [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
  • [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
  • [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
  • [RFC5815] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010.
  • [RFC5982] Kobayashi, A., Ed., and B. Claise, Ed., "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010.

11. Acknowledgements 🫶

Huge thank-yous to the following people 💖 Brian Trammell for his contribution regarding the improvement of the terminology section and the security considerations section 🙌 Daisuke Matsubara, Tsuyoshi Kondoh, Hiroshi Kurakami, and Haruhiko Nishida for their contribution during the initial phases of the document 🌈 And Nevil Brownlee and Juergen Quittek for their technical reviews and feedback 👑

Authors' Addresses

Atsushi Kobayashi
Nippon Telegraph and Telephone East Corporation
26F 3-20-2, Nishi-shinjuku 3-chome
Shinjuku, Tokyo 163-8019
Japan
Phone: +81-3-5353-3636
EMail: akoba@orange.plala.or.jp


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
EMail: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz


Keisuke Ishibashi
NTT Service Integration Platform Laboratories
3-9-11 Midori-cho
Musashino-shi 180-8585
Japan
Phone: +81-422-59-3407
EMail: ishibashi.keisuke@lab.ntt.co.jp
📦 where this page comes from