Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements
Extracted elements (28)
IE type records are scoped to a Transport Session rather than being persistent definitions because the mechanism is intended for interoperability within a session, not as a permanent out-of-band type registry replacement. This scoping also limits the attack surface for malicious type redefinition.
The informationElementId field from the PSAMP Information Model (RFC 5477) was reused rather than defining a new IE, but it only references IANA-defined IEs by itself; the privateEnterpriseNumber IE was added to scope type records to enterprise-specific IEs.
The type export mechanism is explicitly not a replacement for IANA registration of generally useful Information Elements. It introduces overhead and does not provide the real interoperability achieved by standardization; IANA registration is strongly recommended for new IEs intended for broad use.
Exporting Processes SHOULD NOT export type records that could reasonably be assumed to duplicate type information already available at the Collecting Process (e.g., for well-known IANA-registered IEs). This mechanism does not replace the need for implementations to track IANA registry updates.
If an enterprise-specific Information Element previously described via this type export mechanism later becomes an IANA-registered standard IE, old and new versions can coexist. A translation between the enterprise and standardized forms is not required and is out of scope.
An Exporting Process exporting data using Templates containing enterprise-specific Information Elements SHOULD export an Information Element type record for each such IE when interoperability across vendor implementations is important. Collecting Processes MAY use these type records to improve handling of unknown enterprise-specific IEs.
Exporting Processes MUST NOT export, and Collecting Processes MUST ignore, any informationElementName or informationElementDescription content that contains null characters (U+0000) in order to ensure buffer and string lengths are consistent.
Information Element type records containing invalid combinations of informationElementSemantics and informationElementDataType MUST NOT be sent by Exporting Processes, and MUST be ignored by Collecting Processes. For example, a counter cannot be encoded as an IPv4 address.
Information Element type records MUST be handled by Collecting Processes as scoped to the Transport Session in which they are sent; this facility is not intended to provide a method for the permanent definition of Information Elements.
Once an Information Element type record has been exported for a given IE within a given Transport Session, all subsequent type records for that IE MUST be identical. IE type records SHOULD NOT be duplicated within a given Observation Domain within a Transport Session.
The Enterprise bit in the informationElementId field associated with a privateEnterpriseNumber scope field MUST be ignored by the Collecting Process, since the enterprise number is conveyed separately via the privateEnterpriseNumber scope field.
Type information for a given Information Element MUST NOT be redefined by IE type records, and a Collecting Process MUST NOT allow an IE type record to replace its own internal definition of an Information Element. Information Elements for which a Collecting Process receives conflicting semantic or type information MUST be ignored.
The Information Element Type Options Template is an IPFIX Options Template that encodes IE type records inline within an IPFIX Message stream. It uses informationElementId and privateEnterpriseNumber as scope fields, and includes informationElementDataType, informationElementSemantics, informationElementUnits, informationElementRangeBegin/End, informationElementName, and informationElementDescription as non-scope fields.
The informationElementDataType Information Element (IE 339, unsigned8) encodes the abstract data type of an IPFIX Information Element. It takes values 0–19 corresponding to types such as octetArray, unsigned8–64, signed8–64, float32/64, boolean, macAddress, string, dateTime variants, and ipv4Address/ipv6Address.
The informationElementDescription Information Element (IE 340, string) carries a UTF-8 encoded Unicode human-readable description of an Information Element. It MAY be annotated with language tags inline; in the absence of a tag, 'i-default' SHOULD be assumed.
The informationElementName Information Element (IE 341, string) carries a UTF-8 encoded Unicode string serving as a simple identifier for an Information Element. It is used within IE type records and must not contain null characters (U+0000).
The informationElementRangeBegin (IE 342, unsigned64, semantics=quantity) and informationElementRangeEnd (IE 343, unsigned64, semantics=quantity) carry the inclusive low and high ends of the acceptable value range for an Information Element.
The informationElementSemantics Information Element (IE 344, unsigned8) encodes the semantic interpretation of an IPFIX Information Element's numeric value. Values are: 0=default (no semantics), 1=quantity, 2=totalCounter, 3=deltaCounter, 4=identifier, 5=flags.
The informationElementUnits Information Element (IE 345, unsigned16) describes the units of an IPFIX Information Element. Defined values range 0–12: none, bits, octets, packets, flows, seconds, milliseconds, microseconds, nanoseconds, 4-octet words, messages, hops, entries.
The privateEnterpriseNumber Information Element (IE 346, unsigned32, semantics=identifier) carries an IANA-assigned private enterprise number. It is used as a scope field alongside informationElementId to identify enterprise-specific Information Elements; set to 0 (or omitted) for IANA-assigned IEs.
Valid informationElementSemantics values are constrained by informationElementDataType: any value is valid for unsigned types; 'flags' is excluded for signed types; 'identifier' and 'flags' are excluded for floating-point types; only 'default' is valid for all other types (boolean, string, IP address, datetime, macAddress, octetArray).
IANA assigned Information Element numbers 339–346 in the IPFIX Information Element registry for: informationElementDataType (339), informationElementDescription (340), informationElementName (341), informationElementRangeBegin (342), informationElementRangeEnd (343), informationElementSemantics (344), informationElementUnits (345), and privateEnterpriseNumber (346).
IANA created the IPFIX Information Element Data Type subregistry for values of the informationElementDataType IE (339). New entries require a Standards Action per RFC 5226.
IANA created the IPFIX Information Element Semantics subregistry for values of the informationElementSemantics IE (344). New entries require a Standards Action per RFC 5226.
IANA created the IPFIX Information Element Units subregistry for values of the informationElementUnits IE (345). New entries may be added on a First Come First Served basis per RFC 5226.
IPFIX strings are length-prefixed and UTF-8 encoded, mitigating unterminated-string attacks. However, Collecting Processes must pay particular attention to buffer sizes when converting between length-prefixed and null-terminated strings, and must reject strings containing U+0000 null characters.
The maximum IPFIX string length is 65512 octets (max message 65535, minus message header 16, minus set header 4, minus variable-length field encoding 3). Implementations must handle informationElementName and informationElementDescription strings up to this size, regardless of typical IANA IE name lengths (~40 octets).
The type information precedence rules — a Collecting Process's current knowledge overrides IE type records, and types cannot be redefined during a session — are designed to minimize the opportunity for an attacker to maliciously redefine the data model.