IPFIX working group Internet Draft EDITOR: B. Claise draft-ietf-ipfix-protocol-21.txt Cisco Systems Expires: October 27, 2006 April 2006 IPFIX Protocol Specification Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies the 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 Claise, et. al Standard Track [Page 1] IPFIX Protocol Specification April 2006 data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction..................................................4 1.1 IPFIX Documents Overview.....................................4 2. Terminology....................................................5 2.1 Terminology Summary Table...................................10 3. IPFIX Message Format..........................................10 3.1 Message Header Format.......................................12 3.2 Field Specifier Format......................................13 3.3 Set and Set Header Format...................................15 3.3.1 Set Format...............................................15 3.3.2 Set Header Format........................................16 3.4 Record Format...............................................16 3.4.1 Template Record Format...................................17 3.4.2 Options Template Record Format...........................19 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.............24 4.2 The Metering Process Reliability Statistics Option Template.25 4.3 The Exporting Process Reliability Statistics Option Template26 4.4 The Flow Keys Option Template...............................27 5. IPFIX Message Header "Export Time" and Flow Record Time.......28 6. Linkage with the Information Model............................28 6.1 Encoding of IPFIX Data Types................................29 6.1.1 Integral Data Types......................................29 6.1.2 Address Types............................................29 6.1.3 float32..................................................29 6.1.4 float64..................................................29 6.1.5 boolean..................................................29 6.1.6 string and octetarray....................................30 6.1.7 dateTimeseconds..........................................30 6.1.8 dateTimeMilliseconds.....................................30 6.1.9 dateTimeNanoseconds......................................30 6.1.10 dateTimeMicroseconds.....................................30 6.2 Reduced Size Encoding of Integer and Float Types............30 Claise, et. al Standard Track [Page 2] IPFIX Protocol Specification April 2006 7. Variable Length Information Element...........................31 8. Template Management...........................................33 9. The Collecting Process's Side.................................36 10. Transport Protocol...........................................38 10.1 Transport Compliance and Transport Usage...................38 10.2 SCTP.......................................................39 10.2.1 Congestion Avoidance.....................................39 10.2.2 Reliability..............................................39 10.2.3 MTU......................................................39 10.2.4 Exporting Process........................................40 10.2.4.1 Association Establishment...............................40 10.2.4.2 Association Shutdown....................................40 10.2.4.3 Stream..................................................41 10.2.4.4 Template Management.....................................42 10.2.5 Collecting Process.......................................42 10.2.6 Failover.................................................42 10.3 UDP........................................................42 10.3.1 Congestion Avoidance.....................................42 10.3.2 Reliability..............................................42 10.3.3 MTU......................................................43 10.3.4 Port Numbers.............................................43 10.3.5 Exporting Process........................................43 10.3.6 Template Management......................................43 10.3.7 Collecting Process.......................................44 10.3.8 Failover.................................................45 10.4 TCP........................................................45 10.4.1 Connection Management....................................45 10.4.1.1 Connection Establishment................................45 10.4.1.2 Graceful Connection Release.............................45 10.4.1.3 Restarting Interrupted Connections......................46 10.4.1.4 Failover................................................46 10.4.2 Data Transmission........................................46 10.4.2.1 IPFIX Message Encoding..................................46 10.4.2.2 Templates...............................................47 10.4.2.3 Congestion Handling and Reliability.....................47 11. Security Considerations......................................48 11.1 IPsec Usage................................................49 11.1.1 Selectors................................................49 11.1.2 Mode.....................................................49 11.1.3 Key Management...........................................49 11.1.4 Security Policy..........................................49 11.1.5 Authentication...........................................50 11.1.6 Availability.............................................50 11.2 TLS Usage..................................................50 11.3 Protection against DoS attacks.............................50 11.4 When IPsec or TLS is not an option.........................51 11.5 Logging an IPFIX Attack....................................51 12. IANA Considerations..........................................52 13. Appendix A...................................................52 Claise, et. al Standard Track [Page 3] IPFIX Protocol Specification April 2006 13.1 Message Header Example.....................................53 13.2 Template Set Examples......................................53 13.2.1 Template Set using IETF specified Information Elements...53 13.2.2 Template Set using Enterprise Specific Information Elements.........................................................54 13.3 Data Set Example...........................................55 13.4 Options Template Set Examples..............................56 13.4.1 Options Template Set using IETF specified Information Elements.........................................................56 13.4.2 Options Template Set using enterprise-specific Information Elements.............................................57 13.4.3 Options Template Set using an enterprise-specific scope..58 13.4.4 Data Set using an enterprise-specific scope..............59 13.5 Variable length Information Element examples...............59 13.5.1 Example of Variable Length Information Element with Length inferior to 255 octets....................................59 13.5.2 Example of Variable Length Information Element with Length 255 to 65535 octets.......................................59 14. References...................................................60 14.1 Normative References.......................................60 14.2 Informative References.....................................61 15. Acknowledgments..............................................61 1. Introduction A data network with IP traffic, primarily consists of IP Flows passing through the network elements of the network. It is often interesting, useful or even a requirement to have access to information about these flows that pass through the network elements for administrative or other 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 Claise, et. al Standard Track [Page 4] IPFIX Protocol Specification April 2006 process is defined in [IPFIX-ARCH], per the requirements defined in [RFC3917]. This document specifies how IPFIX data record and templates are carried via a congestion-aware transport protocol from IPFIX exporting processes to IPFIX collecting process. IPFIX has a formal description of IPFIX information elements, their name, type and additional semantic information, as specified in [IPFIX-INFO]. 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 definitions of the basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical with 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 has also been defined. Definitions in this document and in [IPFIX-ARCH] are equivalent, except that definitions which 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. 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 Claise, et. al Standard Track [Page 5] IPFIX Protocol Specification April 2006 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. 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 field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields [RFC1889]) 2. one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...) A packet is defined to belong 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 which Claise, et. al Standard Track [Page 6] IPFIX Protocol Specification April 2006 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. AS number) and which 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. 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 which hosts one or more Exporting Processes is termed an Exporter. Claise, et. al Standard Track [Page 7] IPFIX Protocol Specification April 2006 IPFIX Device An IPFIX Device hosts at least one Observation Point, a Metering Process and an Exporting Process. 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 which hosts one or more Collecting Processes is termed a Collector. Template Template is an ordered sequence of 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. 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. Claise, et. al Standard Track [Page 8] IPFIX Protocol Specification April 2006 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. Information Element An Information Element is a protocol and encoding independent description of an attribute which may appear in an IPFIX Record. The IPFIX information model [IPFIX-INFO] defines the base set of Claise, et. al Standard Track [Page 9] IPFIX Protocol Specification April 2006 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. 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). 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 | Claise, et. al Standard Track [Page 10] IPFIX Protocol Specification April 2006 +----------------------------------------------------+ ... +----------------------------------------------------+ | 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 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 | | | | +---------+ +---------+ +---------+ | +--------+----------------------------------------------+ Claise, et. al Standard Track [Page 11] IPFIX Protocol Specification April 2006 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 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 Claise, et. al Standard Track [Page 12] IPFIX Protocol Specification April 2006 Total length of the IPFIX Message, measured in octets, including Message Header and Set(s). Export Time Time in seconds since 0000 UTC Jan 1st 1970, at which the IPFIX Message Header leaves the Exporter. Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this stream from the current Observation Domain by the Exporting Process. 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. Collecting Processes SHOULD use the combination of the Exporter (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message. For example, when exporting the Exporting Process Statistics, or in case of hierarchy of Collector when aggregated data records are exported. 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 [IPFIX-INFO] 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. Claise, et. al Standard Track [Page 13] IPFIX Protocol Specification April 2006 When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element and the Enterprise Number MUST be present. An example of this is shown in section 13.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 the Information Element. Refer to [IPFIX-INFO]. Field Length The length of the corresponding encoded Information Element, in octets. Refer to [IPFIX-INFO]. The field length may be smaller than the definition in [IPFIX-INFO] if reduced size encoding is used (see section 6.2). The value 65535 is reserved for variable length Information Element (see section 7). Enterprise Number IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record. Claise, et. al Standard Track [Page 14] IPFIX Protocol Specification April 2006 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 records 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. Record One of the Record Formats: Template Record or 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 Claise, et. al Standard Track [Page 15] IPFIX Protocol Specification April 2006 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' [IPFIX-INFO] 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. 3.4 Record Format Claise, et. al Standard Track [Page 16] IPFIX Protocol Specification April 2006 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 The Template Record Header Field Definitions are as follows: Claise, et. al Standard Track [Page 17] IPFIX Protocol Specification April 2006 Template ID Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the 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 Set Header, Template Header and several Field Specifiers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 1.1 | Field Length 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element id. 1.2 | Field Length 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 1.N | Field Length 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element id. 2.1 | Field Length 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Information Element id. 2.2 | Field Length 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | Claise, et. al Standard Track [Page 18] IPFIX Protocol Specification April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 which would not be possible with Flow Records alone. 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 Claise, et. al Standard Track [Page 19] IPFIX Protocol Specification April 2006 "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 [IPFIX-INFO]. 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, sourceId, 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 specifed as scope. For example: the counter Information Elements. Finally, note that the Scope Field Count MAY NOT be zero. 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 | +--------------------------------------------------+ Claise, et. al Standard Track [Page 20] IPFIX Protocol Specification April 2006 ... +--------------------------------------------------+ | 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. 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 MAY NOT be zero. The example in Figure O shows an Option Template Set with mixed IETF and enterprise-specific Information Elements. It consists of Set Header, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 21] IPFIX Protocol Specification April 2006 | 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 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 | +--------------------------------------------------+ Claise, et. al Standard Track [Page 22] IPFIX Protocol Specification April 2006 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 [IPFIX-INFO]. 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 several Field Values. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = Template ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 1 | Record 1 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 1 | Record 2 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 1 | Record 3 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Padding (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure Q: Data Set, containing Data Records 4. Specific Reporting Requirements Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process. Claise, et. al Standard Track [Page 23] IPFIX Protocol Specification April 2006 The Option Template and Options Template Records defined in these sub-sections, 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 sub-sections. 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 [IPFIX-INFO]: sourceId 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 Claise, et. al Standard Track [Page 24] IPFIX Protocol Specification April 2006 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 [IPFIX-INFO]: sourceId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field. 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 time stamp of the first IP packet that was ignored by the Metering Process. For this time stamp, any of the "flowStart" time stamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last ignored The time stamp of the last IP packet that was ignored by the Metering Process. For this time stamp, any of the "flowEnd" time stamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. Claise, et. al Standard Track [Page 25] IPFIX Protocol Specification April 2006 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 [IPFIX-INFO]: Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [IPFIX-INFO] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or 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 but dropped by the Metering Process or by the Exporting Process instead of sending it to the Collecting Process. notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and but dropped by the Metering Process or by the Exporting Process instead of sending it to the Collecting Process. notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and but dropped Claise, et. al Standard Track [Page 26] IPFIX Protocol Specification April 2006 by the Metering Process or by the Exporting Process instead of sending it to the Collecting Process. time first flow dropped The time stamp of the first Flow was dropped by the Metering Process. For this time stamp, any of the "flowStart" time stamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last flow dropped The time stamp of the last IP packet that was ignored by the Metering Process. For this time stamp, any of the "flowEnd" time stamp 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 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 server as Flow Keys of the reported Flow. The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [IPFIX-INFO]: templateId An identifier of a Template that locally unique to the Exporting Process. This Information Claise, et. al Standard Track [Page 27] IPFIX Protocol Specification April 2006 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 1st, 1970, at which the IPFIX Message Header leaves the Exporter. The time-related Information Elements specified in [IPFIX-INFO] 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 1st, 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 [IPFIX-INFO], containing the time since 0000 UTC Jan 1st 1970. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [IPFIX-INFO] 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 [IPFIX-INFO], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bits counter would not be sufficient to contain the flow start time offset. 6. Linkage with the Information Model Claise, et. al Standard Track [Page 28] IPFIX Protocol Specification April 2006 The Information Elements [IPFIX-INFO] 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 [IPFIX-INFO]. 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]: that 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. Claise, et. al Standard Track [Page 29] IPFIX Protocol Specification April 2006 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. 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 normalised to the GMT timezone. It MUST be encoded in a 32- bit integer containing the number of seconds since 0000 UTC Jan 1st 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 1st 1970. 6.1.9 dateTimeNanoseconds The data type of dateTimeNanoseconds represents a time value in units of nanoseconds 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 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.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 [IPFIX-INFO], based on the assumption that the Claise, et. al Standard Track [Page 30] IPFIX Protocol Specification April 2006 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 [IPFIX-INFO] will always define the maximum encoding size. For instance the information model [IPFIX-INFO] 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. 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, 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 [IPFIX-INFO]. 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. Claise, et. al Standard Track [Page 31] IPFIX Protocol Specification April 2006 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. 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. Claise, et. al Standard Track [Page 32] IPFIX Protocol Specification April 2006 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 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. If an Information Element is required more than once in 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 ddresses 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 Option Template Sets MUST be only sent once on SCTP stream zero with full reliability. As such, 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. New Template Records SHOULD be transmitted as soon as they are created. The Exporting Process MAY transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to 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). Claise, et. al Standard Track [Page 33] IPFIX Protocol Specification April 2006 A Template ID MUST be unique per Observation Domain. Different Observation Domains from the same Exporter 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 Withdraw Message. The Template Withdraw 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 withdraw message. A Template Withdraw 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. 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 Withdraw Message withdraws the Template IDs for the Observation Domain ID specified in the IPFIX Message header. Claise, et. al Standard Track [Page 34] IPFIX Protocol Specification April 2006 The Template Withdraw Message MUST NOT contain new Template or Options Template Records. If the measurement parameters change, 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. If a Template is changed, a Template Withdraw Message MUST be sent to delete the Template. When the Exporting Process restarts, due to the SCTP association shutdown, all Template assignments are lost and Template IDs MUST be re-assigned. 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. 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 | Claise, et. al Standard Track [Page 35] IPFIX Protocol Specification April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. A Collecting Process MUST support at least two inbound streams per association. An Exporting Process MAY ask for and support more than two streams. If the Collecting Process receives a malformed IPFIX Message, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error. 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. Template IDs are unique per Exporting Process and per Observation Domain. If the Collecting Process receives a Template which has already been received but which has not previously been withdrawn (i.e. a Template Record from the same Exporter Observation Domain with the same Template ID), then the Collecting Process MUST shutdown 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. Claise, et. al Standard Track [Page 36] IPFIX Protocol Specification April 2006 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 which 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 can not 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 can not 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 Withdraw Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific Exporter and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages. Claise, et. al Standard Track [Page 37] IPFIX Protocol Specification April 2006 A Collecting Process that receives IPFIX Messages from several Observation Domains from the same Exporter 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 a 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 [RFC2960] and PR-SCTP [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 Standard Track [Page 38] IPFIX Protocol Specification April 2006 UDP MAY be used although it is not a congestion aware protocol. However, the IPFIX traffic between Exporter and Collector MUST remain wholly within the administrative domains of the operators. 10.2 SCTP This section describes how IPFIX can be transported over SCTP [RFC2960] 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 operate in unreliable and partially reliable modes [RFC3758]. Using reliable SCTP streams (referred to hereafter as "streams") for the IPFIX export is not in itself a guarantee that all Data Records are 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 sequence numbers used for export MUST reflect the loss of data. 10.2.3 MTU Claise, et. al Standard Track [Page 39] IPFIX Protocol Specification April 2006 SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery. 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 Exporting Process tries to connect to this port. 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 associations (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). Each SCTP stream over which TLS [TLS] will be used MUST be established as a fully reliable bidirectional stream as required by RFC 3436 [RFC3436]. 10.2.4.2 Association Shutdown When an Exporting Process is shutdown, it SHOULD shutdown the SCTP association. When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shutdown 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. If TLS [TLS] is used, the Process initiating association teardown SHOULD send a close_notify alert over each TLS stream before closing the SCTP association. When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment. Claise, et. al Standard Track [Page 40] IPFIX Protocol Specification April 2006 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 MUST request at least two outbound streams per association. The first stream (referred to as stream zero in the rest of this document), is used to send the Template Set and the Options Template Set. Stream zero MUST be fully reliable. Data Sets MUST NOT be sent on stream zero. Depending on the application requirement, the Exporting Process selects the mode (unreliable, partially reliable, or fully reliable) of the stream, used to send the Data Sets. Unreliable mode MAY be used where the application does not require reliable transmission and the use of a retransmission queue is impractical. Only fully reliable bidirectional streams are available if TLS [TLS] is used, as required by RFC 3436 [RFC3436]. An Exporter MAY use multiple streams to export Data Sets, in some cases different applications will have different requirements in terms of reliability. In such a case, the Observation Domain MUST use the same Observation Domain ID value on all of the multiple streams it uses. Data Sets from multiple Observation Domains MUST NOT be transmitted over the same stream; the Collecting Process should however verify that the Observation Domain ID values are the expected values. When Data Sets are exported over a partially reliable stream, they SHOULD be marked for retransmission as long as there is room in the SCTP send queues. However, if the queue overflows during times of congestion or other retransmission events, the oldest Data Record that has been transmitted and marked as partially reliable should be freed and marked to be skipped per the PR-SCTP [RFC3758] specification. The freed buffer space should then be re-used for the new Data Sets being exported. Claise, et. al Standard Track [Page 41] IPFIX Protocol Specification April 2006 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 deprecated. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion. 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. Claise, et. al Standard Track [Page 42] IPFIX Protocol Specification April 2006 The Collecting Process could deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Message sequence number. In the case of UDP, the IPFIX Message sequence number contains the total number of IPFIX Data Records received for the UDP association, prior to the receipt of this IPFIX Message, modulo 2^32. IPFIX sequence number discontinuities SHOULD be logged. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be resent at regular intervals in case previous copies were lost. Implementations MAY send templates using a reliable transport protocol, and send IPFIX Data Records using UDP as the transport protocol. 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. 10.3.4 Port Numbers By default, the Collecting Process listens on the UDP port 4739. By default the Exporting Process tries to connect to this port. 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 (Options) Template transmission MUST be configurable. New Template Records SHOULD be transmitted as soon as they are created, and SHOULD be transmitted before any associated Data Record is transmitted. 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 MAY Claise, et. al Standard Track [Page 43] IPFIX Protocol Specification April 2006 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. Template Withdraw Messages SHOULD NOT be sent over UDP. 10.3.7 Collecting Process The Collecting Process MUST associate a lifetime with each Template received via UDP. Templates not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the template is not refreshed by the Exporting Process before that lifetime has expired, the Collecting Process MUST discard the Template 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 which are associated with the expired Template. If a Template is refreshed with a Template Record that differs from the previous received Template Record, the Collecting Process SHOULD log a warning and replace the previous received Template Record with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher that the Template refresh timeout configured on the Exporting Process. At any given time the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: . The Collecting Process SHOULD accept Data Records without the associated Template Record. If the Template Records have not been received at the time Data Records are received, the Collecting Claise, et. al Standard Track [Page 44] IPFIX Protocol Specification April 2006 Process SHOULD store the Data Records for a short period of time and decode them after the Template Records are received. The short period of time MUST be lower than the Template lifetime. 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 IFPIX Messages. Therefore, it can not 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 Exporting Process tries to connect to this port. 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. 10.4.1.2 Graceful Connection Release When an Exporting Process is shutdown, it SHOULD shutdown the TCP connection. If TLS [TLS] is used, the Exporting Process SHOULD send a close_notify alert before closing the TCP connection. Claise, et. al Standard Track [Page 45] IPFIX Protocol Specification April 2006 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 an 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, and, if configured, TLS [TLS] usage has been negotiated, 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. Claise, et. al Standard Track [Page 46] IPFIX Protocol Specification April 2006 In the case of TCP, the IPFIX Message sequence number contains the total number of IPFIX Data Records received for the TCP connection, prior to the receipt of this IPFIX Message, modulo 2^32. 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 Templates For each template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that template. 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 an TCP connection is closed, the Collecting Process MUST discard all templates received over that connection and stop decoding IPFIX Messages that use those templates. 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 timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked. Claise, et. al Standard Track [Page 47] IPFIX Protocol Specification April 2006 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. 11. Security Considerations Because IPFIX can be used to collect billing information and network forensics, confusing or blinding IPFIX must be seen as a prime objective during a sophisticated network attack. If an attacker is in a position to inject false messages into an IPFIX Message stream, this will allow them to send forged Data Records or Template Records. Forged Templates may impair the Collectors ability to process any further Flow Records. Forged Flow Records would have a direct effect on the application using the Flows, for example a billing system may generate incorrect billing information. Forged options may be able to alter the meaning of Flow Records, for example if the sample rate is changed. The IPFIX Messages themselves may contain information of value to an attacker, and thus care must be taken to confine their visibility to authorized users. IPFIX Messages can be secured using IPsec. Alternatively if IPFIX runs on top of SCTP or TCP, TLS [TLS] can be used. 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 responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data. Claise, et. al Standard Track [Page 48] IPFIX Protocol Specification April 2006 11.1 IPsec Usage To secure messages between the Exporter and the Collector an IPFIX implementation MAY use IPsec. To ensure interworking between Exporters and Collectors from different vendors, the following IPsec profile MUST be supported. This profile is derived from [USEIPSEC]. 11.1.1 Selectors IPFIX runs between manually configured pairs of hosts on the UDP, TCP, or SCTP transport port 4739. The appropriate selector would be Exporter-Collector pairs and port number. Note that, if the Exporter is a router, a non-interface ("loopback") address should be used. 11.1.2 Mode IPsec MUST be run in transport mode. The AH and ESP MUST be supported by an IPFIX implementation of IPsec. The Authentication Header (AH) [RFC2402] MUST be used if authentication is required. The Security Protocol (ESP) [RFC2406] must be used if there is a threat to the IPFIX Message content, or if that content is confidential. Normally in situations where the ESP was required the AH would also be required. If only ESP is used, the sender's IP address MUST be checked against the IP address asserted in the key management exchange. 11.1.3 Key Management In many networks, manual key management will be sufficient, and this reduces the complexity of the Exporter, albeit at a cost of greater configuration complexity. Manual key management MUST be supported. If a replay attack is considered likely, an automated key management such as the IKE [IKE] key management system SHOULD be used. 11.1.4 Security Policy Connections should be accepted only from designated peers. Claise, et. al Standard Track [Page 49] IPFIX Protocol Specification April 2006 11.1.5 Authentication Given the number of IPFIX capable Exporters that are likely to be deployed by large ISPs, there will be circumstances where shared key mechanisms are not adequate. Where an automated key management system is used, certificate-based IKE SHOULD be supported. 11.1.6 Availability It is accepted that IPsec will not be universally available in IPFIX Exporters, and that where it is available, there may be issues of throughput, which may itself raise security issues. In such circumstances the other security measures described in this document provide some threat mitigation. 11.2 TLS Usage The IPFIX Exporter initiating a connection acts as a TLS client according to [TLS], and an IPFIX Collector that accepts a connection acts as a TLS server. If mutual authentication is required the Collector MUST request a certificate from the Exporter, and the Exporter MUST be prepared to supply a certificate on request. 11.3 Protection against DoS attacks An attacker may directly mount a DoS attack by generating large amounts of traffic. If TCP is used for transport, then the Flow to the Collector would back off due to congestion and eventually stall, blinding the IPFIX system. An attack could then proceed without further observation. PR-SCTP will have a different pathology under such an attack. Stale data at the head of the queue will get flushed giving some visibility of the attack. In case of UDP, IPFIX would reduce to some sort of sampling, meaning that some forensics may be left. To avoid blinding of the IPFIX system some mechanism for service differentiation can be used to prioritize IPFIX traffic over user traffic. An alternative is to use a dedicated network for the transport of IPFIX Messages. By sending the IPFIX Messages over a dedicated network, IPFIX Message loss induced by user traffic congestion is minimized. However an attacker may trigger the generation of excessive IPFIX Messages, and to avoid information Claise, et. al Standard Track [Page 50] IPFIX Protocol Specification April 2006 loss during such an attack the IPFIX network must be adequately sized. 11.4 When IPsec or TLS is not an option The use of IPsec or TLS might not be possible in certain cases due to performance issues. Without IPsec or TLS the only way that an IPFIX Exporter, proxy or Collector can authenticate each other is by inspecting the IP source address of the packets carrying the IPFIX Messages and their transport acknowledgments. Useful protection is gained by allocating Exporter and Collector IP addresses from ranges that are excluded from use by user traffic and hence preventing spoofing attacks by ingress packet filtering. Where large numbers of Exporters, proxies and Collectors are used in a network, it may be tempting for the administrator to not impose source IP address restrictions but this leaves a proxy or Collector open to the reception of invalid information. The use of an open proxy or Collector is therefore discouraged. If IP address spoofing can not be prevented, some level of protection against an insertion attack is required. With a modern implementation of TCP with good ISN randomization [RFC1948] or SCTP insertion such attacks are difficult without the ability to snoop the packet Flow [RFC2960]. UDP is vulnerable to insertion attacks, and SHOULD be protected by the use of the address restriction mechanism described above. The use of a dedicated network prevents IPFIX Messages from being inspected by an external attacker. 11.5 Logging an IPFIX Attack A Collector may detect problems by tracking the IPFIX Sequence Number and therefore SHOULD provide a logging mechanism for tracking out of sequence messages. Such out of sequence messages may not only be caused by network congestion or Exporter/Collector resource exhaustion but also by an attacker injecting false messages. Note that an attacker may be able to exploit the behavior of the Collector when it receives an out of sequence message. For example a Collector that simply resets the expected Sequence Number upon Claise, et. al Standard Track [Page 51] IPFIX Protocol Specification April 2006 receipt of a later message would easily be temporarily blinded by deliberately injecting messages with a much larger Sequence Number. 12. IANA Considerations Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document IANA-RFC [RFC2434]. 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. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. 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. Changes in either IPFIX Version Number or IPFIX Set ID assignments require an Standards Action [RFC 2434], i.e. they are to be made via Standards Track RFCs approved by the IESG. 13. Appendix A 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) | | | +--------------+ +------------------+ +--------+------------------------------------------. . . Claise, et. al Standard Track [Page 52] IPFIX Protocol Specification April 2006 . . .-------------------------------------------+ +------------------+ +------------------+ | | Options | | Data | | . . . | Template Set | | Set | | | (1 Template) | | (2 Data Records) | | +------------------+ +------------------+ | . . .-------------------------------------------+ 13.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.2 Template Set Examples 13.2.1 Template Set using IETF specified Information Elements We want to report the following Information Elements: - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], with a length of 4 octets - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- INFO], with a length of 4 octets - The next-hop IP address (IPv4): ipNextHopIPv4Address in [IPFIX- INFO], with a length of 4 octets - The number of packets of the Flow: inPacketDeltaCount in [IPFIX- INFO], with a length of 4 octets - The number of octets of the Flow: inOctetDeltaCount in [IPFIX- INFO], with a length of 4 octets Claise, et. al Standard Track [Page 53] IPFIX Protocol Specification April 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.2.2 Template Set using Enterprise Specific Information Elements We want to report the following Information Elements: - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], with a length of 4 octets - The IPv4 destination IP address: destinationIPv4Address in [IPFIX-INFO], 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 [IPFIX-INFO], with a length of 4 octets - The number of octets of the Flow: inOctetDeltaCount in [IPFIX-INFO], with a length of 4 octets Therefore, the Template Set will be composed of the following: Claise, et. al Standard Track [Page 54] IPFIX Protocol Specification April 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.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 ------------------------------------------------------------------ 198.18.1.12 | 198.18.2.254 | 198.18.1.1 | 5009 | 5344385 198.18.1.27 | 198.18.2.23 | 198.18.1.2 | 748 | 388934 198.18.1.56 | 198.18.2.65 | 198.18.1.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5009 | Claise, et. al Standard Track [Page 55] IPFIX Protocol Specification April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5344385 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.2.23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 748 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 388934 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.56 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.2.65 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6534 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that padding is not necessary in this example. 13.4 Options Template Set Examples 13.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 [IPFIX-INFO], with a length of 2 octets - Total number of exported Flows: exportedFlowCount [IPFIX-INFO], with a length of 2 octets The line card, which is represented by the lineCardId Information Element [IPFIX-INFO], is used as the Scope Field. Therefore, the Options Template Set will be: Claise, et. al Standard Track [Page 56] IPFIX Protocol Specification April 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.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 [IPFIX-INFO], 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 [IPFIX-INFO], is used as the Scope Field. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 57] IPFIX Protocol Specification April 2006 | Scope 1 Field Length = 4 |0| exportedPacketCount = 41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |1|Information Element Id. = 42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | Enterprise number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Enterprise number | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.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 13.4.1: - Total number of IPFIX Messages: exportedPacketCount [IPFIX-INFO], with a length of 2 octets - Total number of exported Flows: exportedFlowCount [IPFIX-INFO], with a length of 2 octets But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Claise, et. al Standard Track [Page 58] IPFIX Protocol Specification April 2006 13.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.5 Variable length Information Element examples 13.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 13.5.2 Example of Variable Length Information Element with Length 255 to 65535 octets 0 1 2 3 Claise, et. al Standard Track [Page 59] IPFIX Protocol Specification April 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 14. References 14.1 Normative References [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- arch-09.txt, May 2005 [IPFIX-INFO] Quittek, J., Bryant S., Claise, B., Meyer, J. "Information Model for IP Flow Information Export" draft-ietf-ipfix- info-11.txt, May 2005 [UDP] Postel, J., "User Datagram Protocol" RFC 768, August 1980 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" RFC 793, September 1981 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header ", RFC 2402, November 1998 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", RFC 2960, October 2000 Claise, et. al Standard Track [Page 60] IPFIX Protocol Specification April 2006 [RFC3436] Rescorla, E., Tuexen, M., "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004 14.2 Informative References [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX Applicability", draft-ietf-ipfix-as-06.txt, May 2005 [PEN] IANA Private Enterprise Numbers registry http://www.iana.org/assignments/enterprise-numbers [USEIPSEC] Bellovin, S., Guidelines for Mandating the Use of IPsec, draft-bellovin-useipsec-02.txt, October 2003, work in progress. [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications ", RFC 1889, January 1996 [RFC2579] McCloghrie, K., et al "Textual Conventions for SMIv2", RFC 2579, April 1999 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., "Requirements for IP Flow Information Export" RFC 3917, October 2004 [RFC3954] Claise, B., et al "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. 15. Acknowledgments We would like to thank the following persons: Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, and Paul Aitken for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise; Martin Djernaes for the Claise, et. al Standard Track [Page 61] IPFIX Protocol Specification April 2006 first essay on the SCTP section; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Brian Trammell, Robert Lowe, Paul Calato, and many more, for the technical review and feedback. Authors' Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 E-mail: 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 Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Simon Leinen SWITCH Limmatquai 138 P.O. Box CH-8021 Zurich Switzerland Phone: +41 1 268 1536 EMail: simon@switch.ch Thomas Dietz NEC Europte Ltd. Claise, et. al Standard Track [Page 62] IPFIX Protocol Specification April 2006 Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-28 Email: dietz@netlab.nec.de Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Claise, et. al Standard Track [Page 63] IPFIX Protocol Specification April 2006 Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Claise, et. al Standard Track [Page 64]