IPFIX Working Group B. Claise
Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track A. Kobayashi
Expires: October 7, 2010 NTT PF Lab.
B. Trammell
Hitachi Europe
March 7, 2010
Specification of the Protocol for IPFIX Mediations
draft-claise-ipfix-mediation-protocol-01
Abstract
This document specifies the IP Flow Information Export
(IPFIX) protocol specific to the Mediation.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
<Claise, et. Al> Expires October 7 2010 [Page 1]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
respect to this document. Code Components extracted from this
document must 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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction................................................3
1.1. IPFIX Documents Overview...............................4
1.2. Relationship with IPFIX and PSAMP......................4
2. Terminology.................................................5
3. Specifications..............................................7
3.1. Encoding of IPFIX Message Header.......................7
3.2. Template Management....................................9
3.2.1. Template Management Without Template Record Change9
3.2.2. Template Management With Template Record Change..10
3.3. Time Management.......................................10
3.4. Observation Point Management..........................11
3.4.1. Observation Domain Management....................12
3.5. Specific Reporting Requirements.......................12
3.5.1. The Flow Keys Options Template...................13
3.5.2. IPFIX Protocol Options Template..................13
3.5.3. IPFIX Mediator Options Template..................13
3.5.4. The Flow Key List Options Template...............14
3.6. Transport Session Management..........................14
3.7. The Collecting Process's Side.........................15
3.8. Sampling Management...................................15
3.9. Filtering Management..................................16
4. New Intermediate Function..................................16
5. New Information Elements...................................16
6. Security Considerations....................................16
6.1. Avoiding Security Downgrade...........................17
6.2. End-to-End Assertions for Mediators...................17
7. IANA Considerations........................................18
8. References.................................................18
8.1. Normative References..................................18
8.2. Informative References................................19
<Claise, et. Al> Expires October 8, 2010 [Page 2]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
9. Author's Addresses.........................................20
TO DO
- This draft is basically a starting point: multiple open issues
must be discussed throughout the draft
- What should we export in terms of Original Exporter? A
specific Options Template?
- Should we export the aggregation function for an IPFIX
Concentrator?
- Do we want to have an aggregate observation point?
- Review the problem statement, section 6 "IPFIX Mediators
Implementation Specific Problems" to see if we covered all
problems
- See the EDITOR'S NOTE within the document
1. Introduction
The IPFIX architectural components in [RFC5470] consist of
IPFIX Devices and IPFIX Collectors communicating using the
IPFIX protocol [RFC5101], which specifies how to export IP
Flow information. This protocol is designed to export
information about IP traffic Flows and related measurement
data, where a Flow is defined by a set of key attributes
(e.g. source and destination IP address, source and
destination port, etc.).
However, thanks to its Template mechanism, the IPFIX protocol
can export any type of information, as long as the relevant
Information Element is specified in the IPFIX Information
Model [RFC5102], registered with IANA, or specified as an
enterprise-specific Information Element.The specifications in
the IPFIX protocol [RFC5101] have not been defined in the
context of an IPFIX Mediator
receiving/aggregating/correlating/anonymizing/etc... Flow
Records from the one or multiple Exporters. Indeed, the
IPFIX protocol must be adapted for Intermediate Processes, as
defined in the IPFIX Mediation Reference Model (Figure A of
[IPFIX-MED-FMWK], which is based on the IPFIX Mediation
Problem Statement [IPFIX-MED-PS].
This document specifies the IP Flow Information Export
(IPFIX) protocol specific to the IPFIX Mediator. These
specifications are based on the IPFIX protocol
<Claise, et. Al> Expires October 8, 2010 [Page 3]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
specifications but adapted according to the IPFIX Mediation
Framework [IPFIX-MED-FMWK].
1.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 out of an IPFIX Exporting Process to a Collecting
Process is defined in the IPFIX Architecture [RFC5470], per
the requirements defined in RFC 3917 [RFC3917].
The IPFIX Architecture [RFC5470] specifies how IPFIX Data
Records and Templates are carried via a congestion-aware
transport protocol from IPFIX Exporting Processes to IPFIX
Collecting Processes.
IPFIX has a formal description of IPFIX Information Elements,
their name, type and additional semantic information, as
specified in the IPFIX Information Model [RFC5102].
The IPFIX Applicability Statement [RFC5472] describes what
type of applications can use the IPFIX protocol and how they
can use the information provided. It furthermore shows how
the IPFIX framework relates to other architectures and
frameworks.
"IPFIX Mediation: Problem Statement" [IPFIX-MED-PS], describing
the IPFIX Mediation applicability examples, along with some
problems that network administrators have been facing, is the
basis for the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].
This framework details the IPFIX Mediation reference model and
the components of an IPFIX Mediator.
1.2. Relationship with IPFIX and PSAMP
The specification in this document applies to the IPFIX
protocol specifications [RFC5101]. All specifications from
[RFC5101] apply unless specified otherwise in this document.
As the Packet Sampling (PSAMP) protocol specifications
[RFC5476] are based on the IPFIX protocol specifications, the
specifications in this document are also valid for the PSAMP
<Claise, et. Al> Expires October 8, 2010 [Page 4]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
protocol. Therefore, the method specified by this document
also applies to PSAMP.
2. Terminology
The IPFIX-specific and PSAMP-specific terminology used in this
document is defined in [RFC5101] and [RFC5476], respectively.
The IPFIX Mediation-specific terminology used in this document
is defined in [IPFIX-MED-PS], and reuse in [IPFIX-MED-FMWK].
However, as reading the problem statements document is not a
prerequisite to reading this framework document, the definitions
have been reproduced here along with additional definitions. In
this document, as in [RFC5101] and [RFC5476], the first letter
of each IPFIX-specific and PSAMP-specific term is capitalized
along with the IPFIX Mediation-specific term defined here.
In this document, we call "record stream" a stream of records
carrying flow- or packet-based information. The records may be
encoded as IPFIX Data Records in any other format.
Transport Session Information
The Transport Session is specified in [RFC5101]. In SCTP, the
Transport Session Information is the SCTP association. In TCP
and UDP, the Transport Session Information corresponds to a 5-
tuple {Exporter IP address, Collector IP address, Exporter
transport port, Collector transport port, transport protocol}.
Original Exporter
An Original Exporter is an IPFIX Device that hosts the
Observation Points where the metered IP packets are observed.
IPFIX Mediation
IPFIX Mediation is the manipulation and conversion of a record
stream for subsequent export using the IPFIX protocol.
The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.
Intermediate Process
An Intermediate Process takes a record stream as its input
from Collecting Processes, Metering Processes, IPFIX File
Readers, other Intermediate Processes, or other record
<Claise, et. Al> Expires October 8, 2010 [Page 5]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
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.
Specific Intermediate Processes are described below. However,
this is not an exhaustive list.
Intermediate Conversion Process
An Intermediate Conversion Process is an Intermediate Process
that transforms non-IPFIX into IPFIX, or manages the relation
among Templates and states of incoming/outgoing transport
sessions in the case of transport protocol conversion (e.g.,
from UDP to SCTP).
Intermediate Aggregation Process
An Intermediate Aggregation Process is an Intermediate Process
that aggregates records based upon a set of Flow Keys or
functions applied to fields from the record (e.g., binning and
subnet aggregation).
Intermediate Correlation Process
An Intermediate Correlation Process is an Intermediate Process
that adds information to records, noting correlations among
them, or generates new records with correlated data from
multiple records (e.g., the production of bidirectional flow
records from unidirectional flow records).
Intermediate Selection Process
An Intermediate Selection Process is an Intermediate Process
that selects records from a sequence based upon criteria-
evaluated record values and passes only those records that
match the criteria (e.g., filtering only records from a given
network to a given Collector).
Intermediate Anonymization Process
<Claise, et. Al> Expires October 8, 2010 [Page 6]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
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 a record stream from a Collecting
Process, but it could also receive a record stream from data
sources not encoded using IPFIX, e.g., in the case of
conversion from the NetFlow V9 protocol [RFC3954] to IPFIX
protocol.
3. Specifications
This section describes the IPFIX specifications for Mediation.
These new specifications, which are more specific compared to
[RFC5101], are described with the key words described in
[RFC2119].
3.1. Encoding of IPFIX Message Header
The format of the IPFIX Message Header is shown in Figure A.
Note that the format is similar to the IPFIX Message in
[RFC5101], but some field definitions (for the example, the
Export Time) have been updated in the context of the IPFIX
Mediator.
<Claise, et. Al> Expires October 8, 2010 [Page 7]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A: IPFIX Message Header format
Message Header Field Descriptions
Version
Version of Flow Record format exported in this message.
The value of this field is 0x000a for the current
version, incrementing by one the version used in the
NetFlow services export version 9 [RFC3954].
Length
Total length of the IPFIX Message, measured in octets,
including Message Header and Set(s).
Export Time
Time in seconds since 0000 UTC Jan 1st 1970, at which
the IPFIX Message Header leaves the IPFIX Mediator.
Sequence Number
Incremental sequence counter modulo 2^32 of all IPFIX
Data Records sent on this PR-SCTP stream from the
current Observation Domain by the Exporting Process.
Check the specific meaning of this field in the sub-
sections of section 10 when UDP or TCP is selected as
the transport protocol. This value SHOULD be used by
the Collecting Process to identify whether any IPFIX
Data Records have been missed. Template and Options
Template Records do not increase the Sequence Number.
<Claise, et. Al> Expires October 8, 2010 [Page 8]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
Observation Domain ID
A 32-bit identifier of the Observation Domain that is
locally unique to the Exporting Process. The Exporting
Process uses the Observation Domain ID to uniquely
identify to the Collecting Process the Observation
Domain that metered the Flows. It is RECOMMENDED that
this identifier is also unique per IPFIX
Device. Collecting Processes SHOULD use the Transport
Session and the Observation Domain ID field to separate
different export streams originating from the same
Exporting Process. The Observation Domain ID SHOULD be
0 when no specific Observation Domain ID is relevant for
the entire IPFIX Message. For example, when exporting
the Exporting Process Statistics, or in case of
hierarchy of Collector when aggregated data records are
exported.
EDITOR'S NOTE: make the link with section 3.4.1.
3.2. Template Management
3.2.1. Template Management Without Template Record Change
The first case is a situation where the IPFIX Mediator,
typically an IPFIX Distributor, relays an (Options) Template
without changing its content.
As in [RFC5101], the Template IDs are unique per Exporter, per
Transport Session, and per Observation Domain. As there is no
guarantee that, for similar Template Records, the Template IDs
received on the incoming Transport Session and exported to the
outgoing Transport Session would be same, the IPFIX Mediator
MUST maintain a mapping database between received and exported
(Options) Template Records:
- for each Received (Options) Template Record: Template Record
Flow Keys and non Flow Keys, Template ID, Original Exporter,
Observation Domain, and Transport Session
- for each Exported (Options) Template Record: Template Record
Flow Keys and non Flow Keys, Template ID, Collector,
Observation Domain, and Transport Session
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
(Options) Template Record that is not used anymore in any
outgoing Transport Sessions, the IPFIX Mediator SHOULD export he
<Claise, et. Al> Expires October 8, 2010 [Page 9]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
appropriate IPFIX Withdrawal Message(s) on the outgoing
Transport Session, and remove the corresponding entry in its
mapping database.
If a (Options) Template Record is not used anymore in outgoing
Transport Session, it MUST be withdrawn with an IPFIX Template
Withdrawal Message on that specific outgoing Transport Session,
and remove the corresponding entry in its mapping database.
If an incoming Transport Session is gracefully shutdown or
reset, the (Options) Template Records corresponding to that
Transport Session MUST be removed from the mapping database.
3.2.2. Template Management With Template Record Change
The second case is a situation where the IPFIX Mediator,
typically an IPFIX Concentrator or an IPFIX Masquerading Proxy,
generates new (Options) Template compared to what it receives
from the Original Exporters.
EDITOR'S NOTE: to be completed. This is slightly more complex as
we have to introduce the notion of derived (Options) Template
Records.
3.3. Time Management
The IPFIX Message Header "Export Time" field is the time in
seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message
Header leaves the IPFIX Mediator. However, in the specific case
of an IPFIX Mediator containing an Intermediate Conversion
Process, the IPFIX Mediator MAY keep the export time received
from the incoming Transport Session.
It is RECOMMENDED that Mediators handle time using absolute
timestamps (e.g. flowStartSeconds, flowStartMilliseconds,
flowStartNanoseconds), which are specified relative to the UNIX
epoch (00:00 UTC 1 Jan 1970), where possible, rather than
relative timestamps (e.g. flowStartSysUpTime,
flowStartDeltaMicroseconds), which are specified relative to
protocol structures such as system initialization or message
export time.
<Claise, et. Al> Expires October 8, 2010 [Page 10]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
The latter are difficult to manage for two reasons. First, they
require constant translation, as the system initialization time
of an intermediate system and the export time of an intermediate
message will change across mediation operations. Further,
relative timestamps introduce range problems.
For example, when using the flowStartDeltaMicroseconds and
flowEndDeltaMicroseconds Information Elements [RFC5102], the
Data Record must be exported within a maximum of 71 minutes
after its creation. Otherwise, the 32-bit counter would not be
sufficient to contain the flow start time offset. Those time
constraints might be incompatible with some of the Intermediate
Processes: Intermediate Aggregation Process (temporal) and
Intermediate Correlation Process, for example.
When an Intermediate Aggregation Process aggregates information
from different Flow Records, the typical reporting times are the
minimum of the start times and the maximum of the end times.
However, if the Flow Records do not overlap, i.e. if there is a
time gap between the times in the Flow Records, then the report
may be inaccurate. The IPFIX Mediator is only reporting what it
knows, on the basis of the information made available to it -
and there may not have been any data to observe during the gap.
Then again, if there is an overlap in timestamps, there's the
potential of double-accounting: different Observation Points may
have observed the same traffic simultaneously. Therefore, as
there is not a single rule that fits all different situations,
the precise rules of applying the Flow Record timestamps in
IPFIX Mediators is out of the scope of this document.
3.4. Observation Point Management
Generally, top Collector needs to be able to distinguish the
real original Exporters, otherwise it may wrongly conclude that
the IPFIX Mediator contains the Observation Point(s) where the
Flow Records were observed. A new Information Element
originalExporterIPaddress is introduced.
When an IPFIX Mediator exports the originalExporterIPaddress, it
needs to export other information indicating that an IPFIX
Mediator certificates the original exporter IP address.
ExporterCertificate in [RFC5655] can be used in that case. And
also, another Information Element indicating that certifies that
an IPFIX Mediator is required, just like mediatorCertificate.
<Claise, et. Al> Expires October 8, 2010 [Page 11]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
EDITOR'S NOTE: Do we want a structure data representing the list
of all observation points in case of an Intermediate Aggregation
Process?
3.4.1. Observation Domain Management
When mixing Data Records from multiple IPFIX Messages received
from multiple Observation Domains, or generating new Data
Records from the result of some intermediate function on Data
Records from multiple IPFIX Messages received from multiple
Observation Domains, a Mediator MUST assign a new Observation
Domain ID for the exported IPFIX Messages. This Observation
Domain ID is unique per Intermediate Process instance. This is
consistent with the preservation guideline above, as in most if
not all such circumstances, the IPFIX Mediator will be
generating new Templates itself as a consequence of the
mediation being performed.
If the IPFIX Mediator must export information about the original
Exporter IP address and the original Observation Domain Id
(typically a router line card), the IPFIX Mediator MUST include
the orginalExporterIPAddress and originalObservationDomainId
Information Elements in the Flow Records.
3.5. Specific Reporting Requirements
Some specific Options Templates and Options Template Records are
necessary to provide extra information about the Flow Records
and about the Metering Process.
The Option Template and Options Template Records defined in
these subsections, which impose some constraints on the Metering
Process and Exporting Process implementations, MAY be
implemented. If implemented, the specific Option Templates
SHOULD be implemented as specified in these subsections.
The minimum set of Information Elements is always specified in
these Specific IPFIX Options Templates. Nevertheless, extra
Information Elements may be used in these specific Options
Templates.
<Claise, et. Al> Expires October 8, 2010 [Page 12]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
3.5.1. The Flow Keys Options Template
Exactly like the IPFIX protocol [RFC5101], the Flow Keys Option
Template specifies the structure of a Data Record for reporting
the Flow Keys of reported Flows. A Flow Keys Data Record
extends a particular Template Record that is referenced by its
templateId identifier. The Template Record is extended by
specifying which of the Information Elements contained in the
corresponding Data Records describe Flow properties that serve
as Flow Keys of the reported Flow.
The Flow Keys Option Template SHOULD contain the following
Information Elements that are defined in [RFC5102]
templateId An identifier of a Template. This
Information Element MUST be defined
as a Scope Field.
flowKeyIndicator Bitmap with the positions of the Flow
Keys in the Data Records.
When any Intermediate Process changes the Flow Keys, the Flow
Keys Option Template MUST include the new set of Flow Keys.
Typically, an Intermediate Aggregation Process keeps or reduces
the number of Flow Keys
3.5.2. IPFIX Protocol Options Template
The "Metering Process Statistics Options Template", "The
Metering Process Reliability Statistics Options Template", and
"The Exporting Process Reliability Statistics Options Template",
as specified in [RFC5101], SHOULD be implemented on the IFPIX
Mediator.
3.5.3. IPFIX Mediator Options Template
EDITOR'S NOTE: we don't think we need a specific Options
Template for the IPFIX Mediator; instead, each mediation
function which has some useful metadata (for example, [IPFIX-
ANON] should define its own Options Template Record(s). They
should simply all look like each others.
For example, a specification of IPFIX flow anonymisation
including an Options Template for the export of metadata about
anonymised flows is described in [IPFIX-ANON]; when anonymising
Flows Records, IPFIX Mediators SHOULD add the Options Template
specified therein to annotate the exported data.
<Claise, et. Al> Expires October 8, 2010 [Page 13]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
3.5.4. The Flow Key List Options Template
EDITOR'S NOTE: TO BE DISCUSSED
Even when an IPFIX Mediator aggregates original Flow Records,
IPFIX Collector needs to know the number of original Flow
Records. In that case, an IPFIX Mediator needs to export this
data. However, the term of Flows in IPFIX means all of Flow
Records even if they have different Flow Keys. Therefore,
another method presenting Flow Keys rather than bit map is
required.
(I propose) The following Options Template using basicList in
draft-ietf-ipfix-structured-data-00 can be applied.
- flows as a scope
- basicList
The basicList contains the informationElementId list indicating
Flow Keys. Thus, the following IE also needs to be defined.
- Flows
This information indicates the number of original Flow Records.
When using this IEs, set of Flow keys SHOULD be presented in
Flow Key List Options Template. However, when an IPFIX Mediator
aggregates original Flow Records that have different Flow Keys,
the IPFIX Mediator cannot export "Flows".
3.6. Transport Session Management
SCTP [RFC4960] using the PR-SCTP extension specified in
[RFC3758] MUST be implemented by all compliant IPFIX Mediator
implementations. UDP [UDP] MAY also be implemented by compliant
IPFIX Mediator implementations. TCP [TCP] MAY also be
implemented by IPFIX Mediator compliant implementations.
PR-SCTP SHOULD be used in deployments where IPFIX Mediators and
Collectors are communicating over links that are susceptible to
congestion. PR-SCTP is capable of providing any required degree
of reliability.
TCP MAY be used in deployments where IPFIX Mediators and
Collectors communicate over links that are susceptible to
congestion, but PR-SCTP is preferred due to its ability to limit
<Claise, et. Al> Expires October 8, 2010 [Page 14]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
back pressure on Exporters and its message versus stream
orientation.
UDP MAY be used, although it is not a congestion-aware protocol.
However, the IPFIX traffic between IPFIX Mediator and Collector
MUST run in an environment where IPFIX traffic has been
provisioned for, or is contained through some other means.
3.7. The Collecting Process's Side
If we change something on the protocol, the Collecting Process
must be able to support it.
For example, if we impose that the new O.P. is a structured data
composed of different remote O.P., then the C.P. must support
structured data.
EDITOR'S NOTE: to be completed
3.8. Sampling Management
EDITOR'S NOTE: What about the accuracy of aggregated Flow
Records with the sampling rates? With different sampling rates?
EDITOR'S NOTE: similarly, shouldn't this section be handled in
the adopted -sampling draft?
Potentially.
Maybe but we could write a sentence such:
"if the Mediation aggregates flow records with sampling rate,
the new sampling rate must be calculated"
Or maybe
"the Mediation can't aggregate flow records with different
sampling rate"
Or each sampled data stream should be normalised, and the
normalised streams merged before being resampled. Eg if one
incoming stream is 1:2 and another is 1:3, while the desired
outbound stream is 1:5, the MD must do (2 x stream1 + 3 x
stream2) / 5. In this case, not sure what would happen in terms
of accuracy.
Or ...
In an IPFIX Mediation, aggregation for Flow Records with same
sampling rate and same sampling algorithm is recommended. In
that case, an IPFIX Mediator can export the sampling rate and
sampling algorithm, and other accuracy statistics data.
<Claise, et. Al> Expires October 8, 2010 [Page 15]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
3.9. Filtering Management
EDITOR'S QUESTION: What should we do in terms of filtering?
Should we try to export the filtering function? Note that, in
some cases, it doesn't even make sense: if filter X was applied
on stream1 and filter Y on stream2. If we're sending (red apples
+ green pears) to the collector, these filters make sense
individually, but together? I'm not sure that they do.
4. New Intermediate Function
EDITOR'S NOTE: How should new intermediate functions be plugged
into this protocol? OR maybe this is a framework question?
5. New Information Elements
EDITOR'S NOTE: to be discussed
- orginalExporterIpAddress
- orginalObservationDomainId?
- mediatorCertificate?
Maybe the following ones should be defined in a specific flow
aggregation draft:
- Maximum counter or minimum counter for packets or bytes
- activeTime and inactiveTime for Flow aggregation
6. Security Considerations
The same security considerations as for the IPFIX Protocol
[RFC5101] apply.
As they act as both IPFIX Collecting Processes and Exporting
Processes, the Security Considerations for IPFIX [RFC5101] apply
as well to Mediators. The Security Considerations for IPFIX
Files [RFC5655] apply as well to IPFIX Mediators that write
IPFIX Files or use them for internal storage. However, there
are a few specific considerations that IPFIX Mediator
implementations must take into account in addition.
By design, IPFIX Mediators are "men-in-the-middle": they
intercede in the communication between an Original Exporter (or
another upstream Mediator) and a downstream Collecting Process.
This has two important implications for the level of
<Claise, et. Al> Expires October 8, 2010 [Page 16]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
confidentiality provided across an IPFIX Mediator, and the
ability to protect data integrity and Original Exporter
authenticity across a Mediator. We address these in the
following subsections.
6.1. Avoiding Security Downgrade
An IPFIX Mediator that accepts IPFIX Messages over a Transport
Session protected by TLS or DTLS, and which then exports IPFIX
Messages derived there from in cleartext, is a potentially
serious vulnerability in an IPFIX infrastructure. While this is
potentially acceptable in the specific case of an IPFIX Mediator
at the border of an administrative domain accepting IPFIX
Messages from outside the domain and re-exporting derived
information via an internal network protected by other means, in
the general case this situation SHOULD be avoided.
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
Intermediate Process to a downstream Collecting Process using
TLS or DTLS. It MAY allow for the configuration of unprotected
export of such IPFIX Messages, but in this case it MUST warn the
administrator that the exported IPFIX Messages will not be
protected, and that this could result in the leakage of
information deemed by the Original Exporter to be worth
protecting.
6.2. End-to-End Assertions for Mediators
Because the Transport Session between an IPFIX Mediator and an
Original Exporter is independent from the Transport Session
between the Mediator and the downstream Collecting Process,
there exists no method via TLS to assert the identity of the
original Exporting Process downstream. However, an IPFIX
Mediator, which modifies the stream of IPFIX Messages sent to
it, is by definition a trusted entity in the infrastructure.
Therefore, the IPFIX Mediator's signature on an outgoing
Transport Session can be treated as an implicit assertion that
the Original Exporter was positively identified by the Mediator
and that the source information it received was trustworthy.
However, IPFIX Mediators must in this circumstance take care not
to provide an inappropriate upgrade of trust.
<Claise, et. Al> Expires October 8, 2010 [Page 17]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
Therefore, an IPFIX Mediator SHOULD NOT sign a Transport Session
to a downstream Collector unless ALL the Original Exporters from
which the information to be exported is derived were positively
identified by the Mediator by its certificate. An exception to
this case is the reverse of the special case in the previous
subsection: an IPFIX Mediator that accepts information from
within a trusted domain via an internal network protected by
other means MAY use TLS or DTLS to protect the Transport Session
to a downstream Collector outside the domain.
[EDITOR OPEN ISSUE: We might want to use exporterCertificate and
(optionally) collectorCertificate from [RFC5655] here, but I
think they need a new Mediator-specific template if so. If we
were to use the templates defined by 5655, it would look like
this:]
If the X.509 certificates used to protect a Transport Session
between an Original Exporter and an IPFIX Mediator are required
downstream, an IPFIX Mediator MAY use the exporterCertificate
and the collectorCertificate Information Elements with the
Export Session Details Options Template defined in Section 8.1.3
of [RFC5655] or the Message Details Options Template defined in
Section 8.1.4. of [RFC5655] in order to export this information
downstream. However, in this case, the IPFIX Mediator is making
an implicit assertion that the upstream Session was properly
protected and therefore trustworthy, and as such MUST protect
the Transport Session to the downstream Collector using TLS or
DTLS, as well.
7. IANA Considerations
EDITOR'S NOTE: to be updated with any Mediation's specific new
Information Elements.
8. References
8.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
[RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP),
Partial Reliability Extension", May 2004
<Claise, et. Al> Expires October 8, 2010 [Page 18]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[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.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and
J. Meyer, "Information Model for IP Flow Information
Export", RFC 5102, January 2008.
[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.
8.2. Informative References
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export", RFC
3917, October 2004
[RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services
Export Version 9", RFC 3954, October 2004
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
Quittek, "Architecture Model for IP Flow Information
Export", RFC5470, March 2009
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
"IP Flow Information Export (IPFIX) Applicability", RFC
5472, March 2009
[RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", RFC 5476,
March 2009.
<Claise, et. Al> Expires October 8, 2010 [Page 19]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
[IPFIX-MED-PS] Kobayashi, A. (Ed), Claise, B. (Ed), "IPFIX
Mediation: Problem Statement", draft-ietf-ipfix-
mediators-problem-statement-08, Internet-Draft work in
progress, February 2010.
[IPFIX-MED-FMWK] Kobayashi, A., Claise, B., and K. Ishibashi,
"IPFIX Mediation: Framework", draft-ietf-ipfix-
mediators-framework-04, Internet-Draft work in
progress, October 2009.
[IPFIX-ANON] Boschi, E., Trammell, B. "IPFIX Mediation:
Framework", draft-ietf-ipfix-anon-02.txt, Internet-
Draft work in progress, Feb 2010.
9. Author's Addresses
Benoit Claise
Cisco Systems Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
URI: http://www3.plala.or.jp/akoba/
Brian Trammell
Hitachi Europe
c/o ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
<Claise, et. Al> Expires October 8, 2010 [Page 20]
Internet-Draft <Protocol for IPFIX Mediations> March 2010
EMail: brian.trammell@hitachi-eu.com
<Claise, et. Al> Expires October 8, 2010 [Page 21]