summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6183.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6183.txt')
-rw-r--r--doc/rfc/rfc6183.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc6183.txt b/doc/rfc/rfc6183.txt
new file mode 100644
index 0000000..7a0a1e2
--- /dev/null
+++ b/doc/rfc/rfc6183.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+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]
+