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 Expires October 7 2010 [Page 1] Internet-Draft 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 Expires October 8, 2010 [Page 2] Internet-Draft 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 Expires October 8, 2010 [Page 3] Internet-Draft 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 Expires October 8, 2010 [Page 4] Internet-Draft 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 Expires October 8, 2010 [Page 5] Internet-Draft 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 Expires October 8, 2010 [Page 6] Internet-Draft 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. Expires October 8, 2010 [Page 7] Internet-Draft 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. Expires October 8, 2010 [Page 8] Internet-Draft 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 Expires October 8, 2010 [Page 9] Internet-Draft 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. Expires October 8, 2010 [Page 10] Internet-Draft 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. Expires October 8, 2010 [Page 11] Internet-Draft 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. Expires October 8, 2010 [Page 12] Internet-Draft 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. Expires October 8, 2010 [Page 13] Internet-Draft 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 Expires October 8, 2010 [Page 14] Internet-Draft 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. Expires October 8, 2010 [Page 15] Internet-Draft 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 Expires October 8, 2010 [Page 16] Internet-Draft 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. Expires October 8, 2010 [Page 17] Internet-Draft 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 Expires October 8, 2010 [Page 18] Internet-Draft 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. Expires October 8, 2010 [Page 19] Internet-Draft 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 Expires October 8, 2010 [Page 20] Internet-Draft March 2010 EMail: brian.trammell@hitachi-eu.com Expires October 8, 2010 [Page 21]