GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6183

Internet Engineering Task Force (IETF) A. Kobayashi Request for Comments: 6183 NTT Updates: 5470 B. Claise Category: Informational Cisco Systems, Inc. ISSN: 2070-1721 G. Muenz

                                                           TU Muenchen
                                                          K. Ishibashi
                                                                   NTT
                                                            April 2011
      IP Flow Information Export (IPFIX) Mediation: Framework

Abstract

 This document describes a framework for IP Flow Information Export
 (IPFIX) Mediation.  This framework extends the IPFIX reference model
 specified in RFC 5470 by defining the IPFIX Mediator components.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6183.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must

Kobayashi, et al. Informational [Page 1] RFC 6183 IPFIX Mediation: Framework April 2011

 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
 2. Terminology and Definitions .....................................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

Kobayashi, et al. Informational [Page 2] RFC 6183 IPFIX Mediation: Framework April 2011

1. Introduction

 The IP Flow Information Export (IPFIX) architectural components in
 [RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating
 using the IPFIX protocol.  Due to the sustained growth of IP traffic
 in heterogeneous network environments, this Exporter-Collector
 architecture may lead to scalability problems.  In addition, it does
 not provide the flexibility required by a wide variety of measurement
 applications.  A detailed descriptions of these problems is given in
 [RFC5982].
 To fulfill application requirements with limited system resources,
 the IPFIX architecture needs to introduce an intermediate entity
 between Exporters and Collectors.  From a data manipulation point of
 view, this intermediate entity may provide the aggregation,
 correlation, filtering, and modification of Flow Records and/or
 Packet Sampling (PSAMP) Packet Reports to save measurement system
 resources and to perform preprocessing tasks for the Collector.  From
 a protocol conversion point of view, this intermediate entity may
 provide conversion into IPFIX, or conversion of IPFIX transport
 protocols (e.g., from UDP to the Stream Control Transmission Protocol
 (SCTP)) to improve the export reliability.
 This document introduces a generalized concept for such intermediate
 entities and describes the high-level architecture of IPFIX
 Mediation, key IPFIX Mediation architectural components, and
 characteristics of IPFIX Mediation.
 This document is structured as follows: Section 2 describes the
 terminology used in this document, Section 3 gives an IPFIX/PSAMP
 document overview, Section 4 describes a high-level reference model,
 Section 5 describes functional features related to IPFIX Mediation,
 Section 6 describes combinations of components along with some
 application examples, Section 7 describes consideration points of the
 encoding for IPFIX Message Headers, 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 in this
 document is defined in [RFC5101] and [RFC5476], respectively.  The
 IPFIX-Mediation-specific terminology used in this document is defined
 in [RFC5982].  However, as reading the problem statements document is
 not a prerequisite to reading this framework document, the
 definitions have been reproduced here along with additional
 definitions.  In this document, as in [RFC5101] and [RFC5476], the
 first letter of each IPFIX-specific and PSAMP-specific term is

Kobayashi, et al. Informational [Page 3] RFC 6183 IPFIX Mediation: Framework April 2011

 capitalized along with the IPFIX-Mediation-specific terms defined
 here.  The use of the terms "must", "should", and "may" in this
 document is informational only.
 In this document, we use the term "record stream" to mean 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 information that allows
    the identification of an individual Transport Session as defined
    in [RFC5101].  If SCTP is used as transport protocol, the
    Transport Session Information identifies the SCTP association.  If
    TCP or UDP is used as 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}.  The Transport Session Information may
    include further 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 are used in this document to describe the
 architectural entities used by IPFIX Mediation.
 Intermediate Process
    An Intermediate Process takes a record stream as its input from
    Collecting Processes, Metering Processes, IPFIX File Readers,
    other Intermediate Processes, or other record sources; performs
    some transformations on this stream based upon the content of each
    record, states maintained across multiple records, or other data
    sources; and passes the transformed record stream as its output to
    Exporting Processes, IPFIX File Writers, or other 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.

Kobayashi, et al. Informational [Page 4] RFC 6183 IPFIX Mediation: Framework April 2011

 Specific Intermediate Processes are described below.  However, this
 is not an exhaustive list.
 Intermediate Conversion Process
    An Intermediate Conversion Process is an Intermediate Process that
    transforms non-IPFIX into IPFIX or manages the relation among
    Templates and states of incoming/outgoing transport sessions in
    the case of transport protocol conversion (e.g., from UDP to
    SCTP).
 Intermediate Aggregation Process
    An Intermediate Aggregation Process is an Intermediate Process
    that aggregates records based upon a set of Flow Keys or functions
    applied to fields from the record (e.g., 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,
    or generates new records with correlated data from multiple
    records (e.g., the production of bidirectional flow records from
    unidirectional flow records).
 Intermediate Selection Process
    An Intermediate Selection Process is an Intermediate Process that
    selects records from a sequence based upon criteria-evaluated
    record values and passes only those records that match the
    criteria (e.g., filtering only records from a given network to a
    given Collector).
 Intermediate Anonymization Process
    An Intermediate Anonymization Process is an Intermediate Process
    that transforms records in order to anonymize them, to protect the
    identity of the entities described by the records (e.g., by
    applying prefix-preserving pseudonymization of IP addresses).
 IPFIX Mediator
    An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation
    by receiving a record stream from some data sources, hosting one
    or more Intermediate Processes to transform that stream, and
    exporting the transformed record stream into IPFIX Messages via an
    Exporting Process.  In the common case, an IPFIX Mediator receives

Kobayashi, et al. Informational [Page 5] RFC 6183 IPFIX Mediation: Framework April 2011

    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

 IPFIX Mediation can be applied to flow-based or packet-based
 information.  The flow-based information is encoded as IPFIX Flow
 Records by the IPFIX protocol, and the packet-based information is
 extracted by some packet selection techniques and then encoded as
 PSAMP Packet Reports by the PSAMP protocol.  Thus, this section
 describes relevant documents for both protocols.

3.1. IPFIX Documents Overview

 The IPFIX protocol [RFC5101] provides network administrators with
 access to IP Flow information.  The architecture for the export of
 measured IP Flow information from an IPFIX Exporting Process to a
 Collecting Process is defined in [RFC5470], per the requirements
 defined in [RFC3917].  The IPFIX protocol [RFC5101] specifies how
 IPFIX Data Records and Templates are carried via a number of
 transport protocols from IPFIX Exporting Processes to IPFIX
 Collecting Processes.  IPFIX has a formal description of IPFIX
 Information Elements, their names, types, and additional semantic
 information, as specified in [RFC5102].  The IPFIX Management
 Information Base is defined in [RFC5815].  Finally, [RFC5472]
 describes what types of applications can use the IPFIX protocol and
 how they can use the information provided.  Furthermore, it shows how
 the IPFIX framework relates to other architectures and frameworks.
 The storage of IPFIX Messages in a file is specified in [RFC5655].

3.2. PSAMP Documents Overview

 The framework for packet selection and reporting [RFC5474] enables
 network elements to select subsets of packets by statistical and
 other methods and to export a stream of reports on the selected
 packets to a Collector.  The set of packet selection techniques
 (Sampling and Filtering) standardized by PSAMP is described in
 [RFC5475].  The PSAMP protocol [RFC5476] specifies the export of
 packet information from a PSAMP Exporting Process to a Collector.
 Like IPFIX, PSAMP has a formal description of its Information

Kobayashi, et al. Informational [Page 6] RFC 6183 IPFIX Mediation: Framework April 2011

 Elements, their names, types, and additional semantic information.
 The PSAMP information model is defined in [RFC5477].  The PSAMP
 Management Information Base is described in [PSAMP-MIB].

4. IPFIX Mediation Reference Model

 Figure A shows the high-level IPFIX Mediation reference model as an
 extension of the IPFIX reference model presented in [RFC5470].  This
 figure covers the various possible scenarios that can exist in an
 IPFIX measurement system.
     +----------------+  +---------------+    +---------------+
     | Collector 1    |  | Collector 2   |    | Collector N   |
     |[Collecting     |  |[Collecting    |    |[Collecting    |
     |   Process(es)] |  |  Process(es)] |... |  Process(es)] |
     +----^-----------+  +---^--------^--+    +--------^------+
          |                 /          \               |
          |                /            \              |
   Flow Records     Flow Records   Flow Records   Flow Records
          |              /                \            |
   +------+-------------+------+    +------+-----------+--------+
   |IPFIX Mediator 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

Kobayashi, et al. Informational [Page 7] RFC 6183 IPFIX Mediation: Framework April 2011

 The functional components within each entity are indicated within
 brackets [].  An IPFIX Mediator receives 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.  The IPFIX
 Mediator then exports IPFIX Flow Records and/or PSAMP Packet Reports
 to one or multiple Collectors and/or other IPFIX Mediators.
 Figure B shows the basic IPFIX Mediator component model.  An IPFIX
 Mediator contains one or more Intermediate Processes and one or more
 Exporting Processes.  Typically, it also contains a Collecting
 Process but might contain 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
 However, other data sources are also possible: an IPFIX Mediator can
 receive a record stream from non-IPFIX protocols such as NetFlow
 [RFC3954] exporter(s).  This document does not make any particular
 assumption on how a record stream is transferred to an IPFIX
 Mediator.  Figure C shows the IPFIX Mediator component model in the
 case of IPFIX protocol conversion from non-IPFIX exporters.

Kobayashi, et al. Informational [Page 8] RFC 6183 IPFIX Mediation: Framework April 2011

                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
 Alternatively, an Original Exporter may provide IPFIX Mediation by
 hosting one or more Intermediate Processes.  The component model in
 Figure D adds Intermediate Process(es) to the IPFIX Device model
 illustrated in [RFC5470].  In comparison with Figures 1 or 2 in
 [RFC5470], the Intermediate Process is located between Exporting
 Process(es) and IPFIX or PSAMP Metering Process(es).

Kobayashi, et al. Informational [Page 9] RFC 6183 IPFIX Mediation: Framework April 2011

                   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
 In addition, an Intermediate Process may be collocated with an IPFIX
 File Reader and/or Writer.  Figure E shows an IPFIX Mediation
 component model with an IPFIX File Writer and/or Reader.

Kobayashi, et al. Informational [Page 10] RFC 6183 IPFIX Mediation: Framework April 2011

                 IPFIX (Data Records)
                             ^
                           ^ |
    .----------------------|-+--------------------.
   .-----------------------+---------------------.|
   |              IPFIX File Writer              |'
   '-----------------------^---------------------'
                           | |
    .----------------------|-+--------------------.
   .-----------------------+---------------------.|
   |          Intermediate Process(es)           |'
   '-----------------------^---------------------'
                           | |
    .----------------------|-+--------------------.
   .-----------------------+---------------------.|
   |              IPFIX File Reader              |'
   '-----------------------^---------------------'
                           |
                 IPFIX (Data Records)
 Figure E: IPFIX Mediation Component Model Collocated
           with IPFIX File Writer/Reader

Kobayashi, et al. Informational [Page 11] RFC 6183 IPFIX Mediation: Framework April 2011

5. IPFIX Mediation Functional Blocks

 Figure F shows a functional block diagram example in an IPFIX
 Mediator that has 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 not different from the
 Collecting Process described in [RFC5101].  Additional functions in
 an IPFIX Mediator include transmitting the set of Data Records and
 Control Information to one or more components, i.e., Intermediate
 Processes and other applications.  In other words, a Collecting
 Process may duplicate the set and transmit it to one or more
 components in sequence or in parallel.  In the case of an IPFIX

Kobayashi, et al. Informational [Page 12] RFC 6183 IPFIX Mediation: Framework April 2011

 Mediator, the Control Information described in [RFC5470] includes
 IPFIX Message Header information and Transport Session Information
 along with information about the Metering Process and the Exporting
 Process in an Original Exporter, e.g., Sampling parameters.

5.2. Exporting Process

 An Exporting Process in an IPFIX Mediator is not different from the
 Exporting Process described in [RFC5101].  Additional functions in an
 IPFIX Mediator may include the following:
 o  Receiving the trigger to transmit the Template Withdrawal Messages
    from Intermediate Process(es) when relevant Templates become
    invalid due to, for example, incoming session failure.
 o  Transmitting the origin (e.g., Observation Point, Observation
    Domain ID, Original Exporter IP address, etc.) of the data in
    additional Data Record fields or additional Data Records.  The
    parameters that represent the origin should be configurable.

5.3. Intermediate Process

 An Intermediate Process is a key functional block for IPFIX
 Mediation.  Its typical functions include the following:
 o  Generating a new record stream from an input record stream
    including context information (e.g., Observation Domain ID and
    Transport Session Information) and transmitting it to other
    components.
 o  Reporting statistics and interpretations for IPFIX Metering
    Processes, PSAMP Metering Processes, and Exporting Processes from
    an Original Exporter.  See Section 4 of [RFC5101] and Section 6 of
    [RFC5476] for relevant statistics data structures and
    interpretations, respectively.  Activation of this function should
    be configurable.
 o  Maintaining the configurable relation between Collecting
    Process(es)/Metering Process(es) and Exporting Process(es)/other
    Intermediate Process(es).
 o  Maintaining database(s) of Data Records in the case of an
    Intermediate Aggregation Process and an Intermediate Correlation
    Process.  The function has the Data Record expiration rules
    described in the next subsection.
 o  Maintaining statistics on the Intermediate Process itself, such as
    the number of input/output Data Records, etc.

Kobayashi, et al. Informational [Page 13] RFC 6183 IPFIX Mediation: Framework April 2011

 o  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 Intermediate Correlation
 Process need to have expiration conditions to export cached Data
 Records.  In the case of the Metering Process in an Original
 Exporter, these conditions are described in [RFC5470].  In the case
 of the Intermediate Process, these conditions are as follows:
 o  If there are no input Data Records belonging to a cached Flow for
    a certain time period, aggregated Flow Records will expire.  This
    time period should be configurable at the Intermediate Process.
 o  If the Intermediate Process experiences resource constraints
    (e.g., lack of memory to store Flow Records), aggregated Flow
    Records may prematurely expire.
 o  For long-running Flows, the Intermediate Process should cause the
    Flow to expire on a regular basis or on the basis of an expiration
    policy.  This periodicity or expiration policy should be
    configurable at the Intermediate Process.
 In the case of an Intermediate Correlation Process, a cached Data
 Record may be prematurely expired (and discarded) when no correlation
 can be computed with newly received Data Records.  For example, an
 Intermediate Correlation Process computing one-way delay may discard
 the cached Packet Report when no other matching Packet Report are
 observed within a certain time period.

5.3.2. Specific Intermediate Processes

 This section describes the functional blocks of specific Intermediate
 Processes.

Kobayashi, et al. Informational [Page 14] RFC 6183 IPFIX Mediation: Framework April 2011

5.3.2.1. Intermediate Conversion Process

 When receiving a non-IPFIX record stream, the Intermediate Conversion
 Process covers the following functions:
 o  Determining the IPFIX Information Element identifiers that
    correspond to the fields of the non-IPFIX records (e.g.,
    converting the NetFlow V9 protocol [RFC3954] to the IPFIX
    Information Model [RFC5102]).
 o  Transforming the non-IPFIX records into Data Records, (Options)
    Template Records, and/or Data Records defined by Options
    Templates.
 o  Converting additional information (e.g., sampling rate, sampling
    algorithm, and observation information) into appropriate fields in
    the existing Data Records or into Data Records defined by new
    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:
 o  Relaying Data Records, (Options) Template Records, and Data
    Records defined by Options Templates.
 o  Setting the trigger for the Exporting Process in order to export
    IPFIX Template Withdrawal Messages relevant to the Templates when
    Templates becomes invalid due to, for example, incoming session
    failure.  This case applies to SCTP and TCP Transport Sessions on
    the outgoing side only.
 o  Maintaining the mapping information about Transport Sessions,
    Observation Domain IDs, and Template IDs on the incoming and
    outgoing sides 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.

Kobayashi, et al. Informational [Page 15] RFC 6183 IPFIX Mediation: Framework April 2011

 The typical function is property match filtering that retrieves a
 record stream of interest.  The function selects a Data Record if the
 value of a specific field in the Data Record equals a configured
 value or falls within a configured range.

5.3.2.3. Intermediate Aggregation Process

 An Intermediate Aggregation Process covers the following functions:
 o  Merging a set of Data Records within a certain time period into
    one Flow Record by summing up the counters where appropriate.
 o  Maintaining 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.
 o  Aggregation of Data Records, which can be done in the following
    ways:
  • Spatial composition
       With spatial composition, Data Records sharing common
       properties are merged into one Flow Record within a certain
       time period.  One typical aggregation can be based on a new set
       of Flow Keys.  Generally, a 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.

Kobayashi, et al. Informational [Page 16] RFC 6183 IPFIX Mediation: Framework April 2011

       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

 An Intermediate Anonymization Process covers the following typical
 functions:
 o  Deleting specified fields
    The function deletes existing fields in accordance with some
    instruction rules.  Examples include hiding network topology
    information and private information.  In the case of feeding Data
    Records to end customers, disclosing vulnerabilities is avoided by
    deleting fields, e.g., "ipNextHopIP{v4|v6}Address",
    "bgpNextHopIP{v4|v6}Address", "bgp{Next|Prev}AdjacentAsNumber",
    and "mplsLabelStackSection", as described in [RFC5102].

Kobayashi, et al. Informational [Page 17] RFC 6183 IPFIX Mediation: Framework April 2011

 o  Anonymizing values of specified fields
    The function modifies the values of specified fields.  Examples
    include anonymizing customers' private information, such as IP
    address and port number, in accordance with a privacy protection
    policy.  The Intermediate Anonymization Process may also report
    anonymized fields and the anonymization method as additional
    information.

5.3.2.5. Intermediate Correlation Process

 An Intermediate Correlation Process can be viewed as a special case
 of the Intermediate Aggregation Process, covering the following
 typical functions:
 o  Producing new information including metrics, counters, attributes,
    or packet property parameters by evaluating the correlation among
    sets of Data Records or among Data Records and other meta data
    after gathering sets of Data Records within a certain time period.
 o  Adding new fields into a Data Record or creating a new Data
    Record.
 A correlation of Data Records can be done in the following ways,
 which can be implemented individually or in combinations.
 o  One-to-one correlation between Data Records, with the following
    examples:
  • One-way delay, Packet delay variation in [RFC5481]

The metrics come from the correlation of the timestamp value on

       a pair of Packet Reports indicating an identical packet 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.

Kobayashi, et al. Informational [Page 18] RFC 6183 IPFIX Mediation: Framework April 2011

 o  Correlation amongst Data Records, with the following examples:
  • Bidirectional Flow composition

The method of exporting and representing a Bidirectional Flow

       (Biflow) is described in [RFC5103].  The Bidirectional Flow
       composition is a special case of Flow Key aggregation.  The
       Flow Records are merged into one Flow Record as Biflow if Non-
       directional Key Fields 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.
 o  Correlation between Data Record and other meta data
    Typical examples are derived packet property parameters described
    in [RFC5102].  The parameters are retrieved based on the value of
    the specified field in an input Data Record, compensating for
    traditional exporting devices or probes that are unable to add
    packet property parameters.  Typical derived packet property
    parameters are as follows:
  • "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102]

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.

Kobayashi, et al. Informational [Page 19] RFC 6183 IPFIX Mediation: Framework April 2011

6. Component Combination

 An IPFIX Mediator may be able to simultaneously support more than one
 Intermediate Process.  Multiple Intermediate Processes generally are
 configured in the following ways.
 o  Parallel Intermediate Processes
    A record stream is processed by multiple Intermediate Processes in
    parallel to fulfill the requirements of different applications.
    In this setup, every Intermediate Process receives a copy of the
    entire record stream as its input.
 o  Serial Intermediate Processes
    To execute flexible manipulation of a record stream, the
    Intermediate Processes are connected serially.  In that case, an
    output record stream from one Intermediate Process forms an input
    record stream for a succeeding Intermediate Process.
 In addition to the combination of Intermediate Processes, the
 combination of some components (Exporting Process, Collecting
 Process, IPFIX File Writer and Reader) can be applied to provide
 various data reduction techniques.  This section shows some
 combinations along with examples.

6.1. Data-Based Collector Selection

 The combination of one or more Intermediate Selection Processes and
 Exporting Processes can determine to which Collector input Data
 Records are exported.  Applicable examples include exporting Data
 Records to a dedicated Collector on the basis of a customer or an
 organization.  For example, an Intermediate Selection Process selects
 Data Records from 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.

Kobayashi, et al. Informational [Page 20] RFC 6183 IPFIX Mediation: Framework April 2011

           .----------------------.   .------------.
           | Intermediate         |   | Exporting  |
           |  Selection Process 1 |   |  Process 1 |
        +--+--- Peering AS #10 ---+-->|            +--> Collector 1
        |  '----------------------'   '------------'
        |  .----------------------.   .------------.
 record |  | Intermediate         |   | Exporting  |
 stream |  |  Selection Process 2 |   |  Process 2 |
 -------+--+--- Peering AS #20 ---+-->|            +--> Collector 2
        |  '----------------------'   '------------'
        |  .----------------------.   .------------.
        |  | Intermediate         |   | Exporting  |
        |  |  Selection Process 3 |   |  Process 3 |
        +--+--- Peering AS #30 ---+-->|            +--> Collector 3
           '----------------------'   '------------'
           Figure G: Data-Based Collector Selection

6.2. Flow Selection and Aggregation

 The combination of one or more Intermediate Selection Processes and
 Intermediate Aggregation Processes can efficiently reduce the amount
 of Flow Records.  The combination structure is similar to the concept
 of the Composite Selector described in [RFC5474].  For example, an
 Intermediate Selection Process selects Flows consisting of a small
 number of packets and then transmits them to an Intermediate
 Aggregation Process.  Another Intermediate Selection Process selects
 other Flow Records and then transmits them to an Exporting Process,
 as shown in Figure H.  This results in aggregation on the basis of
 the distribution of the number of packets per Flow.
          .------------------.  .--------------.  .------------.
          | Intermediate     |  | Intermediate |  | Exporting  |
          |   Selection      |  |  Aggregation |  |    Process |
          |        Process 1 |  |     Process  |  |            |
        +-+ packetDeltaCount +->|              +->|            |
        | |             <= 5 |  |              |  |            |
 record | '------------------'  '--------------'  |            |
 stream | .------------------.                    |            |
 -------+ | Intermediate     |                    |            |
        | |   Selection      |                    |            |
        | |        Process 2 |                    |            |
        +-+ packetDeltaCount +------------------->|            |
          |              > 5 |                    |            |
          '------------------'                    '------------'
        Figure H: Flow Selection and Aggregation Example

Kobayashi, et al. Informational [Page 21] RFC 6183 IPFIX Mediation: Framework April 2011

6.3. IPFIX File Writer/Reader

 An IPFIX File Writer [RFC5655] stores Data Records in a file system.
 When Data Records include problematic Information Elements, an
 Intermediate Anonymization Process can delete these fields before the
 IPFIX File Writer handles them, as shown in Figure I.
        .---------------.  .---------------.  .-------------.
        | Collecting    |  | Intermediate  |  | IPFIX       |
  IPFIX |      Process  |  | Anonymization |  |   File      |
  ----->|               +->|       Process +->|      Writer |
        '---------------'  '---------------'  '-------------'
    Figure I: IPFIX Mediation Example with IPFIX File Writer
 In contrast, an IPFIX File Reader [RFC5655] retrieves stored Data
 Records when administrators want to retrieve past Data Records from a
 given time period.  If the data structure of the Data Records from
 the IPFIX File Reader is different from what administrators want, an
 Intermediate Anonymization Process and Intermediate Correlation
 Process can modify the data structure, as shown in Figure J.
  .-------------.  .---------------.  .---------------.  .-----------.
  | IPFIX       |  | Intermediate  |  | Intermediate  |  | Exporting |
  |   File      |  | Anonymization |  |   Correlation |  |   Process |
  |      Reader +->|       Process +->|       Process +->|           |
  '-------------'  '---------------'  '---------------'  '-----------'
    Figure J: IPFIX Mediation Example with IPFIX File Reader
 In the case where distributed IPFIX Mediators enable on-demand export
 of Data Records that have been previously stored by a File Writer, a
 collecting infrastructure with huge storage capacity for data
 retention can be set up.

7. Encoding for IPFIX Message Header

 The IPFIX Message Header [RFC5101] includes Export Time, Sequence
 Number, and Observation Domain ID fields.  This section describes
 some consideration points for the IPFIX Message Header encoding in
 the context of IPFIX Mediation.
 Export Time
    An IPFIX Mediator can set the Export Time in two ways.
  • Case 1: keeping the field value of incoming Transport Sessions

Kobayashi, et al. Informational [Page 22] RFC 6183 IPFIX Mediation: Framework April 2011

  • 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.  In
    contrast 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.
    The information contains the IP addresses and Observation Domain
    IDs used by the Original Exporters and some information about the
    Transport Session, for example, the source port number, so that
    different Exporting Processes on the same Original Exporter can be
    identified.  As far as privacy policy permits, an IPFIX Mediator
    reports the 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 the set of Original Exporters.  The Common Properties

Kobayashi, et al. Informational [Page 23] RFC 6183 IPFIX Mediation: Framework April 2011

    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 Intermediate Processes type,
 potentially Information Elements such as:
 o  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.
 o  Report on the applied IPFIX Mediation functions as described in
    Section 6.7. in [RFC5982].
 o  Certificate of an Original Exporter in Section 9.  The Information
    Element exporterCertificate in [RFC5655] may be utilized for this
    purpose.

9. Security Considerations

 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.  In addition, there are a few specific
 considerations that IPFIX Mediator implementations must take into
 account.
 By design, IPFIX Mediators are "men-in-the-middle": they intercede in
 the communication between an Original Exporter (or another upstream
 Mediator) and a downstream Collecting Process.  TLS provides no way
 to connect the session between the Mediator and the Original Exporter
 to the session between the Mediator and the downstream Collecting
 Process; indeed, this is by design.  This has important implications
 for the level of confidentiality provided across an IPFIX Mediator
 and the ability to protect data integrity and Original Exporter
 authenticity across a Mediator.  In general, a Mediator should
 maintain the same level of integrity and confidentiality protection
 on both sides of the mediation operation, except in situations where
 the Mediator is explicitly deployed as a gateway between trusted and
 untrusted networks.

Kobayashi, et al. Informational [Page 24] RFC 6183 IPFIX Mediation: Framework April 2011

 Subsequent subsections deal with 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 that then
 exports IPFIX Messages derived therefrom in cleartext is a
 potentially serious vulnerability in an IPFIX infrastructure.  The
 concern here is that confidentiality protection may be lost across a
 Mediator.
 Therefore, an IPFIX Mediator that receives IPFIX Messages from an
 upstream Exporting Process protected using TLS or DTLS must provide
 for sending of IPFIX Messages resulting from the operation of the
 Intermediate Process(es) to a downstream Collecting Process using TLS
 or DTLS 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 is a similar problem in the opposite direction: as an IPFIX
 Mediator's signature on a TLS session to a downstream Collecting
 Process acts as an implicit assertion of the trustworthiness of the
 data within the session, a poorly deployed IPFIX Mediator could be
 used to "legitimize" records derived from untrusted sources.
 Unprotected sessions from the Original Exporter are generally
 untrusted, because they could have been tampered with or forged by an
 unauthorized third party.  The concern here 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

Kobayashi, et al. Informational [Page 25] RFC 6183 IPFIX Mediation: Framework April 2011

 external (untrusted) network and when the path from the Original
 Exporter is protected using some other method and 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

 Because the Transport Session between an IPFIX Mediator and an
 Original Exporter is independent from the Transport Session between
 the Mediator and the downstream Collecting Process, there is no
 existing method via TLS to assert the identity of the original
 Exporting Process downstream.  However, an IPFIX Mediator, which
 modifies the stream of IPFIX Messages sent to it, is by definition a
 trusted entity in the infrastructure.  Therefore, the IPFIX
 Mediator's signature on an outgoing Transport Session can be treated
 as an implicit assertion that the Original Exporter was positively
 identified by the Mediator and that the source information it
 received was trustworthy.  However, as noted in the previous section,
 IPFIX Mediators must in this circumstance take care not to provide an
 inappropriate upgrade of trust.
 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 and, as such, must protect the
 Transport Session to the downstream Collector using TLS or DTLS as
 well.

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.  Though the details of this are
 application-specific, this generally entails separating Transport

Kobayashi, et al. Informational [Page 26] RFC 6183 IPFIX Mediation: Framework April 2011

 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.

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.

Kobayashi, et al. Informational [Page 27] RFC 6183 IPFIX Mediation: Framework April 2011

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

Kobayashi, et al. Informational [Page 28] RFC 6183 IPFIX Mediation: Framework April 2011

11. Acknowledgements

 We would like to thank the following persons: 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; 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

Kobayashi, et al. Informational [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6183.txt · Last modified: 2011/04/05 00:14 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki