| IPFIX Working Group | B. Claise |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | A. Kobayashi |
| Expires: June 9, 2014 | NTT |
| B. Trammell | |
| ETH Zurich | |
| December 6, 2013 |
Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
draft-ietf-ipfix-mediation-protocol-09.txt
This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 9, 2014.
Copyright (c) 2013 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 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.
The IPFIX architectural components in [RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol [RFC7011], 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 [RFC7012], registered with IANA, or specified as an enterprise-specific Information Element. The IPFIX protocol [RFC7011] was not originally written with IPFIX Mediators in mind. Therefore, the IPFIX protocol must be adapted for Intermediate Processes, as defined in the IPFIX Mediation Reference Model as specified in Figure A of [RFC6183], which is based on the IPFIX Mediation Problem Statement [RFC5982].
This document specifies the IP Flow Information Export (IPFIX) protocol in the context of the implementation and deployment of IPFIX Mediators. The use of the IPFIX protocol within an IPFIX Mediator -- a device which contains both a Collecting Process and an Exporting Process -- has an impact on the technical details of the usage of the protocol. An overview of the technical problem is covered in section 6 of [RFC5982]: loss of original Exporter information, loss of base time information, transport sessions management, loss of Options Template Information, Template Id management, considerations for network topology, and for aggregation.
The specifications in this document are based on the IPFIX protocol specifications [RFC7011] but adapted according to the IPFIX Mediation Framework [RFC6183].
The IPFIX Protocol [RFC7011] 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 the IPFIX Requirement doc, [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 [RFC7012]. The IPFIX Information Element registry [iana-ipfix-assignments] is maintained by IANA. New Information Element definitions can be added to this registry subject to an Expert Review [RFC5226], with additional process considerations described in [RFC7013]; that document also provides guidelines for authors and reviewers of new Information Element definitions. The inline export of the Information Element type information is specified in [RFC5610].
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.
The "IPFIX Mediation: Problem Statement" [RFC5982] provides an overview of the applicability of IPFIX Mediators, and defines requirements for IPFIX Mediators in general terms. This document is of use largely to define the problems to be solved through the deployment of IPFIX Mediators, and to provide scope to the role of IPFIX Mediators within an IPFIX collection infrastructure.
The "IPFIX Mediation: Framework" [RFC6183], which details the IPFIX Mediation reference model and the components of an IPFIX Mediator, provides more architectural details of the arrangement of Intermediate Processes within an IPFIX Mediator.
Documents specifying the operations of specific Intermediate Processes cover the operation of these Processes within the IPFIX Mediator framework, and comply with the specifications given in this document; they may additionally specify the operation of the process independently, outside the context of an IPFIX Mediator, when this is appropriate. The details of specific Intermediate Processes, when these have additional export specifications (e.g., metadata about the intermediate processing conveyed through IPFIX Options Templates), are each treated in their own document. As of today, these documents are:
This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, which all Intermediate Processes must comply to. Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those).
The specification in this document applies to the IPFIX protocol specifications [RFC7011]. All specifications from [RFC7011] 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 protocol. Therefore, the method specified by this document also applies to PSAMP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
IPFIX-specific terms, such as Observation Domain, Flow, Flow Key, Metering Process, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, Template, IPFIX Message, Message Header, Template Record, Data Record, Options Template Record, Set, Data Set, Information Element, Scope and Transport Session, used in this document are defined in [RFC7011]. The PSAMP-specific terms used in this document, such as Filtering and Sampling, are defined in [RFC5476].
IPFIX Mediation terms related to aggregation, such as the Interval, Aggregated Flow, and Aggregated Function are defined in [RFC7015].
The IPFIX Mediation-specific terminology used in this document is defined in "IPFIX Mediation: Problem Statement" [RFC5982], and reused in "IPFIX Mediation: Framework" [RFC6183]. However, since both of those documents are an informational RFCs, the definitions have been reproduced here along with additional definitions.
Similarly, since [RFC6235] is an experimental RFC, the Anonymization Record, Anonymized Data Record, and Intermediate Anonymization Process terms, specified in [RFC6235], are also reproduced here.
In this document, as in [RFC7011], [RFC5476], [RFC7015], and [RFC6235], 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 a stream of records carrying flow- or packet-based information a "record stream". The records may be encoded as IPFIX Data Records or any other format.
The following terms are used in this document to describe the architectural entities used by IPFIX Mediation.
Specific Intermediate Processes are described below.
The format of the IPFIX Message Header as exported by an IPFIX Mediator is shown in Figure 1. This is identical to the format defined for IPFIX in [RFC7011], though Export Time and Observation Domain ID may be handled differently at certain Mediators, as noted below.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPFIX Message Header format
The header fields as exported by an IPFIX Mediator are describe below.
The following specifications, copied over from [RFC7011] have some implications in this document: "Template Withdrawals MAY appear interleaved with Template Sets, Options Template Sets, and Data Sets within an IPFIX Message. In this case, the Templates and Template Withdrawals shall be taken to take effect in the order in which they appear in the IPFIX Message."
If an IPFIX Mediator receives an IPFIX Message composed of Template Withdrawals and Template Sets, and if the IPFIX Mediator forwards this IPFIX Message, it MUST NOT modify the Set order. If an IPFIX Mediator receives IPFIX Messages composed of Template Withdrawals and Template Sets, and if the IPFIX Mediator forwards these IPFIX Messages, it MUST NOT modify the IPFIX Message order. Note that the Template Mapping (see section 4.1) is the authoritative source of information on the IPFIX Mediator to decide whether the entire IPFIX Messages can be forwarded as such.
How an IPFIX Mediator handles the Templates it receives from the Original Exporter depends entirely on the nature of the Intermediate Process running on that IPFIX Mediator. There are two cases here:
Subsequent subsections deal with specific issues in Template management that may occur at IPFIX Mediators.
For some Intermediate Processes, the IPFIX Mediator doesn't modify the (Options) Template Record(s) content. A typical example is an Intermediate Flow Selection Process acting as distributor, which collects Flow Records from one or more Exporters, and based on the Information Elements content, redirects the Flow Records to the appropriate Collector. This example is a typical case of a single network operation center managing multiple universities: an unique IPFIX Collector collects all Flow Records for the common infrastructure, but might be re-exporting specific university Flow Records to the responsible system administrator.
As specified in [RFC7011], 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 Template Mapping composed of related received and exported (Options) Template Records:
(*) The "metadata scoped to the Template" encompasses the metadata, that are scoped to the Template, and that help to determine the semantics of the Template Record. Note that these metadata are typically sent in Data Records described by an Options Template. A example is the flowKeyIndicator: An IPFIX Mediator could potentially receive two different Template IDs, from the same Exporter, with the same Information Elements, but with a different set of Flow Keys (indicated by the flowKeyIndicator in an Options Template Record). Another example is the combination of anonymizationFlags and anonymizationTechnique [RFC6235]). This metadata information must be present in the Template Mapping, to stress that the two Template Record semantics are different.
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any other Template Mappings, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping.
If a (Options) Template Record is not used anymore in an outgoing Transport Session, it MUST be withdrawn with an IPFIX Template Withdrawal Message on that specific outgoing Transport Session, and its entry MUST be removed from the Template Mapping.
If an incoming or outgoing Transport Session is gracefully shutdown or reset, the (Options) Template Records corresponding to that Transport Session MUST be removed from the Template Mapping.
For example, Figure 2 displays an example of an Intermediate Flow Selection Process, re-distributing Data Records to Collectors on the basis of customer networks, i.e. the Route Distinguisher (RD). In this example, the Template Record received from the Exporter #1 is reused towards Collector #1, Collector #2, and Collector #3, for the customer #1, customer #2, and customer #3, respectively. In this example, the outgoing Template Records exported to the different Collectors are identical. As a reminder that the Template ID uniqueness is local to the Transport Session and Observation Domain that generated the Template ID, a mix of Template ID 256 and 257 has been used.
.---------.
Tmpl. | |
ID .---->|Collector|<==>Customer 1
256 | | #1 |
| | |
RD=100:1 '---------'
.--------. .--------. |
| | Tmpl. | |----'
| | Id | | .---------.
| | 258 | | RD=100:2 | |
| IPFIX |------->| IPFIX |--------->|Collector|<==>Customer 2
|Exporter| |Mediator| Tmpl. | #2 |
| #1 | | | ID 257 | |
| | | | '---------'
| | | |----.
'--------' '--------' |
RD=100:3
| .---------.
Tmpl. | | |
ID '---->|Collector|<==>Customer 3
257 | #3 |
| |
'---------'
Figure 2: Intermediate Flow Selection Process example
Figure 3 shows the Template Mapping for the system shown in Figure 2. [RFC EDITOR NOTE: if possible, try to display the figures on a single page.]
+-----------------------------------------------------------------+ | Template Entry A: | | Incoming Transport Session Information (from Exporter#1): | | Source IP: <Exporter#1 export IP address> | | Destination IP: <IPFIX Mediator IP address> | | Protocol: SCTP | | Source Port: <source port> | | Destination Port: 4739 (IPFIX) | | Observation Domain Id: <Observation Domain ID> | | Template Id: 258 | | Metadata scoped to the Template : <not applicable in this case> | | | | Template Entry B: | | Outgoing Transport Session Information (to Collector#1): | | Source IP: <IPFIX Mediator IP address> | | Destination IP: <IPFIX Collector#1 IP address> | | Protocol: SCTP | | Source Port: <source port> | | Destination Port: 4739 (IPFIX) | | Observation Domain Id: <Observation Domain ID> | | Template Id: 256 | | Metadata scoped to the Template : <not applicable in this case> | | | | Template Entry C: | | Outgoing Transport Session Information (to Collector#2): | | Source IP: <IPFIX Mediator IP address> | | Destination IP: <IPFIX Collector#2 IP address> | | Protocol: SCTP | | Source Port: <source port> | | Destination Port: 4739 (IPFIX) | | Observation Domain Id: <Observation Domain ID> | | Template Id: 257 | | Metadata scoped to the Template : <not applicable in this case> | | | | Template Entry D: | | Outgoing Transport Session Information (to Collector#3): | | Source IP: <IPFIX Mediator IP address> | | Destination IP: <IPFIX Collector#3 IP address> | | Protocol: SCTP | | Source Port: <source port> | | Destination Port: 4739 (IPFIX) | | Observation Domain Id: <Observation Domain ID> | | Template Id: 257 | | Metadata scoped to the Template : <not applicable in this case> | +-----------------------------------------------------------------+
Figure 3: Template Mapping example: templates
The Template Mapping corresponding to Figure 3 is displayed in Figure 4:
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry D
Figure 4: Template Mapping example: mappings
Alternatively, the Template Mapping may be optimized as in Figure 5:
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry D
Figure 5: Template Mapping example2: mappings
Note that all examples use Transport Sessions based on the SCTP protocol, as simplified use cases. However, the transport protocol would be important in situations such as an Intermediate Conversion Process doing transport protocol conversion.
In the situation where Original Exporters each export an (Options) Template to a single IPFIX Mediator, and the (Options) Template Record contains the same Information Elements but in different order, should the IPFIX Mediator maintain a Template Mapping with a single Export Template Record (see Figure 6) or should the IPFIX Mediator maintain multiple independent Template Records (see Figure 7) before re-exporting to the Collector?
Template Entry A <--+
|
Template Entry B <--+--> Template Entry D
|
Template Entry C <--+
Figure 6: Template Mapping and Ordering: a single Export Template Record
Template Entry A <--+--> Template Entry D
Template Entry B <--+--> Template Entry E
Template Entry C <--+--> Template Entry F
Figure 7: Template Mapping and Ordering: multiple Export Template Records
The answer depends whether the order of the Information Elements implies some specific semantic. One of the guiding principles in IPFIX protocol specifications is that the semantic meaning of one Information Element doesn't depend on the value of any other Information Element. However, there is one noticeable exception, as mentioned in [RFC7011]:
"Multiple Scope Fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are meteringProcessId and templateId, the combined scope is this Template for this Metering Process. If a different order of Scope Fields would result in a Record having a different semantic meaning, then the order of Scope Fields MUST be preserved by the Exporting Process. For example, in the context of PSAMP [RFC5476], if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function."
If an IPFIX Mediator receives, from multiple Exporters, Template Records with identical Information Elements, but ordered differently, it SHOULD consider those Template Records as identical, subject to metadata information in the associated Options Template (for example, the Flow Key Options Template. See Section 10.2).
If an IPFIX Mediator receives, from multiple Exporters, Options Template Records with identical and ordered Information Elements in the Scope fields, and with identical Information Elements, but ordered differently, in the non Scope fields, it SHOULD consider those Template Records as identical.
If an IPFIX Mediator receives, from multiple Exporters, Options Template Records with identical Information Elements in the scope, but ordered differently, it MUST consider those Template Records as semantically different.
For other Intermediate Processes, the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process.
In these cases, the IPFIX Mediator doesn't need to maintain a Template Mapping, as it generates its own series of (Options) Template Records. However, some special cases might still require a Template Mapping. Consider a situation where the IPFIX Mediator generates new (Options) Template Records based on what it receives from the Exporter(s) based on the Intermediate Process function: e.g. an Intermediate Anonymization process which performs black-marker anonymization [RFC6235] on certain Information Elements. In such cases, it's important to keep the correlation between the received (Options) Template Records and derived (Options) Template Records in the Template Mapping. These Template Mappings would be kept as in Section 4.1, except that the exported Template would not be identical to the received Template.
Similarly to Exporting Processes in any Exporter, an IPFIX Mediator may use the technique for reducing redundancy in IPFIX described in [RFC5473].
Depending on application requirements, Mediators which do not generate new Records SHOULD re-export values for unknown Information Elements, for which the Mediator does not have information about Information Element data type and semantics. However, as there may be presence or ordering dependencies among the unknown Information Elements, the Mediator MUST NOT omit fields from such re-exported Records, or re-order any fields within the Records.
Mediators which generate new Records, as in Section 4.2, SHOULD NOT use values of Information Elements they do not understand. If they do pass such values, they MUST NOT pass values of unknown Information Elements unless all such values are passed on in the original order in which they were received.
In any case, Mediators handling unknown Information Elements SHOULD log this fact, as it is likely that mediation of records containing unknown values will have unintended consequences.
Depending on the use case, the Collector in an Exporter - IPFIX Mediator - Collector structure (for example tiered Mediators) may need to receive information about the Original Observation Point(s), otherwise it may wrongly conclude that the IPFIX Device exporting the Flow Records, i.e. the IPFIX Mediator, directly observed the packets that generated the Flow Records. Two new Information Elements are introduced to address this use case: originalExporterIPv4Address and originalExporterIPv6Address. Practically, the Original Exporters will not be exporting these Information Elements. Therefore, the Intermediate Process SHOULD report the Original Observation Point(s) to the best of its knowledge. Note that the Configuration Data Model for IPFIX and PSAMP [RFC6728] may report the Original Exporter information out of band.
In the IPFIX Mediator, the Observation Point(s) may be represented by:
Some Information Elements characterizing the Observation Point may be added. For example, the flowDirection Information Element specifies the direction of the observation, and, as such, characterizes the Observation Point.
Any combination of the above representations is possible. An example of an Original Observation Point for an Intermediate Aggregation Process is displayed in Figure 8.
exporterIPv4Address 192.0.2.1 exporterIPv4Address 192.0.2.2, interface ethernet 0, direction ingress interface ethernet 1, direction ingress interface serial 1, direction egress interface serial 2, direction egress exporterIPv4Address 192.0.2.3, lineCardId 1, direction ingress
Figure 8: Complex Observation Point Definition Example
A Mediator MAY export such complex Original Observation Point information, depending on application requirements. If such information is exported, the Mediator MUST use [RFC6313] to do so, as described below.
The most generic way to export the Original Observation Point is to use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking the previous example, the encoding in Figure 9 can be used.
Template Record 257: exporterIPv4Address
Template Record 258: exporterIPv4Address,
basicList of ingressInterface, flowDirection
Template Record 259: exporterIPv4Address, lineCardId, flowDirection
Figure 9: Complex Observation Point Definition Example: Templates
The Original Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3 but not more than one of these ("exactlyOneOf" semantic). This implies that the Flow was observed at exactly one of the Observation Points reported.
When an IPFIX Mediator receives Flow Records containing the Original Observation Point Information Element, i.e. originalExporterIPv4Address or originalExporterIPv6Address, the IPFIX Mediator SHOULD NOT modify its value(s) when composing new Flow Records in the general case. Known exceptions include anonymization per [RFC6235] section 7.2.4 and an Intermediate Correlation Process rewriting addresses across NAT. In other words, the Original Observation Point should not be replaced with the IPFIX Mediator Observation Point. The daisy chain of (Exporter, Observation Point) representing the path the Flow Records took from the Exporter to the top Collector in the Exporter - IPFIX Mediator(s) - Collector structure model is out of the scope of this specification.
The following subsections describe Information Elements for reporting Original Exporter addresses as seen by the Collecting Process; note they may be subject to network address translation upstream; see [I-D.ietf-behave-ipfix-nat-logging] for more on logging in this situation.
The Observation Domain ID of any IPFIX Message containing Flow Records relevant to no particular Observation Domain, or to multiple Observation Domains, MUST have an Observation Domain ID of 0, as in Section 3 above, and section 3.1 of [RFC7011].
IPFIX Mediators that do not change (Options) Template Records MUST maintain a Template Mapping, as detailed in Section 4.1, to ensure that the combination of Observation Domain IDs and Template IDs do not collide on export.
For IPFIX Mediators that export New (Options) Template Records, as in Section 4.2, there are two options for Observation Domain ID management. The first and simplest of these is to completely decouple exported Observation Domain IDs from received Observation Domain IDs; the IPFIX Mediator, in this case, comprises its own set of Observation Domain(s) independent of the Observation Domain(s) of the Original Exporters.
The second option is to provide or maintain a Template Mapping for received (Options) Template Records and exported inferred (Options) Template Records, along with the appropriate Observation Domain IDs per Transport Session, which ensures that the combination of Observation Domain IDs and Template IDs do not collide on export.
In some cases where the IPFIX Message Header can't contain a consistent Observation Domain for the entire IPFIX Message, but the Flow Records exported from the IPFIX Mediator should anyway contain the Observation Domain of the Original Exporter, the (Options) Template Record must contain the originalObservationDomainId Information Element, specified in Section 6.1. When an IPFIX Mediator receives Flow Records containing the originalObservationDomainId Information Element, the IPFIX Mediator MUST NOT modify its value(s) when composing new Flow Records with the originalObservationDomainId Information Element.
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the IPFIX Mediator. However, in the specific case of an IPFIX Mediator containing an Intermediate Conversion Process, the IPFIX Mediator MAY use the export time received from the incoming Transport Session.
It is RECOMMENDED that IPFIX 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.
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 [iana-ipfix-assignments], 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 application requirements of some Intermediate Processes.
Intermediate Processes MUST NOT assume that received records appear in flowStartTime, flowEndTime, or observationTime order. An Intermediate Process processing timing information (e.g., an Intermediate Aggregation Process) MAY ignore records that are significantly out of order, in order to meet application-specific state and latency requirements, but SHOULD report that records were dropped.
When an Intermediate Process aggregates information from different Flow Records, the timestamps on exported records SHOULD be the minimum of the start times and the maximum of the end times in the general case. 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. The specification of the precise rules for applying Flow Record timestamps at IPFIX Mediators for all the different situations is out of the scope of this document.
Note that [RFC7015] provides additional specifications for handling of timestamps at an Intermediate Aggregation Process.
SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant IPFIX Mediator implementations. TCP [RFC0793] MAY also be implemented by IPFIX Mediator compliant implementations. UDP [RFC0768] MAY also be implemented by compliant IPFIX Mediator implementations. Transport-specific considerations for IPFIX Exporters as specified in sections 8.3, 8.4, 9.1, 9.2, and 10 of [RFC7011] apply to IPFIX Mediators as well.
SCTP SHOULD be used in deployments where IPFIX Mediators and Collectors are communicating over links that are susceptible to congestion. 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 SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation. UDP MAY be used, although it is not a congestion-aware protocol. However, in this case, the IPFIX traffic between IPFIX Mediator and Collector MUST run in an environment where IPFIX traffic has been provisioned for and/or separated from non-IPFIX traffic, whether physically or virtually.
Any Collecting Process compliant with [RFC7011] can receive IPFIX Messages from an IPFIX Mediator. If the IPFIX Mediator uses IPFIX Structured Data [RFC6313] to export Original Exporter Information as in Section 5, the Collecting Process MUST support [RFC6313].
IPFIX provides Options Templates for the reporting the reliability of processes within the IPFIX Architecture. As each Mediator includes at least one IPFIX Exporting Process, they MAY use the Exporting Process Reliability Statistics Options Template, as specified in [RFC7011].
Analogous to the Metering Process Reliability Statistics Options Template, also specified in [RFC7011], Mediators MAY implement the Intermediate Process Reliability Statistics Options Template, specified in Section 10.1. Sections 10.3 and 10.4 define Information Elements used by this Options Template.
The Flow Keys Options Template, as specified in [RFC7011], may require special handling at an IPFIX Mediator as described in Section 10.2.
In addition, each Intermediate Process may have its own specific reporting requirements (e.g. Anonymization Records as in [RFC6235], or the Aggregation Counter Distribution Options Template as in [RFC7015]); these SHOULD be implemented as necessary, as described in the specification for each Intermediate Process.
The Intermediate Process Statistics Options Template specifies the structure of a Data Record for reporting Intermediate Process statistics. It SHOULD contain the following Information Elements; the intermediateProcessId Information Element is defined in Section 10.3, and the ignoredDataRecordTotalCount Information Element is defined in Section 10.4:
| IE | Description |
|---|---|
| observationDomainId [scope] | An identifier of the Observation Domain (of messages exported by this Mediator), locally unique to the Intermediate Process, to which this statistics record applies. ---------------------------------- |
| intermediateProcessId [scope] | An identifier for the Intermediate Process to which this statistics record applies. ---------------------------------- |
| ignoredDataRecordTotalCount | The total number of Data Records received but not processed by the Intermediate Process. ---------------------------------- |
| time first record ignored | The timestamp of the first record that was ignored by the Intermediate Process. For Data Records containing timestamp ranges, this SHOULD be taken from the start timestamp of the range; for data records containing no timing information, this SHOULD be taken from the Export Time in the message header of the containing IPFIX Message. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. ---------------------------------- |
| time last record ignored | The timestamp of the last record that was ignored by the Intermediate Process. For Data Records containing timestamp ranges, this SHOULD be taken from the end timestamp of the range; for data records containing no timing information, this SHOULD be taken from the Export Time in the message header of the containing IPFIX Message. For this timestamp, any of the following timestamp can be used: observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds. |
The Flow Keys Options 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. This Options Template is defined in section 4.4 of [RFC7011], and SHOULD be used by Mediators for export as defined there.
When an Intermediate Process exports Data Records containing different Flow Keys from those received from the Original Exporter, and the Original Exporter sent a Flow Keys Options record to the IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options record defining the new set of Flow Keys.
In general, using IPFIX Mediators to combine information from multiple Original Exporters requires a consistent configuration of the Metering Processes behind these Original Exporters. The details of this consistency are specific to each Intermediate Process. Consistency of configuration should be verified out of band, with the MIB modules ([RFC6615] and [RFC6727]) or with the Configuration Data Model for IPFIX and PSAMP [RFC6728].
From an operational perspective, this specification provides all the information required to setup IPFIX Mediators and Collectors behind IPFIX Mediators. While configuring the IPFIX Mediators, care must be taken to include all the relevant information so that the Collectors deduce the Data Records precise semantic. This is covered by the Template Mapping specifications in Section 4.1. Also, caution must be taken that if something is not carefully configured in the processing chain, this can lead to the wrong interpretation of collected IPFIX data, and the associated applications can produce results that are not operationally meaningful.
As they act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for the IPFIX Protocol [RFC7011] also apply to IPFIX Mediators. The Security Considerations for IPFIX Files [RFC5655] also apply 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 also take into account.
By design, IPFIX Mediators are "men-in-the-middle": they intercede in the communication between an Original Exporter (or another upstream IPFIX Mediator) and a downstream Collecting Process. This has two important implications for the level of confidentiality provided across an IPFIX Mediator, and the ability to protect data integrity and Original Exporter authenticity across an IPFIX Mediator. These are addressed in more detail in the Security Considerations for IPFIX Mediators in [RFC6183].
Note that, while IPFIX Mediators can use the exporterCertificate and collectorCertificate Information Elements defined in [RFC5655] as described in section 9.3 of [RFC6183] to export information about X.509 identities in upstream TLS-protected Transport Sessions, this mechanism cannot be used to provide true end-to-end assertions about a chain of IPFIX Mediators: any IPFIX Mediator in the chain can simply falsify the information about upstream Transport Sessions. In situations where information about the chain of mediation is important, it must be determined out of band. Note as well that an Exporting Process has no in-band way to determine whether a given Collecting Process will act as a Mediator or not. Trust placed in Collecting Processes is absolute, so care should be taken when exporting IPFIX Messages between Exporting Processes and Collecting Processes controlled by different entities.
This document specifies new IPFIX Information Elements, originalExporterIPv4Address in Section 5.1, originalExporterIPv6Address in Section 5.2, originalObservationDomainId in Section 6.1, intermediateProcessId in Section 10.3, and ignoredDataRecordTotalCount in Section 10.4, to be added to the IPFIX Information Element registry [iana-ipfix-assignments]. [IANA NOTE: please add the five Information Elements as specified in the references subsections, change TBD1, TBD2, TBD3, TBD4, and TBD5 in this document to reflect the assigned identifiers, put the Status as current, insert THISRFC into the Requester entry, insert 0 for the Revision, and use the current date for Date. From the Information Element definitions in section 5.1, 5.2, 6.1, 10.3, and 10.4, the Name, Description, Data Type, Data Type Semantics, and ElementId fields refer to the corresponding column entries in the IPFIX IANA registry.]
We would like to thank the IPFIX contributors, specifically Paul Aitken (THE ultimate IPFIX document reviewer) and Andrew Feren for their thorough reviews; Nevil Brownlee and Juergen Quittek for shepherding this document and chairing the IPFIX Working Group; and to Rahul Patel, Meral Shirazipour, and Juergen Schoenwaelder for their feedback and comments. This work is materially supported by the European Union Seventh Framework Programme under grant agreement 257315 (DEMONS) and 318627 (mPlane).