summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7011.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7011.txt')
-rw-r--r--doc/rfc/rfc7011.txt4259
1 files changed, 4259 insertions, 0 deletions
diff --git a/doc/rfc/rfc7011.txt b/doc/rfc/rfc7011.txt
new file mode 100644
index 0000000..fdc2ddc
--- /dev/null
+++ b/doc/rfc/rfc7011.txt
@@ -0,0 +1,4259 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Claise, Ed.
+Request for Comments: 7011 Cisco Systems, Inc.
+STD: 77 B. Trammell, Ed.
+Obsoletes: 5101 ETH Zurich
+Category: Standards Track P. Aitken
+ISSN: 2070-1721 Cisco Systems, Inc.
+ September 2013
+
+
+ Specification of the IP Flow Information Export (IPFIX) Protocol
+ for the Exchange of Flow Information
+
+Abstract
+
+ This document specifies the IP Flow Information Export (IPFIX)
+ protocol, which serves as a means for transmitting Traffic Flow
+ information over the network. In order to transmit Traffic Flow
+ information from an Exporting Process to a Collecting Process, a
+ common representation of flow data and a standard means of
+ communicating them are required. This document describes how the
+ IPFIX Data and Template Records are carried over a number of
+ transport protocols from an IPFIX Exporting Process to an IPFIX
+ Collecting Process. This document obsoletes RFC 5101.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 1]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Copyright Notice
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................5
+ 1.1. Changes since RFC 5101 .....................................5
+ 1.2. IPFIX Documents Overview ...................................6
+ 2. Terminology .....................................................7
+ 2.1. Terminology Summary Table .................................13
+ 3. IPFIX Message Format ...........................................13
+ 3.1. Message Header Format .....................................15
+ 3.2. Field Specifier Format ....................................16
+ 3.3. Set and Set Header Format .................................18
+ 3.3.1. Set Format .........................................18
+ 3.3.2. Set Header Format ..................................19
+ 3.4. Record Format .............................................20
+ 3.4.1. Template Record Format .............................20
+ 3.4.2. Options Template Record Format .....................23
+ 3.4.2.1. Scope .....................................23
+ 3.4.2.2. Options Template Record Format ............24
+ 3.4.3. Data Record Format .................................27
+ 4. Specific Reporting Requirements ................................28
+ 4.1. The Metering Process Statistics Options Template ..........29
+ 4.2. The Metering Process Reliability Statistics
+ Options Template ..........................................29
+ 4.3. The Exporting Process Reliability Statistics
+ Options Template ..........................................31
+ 4.4. The Flow Keys Options Template ............................32
+ 5. Timing Considerations ..........................................32
+ 5.1. IPFIX Message Header Export Time and Flow Record Time .....32
+ 5.2. Supporting Timestamp Wraparound ...........................33
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 2]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ 6. Linkage with the Information Model .............................34
+ 6.1. Encoding of IPFIX Data Types ..............................34
+ 6.1.1. Integral Data Types ................................34
+ 6.1.2. Address Types ......................................34
+ 6.1.3. float32 ............................................34
+ 6.1.4. float64 ............................................34
+ 6.1.5. boolean ............................................35
+ 6.1.6. string and octetArray ..............................35
+ 6.1.7. dateTimeSeconds ....................................35
+ 6.1.8. dateTimeMilliseconds ...............................35
+ 6.1.9. dateTimeMicroseconds ...............................35
+ 6.1.10. dateTimeNanoseconds ...............................36
+ 6.2. Reduced-Size Encoding .....................................36
+ 7. Variable-Length Information Element ............................37
+ 8. Template Management ............................................38
+ 8.1. Template Withdrawal and Redefinition ......................40
+ 8.2. Sequencing Template Management Actions ....................42
+ 8.3. Additional Considerations for Template Management
+ over SCTP .................................................43
+ 8.4. Additional Considerations for Template Management
+ over UDP ..................................................44
+ 9. The Collecting Process's Side ..................................45
+ 9.1. Collecting Process Handling of Malformed IPFIX Messages ...46
+ 9.2. Additional Considerations for SCTP Collecting Processes ...46
+ 9.3. Additional Considerations for UDP Collecting Processes ....46
+ 10. Transport Protocol ............................................47
+ 10.1. Transport Compliance and Transport Usage .................47
+ 10.2. SCTP .....................................................48
+ 10.2.1. Congestion Avoidance ..............................48
+ 10.2.2. Reliability .......................................49
+ 10.2.3. MTU ...............................................49
+ 10.2.4. Association Establishment and Shutdown ............49
+ 10.2.5. Failover ..........................................50
+ 10.2.6. Streams ...........................................50
+ 10.3. UDP ......................................................50
+ 10.3.1. Congestion Avoidance ..............................50
+ 10.3.2. Reliability .......................................51
+ 10.3.3. MTU ...............................................51
+ 10.3.4. Session Establishment and Shutdown ................51
+ 10.3.5. Failover and Session Duplication ..................51
+ 10.4. TCP ......................................................52
+ 10.4.1. Congestion Avoidance ..............................52
+ 10.4.2. Reliability .......................................52
+ 10.4.3. MTU ...............................................52
+ 10.4.4. Connection Establishment and Shutdown .............53
+ 10.4.5. Failover ..........................................53
+
+
+
+
+
+Claise, et al. Standards Track [Page 3]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ 11. Security Considerations .......................................54
+ 11.1. Applicability of TLS and DTLS ............................55
+ 11.2. Usage ....................................................56
+ 11.3. Mutual Authentication ....................................56
+ 11.4. Protection against DoS Attacks ...........................57
+ 11.5. When DTLS or TLS Is Not an Option ........................58
+ 11.6. Logging an IPFIX Attack ..................................58
+ 11.7. Securing the Collector ...................................59
+ 11.8. Privacy Considerations for Collected Data ................59
+ 12. Management Considerations .....................................60
+ 13. IANA Considerations ...........................................61
+ Appendix A. IPFIX Encoding Examples ...............................62
+ A.1. Message Header Example ....................................62
+ A.2. Template Set Examples .....................................63
+ A.2.1. Template Set Using IANA Information Elements ..........63
+ A.2.2. Template Set Using Enterprise-Specific Information
+ Elements ..............................................64
+ A.3. Data Set Example ..........................................65
+ A.4. Options Template Set Examples .............................66
+ A.4.1. Options Template Set Using IANA Information Elements ..66
+ A.4.2. Options Template Set Using Enterprise-Specific
+ Information Elements ..................................66
+ A.4.3. Options Template Set Using an Enterprise-Specific
+ Scope .................................................67
+ A.4.4. Data Set Using an Enterprise-Specific Scope ...........68
+ A.5. Variable-Length Information Element Examples ..............69
+ A.5.1. Example of Variable-Length Information Element with
+ Length Less Than 255 Octets ...........................69
+ A.5.2. Example of Variable-Length Information Element with
+ 3-Octet Length Encoding ...............................70
+ Normative References ..............................................71
+ Informative References ............................................71
+ Acknowledgments ...................................................74
+ Contributors ......................................................75
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 4]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+1. Introduction
+
+ Traffic on a data network can be seen as consisting of flows passing
+ through network elements. For administrative or other purposes, it
+ is often interesting, useful, or even necessary to have access to
+ information about these flows that pass through the network elements.
+ A Collecting Process should be able to receive the Flow information
+ passing through multiple network elements within the data network.
+ This requires uniformity in the method of representing the flow
+ information and the means of communicating the flows from the network
+ elements to the collection point. This document specifies a protocol
+ to achieve these requirements. This document specifies in detail the
+ representation of different flows, as well as the additional data
+ required for flow interpretation, packet format, transport mechanisms
+ used, security concerns, etc.
+
+1.1. Changes since RFC 5101
+
+ This document obsoletes the Proposed Standard revision of the IPFIX
+ Protocol Specification [RFC5101]. The protocol specified by this
+ document is interoperable with the protocol as specified in
+ [RFC5101]. The following changes have been made to this document
+ with respect to the previous document:
+
+ - All outstanding technical and editorial errata on [RFC5101] have
+ been addressed.
+
+ - As the [IANA-IPFIX] registry is now the normative reference for all
+ Information Element definitions (see [RFC7012]), all definitions of
+ Information Elements in Section 4 have been replaced with
+ references to that registry.
+
+ - The encoding of the dateTimeSeconds, dateTimeMilliseconds,
+ dateTimeMicroseconds, and dateTimeNanoseconds data types, and the
+ related encoding of the IPFIX Message Header Export Time field,
+ have been clarified, especially with respect to the epoch upon
+ which the timestamp data types are based.
+
+ - A new Section 5.2 has been added to address wraparound of these
+ timestamp data types after they overflow in the years 2032-2038.
+
+ - Clarifications on encoding, especially in Section 6, have been
+ made: all IPFIX values are encoded in network byte order.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 5]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ - Template management, as described in Section 8, has been simplified
+ and clarified: the specification has been relaxed with respect to
+ [RFC5101], especially concerning potential failures in Template ID
+ reuse. Additional corner cases in template management have been
+ addressed. The new template management language is interoperable
+ with that in [RFC5101] to the extent that the behavior was defined
+ in the prior specification.
+
+ - Section 11.3 (Mutual Authentication) has been improved to refer to
+ current practices in Transport Layer Security (TLS) mutual
+ authentication; references to Punycode were removed, as these are
+ covered in [RFC6125].
+
+ - Editorial improvements, including structural changes to Sections 8,
+ 9, and 10 to improve readability, have been applied. Behavior
+ common to all transport protocols has been separated out, with
+ exceptions per transport specifically noted. All template
+ management language (on both Exporting and Collecting Processes)
+ has been unified in Section 8.
+
+ - A new Section 12 on management considerations has been added.
+
+1.2. IPFIX Documents Overview
+
+ The IPFIX protocol 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 [RFC5470], per the requirements defined in
+ [RFC3917]. This document specifies how IPFIX Data Records and
+ Templates are carried via a number of transport protocols from IPFIX
+ Exporting Processes to IPFIX Collecting Processes.
+
+ Four IPFIX optimizations/extensions are currently specified: a
+ bandwidth-saving method for the IPFIX protocol [RFC5473], an
+ efficient method for exporting bidirectional flows [RFC5103], a
+ method for the definition and export of complex data structures
+ [RFC6313], and the specification of the Protocol on IPFIX Mediators
+ [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183].
+
+ A "file-based transport" for IPFIX, which defines how IPFIX Messages
+ can be stored in files for document-based workflows and for archival
+ purposes, is discussed in [RFC5655].
+
+ IPFIX has a formal description of IPFIX Information Elements -- their
+ names, data types, and additional semantic information -- as
+ specified in [RFC7012]. The registry is maintained by IANA
+ [IANA-IPFIX]. The inline export of the Information Element type
+ information is specified in [RFC5610].
+
+
+
+Claise, et al. Standards Track [Page 6]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The framework for packet selection and reporting [RFC5474] enables
+ network elements to select subsets of packets by statistical and
+ other methods, and to export a stream of reports on the selected
+ packets to a Collector. The set of packet selection techniques
+ (Sampling, Filtering, and hashing) standardized by the Packet
+ Sampling (PSAMP) protocol is described in [RFC5475]. The PSAMP
+ protocol [RFC5476], which uses IPFIX as its export protocol,
+ specifies the export of packet information from a PSAMP Exporting
+ Process to a PSAMP Collector. Instead of exporting PSAMP Packet
+ Reports, the stream of selected packets may also serve as input to
+ the generation of IPFIX Flow Records. Like IPFIX, PSAMP has a formal
+ description of its Information Elements: their names, types, and
+ additional semantic information. The PSAMP information model is
+ defined in [RFC5477].
+
+ [RFC6615] specifies a MIB module for monitoring, and [RFC6728]
+ specifies a data model for configuring and monitoring IPFIX and
+ PSAMP-compliant devices using the Network Configuration Protocol
+ (NETCONF). [RFC6727] specifies the PSAMP MIB module as an extension
+ of the IPFIX SELECTOR MIB module defined in [RFC6615].
+
+ In terms of development, [RFC5153] provides guidelines for the
+ implementation and use of the IPFIX protocol, while [RFC5471]
+ provides guidelines for testing. Finally, [RFC5472] describes what
+ types 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.
+
+2. Terminology
+
+ 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
+ RFC 2119 [RFC2119].
+
+ The definitions of the basic terms like Traffic Flow, Exporting
+ Process, Collecting Process, Observation Points, etc. are
+ semantically identical to those found in the IPFIX requirements
+ document [RFC3917]. Some of the terms have been expanded for more
+ clarity when defining the protocol. Additional terms required for
+ the protocol have also been defined. Definitions in this document
+ and in [RFC5470] are equivalent; definitions that are only relevant
+ to the IPFIX protocol only appear here.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 7]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The terminology summary table in Section 2.1 gives a quick overview
+ of the relationships among some of the different terms defined.
+
+ Observation Point
+
+ An Observation Point is a location in the network where packets
+ can be observed. Examples include a line to which a probe is
+ attached; a shared medium, such as an Ethernet-based LAN; a single
+ port of a router; or a set of interfaces (physical or logical) of
+ a router.
+
+ Note that every Observation Point is associated with an
+ Observation Domain (defined below) and that one Observation Point
+ may be a superset of several other Observation Points. For
+ example, one Observation Point can be an entire line card. That
+ would be the superset of the individual Observation Points at the
+ line card's interfaces.
+
+ Observation Domain
+
+ An Observation Domain is the largest set of Observation Points for
+ which Flow information can be aggregated by a Metering Process.
+ For example, a router line card may be an Observation Domain if it
+ is composed of several interfaces, each of which is an Observation
+ Point. In the IPFIX Message it generates, the Observation Domain
+ includes its Observation Domain ID, which is unique per Exporting
+ Process. That way, the Collecting Process can identify the
+ specific Observation Domain from the Exporter that sends the IPFIX
+ Messages. Every Observation Point is associated with an
+ Observation Domain. It is RECOMMENDED that Observation Domain IDs
+ also be unique per IPFIX Device.
+
+ Packet Treatment
+
+ "Packet Treatment" refers to action(s) performed on a packet by a
+ forwarding device or other middlebox, including forwarding,
+ dropping, delaying for traffic-shaping purposes, etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 8]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Traffic Flow or Flow
+
+ There are several definitions of the term 'flow' being used by the
+ Internet community. Within the context of IPFIX, we use the
+ following definition:
+
+ A Flow is defined as a set of packets or frames passing an
+ Observation Point in the network during a certain time interval.
+ All packets belonging to a particular Flow have a set of common
+ properties. Each property is defined as the result of applying a
+ function to the values of:
+
+ 1. one or more packet header fields (e.g., destination IP
+ address), transport header fields (e.g., destination port
+ number), or application header fields (e.g., RTP header fields
+ [RFC3550]).
+
+ 2. one or more characteristics of the packet itself (e.g., number
+ of MPLS labels, etc.).
+
+ 3. one or more of the fields derived from Packet Treatment (e.g.,
+ next-hop IP address, the output interface, etc.).
+
+ A packet is defined as belonging to a Flow if it completely
+ satisfies all the defined properties of the Flow.
+
+ Note that the set of packets represented by a Flow may be empty;
+ that is, a Flow may represent zero or more packets. As sampling
+ is a Packet Treatment, this definition includes packets selected
+ by a sampling mechanism.
+
+ Flow Key
+
+ Each of the fields that:
+
+ 1. belong to the packet header (e.g., destination IP address), or
+
+ 2. are a property of the packet itself (e.g., packet length), or
+
+ 3. are derived from Packet Treatment (e.g., Autonomous System (AS)
+ number),
+
+ and that are used to define a Flow (i.e., are the properties
+ common to all packets in the Flow) are termed Flow Keys. As an
+ example, the traditional '5-tuple' Flow Key of source and
+ destination IP address, source and destination transport port, and
+ transport protocol, groups together all packets belonging to a
+ single direction of communication on a single socket.
+
+
+
+Claise, et al. Standards Track [Page 9]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Flow Record
+
+ A Flow Record contains information about a specific Flow that was
+ observed at an Observation Point. A Flow Record contains measured
+ properties of the Flow (e.g., the total number of bytes for all
+ the Flow's packets) and usually contains characteristic properties
+ of the Flow (e.g., source IP address).
+
+ Metering Process
+
+ The Metering Process generates Flow Records. Inputs to the
+ process are packet headers, characteristics, and Packet Treatment
+ observed at one or more Observation Points.
+
+ The Metering Process consists of a set of functions that includes
+ packet header capturing, timestamping, sampling, classifying, and
+ maintaining Flow Records.
+
+ The maintenance of Flow Records may include creating new records,
+ updating existing ones, computing Flow statistics, deriving
+ further Flow properties, detecting Flow expiration, passing Flow
+ Records to the Exporting Process, and deleting Flow Records.
+
+ Exporting Process
+
+ The Exporting Process sends IPFIX Messages to one or more
+ Collecting Processes. The Flow Records in the Messages are
+ generated by one or more Metering Processes.
+
+ Exporter
+
+ A device that hosts one or more Exporting Processes is termed an
+ Exporter.
+
+ IPFIX Device
+
+ An IPFIX Device hosts at least one Exporting Process. It may host
+ further Exporting Processes as well as arbitrary numbers of
+ Observation Points and Metering Processes.
+
+ Collecting Process
+
+ A Collecting Process receives IPFIX Messages from one or more
+ Exporting Processes. The Collecting Process might process or
+ store Flow Records received within these Messages, but such
+ actions are out of scope for this document.
+
+
+
+
+
+Claise, et al. Standards Track [Page 10]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Collector
+
+ A device that hosts one or more Collecting Processes is termed a
+ Collector.
+
+ Template
+
+ A Template is an ordered sequence of <type, length> pairs used to
+ completely specify the structure and semantics of a particular set
+ of information that needs to be communicated from an IPFIX Device
+ to a Collector. Each Template is uniquely identifiable by means
+ of a Template ID.
+
+ IPFIX Message
+
+ An IPFIX Message is a message that originates at the Exporting
+ Process and carries the IPFIX records of this Exporting Process,
+ and whose destination is a Collecting Process. An IPFIX Message
+ is encapsulated at the transport layer.
+
+ Message Header
+
+ The Message Header is the first part of an IPFIX Message; the
+ Message Header provides basic information about the message, such
+ as the IPFIX version, length of the message, message sequence
+ number, etc.
+
+ Template Record
+
+ A Template Record defines the structure and interpretation of
+ fields in a Data Record.
+
+ Data Record
+
+ A Data Record is a record that contains values of the parameters
+ corresponding to a Template Record.
+
+ Options Template Record
+
+ An Options Template Record is a Template Record that defines the
+ structure and interpretation of fields in a Data Record, including
+ defining how to scope the applicability of the Data Record.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 11]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Set
+
+ A Set is a collection of records that have a similar structure,
+ prefixed by a header. In an IPFIX Message, zero or more Sets
+ follow the Message Header. There are three different types of
+ Sets: Template Sets, Options Template Sets, and Data Sets.
+
+ Template Set
+
+ A Template Set is a collection of one or more Template Records
+ that have been grouped together in an IPFIX Message.
+
+ Options Template Set
+
+ An Options Template Set is a collection of one or more Options
+ Template Records that have been grouped together in an IPFIX
+ Message.
+
+ Data Set
+
+ A Data Set is one or more Data Records, of the same type, that are
+ grouped together in an IPFIX Message. Each Data Record is
+ previously defined by a Template Record or an Options Template
+ Record.
+
+ Information Element
+
+ An Information Element is a protocol- and encoding-independent
+ description of an attribute that may appear in an IPFIX Record.
+ Information Elements are defined in the IANA "IPFIX Information
+ Elements" registry [IANA-IPFIX]. The type associated with an
+ Information Element indicates constraints on what it may contain
+ and also determines the valid encoding mechanisms for use in
+ IPFIX.
+
+ Transport Session
+
+ In the Stream Control Transmission Protocol (SCTP), the Transport
+ Session is known as the SCTP association, which is uniquely
+ identified by the SCTP endpoints [RFC4960]; in TCP, the Transport
+ Session is known as the TCP connection, which is uniquely
+ identified by the combination of IP addresses and TCP ports used.
+ In UDP, the Transport Session is known as the UDP session, which
+ is uniquely identified by the combination of IP addresses and UDP
+ ports used.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 12]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+2.1. Terminology Summary Table
+
+ Figure A shows a summary of IPFIX terminology.
+
+ +------------------+---------------------------------------------+
+ | | Contents |
+ | +--------------------+------------------------+
+ | Set | Template | Record |
+ +------------------+--------------------+------------------------+
+ | Data Set | / | Data Record(s) |
+ +------------------+--------------------+------------------------+
+ | Template Set | Template Record(s) | / |
+ +------------------+--------------------+------------------------+
+ | Options Template | Options Template | / |
+ | Set | Record(s) | |
+ +------------------+--------------------+------------------------+
+
+ Figure A: Terminology Summary Table
+
+ A Data Set is composed of Data Record(s). No Template Record is
+ included. A Template Record or an Options Template Record defines
+ the Data Record.
+
+ A Template Set contains only Template Record(s).
+
+ An Options Template Set contains only Options Template Record(s).
+
+3. IPFIX Message Format
+
+ An IPFIX Message consists of a Message Header, followed by zero or
+ more Sets. The Sets can be any of these three possible types:
+ Data Set, Template Set, or Options Template Set.
+
+ The format of the IPFIX Message is shown in Figure B.
+
+ +----------------------------------------------------+
+ | Message Header |
+ +----------------------------------------------------+
+ | Set |
+ +----------------------------------------------------+
+ | Set |
+ +----------------------------------------------------+
+ ...
+ +----------------------------------------------------+
+ | Set |
+ +----------------------------------------------------+
+
+ Figure B: IPFIX Message Format
+
+
+
+Claise, et al. Standards Track [Page 13]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Following are some examples of IPFIX Messages:
+
+ 1. An IPFIX Message consisting of interleaved Template, Data, and
+ Options Template Sets, as shown in Figure C. Here, Template and
+ Options Template Sets are transmitted "on demand", before the
+ first Data Set whose structure they define.
+
+ +--------+--------------------------------------------------------+
+ | | +----------+ +---------+ +-----------+ +---------+ |
+ |Message | | Template | | Data | | Options | | Data | |
+ | Header | | Set | | Set | ... | Template | | Set | |
+ | | | | | | | Set | | | |
+ | | +----------+ +---------+ +-----------+ +---------+ |
+ +--------+--------------------------------------------------------+
+
+ Figure C: IPFIX Message: Example 1
+
+ 2. An IPFIX Message consisting entirely of Data Sets, sent after the
+ appropriate Template Records have been defined and transmitted to
+ the Collecting Process, as shown in Figure D.
+
+ +--------+----------------------------------------------+
+ | | +---------+ +---------+ +---------+ |
+ |Message | | Data | | Data | | Data | |
+ | Header | | Set | ... | Set | ... | Set | |
+ | | +---------+ +---------+ +---------+ |
+ +--------+----------------------------------------------+
+
+ Figure D: IPFIX Message: Example 2
+
+ 3. An IPFIX Message consisting entirely of Template and Options
+ Template Sets, as shown in Figure E. Such a message can be used
+ to define or redefine Templates and Options Templates in bulk.
+
+ +--------+-------------------------------------------------+
+ | | +----------+ +----------+ +----------+ |
+ |Message | | Template | | Template | | Options | |
+ | Header | | Set | ... | Set | ... | Template | |
+ | | | | | | | Set | |
+ | | +----------+ +----------+ +----------+ |
+ +--------+-------------------------------------------------+
+
+ Figure E: IPFIX Message: Example 3
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 14]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.1. Message Header Format
+
+ The format of the IPFIX Message Header is shown in Figure F.
+
+ 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 F: IPFIX Message Header Format
+
+ Each Message Header field is exported in network byte order. The
+ fields are defined as follows:
+
+ Version
+
+ Version of IPFIX to which this Message conforms. 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 at which the IPFIX Message Header leaves the Exporter,
+ expressed in seconds since the UNIX epoch of 1 January 1970 at
+ 00:00 UTC, encoded as an unsigned 32-bit integer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 15]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Sequence Number
+
+ Incremental sequence counter modulo 2^32 of all IPFIX Data Records
+ sent in the current stream from the current Observation Domain by
+ the Exporting Process. Each SCTP Stream counts sequence numbers
+ separately, while all messages in a TCP connection or UDP session
+ are considered to be part of the same stream. This value can 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.
+
+ 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 also be 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 Exporter. 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 the case of a hierarchy of
+ Collectors when aggregated Data Records are exported.
+
+3.2. Field Specifier Format
+
+ Vendors need the ability to define proprietary Information Elements,
+ because, for example, they are delivering a pre-standards product, or
+ the Information Element is in some way commercially sensitive. This
+ section describes the Field Specifier format for both IANA-registered
+ Information Elements [IANA-IPFIX] and enterprise-specific Information
+ Elements.
+
+ The Information Elements are identified by the Information Element
+ identifier. When the Enterprise bit is set to 0, the corresponding
+ Information Element appears in [IANA-IPFIX], and the Enterprise
+ Number MUST NOT be present. When the Enterprise bit is set to 1, the
+ corresponding Information Element identifier identified an
+ enterprise-specific Information Element; the Enterprise Number MUST
+ be present. An example of this is shown in Appendix A.2.2.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 16]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The Field Specifier format is shown in Figure G.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |E| Information Element ident. | Field Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure G: Field Specifier Format
+
+ Where:
+
+ E
+
+ Enterprise bit. This is the first bit of the Field Specifier. If
+ this bit is zero, the Information Element identifier identifies an
+ Information Element in [IANA-IPFIX], and the four-octet Enterprise
+ Number field MUST NOT be present. If this bit is one, the
+ Information Element identifier identifies an enterprise-specific
+ Information Element, and the Enterprise Number field MUST be
+ present.
+
+ Information Element identifier
+
+ A numeric value that represents the Information Element. Refer to
+ [IANA-IPFIX].
+
+ Field Length
+
+ The length of the corresponding encoded Information Element, in
+ octets. Refer to [IANA-IPFIX]. The Field Length may be smaller
+ than that listed in [IANA-IPFIX] if the reduced-size encoding is
+ used (see Section 6.2). The value 65535 is reserved for variable-
+ length Information Elements (see Section 7).
+
+ Enterprise Number
+
+ IANA enterprise number [IANA-PEN] of the authority defining the
+ Information Element identifier in this Template Record.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 17]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.3. Set and Set Header Format
+
+ A Set is a generic term for a collection of records that have a
+ similar structure. There are three different types of Sets: Template
+ Sets, Options Template Sets, and Data Sets. Each of these Sets
+ consists of a Set Header and one or more records. The Set Format and
+ the Set Header Format are defined in the following sections.
+
+3.3.1. Set Format
+
+ A Set has the format shown in Figure H. The record types can be
+ either Template Records, Options Template Records, or Data Records.
+ The record types MUST NOT be mixed within a Set.
+
+ +--------------------------------------------------+
+ | Set Header |
+ +--------------------------------------------------+
+ | record |
+ +--------------------------------------------------+
+ | record |
+ +--------------------------------------------------+
+ ...
+ +--------------------------------------------------+
+ | record |
+ +--------------------------------------------------+
+ | Padding (opt.) |
+ +--------------------------------------------------+
+
+ Figure H: Set Format
+
+ Set Header
+
+ The Set Header Format is defined in Section 3.3.2.
+
+ Record
+
+ One of the record formats: Template Record, Options Template
+ Record, or Data Record format.
+
+ Padding
+
+ The Exporting Process MAY insert some padding octets, so that the
+ subsequent Set starts at an aligned boundary. For security
+ reasons, the padding octet(s) MUST be composed of octets with
+ value zero (0). The padding length MUST be shorter than any
+ allowable record in this Set. If padding of the IPFIX Message is
+ desired in combination with very short records, then the padding
+ Information Element 'paddingOctets' can be used for padding
+
+
+
+Claise, et al. Standards Track [Page 18]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ records such that their length is increased to a multiple of 4 or
+ 8 octets. Because Template Sets are always 4-octet aligned by
+ definition, padding is only needed in the case of other
+ alignments, e.g., on 8-octet boundaries.
+
+3.3.2. Set Header Format
+
+ Every Set contains a common header. This header is defined in
+ Figure I.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure I: Set Header Format
+
+ Each Set Header field is exported in network format. The fields are
+ defined as follows:
+
+ Set ID
+
+ Identifies the Set. A value of 2 is reserved for Template Sets.
+ A value of 3 is reserved for Options Template Sets. Values from 4
+ to 255 are reserved for future use. Values 256 and above are used
+ for Data Sets. The Set ID values of 0 and 1 are not used, for
+ historical reasons [RFC3954].
+
+ Length
+
+ Total length of the Set, in octets, including the Set Header, all
+ records, and the optional padding. Because an individual Set MAY
+ contain multiple records, the Length value MUST be used to
+ determine the position of the next Set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 19]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.4. Record Format
+
+ IPFIX defines three record formats, as defined in the next sections:
+ the Template Record format, the Options Template Record format, and
+ the Data Record format.
+
+3.4.1. Template Record Format
+
+ One of the essential elements in the IPFIX record format is the
+ Template Record. Templates greatly enhance the flexibility of the
+ record format because they allow the Collecting Process to process
+ IPFIX Messages without necessarily knowing the interpretation of all
+ Data Records. A Template Record contains any combination of IANA-
+ assigned and/or enterprise-specific Information Element identifiers.
+
+ The format of the Template Record is shown in Figure J. It consists
+ of a Template Record Header and one or more Field Specifiers. Field
+ Specifiers are defined in Figure G above.
+
+ +--------------------------------------------------+
+ | Template Record Header |
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+ ...
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+
+ Figure J: Template Record Format
+
+ The format of the Template Record Header is shown in Figure K.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID (> 255) | Field Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure K: Template Record Header Format
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 20]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The Template Record Header Field definitions are as follows:
+
+ Template ID
+
+ Each Template Record is given a unique Template ID in the range
+ 256 to 65535. This uniqueness is local to the Transport Session
+ and Observation Domain that generated the Template ID. Since
+ Template IDs are used as Set IDs in the Sets they describe (see
+ Section 3.4.3), values 0-255 are reserved for special Set types
+ (e.g., Template Sets themselves), and Templates and Options
+ Templates (see Section 3.4.2) cannot share Template IDs within a
+ Transport Session and Observation Domain. There are no
+ constraints regarding the order of the Template ID allocation. As
+ Exporting Processes are free to allocate Template IDs as they see
+ fit, Collecting Processes MUST NOT assume incremental Template
+ IDs, or anything about the contents of a Template based on its
+ Template ID alone.
+
+ Field Count
+
+ Number of fields in this Template Record.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 21]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The example in Figure L shows a Template Set with mixed IANA-assigned
+ and enterprise-specific Information Elements. It consists of a Set
+ Header, a Template Header, and several Field Specifiers.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 2 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 256 | Field Count = N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| Information Element id. 1.1 | Field Length 1.1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number 1.1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| Information Element id. 1.2 | Field Length 1.2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| Information Element id. 1.N | Field Length 1.N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number 1.N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 257 | Field Count = M |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| Information Element id. 2.1 | Field Length 2.1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| Information Element id. 2.2 | Field Length 2.2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number 2.2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| Information Element id. 2.M | Field Length 2.M |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number 2.M |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Padding (opt) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure L: Template Set Example
+
+ Information Element id.s 1.2 and 2.1 appear in [IANA-IPFIX]
+ (Enterprise bit = 0) and therefore do not need an Enterprise Number
+ to identify them.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 22]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.4.2. Options Template Record Format
+
+ Thanks to the notion of scope, The Options Template Record gives the
+ Exporter the ability to provide additional information to the
+ Collector that would not be possible with Flow Records alone.
+
+ See Section 4 for specific Options Templates used for reporting
+ metadata about IPFIX Exporting and Metering Processes.
+
+3.4.2.1. Scope
+
+ The scope, which is only available in the Options Template Set, gives
+ the context of the reported Information Elements in the Data Records.
+
+ The scope is one or more Information Elements, specified in the
+ Options Template Record. At a minimum, Collecting Processes SHOULD
+ support as scope the observationDomainId, exportingProcessId,
+ meteringProcessId, templateId, lineCardId, exporterIPv4Address,
+ exporterIPv6Address, and ingressInterface Information Elements. The
+ IPFIX protocol doesn't prevent the use of any Information Elements
+ for scope. However, some Information Element types don't make sense
+ if specified as scope (for example, the counter Information
+ Elements).
+
+ The IPFIX Message Header already contains the Observation Domain ID.
+ If not zero, this Observation Domain ID can be considered as an
+ implicit scope for the Data Records in the IPFIX Message.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 23]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.4.2.2. Options Template Record Format
+
+ An Options Template Record contains any combination of IANA-assigned
+ and/or enterprise-specific Information Element identifiers.
+
+ The format of the Options Template Record is shown in Figure M. It
+ consists of an Options Template Record Header and one or more Field
+ Specifiers. Field Specifiers are defined in Figure G above.
+
+ +--------------------------------------------------+
+ | Options Template Record Header |
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+ ...
+ +--------------------------------------------------+
+ | Field Specifier |
+ +--------------------------------------------------+
+
+ Figure M: Options Template Record Format
+
+ The format of the Options Template Record Header is shown in
+ Figure N.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID (> 255) | Field Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure N: Options Template Record Header Format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 24]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The Options Template Record Header Field definitions are as follows:
+
+ Template ID
+
+ Each Options Template Record is given a unique Template ID in the
+ range 256 to 65535. This uniqueness is local to the Transport
+ Session and Observation Domain that generated the Template ID.
+ Since Template IDs are used as Set IDs in the sets they describe
+ (see Section 3.4.3), values 0-255 are reserved for special Set
+ types (e.g., Template Sets themselves), and Templates and Options
+ Templates cannot share Template IDs within a Transport Session and
+ Observation Domain. There are no constraints regarding the order
+ of the Template ID allocation. As Exporting Processes are free to
+ allocate Template IDs as they see fit, Collecting Processes MUST
+ NOT assume incremental Template IDs, or anything about the
+ contents of an Options Template based on its Template ID alone.
+
+ Field Count
+
+ Number of all fields in this Options Template Record, including
+ the Scope Fields.
+
+ Scope Field Count
+
+ Number of scope fields in this Options Template Record. The Scope
+ Fields are normal Fields, except that they are interpreted as
+ scope at the Collector. A scope field count of N specifies that
+ the first N Field Specifiers in the Template Record are Scope
+ Fields. The Scope Field Count MUST NOT be zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 25]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The example in Figure O shows an Options Template Set with mixed
+ IANA-assigned and enterprise-specific Information Elements. It
+ consists of a Set Header, an Options Template Header, and several
+ Field Specifiers.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 3 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 258 | Field Count = N + M |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count = N |0| Scope 1 Infor. Element id. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope 1 Field Length |0| Scope 2 Infor. Element id. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope 2 Field Length | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |1| Scope N Infor. Element id. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope N Field Length | Scope N Enterprise Number ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Scope N Enterprise Number |1| Option 1 Infor. Element id. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option 1 Field Length | Option 1 Enterprise Number ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Option 1 Enterprise Number | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |0| Option M Infor. Element id. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option M Field Length | Padding (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure O: Options Template Set Example
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 26]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+3.4.3. Data Record Format
+
+ The Data Records are sent in Data Sets. The format of the Data
+ Record is shown in Figure P. It consists only of one or more Field
+ Values. The Template ID to which the Field Values belong is encoded
+ in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
+
+ +--------------------------------------------------+
+ | Field Value |
+ +--------------------------------------------------+
+ | Field Value |
+ +--------------------------------------------------+
+ ...
+ +--------------------------------------------------+
+ | Field Value |
+ +--------------------------------------------------+
+
+ Figure P: Data Record Format
+
+ Note that Field Values do not necessarily have a length of 16 bits.
+ Field Values are encoded according to their data type as specified in
+ [RFC7012].
+
+ Interpretation of the Data Record format can be done only if the
+ Template Record corresponding to the Template ID is available at the
+ Collecting Process.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 27]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The example in Figure Q shows a Data Set. It consists of a Set
+ Header and several Field Values.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = Template ID | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 1 - Field Value 3 | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 2 - Field Value 3 | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Record 3 - Field Value 3 | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... | Padding (optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure Q: Data Set, Containing Data Records
+
+4. 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 Options 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 Options 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.
+
+ The Collecting Process MUST check the possible combinations of
+ Information Elements within the Options Template Records to correctly
+ interpret the following Options Templates.
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 28]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+4.1. The Metering Process Statistics Options Template
+
+ The Metering Process Statistics Options Template specifies the
+ structure of a Data Record for reporting Metering Process statistics.
+ It SHOULD contain the following Information Elements, as defined in
+ [IANA-IPFIX]:
+
+ (scope) observationDomainId
+
+ This Information Element MUST be defined as a Scope Field and
+ MUST be present, unless the Observation Domain ID of the
+ enclosing Message is non-zero.
+
+ (scope) meteringProcessId
+
+ If present, this Information Element MUST be defined as a Scope
+ Field.
+
+ exportedMessageTotalCount
+
+ exportedFlowRecordTotalCount
+
+ exportedOctetTotalCount
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Metering Process Statistics Options Template on a regular basis or
+ based on some export policy. This periodicity or export policy
+ SHOULD be configurable.
+
+ Note that if several Metering Processes are available on the Exporter
+ Observation Domain, the Information Element meteringProcessId MUST be
+ specified as an additional Scope Field.
+
+4.2. The Metering Process Reliability Statistics Options Template
+
+ The Metering Process Reliability Statistics Options Template
+ specifies the structure of a Data Record for reporting lack of
+ reliability in the Metering Process. It SHOULD contain the following
+ Information Elements, as defined in [IANA-IPFIX]:
+
+ (scope) observationDomainId
+
+ This Information Element MUST be defined as a Scope Field and
+ MUST be present, unless the Observation Domain ID of the
+ enclosing Message is non-zero.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 29]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ (scope) meteringProcessId
+
+ If present, this Information Element MUST be defined as a Scope
+ Field.
+
+ ignoredPacketTotalCount
+
+ ignoredOctetTotalCount
+
+ time first packet ignored
+
+ The timestamp of the first packet that was ignored by the
+ Metering Process. For this timestamp, any of the following
+ timestamp Information Elements can be used:
+
+ observationTimeSeconds,
+ observationTimeMilliseconds,
+ observationTimeMicroseconds, or
+ observationTimeNanoseconds.
+
+ time last packet ignored
+
+ The timestamp of the last packet that was ignored by the
+ Metering Process. For this timestamp, any of the following
+ timestamp Information Elements can be used:
+
+ observationTimeSeconds,
+ observationTimeMilliseconds,
+ observationTimeMicroseconds, or
+ observationTimeNanoseconds.
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Metering Process Reliability Statistics Options Template on a regular
+ basis or based on some export policy. This periodicity or export
+ policy SHOULD be configurable.
+
+ Note that if several Metering Processes are available on the Exporter
+ Observation Domain, the Information Element meteringProcessId MUST be
+ specified as an additional Scope Field.
+
+ Since the Metering Process Reliability Statistics Options Template
+ contains two identical timestamp Information Elements, and since the
+ order of the Information Elements in the Template Records is not
+ guaranteed, the Collecting Process interprets the time interval of
+ ignored packets as the range between the two values; see Section 5.2
+ for wraparound considerations.
+
+
+
+
+
+Claise, et al. Standards Track [Page 30]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+4.3. The Exporting Process Reliability Statistics Options Template
+
+ The Exporting Process Reliability Statistics Options Template
+ specifies the structure of a Data Record for reporting lack of
+ reliability in the Exporting Process. It SHOULD contain the
+ following Information Elements, as defined in [IANA-IPFIX]:
+
+ (scope) Exporting Process Identifier
+
+ The identifier of the Exporting Process for which reliability
+ is reported. Any of the exporterIPv4Address,
+ exporterIPv6Address, or exportingProcessId Information Elements
+ can be used for this field. This Information Element MUST be
+ defined as a Scope Field.
+
+ notSentFlowTotalCount
+
+ notSentPacketTotalCount
+
+ notSentOctetTotalCount
+
+ time first flow dropped
+
+ The time at which the first Flow Record was dropped by the
+ Exporting Process. For this timestamp, any of the following
+ timestamp Information Elements can be used:
+
+ observationTimeSeconds,
+ observationTimeMilliseconds,
+ observationTimeMicroseconds, or
+ observationTimeNanoseconds.
+
+ time last flow dropped
+
+ The time at which the last Flow Record was dropped by the
+ Exporting Process. For this timestamp, any of the following
+ timestamp Information Elements can be used:
+
+ observationTimeSeconds,
+ observationTimeMilliseconds,
+ observationTimeMicroseconds, or
+ observationTimeNanoseconds.
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Exporting Process Reliability Statistics Options Template on a
+ regular basis or based on some export policy. This periodicity or
+ export policy SHOULD be configurable.
+
+
+
+
+Claise, et al. Standards Track [Page 31]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Since the Exporting Process Reliability Statistics Options Template
+ contains two identical timestamp Information Elements, and since the
+ order of the Information Elements in the Template Records is not
+ guaranteed, the Collecting Process interprets the time interval of
+ dropped packets as the range between the two values; see Section 5.2
+ for wraparound considerations.
+
+4.4. The Flow Keys Options Template
+
+ 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. 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 Options Template SHOULD contain the following
+ Information Elements, as defined in [IANA-IPFIX]:
+
+ (scope) templateId
+
+ This Information Element MUST be defined as a Scope Field.
+
+ flowKeyIndicator
+
+5. Timing Considerations
+
+5.1. IPFIX Message Header Export Time and Flow Record Time
+
+ The IPFIX Message Header Export Time field is the time at which the
+ IPFIX Message Header leaves the Exporter, using the same encoding as
+ the dateTimeSeconds abstract data type [RFC7012], i.e., expressed in
+ seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded as
+ an unsigned 32-bit integer.
+
+ Certain time-related Information Elements may be expressed as an
+ offset from this Export Time. For example, Data Records requiring a
+ microsecond precision can export the flow start and end times with
+ the flowStartMicroseconds and flowEndMicroseconds Information
+ Elements, which encode the absolute time in microseconds in terms of
+ the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An
+ alternate solution is to export the flowStartDeltaMicroseconds and
+ flowEndDeltaMicroseconds Information Elements in the Data Record,
+ which respectively report the flow start and end time as negative
+ offsets from the Export Time, as an unsigned 32-bit integer. This
+ latter solution lowers the export bandwidth requirement, saving
+ four bytes per timestamp, while increasing the load on the Exporter,
+
+
+
+Claise, et al. Standards Track [Page 32]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ as the Exporting Process must calculate the
+ flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every
+ single Data Record before exporting the IPFIX Message.
+
+ It must be noted that timestamps based on the Export Time impose some
+ time constraints on the Data Records contained within the IPFIX
+ Message. In the example of flowStartDeltaMicroseconds and
+ flowEndDeltaMicroseconds Information Elements, the Data Record can
+ only contain records with timestamps within 71 minutes of the Export
+ Time. Otherwise, the 32-bit counter would not be sufficient to
+ contain the flow start time offset.
+
+5.2. Supporting Timestamp Wraparound
+
+ The dateTimeSeconds abstract data type [RFC7012] and the Export Time
+ Message Header field (Section 3.1) are encoded as 32-bit unsigned
+ integers, expressed as seconds since the UNIX epoch, 1 January 1970
+ at 00:00 UTC, as defined in [POSIX.1]. These values will wrap around
+ on 7 February 2106 at 06:28:16 UTC.
+
+ In order to support continued use of the IPFIX protocol beyond this
+ date, Exporting Processes SHOULD export dateTimeSeconds values and
+ the Export Time Message Header field as the number of seconds since
+ the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting
+ Processes SHOULD use the current date, or other contextual
+ information, to properly interpret dateTimeSeconds values and the
+ Export Time Message Header field.
+
+ There are similar considerations for the NTP-based
+ dateTimeMicroseconds and dateTimeNanoseconds abstract data types
+ [RFC7012]. Exporting Processes SHOULD export dateTimeMicroseconds
+ and dateTimeNanoseconds values as if the NTP era [RFC5905] is
+ implicit; Collecting Processes SHOULD use the current date, or other
+ contextual information, to determine the NTP era in order to properly
+ interpret dateTimeMicroseconds and dateTimeNanoseconds values in
+ received Data Records.
+
+ The dateTimeMilliseconds abstract data type will wrap around in
+ approximately 500 billion years; the specification of the behavior of
+ this abstract data type after that time is left as a subject of a
+ future revision of this specification.
+
+ The long-term storage of files [RFC5655] for archival purposes is
+ affected by timestamp wraparound, as the use of the current date to
+ interpret timestamp values in files stored on the order of multiple
+ decades in the past may lead to incorrect values; therefore, it is
+ RECOMMENDED that such files be stored with contextual information to
+ assist in the interpretation of these timestamps.
+
+
+
+Claise, et al. Standards Track [Page 33]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+6. Linkage with the Information Model
+
+ As with values in the IPFIX Message Header and Set Header, values of
+ all Information Elements [RFC7012], except for those of the string
+ and octetArray data types, are encoded in canonical format in network
+ byte order (also known as big-endian byte ordering).
+
+6.1. Encoding of IPFIX Data Types
+
+ The following sections define the encoding of the data types
+ specified in [RFC7012].
+
+6.1.1. Integral Data Types
+
+ Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64,
+ signed8, signed16, signed32, and signed64 -- MUST be encoded using
+ the default canonical format in network byte order. Signed integral
+ data types are represented in two's complement notation.
+
+6.1.2. Address Types
+
+ Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
+ encoded the same way as the integral data types, as six, four, and
+ sixteen octets in network byte order, respectively.
+
+6.1.3. float32
+
+ The float32 data type MUST be encoded as an IEEE binary32 floating
+ point type as specified in [IEEE.754.2008], in network byte order as
+ specified in Section 3.6 of [RFC1014]. Note that on little-endian
+ machines, byte swapping of the native representation is necessary
+ before export. Note that the method for doing this may be
+ implementation platform dependent.
+
+6.1.4. float64
+
+ The float64 data type MUST be encoded as an IEEE binary64 floating
+ point type as specified in [IEEE.754.2008], in network byte order as
+ specified in Section 3.7 of [RFC1014]. Note that on little-endian
+ machines, byte swapping of the native representation is necessary
+ before export. Note that the method for doing this may be
+ implementation platform dependent.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 34]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+6.1.5. boolean
+
+ The boolean data type is specified according to the TruthValue in
+ [RFC2579]. It is encoded as a single-octet integer per
+ Section 6.1.1, with the value 1 for true and value 2 for false.
+ Every other value is undefined.
+
+6.1.6. string and octetArray
+
+ The "string" data type represents a finite-length string of valid
+ characters of the Unicode character encoding set. The string data
+ type MUST be encoded in UTF-8 [RFC3629] format. The string is sent
+ as an array of zero or more octets using an Information Element of
+ fixed or variable length. IPFIX Exporting Processes MUST NOT send
+ IPFIX Messages containing ill-formed UTF-8 string values for
+ Information Elements of the string data type; Collecting Processes
+ SHOULD detect and ignore such values. See [UTF8-EXPLOIT] for
+ background on this issue.
+
+ The octetArray data type has no encoding rules; it represents a raw
+ array of zero or more octets, with the interpretation of the octets
+ defined in the Information Element definition.
+
+6.1.7. dateTimeSeconds
+
+ The dateTimeSeconds data type is an unsigned 32-bit integer in
+ network byte order containing the number of seconds since the UNIX
+ epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1].
+ dateTimeSeconds is encoded identically to the IPFIX Message Header
+ Export Time field. It can represent dates between 1 January 1970 and
+ 7 February 2106 without wraparound; see Section 5.2 for wraparound
+ considerations.
+
+6.1.8. dateTimeMilliseconds
+
+ The dateTimeMilliseconds data type is an unsigned 64-bit integer in
+ network byte order containing the number of milliseconds since the
+ UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It
+ can represent dates beginning on 1 January 1970 and for approximately
+ the next 500 billion years without wraparound.
+
+6.1.9. dateTimeMicroseconds
+
+ The dateTimeMicroseconds data type is a 64-bit field encoded
+ according to the NTP Timestamp format as defined in Section 6 of
+ [RFC5905]. This field is made up of two unsigned 32-bit integers in
+ network byte order: Seconds and Fraction. The Seconds field is the
+ number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
+
+
+
+Claise, et al. Standards Track [Page 35]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The Fraction field is the fractional number of seconds in units of
+ 1/(2^32) seconds (approximately 233 picoseconds). It can represent
+ dates between 1 January 1900 and 8 February 2036 in the current
+ NTP era; see Section 5.2 for wraparound considerations.
+
+ Note that dateTimeMicroseconds and dateTimeNanoseconds share an
+ identical encoding. The dateTimeMicroseconds data type is intended
+ only to represent timestamps of microsecond precision. Therefore,
+ the bottom 11 bits of the Fraction field SHOULD be zero and MUST
+ be ignored for all Information Elements of this data type
+ (as 2^11 x 233 picoseconds = .477 microseconds).
+
+6.1.10. dateTimeNanoseconds
+
+ The dateTimeNanoseconds data type is a 64-bit field encoded according
+ to the NTP Timestamp format as defined in Section 6 of [RFC5905].
+ This field is made up of two unsigned 32-bit integers in network byte
+ order: Seconds and Fraction. The Seconds field is the number of
+ seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The
+ Fraction field is the fractional number of seconds in units of
+ 1/(2^32) seconds (approximately 233 picoseconds). It can represent
+ dates between 1 January 1900 and 8 February 2036 in the current
+ NTP era; see Section 5.2 for wraparound considerations.
+
+ Note that dateTimeMicroseconds and dateTimeNanoseconds share an
+ identical encoding. There is no restriction on the interpretation of
+ the Fraction field for the dateTimeNanoseconds data type.
+
+6.2. Reduced-Size Encoding
+
+ Information Elements encoded as signed, unsigned, or float data types
+ MAY be encoded using fewer octets than those implied by their type in
+ the information model definition, based on the assumption that the
+ smaller size is sufficient to carry any value the Exporter may need
+ to deliver. This reduces the network bandwidth requirement between
+ the Exporter and the Collector. Note that the Information Element
+ definitions [IANA-IPFIX] always define the maximum encoding size.
+
+ For instance, the information model defines octetDeltaCount as an
+ unsigned64 type, which would require 64 bits. However, if the
+ Exporter will never locally encounter the need to send a value larger
+ than 4294967295, it may choose to send the value as unsigned32
+ instead.
+
+ This behavior is indicated by the Exporter by specifying a size in
+ the Template with a smaller length than that associated with the
+ assigned type of the Information Element. In the example above, the
+ Exporter would place a length of 4 versus 8 in the Template.
+
+
+
+Claise, et al. Standards Track [Page 36]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Reduced-size encoding MAY be applied to the following integer types:
+ unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
+ The signed versus unsigned property of the reported value MUST be
+ preserved. The reduction in size can be to any number of octets
+ smaller than the original type if the data value still fits, i.e., so
+ that only leading zeroes are dropped. For example, an unsigned64 can
+ be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
+
+ Reduced-size encoding MAY be used to reduce float64 to float32. The
+ float32 not only has a reduced number range but, due to the smaller
+ mantissa, is also less precise. In this case, the float64 would be
+ reduced in size to 4 octets.
+
+ Reduced-size encoding MUST NOT be applied to any other data type
+ defined in [RFC7012] that implies a fixed length, as these types
+ either have internal structure (such as ipv4Address or
+ dateTimeMicroseconds) or restricted ranges that are not suitable for
+ reduced-size encoding (such as dateTimeMilliseconds).
+
+ Information Elements of type octetArray and string may be exported
+ using any length, subject to restrictions on length specific to each
+ Information Element, as noted in that Information Element's
+ description.
+
+7. Variable-Length Information Element
+
+ The IPFIX Template mechanism is optimized for fixed-length
+ Information Elements [RFC7012]. Where an Information Element has a
+ variable length, the following mechanism MUST be used to carry the
+ length information for both the IANA-assigned and enterprise-specific
+ Information Elements.
+
+ In the Template Set, the Information Element Field Length is recorded
+ as 65535. This reserved length value notifies the Collecting Process
+ that the length value of the Information Element will be carried in
+ the Information Element content itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 37]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ In most cases, the length of the Information Element will be less
+ than 255 octets. The following length-encoding mechanism optimizes
+ the overhead of carrying the Information Element length in this more
+ common case. The length is carried in the octet before the
+ Information Element, as shown in Figure R.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length (< 255)| Information Element |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... continuing as needed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure R: Variable-Length Information Element (IE)
+ (Length < 255 Octets)
+
+ The length may also be encoded into 3 octets before the Information
+ Element, allowing the length of the Information Element to be greater
+ than or equal to 255 octets. In this case, the first octet of the
+ Length field MUST be 255, and the length is carried in the second and
+ third octets, as shown in Figure S.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 255 | Length (0 to 65535) | IE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... continuing as needed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure S: Variable-Length Information Element (IE)
+ (Length 0 to 65535 Octets)
+
+ The octets carrying the length (either the first or the first
+ three octets) MUST NOT be included in the length of the Information
+ Element.
+
+8. Template Management
+
+ This section describes the management of Templates and Options
+ Templates at the Exporting and Collecting Processes. The goal of
+ Template management is to ensure, to the extent possible, that the
+ Exporting Process and Collecting Process have a consistent view of
+ the Templates and Options Templates used to encode and decode the
+ Records sent from the Exporting Process to the Collecting Process.
+
+
+
+
+
+Claise, et al. Standards Track [Page 38]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Achieving this goal is complicated somewhat by two factors: 1) the
+ need to support the reuse of Template IDs within a Transport Session
+ and 2) the need to support unreliable transmission for Templates when
+ UDP is used as the transport protocol for IPFIX Messages.
+
+ The Template Management mechanisms defined in this section apply to
+ the export of IPFIX Messages on SCTP, TCP, or UDP. Additional
+ considerations specific to SCTP and UDP transport are given in
+ Sections 8.3 and 8.4, respectively.
+
+ The Exporting Process assigns and maintains Template IDs per
+ Transport Session and Observation Domain. A newly created Template
+ Record is assigned an unused Template ID by the Exporting Process.
+ The Collecting Process MUST store all received Template Record
+ information for the duration of each Transport Session until reuse or
+ withdrawal as described in Section 8.1, or expiry over UDP as
+ described in Section 8.4, so that it can interpret the corresponding
+ Data Records.
+
+ The Collecting Process MUST NOT assume that the Template IDs from a
+ given Exporting Process refer to the same Templates as they did in
+ previous Transport Sessions from the same Exporting Process; a
+ Collecting Process MUST NOT use Templates from one Transport Session
+ to decode Data Sets in a subsequent Transport Session.
+
+ If a specific Information Element is required by a Template but is
+ not present in observed packets, the Exporting Process MAY choose to
+ export Flow Records without this Information Element in a Data Record
+ described by a new Template.
+
+ If an Information Element is required more than once in a Template,
+ the different occurrences of this Information Element SHOULD follow
+ the logical order of their treatments by the Metering Process. For
+ example, if a selected packet goes through two hash functions, and if
+ the two hash values are sent within a single Template, the first
+ occurrence of the hash value should belong to the first hash function
+ in the Metering Process. For example, when exporting the two source
+ IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address
+ Information Element occurrence should be the IPv4 address of the
+ outer header, while the second occurrence should be the address of
+ the inner header. Collecting Processes MUST properly handle
+ Templates with multiple identical Information Elements.
+
+ The Exporting Process SHOULD transmit the Template Set and Options
+ Template Set in advance of any Data Sets that use that (Options)
+ Template ID, to help ensure that the Collector has the Template
+ Record before receiving the first Data Record. Data Records that
+ correspond to a Template Record MAY appear in the same and/or
+
+
+
+Claise, et al. Standards Track [Page 39]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ subsequent IPFIX Message(s). However, a Collecting Process MUST NOT
+ assume that the Data Set and the associated Template Set (or Options
+ Template Set) are exported in the same IPFIX Message.
+
+ Though a Collecting Process normally receives Template Records from
+ the Exporting Process before receiving Data Records, this is not
+ always the case, e.g., in the case of reordering or Collecting
+ Process restart over UDP. In these cases, the Collecting Process MAY
+ buffer Data Records for which it has no Templates, to wait for
+ Template Records describing them; however, note that in the presence
+ of Template withdrawal and redefinition (Section 8.1) this may lead
+ to incorrect interpretation of Data Records.
+
+ Different Observation Domains within a Transport Session MAY use the
+ same Template ID value to refer to different Templates; Collecting
+ Processes MUST properly handle this case.
+
+ Options Templates and Templates that are related or interdependent
+ (e.g., by sharing common properties as described in [RFC5473]) SHOULD
+ be sent together in the same IPFIX Message.
+
+8.1. Template Withdrawal and Redefinition
+
+ Templates that will not be used further by an Exporting Process MAY
+ be withdrawn by sending a Template Withdrawal. After receiving a
+ Template Withdrawal, a Collecting Process MUST stop using the
+ Template to interpret subsequently exported Data Sets. Note that
+ this mechanism does not apply when UDP is used to transport IPFIX
+ Messages; for that case, see Section 8.4.
+
+ A Template Withdrawal consists of a Template Record for the Template
+ ID to be withdrawn, with a Field Count of 0. The format of a
+ Template Withdrawal is shown in Figure T.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = (2 or 3) | Length = 16 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID N | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID ... | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID M | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure T: Template Withdrawal Format
+
+
+
+
+Claise, et al. Standards Track [Page 40]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The Set ID field MUST contain the value 2 for Template Set Withdrawal
+ or the value 3 for Options Template Set Withdrawal. Multiple
+ Template IDs MAY be withdrawn with a single Template Withdrawal; in
+ that case, padding MAY be used.
+
+ 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
+ interpreted as taking effect in the order in which they appear in the
+ IPFIX Message. An Exporting Process SHOULD NOT send a Template
+ Withdrawal until sufficient time has elapsed to allow receipt and
+ processing of any Data Records described by the withdrawn Templates;
+ see Section 8.2 for details regarding the sequencing of Template
+ management actions.
+
+ The end of a Transport Session implicitly withdraws all the Templates
+ used within the Transport Session, and Templates must be resent
+ during subsequent Transport Sessions between an Exporting Process and
+ Collecting Process. This applies to SCTP and TCP only; see
+ Sections 8.4 and 10.3.4 for discussions of Transport Session and
+ Template lifetime over UDP.
+
+ All Templates for a given Observation Domain MAY also be withdrawn
+ using an All Templates Withdrawal, as shown in Figure U. All Options
+ Templates for a given Observation Domain MAY likewise be withdrawn
+ using an All Options Templates Withdrawal, as shown in Figure V.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 2 | Length = 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 2 | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure U: All Templates Withdrawal Set Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 3 | Length = 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 3 | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure V: All Options Templates Withdrawal Set Format
+
+
+
+
+
+Claise, et al. Standards Track [Page 41]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Template IDs MAY be reused for new Templates by sending a new
+ Template Record or Options Template Record for a given Template ID
+ after withdrawing the Template.
+
+ If a Collecting Process receives a Template Withdrawal for a Template
+ or Options Template it does not presently have stored, this indicates
+ a malfunctioning or improperly implemented Exporting Process. The
+ continued receipt and interpretation of Data Records are still
+ possible, but the Collecting Process MUST ignore the Template
+ Withdrawal and SHOULD log the error.
+
+ If a Collecting Process receives a new Template Record or Options
+ Template Record for an already-allocated Template ID, and that
+ Template or Options Template is identical to the already-received
+ Template or Options Template, it SHOULD log the retransmission;
+ however, this is not an error condition, as it does not affect the
+ interpretation of Data Records.
+
+ If a Collecting Process receives a new Template Record or Options
+ Template Record for an already-allocated Template ID, and that
+ Template or Options Template is different from the already-received
+ Template or Options Template, this indicates a malfunctioning or
+ improperly implemented Exporting Process. The continued receipt and
+ unambiguous interpretation of Data Records for this Template ID are
+ no longer possible, and the Collecting Process SHOULD log the error.
+ Further Collecting Process actions are out of scope for this
+ specification.
+
+8.2. Sequencing Template Management Actions
+
+ Since there is no guarantee of the ordering of exported IPFIX
+ Messages across SCTP Streams or over UDP, an Exporting Process MUST
+ sequence all Template management actions (i.e., Template Records
+ defining new Templates and Template Withdrawals withdrawing them)
+ using the Export Time field in the IPFIX Message Header.
+
+ An Exporting Process MUST NOT export a Data Set described by a new
+ Template in an IPFIX Message with an Export Time before the Export
+ Time of the IPFIX Message containing that Template. If a new
+ Template and a Data Set described by it appear in the same IPFIX
+ Message, the Template Set containing the Template MUST appear before
+ the Data Set in the Message.
+
+ An Exporting Process MUST NOT export any Data Sets described by a
+ withdrawn Template in IPFIX Messages with an Export Time after the
+ Export Time of the IPFIX Message containing the Template Withdrawal
+ withdrawing that Template.
+
+
+
+
+Claise, et al. Standards Track [Page 42]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Put another way, a Template describes Data Records contained in IPFIX
+ Messages when the Export Time of such messages is between a specific
+ start and end time, inclusive. The start time is the Export Time of
+ the IPFIX Message containing the Template Record. The end time is
+ one of two times: if the template is withdrawn during the session,
+ then it is the Export Time of the IPFIX Message containing the
+ Template Withdrawal for the template; otherwise, it is the end of the
+ Transport Session.
+
+ Even if sent in order, IPFIX Messages containing Template management
+ actions could arrive at the Collecting Process out of order, i.e., if
+ sent via UDP or via different SCTP Streams. Given this, Template
+ Withdrawals and subsequent reuse of Template IDs can significantly
+ complicate the problem of determining Template lifetimes at the
+ Collecting Process. A Collecting Process MAY implement a buffer and
+ use Export Time information to disambiguate the order of Template
+ management actions. This buffer, if implemented, SHOULD be
+ configurable to impart a delay on the order of the maximum reordering
+ delay experienced at the Collecting Process. Note, in this case,
+ that the Collecting Process's clock is irrelevant: it is only
+ comparing the Export Times of Messages to each other.
+
+8.3. Additional Considerations for Template Management over SCTP
+
+ The specifications in this section apply only to SCTP; in cases of
+ contradiction with specifications in Section 8 or Section 8.1, this
+ section takes precedence.
+
+ Template Sets and Options Template Sets MAY be sent on any SCTP
+ Stream. Data Sets sent on a given SCTP Stream MAY be represented by
+ Template Records exported on any SCTP Stream.
+
+ Template Sets and Options Template Sets MUST be sent reliably, using
+ SCTP ordered delivery.
+
+ Template Withdrawals MAY be sent on any SCTP Stream. Template
+ Withdrawals MUST be sent reliably, using SCTP ordered delivery.
+ Template IDs MAY be reused by sending a Template Withdrawal and/or a
+ new Template Record on a different SCTP Stream than the stream on
+ which the original Template was sent.
+
+ Additional Template Management considerations are provided in
+ [RFC6526], which specifies an extension to explicitly link Templates
+ with SCTP Streams. In exchange for more restrictive rules on the
+ assignment of Template Records to SCTP Streams, this extension allows
+ fast, reliable reuse of Template IDs and estimation of Data Record
+ loss per Template.
+
+
+
+
+Claise, et al. Standards Track [Page 43]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+8.4. Additional Considerations for Template Management over UDP
+
+ The specifications in this section apply only to UDP; in cases of
+ contradiction with specifications in Section 8 or Section 8.1, this
+ section takes precedence.
+
+ Since UDP provides no method for reliable transmission of Templates,
+ Exporting Processes using UDP as the transport protocol MUST
+ periodically retransmit each active Template at regular intervals.
+ The Template retransmission interval MUST be configurable via, for
+ example, the templateRefreshTimeout and optionsTemplateRefreshTimeout
+ parameters as defined in [RFC6728]. Default settings for these
+ values are deployment- and application-specific.
+
+ Before exporting any Data Records described by a given Template
+ Record or Options Template Record, especially in the case of Template
+ ID reuse as described in Section 8.1, the Exporting Process SHOULD
+ send multiple copies of the Template Record in a separate IPFIX
+ Message, in order to help ensure that the Collecting Process has
+ received it.
+
+ In order to minimize resource requirements for Templates that are no
+ longer being used by the Exporting Process, the Collecting Process
+ MAY associate a lifetime with each Template received in a Transport
+ Session. Templates not refreshed by the Exporting Process within the
+ lifetime can then be discarded by the Collecting Process. The
+ Template lifetime at the Collecting Process MAY be exposed by a
+ configuration parameter or MAY be derived from observation of the
+ interval of periodic Template retransmissions from the Exporting
+ Process. In this latter case, the Template lifetime SHOULD default
+ to at least 3 times the observed retransmission rate.
+
+ Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting
+ Processes exporting via UDP and MUST be ignored by Collecting
+ Processes collecting via UDP. Template IDs MAY be reused by
+ Exporting Processes by exporting a new Template for the Template ID
+ after waiting at least 3 times the retransmission delay. Note that
+ Template ID reuse may lead to incorrect interpretation of Data
+ Records if the retransmission and lifetime are not properly
+ configured.
+
+ When a Collecting Process receives a new Template Record or Options
+ Template Record via UDP for an already-allocated Template ID, and
+ that Template or Options Template is identical to the already-
+ received Template or Options Template, it SHOULD NOT log the
+ retransmission, as this is the normal operation of Template refresh
+ over UDP.
+
+
+
+
+Claise, et al. Standards Track [Page 44]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ When a Collecting Process receives a new Template Record or Options
+ Template Record for an already-allocated Template ID, and that
+ Template or Options Template is different from the already-received
+ Template or Options Template, the Collecting Process MUST replace the
+ Template or Options Template for that Template ID with the newly
+ received Template or Options Template. This is the normal operation
+ of Template ID reuse over UDP.
+
+ As Template IDs are unique per UDP session and per Observation
+ Domain, at any given time, the Collecting Process SHOULD maintain the
+ following for all the current Template Records and Options Template
+ Records: <IPFIX Device, Exporter source UDP port, Collector IP
+ address, Collector destination UDP port, Observation Domain ID,
+ Template ID, Template Definition, Last Received>.
+
+9. The Collecting Process's Side
+
+ This section describes the handling of the IPFIX protocol at the
+ Collecting Process common to all transport protocols. Additional
+ considerations for SCTP and UDP are provided in Sections 9.2 and 9.3,
+ respectively. Template management at Collecting Processes is covered
+ in Section 8.
+
+ The Collecting Process MUST listen for association requests /
+ connections to start new Transport Sessions from the Exporting
+ Process.
+
+ The Collecting Process MUST note the Information Element identifier
+ of any Information Element that it does not understand and MAY
+ discard that Information Element from received Data Records.
+
+ The Collecting Process MUST accept padding in Data Records and
+ Template Records. The padding size is the Set Length minus the size
+ of the Set Header (4 octets for the Set ID and the Set Length),
+ modulo the minimum Record size deduced from the Template Record.
+
+ The IPFIX protocol has a Sequence Number field in the Export header
+ that increases with the number of IPFIX Data Records in the IPFIX
+ Message. A Collector can detect out-of-sequence, dropped, or
+ duplicate IPFIX Messages by tracking the Sequence Number. A
+ Collector SHOULD provide a logging mechanism for tracking out-of-
+ sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be
+ due to Exporter resource exhaustion where it cannot transmit messages
+ at their creation rate, an Exporting Process reset, congestion on the
+ network link between the Exporter and Collector, Collector resource
+ exhaustion where it cannot process the IPFIX Messages at their
+ arrival rate, out-of-order packet reception, duplicate packet
+ reception, or an attacker injecting false messages.
+
+
+
+Claise, et al. Standards Track [Page 45]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+9.1. Collecting Process Handling of Malformed IPFIX Messages
+
+ If the Collecting Process receives a malformed IPFIX Message, it MUST
+ discard the IPFIX Message and SHOULD log the error. A malformed
+ IPFIX Message is one that cannot be interpreted due to nonsensical
+ length values (e.g., a variable-length Information Element longer
+ than its enclosing Set, a Set longer than its enclosing IPFIX
+ Message, or an IPFIX Message shorter than an IPFIX Message Header) or
+ a reserved Version value (which may indicate that a future version of
+ IPFIX is being used for export but in practice occurs most often when
+ non-IPFIX data is sent to an IPFIX Collecting Process). Note that
+ non-zero Set padding does not constitute a malformed IPFIX Message.
+
+ As the most likely cause of malformed IPFIX Messages is a poorly
+ implemented Exporting Process, or the sending of non-IPFIX data to an
+ IPFIX Collecting Process, human intervention is likely necessary to
+ correct the issue. In the meantime, the Collecting Process MAY
+ attempt to rectify the situation any way it sees fit, including:
+
+ - terminating the TCP connection or SCTP connection
+
+ - using the receiver window to reduce network load from the
+ malfunctioning Exporting Process
+
+ - buffering and saving malformed IPFIX Message(s) to assist in
+ diagnosis
+
+ - attempting to resynchronize the stream, e.g., as described in
+ Section 10.3 of [RFC5655]
+
+ Resynchronization should only be attempted if the Collecting Process
+ has reason to believe that the error is transient. On the other
+ hand, the Collecting Process SHOULD stop processing IPFIX Messages
+ from clearly malfunctioning Exporting Processes (e.g., those from
+ which the last few IPFIX Messages have been malformed).
+
+9.2. Additional Considerations for SCTP Collecting Processes
+
+ As an Exporting Process may request and support more than one stream
+ per SCTP association, the Collecting Process MUST support the opening
+ of multiple SCTP Streams.
+
+9.3. Additional Considerations for UDP Collecting Processes
+
+ A Transport Session for IPFIX Messages transported over UDP is
+ defined from the point of view of the Exporting Process and roughly
+ corresponds to the time during which a given Exporting Process sends
+ IPFIX Messages over UDP to a given Collecting Process. Since this is
+
+
+
+Claise, et al. Standards Track [Page 46]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ difficult to detect at the Collecting Process, the Collecting Process
+ MAY discard all Transport Session state after no IPFIX Messages are
+ received from a given Exporting Process within a given Transport
+ Session during a configurable idle timeout.
+
+ The Collecting Process SHOULD accept Data Records without the
+ associated Template Record (or other definitions such as Common
+ Properties) required to decode the Data Record. If the Template
+ Records or other definitions have not been received at the time Data
+ Records are received, the Collecting Process MAY store the Data
+ Records for a short period of time and decode them after the Template
+ Records or other definitions are received, comparing Export Times of
+ IPFIX Messages containing the Template Records with those containing
+ the Data Records as discussed in Section 8.2. Note that this
+ mechanism may lead to incorrectly interpreted records in the presence
+ of Template ID reuse or other identifiers with limited lifetimes.
+
+10. Transport Protocol
+
+ The IPFIX Protocol Specification has been designed to be transport
+ protocol independent. Note that the Exporter can export to multiple
+ Collecting Processes using independent transport protocols.
+
+ The IPFIX Message Header 16-bit Length field limits the length of an
+ IPFIX Message to 65535 octets, including the header. A Collecting
+ Process MUST be able to handle IPFIX Message lengths of up to
+ 65535 octets.
+
+ While an Exporting Process or Collecting Process may support multiple
+ transport protocols, Transport Sessions are bound to a transport
+ protocol. Transport Session state MUST NOT be migrated by an
+ Exporting Process or Collecting Process among Transport Sessions
+ using different transport protocols between the same Exporting
+ Process and Collecting Process pair. In other words, an Exporting
+ Process supporting multiple transport protocols is conceptually
+ multiple Exporting Processes, one per supported transport protocol.
+ Likewise, a Collecting Process supporting multiple transport
+ protocols is conceptually multiple Collecting Processes, one per
+ supported transport protocol.
+
+10.1. Transport Compliance and Transport Usage
+
+ SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension
+ as specified in [RFC3758] MUST be implemented by all compliant
+ implementations. UDP [UDP] MAY also be implemented by compliant
+ implementations. TCP [TCP] MAY also be implemented by compliant
+ implementations.
+
+
+
+
+Claise, et al. Standards Track [Page 47]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ SCTP should be used in deployments where Exporters and Collectors are
+ communicating over links that are susceptible to congestion. SCTP is
+ capable of providing any required degree of reliability when used
+ with the PR-SCTP extension.
+
+ TCP may be used in deployments where Exporters 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 the Exporter and
+ Collector must be separately contained or provisioned to minimize the
+ risk of congestion-related loss.
+
+ By default, the Collecting Process listens for connections on SCTP,
+ TCP, and/or UDP port 4739. By default, the Collecting Process
+ listens for secure connections on SCTP, TCP, and/or UDP port 4740
+ (refer to the Security Considerations section). By default, the
+ Exporting Process attempts to connect to one of these ports. It MUST
+ be possible to configure both the Exporting and Collecting Processes
+ to use different ports than the default.
+
+10.2. SCTP
+
+ This section describes how IPFIX is transported over SCTP [RFC4960]
+ using the PR-SCTP [RFC3758] extension.
+
+10.2.1. Congestion Avoidance
+
+ SCTP provides the required level of congestion avoidance by design.
+
+ SCTP detects congestion in the end-to-end path between the IPFIX
+ Exporting Process and the IPFIX Collecting Process, and limits the
+ transfer rate accordingly. When an IPFIX Exporting Process has
+ records to export but detects that transmission by SCTP is
+ temporarily impossible, it can either wait until sending is possible
+ again or decide to drop the record. In the latter case, the dropped
+ export data SHOULD be accounted for, so that the amount of dropped
+ export data can be reported using the mechanism described in
+ Section 4.3.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 48]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+10.2.2. Reliability
+
+ The SCTP transport protocol is by default reliable but has the
+ capability to deliver messages with partial reliability [RFC3758].
+
+ Using reliable SCTP messages for IPFIX export is not in itself a
+ guarantee that all Data Records will be delivered. If there is
+ congestion on the link from the Exporting Process to the Collecting
+ Process, or if a significant number of retransmissions are required,
+ the send queues on the Exporting Process may fill up; the Exporting
+ Process MAY either suspend, export, or discard the IPFIX Messages.
+ If Data Records are discarded, the IPFIX Sequence Numbers used for
+ export MUST reflect the loss of data.
+
+10.2.3. MTU
+
+ SCTP provides the required IPFIX Message fragmentation service based
+ on Path MTU (PMTU) discovery.
+
+10.2.4. Association Establishment and Shutdown
+
+ The IPFIX Exporting Process initiates an SCTP association with the
+ IPFIX Collecting Process. The Exporting Process MAY establish more
+ than one association (connection "bundle" in SCTP terminology) to the
+ Collecting Process.
+
+ An Exporting Process MAY support more than one active association to
+ different Collecting Processes (including the case of different
+ Collecting Processes on the same host).
+
+ When an Exporting Process is shut down, it SHOULD shut down the SCTP
+ association.
+
+ When a Collecting Process no longer wants to receive IPFIX Messages,
+ it SHOULD shut down its end of the association. The Collecting
+ Process SHOULD continue to receive and process IPFIX Messages until
+ the Exporting Process has closed its end of the association.
+
+ When a Collecting Process detects that the SCTP association has been
+ abnormally terminated, it MUST continue to listen for a new
+ association establishment.
+
+ When an Exporting Process detects that the SCTP association to the
+ Collecting Process is abnormally terminated, it SHOULD try to
+ re-establish the association.
+
+ Association timeouts SHOULD be configurable.
+
+
+
+
+Claise, et al. Standards Track [Page 49]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+10.2.5. Failover
+
+ If the Collecting Process does not acknowledge an attempt by the
+ Exporting Process to establish an association, SCTP will
+ automatically retry association establishment using exponential
+ backoff. The Exporter MAY log an alarm if the underlying SCTP
+ association establishment times out; this timeout should be
+ configurable on the Exporter.
+
+ The Exporting Process MAY open a backup SCTP association to a
+ Collecting Process in advance, if it supports Collecting Process
+ failover.
+
+10.2.6. Streams
+
+ An Exporting Process MAY request more than one SCTP Stream per
+ association. Each of these streams may be used for the transmission
+ of IPFIX Messages containing Data Sets, Template Sets, and/or Options
+ Template Sets.
+
+ Depending on the requirements of the application, the Exporting
+ Process may send Data Sets with full or partial reliability, using
+ ordered or out-of-order delivery, over any SCTP Stream established
+ during SCTP association setup.
+
+ An IPFIX Exporting Process MAY use any PR-SCTP service definition as
+ per Section 4 of the PR-SCTP specification [RFC3758] when using
+ partial reliability to transmit IPFIX Messages containing only
+ Data Sets.
+
+ However, Exporting Processes SHOULD mark such IPFIX Messages for
+ retransmission for as long as resource or other constraints allow.
+
+10.3. UDP
+
+ This section describes how IPFIX is transported over UDP [UDP].
+
+10.3.1. Congestion Avoidance
+
+ UDP has no integral congestion-avoidance mechanism. Its use over
+ congestion-sensitive network paths is therefore not recommended. UDP
+ MAY be used in deployments where Exporters and Collectors always
+ communicate over dedicated links that are not susceptible to
+ congestion, i.e., links that are over-provisioned compared to the
+ maximum export rate from the Exporters.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 50]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+10.3.2. Reliability
+
+ UDP is not a reliable transport protocol and cannot guarantee
+ delivery of messages. IPFIX Messages sent from the Exporting Process
+ to the Collecting Process using UDP may therefore be lost. UDP MUST
+ NOT be used unless the application can tolerate some loss of IPFIX
+ Messages.
+
+ The Collecting Process SHOULD deduce the loss and reordering of IPFIX
+ Data Records by looking at the discontinuities in the IPFIX Sequence
+ Number. In the case of UDP, the IPFIX Sequence Number contains the
+ total number of IPFIX Data Records sent for the Transport Session
+ prior to the receipt of this IPFIX Message, modulo 2^32. A Collector
+ SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
+ by tracking the Sequence Number.
+
+ Exporting Processes exporting IPFIX Messages via UDP MUST include a
+ valid UDP checksum [UDP] in UDP datagrams including IPFIX Messages.
+
+10.3.3. MTU
+
+ The maximum size of exported messages MUST be configured such that
+ the total packet size does not exceed the PMTU. If the PMTU is
+ unknown, a maximum packet size of 512 octets SHOULD be used.
+
+10.3.4. Session Establishment and Shutdown
+
+ As UDP is a connectionless protocol, there is no real session
+ establishment or shutdown for IPFIX over UDP. An Exporting Process
+ starts sending IPFIX Messages to a Collecting Process at one point in
+ time and stops sending them at another point in time. This can lead
+ to some complications in Template management, as outlined in
+ Section 8.4 above.
+
+10.3.5. Failover and Session Duplication
+
+ Because UDP is not a connection-oriented protocol, the Exporting
+ Process is unable to determine from the transport protocol that the
+ Collecting Process is no longer able to receive the IPFIX Messages.
+ Therefore, it cannot invoke a failover mechanism. However, the
+ Exporting Process MAY duplicate the IPFIX Message to several
+ Collecting Processes.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 51]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+10.4. TCP
+
+ This section describes how IPFIX is transported over TCP [TCP].
+
+10.4.1. Congestion Avoidance
+
+ TCP controls the rate at which data can be sent from the Exporting
+ Process to the Collecting Process, using a mechanism that takes into
+ account both congestion in the network and the capabilities of the
+ receiver.
+
+ Therefore, an IPFIX Exporting Process may not be able to send IPFIX
+ Messages at the rate that the Metering Process generates them, either
+ because of congestion in the network or because the Collecting
+ Process cannot handle IPFIX Messages fast enough. As long as
+ congestion is transient, the Exporting Process can buffer IPFIX
+ Messages for transmission. But such buffering is necessarily
+ limited, both because of resource limitations and because of
+ timeliness requirements, so ongoing and/or severe congestion may lead
+ to a situation where the Exporting Process is blocked.
+
+ When an Exporting Process has Data Records to export but the
+ transmission buffer is full, and it wants to avoid blocking, it can
+ decide to drop some Data Records. The dropped Data Records MUST be
+ accounted for, so that the number of lost records can later be
+ reported as described in Section 4.3.
+
+10.4.2. Reliability
+
+ TCP ensures reliable delivery of data from the Exporting Process to
+ the Collecting Process.
+
+10.4.3. MTU
+
+ As TCP offers a stream service instead of a datagram or sequential
+ packet service, IPFIX Messages transported over TCP are instead
+ separated using the Length field in the IPFIX Message Header. The
+ Exporting Process can choose any valid length for exported IPFIX
+ Messages, as TCP handles segmentation.
+
+ Exporting Processes may choose IPFIX Message lengths lower than the
+ maximum in order to ensure timely export of Data Records.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 52]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+10.4.4. Connection Establishment and Shutdown
+
+ The IPFIX Exporting Process initiates a TCP connection to the
+ Collecting Process. An Exporting Process MAY support more than one
+ active connection to different Collecting Processes (including the
+ case of different Collecting Processes on the same host). An
+ Exporting Process MAY support more than one active connection to the
+ same Collecting Process to avoid head-of-line blocking across
+ Observation Domains.
+
+ The Exporter MAY log an alarm if the underlying TCP connection
+ establishment times out; this timeout should be configurable on the
+ Exporter.
+
+ When an Exporting Process is shut down, it SHOULD shut down the TCP
+ connection.
+
+ When a Collecting Process no longer wants to receive IPFIX Messages,
+ it SHOULD close its end of the connection. The Collecting Process
+ SHOULD continue to read IPFIX Messages until the Exporting Process
+ has closed its end.
+
+ When a Collecting Process detects that the TCP connection to the
+ Exporting Process has terminated abnormally, it MUST continue to
+ listen for a new connection.
+
+ When an Exporting Process detects that the TCP connection to the
+ Collecting Process has terminated abnormally, it SHOULD try to
+ re-establish the connection. Connection timeouts and retry schedules
+ SHOULD be configurable. In the default configuration, an Exporting
+ Process MUST NOT attempt to establish a connection more frequently
+ than once per minute.
+
+10.4.5. Failover
+
+ If the Collecting Process does not acknowledge an attempt by the
+ Exporting Process to establish a connection, TCP will automatically
+ retry connection establishment using exponential backoff. The
+ Exporter MAY log an alarm if the underlying TCP connection
+ establishment times out; this timeout should be configurable on the
+ Exporter.
+
+ The Exporting Process MAY open a backup TCP connection to a
+ Collecting Process in advance, if it supports Collecting Process
+ failover.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 53]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+11. Security Considerations
+
+ The security considerations for the IPFIX protocol have been derived
+ from an analysis of potential security threats, as discussed in the
+ Security Considerations section of the IPFIX requirements document
+ [RFC3917]. The requirements for IPFIX security are as follows:
+
+ 1. IPFIX must provide a mechanism to ensure the confidentiality of
+ IPFIX data transferred from an Exporting Process to a Collecting
+ Process, in order to prevent disclosure of Flow Records
+ transported via IPFIX.
+
+ 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX
+ data transferred from an Exporting Process to a Collecting
+ Process, in order to prevent the injection of incorrect data or
+ control information (e.g., Templates), or the duplication of
+ Messages, in an IPFIX Message stream.
+
+ 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting
+ and Exporting Processes, to prevent the collection of data from an
+ unauthorized Exporting Process or the export of data to an
+ unauthorized Collecting Process.
+
+ Because IPFIX can be used to collect information for network
+ forensics and billing purposes, attacks designed to confuse, disable,
+ or take information from an IPFIX collection system may be seen as a
+ prime objective during a sophisticated network attack.
+
+ An attacker in a position to inject false messages into an IPFIX
+ Message stream can affect either the application using IPFIX (by
+ falsifying data) or the IPFIX Collecting Process itself (by modifying
+ or revoking Templates, or changing options); for this reason, IPFIX
+ Message integrity is important.
+
+ The IPFIX Messages themselves may also contain information of value
+ to an attacker, including information about the configuration of the
+ network as well as end-user traffic and payload data, so care must be
+ taken to confine their visibility to authorized users. When an
+ Information Element containing end-user payload information is
+ exported, it SHOULD be transmitted to the Collecting Process using a
+ means that secures its contents against eavesdropping. Suitable
+ mechanisms include the use of either a direct point-to-point
+ connection assumed to be unavailable to attackers, or the use of an
+ encryption mechanism. It is the responsibility of the Collecting
+ Process to provide a satisfactory degree of security for this
+ collected data, including, if necessary, encryption and/or
+ anonymization of any reported data; see Section 11.8.
+
+
+
+
+Claise, et al. Standards Track [Page 54]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+11.1. Applicability of TLS and DTLS
+
+ Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer
+ Security (DTLS) [RFC6347] were designed to provide the
+ confidentiality, integrity, and authentication assurances required by
+ the IPFIX protocol, without the need for pre-shared keys.
+
+ IPFIX Exporting Processes and Collecting Processes using TCP MUST
+ support TLS version 1.1 and SHOULD support TLS version 1.2 [RFC5246],
+ including the mandatory ciphersuite(s) specified in each version.
+ IPFIX Exporting Processes and Collecting Processes using UDP or SCTP
+ MUST support DTLS version 1.0 and SHOULD support DTLS version 1.2
+ [RFC6347], including the mandatory ciphersuite(s) specified in each
+ version.
+
+ Note that DTLS is selected as the security mechanism for SCTP.
+ Though TLS bindings to SCTP are defined in [RFC3436], they require
+ that all communication be over reliable, bidirectional streams, and
+ they also require one TLS connection per stream. This arrangement is
+ not compatible with the rationale behind the choice of SCTP as an
+ IPFIX transport protocol.
+
+ Note that using DTLS has a man-in-the-middle vulnerability not
+ present in TLS, allowing a message to be removed from the stream
+ without the knowledge of either the sender or receiver.
+ Additionally, when using DTLS over SCTP, an attacker could inject
+ SCTP control information and shut down the SCTP association, causing
+ a loss of IPFIX Messages if those messages are buffered outside of
+ the SCTP association. Techniques such as those described in
+ [RFC6083] could be used to overcome these vulnerabilities.
+
+ When using DTLS over SCTP, the Exporting Process MUST ensure that
+ each IPFIX Message is sent over the same SCTP Stream that would be
+ used when sending the same IPFIX Message directly over SCTP. Note
+ that DTLS may send its own control messages on stream 0 with full
+ reliability; however, this will not interfere with the processing of
+ stream 0 IPFIX Messages at the Collecting Process, because DTLS
+ consumes its own control messages before passing IPFIX Messages up to
+ the application layer.
+
+ When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520]
+ SHOULD be used, especially on long-lived Transport Sessions, to
+ ensure that the association remains active.
+
+ Exporting and Collecting Processes MUST NOT request, offer, or use
+ any version of the Secure Socket Layer (SSL), or any version of TLS
+ prior to 1.1, due to known security vulnerabilities in prior versions
+ of TLS; see Appendix E of [RFC5246] for more information.
+
+
+
+Claise, et al. Standards Track [Page 55]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+11.2. Usage
+
+ The IPFIX Exporting Process initiates the communication to the IPFIX
+ Collecting Process and acts as a TLS or DTLS client according to
+ [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a
+ TLS or DTLS server. The DTLS client opens a secure connection on
+ SCTP port 4740 of the DTLS server if SCTP is selected as the
+ transport protocol. The TLS client opens a secure connection on TCP
+ port 4740 of the TLS server if TCP is selected as the transport
+ protocol. The DTLS client opens a secure connection on UDP port 4740
+ of the DTLS server if UDP is selected as the transport protocol.
+
+11.3. Mutual Authentication
+
+ When using TLS or DTLS, IPFIX Exporting Processes and IPFIX
+ Collecting Processes SHOULD be identified by a certificate containing
+ the DNS-ID as discussed in Section 6.4 of [RFC6125]; the inclusion of
+ Common Names (CN-IDs) in certificates identifying IPFIX Exporting
+ Processes or Collecting Processes is NOT RECOMMENDED.
+
+ To prevent man-in-the-middle attacks from impostor Exporting or
+ Collecting Processes, the acceptance of data from an unauthorized
+ Exporting Process, or the export of data to an unauthorized
+ Collecting Process, mutual authentication MUST be used for both TLS
+ and DTLS. Exporting Processes MUST verify the reference identifiers
+ of the Collecting Processes to which they are exporting IPFIX
+ Messages against those stored in the certificates. Likewise,
+ Collecting Processes MUST verify the reference identifiers of the
+ Exporting Processes from which they are receiving IPFIX Messages
+ against those stored in the certificates. Exporting Processes MUST
+ NOT export to non-verified Collecting Processes, and Collecting
+ Processes MUST NOT accept IPFIX Messages from non-verified Exporting
+ Processes.
+
+ Exporting Processes and Collecting Processes MUST support the
+ verification of certificates against an explicitly authorized list of
+ peer certificates identified by Common Name and SHOULD support the
+ verification of reference identifiers by matching the DNS-ID or CN-ID
+ with a DNS lookup of the peer.
+
+ IPFIX Exporting Processes and Collecting Processes MUST use non-NULL
+ ciphersuites for authentication, integrity, and confidentiality.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 56]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+11.4. Protection against DoS Attacks
+
+ An attacker may mount a denial-of-service (DoS) attack against an
+ IPFIX collection system either directly, by sending large amounts of
+ traffic to a Collecting Process, or indirectly, by generating large
+ amounts of traffic to be measured by a Metering Process.
+
+ Direct DoS attacks can also involve state exhaustion, whether at the
+ transport layer (e.g., by creating a large number of pending
+ connections) or within the IPFIX Collecting Process itself (e.g., by
+ sending Flow Records pending Template or scope information, or a
+ large amount of Options Template Records, etc.).
+
+ SCTP mandates a cookie-exchange mechanism designed to defend against
+ SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN
+ cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be
+ used by any Collecting Process accepting TCP connections. DTLS also
+ provides cookie exchange to protect against DTLS server state
+ exhaustion.
+
+ The reader should note that there is no way to prevent fake IPFIX
+ Message processing (and state creation) for UDP and SCTP
+ communication. The use of TLS and DTLS can obviously prevent the
+ creation of fake states, but they are themselves prone to state
+ exhaustion attacks. Therefore, Collector rate limiting SHOULD be
+ used to protect TLS and DTLS (like limiting the number of new TLS or
+ DTLS sessions per second to a sensible number).
+
+ IPFIX state exhaustion attacks can be mitigated by limiting the rate
+ at which new connections or associations will be opened by the
+ Collecting Process; limiting the rate at which IPFIX Messages will be
+ accepted by the Collecting Process; and adaptively limiting the
+ amount of state kept, particularly for records waiting for Templates.
+ These rate and state limits MAY be provided by a Collecting Process,
+ and if provided, the limits SHOULD be user configurable.
+
+ Additionally, an IPFIX Collecting Process can eliminate the risk of
+ state exhaustion attacks from untrusted nodes by requiring TLS or
+ DTLS mutual authentication, causing the Collecting Process to accept
+ IPFIX Messages only from trusted sources.
+
+ With respect to indirect denial of service, the behavior of IPFIX
+ under overload conditions depends on the transport protocol in use.
+ For IPFIX over TCP, TCP congestion control would cause the flow of
+ IPFIX Messages to back off and eventually stall, blinding the IPFIX
+ system. SCTP improves upon this situation somewhat, as some IPFIX
+ Messages would continue to be received by the Collecting Process due
+ to the avoidance of head-of-line blocking by SCTP's multiple streams
+
+
+
+Claise, et al. Standards Track [Page 57]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ and partial reliability features, possibly affording some visibility
+ of the attack. The situation is similar with UDP, as some datagrams
+ may continue to be received at the Collecting Process, effectively
+ applying sampling to the IPFIX Message stream and implying that some
+ information about the attack will be available.
+
+ To minimize IPFIX Message loss under overload conditions, some
+ mechanism for service differentiation could be used to prioritize
+ IPFIX traffic over other traffic on the same link. Alternatively,
+ IPFIX Messages can be transported over a dedicated network. In this
+ case, care must be taken to ensure that the dedicated network can
+ handle the expected peak IPFIX Message traffic.
+
+11.5. When DTLS or TLS Is Not an Option
+
+ The use of DTLS or TLS might not be possible in some cases, due to
+ performance issues or other operational concerns.
+
+ Without TLS or DTLS mutual authentication, IPFIX Exporting Processes
+ and Collecting Processes can fall back on using IP source addresses
+ to authenticate their peers. A policy of allocating Exporting
+ Process and Collecting Process IP addresses from specified address
+ ranges, and using ingress filtering to prevent spoofing, can improve
+ the usefulness of this approach. Again, completely segregating IPFIX
+ traffic on a dedicated network, where possible, can improve security
+ even further. In any case, the use of open Collecting Processes
+ (those that will accept IPFIX Messages from any Exporting Process
+ regardless of IP address or identity) is discouraged.
+
+ Modern TCP and SCTP implementations are resistant to blind insertion
+ attacks (see [RFC4960] and [RFC6528]); however, UDP offers no such
+ protection. For this reason, IPFIX Message traffic transported via
+ UDP and not secured via DTLS SHOULD be protected via segregation to a
+ dedicated network.
+
+11.6. Logging an IPFIX Attack
+
+ IPFIX Collecting Processes MUST detect potential IPFIX Message
+ insertion or loss conditions by tracking the IPFIX Sequence Number
+ and SHOULD provide a logging mechanism for reporting out-of-sequence
+ messages. Note that an attacker may be able to exploit the handling
+ of out-of-sequence messages at the Collecting Process, so care should
+ be taken in handling these conditions. For example, a Collecting
+ Process that simply resets the expected Sequence Number upon receipt
+ of a later Sequence Number could be temporarily blinded by deliberate
+ injection of later Sequence Numbers.
+
+
+
+
+
+Claise, et al. Standards Track [Page 58]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ IPFIX Exporting and Collecting Processes SHOULD log any connection
+ attempt that fails due to authentication failure, whether due to
+ being presented an unauthorized or mismatched certificate during TLS
+ or DTLS mutual authentication, or due to a connection attempt from an
+ unauthorized IP address when TLS or DTLS is not in use.
+
+ IPFIX Exporting and Collecting Processes SHOULD detect and log any
+ SCTP association reset or TCP connection reset.
+
+11.7. Securing the Collector
+
+ The security of the Collector and its implementation is important to
+ achieve overall security; however, a complete set of security
+ guidelines for Collector implementation is outside the scope of this
+ document.
+
+ As IPFIX uses length-prefix encodings, Collector implementors should
+ take care to ensure the detection of inconsistent values that could
+ impact IPFIX Message decoding, and proper operation in the presence
+ of such inconsistent values.
+
+ Specifically, IPFIX Message, Set, and variable-length Information
+ Element lengths must be checked for consistency to avoid buffer-
+ sizing vulnerabilities.
+
+ Collector implementors should also pay special attention to UTF-8
+ encoding of string data types, as vulnerabilities may exist in the
+ interpretation of ill-formed UTF-8 values; see Section 6.1.6.
+
+11.8. Privacy Considerations for Collected Data
+
+ Flow data exported by Exporting Processes and collected by Collecting
+ Processes typically contains information about traffic on the
+ observed network. This information may be personally identifiable
+ and privacy-sensitive. The storage of this data must be protected
+ via technical as well as policy means to ensure that the privacy of
+ the users of the measured network is protected. A complete
+ specification of such means is out of scope for this document and is
+ specific to the application and storage technology used.
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 59]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+12. Management Considerations
+
+ [RFC6615] specifies a MIB module that defines managed objects for
+ monitoring IPFIX Devices, including basic configuration. This MIB
+ can be used to measure the impact of IPFIX export on the monitoring
+ network; it contains tables covering:
+
+ Transport Session,
+ Cache definition,
+ Observation Point definition,
+ Template and Options Template definition,
+ export features (failover, load-balancing, duplicate), and
+ export statistics per Process, Session, and Template
+
+ From an operational aspect, an important function of this MIB module
+ is provided by the Transport Session Statistical table, which
+ contains the rate (in bytes per second) at which the Collector
+ receives or the Exporter sends out IPFIX Messages. Of particular
+ interest to operations, the Transport Session Statistical table in
+ Section 5.8.1 of this MIB module exposes the rate of collection or
+ export of IPFIX Messages, which allows the measurement of the
+ bandwidth used by IPFIX export.
+
+ [RFC6727] describes extensions to the IPFIX-SELECTOR-MIB module
+ specified in [RFC6615] and contains managed objects for providing
+ information on applied packet selection functions and their
+ parameters (filtering and sampling).
+
+ Since the IPFIX-SELECTOR-MIB [RFC6615] and PSAMP-MIB [RFC6727]
+ modules only contain read-only objects, they cannot be used for
+ configuration of IPFIX Devices. [RFC6728] specifies a configuration
+ data model for the IPFIX and PSAMP protocols, using the Network
+ Configuration Protocol (NETCONF). This data model covers Selection
+ Processes, Caches, Exporting Processes, and Collecting Processes on
+ IPFIX and PSAMP Devices, and is defined using UML (Unified Modeling
+ Language) class diagrams and formally specified using YANG. The
+ configuration data is encoded in Extensible Markup Language (XML).
+
+ A few mechanisms specified alongside the IPFIX protocol can help
+ monitor and reduce bandwidth used for IPFIX Export:
+
+ - a bandwidth-saving method for exporting redundant information in
+ IPFIX [RFC5473]
+
+ - an efficient method for exporting bidirectional flows [RFC5103]
+
+ - a method for the definition and export of complex data structures
+ [RFC6313]
+
+
+
+Claise, et al. Standards Track [Page 60]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ Alternatively, PSAMP [RFC5474] can be used to export packets sampled
+ by statistical and other methods, which may be applicable to many
+ monitoring areas for which IPFIX is also suited. PSAMP also provides
+ control over the impact on the measured network through its sampling
+ rate. The set of packet selection techniques (Sampling, Filtering,
+ and hashing) standardized by PSAMP is described in [RFC5475]. PSAMP
+ also defines an explicitly configurable export rate limit in
+ Section 8.4 of [RFC5474].
+
+13. IANA Considerations
+
+ IANA has updated the "IPFIX Information Elements" registry
+ [IANA-IPFIX] so that all references that previously pointed to
+ RFC 5101 now point to this document instead.
+
+ IPFIX Messages use two fields with assigned values. These are the
+ IPFIX Version Number, indicating which version of the IPFIX protocol
+ was used to export an IPFIX Message, and the IPFIX Set ID, indicating
+ the type for each set of information within an IPFIX Message.
+
+ The Information Elements used by IPFIX, and sub-registries of
+ Information Element values, are managed by IANA [IANA-IPFIX], as are
+ the Private Enterprise Numbers used by enterprise-specific
+ Information Elements [IANA-PEN]. This document makes no changes to
+ these registries.
+
+ The IPFIX Version Number value of 0x000a (10) is reserved for the
+ IPFIX protocol specified in this document. Set ID values of 0 and 1
+ are not used, for historical reasons [RFC3954]. The Set ID value of
+ 2 is reserved for the Template Set. The Set ID value of 3 is
+ reserved for the Options Template Set. All other Set ID values from
+ 4 to 255 are reserved for future use. Set ID values above 255 are
+ used for Data Sets.
+
+ New assignments in either the "IPFIX Version Number" or "IPFIX Set
+ IDs" sub-registries require a Standards Action [RFC5226], i.e., they
+ are to be made via Standards Track RFCs approved by the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 61]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Appendix A. IPFIX Encoding Examples
+
+ This appendix, which is a not a normative reference, contains IPFIX
+ encoding examples.
+
+ Let's consider the example of an IPFIX Message composed of a Template
+ Set, a Data Set (which contains three Data Records), an Options
+ Template Set, and another Data Set (which contains two Data Records
+ related to the previous Options Template Record).
+
+ IPFIX Message:
+
+ +--------+------------------------------------------. . .
+ | | +--------------+ +------------------+
+ |Message | | Template | | Data |
+ | Header | | Set | | Set | . . .
+ | | | (1 Template) | | (3 Data Records) |
+ | | +--------------+ +------------------+
+ +--------+------------------------------------------. . .
+
+ . . .-------------------------------------------+
+ +------------------+ +------------------+ |
+ | Options | | Data | |
+ . . . | Template Set | | Set | |
+ | (1 Template) | | (2 Data Records) | |
+ +------------------+ +------------------+ |
+ . . .-------------------------------------------+
+
+A.1. Message Header Example
+
+ The Message Header is composed of:
+
+ 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 = 0x000a | Length = 152 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Export Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Observation Domain ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 62]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+A.2. Template Set Examples
+
+A.2.1. Template Set Using IANA Information Elements
+
+ We want to report the following Information Elements:
+
+ - IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a
+ length of 4 octets
+
+ - IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX],
+ with a length of 4 octets
+
+ - Next-hop IP address (IPv4): ipNextHopIPv4Address [IANA-IPFIX], with
+ a length of 4 octets
+
+ - Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with
+ a length of 4 octets
+
+ - Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a
+ length of 4 octets
+
+ Therefore, the Template Set will be composed of the following:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 2 | Length = 28 octets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID 256 | Field Count = 5 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| sourceIPv4Address = 8 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| destinationIPv4Address = 12 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| packetDeltaCount = 2 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| octetDeltaCount = 1 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 63]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+A.2.2. Template Set Using Enterprise-Specific Information Elements
+
+ We want to report the following Information Elements:
+
+ - IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a
+ length of 4 octets
+
+ - IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX],
+ with a length of 4 octets
+
+ - An enterprise-specific Information Element representing proprietary
+ information, with a type of 15 and a length of 4 octets
+
+ - Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with
+ a length of 4 octets
+
+ - Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a
+ length of 4 octets
+
+ Therefore, the Template Set will be composed of the following:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 2 | Length = 32 octets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID 257 | Field Count = 5 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| sourceIPv4Address = 8 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| destinationIPv4Address = 12 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| Information Element id. = 15| Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| packetDeltaCount = 2 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| octetDeltaCount = 1 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 64]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+A.3. Data Set Example
+
+ In this example, we report the following three Flow Records:
+
+ Src IP Addr. | Dst IP Addr. | Next-Hop Addr. | Packet | Octets
+ | | | Number | Number
+ ----------------------------------------------------------------
+ 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
+ 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
+ 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 256 | Length = 64 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.12 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.254 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5009 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5344385 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.27 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.23 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 748 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 388934 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.56 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.65 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 192.0.2.3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 6534 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Note that padding is not necessary in this example.
+
+
+
+Claise, et al. Standards Track [Page 65]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+A.4. Options Template Set Examples
+
+A.4.1. Options Template Set Using IANA Information Elements
+
+ Per line card (the router being composed of two line cards), we want
+ to report the following Information Elements:
+
+ - Total number of IPFIX Messages: exportedMessageTotalCount
+ [IANA-IPFIX], with a length of 2 octets
+
+ - Total number of exported Flows: exportedFlowRecordTotalCount
+ [IANA-IPFIX], with a length of 2 octets
+
+ The line card, which is represented by the lineCardId Information
+ Element [IANA-IPFIX], is used as the Scope Field.
+
+ Therefore, the Options Template Set will be:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 3 | Length = 24 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID 258 | Field Count = 3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count = 1 |0| lineCardId = 141 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.2. Options Template Set Using Enterprise-Specific Information
+ Elements
+
+ Per line card (the router being composed of two line cards), we want
+ to report the following Information Elements:
+
+ - Total number of IPFIX Messages: exportedMessageTotalCount
+ [IANA-IPFIX], with a length of 2 octets
+
+ - An enterprise-specific number of exported Flows, with a type of 42
+ and a length of 4 octets
+
+ The line card, which is represented by the lineCardId Information
+ Element [IANA-IPFIX], is used as the Scope Field.
+
+
+
+Claise, et al. Standards Track [Page 66]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The format of the Options Template Set is as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 3 | Length = 28 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID 259 | Field Count = 3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count = 1 |0| lineCardId = 141 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |1|Information Element id. = 42 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 4 | Enterprise number ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Enterprise number | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.3. Options Template Set Using an Enterprise-Specific Scope
+
+ In this example, we want to export the same information as in the
+ example in Appendix A.4.1:
+
+ - Total number of IPFIX Messages: exportedMessageTotalCount
+ [IANA-IPFIX], with a length of 2 octets
+
+ - Total number of exported Flows: exportedFlowRecordTotalCount
+ [IANA-IPFIX], with a length of 2 octets
+
+ But this time, the information pertains to a proprietary scope,
+ identified by enterprise-specific Information Element number 123.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 67]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ The format of the Options Template Set is now as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 3 | Length = 28 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID 260 | Field Count = 3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count = 1 |1|Scope 1 Infor. El. id. = 123 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope 1 Field Length = 4 | Enterprise Number ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ... Enterprise Number |0|exportedMessageTotalCount=41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |0|exportedFlowRecordTotalCo.=42|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 | Padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.4. Data Set Using an Enterprise-Specific Scope
+
+ In this example, we report the following two Data Records:
+
+ Enterprise field 123 | IPFIX Message | Exported Flow Records
+ ---------------------------------------------------------------
+ 1 | 345 | 10201
+ 2 | 690 | 20402
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 260 | Length = 20 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 345 | 10201 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 690 | 20402 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 68]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+A.5. Variable-Length Information Element Examples
+
+A.5.1. Example of Variable-Length Information Element with Length
+ Less Than 255 Octets
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5 | 5-octet Information Element |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.5.2. Example of Variable-Length Information Element with 3-Octet
+ Length Encoding
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 255 | 1000 | IE ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 1000-octet Information Element |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ : ... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... IE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 69]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Normative References
+
+ [IANA-IPFIX]
+ IANA, "IP Flow Information Export (IPFIX) Entities",
+ <http://www.iana.org/assignments/ipfix/>.
+
+ [RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation
+ Standard", RFC 1014, June 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
+ Layer Security over Stream Control Transmission Protocol",
+ RFC 3436, December 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of
+ ISO 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+ Conrad, "Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension", RFC 3758, May 2004.
+
+ [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
+ RFC 4960, September 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+ "Network Time Protocol Version 4: Protocol and Algorithms
+ Specification", RFC 5905, June 2010.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, March 2011.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 70]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
+ Layer Security (TLS) and Datagram Transport Layer Security
+ (DTLS) Heartbeat Extension", RFC 6520, February 2012.
+
+ [RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model
+ for IP Flow Information Export (IPFIX)", RFC 7012,
+ September 2013.
+
+ [TCP] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+Informative References
+
+ [IEEE.754.2008]
+ Institute of Electrical and Electronics Engineers, "IEEE
+ Standard for Floating-Point Arithmetic", IEEE
+ Standard 754, August 2008.
+
+ [IPFIX-MED-PROTO]
+ Claise, B., Kobayashi, A., and B. Trammell, "Operation of
+ the IP Flow Information Export (IPFIX) Protocol on IPFIX
+ Mediators", Work in Progress, July 2013.
+
+ [IANA-PEN]
+ IANA, "Private Enterprise Numbers",
+ <http://www.iana.org/assignments/enterprise-numbers/>.
+
+ [POSIX.1] IEEE 1003.1-2008, "IEEE Standard for Information
+ Technology - Portable Operating System Interface
+ (POSIX(R))", 2008.
+
+ [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+ STD 58, RFC 2579, April 1999.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
+ "Requirements for IP Flow Information Export (IPFIX)",
+ RFC 3917, October 2004.
+
+ [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
+ Version 9", RFC 3954, October 2004.
+
+
+
+Claise, et al. Standards Track [Page 71]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ [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.
+
+ [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export
+ Using IP Flow Information Export (IPFIX)", RFC 5103,
+ January 2008.
+
+ [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
+ Aitken, "IP Flow Information Export (IPFIX) Implementation
+ Guidelines", RFC 5153, April 2008.
+
+ [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+ "Architecture for IP Flow Information Export", RFC 5470,
+ March 2009.
+
+ [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
+ Flow Information Export (IPFIX) Testing", RFC 5471,
+ March 2009.
+
+ [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
+ Flow Information Export (IPFIX) Applicability", RFC 5472,
+ March 2009.
+
+ [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
+ in IP Flow Information Export (IPFIX) and Packet Sampling
+ (PSAMP) Reports", RFC 5473, March 2009.
+
+ [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A.,
+ Grossglauser, M., and J. Rexford, "A Framework for Packet
+ Selection and Reporting", RFC 5474, March 2009.
+
+ [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
+ Raspall, "Sampling and Filtering Techniques for IP Packet
+ Selection", RFC 5475, March 2009.
+
+ [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
+ Sampling (PSAMP) Protocol Specifications", RFC 5476,
+ March 2009.
+
+ [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
+ Carle, "Information Model for Packet Sampling Exports",
+ RFC 5477, March 2009.
+
+ [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby,
+ "Exporting Type Information for IP Flow Information Export
+ (IPFIX) Information Elements", RFC 5610, July 2009.
+
+
+
+
+Claise, et al. Standards Track [Page 72]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+ [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.
+
+ [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
+ Transport Layer Security (DTLS) for Stream Control
+ Transmission Protocol (SCTP)", RFC 6083, January 2011.
+
+ [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
+ "IP Flow Information Export (IPFIX) Mediation: Framework",
+ RFC 6183, April 2011.
+
+ [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+ "Export of Structured Data in IP Flow Information Export
+ (IPFIX)", RFC 6313, July 2011.
+
+ [RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP
+ Flow Information Export (IPFIX) Per Stream Control
+ Transmission Protocol (SCTP) Stream", RFC 6526,
+ March 2012.
+
+ [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
+ Number Attacks", RFC 6528, February 2012.
+
+ [RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz,
+ "Definitions of Managed Objects for IP Flow Information
+ Export", RFC 6615, June 2012.
+
+ [RFC6727] Dietz, T., Ed., Claise, B., and J. Quittek, "Definitions
+ of Managed Objects for Packet Sampling", RFC 6727,
+ October 2012.
+
+ [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data
+ Model for the IP Flow Information Export (IPFIX) and
+ Packet Sampling (PSAMP) Protocols", RFC 6728,
+ October 2012.
+
+ [UTF8-EXPLOIT]
+ Davis, M. and M. Suignard, "Unicode Technical Report #36:
+ Unicode Security Considerations", The Unicode Consortium,
+ July 2012.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 73]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Acknowledgments
+
+ We would like to thank Ganesh Sadasivan for his significant
+ contribution during the initial phases of the protocol specification.
+ Additional thanks go to Juergen Quittek for coordination between
+ IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, and Andrew Johnson for
+ the thorough reviews; Randall Stewart and Peter Lei for their SCTP
+ expertise and contributions; Martin Djernaes for the first essay on
+ the SCTP section; Michael Behringer and Eric Vyncke for their advice
+ and knowledge in security; Michael Tuexen for his help regarding the
+ DTLS section; Elisa Boschi for her contribution regarding the
+ improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff
+ Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David
+ Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, Sue
+ Hares, and many more, for the technical reviews and feedback.
+ Finally, a special mention to Adrian Farrel for his attention to
+ management and operational aspects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 74]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Contributors
+
+ Stewart Bryant
+ Cisco Systems
+ 10 New Square, Bedfont Lakes
+ Feltham, Middlesex TW18 8HA
+ United Kingdom
+
+ EMail: stbryant@cisco.com
+
+
+ Simon Leinen
+ SWITCH
+ Werdstrasse 2
+ P.O. Box 8021
+ Zurich
+ Switzerland
+
+ Phone: +41 44 268 1536
+ EMail: simon.leinen@switch.ch
+
+
+ Thomas Dietz
+ NEC Europe Ltd.
+ NEC Laboratories Europe
+ Network Research Division
+ Kurfuersten-Anlage 36
+ 69115 Heidelberg
+ Germany
+
+ Phone: +49 6221 4342-128
+ EMail: Thomas.Dietz@nw.neclab.eu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 75]
+
+RFC 7011 IPFIX Protocol Specification September 2013
+
+
+Authors' Addresses
+
+ Benoit Claise (editor)
+ Cisco Systems, Inc.
+ De Kleetlaan 6a b1
+ 1831 Diegem
+ Belgium
+
+ Phone: +32 2 704 5622
+ EMail: bclaise@cisco.com
+
+
+ Brian Trammell (editor)
+ Swiss Federal Institute of Technology Zurich
+ Gloriastrasse 35
+ 8092 Zurich
+ Switzerland
+
+ Phone: +41 44 632 70 13
+ EMail: trammell@tik.ee.ethz.ch
+
+
+ Paul Aitken
+ Cisco Systems, Inc.
+ 96 Commercial Quay
+ Commercial Street, Edinburgh EH6 6LX
+ United Kingdom
+
+ Phone: +44 131 561 3616
+ EMail: paitken@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 76]
+