idnits 2.17.1 draft-ietf-ipfix-protocol-rfc5101bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2013) is 3935 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 1014 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-IANA' -- Obsolete informational reference (is this intentional?): RFC 5101 (ref. 'RFC5103') (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-05 Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Obsoletes: 5101 B. Trammell, Ed. 5 Category: Standards Track ETH Zurich 6 Expires: January 12, 2014 July 11, 2013 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of Flow Information 10 draft-ietf-ipfix-protocol-rfc5101bis-10 12 Abstract 14 This document specifies the IP Flow Information Export (IPFIX) 15 protocol that serves for transmitting Traffic Flow information over 16 the network. In order to transmit Traffic Flow information from an 17 Exporting Process to a Collecting Process, a common representation of 18 flow data and a standard means of communicating them is required. 19 This document describes how the IPFIX Data and Template Records are 20 carried over a number of transport protocols from an IPFIX Exporting 21 Process to an IPFIX Collecting Process. This document obsoletes RFC 22 5101. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 22, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Changes since RFC 5101 . . . . . . . . . . . . . . . . . . 5 60 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 7 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 13 63 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 13 64 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 15 65 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 16 66 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 17 67 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 18 68 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 19 69 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 19 70 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 19 71 3.4.2. Options Template Record Format . . . . . . . . . . . . 22 72 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 22 73 3.4.2.2. Options Template Record Format . . . . . . . . . . 22 74 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 25 75 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 26 76 4.1. The Metering Process Statistics Options Template . . . . . 26 77 4.2. The Metering Process Reliability Statistics Options 78 Template . . . . . . . . . . . . . . . . . . . . . . . . . 27 79 4.3. The Exporting Process Reliability Statistics Options 80 Template . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 30 82 5. Timing Considerations . . . . . . . . . . . . . . . . . . . . 30 83 5.1 IPFIX Message Header Export Time and Flow Record Time . . . 30 84 5.2 Supporting Timestamp Wraparound . . . . . . . . . . . . . . 31 85 6. Linkage with the Information Model . . . . . . . . . . . . . . 31 86 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 32 87 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 32 88 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 32 89 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 32 90 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 32 91 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 32 92 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 32 93 6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 33 94 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 33 95 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 33 96 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 34 97 6.2. Reduced Size Encoding . . . . . . . . . . . . . . . . . . 34 98 7. Variable-Length Information Element . . . . . . . . . . . . . 35 99 8. Template Management . . . . . . . . . . . . . . . . . . . . . 36 100 8.1. Template Withdrawal and Redefinition . . . . . . . . . . . 38 101 8.2 Sequencing Template Management Actions . . . . . . . . . . 40 102 8.3. Additional considerations for Template Management over 103 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 104 8.4. Additional considerations for Template Management over 105 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 106 9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 42 107 9.1. Collecting Process handling of malformed IPFIX Messages . . 43 108 9.2. Additional considerations for SCTP Collecting Processes . 44 109 9.3. Additional considerations for UDP Collecting Processes . . 44 110 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 44 111 10.1. Transport Compliance and Transport Usage . . . . . . . . 45 112 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 46 113 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 46 114 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 46 115 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 46 116 10.2.4. Association Establishment and Shutdown . . . . . . . 46 117 10.2.5. Failover . . . . . . . . . . . . . . . . . . . . . . 47 118 10.2.6. Streams . . . . . . . . . . . . . . . . . . . . . . . 47 119 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 120 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 48 121 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 48 122 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 48 123 10.3.4. Session Establishment and Shutdown . . . . . . . . . 49 124 10.3.5. Failover and Session Duplication . . . . . . . . . . 49 125 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 126 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 49 127 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 50 128 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 50 129 10.4.4. Connection Establishment and Shutdown . . . . . . . . 50 130 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 51 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 132 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 52 133 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 53 134 11.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 53 135 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 54 136 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 55 137 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 56 138 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 56 139 11.8. Privacy Considerations for Collected Data . . . . . . . . 56 140 12. Management Considerations . . . . . . . . . . . . . . . . . . 57 141 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 142 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 60 143 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 60 144 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 61 145 A.2.1. Template Set Using IANA Information Elements . . . . . 61 146 A.2.2. Template Set Using Enterprise-Specific Information 147 Elements . . . . . . . . . . . . . . . . . . . . . . . 61 148 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 63 149 A.4. Options Template Set Examples . . . . . . . . . . . . . . 64 150 A.4.1. Options Template Set Using IANA Information Elements . 64 151 A.4.2. Options Template Set Using Enterprise-Specific 152 Information . . . . . . . . . . . . . . . . . . . . . 64 153 A.4.3. Options Template Set Using an Enterprise-Specific 154 Scope . . . . . . . . . . . . . . . . . . . . . . . . 65 155 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 66 156 A.5. Variable-Length Information Element Examples . . . . . . . 67 157 A.5.1. Example of Variable-Length Information Element with 158 Length . . . . . . . . . . . . . . . . . . . . . . . . 67 159 A.5.2. Example of Variable-Length Information Element with 160 3 Octet Length Encoding . . . . . . . . . . . . . . . 67 161 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 162 Normative References . . . . . . . . . . . . . . . . . . . . . . . 68 163 Informative References . . . . . . . . . . . . . . . . . . . . . . 69 164 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 72 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 166 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 73 168 1. Introduction 170 Traffic on a data network can be seen as consisting of flows passing 171 through network elements. It is often interesting, useful, or even 172 necessary to have access to information about these flows that pass 173 through the network elements for administrative or other purposes. A 174 Collecting Process should be able to receive the flow information 175 passing through multiple network elements within the data network. 176 This requires uniformity in the method of representing the flow 177 information and the means of communicating the flows from the network 178 elements to the collection point. This document specifies a protocol 179 to achieve these requirements. This document specifies in detail the 180 representation of different flows, the additional data required for 181 flow interpretation, packet format, transport mechanisms used, 182 security concerns, etc. 184 1.1. Changes since RFC 5101 186 This document obsoletes the Proposed Standard revision of the IPFIX 187 Protocol Specification [RFC5101]. The protocol specified by this 188 document is interoperable with the protocol as specified in 189 [RFC5101]. The following changes have been made to this document with 190 respect to the previous document: 192 - All outstanding technical and editorial errata on [RFC5101] have 193 been addressed. 195 - As [IPFIX-IANA] is now the normative reference for all 196 Information Element definitions (see [RFC5102bis]), all 197 definitions of Information Elements in Section 4 have been 198 replaced with references to the registry. 200 - The encoding of the dateTimeSeconds, dateTimeMilliseconds, 201 dateTimeMicroseconds, and dateTimeNanoseconds data types, and 202 the related encoding of the IPFIX Message Header Export Time 203 field, have been clarified, especially with respect to the epoch 204 upon which the timestamp data types are based. 206 - A new Section 5.2 has been added to address wraparound of these 207 timestamp data types after they overflow in 2032 - 2038 CE 208 (common era). 210 - Clarifications on encoding, especially in Section 6: all IPFIX 211 values are encoded in network byte order. 213 - Template management in section 8 has been simplified and 214 clarified: the specification has been relaxed with respect to 215 [RFC5101], especially concerning potential failures in Template 216 ID reuse. Additional corner cases in template management have 217 been addressed. The new template management language is 218 interoperable with that in [RFC5101] to the extent that the 219 behavior was defined in the prior specification. 221 - Section 11.3 (Mutual Authentication) has been improved to refer 222 to current practices in TLS mutual authentication; references to 223 Punycode were removed as these are covered in [RFC6125]. 225 - Editorial improvements, including structural changes to sections 226 8, 9, and 10 to improve readability. Behavior common to all 227 transport protocols has been separated out, with exceptions per 228 transport specifically noted. All template management language 229 (on both Exporting and Collecting Processes) has been unified in 230 section 8. 232 - A new section 12 has been added on management considerations 234 1.2. IPFIX Documents Overview 236 The IPFIX protocol provides network administrators with access to IP 237 flow information. The architecture for the export of measured IP 238 flow information out of an IPFIX Exporting Process to a Collecting 239 Process is defined in [RFC5470], per the requirements defined in 240 [RFC3917]. This document specifies how IPFIX Data Records and 241 Templates are carried via a number of transport protocols from IPFIX 242 Exporting Processes to IPFIX Collecting Processes. 244 Four IPFIX optimizations/extensions are currently specified: a 245 bandwidth saving method for the IPFIX protocol in [RFC5473], an 246 efficient method for exporting bidirectional flows in [RFC5103], a 247 method for the definition and export of complex data structures in 248 [RFC6313], and the specification of the Protocol for IPFIX Mediations 249 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 251 A "file-based transport" for IPFIX, which defines how IPFIX Messages 252 can be stored in files for document-based workflows and for archival 253 purposes, is given in [RFC5655]. 255 IPFIX has a formal description of IPFIX Information Elements, their 256 name, type and additional semantic information, as specified in 257 [RFC5102bis]. The registry is maintained by IANA [IPFIX-IANA]. The 258 inline export of the Information Element type information is 259 specified in [RFC5610]. 261 The framework for packet selection and reporting [RFC5474] enables 262 network elements to select subsets of packets by statistical and 263 other methods, and to export a stream of reports on the selected 264 packets to a Collector. The set of packet selection techniques 265 (Sampling, Filtering, and hashing) standardized by PSAMP is described 266 in [ RFC5475]. The PSAMP protocol [RFC5476], which uses IPFIX as 267 export protocol, specifies the export of packet information from a 268 PSAMP Exporting Process to a PSAMP Collector. Instead of exporting 269 PSAMP Packet Reports, the stream of selected packets may also serve 270 as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP 271 has a formal description of its Information Elements, their name, 272 type, and additional semantic information. The PSAMP information 273 model is defined in [RFC5477]. 275 [RFC6615] specifies a MIB module for monitoring, and [RFC6728] 276 specifies a data model for configuring and monitoring IPFIX and PSAMP 277 compliant devices using the NETCONF protocol. [RFC6727] specifies the 278 PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module 279 defined in [RFC6615]. 281 In terms of development, [RFC5153] provides guidelines for the 282 implementation and use of the IPFIX protocol, while [RFC5471] 283 provides guidelines for testing. Finally, [RFC5472] describes what 284 type of applications can use the IPFIX protocol and how they can use 285 the information provided. It furthermore shows how the IPFIX 286 framework relates to other architectures and frameworks. 288 2. Terminology 290 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 291 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 292 "OPTIONAL" in this document are to be interpreted as described in RFC 293 2119 [RFC2119]. 295 The definitions of the basic terms like Traffic Flow, Exporting 296 Process, Collecting Process, Observation Points, etc. are 297 semantically identical to those found in the IPFIX requirements 298 document [RFC3917]. Some of the terms have been expanded for more 299 clarity when defining the protocol. Additional terms required for 300 the protocol have also been defined. Definitions in this document 301 and in [RFC5470] are equivalent; definitions that are only relevant 302 to the IPFIX protocol only appear here. 304 The terminology summary table in Section 2.1 gives a quick overview 305 of the relationships among some of the different terms defined. 307 Observation Point 309 An Observation Point is a location in the network where packets 310 can be observed. Examples include: a line to which a probe is 311 attached, a shared medium, such as an Ethernet-based LAN, a single 312 port of a router, or a set of interfaces (physical or logical) of 313 a router. 315 Note that every Observation Point is associated with an 316 Observation Domain (defined below), and that one Observation Point 317 may be a superset of several other Observation Points. For 318 example, one Observation Point can be an entire line card. That 319 would be the superset of the individual Observation Points at the 320 line card's interfaces. 322 Observation Domain 324 An Observation Domain is the largest set of Observation Points for 325 which Flow information can be aggregated by a Metering Process. 326 For example, a router line card may be an Observation Domain if it 327 is composed of several interfaces, each of which is an Observation 328 Point. In the IPFIX Message it generates, the Observation Domain 329 includes its Observation Domain ID, which is unique per Exporting 330 Process. That way, the Collecting Process can identify the 331 specific Observation Domain from the Exporter that sends the IPFIX 332 Messages. Every Observation Point is associated with an 333 Observation Domain. It is RECOMMENDED that Observation Domain IDs 334 also be unique per IPFIX Device. 336 Packet Treatment 338 Action(s) performed on a packet by a forwarding device or other 339 middlebox, including forwarding, dropping, delaying for traffic 340 shaping purposes, etc. 342 Traffic Flow or Flow 344 There are several definitions of the term 'flow' being used by the 345 Internet community. Within the context of IPFIX we use the 346 following definition: 348 A Flow is defined as a set of packets or frames passing an 349 Observation Point in the network during a certain time interval. 350 All packets belonging to a particular Flow have a set of common 351 properties. Each property is defined as the result of applying a 352 function to the values of: 354 1. one or more packet header fields (e.g., destination IP 355 address), transport header fields (e.g., destination port 356 number), or application header fields (e.g., RTP header 357 fields [RFC3550]). 359 2. one or more characteristics of the packet itself (e.g., 360 number of MPLS labels, etc...). 362 3. one or more of fields derived from Packet Treatment (e.g., 363 next hop IP address, the output interface, etc...). 365 A packet is defined as belonging to a Flow if it completely 366 satisfies all the defined properties of the Flow. 368 Note that the set of packets represented by a Flow may be empty; 369 that is, a Flow may represent zero or more packets. As sampling is 370 a Packet Treatment, this definition includes packets selected by a 371 sampling mechanism. 373 Flow Key 375 Each of the fields that: 377 1. belong to the packet header (e.g., destination IP address), or 379 2. are a property of the packet itself (e.g., packet length), or 381 3. are derived from Packet Treatment (e.g., Autonomous System 382 (AS) number), 384 and that are used to define a Flow (i.e., are the properties 385 common to all packets in the Flow) are termed Flow Keys. As an 386 example, the traditional '5-tuple' Flow Key of source and 387 destination IP address, source and destination transport port, and 388 transport protocol, groups together all packets belonging to a 389 single direction of communication on a single socket. 391 Flow Record 393 A Flow Record contains information about a specific Flow that was 394 observed at an Observation Point. A Flow Record contains measured 395 properties of the Flow (e.g., the total number of bytes for all 396 the Flow's packets) and usually contains characteristic properties 397 of the Flow (e.g., source IP address). 399 Metering Process 401 The Metering Process generates Flow Records. Inputs to the 402 process are packet headers, characteristics, and Packet Treatment 403 observed at one or more Observation Points. 405 The Metering Process consists of a set of functions that includes 406 packet header capturing, timestamping, sampling, classifying, and 407 maintaining Flow Records. 409 The maintenance of Flow Records may include creating new records, 410 updating existing ones, computing Flow statistics, deriving 411 further Flow properties, detecting Flow expiration, passing Flow 412 Records to the Exporting Process, and deleting Flow Records. 414 Exporting Process 416 The Exporting Process sends IPFIX Messages to one or more 417 Collecting Processes. The Flow Records in the Messages are 418 generated by one or more Metering Processes. 420 Exporter 422 A device that hosts one or more Exporting Processes is termed an 423 Exporter. 425 IPFIX Device 427 An IPFIX Device hosts at least one Exporting Process. It may host 428 further Exporting Processes and arbitrary numbers of Observation 429 Points and Metering Processes. 431 Collecting Process 433 A Collecting Process receives IPFIX Messages from one or more 434 Exporting Processes. The Collecting Process might process or 435 store Flow Records received within these Messages, but such 436 actions are out of scope for this document. 438 Collector 440 A device that hosts one or more Collecting Processes is termed a 441 Collector. 443 Template 445 A Template is an ordered sequence of pairs used to 446 completely specify the structure and semantics of a particular set 447 of information that needs to be communicated from an IPFIX Device 448 to a Collector. Each Template is uniquely identifiable by means 449 of a Template ID. 451 IPFIX Message 453 An IPFIX Message is a message originating at the Exporting Process 454 that carries the IPFIX records of this Exporting Process and whose 455 destination is a Collecting Process. An IPFIX Message is 456 encapsulated at the transport layer. 458 Message Header 460 The Message Header is the first part of an IPFIX Message, which 461 provides basic information about the message, such as the IPFIX 462 version, length of the message, message sequence number, etc. 464 Template Record 466 A Template Record defines the structure and interpretation of 467 fields in a Data Record. 469 Data Record 471 A Data Record is a record that contains values of the parameters 472 corresponding to a Template Record. 474 Options Template Record 476 An Options Template Record is a Template Record that defines the 477 structure and interpretation of fields in a Data Record, including 478 defining how to scope the applicability of the Data Record. 480 Set 482 A Set is a collection of records that have a similar structure, 483 prefixed by a header. In an IPFIX Message, zero or more Sets 484 follow the Message Header. There are three different types of 485 Sets: Template Set, Options Template Set, and Data Set. 487 Template Set 489 A Template Set is a collection of one or more Template Records 490 that have been grouped together in an IPFIX Message. 492 Options Template Set 494 An Options Template Set is a collection of one or more Options 495 Template Records that have been grouped together in an IPFIX 496 Message. 498 Data Set 500 A Data Set is one or more Data Records, of the same type, that are 501 grouped together in an IPFIX Message. Each Data Record is 502 previously defined by a Template Record or an Options Template 503 Record. 505 Information Element 507 An Information Element is a protocol and encoding-independent 508 description of an attribute that may appear in an IPFIX Record. 509 The base set of Information Elements making up the IPFIX 510 information model [RFC5102bis] are described in the IANA IPFIX 511 Information Element Registry [IPFIX-IANA]. The type associated 512 with an Information Element indicates constraints on what it may 513 contain and also determines the valid encoding mechanisms for use 514 in IPFIX. 516 Transport Session 518 In Stream Control Transmission Protocol (SCTP), the transport 519 session is known as the SCTP association, which is uniquely 520 identified by the SCTP endpoints [RFC4960]; in TCP, the transport 521 session is known as the TCP connection, which is uniquely 522 identified by the combination of IP addresses and TCP ports used. 523 In UDP, the transport session is known as the UDP session, which 524 is uniquely identified by the combination of IP addresses and UDP 525 ports used. 527 2.1. Terminology Summary Table 529 +------------------+---------------------------------------------+ 530 | | contents | 531 | +--------------------+------------------------+ 532 | Set | Template | Record | 533 +------------------+--------------------+------------------------+ 534 | Data Set | / | Data Record(s) | 535 +------------------+--------------------+------------------------+ 536 | Template Set | Template Record(s) | / | 537 +------------------+--------------------+------------------------+ 538 | Options Template | Options Template | / | 539 | Set | Record(s) | | 540 +------------------+--------------------+------------------------+ 542 Figure A: Terminology Summary Table 544 A Data Set is composed of Data Record(s). No Template Record is 545 included. A Template Record or an Options Template Record defines 546 the Data Record. 548 A Template Set contains only Template Record(s). 550 An Options Template Set contains only Options Template Record(s). 552 3. IPFIX Message Format 554 An IPFIX Message consists of a Message Header, followed by zero or 555 more Sets. The Sets can be any of the possible three types: Data 556 Set, Template Set, or Options Template Set. 558 The format of the IPFIX Message is shown in Figure B. 560 +----------------------------------------------------+ 561 | Message Header | 562 +----------------------------------------------------+ 563 | Set | 564 +----------------------------------------------------+ 565 | Set | 566 +----------------------------------------------------+ 567 ... 568 +----------------------------------------------------+ 569 | Set | 570 +----------------------------------------------------+ 572 Figure B: IPFIX Message Format 574 Following are some examples of IPFIX Messages: 576 1. An IPFIX Message consisting of interleaved Template, Data, and 577 Options Template Sets, shown in Figure C. Here, Template and 578 Options Template Sets are transmitted "on demand", before the 579 first Data Set they define the structure of. 581 +--------+--------------------------------------------------------+ 582 | | +----------+ +---------+ +-----------+ +---------+ | 583 |Message | | Template | | Data | | Options | | Data | | 584 | Header | | Set | | Set | ... | Template | | Set | | 585 | | | | | | | Set | | | | 586 | | +----------+ +---------+ +-----------+ +---------+ | 587 +--------+--------------------------------------------------------+ 589 Figure C: IPFIX Message, Example 1 591 2. An IPFIX Message consisting entirely of Data Sets, sent after the 592 appropriate Template Records have been defined and transmitted to 593 the Collecting Process, shown in Figure D. 595 +--------+----------------------------------------------+ 596 | | +---------+ +---------+ +---------+ | 597 |Message | | Data | | Data | | Data | | 598 | Header | | Set | ... | Set | ... | Set | | 599 | | +---------+ +---------+ +---------+ | 600 +--------+----------------------------------------------+ 602 Figure D: IPFIX Message, Example 2 604 3. An IPFIX Message consisting entirely of Template and Options 605 Template Sets, shown in Figure E. Such a message can be used to 606 define or redefine Templates and Options Templates in bulk. 608 +--------+-------------------------------------------------+ 609 | | +----------+ +----------+ +----------+ | 610 |Message | | Template | | Template | | Options | | 611 | Header | | Set | ... | Set | ... | Template | | 612 | | | | | | | Set | | 613 | | +----------+ +----------+ +----------+ | 614 +--------+-------------------------------------------------+ 616 Figure E: IPFIX Message, Example 3 618 3.1. Message Header Format 620 The format of the IPFIX Message Header is shown in Figure F. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Version Number | Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Export Time | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Sequence Number | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Observation Domain ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure F: IPFIX Message Header Format 636 Each Message Header field is exported in network byte order. The 637 fields are defined as follows: 639 Version 641 Version of IPFIX to which this Message conforms. The value of this 642 field is 0x000a for the current version, incrementing by one the 643 version used in the NetFlow services export version 9 [RFC3954]. 645 Length 647 Total length of the IPFIX Message, measured in octets, including 648 Message Header and Set(s). 650 Export Time 652 Time at which the IPFIX Message Header leaves the Exporter, 653 expressed in seconds since the UNIX epoch of 1 January 1970 at 654 00:00 UTC, encoded as an unsigned 32-bit integer. 656 Sequence Number 658 Incremental sequence counter modulo 2^32 of all IPFIX Data Records 659 sent in the current stream from the current Observation Domain by 660 the Exporting Process. Each SCTP Stream counts sequence numbers 661 separately, while all messages in a TCP connection or UDP 662 transport session are considered to be part of the same stream. 663 This value can be used by the Collecting Process to identify 664 whether any IPFIX Data Records have been missed. Template and 665 Options Template Records do not increase the Sequence Number. 667 Observation Domain ID 669 A 32-bit identifier of the Observation Domain that is locally 670 unique to the Exporting Process. The Exporting Process uses the 671 Observation Domain ID to uniquely identify to the Collecting 672 Process the Observation Domain that metered the Flows. It is 673 RECOMMENDED that this identifier also be unique per IPFIX Device. 674 Collecting Processes SHOULD use the Transport Session and the 675 Observation Domain ID field to separate different export streams 676 originating from the same Exporter. The Observation Domain ID 677 SHOULD be 0 when no specific Observation Domain ID is relevant for 678 the entire IPFIX Message, for example, when exporting the 679 Exporting Process Statistics, or in case of a hierarchy of 680 Collectors when aggregated Data Records are exported. 682 3.2. Field Specifier Format 684 Vendors need the ability to define proprietary Information Elements, 685 because, for example, they are delivering a pre-standards product, or 686 the Information Element is, in some way, commercially sensitive. 687 This section describes the Field Specifier format for both 688 IANA-registered Information Elements [IPFIX-IANA] and enterprise- 689 specific Information Elements. 691 The Information Elements are identified by the Information Element 692 identifier. When the Enterprise bit is set to 0, the corresponding 693 Information Element appears in [IPFIX-IANA], and the Enterprise 694 Number MUST NOT be present. When the Enterprise bit is set to 1, the 695 corresponding Information Element identifier identified an 696 enterprise-specific Information Element; the Enterprise Number MUST 697 be present. An example of this is shown in Section A.2.2. 699 The Field Specifier format is shown in Figure G. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 |E| Information Element ident. | Field Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Enterprise Number | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Figure G: Field Specifier Format 711 Where: 713 E 715 Enterprise bit. This is the first bit of the Field Specifier. If 716 this bit is zero, the Information Element Identifier identifies an 717 Information Element in [IPFIX-IANA], and the four-octet Enterprise 718 Number field MUST NOT be present. If this bit is one, the 719 Information Element identifier identifies an enterprise-specific 720 Information Element, and the Enterprise Number field MUST be 721 present. 723 Information Element identifier 725 A numeric value that represents the Information Element. Refer to 726 [IPFIX-IANA]. 728 Field Length 730 The length of the corresponding encoded Information Element, in 731 octets. Refer to [IPFIX-IANA]. The field length may be smaller 732 than that in [IPFIX-IANA] if the reduced size encoding is used 733 (see Section 6.2). The value 65535 is reserved for variable- 734 length Information Elements (see Section 7). 736 Enterprise Number 738 IANA enterprise number [PEN-IANA] of the authority defining the 739 Information Element identifier in this Template Record. 741 3.3. Set and Set Header Format 743 A Set is a generic term for a collection of records that have a 744 similar structure. There are three different types of Sets: Template 745 Sets, Options Template Sets, and Data Sets. Each of these Sets 746 consists of a Set Header and one or more records. The Set Format and 747 the Set Header Format are defined in the following sections. 749 3.3.1. Set Format 751 A Set has the format shown in Figure H. The record types can be 752 either Template Records, Options Template Records, or Data Records. 753 The record types MUST NOT be mixed within a Set. 755 +--------------------------------------------------+ 756 | Set Header | 757 +--------------------------------------------------+ 758 | record | 759 +--------------------------------------------------+ 760 | record | 761 +--------------------------------------------------+ 762 ... 763 +--------------------------------------------------+ 764 | record | 765 +--------------------------------------------------+ 766 | Padding (opt.) | 767 +--------------------------------------------------+ 769 Figure H: Set Format 771 Set Header 773 The Set Header Format is defined in Section 3.3.2. 775 Record 777 One of the record Formats: Template Record, Options Template 778 Record, or Data Record Format. 780 Padding 782 The Exporting Process MAY insert some padding octets, so that the 783 subsequent Set starts at an aligned boundary. For security 784 reasons, the padding octet(s) MUST be composed of zero (0) valued 785 octets. The padding length MUST be shorter than any allowable 786 record in this Set. If padding of the IPFIX Message is desired in 787 combination with very short records, then the padding Information 788 Element 'paddingOctets' can be used for padding records such that 789 their length is increased to a multiple of 4 or 8 octets. Because 790 Template Sets are always 4-octet aligned by definition, padding is 791 only needed in case of other alignments e.g., on 8-octet 792 boundaries. 794 3.3.2. Set Header Format 796 Every Set contains a common header. This header is defined in Figure 797 I. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Set ID | Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure I: Set Header Format 807 Each Set Header field is exported in network format. The fields are 808 defined as follows: 810 Set ID 812 Identifies the Set. A value of 2 is reserved for Template Sets. 813 A value of 3 is reserved for Options Template Sets. Values from 4 814 to 255 are reserved for future use. Values 256 and above are used 815 for Data Sets. The Set ID values of 0 and 1 are not used, for 816 historical reasons [RFC3954]. 818 Length 820 Total length of the Set, in octets, including the Set Header, all 821 records, and the optional padding. Because an individual Set MAY 822 contain multiple records, the Length value MUST be used to 823 determine the position of the next Set. 825 3.4. Record Format 827 IPFIX defines three record formats, defined in the next sections: the 828 Template Record Format, the Options Template Record Format, and the 829 Data Record Format. 831 3.4.1. Template Record Format 833 One of the essential elements in the IPFIX record format is the 834 Template Record. Templates greatly enhance the flexibility of the 835 record format because they allow the Collecting Process to process 836 IPFIX Messages without necessarily knowing the interpretation of all 837 Data Records. A Template Record contains any combination of 838 IANA-assigned and/or enterprise-specific Information Element 839 identifiers. 841 The format of the Template Record is shown in Figure J. It consists 842 of a Template Record Header and one or more Field Specifiers. The 843 definition of the Field Specifiers is given in Figure G above. 845 +--------------------------------------------------+ 846 | Template Record Header | 847 +--------------------------------------------------+ 848 | Field Specifier | 849 +--------------------------------------------------+ 850 | Field Specifier | 851 +--------------------------------------------------+ 852 ... 853 +--------------------------------------------------+ 854 | Field Specifier | 855 +--------------------------------------------------+ 857 Figure J: Template Record Format 859 The format of the Template Record Header is shown in Figure K. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Template ID (> 255) | Field Count | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Figure K: Template Record Header Format 869 The Template Record Header Field Definitions are as follows: 871 Template ID 873 Each Template Record is given a unique Template ID in the range 874 256 to 65535. This uniqueness is local to the Transport Session 875 and Observation Domain that generated the Template ID. Since 876 Template IDs are used as Set IDs in the Sets they describe (see 877 section 3.4.3), values 0-255 are reserved for special Set types 878 (e.g. Template Sets themselves), and Templates and Options 879 Templates (see section 3.4.2) cannot share Template IDs within a 880 Transport Session and Observation Domain. There are no constraints 881 regarding the order of the Template ID allocation. As Exporting 882 Processes are free to allocate Template IDs as they see fit, 883 Collecting Processes MUST NOT assume incremental Template IDs, or 884 anything about the contents of a Template based on its Template ID 885 alone. 887 Field Count 889 Number of fields in this Template Record. 891 The example in Figure L shows a Template Set with mixed IANA-assigned 892 and enterprise-specific Information Elements. It consists of a Set 893 Header, a Template Header, and several Field Specifiers. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Set ID = 2 | Length | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Template ID = 256 | Field Count = N | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |1| Information Element id. 1.1 | Field Length 1.1 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Enterprise Number 1.1 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 |0| Information Element id. 1.2 | Field Length 1.2 | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | ... | ... | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 |1| Information Element id. 1.N | Field Length 1.N | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Enterprise Number 1.N | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Template ID = 257 | Field Count = M | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |0| Information Element id. 2.1 | Field Length 2.1 | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |1| Information Element id. 2.2 | Field Length 2.2 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Enterprise Number 2.2 | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | ... | ... | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |1| Information Element id. 2.M | Field Length 2.M | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Enterprise Number 2.M | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Padding (opt) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Figure L: Template Set Example 933 Information Element Identifiers 1.2 and 2.1 appear in [IPFIX-IANA] 934 (Enterprise bit = 0) and, therefore, do not need an Enterprise Number 935 to identify them. 937 3.4.2. Options Template Record Format 939 Thanks to the notion of scope, The Options Template Record gives the 940 Exporter the ability to provide additional information to the 941 Collector that would not be possible with Flow Records alone. 943 See Section 4 for specific Options Templates used for reporting 944 metadata about IPFIX Exporting and Metering Processes. 946 3.4.2.1. Scope 948 The scope, which is only available in the Options Template Set, gives 949 the context of the reported Information Elements in the Data 950 Records. 952 The scope is one or more Information Elements, specified in the 953 Options Template Record. Collecting Processes SHOULD support as 954 scope, at minimum, the observationDomainId, exportingProcessId, 955 meteringProcessId, templateId, lineCardId, exporterIPv4Address, 956 exporterIPv6Address, and ingressInterface Information Elements. The 957 IPFIX protocol doesn't prevent the use of any Information Elements 958 for scope. However, some Information Element types don't make sense 959 if specified as scope; for example, the counter Information Elements. 961 The IPFIX Message Header already contains the Observation Domain ID. 962 If not zero, this Observation Domain ID can be considered as an 963 implicit scope for the Data Records in the IPFIX Message. 965 Multiple Scope Fields MAY be present in the Options Template Record, 966 in which case, the composite scope is the combination of the scopes. 967 For example, if the two scopes are meteringProcessId and templateId, 968 the combined scope is this Template for this Metering Process. If a 969 different order of Scope Fields would result in a Record having a 970 different semantic meaning, then the order of Scope Fields MUST be 971 preserved by the Exporting Process. For example, in the context of 972 PSAMP [RFC5476], if the first scope defines the filtering function, 973 while the second scope defines the sampling function, the order of 974 the scope is important. Applying the sampling function first, 975 followed by the filtering function, would lead to potentially 976 different Data Records than applying the filtering function first, 977 followed by the sampling function. 979 3.4.2.2. Options Template Record Format 981 An Options Template Record contains any combination of IANA-assigned 982 and/or enterprise-specific Information Element identifiers. 984 The format of the Options Template Record is shown in Figure M. It 985 consists of an Options Template Record Header and one or more Field 986 Specifiers. The definition of the Field Specifiers is given in 987 Figure G above. 989 +--------------------------------------------------+ 990 | Options Template Record Header | 991 +--------------------------------------------------+ 992 | Field Specifier | 993 +--------------------------------------------------+ 994 | Field Specifier | 995 +--------------------------------------------------+ 996 ... 997 +--------------------------------------------------+ 998 | Field Specifier | 999 +--------------------------------------------------+ 1001 Figure M: Options Template Record Format 1003 The format of the Options Template Record Header is shown in Figure 1004 N. 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Template ID (> 255) | Field Count | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Scope Field Count | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 Figure N: Options Template Record Header Format 1016 The Options Template Record Header Field Definitions are as follows: 1018 Template ID 1020 Each Options Template Record is given a unique Template ID in the 1021 range 256 to 65535. This uniqueness is local to the Transport 1022 Session and Observation Domain that generated the Template ID. 1023 Since Template IDs are used as Set IDs in the sets they describe 1024 (see section 3.4.3), values 0-255 are reserved for special Set 1025 types (e.g. Template Sets themselves), and Templates and Options 1026 Templates cannot share Template IDs within a Transport Session and 1027 Observation Domain. There are no constraints regarding the order 1028 of the Template ID allocation. As Exporting Processes are free to 1029 allocate Template IDs as they see fit, Collecting Processes MUST 1030 NOT assume incremental Template IDs, or anything about the 1031 contents of an Options Template based on its Template ID alone. 1033 Field Count 1035 Number of all fields in this Options Template Record, including 1036 the Scope Fields. 1038 Scope Field Count 1040 Number of scope fields in this Options Template Record. The Scope 1041 Fields are normal Fields except that they are interpreted as scope 1042 at the Collector. A scope field count of N specifies that the 1043 first N Field Specifiers in the Template Record are Scope Fields. 1044 The Scope Field Count MUST NOT be zero. 1046 The example in Figure O shows an Options Template Set with mixed 1047 IANA-assigned and enterprise-specific Information Elements. It 1048 consists of a Set Header, a Options Template Header, and several 1049 Field Specifiers. 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Set ID = 3 | Length | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Template ID = 258 | Field Count = N + M | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Scope 2 Field Length | ... | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | ... |1| Scope N Infor. Element Id. | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Scope N Field Length | Scope N Enterprise Number ... 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Option 1 Field Length | Option 1 Enterprise Number ... 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 ... Option 1 Enterprise Number | ... | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | ... |0| Option M Infor. Element Id. | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Option M Field Length | Padding (optional) | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 Figure O: Options Template Set Example 1081 3.4.3. Data Record Format 1083 The Data Records are sent in Data Sets. The format of the Data 1084 Record is shown in Figure P. It consists only of one or more Field 1085 Values. The Template ID to which the Field Values belong is encoded 1086 in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 1088 +--------------------------------------------------+ 1089 | Field Value | 1090 +--------------------------------------------------+ 1091 | Field Value | 1092 +--------------------------------------------------+ 1093 ... 1094 +--------------------------------------------------+ 1095 | Field Value | 1096 +--------------------------------------------------+ 1098 Figure P: Data Record Format 1100 Note that Field Values do not necessarily have a length of 16 bits. 1101 Field Values are encoded according to their data type specified in 1102 [RFC5102bis]. 1104 Interpretation of the Data Record format can be done only if the 1105 Template Record corresponding to the Template ID is available at the 1106 Collecting Process. 1108 The example in Figure Q shows a Data Set. It consists of a Set Header 1109 and several Field Values. 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Set ID = Template ID | Length | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Record 1 - Field Value 3 | ... | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Record 2 - Field Value 3 | ... | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Record 3 - Field Value 3 | ... | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | ... | Padding (optional) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 Figure Q: Data Set, containing Data Records 1133 4. Specific Reporting Requirements 1135 Some specific Options Templates and Options Template Records are 1136 necessary to provide extra information about the Flow Records and 1137 about the Metering Process. 1139 The Options Template and Options Template Records defined in these 1140 subsections, which impose some constraints on the Metering Process 1141 and Exporting Process implementations, MAY be implemented. If 1142 implemented, the specific Options Templates SHOULD be implemented as 1143 specified in these subsections. 1145 The minimum set of Information Elements is always specified in these 1146 Specific IPFIX Options Templates. Nevertheless, extra Information 1147 Elements may be used in these specific Options Templates. 1149 The Collecting Process MUST check the possible combinations of 1150 Information Elements within the Options Template Records to correctly 1151 interpret the following Options Templates. 1153 4.1. The Metering Process Statistics Options Template 1155 The Metering Process Statistics Options Template specifies the 1156 structure of a Data Record for reporting Metering Process statistics. 1157 It SHOULD contain the following Information Elements, defined in 1158 [IPFIX-IANA] 1159 (scope) observationDomainId 1160 This Information Element MUST be defined as a 1161 Scope Field, and MUST be present unless the 1162 Observation Domain ID of the enclosing 1163 Message is non-zero. 1165 (scope) meteringProcessId 1166 If present, this Information Element MUST be 1167 defined as a Scope Field. 1169 exportedMessageTotalCount 1171 exportedFlowRecordTotalCount 1173 exportedOctetTotalCount 1175 The Exporting Process SHOULD export the Data Record specified by the 1176 Metering Process Statistics Options Template on a regular basis or 1177 based on some export policy. This periodicity or export policy 1178 SHOULD be configurable. 1180 Note that if several Metering Processes are available on the Exporter 1181 Observation Domain, the Information Element meteringProcessId MUST be 1182 specified as an additional Scope Field. 1184 4.2. The Metering Process Reliability Statistics Options Template 1186 The Metering Process Reliability Options Template specifies the 1187 structure of a Data Record for reporting lack of reliability in the 1188 Metering Process. It SHOULD contain the following Information 1189 Elements defined in [IPFIX-IANA]: 1191 (scope) observationDomainId 1192 This Information Element MUST be defined as a 1193 Scope Field, and MUST be present unless the 1194 Observation Domain ID of the enclosing 1195 Message is non-zero. 1197 (scope) meteringProcessId 1198 If present, this Information Element MUST be 1199 defined as a Scope Field. 1201 ignoredPacketTotalCount 1203 ignoredOctetTotalCount 1204 time first packet ignored 1205 The timestamp of the first packet that was 1206 ignored by the Metering Process. For this 1207 timestamp, any of the following timestamp 1208 Information Elements can be used: 1209 observationTimeSeconds, 1210 observationTimeMilliseconds, 1211 observationTimeMicroseconds, or 1212 observationTimeNanoseconds. 1214 time last packet ignored 1215 The timestamp of the last packet that was 1216 ignored by the Metering Process. For this 1217 timestamp, any of the following timestamp 1218 Information Elements can be used: 1219 observationTimeSeconds, 1220 observationTimeMilliseconds, 1221 observationTimeMicroseconds, or 1222 observationTimeNanoseconds. 1224 The Exporting Process SHOULD export the Data Record specified by the 1225 Metering Process Reliability Statistics Options Template on a regular 1226 basis or based on some export policy. This periodicity or export 1227 policy SHOULD be configurable. 1229 Note that if several Metering Processes are available on the Exporter 1230 Observation Domain, the Information Element meteringProcessId MUST be 1231 specified as an additional Scope Field. 1233 Since the Metering Process Reliability Option Template contains two 1234 identical timestamp Information Elements, and since the order of the 1235 Information Elements in the Template Records is not guaranteed, the 1236 Collecting Process interprets the time interval of ignored packets as 1237 the range between the two values; see Section 5.2 for wraparound 1238 considerations. 1240 4.3. The Exporting Process Reliability Statistics Options Template 1242 The Exporting Process Reliability Options Template specifies the 1243 structure of a Data Record for reporting lack of reliability in the 1244 Exporting Process. It SHOULD contain the following Information 1245 Elements defined in [IPFIX-IANA]: 1247 (scope) Exporting Process ID 1248 The identifier of the Exporting Process for 1249 which reliability is reported. Any of the 1250 exporterIPv4Address, exporterIPv6Address, or 1251 exportingProcessId Information Elements can be 1252 used for this field. This Information Element 1253 MUST be defined as a Scope Field. 1255 notSentFlowTotalCount 1257 notSentPacketTotalCount 1259 notSentOctetTotalCount 1261 time first flow dropped 1262 The time at which the first Flow Record was 1263 dropped by the Exporting Process. For this 1264 timestamp, any of the following timestamp can be 1265 used: observationTimeSeconds, 1266 observationTimeMilliseconds, 1267 observationTimeMicroseconds, or 1268 observationTimeNanoseconds. 1270 time last flow dropped 1271 The time at which the last Flow Record was 1272 dropped by the Exporting Process. For this 1273 timestamp, any of the following timestamp can be 1274 used: observationTimeSeconds, 1275 observationTimeMilliseconds, 1276 observationTimeMicroseconds, or 1277 observationTimeNanoseconds. 1279 The Exporting Process SHOULD export the Data Record specified by the 1280 Exporting Process Reliability Statistics Options Template on a 1281 regular basis or based on some export policy. This periodicity or 1282 export policy SHOULD be configurable. 1284 Since the Exporting Process Reliability Option Template contains two 1285 identical timestamp Information Elements, and since the order of the 1286 Information Elements in the Template Records is not guaranteed, the 1287 Collecting Process interprets the time interval of ignored packets as 1288 the range between the two values; see Section 5.2 for wraparound 1289 considerations. 1291 4.4. The Flow Keys Options Template 1293 The Flow Keys Options Template specifies the structure of a Data 1294 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1295 Data Record extends a particular Template Record that is referenced 1296 by its templateId identifier. The Template Record is extended by 1297 specifying which of the Information Elements contained in the 1298 corresponding Data Records describe Flow properties that serve as 1299 Flow Keys of the reported Flow. 1301 The Flow Keys Options Template SHOULD contain the following 1302 Information Elements that are defined in [IPFIX-IANA]: 1304 (scope) templateId This Information Element MUST be defined as a 1305 Scope Field. 1307 flowKeyIndicator 1309 5. Timing Considerations 1311 5.1 IPFIX Message Header Export Time and Flow Record Time 1313 The IPFIX Message Header Export Time field is the time at which the 1314 IPFIX Message Header leaves the Exporter, using the same encoding as 1315 the dateTimeSeconds abstract data type [RFC5102bis], i.e., expressed 1316 in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded 1317 as an unsigned 32-bit integer. 1319 Certain time-related Information Elements may be expressed as an 1320 offset from this Export Time. For example, Data Records requiring a 1321 microsecond precision can export the flow start and end times with 1322 the flowStartMicroseconds and flowEndMicroseconds Information 1323 Elements, which encode the absolute time in microseconds in terms of 1324 the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An 1325 alternate solution is to export the flowStartDeltaMicroseconds and 1326 flowEndDeltaMicroseconds Information Elements in the Data Record, 1327 which respectively report the flow start and end time as negative 1328 offsets from the Export Time, as an unsigned 32-bit integer. This 1329 latter solution lowers the export bandwidth requirement, saving four 1330 bytes per timestamp, while increasing the load on the Exporter, as 1331 the Exporting Process must calculate the flowStartDeltaMicroseconds 1332 and flowEndDeltaMicroseconds of every single Data Record before 1333 exporting the IPFIX Message. 1335 It must be noted that timestamps based on the Export Time impose some 1336 time constraints on the Data Records contained within the IPFIX 1337 Message. In the example of flowStartDeltaMicroseconds and 1338 flowEndDeltaMicroseconds Information Elements, the Data Record can 1339 only contain records with timestamps within 71 minutes of the Export 1340 Time. Otherwise, the 32-bit counter would not be sufficient to 1341 contain the flow start time offset. 1343 5.2 Supporting Timestamp Wraparound 1345 The dateTimeSeconds abstract data type [RFC5102bis] and the Export 1346 Time Message Header field (Section 3.1) are encoded as 32-bit 1347 unsigned integers, expressed as seconds since the UNIX epoch, 1 1348 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will 1349 wrap around on 7 February 2106 at 06:28:16 UTC. 1351 In order to support continued use of the IPFIX Protocol beyond this 1352 date, Exporting Processes SHOULD export dateTimeSeconds values and 1353 the Export Time Message Header field as the number of seconds since 1354 the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting 1355 Processes SHOULD use the current date, or other contextual 1356 information, to properly interpret dateTimeSeconds values and the 1357 Export Time Message Header field. 1359 There are similar considerations for the NTP-based 1360 dateTimeMicroseconds and dateTimeNanoseconds abstract data types 1361 [RFC5102bis]. Exporting Processes SHOULD export dateTimeMicroseconds 1362 and dateTimeNanoseconds values as if the NTP Era [RFC5905] is 1363 implicit; Collecting Processes SHOULD use the current date, or other 1364 contextual information, to determine the NTP Era in order to properly 1365 interpret dateTimeMicroseconds and dateTimeNanoseconds values in 1366 received Data Records. 1368 The dateTimeMilliseconds abstract data type will wrap around in 1369 approximately 500 billion years; the specification of the behavior of 1370 this abstract data type after that time is left as a subject of a 1371 future revision of this specification. 1373 The long-term storage of files [RFC5655] for archival purposes is 1374 affected by timestamp wraparound, as the use of the current date to 1375 interpret timestamp values in files stored on the order of multiple 1376 decades in the past may lead to incorrect values; therefore, it is 1377 RECOMMENDED that such files be stored with contextual information to 1378 assist in the interpretation of these timestamps. 1380 6. Linkage with the Information Model 1382 As with values in the IPFIX Message Header and Set Header, values of 1383 all Information Elements [RFC5102bis], except for those of the string 1384 and octetArray data types, are encoded in canonical format in network 1385 byte order (also known as big-endian byte ordering). 1387 6.1. Encoding of IPFIX Data Types 1389 The following sections define the encoding of the data types 1390 specified in [RFC5102bis]. 1392 6.1.1. Integral Data Types 1394 Integral data types -- octet, signed8, unsigned16, signed16, 1395 unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded 1396 using the default canonical format in network byte order. Signed 1397 Integral data types are represented in two's complement notation. 1399 6.1.2. Address Types 1401 Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be 1402 encoded the same way as the integral data types, as six, four, and 1403 sixteen octets in network byte order, respectively. 1405 6.1.3. float32 1407 The float32 data type MUST be encoded as an IEEE single-precision 1408 32-bit floating point-type, as specified in [IEEE.754.1985], in 1409 network byte order as in Setion 3.6 of [RFC1014]. Note that on 1410 little-endian machines, byte swapping of the native representation is 1411 necessary before export. Note that the method for doing this may be 1412 implementation platform dependent. 1414 6.1.4. float64 1416 The float64 data type MUST be encoded as an IEEE double-precision 1417 64-bit floating point-type, as specified in [IEEE.754.1985], in 1418 network byte order as in Section 3.7 of [RFC1014]. Note that on 1419 little-endian machines, byte swapping of the native representation is 1420 necessary before export. Note that the method for doing this may be 1421 implementation platform dependent. 1423 6.1.5. boolean 1425 The boolean data type is specified according to the TruthValue in 1426 [RFC2579]. It is encoded as a single-octet integer, as in Section 1427 6.1.1., with the value 1 for true and a value 2 for false. Every 1428 other value is undefined. 1430 6.1.6. string and octetArray 1432 The data type string represents a finite length string of valid 1433 characters of the Unicode character encoding set. The string data 1434 type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as 1435 an array of zero or more octets using an Information Element of fixed 1436 or variable length. IPFIX Exporting Processes MUST NOT send IPFIX 1437 Messages containing ill-formed UTF-8 string values for Information 1438 Elements of the string data type; Collecting Processes SHOULD detect 1439 and ignore such values. See [UTF8-EXPLOIT] for background on this 1440 issue. 1442 The data type octetArray has no encoding rules; it represents a raw 1443 array of zero or more octets, with the interpretation of the octets 1444 defined in the Information Element definition. 1446 6.1.7. dateTimeSeconds 1448 The data type dateTimeSeconds is an unsigned 32-bit integer in 1449 network byte order containing the number of seconds since the UNIX 1450 epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 1451 dateTimeSeconds is encoded identically to the IPFIX Message Header 1452 Export Time field. It can represent dates between 1 January 1970 and 1453 7 February 2106 without wraparound; see section 5.2 for wraparound 1454 considerations. 1456 6.1.8. dateTimeMilliseconds 1458 The data type dateTimeMilliseconds is an unsigned 64-bit integer in 1459 network byte order, containing the number of milliseconds since the 1460 UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It 1461 can represent dates beginning on 1 January 1970 for approximately the 1462 next 500 billion years without wraparound. 1464 6.1.9 dateTimeMicroseconds 1466 The data type dateTimeMicroseconds is a 64-bit field encoded 1467 according to the NTP Timestamp format as defined in section 6 of 1468 [RFC5905]. This field is made up of two unsigned 32-bit integers in 1469 network byte order, Seconds and Fraction. The Seconds field is the 1470 number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. 1471 The Fraction field is the fractional number of seconds in units of 1472 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1473 dates beginning between 1 January 1900 and 8 February 2036 in the 1474 current NTP Era; see section 5.2 for wraparound considerations. 1476 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1477 identical encoding. The dateTimeMicroseconds data type is intended 1478 only to represent timestamps of microsecond precision. Therefore, the 1479 bottom 11 bits of the fraction field SHOULD be zero and MUST be 1480 ignored for all Information Elements of this data type (as 2^11 x 233 1481 picoseconds = .477 microseconds). 1483 6.1.10 dateTimeNanoseconds 1485 The data type dateTimeNanoseconds is a 64-bit field encoded according 1486 to the NTP Timestamp format as defined in section 6 of [RFC5905]. 1487 This field is made up of two unsigned 32-bit integers in network byte 1488 order, Seconds and Fraction. The Seconds field is the number of 1489 seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The 1490 Fraction field is the fractional number of seconds in units of 1491 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1492 dates beginning between 1 January 1900 and 8 February 2036 in the 1493 current NTP Era; see section 5.2 for wraparound considerations. 1495 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1496 identical encoding. There is no restriction on the interpretation of 1497 the Fraction field for the dateTimeNanoseconds data type. 1499 6.2. Reduced Size Encoding 1501 Information Elements encoded as signed, unsigned, or float data types 1502 MAY be encoded using fewer octets than those implied by their type in 1503 the information model definition, based on the assumption that the 1504 smaller size is sufficient to carry any value the Exporter may need 1505 to deliver. This reduces the network bandwidth requirement between 1506 the Exporter and the Collector. Note that the Information Element 1507 definitions [IPFIX-IANA] always define the maximum encoding size. 1509 For instance, the information model defines octetDeltaCount as an 1510 unsigned64 type, which would require 64 bits. However, if the 1511 Exporter will never locally encounter the need to send a value larger 1512 than 4294967295, it may chose to send the value instead as an 1513 unsigned32. 1515 This behavior is indicated by the Exporter by specifying a size in 1516 the Template with a smaller length than that associated with the 1517 assigned type of the Information Element. In the example above, the 1518 Exporter would place a length of 4 versus 8 in the Template. 1520 Reduced size encoding MAY be be applied to the following integer 1521 types: unsigned64, signed64, unsigned32, signed32, unsigned16, and 1522 signed16. The signed versus unsigned property of the reported value 1523 MUST be preserved. The reduction in size can be to any number of 1524 octets smaller than the original type if the data value still fits, 1525 i.e., so that only leading zeroes are dropped. For example, an 1526 unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). 1528 Reduced size encoding MAY be used to reduce float64 to float32. The 1529 float32 not only has a reduced number range, but due to the smaller 1530 mantissa, is also less precise. In this case, the float64 would be 1531 reduced in size to 4 octets. 1533 Reduced size encoding MUST NOT be applied to any other data type 1534 defined in [RFC5102bis] that implies a fixed length, as these types 1535 either have internal structure (such as ipv4Address or 1536 dateTimeMicroseconds) or restricted ranges that are not suitable for 1537 reduced length encoding (such as dateTimeMilliseconds). 1539 Information Elements of type octetArray and string may be exported 1540 using any length, subject to restrictions on length specific to each 1541 Information Element, as noted in that Information Element's 1542 description. 1544 7. Variable-Length Information Element 1546 The IPFIX Template mechanism is optimized for fixed-length 1547 Information Elements [RFC5102bis]. Where an Information Element has 1548 a variable length, the following mechanism MUST be used to carry the 1549 length information for both the IANA and enterprise-specific 1550 Information Elements. 1552 In the Template Set, the Information Element Field Length is recorded 1553 as 65535. This reserved length value notifies the Collecting Process 1554 that length of the Information Element will be carried in the 1555 Information Element content itself. 1557 In most cases, the length of the Information Element will be less 1558 than 255 octets. The following length-encoding mechanism optimizes 1559 the overhead of carrying the Information Element length in this 1560 majority case. The length is carried in the octet before the 1561 Information Element, as shown in Figure R. 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Length (< 255)| Information Element | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | ... continuing as needed | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 Figure R: Variable-Length Information Element (length < 255 octets) 1573 The length may also be encoded into 3 octets before the Information 1574 element allowing the length of the Information Element to be greater 1575 than or equal to 255 octets. In this case, first octet of the Length 1576 field MUST be 255, and the length is carried in the second and third 1577 octets, as shown in Figure S. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | 255 | Length (0 to 65535) | IE | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | ... continuing as needed | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 Figure S: Variable-Length Information Element (length 0 to 65535 1588 octets) 1590 The octets carrying the length (either the first or the first three 1591 octets) MUST NOT be included in the length of the Information 1592 Element. 1594 8. Template Management 1596 This section describes the management of Templates and Options 1597 Templates at the Exporting and Collecting Processes. The goal of 1598 Template management is to ensure, to the extent possible, that the 1599 Exporting Process and Collecting Process have a consistent view of 1600 the Templates and Options Templates used to encode and decode the 1601 Records sent from the Exporting Process to the Collecting Process. 1602 Achieving this goal is complicated somewhat by two factors: 1. the 1603 need to support the reuse of Template IDs within a Transport Session 1604 and 2. the need to support unreliable transmission for Templates when 1605 UDP is used as the transport protocol for IPFIX Messages. 1607 The Template Management mechanisms defined in this section apply to 1608 IPFIX Messages export on SCTP, TCP, or UDP. Additional considerations 1609 specific to SCTP and UDP transport are given in sections 8.3 and 8.4, 1610 respectively. 1612 The Exporting Process assigns and maintains Template IDs per 1613 Transport Session and Observation Domain. A newly created Template 1614 Record is assigned an unused Template ID by the Exporting Process. 1615 The Collecting Process MUST store all received Template Record 1616 information for the duration of each Transport Session until reuse or 1617 withdrawal as in section 8.1, or expiry over UDP as in section 8.4, 1618 so that it can interpret the corresponding Data Records. 1620 The Collecting Process MUST NOT assume that the Template IDs from a 1621 given Exporting Process refer to the same Templates as they did in 1622 previous Transport Sessions from the same Exporting Process; a 1623 Collecting Process MUST NOT use Templates from one Transport Session 1624 to decode Data Sets in a subsequent Transport Session. 1626 If a specific Information Element is required by a Template, but is 1627 not present in observed packets, the Exporting Process MAY choose to 1628 export Flow Records without this Information Element in a Data Record 1629 described by a new Template. 1631 If an Information Element is required more than once in a Template, 1632 the different occurrences of this Information Element SHOULD follow 1633 the logical order of their treatments by the Metering Process. For 1634 example, if a selected packet goes through two hash functions, and if 1635 the two hash values are sent within a single Template, the first 1636 occurrence of the hash value should belong to the first hash function 1637 in the Metering Process. For example, when exporting the two source 1638 IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address 1639 Information Element occurrence should be the IPv4 address of the 1640 outer header, while the second occurrence should be the address of 1641 the inner header. Collecting Processes MUST properly handle Templates 1642 with multiple identical Information Elements. 1644 The Exporting Process SHOULD transmit the Template Set and Options 1645 Template Set in advance of any Data Sets that use that (Options) 1646 Template ID, to help ensure that the Collector has the Template 1647 Record before receiving the first Data Record. Data Records that 1648 correspond to a Template Record MAY appear in the same and/or 1649 subsequent IPFIX Message(s). However, a Collecting Process MUST NOT 1650 assume that the Data Set and the associated Template Set (or Options 1651 Template Set) are exported in the same IPFIX Message. 1653 Though a Collecting Process normally receives Template Records from 1654 the Exporting Process before receiving Data Records, this is not 1655 always the case, e.g. in case of reordering or Collecting Process 1656 restart over UDP. In these cases, the Collecting Process MAY buffer 1657 Data Records for which it has no Templates to wait for Template 1658 Records describing them; however, note that in the presence of 1659 Template withdrawal and redefinition (Section 8.1) this may lead to 1660 incorrect interpretation of Data Records. 1662 Different Observation Domains within a Transport Session MAY use the 1663 same Template ID value to refer to different Templates; Collecting 1664 Processes MUST properly handle this case. 1666 Options Templates and Templates which are related or interdependent 1667 (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent 1668 together in the same IPFIX Message. 1670 8.1. Template Withdrawal and Redefinition 1672 Templates that will not be used further by an Exporting Process MAY 1673 be withdrawn by sending a Template Withdrawal. After receiving a 1674 Template Withdrawal, a Collecting Process MUST stop using the 1675 Template to interpret subsequently-exported Data Sets. Note that this 1676 mechanism does not apply when UDP is used to transport IPFIX 1677 Messages; for this case, see Section 8.4. 1679 A Template Withdrawal consists of a Template Record for the Template 1680 ID to be withdrawn, with a Field Count of 0. The format of a Template 1681 Withdrawal is shown in Figure T. 1683 0 1 2 3 1684 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 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Set ID = (2 or 3) | Length = 16 | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Template ID N | Field Count = 0 | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Template ID ... | Field Count = 0 | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Template ID M | Field Count = 0 | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 Figure T: Template Withdrawal Format 1697 The Set ID field MUST contain the value 2 for Template Set Withdrawal 1698 and the value 3 for Options Template Set Withdrawal. Multiple 1699 Template IDs MAY be withdrawn with a single Template Withdrawal, in 1700 that case, padding MAY be used. 1702 Template Withdrawals MAY appear interleaved with Template Sets, 1703 Options Template Sets, and Data Sets within an IPFIX Message. In this 1704 case, the Templates and Template Withdrawals shall be taken to take 1705 effect in the order in which they appear in the IPFIX Message. An 1706 Exporting Process SHOULD NOT send a Template Withdrawal until 1707 sufficient time has elapsed to allow receipt and processing of any 1708 Data Records described by the withdrawn Templates; see Section 8.2 on 1709 sequencing of Template management actions. 1711 The end of a Transport Session implicitly withdraws all the Templates 1712 used within the Transport Session, and Templates must be resent 1713 during subsequent Transport Sessions between an Exporting Process and 1714 Collecting Process. This applies to SCTP and TCP only; see sections 1715 8.4 and 10.3.4 for a discussion of Transport Session and Template 1716 lifetime over UDP. 1718 All Templates for a given Observation Domain MAY also be withdrawn 1719 using an All Templates Withdrawal, shown in Figure U. All Options 1720 Templates for a given Observation Domain MAY likewise be withdrawn 1721 using an All Options Templates Withdrawal, shown in Figure 3. 1723 0 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Set ID = 2 | Length = 8 | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Template ID = 2 | Field Count = 0 | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 Figure U: All Templates Withdrawal Set Format 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Set ID = 3 | Length = 8 | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Template ID = 3 | Field Count = 0 | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 Figure V: All Options Templates Withdrawal Set Format 1743 Template IDs MAY be reused for new Templates by sending a new 1744 Template Record or Options Template Record for a given Template ID 1745 after withdrawing the Template. 1747 If a Collecting Process receives a Template Withdrawal for a Template 1748 or Options Template it does not presently have stored, this indicates 1749 a malfunctioning or improperly-implemented Exporting Process. The 1750 continued receipt and interpretation of Data Records is still 1751 possible, but it MUST ignore the Template Withdrawal and SHOULD log 1752 the error. 1754 If a Collecting Process receives a new Template Record or Options 1755 Template Record for an already-allocated Template ID, and that 1756 Template or Options Template is identical to the already-received 1757 Template or Options Template, it SHOULD log the retransmission; 1758 however, this is not an error condition, as it does not affect the 1759 interpretation of data records. 1761 If a Collecting Process receives a new Template Record or Options 1762 Template Record for an already-allocated Template ID, and that 1763 Template or Options Template is different from the already-received 1764 Template or Options Template, this indicates a malfunctioning or 1765 improperly-implemented Exporting Process. The continued receipt and 1766 unambiguous interpretation of Data Records for this Template ID is no 1767 longer possible, the Collecting Process SHOULD log the error; further 1768 Collecting Process actions are out of scope of this specification. 1770 8.2 Sequencing Template Management Actions 1772 Since there is no guarantee of the ordering of exported IPFIX 1773 Messages across SCTP Streams or over UDP, an Exporting Process MUST 1774 sequence all Template management actions (i.e., Template Records 1775 defining new Templates and Template Withdrawals withdrawing them) 1776 using the Export Time field in the IPFIX Message Header. 1778 An Exporting Process MUST NOT export a Data Set described by a new 1779 Template in an IPFIX Message with an Export Time before the Export 1780 Time of the IPFIX Message containing that Template. If a new Template 1781 and a Data Set described by it appear in the same IPFIX Message, the 1782 Template Set containing the Template MUST appear before the Data Set 1783 in the Message. 1785 An Exporting Process MUST NOT export any Data Sets described by a 1786 withdrawn Template in IPFIX Messages with an Export Time after the 1787 Export Time of the IPFIX Message containing the Template Withdrawal 1788 withdrawing that Template. 1790 Put another way, a Template describes Data Records contained in IPFIX 1791 messages when the export time of such messages is between a specific 1792 start and end time, inclusive. The start time is the Export Time of 1793 the IPFIX Message containing the Template record. The end time is one 1794 of two times. If the template is withdrawn during the session, then 1795 it is the Export Time of the IPFIX message containing the Template 1796 Withdrawal for the template. Otherwise, it is the end of the 1797 Transport Session. 1799 Even if sent in-order, IPFIX Messages containing Template management 1800 actions could arrive at the Collecting Process out-of-order, i.e. if 1801 sent via UDP or via different SCTP streams. Given this, Template 1802 Withdrawals and subsequent reuse of Template IDs can significantly 1803 complicate the problem of determining Template lifetimes at the 1804 Collecting Process. A Collecting Process MAY implement a buffer and 1805 use Export Time information to disambiguate the order of Template 1806 management actions. This buffer, if implemented, SHOULD be 1807 configurable to impart a delay on the order of the maximum reordering 1808 delay experienced at the Collecting Process. Note, in this case, that 1809 the Collecting Process' clock is irrelevant: it is only comparing the 1810 Export Times of Messages to each other. 1812 8.3. Additional considerations for Template Management over SCTP 1814 The specifications in this section apply only to SCTP; in case of 1815 contradiction with specifications in Sections 8 or 8.1, this section 1816 takes precedence. 1818 Template Sets and Options Template Sets MAY be sent on any SCTP 1819 stream. Data Sets sent on a given SCTP stream MAY be represented by 1820 Template Records exported on any SCTP stream. 1822 Template Sets and Options Template Sets MUST be sent reliably, using 1823 SCTP ordered delivery. 1825 Template Withdrawals MAY be sent on any SCTP stream. Template 1826 Withdrawals MUST be sent reliably, using SCTP ordered delivery. 1827 Template IDs MAY be reused by sending a Template Withdrawal and/or a 1828 new Template Record on a different SCTP stream than the stream on 1829 which the original Template was sent. 1831 Additional Template Management considerations are given in [RFC6526], 1832 which specifies an extension to explicitly link Templates with SCTP 1833 streams. In exchange for more restrictive rules on the assignment of 1834 Template Records to SCTP streams, this extension allows fast, 1835 reliable reuse of Template IDs and estimation of Data Record loss per 1836 Template. 1838 8.4. Additional considerations for Template Management over UDP 1840 The specifications in this section apply only to UDP; in case of 1841 contradiction with specifications in Sections 8 or 8.1, this section 1842 takes precedence. 1844 Since UDP provides no method for reliable transmission of Templates, 1845 Exporting Processes using UDP as the Transport Protocol MUST 1846 periodically retransmit each active Template at regular intervals. 1847 The Template retransmission interval MUST be configurable, as via the 1848 the templateRefreshTimeout and optionsTemplateRefreshTimeout defined 1849 in [RFC6728]. Default settings for these values are deployment- and 1850 application-specific. 1852 Before exporting any Data Records described by a given Template 1853 Record or Options Template Record, especially in the case of Template 1854 ID reuse as in section 8.1, the Exporting Process SHOULD send 1855 multiple copies of the Template Record in separate IPFIX Message, in 1856 order to help ensure the Collecting Process has received it. 1858 In order to minimize resource requirements for Templates which are no 1859 longer being used by the Exporting Process, the Collecting Process 1860 MAY associate a lifetime with each Template received in a UDP 1861 Transport Session. Templates not refreshed by the Exporting Process 1862 within the lifetime can then be discarded by the Collecting Process. 1863 The Template lifetime at the Collecting Process MAY be exposed by a 1864 configuration parameter, or MAY be derived from observation of the 1865 interval of periodic Template retransmissions from the Exporting 1866 Process. In this latter case, the Template lifetime SHOULD default to 1867 at least 3 times the observed retransmission rate. 1869 Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting 1870 Processes exporting via UDP, and MUST be ignored by Collecting 1871 Processes collecting via UDP. Template IDs MAY be reused by Exporting 1872 Processes by exporting a new Template for the Template ID after 1873 waiting at least 3 times the retransmission delay. Note that Template 1874 ID reuse may lead to incorrect interpretation of Data Records if the 1875 retransmission and lifetime are not properly configured. 1877 When a Collecting Process receives a new Template Record or Options 1878 Template Record via UDP for an already-allocated Template ID, and 1879 that Template or Options Template is identical to the already- 1880 received Template or Options Template, it SHOULD NOT log the 1881 retransmission, as this is the normal operation of Template refresh 1882 over UDP. 1884 When a Collecting Process receives a new Template Record or Options 1885 Template Record for an already-allocated Template ID, and that 1886 Template or Options Template is different from the already-received 1887 Template or Options Template, the Collecting Process MUST replace the 1888 Template or Options Template for that Template ID with the newly- 1889 received Template or Options Template. This is the normal operation 1890 of Template ID reuse over UDP. 1892 As Template IDs are unique per UDP session and per Observation 1893 Domain, at any given time, the Collecting Process SHOULD maintain the 1894 following for all the current Template Records and Options Template 1895 Records: . 1899 9. The Collecting Process's Side 1901 This section describes the handling of the IPFIX Protocol at the 1902 Collecting Process common to all Transport Protocols. Additional 1903 considerations for SCTP and UDP are given in Sections 9.2 and 9.3 1904 respectively. Template management at Collecting Processes is covered 1905 in Section 8. 1907 The Collecting Process MUST listen for association requests / 1908 connections to start new Transport Sessions from the Exporting 1909 Process. 1911 The Collecting Process MUST note the Information Element identifier 1912 of any Information Element that it does not understand and MAY 1913 discard that Information Element from received Data Records. 1915 The Collecting Process MUST accept padding in Data Records and 1916 Template Records. The padding size is the Set Length minus the size 1917 of the Set Header (4 octets for the Set ID and the Set Length), 1918 modulo the Record size deduced from the Template Record. 1920 The IPFIX protocol has a Sequence Number field in the Export header 1921 that increases with the number of IPFIX Data Records in the IPFIX 1922 Message. A Collector can detect out-of-sequence, dropped, or 1923 duplicate IPFIX Messages by tracking the Sequence Number. A 1924 Collector SHOULD provide a logging mechanism for tracking out-of- 1925 sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be 1926 due to Exporter resource exhaustion where it cannot transmit messages 1927 at their creation rate, an Exporting Process reset, congestion on the 1928 network link between the Exporter and Collector, Collector resource 1929 exhaustion where it cannot process the IPFIX Messages at their 1930 arrival rate, out-of-order packet reception, duplicate packet 1931 reception, or an attacker injecting false messages. 1933 9.1. Collecting Process handling of malformed IPFIX Messages 1935 If the Collecting Process receives a malformed IPFIX Message it MUST 1936 discard the IPFIX Message and SHOULD log the error. A malformed IPFIX 1937 Message is one that cannot be interpreted due to nonsensical length 1938 values (e.g., a variable length Information Element longer than its 1939 enclosing Set, a Set longer than its enclosing IPFIX Message, an 1940 IPFIX Message shorter than an IPFIX Message Header) or a reserved 1941 Version value (which may indicate a future version of IPFIX is being 1942 used for export, but practically occurs most often when non-IPFIX 1943 data is sent to an IPFIX Collecting Process). Note that non-zero Set 1944 padding does not constitute a malformed IPFIX Message. 1946 As the most likely cause of malformed IPFIX Messages is a poorly 1947 implemented Exporting Process, or the sending of non-IPFIX data to an 1948 IPFIX Collecting Process, human intervention is likely necessary to 1949 correct the issue. In the meantime, the Collecting Process MAY 1950 attempt to rectify the situation any way it sees fit, including: 1952 - terminating the TCP connection or SCTP connection 1954 - using the receiver window to reduce network load from the 1955 malfunctioning Exporting Process 1957 - buffering and saving malformed IPFIX Message(s) to assist in 1958 diagnosis 1960 - attempting to resynchronize the stream, e.g. as in section 1961 10.3 of [RFC5655] 1963 Resynchronization should only be attempted if there Collecting 1964 Process has reason to believe that the error is transient. On the 1965 other hand, the Collecting Process SHOULD stop processing IPFIX 1966 Messages from clearly malfunctioning Exporting Processes (e.g., those 1967 from which the last few IPFIX Messages have been malformed). 1969 9.2. Additional considerations for SCTP Collecting Processes 1971 As an Exporting Process may request and support more than one stream 1972 per SCTP association, the Collecting Process MUST support the opening 1973 of multiple SCTP streams. 1975 9.3. Additional considerations for UDP Collecting Processes 1977 A Transport Session for IPFIX Messages transported over UDP is 1978 defined from the point of view of the Exporting Process, and roughly 1979 corresponds to the time during which a given Exporting Process sends 1980 IPFIX Messages over UDP to a given Collecting Process. Since this is 1981 difficult to detect at the Collecting Process, the Collecting Process 1982 MAY discard all Transport Session state after no IPFIX Messages are 1983 received from a given Exporting Process within a given Transport 1984 Session during a configurable idle timeout. 1986 The Collecting Process SHOULD accept Data Records without the 1987 associated Template Record (or other definitions such as Common 1988 Properties) required to decode the Data Record. If the Template 1989 Records or other definitions have not been received at the time Data 1990 Records are received, the Collecting Process MAY store the Data 1991 Records for a short period of time and decode them after the Template 1992 Records or other definitions are received, comparing Export Times of 1993 IPFIX Messages containing the Template Records with those containing 1994 the Data Records as in Section 8.2. Note that this mechanism may lead 1995 to incorrectly interpreted records in the presence of Template ID 1996 reuse or other identifiers with limited lifetimes. 1998 10. Transport Protocol 1999 The IPFIX Protocol Specification has been designed to be transport 2000 protocol independent. Note that the Exporter can export to multiple 2001 Collecting Processes using independent transport protocols. 2003 The IPFIX Message Header 16-bit Length field limits the length of an 2004 IPFIX Message to 65535 octets, including the header. A Collecting 2005 Process MUST be able to handle IPFIX Message lengths of up to 65535 2006 octets. 2008 While an Exporting Process or Collecting Process may support multiple 2009 transport protocols, Transport Sessions are bound to a transport 2010 protocol. Transport Session state MUST NOT be migrated by an 2011 Exporting Process or Collecting Process among Transport Sessions 2012 using different transport protocols between the same Exporting 2013 Process and Collecting Process pair. In other words, an Exporting 2014 Process supporting multiple transport protocols is conceptually 2015 multiple Exporting Processes, one per supported transport protocol. 2016 Likewise, a Collecting Process supporting multiple transport 2017 protocols is conceptually multiple Collecting Processes, one per 2018 supported Transport Protocol. 2020 10.1. Transport Compliance and Transport Usage 2022 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 2023 MUST be implemented by all compliant implementations. UDP [UDP] MAY 2024 also be implemented by compliant implementations. TCP [TCP] MAY also 2025 be implemented by compliant implementations. 2027 SCTP should be used in deployments where Exporters and Collectors are 2028 communicating over links that are susceptible to congestion. SCTP is 2029 capable of providing any required degree of reliability when used 2030 with the PR-SCTP extension. 2032 TCP may be used in deployments where Exporters and Collectors 2033 communicate over links that are susceptible to congestion, but SCTP 2034 is preferred due to its ability to limit back pressure on Exporters 2035 and its message versus stream orientation. 2037 UDP may be used, although it is not a congestion-aware protocol. 2038 However, in this case the IPFIX traffic between Exporter and 2039 Collector must be separately contained or provisioned to minimize the 2040 risk of congestion-related loss. 2042 By default, the Collecting Process listens for connections on SCTP, 2043 TCP, and/or UDP port 4739. By default, the Collecting Process listens 2044 for secure connections on SCTP, TCP, and/or UDP port 4740 (refer to 2045 the Security Considerations section). By default, the Exporting 2046 Process attempts to connect to one of these ports. It MUST be 2047 possible to configure both the Exporting and Collecting Processes to 2048 use different ports than the default. 2050 10.2. SCTP 2052 This section describes how IPFIX is transported over SCTP [RFC4960] 2053 using the PR-SCTP [RFC3758] extension. 2055 10.2.1. Congestion Avoidance 2057 The SCTP transport protocol provides the required level of congestion 2058 avoidance by design. 2060 SCTP detects congestion in the end-to-end path between the IPFIX 2061 Exporting Process and the IPFIX Collecting Process, and limits the 2062 transfer rate accordingly. When an IPFIX Exporting Process has 2063 records to export, but detects that transmission by SCTP is 2064 temporarily impossible, it can either wait until sending is possible 2065 again, or it can decide to drop the record. In the latter case, the 2066 dropped export data SHOULD be accounted for, so that the amount of 2067 dropped export data can be reported using the mechanism in Section 2068 4.3. 2070 10.2.2. Reliability 2072 The SCTP transport protocol is by default reliable, but has the 2073 capability to deliver messages with partial reliability [RFC3758]. 2075 Using reliable SCTP messages for the IPFIX export is not in itself a 2076 guarantee that all Data Records will be delivered. If there is 2077 congestion on the link from the Exporting Process to the Collecting 2078 Process, or if a significant number of retransmissions are required, 2079 the send queues on the Exporting Process may fill up; the Exporting 2080 Process MAY either suspend, export, or discard the IPFIX Messages. 2081 If Data Records are discarded the IPFIX Sequence Numbers used for 2082 export MUST reflect the loss of data. 2084 10.2.3. MTU 2086 SCTP provides the required IPFIX Message fragmentation service based 2087 on path MTU discovery. 2089 10.2.4. Association Establishment and Shutdown 2091 The IPFIX Exporting Process initiates an SCTP association with the 2092 IPFIX Collecting Process. The Exporting Process MAY establish more 2093 than one association (connection "bundle" in SCTP terminology) to the 2094 Collecting Process. 2096 An Exporting Process MAY support more than one active association to 2097 different Collecting Processes (including the case of different 2098 Collecting Processes on the same host). 2100 When an Exporting Process is shut down, it SHOULD shut down the SCTP 2101 association. 2103 When a Collecting Process no longer wants to receive IPFIX Messages, 2104 it SHOULD shut down its end of the association. The Collecting 2105 Process SHOULD continue to receive and process IPFIX Messages until 2106 the Exporting Process has closed its end of the association. 2108 When a Collecting Process detects that the SCTP association has been 2109 abnormally terminated, it MUST continue to listen for a new 2110 association establishment. 2112 When an Exporting Process detects that the SCTP association to the 2113 Collecting Process is abnormally terminated, it SHOULD try to 2114 re-establish the association. 2116 Association timeouts SHOULD be configurable. 2118 10.2.5. Failover 2120 If the Collecting Process does not acknowledge an attempt by the 2121 Exporting Process to establish an association, SCTP will 2122 automatically retry association establishment using exponential 2123 backoff. The Exporter MAY log an alarm if the underlying SCTP 2124 association establishment times out; this timeout should be 2125 configurable on the Exporter. 2127 The Exporting Process MAY open a backup SCTP association to a 2128 Collecting Process in advance, if it supports Collecting Process 2129 failover. 2131 10.2.6. Streams 2133 An Exporting Process MAY request more than one SCTP stream per 2134 association. Each of these streams may be used for the transmission 2135 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 2136 Template Sets. 2138 Depending on the requirements of the application, the Exporting 2139 Process may send Data Sets with full or partial reliability, using 2140 ordered or out-of-order delivery, over any SCTP stream established 2141 during SCTP Association setup. 2143 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 2144 per Section 4 of the PR-SCTP [RFC3758] specification when using 2145 partial reliability to transmit IPFIX Messages containing only Data 2146 Sets. 2148 However, Exporting Processes SHOULD mark such IPFIX Messages for 2149 retransmission for as long as resource or other constraints allow. 2151 10.3. UDP 2153 This section describes how IPFIX is transported over UDP [UDP]. 2155 10.3.1. Congestion Avoidance 2157 UDP has no integral congestion-avoidance mechanism. Its use over 2158 congestion-sensitive network paths is therefore not recommended. UDP 2159 MAY be used in deployments where Exporters and Collectors always 2160 communicate over dedicated links that are not susceptible to 2161 congestion, i.e., links that are over-provisioned compared to the 2162 maximum export rate from the Exporters. 2164 10.3.2. Reliability 2166 UDP is not a reliable transport protocol, and cannot guarantee 2167 delivery of messages. IPFIX Messages sent from the Exporting Process 2168 to the Collecting Process using UDP may therefore be lost. UDP MUST 2169 NOT be used unless the application can tolerate some loss of IPFIX 2170 Messages. 2172 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 2173 Data Records by looking at the discontinuities in the IPFIX Sequence 2174 Number. In the case of UDP, the IPFIX Sequence Number contains the 2175 total number of IPFIX Data Records sent for the UDP Transport Session 2176 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 2177 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 2178 by tracking the Sequence Number. 2180 Exporting Processes exporting IPFIX Messages via UDP MUST include a 2181 valid UDP checksum [UDP] in UDP datagrams including IPFIX messages. 2183 10.3.3. MTU 2185 The maximum size of exported messages MUST be configured such that 2186 the total packet size does not exceed the path MTU. If the path MTU 2187 is unknown, a maximum packet size of 512 octets SHOULD be used. 2189 10.3.4. Session Establishment and Shutdown 2191 As UDP is a connectionless protocol, there is no real session 2192 establishment or shutdown for IPFIX over UDP. An Exporting Process 2193 starts sending IPFIX Messages to a Collecting Process at one point in 2194 time, and stops sending them at another point in time. This can lead 2195 to some complications in Template management, which are outlined in 2196 Section 8.4 above. 2198 10.3.5. Failover and Session Duplication 2200 Because UDP is not a connection-oriented protocol, the Exporting 2201 Process is unable to determine from the transport protocol that the 2202 Collecting Process is no longer able to receive the IPFIX Messages. 2203 Therefore, it cannot invoke a failover mechanism. However, the 2204 Exporting Process MAY duplicate the IPFIX Message to several 2205 Collecting Processes. 2207 10.4. TCP 2209 This section describes how IPFIX is transported over TCP [TCP]. 2211 10.4.1. Congestion Avoidance 2213 TCP controls the rate at which data can be sent from the Exporting 2214 Process to the Collecting Process, using a mechanism that takes into 2215 account both congestion in the network and the capabilities of the 2216 receiver. 2218 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2219 Messages at the rate that the Metering Process generates them, either 2220 because of congestion in the network or because the Collecting 2221 Process cannot handle IPFIX Messages fast enough. As long as 2222 congestion is transient, the Exporting Process can buffer IPFIX 2223 Messages for transmission. But such buffering is necessarily limited, 2224 both because of resource limitations and because of timeliness 2225 requirements, so ongoing and/or severe congestion may lead to a 2226 situation where the Exporting Process is blocked. 2228 When an Exporting Process has Data Records to export but the 2229 transmission buffer is full, and it wants to avoid blocking, it can 2230 decide to drop some Data Records. The dropped Data Records MUST be 2231 accounted for, so that the number of lost records can later be 2232 reported as in Section 4.3. 2234 10.4.2. Reliability 2236 TCP ensures reliable delivery of data from the Exporting Process to 2237 the Collecting Process. 2239 10.4.3. MTU 2241 As TCP offers a stream service instead of a datagram or sequential 2242 packet service, IPFIX Messages transported over TCP are instead 2243 separated using the Length field in the IPFIX Message Header. The 2244 Exporting Process can choose any valid length for exported IPFIX 2245 Messages, as TCP handles segmentation. 2247 Exporting Processes may choose IPFIX Message lengths lower than the 2248 maximum in order to ensure timely export of Data Records. 2250 10.4.4. Connection Establishment and Shutdown 2252 The IPFIX Exporting Process initiates a TCP connection to the 2253 Collecting Process. An Exporting Process MAY support more than one 2254 active connection to different Collecting Processes (including the 2255 case of different Collecting Processes on the same host). An 2256 Exporting Process MAY support more than one active connection to the 2257 same Collecting Process to avoid head of line blocking across 2258 Observation Domains. 2260 The Exporter MAY log an alarm if the underlying TCP connection 2261 establishment times out; this timeout should be configurable on the 2262 Exporter. 2264 When an Exporting Process is shut down, it SHOULD shut down the TCP 2265 connection. 2267 When a Collecting Process no longer wants to receive IPFIX Messages, 2268 it SHOULD close its end of the connection. The Collecting Process 2269 SHOULD continue to read IPFIX Messages until the Exporting Process 2270 has closed its end. 2272 When a Collecting Process detects that the TCP connection to the 2273 Exporting Process has terminated abnormally, it MUST continue to 2274 listen for a new connection. 2276 When an Exporting Process detects that the TCP connection to the 2277 Collecting Process has terminated abnormally, it SHOULD try to 2278 re-establish the connection. Connection timeouts and retry schedules 2279 SHOULD be configurable. In the default configuration, an Exporting 2280 Process MUST NOT attempt to establish a connection more frequently 2281 than once per minute. 2283 10.4.5. Failover 2285 If the Collecting Process does not acknowledge an attempt by the 2286 Exporting Process to establish a connection, TCP will automatically 2287 retry connection establishment using exponential backoff. The 2288 Exporter MAY log an alarm if the underlying TCP connection 2289 establishment times out; this timeout should be configurable on the 2290 Exporter. 2292 The Exporting Process MAY open a backup TCP connection to a 2293 Collecting Process in advance, if it supports Collecting Process 2294 failover. 2296 11. Security Considerations 2298 The security considerations for the IPFIX protocol have been derived 2299 from an analysis of potential security threats, as discussed in the 2300 "Security Considerations" section of IPFIX requirements [RFC3917]. 2301 The requirements for IPFIX security are as follows: 2303 1. IPFIX must provide a mechanism to ensure the confidentiality of 2304 IPFIX data transferred from an Exporting Process to a Collecting 2305 Process, in order to prevent disclosure of Flow Records 2306 transported via IPFIX. 2308 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2309 data transferred from an Exporting Process to a Collecting 2310 Process, in order to prevent the injection of incorrect data or 2311 control information (e.g., Templates), or the duplication of 2312 Messages, in an IPFIX Message stream. 2314 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2315 and Exporting Processes, to prevent the collection of data from an 2316 unauthorized Exporting Process or the export of data to an 2317 unauthorized Collecting Process. 2319 Because IPFIX can be used to collect information for network 2320 forensics and billing purposes, attacks designed to confuse, disable, 2321 or take information from an IPFIX collection system may be seen as a 2322 prime objective during a sophisticated network attack. 2324 An attacker in a position to inject false messages into an IPFIX 2325 Message stream can either affect the application using IPFIX (by 2326 falsifying data), or the IPFIX Collecting Process itself (by 2327 modifying or revoking Templates, or changing options); for this 2328 reason, IPFIX Message integrity is important. 2330 The IPFIX Messages themselves may also contain information of value 2331 to an attacker, including information about the configuration of the 2332 network as well as end-user traffic and payload data, so care must be 2333 taken to confine their visibility to authorized users. When an 2334 Information Element containing end-user payload information is 2335 exported, it SHOULD be transmitted to the Collecting Process using a 2336 means that secures its contents against eavesdropping. Suitable 2337 mechanisms include the use of either a direct point-to-point 2338 connection assumed to be unavailable to attackers, or the use of an 2339 encryption mechanism. It is the responsibility of the Collecting 2340 Process to provide a satisfactory degree of security for this 2341 collected data, including, if necessary, encryption and/or 2342 anonymization of any reported data; see Section 11.8. 2344 11.1. Applicability of TLS and DTLS 2346 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2347 Security (DTLS) [RFC6347] were designed to provide the 2348 confidentiality, integrity, and authentication assurances required by 2349 the IPFIX protocol, without the need for pre-shared keys. 2351 IPFIX Exporting Processes and Collecting Processes using TCP MUST 2352 support TLS version 1.1 and SHOULD support TLS version 1.2 [RFC5246], 2353 including the mandatory cipher suite(s) specified in each version. 2354 IPFIX Exporting Processes and Collecting Processes using UDP or SCTP 2355 MUST support DTLS 1.0 and SHOULD support DTLS version 1.2 [RFC6347], 2356 including the mandatory cipher suite(s) specified in each version. 2358 Note that DTLS is selected as the security mechanism for SCTP. Though 2359 TLS bindings to SCTP are defined in [RFC3436], they require all 2360 communication to be over reliable, bidirectional streams, and require 2361 one TLS connection per stream. This arrangement is not compatible 2362 with the rationale behind the choice of SCTP as an IPFIX transport 2363 protocol. 2365 Note that using DTLS has a man-in-the-middle vulnerability not 2366 present in TLS, allowing a message to be removed from the stream 2367 without the knowledge of either the sender or receiver. Additionally, 2368 when using DTLS over SCTP, an attacker could inject SCTP control 2369 information and shut down the SCTP association, causing a loss of 2370 IPFIX Messages if those are buffered outside of the SCTP association. 2371 Techniques such as those described in [RFC6083] could be used to 2372 overcome these vulnerabilities. 2374 When using DTLS over SCTP, the Exporting Process MUST ensure that 2375 each IPFIX Message is sent over the same SCTP stream that would be 2376 used when sending the same IPFIX Message directly over SCTP. Note 2377 that DTLS may send its own control messages on stream 0 with full 2378 reliability; however, this will not interfere with the processing of 2379 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2380 consumes its own control messages before passing IPFIX Messages up to 2381 the application layer. 2383 When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] 2384 SHOULD be used, especially on long-lived Transport Sessions, to 2385 ensure that the association remains active. 2387 Exporting and Collecting Processes MUST NOT request, offer, or use 2388 any version of SSL, or any version of TLS prior to 1.1, due to known 2389 security vulnerabilities in prior versions of the protocol; see 2390 Appendix E of [RFC5246] for more information. 2392 11.2. Usage 2394 The IPFIX Exporting Process initiates the communication to the IPFIX 2395 Collecting Process, and acts as a TLS or DTLS client according to 2396 [RFC5246] and [RFC6347] while the IPFIX Collecting Process acts as a 2397 TLS or DTLS server. The DTLS client opens a secure connection on the 2398 SCTP port 4740 of the DTLS server if SCTP is selected as the 2399 transport protocol. The TLS client opens a secure connection on the 2400 TCP port 4740 of the TLS server if TCP is selected as the transport 2401 protocol. The DTLS client opens a secure connection on the UDP port 2402 4740 of the DTLS server if UDP is selected as the transport 2403 protocol. 2405 11.3. Mutual Authentication 2407 When using TLS or DTLS, IPFIX Exporting Processes and IPFIX 2408 Collecting Processes SHOULD be identified by a certificate containing 2409 the DNS-ID identifier as in Section 6.4 of [RFC6125]; the inclusion 2410 of Common Names (CN-IDs) in certificates identifying IPFIX Exporting 2411 Processes or Collecting Processes is NOT RECOMMENDED. 2413 To prevent man-in-the-middle attacks from impostor Exporting or 2414 Collecting Processes, the acceptance of data from an unauthorized 2415 Exporting Process, or the export of data to an unauthorized 2416 Collecting Process, mutual authentication MUST be used for both TLS 2417 and DTLS. Exporting Processes MUST verify the reference identifiers 2418 of the Collecting Processes they are exporting IPFIX messages to 2419 against those stored in the certificates. Likewise, Collecting 2420 Processes MUST verify the reference identifiers of the Exporting 2421 Processes they are receiving IPFIX Messages from against those stored 2422 in the certificates. Exporting Processes MUST NOT export to non- 2423 verified Collecting Processes, and Collecting Processes MUST NOT 2424 accept IPFIX Messages from non-verified Exporting Processes. 2426 Exporting Processes and Collecting Processes MUST support the 2427 verification of certificates against an explicitly authorized list of 2428 peer certificates identified by Common Name, and SHOULD support the 2429 verification of reference identifiers by matching the DNS-ID or CN-ID 2430 with a DNS lookup of the peer. 2432 IPFIX Exporting Processes and Collecting Processes MUST use non-NULL 2433 ciphersuites for authentication, integrity, and confidentiality. 2435 11.4. Protection against DoS Attacks 2437 An attacker may mount a denial-of-service (DoS) attack against an 2438 IPFIX collection system either directly, by sending large amounts of 2439 traffic to a Collecting Process, or indirectly, by generating large 2440 amounts of traffic to be measured by a Metering Process. 2442 Direct DoS attacks can also involve state exhaustion, whether at the 2443 transport layer (e.g., by creating a large number of pending 2444 connections), or within the IPFIX Collecting Process itself (e.g., by 2445 sending Flow Records pending Template or scope information, or a 2446 large amount of Options Template Records, etc.). 2448 SCTP mandates a cookie-exchange mechanism designed to defend against 2449 SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN 2450 cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be 2451 used by any Collecting Process accepting TCP connections. DTLS also 2452 provides cookie exchange to protect against DTLS server state 2453 exhaustion. 2455 The reader should note that there is no way to prevent fake IPFIX 2456 Message processing (and state creation) for UDP & SCTP communication. 2457 The use of TLS and DTLS can obviously prevent the creation of fake 2458 states, but they are themselves prone to state exhaustion attacks. 2459 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2460 DTLS (like limiting the number of new TLS or DTLS session per second 2461 to a sensible number). 2463 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2464 at which new connections or associations will be opened by the 2465 Collecting Process, the rate at which IPFIX Messages will be accepted 2466 by the Collecting Process, and adaptively limiting the amount of 2467 state kept, particularly records waiting on Templates. These rate 2468 and state limits MAY be provided by a Collecting Process, and if 2469 provided, the limits SHOULD be user configurable. 2471 Additionally, an IPFIX Collecting Process can eliminate the risk of 2472 state exhaustion attacks from untrusted nodes by requiring TLS or 2473 DTLS mutual authentication, causing the Collecting Process to accept 2474 IPFIX Messages only from trusted sources. 2476 With respect to indirect denial of service, the behavior of IPFIX 2477 under overload conditions depends on the transport protocol in use. 2478 For IPFIX over TCP, TCP congestion control would cause the flow of 2479 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2480 system. SCTP improves upon this situation somewhat, as some IPFIX 2481 Messages would continue to be received by the Collecting Process due 2482 to the avoidance of head-of-line blocking by SCTP's multiple streams 2483 and partial reliability features, possibly affording some visibility 2484 of the attack. The situation is similar with UDP, as some datagrams 2485 may continue to be received at the Collecting Process, effectively 2486 applying sampling to the IPFIX Message stream, implying that some 2487 forensics may be left. 2489 To minimize IPFIX Message loss under overload conditions, some 2490 mechanism for service differentiation could be used to prioritize 2491 IPFIX traffic over other traffic on the same link. Alternatively, 2492 IPFIX Messages can be transported over a dedicated network. In this 2493 case, care must be taken to ensure that the dedicated network can 2494 handle the expected peak IPFIX Message traffic. 2496 11.5. When DTLS or TLS Is Not an Option 2498 The use of DTLS or TLS might not be possible in some cases due to 2499 performance issues or other operational concerns. 2501 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2502 and Collecting Processes can fall back on using IP source addresses 2503 to authenticate their peers. A policy of allocating Exporting 2504 Process and Collecting Process IP addresses from specified address 2505 ranges, and using ingress filtering to prevent spoofing, can improve 2506 the usefulness of this approach. Again, completely segregating IPFIX 2507 traffic on a dedicated network, where possible, can improve security 2508 even further. In any case, the use of open Collecting Processes 2509 (those that will accept IPFIX Messages from any Exporting Process 2510 regardless of IP address or identity) is discouraged. 2512 Modern TCP and SCTP implementations are resistant to blind insertion 2513 attacks (see [RFC4960], [RFC6528]); however, UDP offers no such 2514 protection. For this reason, IPFIX Message traffic transported via 2515 UDP and not secured via DTLS SHOULD be protected via segregation to a 2516 dedicated network. 2518 11.6. Logging an IPFIX Attack 2520 IPFIX Collecting Processes MUST detect potential IPFIX Message 2521 insertion or loss conditions by tracking the IPFIX Sequence Number, 2522 and SHOULD provide a logging mechanism for reporting out-of-sequence 2523 messages. Note that an attacker may be able to exploit the handling 2524 of out-of-sequence messages at the Collecting Process, so care should 2525 be taken in handling these conditions. For example, a Collecting 2526 Process that simply resets the expected Sequence Number upon receipt 2527 of a later Sequence Number could be temporarily blinded by deliberate 2528 injection of later Sequence Numbers. 2530 IPFIX Exporting and Collecting Processes SHOULD log any connection 2531 attempt that fails due to authentication failure, whether due to 2532 being presented an unauthorized or mismatched certificate during TLS 2533 or DTLS mutual authentication, or due to a connection attempt from an 2534 unauthorized IP address when TLS or DTLS is not in use. 2536 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2537 SCTP association reset or TCP connection reset. 2539 11.7. Securing the Collector 2541 The security of the Collector and its implementation is important to 2542 achieve overall security; however, a complete set of security 2543 guidelines for Collector implementation is outside the scope of this 2544 document. 2546 As IPFIX uses length-prefix encodings, Collector implementors should 2547 take care to ensure detection of and proper operation despite 2548 inconsistent values that could impact IPFIX Message decoding. 2549 Specifically, IPFIX Message, Set, and variable-length Information 2550 Element lengths must be checked for consistency to avoid buffer- 2551 sizing vulnerabilities. 2553 Collector implementors should also pay special attention to UTF-8 2554 encoding of string datatypes, as vulnerabilities may exist in the 2555 interpretation of ill-formed UTF-8 values; see Section 6.1.6. 2557 11.8. Privacy Considerations for Collected Data 2559 Flow data exported by Exporting Processes, and collected by 2560 Collecting Processes, typically contains information about traffic on 2561 the observed network. This information may be personally identifiable 2562 and privacy-sensitive. The storage of this data must be protected via 2563 technical as well as policy means to ensure that the privacy of the 2564 users of the measured network is protected. A complete specification 2565 of such means is out of scope for this document, and specific to the 2566 application and storage technology used. 2568 12. Management Considerations 2570 [RFC6615] specifies a MIB module that defines managed objects for 2571 monitoring IPFIX Devices, including basic configuration. This MIB can 2572 be used to measure the impact of IPFIX export on the monitoring 2573 network, and contains tables covering: 2575 Transport Session, 2576 Cache definition, 2577 Observation Point definition, 2578 Template and Options Template definition, 2579 export features (failover, load-balancing, duplicate), 2580 export statistics per Process, Session, and Template 2582 From an operational aspect, an important function of this MIB module 2583 is given by the Transport Session Statistical table which contains 2584 the rate (in bytes per second) at which the Collector receives or the 2585 Exporter sends out IPFIX Messages. Of particular interest to 2586 operations, the Transport Session Statistical table in this MIB 2587 module (Section 5.8.1) exposes the rate of collection or export of 2588 IPFIX Messages, which allows the measurement of the bandwidth used by 2589 IPFIX export. 2591 RFC6727 describes extensions to the IPFIX-SELECTOR-MIB module, 2592 specified in RFC6615, containing managed objects for providing 2593 information on applied packet selection functions and their 2594 parameters (filtering and sampling). 2596 Since the two MIB modules [RFC6615][RFC6727] only contain read-only 2597 objects, they cannot be used for configuration of IPFIX Devices. 2598 [RFC6728] specifies a configuration data model for the IPFIX and 2599 PSAMP protocols using the Network Configuration Protocol (NETCONF). 2600 This data model covers Selection Processes, Caches, Exporting 2601 Processes, and Collecting Processes on IPFIX and PSAMP Devices, and 2602 is defined using UML (Unified Modeling Language) class diagrams and 2603 formally specified using YANG. The configuration data is encoded in 2604 Extensible Markup Language (XML). 2606 A few mechanisms specified alongside the IPFIX Protocol can help 2607 monitor and reduce bandwidth used for IPFIX Export: 2609 - a bandwidth-saving method for exporting redundant information in 2610 IPFIX [RFC5473] 2612 - an efficient method for exporting bidirectional flows [RFC5103] 2613 - a method for the definition and export of complex data 2614 structures [RFC6313] 2616 Alternately, PSAMP [RFC5474] can be used to export packets sampled by 2617 statistical and other methods, which may be applicable to many 2618 monitoring areas for which IPFIX is also suited, and provides control 2619 over the impact on the measured network through its sampling rate. 2620 The set of packet selection techniques (Sampling, Filtering, and 2621 hashing) standardized by PSAMP is described in [RFC5475]. PSAMP also 2622 defines an explicitly configurable export rate limit in section 8.4 2623 of [RFC5474]. 2625 13. IANA Considerations 2627 On publication of this document, IANA will update the IPFIX 2628 Information Element Registry [IPFIX-IANA] to update all references to 2629 RFC5101 to point to this document, instead. 2631 This document has no further actions for IANA; the text below is 2632 explanatory. 2634 IPFIX Messages use two fields with assigned values. These are the 2635 IPFIX Version Number, indicating which version of the IPFIX Protocol 2636 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2637 the type for each set of information within an IPFIX Message. 2639 The Information Elements used by IPFIX, and sub-registries of 2640 Information Element values, are managed by IANA [IPFIX-IANA], as are 2641 the Private Enterprise Numbers used by enterprise-specific 2642 Information Elements [PEN-IANA]. This document makes no changes to 2643 these registries. 2645 The IPFIX Version Number value of 0x000a (10) is reserved for the 2646 IPFIX protocol specified in this document. Set ID values of 0 and 1 2647 are not used, for historical reasons [RFC3954]. The Set ID value of 2648 2 is reserved for the Template Set. The Set ID value of 3 is 2649 reserved for the Options Template Set. All other Set ID values from 2650 4 to 255 are reserved for future use. Set ID values above 255 are 2651 used for Data Sets. 2653 New assignments in either IPFIX Version Number or IPFIX Set ID 2654 assignments require a Standards Action [RFC5226], i.e., they are to 2655 be made via Standards Track RFCs approved by the IESG. 2657 Appendix A. IPFIX Encoding Examples 2659 This appendix, which is a not a normative reference, contains IPFIX 2660 encoding examples. 2662 Let's consider the example of an IPFIX Message composed of a 2663 Template Set, a Data Set (which contains three Data Records), an 2664 Options Template Set and a Data Set (which contains 2 Data Records 2665 related to the previous Options Template Record). 2667 IPFIX Message: 2669 +--------+------------------------------------------. . . 2670 | | +--------------+ +------------------+ 2671 |Message | | Template | | Data | 2672 | Header | | Set | | Set | . . . 2673 | | | (1 Template) | | (3 Data Records) | 2674 | | +--------------+ +------------------+ 2675 +--------+------------------------------------------. . . 2677 . . .-------------------------------------------+ 2678 +------------------+ +------------------+ | 2679 | Options | | Data | | 2680 . . . | Template Set | | Set | | 2681 | (1 Template) | | (2 Data Records) | | 2682 +------------------+ +------------------+ | 2683 . . .-------------------------------------------+ 2685 A.1. Message Header Example 2687 The Message Header is composed of: 2688 0 1 2 3 2689 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 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | Version = 0x000a | Length = 152 | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Export Time | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Sequence Number | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Observation Domain ID | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 A.2. Template Set Examples 2702 A.2.1. Template Set Using IANA Information Elements 2704 We want to report the following Information Elements: 2706 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], 2707 with a length of 4 octets 2709 - The IPv4 destination IP address: destinationIPv4Address in 2710 [IPFIX-IANA], with a length of 4 octets 2712 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2713 [IPFIX-IANA], with a length of 4 octets 2715 - The number of packets of the Flow: packetDeltaCount in 2716 [IPFIX-IANA], with a length of 4 octets 2718 - The number of octets of the Flow: octetDeltaCount in 2719 [IPFIX-IANA], with a length of 4 octets 2721 Therefore, the Template Set will be composed of the following: 2723 0 1 2 3 2724 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 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Set ID = 2 | Length = 28 octets | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | Template ID 256 | Field Count = 5 | 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 |0| sourceIPv4Address = 8 | Field Length = 4 | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 |0| destinationIPv4Address = 12 | Field Length = 4 | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 |0| packetDeltaCount = 2 | Field Length = 4 | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 |0| octetDeltaCount = 1 | Field Length = 4 | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 A.2.2. Template Set Using Enterprise-Specific Information Elements 2743 We want to report the following Information Elements: 2745 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], with 2746 a length of 4 octets 2748 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2749 IANA], with a length of 4 octets 2751 - An enterprise-specific Information Element representing 2752 proprietary information, with a type of 15 and a length of 4 2754 - The number of packets of the Flow: packetDeltaCount in [IPFIX- 2755 IANA], with a length of 4 octets 2757 - The number of octets of the Flow: octetDeltaCount in [IPFIX-IANA], 2758 with a length of 4 octets 2760 Therefore, the Template Set will be composed of the following: 2762 0 1 2 3 2763 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 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Set ID = 2 | Length = 32 octets | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | Template ID 257 | Field Count = 5 | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 |0| sourceIPv4Address = 8 | Field Length = 4 | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 |0| destinationIPv4Address = 12 | Field Length = 4 | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 |1| Information Element Id. = 15| Field Length = 4 | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | Enterprise number | 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 |0| packetDeltaCount = 2 | Field Length = 4 | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 |0| octetDeltaCount = 1 | Field Length = 4 | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 A.3. Data Set Example 2784 In this example, we report the following three Flow Records: 2786 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2787 | | | Number | Number 2788 ------------------------------------------------------------------ 2789 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2790 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2791 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2793 0 1 2 3 2794 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 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | Set ID = 256 | Length = 64 | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | 192.0.2.12 | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | 192.0.2.254 | 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 | 192.0.2.1 | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | 5009 | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | 5344385 | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | 192.0.2.27 | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | 192.0.2.23 | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | 192.0.2.2 | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | 748 | 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 | 388934 | 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 | 192.0.2.56 | 2819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2820 | 192.0.2.65 | 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 | 192.0.2.3 | 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2824 | 5 | 2825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2826 | 6534 | 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 Note that padding is not necessary in this example. 2831 A.4. Options Template Set Examples 2833 A.4.1. Options Template Set Using IANA Information Elements 2835 Per line card (the router being composed of two line cards), we want 2836 to report the following Information Elements: 2838 - Total number of IPFIX Messages: exportedMessageTotalCount [IPFIX- 2839 IANA], with a length of 2 octets 2841 - Total number of exported Flows: exportedFlowRecordTotalCount 2842 [IPFIX-IANA], with a length of 2 octets 2844 The line card, which is represented by the lineCardId Information 2845 Element [IPFIX-IANA], is used as the Scope Field. 2847 Therefore, the Options Template Set will be: 2849 0 1 2 3 2850 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 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | Set ID = 3 | Length = 24 | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Template ID 258 | Field Count = 3 | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | Scope Field Count = 1 |0| lineCardId = 141 | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | Field Length = 2 | Padding | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 A.4.2. Options Template Set Using Enterprise-Specific Information 2866 Elements 2868 Per line card (the router being composed of two line cards), we want 2869 to report the following Information Elements: 2871 - Total number of IPFIX Messages: exportedMessageTotalCount 2872 [IPFIX-IANA], with a length of 2 octets 2874 - An enterprise-specific number of exported Flows, with a type of 2875 42 and a length of 4 octets 2877 The line card, which is represented by the lineCardId Information 2878 Element [IPFIX-IANA], is used as the Scope Field. 2880 The format of the Options Template Set is as follows: 2882 0 1 2 3 2883 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 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | Set ID = 3 | Length = 28 | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Template ID 259 | Field Count = 3 | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Scope Field Count = 1 |0| lineCardId = 141 | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | Field Length = 2 |1|Information Element Id. = 42 | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | Field Length = 4 | Enterprise number ... 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 ... Enterprise number | Padding | 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2902 In this example, we want to export the same information as in the 2903 example in Section A.4.1: 2905 - Total number of IPFIX Messages: exportedMessageTotalCount 2906 [IPFIX-IANA], with a length of 2 octets 2908 - Total number of exported Flows: exportedFlowRecordTotalCount 2909 [IPFIX-IANA], with a length of 2 octets 2911 But this time, the information pertains to a proprietary scope, 2912 identified by enterprise-specific Information Element number 123. 2914 The format of the Options Template Set is now as follows: 2916 0 1 2 3 2917 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 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Set ID = 3 | Length = 28 | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Template ID 260 | Field Count = 3 | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | Scope 1 Field Length = 4 | Enterprise Number ... 2926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2927 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | Field Length = 2 | Padding | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 A.4.4. Data Set Using an Enterprise-Specific Scope 2936 In this example, we report the following two Data Records: 2938 Enterprise field 123 | IPFIX Message | Exported Flow Records 2939 ------------------------------------------------------------------- 2940 1 | 345 | 10201 2941 2 | 690 | 20402 2943 0 1 2 3 2944 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 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | Set ID = 260 | Length = 20 | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 | 1 | 2949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 | 345 | 10201 | 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | 2 | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 | 690 | 20402 | 2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 A.5. Variable-Length Information Element Examples 2959 A.5.1. Example of Variable-Length Information Element with Length 2960 Inferior to 255 Octets 2962 0 1 2 3 2963 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 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | 5 | 5 octet Information Element | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2970 A.5.2. Example of Variable-Length Information Element with 3 Octet 2971 Length Encoding 2973 0 1 2 3 2974 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 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | 255 | 1000 | IE ... | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 | 1000 octet Information Element | 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 : ... : 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | ... IE | 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 References 2987 Normative References 2989 [RFC1014] Sun Microsystems, Inc., "XDR: External Data 2990 Representation Standard", RFC 1014, June 1987. 2992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2993 Requirement Levels", BCP 14, RFC 2119, March 1997. 2995 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2996 Layer Security over Stream Control Transmission 2997 Protocol", RFC 3436, December 2002. 2999 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3000 10646", RFC 3629, November 2003. 3002 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 3003 Conrad, "Stream Control Transmission Protocol (SCTP) 3004 Partial Reliability Extension", RFC 3758, May 2004. 3006 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 3007 Protocol", RFC 4960, September 2007. 3009 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3010 an IANA Considerations Section in RFCs", BCP 26, RFC 3011 5226, May 2008. 3013 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 3014 Security (TLS) Protocol Version 1.2", RFC 5246, August 3015 2008. 3017 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 3018 W. Kasch, "Network Time Protocol Version 4: Protocol 3019 and Algorithms Specification", RFC 5905, June 2010 3021 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3022 Verification of Domain-Based Application Service 3023 Identity within Internet Public Key Infrastructure 3024 Using X.509 (PKIX) Certificates in the Context of 3025 Transport Layer Security (TLS)", RFC 6125, March 2011. 3027 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 3028 Layer Security Version 1.2", RFC 6347, January 2012. 3030 [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., 3031 "Transport Layer Security (TLS) and Datagram Transport 3032 Layer Security (DTLS) Heartbeat Extension", RFC 6520, 3033 February 2012. 3035 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 3036 RFC 793, September 1981. 3038 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3039 August 1980. 3041 [RFC5102bis] Claise, B., and B. Trammell, eds., "Information Model 3042 for IP Flow Information Export", draft-ietf-ipfix- 3043 information-model-rfc5102bis-10.txt, Work in Progress, 3044 February 2013. 3046 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 3048 Informative References 3050 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 3051 "Textual Conventions for SMIv2", STD 58, RFC 2579, 3052 April 1999. 3054 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3055 Jacobson, "RTP: A Transport Protocol for Real-Time 3056 Applications", STD 64, RFC 3550, July 2003. 3058 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 3059 "Requirements for IP Flow Information Export (IPFIX)", 3060 RFC 3917, October 2004. 3062 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 3063 Export Version 9", RFC 3954, October 2004. 3065 [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP 3066 Flow Information Export (IPFIX)", RFC 5103, January 3067 2008. 3069 [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP 3070 Flow Information Export (IPFIX) Protocol for the 3071 Exchange of IP Traffic Flow Information", RFC 5101, 3072 January 2008. 3074 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 3075 Flow Information Export (IPFIX) Implementation 3076 Guidelines", RFC5153, April 2008 3078 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 3079 Quittek, "Architecture for IP Flow Information 3080 Export", RFC5470, March 2009. 3082 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 3083 "IP Flow Information Export (IPFIX) Applicability", 3084 RFC5472, March 2009. 3086 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 3087 for IP Flow Information Export (IPFIX) Testing", 3088 RFC5471, March 2009. 3090 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 3091 Redundancy in IP Flow Information Export (IPFIX) and 3092 Packet Sampling (PSAMP) Reports", RFC5473, March 2009. 3094 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, 3095 A., Grossglauser, M., and J. Rexford, "A Framework for 3096 Packet Selection and Reporting", RFC 5474, March 2009. 3098 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., 3099 and F. Raspall, "Sampling and Filtering Techniques for 3100 IP Packet Selection", RFC 5475, March 2009. 3102 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet 3103 Sampling (PSAMP) Protocol Specifications", RFC5476, 3104 March 2009. 3106 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and 3107 G. Carle, "Information Model for Packet Sampling 3108 Exports", RFC 5477, March 2009. 3110 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 3111 "Exporting Type Information for IP Flow Information 3112 Export (IPFIX) Information Elements", RFC 5610, July 3113 2009. 3115 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 3116 Wagner, "Specification of the IP Flow Information 3117 Export (IPFIX) File Format", RFC 5655, October 2009. 3119 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 3120 Transport Layer Security (DTLS) for Stream Control 3121 Transmission Protocol (SCTP)", RFC6083, January 2011. 3123 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 3124 "Export of Structured Data in IP Flow Information 3125 Export (IPFIX)", RFC6313, July 2011. 3127 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 3128 "IP Flow Information Export (IPFIX) Mediation: 3129 Framework", RFC6183, April 2011. 3131 [RFC6526] Claise, B., Aitken, P., Johnson, A. and G. Muenz, 3132 "IPFIX Export per SCTP Stream", RFC 6526, March 2012. 3134 [RFC6528] Gont, F. and S. Bellovin, "Defending Against Sequence 3135 Number Attacks", RFC 6528, February 2012. 3137 [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 3138 "Definitions of Managed Objects for IP Flow 3139 Information Export", RFC 6615, June 2012. 3141 [RFC6727] Dietz, T. Ed., Claise, B., and J. Quittek, 3142 "Definitions of Managed Objects for Packet Sampling", 3143 RFC 6727, October 2012. 3145 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration 3146 Data Model for IPFIX and PSAMP", RFC 6728, October 3147 2012. 3149 [PEN-IANA] IANA Private Enterprise Numbers registry 3150 http://www.iana.org/assignments/enterprise-numbers. 3152 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 3153 Technology - Portable Operating System Interface, 3154 IEEE, 2008. 3156 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 3157 "Standard for Binary Floating-Point Arithmetic", IEEE 3158 Standard 754, August 1985. 3160 [UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report 3161 #36: Unicode Security Considerations", The Unicode 3162 Consortium, July 2012. 3164 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 3165 "Specification of the Protocol for IPFIX Mediations", 3166 draft-ietf-ipfix-mediation-protocol-05, Work in 3167 Progress, June 2013. 3169 Acknowledgments 3171 We would like to thank Ganesh Sadasivan, as well, for his significant 3172 contribution during the initial phases of the protocol specification. 3173 Additional thanks to Juergen Quittek for coordination between IPFIX 3174 and PSAMP; Nevil Brownlee, Dave Plonka, and Andrew Johnson for the 3175 thorough reviews; Randall Stewart and Peter Lei for their SCTP 3176 expertise and contributions; Martin Djernaes for the first essay on 3177 the SCTP section; Michael Behringer and Eric Vyncke for their advice 3178 and knowledge in security; Michael Tuexen for his help regarding the 3179 DTLS section; Elisa Boschi for her contribution regarding the 3180 improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff 3181 Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David 3182 Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, Sue 3183 Hares, and many more, for the technical reviews and feedback. 3184 Finally, a special mention to Adrian Farrel for his attention to 3185 management and operational aspects. 3187 Authors' Addresses 3189 Benoit Claise (Ed.) 3190 Cisco Systems, Inc. 3191 De Kleetlaan 6a b1 3192 1831 Diegem 3193 Belgium 3195 Phone: +32 2 704 5622 3196 EMail: bclaise@cisco.com 3198 Brian Trammell (Ed.) 3199 Swiss Federal Institute of Technology Zurich 3200 Gloriastrasse 35 3201 8092 Zurich 3202 Switzerland 3204 Phone: +41 44 632 70 13 3205 EMail: trammell@tik.ee.ethz.ch 3207 Paul Aitken 3208 Cisco Systems, Inc. 3209 96 Commercial Quay 3210 Commercial Street, Edinburgh EH6 6LX 3211 United Kingdom 3213 Phone: +44 131 561 3616 3214 Email: paitken@cisco.com 3216 Contributors' Addresses 3218 Stewart Bryant 3219 Cisco Systems, Inc. 3220 250, Longwater, 3221 Green Park, 3222 Reading, RG2 6GB, 3223 United Kingdom 3225 Phone: +44 (0)20 8824-8828 3226 EMail: stbryant@cisco.com 3228 Simon Leinen 3229 SWITCH 3230 Werdstrasse 2 3231 P.O. Box 3232 8021 Zurich 3233 Switzerland 3235 Phone: +41 44 268 1536 3236 EMail: simon.leinen@switch.ch 3238 Thomas Dietz 3239 NEC Europe Ltd. 3240 NEC Laboratories Europe 3241 Network Research Division 3242 Kurfuersten-Anlage 36 3243 69115 Heidelberg 3244 Germany 3246 Phone: +49 6221 4342-128 3247 EMail: Thomas.Dietz@nw.neclab.eu