summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5101.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5101.txt')
-rw-r--r--doc/rfc/rfc5101.txt3531
1 files changed, 3531 insertions, 0 deletions
diff --git a/doc/rfc/rfc5101.txt b/doc/rfc/rfc5101.txt
new file mode 100644
index 0000000..a2681e0
--- /dev/null
+++ b/doc/rfc/rfc5101.txt
@@ -0,0 +1,3531 @@
+
+
+
+
+
+
+Network Working Group B. Claise, Ed.
+Request for Comments: 5101 Cisco Systems, Inc.
+Category: Standards Track January 2008
+
+
+ Specification of the IP Flow Information Export (IPFIX) Protocol
+ for the Exchange of IP Traffic Flow Information
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document specifies the IP Flow Information Export (IPFIX)
+ protocol that serves for transmitting IP Traffic Flow information
+ over the network. In order to transmit IP Traffic Flow information
+ from an Exporting Process to an information Collecting Process, a
+ common representation of flow data and a standard means of
+ communicating them is 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. IPFIX Documents Overview ...................................4
+ 2. Terminology .....................................................4
+ 2.1. Terminology Summary Table ..................................9
+ 3. IPFIX Message Format ...........................................10
+ 3.1. Message Header Format .....................................11
+ 3.2. Field Specifier Format ....................................13
+ 3.3. Set and Set Header Format .................................14
+ 3.3.1. Set Format .........................................14
+ 3.3.2. Set Header Format ..................................15
+ 3.4. Record Format .............................................16
+ 3.4.1. Template Record Format .............................16
+ 3.4.2. Options Template Record Format .....................18
+ 3.4.2.1. Scope .....................................19
+ 3.4.2.2. Options Template Record Format ............20
+ 3.4.3. Data Record Format .................................22
+ 4. Specific Reporting Requirements ................................23
+ 4.1. The Metering Process Statistics Option Template ...........23
+
+
+
+Claise, et al. Standards Track [Page 1]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 4.2. The Metering Process Reliability Statistics Option
+ Template ..................................................24
+ 4.3. The Exporting Process Reliability Statistics
+ Option Template ...........................................25
+ 4.4. The Flow Keys Option Template .............................26
+ 5. IPFIX Message Header "Export Time" and Flow Record Time ........27
+ 6. Linkage with the Information Model .............................28
+ 6.1. Encoding of IPFIX Data Types ..............................28
+ 6.1.1. Integral Data Types ................................28
+ 6.1.2. Address Types ......................................28
+ 6.1.3. float32 ............................................28
+ 6.1.4. float64 ............................................28
+ 6.1.5. boolean ............................................28
+ 6.1.6. string and octetarray ..............................28
+ 6.1.7. dateTimeSeconds ....................................29
+ 6.1.8. dateTimeMilliseconds ...............................29
+ 6.1.9. dateTimeMicroseconds ...............................29
+ 6.1.10.dateTimeNanoseconds.................................29
+ 6.2. Reduced Size Encoding of Integer and Float Types ..........29
+ 7. Variable-Length Information Element ............................30
+ 8. Template Management ............................................31
+ 9. The Collecting Process's Side ..................................34
+ 10. Transport Protocol ............................................36
+ 10.1. Transport Compliance and Transport Usage .................36
+ 10.2. SCTP .....................................................37
+ 10.2.1. Congestion Avoidance ..............................37
+ 10.2.2. Reliability .......................................37
+ 10.2.3. MTU ...............................................37
+ 10.2.4. Exporting Process .................................38
+ 10.2.4.1. Association Establishment ................38
+ 10.2.4.2. Association Shutdown .....................38
+ 10.2.4.3. Stream ...................................38
+ 10.2.4.4. Template Management ......................39
+ 10.2.5. Collecting Process ................................39
+ 10.2.6. Failover ..........................................39
+ 10.3. UDP ......................................................39
+ 10.3.1. Congestion Avoidance ..............................39
+ 10.3.2. Reliability .......................................40
+ 10.3.3. MTU ...............................................40
+ 10.3.4. Port Numbers ......................................40
+ 10.3.5. Exporting Process .................................40
+ 10.3.6. Template Management ...............................40
+ 10.3.7. Collecting Process ................................41
+ 10.3.8. Failover ..........................................42
+ 10.4. TCP ......................................................42
+ 10.4.1. Connection Management .............................42
+ 10.4.1.1. Connection Establishment .................42
+ 10.4.1.2. Graceful Connection Release ..............43
+
+
+
+Claise, et al. Standards Track [Page 2]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 10.4.1.3. Restarting Interrupted Connections .......43
+ 10.4.1.4. Failover .................................43
+ 10.4.2. Data Transmission .................................43
+ 10.4.2.1. IPFIX Message Encoding ...................43
+ 10.4.2.2. Template Management ......................44
+ 10.4.2.3. Congestion Handling and Reliability ......44
+ 10.4.3. Collecting Process ................................45
+ 11. Security Considerations .......................................46
+ 11.1. Applicability of TLS and DTLS ............................47
+ 11.2. Usage ....................................................48
+ 11.3. Authentication ...........................................48
+ 11.4. Protection against DoS Attacks ...........................48
+ 11.5. When DTLS or TLS Is Not an Option ........................50
+ 11.6. Logging an IPFIX Attack ..................................50
+ 11.7. Securing the Collector ...................................51
+ 12. IANA Considerations ...........................................51
+ Appendix A. IPFIX Encoding Examples ...............................52
+ A.1. Message Header Example.....................................52
+ A.2. Template Set Examples......................................53
+ A.2.1. Template Set Using IETF-Specified Information
+ Elements ...........................................53
+ A.2.2. Template Set Using Enterprise-Specific Information
+ Elements ...........................................53
+ A.3. Data Set Example ..........................................55
+ A.4. Options Template Set Examples .............................56
+ A.4.1. Options Template Set Using IETF-Specified
+ Information Elements ...............................56
+ A.4.2. Options Template Set Using Enterprise-Specific
+ Information Elements ...............................56
+ A.4.3. Options Template Set Using an Enterprise-Specific
+ Scope ..............................................57
+ A.4.4. Data Set Using an Enterprise-Specific Scope ........58
+ A.5. Variable-Length Information Element Examples ..............59
+ A.5.1. Example of Variable-Length Information Element
+ with Length Inferior to 255 Octets .................59
+ A.5.2. Example of Variable-Length Information Element
+ with Length 255 to 65535 Octets ....................59
+ References ........................................................59
+ Normative References ...........................................59
+ Informative References .........................................60
+ Acknowledgments ...................................................61
+
+1. Introduction
+
+ A data network with IP traffic primarily consists of IP flows passing
+ through the network elements. It is often interesting, useful, or
+ even required to have access to information about these flows that
+ pass through the network elements for administrative or other
+
+
+
+Claise, et al. Standards Track [Page 3]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ purposes. The IPFIX 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 the protocol to achieve these aforementioned requirements.
+ This document specifies in detail the representation of different
+ flows, the additional data required for flow interpretation, packet
+ format, transport mechanisms used, security concerns, etc.
+
+1.1. 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 [IPFIX-ARCH], 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. IPFIX has a
+ formal description of IPFIX Information Elements, their name, type
+ and additional semantic information, as specified in [RFC5102].
+ Finally, [IPFIX-AS] describes what type of applications can use the
+ IPFIX protocol and how they can use the information provided. It
+ furthermore shows how the IPFIX framework relates to other
+ architectures and frameworks.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ The definitions of the basic terms like IP 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 [IPFIX-ARCH] are equivalent, except that definitions that are
+ only relevant to the IPFIX protocol only appear here.
+
+ The terminology summary table in Section 2.1 gives a quick overview
+ of the relationships between some of the different terms defined.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 4]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Observation Point
+
+ An Observation Point is a location in the network where IP 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.
+
+ IP 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 IP packets 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...).
+
+
+
+Claise, et al. Standards Track [Page 5]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 3. one or more of 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.
+
+ This definition covers the range from a Flow containing all
+ packets observed at a network interface to a Flow consisting of
+ just a single packet between two applications. It 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),
+
+ 2. are a property of the packet itself (e.g., packet length),
+
+ 3. are derived from packet treatment (e.g., Autonomous System
+ (AS) number),
+
+ and that are used to define a Flow are termed Flow Keys.
+
+ 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 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 and characteristics observed at an
+ Observation Point, and packet treatment at the Observation Point
+ (for example, the selected output interface).
+
+ 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.
+
+
+
+
+Claise, et al. Standards Track [Page 6]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Exporting Process
+
+ The Exporting Process sends Flow Records to one or more Collecting
+ Processes. The Flow Records 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 and arbitrary numbers of Observation
+ Points and Metering Processes.
+
+ Collecting Process
+
+ A Collecting Process receives Flow Records from one or more
+ Exporting Processes. The Collecting Process might process or
+ store received Flow Records, but such actions are out of scope for
+ this document.
+
+ 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 originating at the Exporting Process
+ that carries the IPFIX records of this Exporting Process and whose
+ destination is a Collecting Process. An IPFIX Message is
+ encapsulated at the transport layer.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 7]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Message Header
+
+ The Message Header is the first part of an IPFIX Message, which
+ 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.
+
+ Set
+
+ Set is a generic term for a collection of records that have a
+ similar structure. In an IPFIX Message, one or more Sets follow
+ the Message Header.
+
+ There are three different types of Sets: Template Set, Options
+ Template Set, and Data Set.
+
+ 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.
+
+
+
+Claise, et al. Standards Track [Page 8]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Information Element
+
+ An Information Element is a protocol and encoding-independent
+ description of an attribute that may appear in an IPFIX Record.
+ The IPFIX information model [RFC5102] defines the base set of
+ Information Elements for 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 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.
+
+2.1. Terminology Summary Table
+
+ +------------------+---------------------------------------------+
+ | | 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).
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 9]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+3. IPFIX Message Format
+
+ An IPFIX Message consists of a Message Header, followed by one or
+ more Sets. The Sets can be any of the possible three 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
+
+ The Exporter MUST code all binary integers of the Message Header and
+ the different Sets in network-byte order (also known as the
+ big-endian byte ordering).
+
+ Following are some examples of IPFIX Messages:
+
+ 1. An IPFIX Message consisting of interleaved Template, Data, and
+ Options Template Sets -- A newly created Template is exported as
+ soon as possible. So, if there is already an IPFIX Message with a
+ Data Set that is being prepared for export, the Template and
+ Option Template Sets are interleaved with this information,
+ subject to availability of space.
+
+ +--------+--------------------------------------------------------+
+ | | +----------+ +---------+ +-----------+ +---------+ |
+ |Message | | Template | | Data | | Options | | Data | |
+ | Header | | Set | | Set | ... | Template | | Set | |
+ | | | | | | | Set | | | |
+ | | +----------+ +---------+ +-----------+ +---------+ |
+ +--------+--------------------------------------------------------+
+
+ Figure C: IPFIX Message, Example 1
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 10]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 2. An IPFIX Message consisting entirely of Data Sets -- After the
+ appropriate Template Records have been defined and transmitted to
+ the Collecting Process, the majority of IPFIX Messages consist
+ solely of Data Sets.
+
+ +--------+----------------------------------------------+
+ | | +---------+ +---------+ +---------+ |
+ |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.
+
+ +--------+-------------------------------------------------+
+ | | +----------+ +----------+ +----------+ |
+ |Message | | Template | | Template | | Options | |
+ | Header | | Set | ... | Set | ... | Template | |
+ | | | | | | | Set | |
+ | | +----------+ +----------+ +----------+ |
+ +--------+-------------------------------------------------+
+
+ Figure E: IPFIX Message, Example 3
+
+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
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 11]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Message Header Field Descriptions:
+
+ Version
+
+ Version of Flow Record format exported in this message. The value
+ of this field is 0x000a for the current version, incrementing by
+ one the version used in the NetFlow services export version 9
+ [RFC3954].
+
+ Length
+
+ Total length of the IPFIX Message, measured in octets, including
+ Message Header and Set(s).
+
+ Export Time
+
+ Time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX
+ Message Header leaves the Exporter.
+
+ Sequence Number
+
+ Incremental sequence counter modulo 2^32 of all IPFIX Data Records
+ sent on this PR-SCTP stream from the current Observation Domain by
+ the Exporting Process. Check the specific meaning of this field
+ in the subsections of Section 10 when UDP or TCP is selected as
+ the transport protocol. This value SHOULD be used by the
+ Collecting Process to identify whether any IPFIX Data Records have
+ been missed. Template and Options Template Records do not
+ increase the Sequence Number.
+
+ 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 Exporting Process. The Observation
+ Domain ID SHOULD be 0 when no specific Observation Domain ID is
+ relevant for the entire IPFIX Message, for example, when exporting
+ the Exporting Process Statistics, or in case of a hierarchy of
+ Collectors when aggregated Data Records are exported.
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 12]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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
+ IETF-specified Information Elements [RFC5102] 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 identifier will report an IETF-specified
+ Information Element, and the Enterprise Number MUST NOT be present.
+ When the Enterprise bit is set to 1, the corresponding Information
+ Element identifier will report an enterprise-specific Information
+ Element; the Enterprise Number MUST be present. An example of this
+ is shown in Section A.4.2.
+
+ 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
+ IETF-specified Information Element, 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 filed MUST be
+ present.
+
+ Information Element identifier
+
+ A numeric value that represents the type of Information Element.
+ Refer to [RFC5102].
+
+
+
+
+
+Claise, et al. Standards Track [Page 13]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Field Length
+
+ The length of the corresponding encoded Information Element, in
+ octets. Refer to [RFC5102]. The field length may be smaller than
+ the definition in [RFC5102] 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 [PEN] of the authority defining the
+ Information Element identifier in this Template Record.
+
+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
+
+ The Set Field Definitions are as follows:
+
+ Set Header
+
+ The Set Header Format is defined in Section 3.3.2.
+
+
+
+Claise, et al. Standards Track [Page 14]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 zero (0) valued
+ octets. 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' [RFC5102] can be used for padding 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 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
+
+ The Set Header Field Definitions are as follows:
+
+ Set ID
+
+ Set ID value identifies the Set. A value of 2 is reserved for the
+ Template Set. A value of 3 is reserved for the Option Template
+ Set. All other values from 4 to 255 are reserved for future use.
+ Values above 255 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 15]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+3.4. Record Format
+
+ IPFIX defines three record formats, 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 Elements
+ 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. The
+ definition of the Field Specifiers is given 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 16]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ The Template Record Header Field Definitions are as follows:
+
+ Template ID
+
+ Each of the newly generated Template Records is given a unique
+ Template ID. This uniqueness is local to the Transport Session
+ and Observation Domain that generated the Template ID. Template
+ IDs 0-255 are reserved for Template Sets, Options Template Sets,
+ and other reserved Sets yet to be created. Template IDs of Data
+ Sets are numbered from 256 to 65535. There are no constraints
+ regarding the order of the Template ID allocation.
+
+ Field Count
+
+ Number of fields in this Template Record.
+
+ The example in Figure L shows a Template Set with mixed standard and
+ enterprise-specific Information Elements. It consists of a Set
+ Header, a Template Header, and several Field Specifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 17]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 Identifiers 1.2 and 2.1 are defined by the IETF
+ (Enterprise bit = 0) and, therefore, do not need an Enterprise Number
+ to identify them.
+
+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.
+
+
+
+
+Claise, et al. Standards Track [Page 18]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ One Options Template Record example is the "Flow Keys", which reports
+ the Flow Keys for a Template, which is defined as the scope. Another
+ example is the "Template configuration", which reports the
+ configuration sampling parameter(s) for the Template, which is
+ defined as the scope.
+
+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.
+ Note that the IPFIX Message Header already contains the Observation
+ Domain ID (the identifier of the Observation Domain). If not zero,
+ this Observation Domain ID can be considered as an implicit scope for
+ the Data Records in the IPFIX Message. The Observation Domain ID
+ MUST be zero when the IPFIX Message contains Data Records with
+ different Observation Domain ID values defined as scopes.
+
+ 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 defined as "metering process" and
+ "template", the combined scope is this Template for this Metering
+ Process. The order of the Scope Fields, as defined in the Options
+ Template Record, is irrelevant in this case. However, if the order
+ of the Scope Fields in the Options Template Record is relevant, the
+ order of the Scope Fields MUST be used. For example, 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. In this
+ case, the Collector deduces the function order by looking at the
+ order of the scope in the Options Template Record.
+
+ The scope is an Information Element specified in the IPFIX
+ Information Model [RFC5102]. An IPFIX-compliant implementation of
+ the Collecting Process SHOULD support this minimum set of Information
+ Elements as scope: LineCardId, TemplateId, exporterIPv4Address,
+ exporterIPv6Address, and ingressInterface. Note that other
+ Information Elements, such as meteringProcessId, exportingProcessId,
+ observationDomainId, etc. are also valid scopes. 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.
+
+ Finally, note that the Scope Field Count MUST NOT be zero.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 19]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+3.4.2.2. Options Template Record Format
+
+ An Options Template Record contains any combination of IANA-assigned
+ and/or enterprise-specific Information Elements 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. The definition of the Field Specifiers is given 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
+
+ The Options Template Record Header Field Definitions are as follows:
+
+ Template ID
+
+ Template ID of this Options Template Record. This value is greater
+ than 255.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 20]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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. The Scope Field Count MUST NOT be zero.
+
+ The example in Figure O shows an Option Template Set with mixed IETF
+ and enterprise-specific Information Elements. It consists of a Set
+ Header, an Option 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: Option Template Set Example
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 21]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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 specified in
+ [RFC5102].
+
+ 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.
+
+ The example in Figure Q shows a Data Set. It consists of a Set Header
+ and several Field Values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 22]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 Option Template and Options Template Records defined in these
+ subsections, which impose some constraints on the Metering Process
+ and Exporting Process implementations, MAY be implemented. If
+ implemented, the specific Option Templates SHOULD be implemented as
+ specified in these subsections.
+
+ The minimum set of Information Elements is always specified in these
+ Specific IPFIX Options Templates. Nevertheless, extra Information
+ Elements may be used in these specific Options Templates.
+
+4.1. The Metering Process Statistics Option Template
+
+ The Metering Process Statistics Option Template specifies the
+ structure of a Data Record for reporting Metering Process statistics.
+ It SHOULD contain the following Information Elements that are defined
+ in [RFC5102]:
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 23]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ observationDomainId
+ An identifier of an Observation Domain that
+ is locally unique to the Exporting Process.
+ This Information Element MUST be defined as a
+ Scope Field.
+
+ exportedMessageTotalCount
+ The total number of IPFIX Messages that the
+ Exporting Process successfully sent to the
+ Collecting Process since the Exporting
+ Process re-initialization.
+
+ exportedFlowTotalCount
+ The total number of Flow Records that the
+ Exporting Process successfully sent to the
+ Collecting Process since the Exporting
+ Process re-initialization.
+
+ exportedOctetTotalCount
+ The total number of octets that the Exporting
+ Process successfully sent to the Collecting
+ Process since the Exporting Process re-
+ initialization.
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Metering Process Statistics Option 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 Option Template
+
+ The Metering Process Reliability Option Template specifies the
+ structure of a Data Record for reporting lack of reliability in the
+ Metering Process. It SHOULD contain the following Information
+ Elements that are defined in [RFC5102]:
+
+ observationDomainId
+ An identifier of an Observation Domain that
+ is locally unique to the Exporting Process.
+ This Information Element MUST be defined as a
+ Scope Field.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 24]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ ignoredPacketTotalCount
+ The total number of IP packets that the
+ Metering Process did not process.
+
+ ignoredOctetTotalCount
+ The total number of octets in observed IP
+ packets that the Metering Process did not
+ process.
+
+ time first ignored
+ The timestamp of the first IP packet that was
+ ignored by the Metering Process. For this
+ timestamp, any of the "flowStart" timestamp
+ Information Elements flowStartMilliseconds,
+ flowStartMicroseconds, flowStartNanoseconds,
+ and flowStartDeltaMicroseconds can be used.
+
+ time last ignored
+ The timestamp of the last IP packet that was
+ ignored by the Metering Process. For this
+ timestamp, any of the "flowEnd" timestamp
+ Information Elements flowEndMilliseconds,
+ flowEndMicroseconds, flowEndNanoseconds, and
+ flowEndDeltaMicroseconds can be used.
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Metering Process Reliability Statistics Option 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.3. The Exporting Process Reliability Statistics Option Template
+
+ The Exporting Process Reliability Option Template specifies the
+ structure of a Data Record for reporting lack of reliability in the
+ Exporting process. It SHOULD contain the following Information
+ Elements that are defined in [RFC5102]:
+
+ Exporting Process ID
+ The identifier of the Exporting Process for
+ which lack of reliability is reported. There
+ are three Information Elements specified in
+ [RFC5102] that can be used for this purpose:
+ exporterIPv4Address, exporterIPv6Address, or
+
+
+
+
+Claise, et al. Standards Track [Page 25]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ exportingProcessId. This Information Element
+ MUST be defined as a Scope Field.
+
+ notSentFlowTotalCount
+ The total number of Flows that were generated by
+ the Metering Process and dropped by the Metering
+ Process or by the Exporting Process instead of
+ being sent to the Collecting Process.
+
+ notSentPacketTotalCount
+ The total number of packets in Flow Records that
+ were generated by the Metering Process and
+ dropped by the Metering Process or by the
+ Exporting Process instead of being sent to the
+ Collecting Process.
+
+ notSentOctetTotalCount
+ The total number of octets in packets in Flow
+ Records that were generated by the Metering
+ Process and dropped by the Metering Process or
+ by the Exporting Process instead of being sent
+ to the Collecting Process.
+
+ time first flow dropped
+ The timestamp of the first Flow was dropped by
+ the Metering Process. For this timestamp, any
+ of the "flowStart" timestamp Information
+ Elements flowStartMilliseconds,
+ flowStartMicroseconds, flowStartNanoseconds, and
+ flowStartDeltaMicroseconds can be used.
+
+ time last flow dropped
+ The timestamp of the last IP packet that was
+ ignored by the Metering Process. For this
+ timestamp, any of the "flowEnd" timestamp
+ Information Elements flowEndMilliseconds,
+ flowEndMicroseconds, flowEndNanoseconds, and
+ flowEndDeltaMicroseconds can be used.
+
+ The Exporting Process SHOULD export the Data Record specified by the
+ Exporting Process Reliability Statistics Option Template on a regular
+ basis or based on some export policy. This periodicity or export
+ policy SHOULD be configurable.
+
+4.4. The Flow Keys Option Template
+
+ The Flow Keys Option Template specifies the structure of a Data
+ Record for reporting the Flow Keys of reported Flows. A Flow Keys
+
+
+
+Claise, et al. Standards Track [Page 26]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Data Record extends a particular Template Record that is referenced
+ by its templateId identifier. The Template Record is extended by
+ specifying which of the Information Elements contained in the
+ corresponding Data Records describe Flow properties that serve as
+ Flow Keys of the reported Flow.
+
+ The Flow Keys Option Template SHOULD contain the following
+ Information Elements that are defined in [RFC5102]:
+
+ templateId An identifier of a Template. This
+ Information Element MUST be defined as a
+ Scope Field.
+
+ flowKeyIndicator Bitmap with the positions of the Flow Keys in
+ the Data Records.
+
+5. IPFIX Message Header "Export Time" and Flow Record Time
+
+ The IPFIX Message Header "Export Time" field is the time in seconds
+ since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves
+ the Exporter. The time-related Information Elements specified in
+ [RFC5102] MAY use this "Export Time" as base time and specify an
+ offset relative to it, instead of using a common base time, such as
+ 0000 UTC Jan 1, 1970. All Information Elements that do not have
+ their base time defined by their data type MUST have the base time
+ clearly specified in their description.
+
+ For example, Data Records requiring a microsecond precision can
+ export the flow start and end times with the flowStartMicroseconds
+ and flowEndMicroseconds Information Elements [RFC5102], containing
+ the time since 0000 UTC Jan 1, 1970. An alternate solution is to
+ export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
+ Information Elements [RFC5102] in the Data Record, which respectively
+ report the flow start and end time offsets compared to the IPFIX
+ Message Header "Export Time". The latter solution lowers the export
+ bandwidth requirement while it increases the load on the Exporter, 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 using time-related Information Elements with
+ offset times, compared to the IPFIX Message Header "Export Time",
+ imposes some time constraints on the Data Records contained in the
+ IPFIX Message. In the example of flowStartDeltaMicroseconds and
+ flowEndDeltaMicroseconds Information Elements [RFC5102], the Data
+ Record must be exported within a maximum of 71 minutes after its
+ creation. Otherwise, the 32-bit counter would not be sufficient to
+ contain the flow start time offset.
+
+
+
+Claise, et al. Standards Track [Page 27]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+6. Linkage with the Information Model
+
+ The Information Elements [RFC5102] MUST be sent in canonical format
+ in network-byte order (also known as the big-endian byte ordering).
+
+6.1. Encoding of IPFIX Data Types
+
+ The following sections will define the encoding of the data types
+ specified in [RFC5102].
+
+6.1.1. Integral Data Types
+
+ Integral data types -- octet, signed8, unsigned16, signed16,
+ unsigned32, signed32, signed64, and unsigned64 -- 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. The macAddress is
+ treated as a 6-octet integer, the ipv4Address as a 4-octet integer,
+ and the ipv6Address as a 16-octet integer.
+
+6.1.3. float32
+
+ The float32 data type MUST be encoded as an IEEE single-precision
+ 32-bit floating point-type, as specified in [IEEE.754.1985].
+
+6.1.4. float64
+
+ The float64 data type MUST be encoded as an IEEE double-precision
+ 64-bit floating point-type, as specified in [IEEE.754.1985].
+
+6.1.5. boolean
+
+ The boolean data type is specified according to the TruthValue in
+ [RFC2579]: it is an integer with the value 1 for true and a value 2
+ for false. Every other value is undefined. The boolean data type
+ MUST be encoded in a single octet.
+
+6.1.6. string and octetarray
+
+ The data type string represents a finite length string of valid
+ characters of the Unicode character encoding set. The string data
+ type MUST be encoded in UTF-8 format. The string is sent as an array
+ of octets using an Information Element of fixed or variable length.
+
+
+
+
+Claise, et al. Standards Track [Page 28]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ The length of the Information Element specifies the length of the
+ octetarray.
+
+6.1.7. dateTimeSeconds
+
+ The data type dateTimeseconds represents a time value in units of
+ seconds normalized to the GMT timezone. It MUST be encoded in a
+ 32-bit integer containing the number of seconds since 0000 UTC Jan 1,
+ 1970. The 32-bit integer allows the time encoding up to 136 years.
+
+6.1.8. dateTimeMilliseconds
+
+ The data type dateTimeMilliseconds represents a time value in units
+ of milliseconds normalized to the GMT timezone. It MUST be encoded
+ in a 64-bit integer containing the number of milliseconds since 0000
+ UTC Jan 1, 1970.
+
+6.1.9. dateTimeMicroseconds
+
+ The data type dateTimeMicroseconds represents a time value in units
+ of microseconds normalized to the GMT timezone. It MUST be encoded
+ in a 64-bit integer, according to the NTP format given in [RFC1305].
+
+6.1.10. dateTimeNanoseconds
+
+ The data type of dateTimeNanoseconds represents a time value in units
+ of nanoseconds normalized to the GMT time zone. It MUST be encoded
+ in a 64-bit integer, according to the NTP format given in [RFC1305].
+
+6.2. Reduced Size Encoding of Integer and Float Types
+
+ Information Elements containing integer, string, float, and
+ octetarray types in the information model MAY be encoded using fewer
+ octets than those implied by their type in the information model
+ definition [RFC5102], 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
+ [RFC5102] will always define the maximum encoding size.
+
+ For instance, the information model [RFC5102] defines byteCount 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 chose to send the value instead as an
+ unsigned32. For example, a core router would require an unsigned64
+ byteCount, while an unsigned32 might be sufficient for an access
+ router.
+
+
+
+
+Claise, et al. Standards Track [Page 29]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ This behavior is indicated by the Exporter by specifying a type size
+ 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.
+
+ If reduced sizing is used, it MUST only 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 sizing can also 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.
+
+ The reduced size encoding MUST NOT be applied to dateTimeMicroseconds
+ or to dateTimeNanoseconds because these represent an inherent
+ structure that would be destroyed by using less than the original
+ number of bytes.
+
+7. Variable-Length Information Element
+
+ The IPFIX Template mechanism is optimized for fixed-length
+ Information Elements [RFC5102]. Where an Information Element has a
+ variable length, the following mechanism MUST be used to carry the
+ length information for both the IETF and proprietary Information
+ Elements.
+
+ In the Template Set, the Information Element Field Length is recorded
+ as 65535. This reserved length value notifies the Collecting Process
+ that length of the Information Element will be carried in the
+ Information Element content itself.
+
+ 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
+ majority case. The length is carried in the octet before the
+ Information Element, as shown in Figure R.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 30]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 (length < 255 octets)
+
+ If the length of the Information Element is greater than or equal to
+ 255 octets, the length is encoded into 3 octets before the
+ Information Element. The first octet is 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 (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 Template Management when using SCTP and
+ PR-SCTP as the transport protocol. Any necessary changes to Template
+ Management specifically related to TCP or UDP transport protocols are
+ specified in Section 10.
+
+ The Exporting Process assigns and maintains the Template IDs per SCTP
+ association for the Exporter's Observation Domains. A newly created
+ Template Record is assigned an unused Template ID by the Exporting
+ Process.
+
+ If a specific Information Element is required by a Template, but is
+ not available in observed packets, the Exporting Process MAY choose
+ to export Flow Records without this Information Element in a Data
+ Record defined by a new Template.
+
+
+
+
+
+Claise, et al. Standards Track [Page 31]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 packets, the first sourceIPv4Address
+ Information Element occurrence should be the IPv4 address of the
+ outer header, while the second occurrence should be the inner header
+ one.
+
+ Template Sets and Options Template Sets may be sent on any SCTP
+ stream. Template Sets and Options Template Sets MUST be sent
+ reliably, using SCTP-ordered delivery. As such, the Collecting
+ Process MUST store the Template Record information for the duration
+ of the SCTP association so that it can interpret the corresponding
+ Data Records that are received in subsequent Data Sets.
+
+ 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
+ subsequent IPFIX Message(s).
+
+ Different Observation Domains from the same SCTP association may use
+ the same Template ID value to refer to different Templates.
+
+ The Templates that are not used anymore SHOULD be deleted. Before
+ reusing a Template ID, the Template MUST be deleted. In order to
+ delete an allocated Template, the Template is withdrawn through the
+ use of a Template Withdrawal Message.
+
+ The Template Withdrawal Message MUST NOT be sent until sufficient
+ time has elapsed to allow the Collecting Process to receive and
+ process the last Data Record using this Template information. This
+ time MUST be configurable. A suitable default value is 5 seconds
+ after the last Data Record has been sent.
+
+ The Template ID from a withdrawn Template MUST NOT be reused until
+ sufficient time has elapsed to allow for the Collecting Process to
+ receive and process the Template Withdrawal Message.
+
+ A Template Withdrawal Message is a Template Record for that Template
+ ID with a Field Count of 0. The format of the Template Withdrawal
+ Message is shown in Figure T.
+
+
+
+
+Claise, et al. Standards Track [Page 32]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 Message Format
+
+ The Set ID field MUST contain the value 2 for Template Set Withdrawal
+ and the value 3 for Options Template Set Withdrawal. Multiple
+ Template IDs MAY be withdrawn with a single Template Withdrawal
+ Message, in that case, padding MAY be used.
+
+ The Template Withdrawal Message withdraws the Template IDs for the
+ Observation Domain ID specified in the IPFIX Message Header.
+
+ The Template Withdrawal Message may be sent on any SCTP stream. The
+ Template Withdrawal Message MUST be sent reliably, using SCTP-ordered
+ delivery.
+
+ The Template Withdrawal Message MUST NOT contain new Template or
+ Options Template Records.
+
+ If the measurement parameters change such that a new Template is
+ required, the Template MUST be withdrawn (using a Template Withdraw
+ Message and a new Template definition) or an unused Template ID MUST
+ be used. Examples of the measurement changes are: a new sampling
+ rate, a new Flow expiration process, a new filtering definition, etc.
+
+ When the SCTP association shuts down or the Exporting Process
+ restarts, all Template assignments are lost and Template IDs MUST be
+ reassigned.
+
+ If the Metering Process restarts, the Exporting Process MUST either
+ reuse the previously assigned Template ID for each Template, or it
+ MUST withdraw the previously issued Template IDs by sending Template
+ Withdraw Message(s) before reusing them.
+
+ A Template Withdrawal Message to withdraw all Templates for the
+ Observation Domain ID specified in the IPFIX Message Header MAY be
+ used. Its format is shown in Figure U.
+
+
+
+
+Claise, et al. Standards Track [Page 33]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 Data Templates Withdrawal Message Format
+
+ A Template Withdrawal Message to withdraw all Options Templates for
+ the Observation Domain ID specified in the IPFIX Message Header MAY
+ be used. Its format is 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 = 3 | Length = 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 3 | Field Count = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure V: All Options Templates Withdrawal Message Format
+
+ When the SCTP association restarts, the Exporting Process MUST resend
+ all the Template Records.
+
+9. The Collecting Process's Side
+
+ This section describes the Collecting Process when using SCTP and
+ PR-SCTP as the transport protocol. Any necessary changes to the
+ Collecting Process specifically related to TCP or UDP transport
+ protocols are specified in Section 10.
+
+ The Collecting Process SHOULD listen for a new association request
+ from the Exporting Process. The Exporting Process will request a
+ number of streams to use for export. An Exporting Process MAY
+ request and support more than one stream per SCTP association.
+
+ If the Collecting Process receives a malformed IPFIX Message, it MUST
+ reset the SCTP association, discard the IPFIX Message, and SHOULD log
+ the error. Note that non-zero Set padding does not constitute a
+ malformed IPFIX Message.
+
+ Template Sets and Option Template Sets are only sent once. The
+ Collecting Process MUST store the Template Record information for the
+ duration of the association so that it can interpret the
+ corresponding Data Records that are received in subsequent Data Sets.
+
+
+
+Claise, et al. Standards Track [Page 34]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Template IDs are unique per SCTP association and per Observation
+ Domain. If the Collecting Process receives a Template that has
+ already been received but that has not previously been withdrawn
+ (i.e., a Template Record from the same Exporter Observation Domain
+ with the same Template ID received on the SCTP association), then the
+ Collecting Process MUST shut down the association.
+
+ When an SCTP association is closed, the Collecting Process MUST
+ discard all Templates received over that association and stop
+ decoding IPFIX Messages that use those Templates.
+
+ The Collecting Process normally receives Template Records from the
+ Exporting Process before receiving Data Records. The Data Records
+ are then decoded and stored by the Collector. If the Template
+ Records 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 are received. 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.
+
+ 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 the Flow Record.
+
+ The Collector 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
+ 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 may 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.
+
+ If a Collecting Process receives a Template Withdrawal Message, the
+ Collecting Process MUST delete the corresponding Template Records
+ associated with the specific SCTP association and specific
+ Observation Domain, and stop decoding IPFIX Messages that use the
+ withdrawn Templates.
+
+
+
+Claise, et al. Standards Track [Page 35]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ If the Collecting Process receives a Template Withdraw message for a
+ Template Record it has not received before on this SCTP association,
+ it MUST reset the SCTP association, discard the IPFIX Message, and
+ SHOULD log the error as it does for malformed IPFIX Messages.
+
+ A Collecting Process that receives IPFIX Messages from several
+ Observation Domains on the same Transport Session MUST be aware that
+ the uniqueness of the Template ID is not guaranteed across
+ Observation Domains.
+
+ The Collector MUST support the use of Templates containing multiple
+ occurrences of the similar Information Elements.
+
+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.
+
+10.1. Transport Compliance and Transport Usage
+
+ We need to differentiate between what must be implemented (so that
+ operators can interoperably deploy compliant implementations from
+ different vendors) and what should or could be used in various
+ operational environments. We must also make sure that ALL
+ implementations can operate in a congestion-aware and
+ congestion-avoidance mode.
+
+ SCTP [RFC4960] using the PR-SCTP extension 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.
+
+ PR-SCTP SHOULD be used in deployments where Exporters and Collectors
+ are communicating over links that are susceptible to congestion.
+ PR-SCTP is capable of providing any required degree of reliability.
+
+ TCP MAY be used in deployments where Exporters and Collectors
+ communicate over links that are susceptible to congestion, but
+ PR-SCTP is preferred due to its ability to limit back pressure on
+ Exporters and its message versus stream orientation.
+
+
+
+
+
+Claise, et al. Standards Track [Page 36]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ UDP MAY be used, although it is not a congestion-aware protocol.
+ However, the IPFIX traffic between Exporter and Collector MUST run in
+ an environment where IPFIX traffic has been provisioned for, or is
+ contained through some other means.
+
+10.2. SCTP
+
+ This section describes how IPFIX can be transported over SCTP
+ [RFC4960] using the PR-SCTP [RFC3758] extension.
+
+10.2.1. Congestion Avoidance
+
+ The SCTP transport protocol provides the required level of congestion
+ avoidance by design.
+
+ SCTP will detect congestion in the end-to-end path between the IPFIX
+ Exporting Process and the IPFIX Collecting Process, and limit 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 it can decide to drop the record. In the latter case, the
+ dropped export data MUST be accounted for, so that the amount of
+ dropped export data can be reported.
+
+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 the 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 discovery.
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 37]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+10.2.4. Exporting Process
+
+10.2.4.1. Association Establishment
+
+ The IPFIX Exporting Process SHOULD initiate an SCTP association with
+ the IPFIX Collecting Process. By default, the Collecting Process
+ listens for connections on SCTP port 4739. By default, the
+ Collecting Process listens for secure connections on SCTP port 4740
+ (refer to the Security Considerations section). By default, the
+ Exporting Process tries to connect to one of these ports. It MUST be
+ possible to configure both the Exporting and Collecting Processes to
+ use a different SCTP port.
+
+ 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).
+
+10.2.4.2. Association Shutdown
+
+ 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.
+
+10.2.4.3. Stream
+
+ 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.
+
+
+
+
+
+Claise, et al. Standards Track [Page 38]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 [RFC3758] specification 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.2.4.4. Template Management
+
+ When the transport protocol is SCTP, the default Template Management
+ described in Section 8 is used.
+
+10.2.5. Collecting Process
+
+ When the transport protocol is SCTP, the default Collector processing
+ described in Section 9 is used.
+
+10.2.6. Failover
+
+ If the Collecting Process does not acknowledge the attempt by the
+ Exporting Process to establish an association, the Exporting Process
+ should retry using the SCTP exponential backoff feature. The
+ Exporter MAY log an alarm if the time to establish the association
+ exceeds a specified threshold, configurable on the Exporter.
+
+ If Collecting Process failover is supported by the Exporting Process,
+ a second SCTP association MAY be opened in advance.
+
+10.3. UDP
+
+ This section describes how IPFIX can be 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., over provisioned links compared to the maximum
+ export rate from the Exporters.
+
+
+
+
+
+Claise, et al. Standards Track [Page 39]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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 UDP 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. Templates sent from the Exporting
+ Process to the Collecting Process using UDP as a transport MUST be
+ re-sent at regular intervals, in case previous copies were lost.
+
+10.3.3. MTU
+
+ The maximum size of exported messages MUST be configured such that
+ the total packet size does not exceed the path MTU. If the path MTU
+ is unknown, a maximum packet size of 512 octets SHOULD be used.
+
+10.3.4. Port Numbers
+
+ By default, the Collecting Process listens on the UDP port 4739. By
+ default, the Collecting Process listens for secure connections on UDP
+ port 4740 (refer to the "Security Considerations" section). By
+ default, the Exporting Process tries to connect to one of these
+ ports. It MUST be possible to configure both the Exporting and
+ Collecting Processes to use a different UDP port.
+
+10.3.5. Exporting Process
+
+ The Exporting Process MAY duplicate the IPFIX Message to the several
+ Collecting Processes.
+
+10.3.6. Template Management
+
+ When IPFIX uses UDP as the transport protocol, Template Sets and
+ Option Template Sets MUST be re-sent at regular intervals. The
+ frequency of the (Options) Template transmission MUST be
+ configurable. The default value for the frequency of the (Options)
+ Template transmission is 10 minutes. 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
+
+
+
+
+Claise, et al. Standards Track [Page 40]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Collector has the Template Record before receiving the first Data
+ Record.
+
+ In the event of configuration changes, the Exporting Process SHOULD
+ send multiple copies of the new Template definitions, in different
+ IPFIX Messages, at an accelerated rate. In such a case, it SHOULD
+ transmit the changed Template Record(s) and Options Template
+ Record(s), without any data, in advance to help ensure that the
+ Collector will have the correct Template information before receiving
+ the first data.
+
+ If the Option Template scope is defined in another Template, then
+ both Templates SHOULD be sent in the same IPFIX Message. For
+ example, if a Flow Key Option Template (see Section 4.4) is sent in
+ an Option Template, then the associated Template SHOULD be sent in
+ the same IPFIX Message.
+
+ Following a configuration change that can modify the interpretation
+ of the Data Records (for example, a sampling rate change) a new
+ Template ID MUST be used, and the old Template ID MUST NOT be reused
+ until its lifetime (see Section 10.3.7) has expired.
+
+ If UDP is selected as the transport protocol, the Template Withdraw
+ Messages MUST NOT be used, as this method is inefficient due to the
+ unreliable nature of UDP.
+
+10.3.7. Collecting Process
+
+ The Collecting Process MUST associate a lifetime with each Template
+ (or another definition of an identifier considered unique within the
+ Transport Session) received via UDP. Templates (and similar
+ definitions) not refreshed by the Exporting Process within the
+ lifetime are expired at the Collecting Process. If the Template (or
+ other definition) is not refreshed before that lifetime has expired,
+ the Collecting Process MUST discard that definition and any current
+ and future associated Data Records. In which case, an alarm MUST be
+ logged. The Collecting Process MUST NOT decode any further Data
+ Records that are associated with the expired Template. If a Template
+ is refreshed with a Template Record that differs from the previously
+ received Template Record, the Collecting Process SHOULD log a warning
+ and replace the previously received Template Record with the new one.
+ The Template lifetime at the Collecting Process MUST be at least 3
+ times higher than the Template refresh timeout configured on the
+ Exporting Process.
+
+ 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
+
+
+
+Claise, et al. Standards Track [Page 41]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Records: <IPFIX Device, Exporter source UDP port, Observation Domain
+ ID, Template ID, Template Definition, Last Received>.
+
+ The Collecting Process SHOULD accept Data Records without the
+ associated Template Record (or other definitions) required to decode
+ the Data Record. If the Template Records (or other definitions such
+ as Common Properties) have not been received at the time Data Records
+ are received, the Collecting Process SHOULD store the Data Records
+ for a short period of time and decode them after the Template Records
+ (or other definitions) are received. The short period of time MUST
+ be lower than the lifetime of definitions associated with identifiers
+ considered unique within the UDP session.
+
+ If the Collecting Process receives a malformed IPFIX Message, it MUST
+ discard the IPFIX Message and SHOULD log the error.
+
+10.3.8. Failover
+
+ 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.
+
+10.4. TCP
+
+ This section describes how IPFIX can be transported over TCP [TCP].
+
+10.4.1. Connection Management
+
+10.4.1.1. Connection Establishment
+
+ The IPFIX Exporting Process initiates a TCP connection to the
+ Collecting Process. By default, the Collecting Process listens for
+ connections on TCP port 4739. By default, the Collecting Process
+ listens for secure connections on TCP port 4740 (refer to the
+ Security Considerations section). By default, the Exporting Process
+ tries to connect to one of these ports. It MUST be possible to
+ configure both the Exporting Process and the Collecting Process to
+ use a different TCP port.
+
+ 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).
+
+ The Exporter MAY log an alarm if the time to establish the connection
+ exceeds a specified threshold, configurable on the Exporter.
+
+
+
+Claise, et al. Standards Track [Page 42]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+10.4.1.2. Graceful Connection Release
+
+ 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.
+
+10.4.1.3. Restarting Interrupted Connections
+
+ 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.1.4. Failover
+
+ If the Collecting Process does not acknowledge the attempt by the
+ Exporting Process to establish a connection, it will retry using the
+ TCP exponential backoff feature.
+
+ If Collecting Process failover is supported by the Exporting Process,
+ a second TCP connection MAY be opened in advance.
+
+10.4.2. Data Transmission
+
+ Once a TCP connection is established, the Exporting Process starts
+ sending IPFIX Messages to the Collecting Process.
+
+10.4.2.1. IPFIX Message Encoding
+
+ IPFIX Messages are sent over the TCP connection without any special
+ encoding. The Length field in the IPFIX Message Header defines the
+ end of each IPFIX Message and thus the start of the next IPFIX
+ Message. This means that IPFIX Messages cannot be interleaved.
+
+ In the case of TCP, the IPFIX Sequence Number contains the total
+ number of IPFIX Data Records sent from this TCP connection, from the
+ current Observation Domain by the Exporting Process, prior to the
+ receipt of this IPFIX Message, modulo 2^32.
+
+
+
+Claise, et al. Standards Track [Page 43]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ If an Exporting Process exports data from multiple Observation
+ Domains, it should be careful to choose IPFIX Message lengths
+ appropriately to minimize head-of-line blocking between different
+ Observation Domains. Multiple TCP connections MAY be used to avoid
+ head-of-line between different Observation Domains.
+
+10.4.2.2. Template Management
+
+ For each Template, the Exporting Process MUST send the Template
+ Record before exporting Data Records that refer to that Template.
+
+ Template IDs are unique per TCP connection and per Observation
+ Domain. A Collecting Process MUST record all Template and Options
+ Template Records for the duration of the connection, as an Exporting
+ Process is not required to re-export Template Records.
+
+ When the TCP connection restarts, the Exporting Process MUST resend
+ all the Template Records.
+
+ When a TCP connection is closed, the Collecting Process MUST discard
+ all Templates received over that connection and stop decoding IPFIX
+ Messages that use those Templates.
+
+ The Templates that are not used anymore SHOULD be deleted. Before
+ reusing a Template ID, the Template MUST be deleted. In order to
+ delete an allocated Template, the Template is withdrawn through the
+ use of a Template Withdrawal Message over the TCP connection.
+
+ If the Collecting Process receives a malformed IPFIX Message, it MUST
+ reset the TCP connection, discard the IPFIX Message, and SHOULD log
+ the error.
+
+10.4.2.3. Congestion Handling and Reliability
+
+ TCP ensures reliable delivery of data from the Exporting Process to
+ the Collecting Process. TCP also 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 it, 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
+
+
+
+
+Claise, et al. Standards Track [Page 44]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 amount can later be exported.
+
+ When an Exporting Process finds that the rate at which records should
+ be exported is consistently higher than the rate at which TCP sending
+ permits, it should provide back pressure to the Metering Processes.
+ The Metering Process could then adapt by temporarily reducing the
+ amount of data it generates, for example, using sampling or
+ aggregation.
+
+10.4.3. Collecting Process
+
+ The Collecting Process SHOULD listen for a new TCP connection from
+ the Exporting Process.
+
+ If the Collecting Process receives a malformed IPFIX Message, it MUST
+ reset the TCP connection, discard the IPFIX Message, and SHOULD log
+ the error. Note that non-zero Set padding does not constitute a
+ malformed IPFIX Message.
+
+ Template Sets and Option Template Sets are only sent once. The
+ Collecting Process MUST store the Template Record information for the
+ duration of the connection so that it can interpret the corresponding
+ Data Records that are received in subsequent Data Sets.
+
+ Template IDs are unique per TCP connection and per Observation
+ Domain. If the Collecting Process receives a Template that has
+ already been received but that has not previously been withdrawn
+ (i.e., a Template Record from the same Exporter Observation Domain
+ with the same Template ID received on the TCP connection), then the
+ Collecting Process MUST shut down the connection.
+
+ When a TCP connection is closed, the Collecting Process MUST discard
+ all Templates received over that connection and stop decoding IPFIX
+ Messages that use those Templates.
+
+ If a Collecting Process receives a Template Withdrawal Message, the
+ Collecting Process MUST delete the corresponding Template Records
+ associated with the specific TCP connection and specific Observation
+ Domain, and stop decoding IPFIX Messages that use the withdrawn
+ Templates.
+
+
+
+
+
+Claise, et al. Standards Track [Page 45]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ If the Collecting Process receives a Template Withdrawal Message for
+ a Template Record it has not received before on this TCP connection,
+ it MUST reset the TCP association, discard the IPFIX Message, and
+ SHOULD log the error as it does for malformed IPFIX Messages.
+
+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 IPFIX requirements [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) into 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 either affect 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 or the use of an encryption mechanism. It is the
+
+
+
+Claise, et al. Standards Track [Page 46]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ responsibility of the Collecting Process to provide a satisfactory
+ degree of security for this collected data, including, if necessary,
+ anonymization of any reported data.
+
+11.1. Applicability of TLS and DTLS
+
+ Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer
+ Security (DTLS) [RFC4347] were designed to provide the
+ confidentiality, integrity, and authentication assurances required by
+ the IPFIX protocol, without the need for pre-shared keys.
+
+ With the mandatory SCTP and PR-SCTP transport protocols for IPFIX,
+ DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX
+ transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is
+ selected as the IPFIX transport protocol, TLS [RFC4346] MUST be
+ implemented.
+
+ Note that DTLS is selected as the security mechanism for SCTP and
+ PR-SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they
+ require all communication to be over reliable, bidirectional streams,
+ and 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 [RFC4347] has a vulnerability, i.e., a true man
+ in the middle may attempt to take data out of an association and fool
+ the sender into thinking that the data was actually received by the
+ peer. In generic TLS for SCTP (and/or TCP), this is not possible.
+ This means that the removal of a message may become hidden from the
+ sender or receiver. Another vulnerability of using PR-SCTP with DTLS
+ is that someone could inject SCTP control information to shut down
+ the SCTP association, effectively generating a loss of IPFIX Messages
+ if those are buffered outside of the SCTP association. In the
+ future, techniques such as [dtls-for-sctp] 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.
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 47]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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
+ [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a
+ TLS or DTLS server. The DTLS client opens a secure connection on the
+ SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as
+ the transport protocol. The TLS client opens a secure connection on
+ the TCP port 4740 of the TLS server if TCP is selected as the
+ transport protocol. The DTLS client opens a secure connection on the
+ UDP port 4740 of the DTLS server if UDP is selected as the transport
+ protocol.
+
+11.3. Authentication
+
+ IPFIX Exporting Processes and IPFIX Collecting Processes are
+ identified by the fully qualified domain name of the interface on
+ which IPFIX Messages are sent or received, for purposes of X.509
+ client and server certificates as in [RFC3280].
+
+ 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, strong mutual authentication via asymmetric keys
+ MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and
+ Collecting Processes MUST verify the identity of its peer against its
+ authorized certificates, and MUST verify that the peer's certificate
+ matches its fully qualified domain name, or, in the case of SCTP, the
+ fully qualified domain name of one of its endpoints.
+
+ The fully qualified domain name used to identify an IPFIX Collecting
+ Process or Exporting Process may be stored either in a subjectAltName
+ extension of type dNSName, or in the most specific Common Name field
+ of the Subject field of the X.509 certificate. If both are present,
+ the subjectAltName extension is given preference.
+
+ Internationalized domain names (IDN) in either the subjectAltName
+ extension of type dNSName or the most specific Common Name field of
+ the Subject field of the X.509 certificate MUST be encoded using
+ Punycode [RFC3492] as described in Section 4 of [RFC3490],
+ "Conversion Operations".
+
+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.
+
+
+
+Claise, et al. Standards Track [Page 48]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ Direct denial-of-service 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,
+ a large amount of Options Template Records, etc.).
+
+ SCTP mandates a cookie-exchange mechanism designed to defend against
+ SCTP state exhaustion denial-of-service 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 & 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 &
+ DTLS (like limiting the number of new TLS or DTLS session 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, the rate at which IPFIX Messages will be accepted
+ by the Collecting Process, and adaptively limiting the amount of
+ state kept, particularly records waiting on Templates. These rate
+ and state limits MAY be provided by a Collecting Process; 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. PR-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
+ 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, implying that some
+ forensics may be left.
+
+
+
+
+
+Claise, et al. Standards Track [Page 49]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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 [RFC1948], [RFC4960]); 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.
+
+ 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.
+
+
+
+
+
+Claise, et al. Standards Track [Page 50]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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, it is outside the scope of this
+ document.
+
+12. IANA Considerations
+
+ 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 IPFIX Version Number value of 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 Option 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 IPFIX Version Number or IPFIX Set ID
+ assignments require a Standards Action [RFC2434], i.e., they are to
+ be made via Standards Track RFCs approved by the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 51]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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 a Data Set (which contains 2 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 52]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+A.2. Template Set Examples
+
+A.2.1. Template Set Using IETF-Specified Information Elements
+
+
+ We want to report the following Information Elements:
+
+ - The IPv4 source IP address: sourceIPv4Address in [RFC5102],
+ with a length of 4 octets
+
+ - The IPv4 destination IP address: destinationIPv4Address in
+ [RFC5102], with a length of 4 octets
+
+ - The next-hop IP address (IPv4): ipNextHopIPv4Address in
+ [RFC5102], with a length of 4 octets
+
+ - The number of packets of the Flow: inPacketDeltaCount in
+ [RFC5102], with a length of 4 octets
+
+ - The number of octets of the Flow: inOctetDeltaCount in
+ [RFC5102], 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| inPacketDeltaCount = 2 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| inOctetDeltaCount = 1 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.2. Template Set Using Enterprise-Specific Information Elements
+
+ We want to report the following Information Elements:
+
+ - The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a
+ length of 4 octets
+
+
+
+Claise, et al. Standards Track [Page 53]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ - The IPv4 destination IP address: destinationIPv4Address in
+ [RFC5102], with a length of 4 octets
+
+ - An enterprise-specific Information Element representing proprietary
+ information, with a type of 15 and a length of 4
+
+ - The number of packets of the Flow: inPacketDeltaCount in [RFC5102],
+ with a length of 4 octets
+
+ - The number of octets of the Flow: inOctetDeltaCount in [RFC5102],
+ 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| inPacketDeltaCount = 2 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| inOctetDeltaCount = 1 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 54]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+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 55]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+A.4. Options Template Set Examples
+
+A.4.1. Options Template Set Using IETF-Specified 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: exportedPacketCount [RFC5102], with
+ a length of 2 octets
+
+ - Total number of exported Flows: exportedFlowCount [RFC5102], with a
+ length of 2 octets
+
+ The line card, which is represented by the lineCardId Information
+ Element [RFC5102], 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| exportedPacketCount = 41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |0| exportedFlowCount = 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: exportedPacketCount [RFC5102],
+ 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 [RFC5102], is used as the Scope Field.
+
+
+
+Claise, et al. Standards Track [Page 56]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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| exportedPacketCount = 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 Section A.4.1:
+
+ - Total number of IPFIX Messages: exportedPacketCount [RFC5102],
+ with a length of 2 octets
+
+ - Total number of exported Flows: exportedFlowCount [RFC5102],
+ 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 57]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ 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| exportedPacketCount = 41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |0| exportedFlowCount = 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:
+
+ Line Card ID | IPFIX Message | Exported Flow Records
+ -------------------------------------------------------------------
+ Line Card 1 (lineCardId=1) | 345 | 10201
+ Line Card 2 (lineCardId=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 58]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+A.5. Variable-Length Information Element Examples
+
+A.5.1. Example of Variable-Length Information Element with Length
+ Inferior to 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 Length 255
+ to 65535 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 255 | 1000 | IE ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 1000 octet Information Element |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ : ... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... IE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+References
+
+Normative References
+
+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
+ Specification, Implementation and Analysis", RFC
+ 1305, March 1992.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 2434, October 1998.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
+ "Internet X.509 Public Key Infrastructure Certificate
+ and Certificate Revocation List (CRL) Profile", RFC
+ 3280, April 2002.
+
+
+
+
+Claise, et al. Standards Track [Page 59]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen,
+ "Transport Layer Security over Stream Control
+ Transmission Protocol", RFC 3436, December 2002.
+
+ [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+ Conrad, "Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension", RFC 3758, May 2004.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.1", RFC 4346, April
+ 2006.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
+ Layer Security", RFC 4347, April 2006.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3492] Costello, A., "Punycode: A Bootstring encoding of
+ Unicode for Internationalized Domain Names in
+ Applications (IDNA)", RFC 3492, March 2003.
+
+ [RFC4960] Stewart, R., Ed., "Stream Control Transmission
+ Protocol", RFC 4960, September 2007.
+
+ [RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and
+ J. Meyer, "Information Model for IP Flow Information
+ Export", RFC 5102, January 2008.
+
+ [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
+
+ [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J.
+ Quittek, "Architecture Model for IP Flow Information
+ Export", Work in Progress, September 2006.
+
+ [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
+ "IPFIX Applicability", Work in Progress, June 2007.
+
+ [PEN] IANA Private Enterprise Numbers registry
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+
+Claise, et al. Standards Track [Page 60]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+ [RFC1948] Bellovin, S., "Defending Against Sequence Number
+ Attacks", RFC 1948, May 1996.
+
+ [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Textual Conventions for SMIv2", STD 58, RFC 2579,
+ April 1999.
+
+ [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
+ "Requirements for IP Flow Information Export
+ (IPFIX)", RFC 3917, October 2004.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services
+ Export Version 9", RFC 3954, October 2004.
+
+ [IEEE.754.1985] Institute of Electrical and Electronics Engineers,
+ "Standard for Binary Floating-Point Arithmetic", IEEE
+ Standard 754, August 1985.
+
+ [dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer
+ Security for Stream Control Transmission Protocol",
+ Work in Progress, November 2007.
+
+Acknowledgments
+
+ We would like to thank the following persons: Ganesh Sadasivan for
+ his significant contribution during the initial phases of the
+ protocol specification; Juergen Quittek for the coordination job
+ within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, 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, and many more, for the technical reviews and feedback.
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 61]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+Authors' Addresses
+
+ Benoit Claise
+ Cisco Systems
+ De Kleetlaan 6a b1
+ 1831 Diegem
+ Belgium
+ Phone: +32 2 704 5622
+ EMail: bclaise@cisco.com
+
+ Stewart Bryant
+ Cisco Systems, Inc.
+ 250, Longwater,
+ Green Park,
+ Reading, RG2 6GB,
+ United Kingdom
+ Phone: +44 (0)20 8824-8828
+ EMail: stbryant@cisco.com
+
+ Simon Leinen
+ SWITCH
+ Werdstrasse 2
+ P.O. Box
+ CH-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
+
+ Brian H. Trammell
+ CERT Network Situational Awareness
+ Software Engineering Institute
+ 4500 Fifth Avenue
+ Pittsburgh, PA 15213
+ United States
+ Phone: +1 412 268 9748
+ EMail: bht@cert.org
+
+
+
+
+
+Claise, et al. Standards Track [Page 62]
+
+RFC 5101 IPFIX Protocol Specification January 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 63]
+