idnits 2.17.1 draft-ietf-ipfix-protocol-rfc5101bis-06.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 (February 18, 2013) is 4083 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) ** 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: Normative reference to a draft: ref. 'RFC5102bis' -- 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-03 Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: August 22, 2013 February 18, 2013 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of Flow Information 10 draft-ietf-ipfix-protocol-rfc5101bis-06 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 . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 12 63 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 12 64 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 14 65 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 15 66 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 16 67 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 16 68 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 17 69 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 18 70 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 18 71 3.4.2. Options Template Record Format . . . . . . . . . . . . 21 72 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 21 73 3.4.2.2. Options Template Record Format . . . . . . . . . . 21 74 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 24 75 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 25 76 4.1. The Metering Process Statistics Options Template . . . . . 25 77 4.2. The Metering Process Reliability Statistics Options 78 Template . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 4.3. The Exporting Process Reliability Statistics Options 80 Template . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 29 82 5. Timing Considerations . . . . . . . . . . . . . . . . . . . . 29 83 5.1 IPFIX Message Header Export Time and Flow Record Time . . . 29 84 5.2 Supporting Timestamp Wraparound . . . . . . . . . . . . . . 30 85 6. Linkage with the Information Model . . . . . . . . . . . . . . 30 86 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31 87 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31 88 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31 89 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31 90 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31 91 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 31 92 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 31 93 6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 32 94 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 32 95 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 32 96 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 32 97 6.2. Reduced Size Encoding . . . . . . . . . . . . . . . . . . 33 98 7. Variable-Length Information Element . . . . . . . . . . . . . 34 99 8. Template Management . . . . . . . . . . . . . . . . . . . . . 35 100 8.1. Template Withdrawal and Redefinition . . . . . . . . . . . 36 101 8.2 Sequencing Template Management Actions . . . . . . . . . . 39 102 8.3. Additional considerations for Template Management over 103 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 8.4. Additional considerations for Template Management over 105 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 106 9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 41 107 9.1. Additional considerations for SCTP Collecting Processes . 42 108 9.2. Additional considerations for UDP Collecting Processes . . 42 109 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 43 110 10.1. Transport Compliance and Transport Usage . . . . . . . . 43 111 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 44 112 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 44 113 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 44 114 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 44 115 10.2.4. Association Establishment and Shutdown . . . . . . . 44 116 10.2.5. Failover . . . . . . . . . . . . . . . . . . . . . . 45 117 10.2.6. Streams . . . . . . . . . . . . . . . . . . . . . . . 45 118 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 119 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 46 120 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 46 121 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 46 122 10.3.4. Session Establishment and Shutdown . . . . . . . . . 46 123 10.3.5. Failover and Session Duplication . . . . . . . . . . 47 124 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 125 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 47 126 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 47 127 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 48 128 10.4.4. Connection Establishment and Shutdown . . . . . . . . 48 129 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 48 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 131 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 50 132 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 51 133 11.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 51 134 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 52 135 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 53 136 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 53 137 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 54 138 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 139 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 56 140 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 56 141 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 57 142 A.2.1. Template Set Using IANA Information Elements . . . . . 57 143 A.2.2. Template Set Using Enterprise-Specific Information 144 Elements . . . . . . . . . . . . . . . . . . . . . . . 57 145 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 59 146 A.4. Options Template Set Examples . . . . . . . . . . . . . . 60 147 A.4.1. Options Template Set Using IANA Information Elements . 60 148 A.4.2. Options Template Set Using Enterprise-Specific 149 Information . . . . . . . . . . . . . . . . . . . . . 60 150 A.4.3. Options Template Set Using an Enterprise-Specific 151 Scope . . . . . . . . . . . . . . . . . . . . . . . . 61 152 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 62 153 A.5. Variable-Length Information Element Examples . . . . . . . 63 154 A.5.1. Example of Variable-Length Information Element with 155 Length . . . . . . . . . . . . . . . . . . . . . . . . 63 156 A.5.2. Example of Variable-Length Information Element with 157 3 Octet Length Encoding . . . . . . . . . . . . . . . 63 158 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 159 Normative References . . . . . . . . . . . . . . . . . . . . . . . 64 160 Informative References . . . . . . . . . . . . . . . . . . . . . . 65 161 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 68 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 163 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 69 165 1. Introduction 167 Traffic on a data network can be seen as consisting of flows passing 168 through network elements. It is often interesting, useful, or even 169 necessary to have access to information about these flows that pass 170 through the network elements for administrative or other purposes. A 171 Collecting Process should be able to receive the flow information 172 passing through multiple network elements within the data network. 173 This requires uniformity in the method of representing the flow 174 information and the means of communicating the flows from the network 175 elements to the collection point. This document specifies a protocol 176 to achieve these requirements. This document specifies in detail the 177 representation of different flows, the additional data required for 178 flow interpretation, packet format, transport mechanisms used, 179 security concerns, etc. 181 1.1. Changes since RFC 5101 183 This document obsoletes the Proposed Standard revision of the IPFIX 184 Protocol Specification [RFC5101]. The protocol specified by this 185 document is interoperable with the protocol as specified in 186 [RFC5101]. The following changes have been made to this document with 187 respect to the previous document: 189 - All outstanding technical and editorial errata on [RFC5101] have 190 been addressed. 192 - The encoding of the dateTimeSeconds, dateTimeMilliseconds, 193 dateTimeMicroseconds, and dateTimeNanoseconds data types, and the 194 related encoding of the IPFIX Message Header Export Time field, have 195 been clarified, especially with respect to the epoch upon which the 196 timestamp data types are based. 198 - A new Section 5.2 has been added to address wraparound of these 199 timestamp data types after they overflow in 2032 - 2038 CE (common 200 era). 202 - Clarifications on encoding, especially in Section 6: all IPFIX 203 values are encoded big-endian. 205 - Template management in section 8 has been simplified and clarified: 206 the specification has been relaxed with respect to [RFC5101], 207 especially concerning potential failures in Template ID reuse. 208 Additional corner cases in template management have been addressed. 209 The new template management language is interoperable with that in 210 [RFC5101] to the extent that the behavior was defined in the prior 211 specification. 213 - Section 11.3 (Mutual Authentication) has been improved to refer to 214 current practices in TLS mutual authentication; references to 215 Punycode were removed as these are covered in [RFC6125]. 217 - Editorial improvements, including structural changes to sections 8, 218 9, and 10 to improve readability. Behavior common to all transport 219 protocols has been separated out, with exceptions per transport 220 specifically noted. All template management language (on both 221 Exporting and Collecting Processes) has been unified in section 8. 223 1.2. IPFIX Documents Overview 225 The IPFIX protocol provides network administrators with access to IP 226 flow information. The architecture for the export of measured IP 227 flow information out of an IPFIX Exporting Process to a Collecting 228 Process is defined in [RFC5470], per the requirements defined in 230 [RFC3917]. This document specifies how IPFIX Data Records and 231 Templates are carried via a number of transport protocols from IPFIX 232 Exporting Processes to IPFIX Collecting Processes. 234 Four IPFIX optimizations/extensions are currently specified: a 235 bandwidth saving method for the IPFIX protocol in [RFC5473], an 236 efficient method for exporting bidirectional flows in [RFC5103], a 237 method for the definition and export of complex data structures in 238 [RFC6313], and the specification of the Protocol for IPFIX Mediations 239 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 241 A "file-based transport" for IPFIX, which defines how IPFIX Messages 242 can be stored in files for document-based workflows and for archival 243 purposes, is given in [RFC5655]. 245 IPFIX has a formal description of IPFIX Information Elements, their 246 name, type and additional semantic information, as specified in 247 [RFC5102bis]. The registry is maintained by IANA [IPFIX-IANA]. The 248 inline export of the Information Element type information is 249 specified in [RFC5610]. 251 The framework for packet selection and reporting [RFC5474] enables 252 network elements to select subsets of packets by statistical and 253 other methods, and to export a stream of reports on the selected 254 packets to a Collector. The set of packet selection techniques 255 (Sampling, Filtering, and hashing) standardized by PSAMP is described 256 in [ RFC5475]. The PSAMP protocol [RFC5476], which uses IPFIX as 257 export protocol, specifies the export of packet information from a 258 PSAMP Exporting Process to a PSAMP Collector. Instead of exporting 259 PSAMP Packet Reports, the stream of selected packets may also serve 260 as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP 261 has a formal description of its Information Elements, their name, 262 type, and additional semantic information. The PSAMP information 263 model is defined in [RFC5477]. 265 [RFC6615] specifies a MIB module for monitoring, and [RFC6728] 266 specifies a data model for configuring and monitoring IPFIX and PSAMP 267 compliant devices using the NETCONF protocol. [RFC6727] specifies the 268 PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module 269 defined in [RFC6615]. 271 In terms of development, [RFC5153] provides guidelines for the 272 implementation and use of the IPFIX protocol, while [RFC5471] 273 provides guidelines for testing. Finally, [RFC5472] describes what 274 type of applications can use the IPFIX protocol and how they can use 275 the information provided. It furthermore shows how the IPFIX 276 framework relates to other architectures and frameworks. 278 2. Terminology 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 282 "OPTIONAL" in this document are to be interpreted as described in RFC 283 2119 [RFC2119]. 285 The definitions of the basic terms like Traffic Flow, Exporting 286 Process, Collecting Process, Observation Points, etc. are 287 semantically identical to those found in the IPFIX requirements 288 document [RFC3917]. Some of the terms have been expanded for more 289 clarity when defining the protocol. Additional terms required for 290 the protocol have also been defined. Definitions in this document 291 and in [RFC5470] are equivalent; definitions that are only relevant 292 to the IPFIX protocol only appear here. 294 The terminology summary table in Section 2.1 gives a quick overview 295 of the relationships among some of the different terms defined. 297 Observation Point 299 An Observation Point is a location in the network where packets 300 can be observed. Examples include: a line to which a probe is 301 attached, a shared medium, such as an Ethernet-based LAN, a single 302 port of a router, or a set of interfaces (physical or logical) of 303 a router. 305 Note that every Observation Point is associated with an 306 Observation Domain (defined below), and that one Observation Point 307 may be a superset of several other Observation Points. For 308 example, one Observation Point can be an entire line card. That 309 would be the superset of the individual Observation Points at the 310 line card's interfaces. 312 Observation Domain 314 An Observation Domain is the largest set of Observation Points for 315 which Flow information can be aggregated by a Metering Process. 316 For example, a router line card may be an Observation Domain if it 317 is composed of several interfaces, each of which is an Observation 318 Point. In the IPFIX Message it generates, the Observation Domain 319 includes its Observation Domain ID, which is unique per Exporting 320 Process. That way, the Collecting Process can identify the 321 specific Observation Domain from the Exporter that sends the IPFIX 322 Messages. Every Observation Point is associated with an 323 Observation Domain. It is RECOMMENDED that Observation Domain IDs 324 also be unique per IPFIX Device. 326 Traffic Flow or Flow 328 There are several definitions of the term 'flow' being used by the 329 Internet community. Within the context of IPFIX we use the 330 following definition: 332 A Flow is defined as a set of packets or frames passing an 333 Observation Point in the network during a certain time interval. 334 All packets belonging to a particular Flow have a set of common 335 properties. Each property is defined as the result of applying a 336 function to the values of: 338 1. one or more packet header fields (e.g., destination IP 339 address), transport header fields (e.g., destination port 340 number), or application header fields (e.g., RTP header 341 fields [RFC3550]). 343 2. one or more characteristics of the packet itself (e.g., 344 number of MPLS labels, etc...). 346 3. one or more of fields derived from packet treatment (e.g., 347 next hop IP address, the output interface, etc...). 349 A packet is defined as belonging to a Flow if it completely 350 satisfies all the defined properties of the Flow. 352 Note that the set of packets represented by a Flow may be empty; 353 that is, a Flow may represent zero or more packets. As sampling is 354 a packet treatment, this definition includes packets selected by a 355 sampling mechanism. 357 Flow Key 359 Each of the fields that: 361 1. belong to the packet header (e.g., destination IP address), or 363 2. are a property of the packet itself (e.g., packet length), or 365 3. are derived from packet treatment (e.g., Autonomous System 366 (AS) number), 368 and that are used to define a Flow are termed Flow Keys. 370 Flow Record 372 A Flow Record contains information about a specific Flow that was 373 observed at an Observation Point. A Flow Record contains measured 374 properties of the Flow (e.g., the total number of bytes for all 375 the Flow's packets) and usually contains characteristic properties 376 of the Flow (e.g., source IP address). 378 Metering Process 380 The Metering Process generates Flow Records. Inputs to the 381 process are packet headers, characteristics, and packet treatment 382 observed at one or more Observation Points. 384 The Metering Process consists of a set of functions that includes 385 packet header capturing, timestamping, sampling, classifying, and 386 maintaining Flow Records. 388 The maintenance of Flow Records may include creating new records, 389 updating existing ones, computing Flow statistics, deriving 390 further Flow properties, detecting Flow expiration, passing Flow 391 Records to the Exporting Process, and deleting Flow Records. 393 Exporting Process 395 The Exporting Process sends IPFIX Messages to one or more 396 Collecting Processes. The Flow Records in the Messages are 397 generated by one or more Metering Processes. 399 Exporter 401 A device that hosts one or more Exporting Processes is termed an 402 Exporter. 404 IPFIX Device 406 An IPFIX Device hosts at least one Exporting Process. It may host 407 further Exporting Processes and arbitrary numbers of Observation 408 Points and Metering Processes. 410 Collecting Process 412 A Collecting Process receives IPFIX Messages from one or more 413 Exporting Processes. The Collecting Process might process or 414 store Flow Records received within these Messages, but such 415 actions are out of scope for this document. 417 Collector 419 A device that hosts one or more Collecting Processes is termed a 420 Collector. 422 Template 424 A Template is an ordered sequence of pairs used to 425 completely specify the structure and semantics of a particular set 426 of information that needs to be communicated from an IPFIX Device 427 to a Collector. Each Template is uniquely identifiable by means 428 of a Template ID. 430 IPFIX Message 432 An IPFIX Message is a message originating at the Exporting Process 433 that carries the IPFIX records of this Exporting Process and whose 434 destination is a Collecting Process. An IPFIX Message is 435 encapsulated at the transport layer. 437 Message Header 439 The Message Header is the first part of an IPFIX Message, which 440 provides basic information about the message, such as the IPFIX 441 version, length of the message, message sequence number, etc. 443 Template Record 445 A Template Record defines the structure and interpretation of 446 fields in a Data Record. 448 Data Record 450 A Data Record is a record that contains values of the parameters 451 corresponding to a Template Record. 453 Options Template Record 455 An Options Template Record is a Template Record that defines the 456 structure and interpretation of fields in a Data Record, including 457 defining how to scope the applicability of the Data Record. 459 Set 461 A Set is a collection of records that have a similar structure, 462 prefixed by a header. In an IPFIX Message, zero or more Sets 463 follow the Message Header. There are three different types of 464 Sets: Template Set, Options Template Set, and Data Set. 466 Template Set 468 A Template Set is a collection of one or more Template Records 469 that have been grouped together in an IPFIX Message. 471 Options Template Set 473 An Options Template Set is a collection of one or more Options 474 Template Records that have been grouped together in an IPFIX 475 Message. 477 Data Set 479 A Data Set is one or more Data Records, of the same type, that are 480 grouped together in an IPFIX Message. Each Data Record is 481 previously defined by a Template Record or an Options Template 482 Record. 484 Information Element 486 An Information Element is a protocol and encoding-independent 487 description of an attribute that may appear in an IPFIX Record. 488 The base set of Information Elements making up the IPFIX 489 information model [RFC5102bis] are described in the IANA IPFIX 490 Information Element Registry [IPFIX-IANA]. The type associated 491 with an Information Element indicates constraints on what it may 492 contain and also determines the valid encoding mechanisms for use 493 in IPFIX. 495 Transport Session 497 In Stream Control Transmission Protocol (SCTP), the transport 498 session is known as the SCTP association, which is uniquely 499 identified by the SCTP endpoints [RFC4960]; in TCP, the transport 500 session is known as the TCP connection, which is uniquely 501 identified by the combination of IP addresses and TCP ports used. 502 In UDP, the transport session is known as the UDP session, which 503 is uniquely identified by the combination of IP addresses and UDP 504 ports used. 506 2.1. Terminology Summary Table 508 +------------------+---------------------------------------------+ 509 | | contents | 510 | +--------------------+------------------------+ 511 | Set | Template | Record | 512 +------------------+--------------------+------------------------+ 513 | Data Set | / | Data Record(s) | 514 +------------------+--------------------+------------------------+ 515 | Template Set | Template Record(s) | / | 516 +------------------+--------------------+------------------------+ 517 | Options Template | Options Template | / | 518 | Set | Record(s) | | 519 +------------------+--------------------+------------------------+ 521 Figure A: Terminology Summary Table 523 A Data Set is composed of Data Record(s). No Template Record is 524 included. A Template Record or an Options Template Record defines 525 the Data Record. 527 A Template Set contains only Template Record(s). 529 An Options Template Set contains only Options Template Record(s). 531 3. IPFIX Message Format 533 An IPFIX Message consists of a Message Header, followed by zero or 534 more Sets. The Sets can be any of the possible three types: Data 535 Set, Template Set, or Options Template Set. 537 The format of the IPFIX Message is shown in Figure B. 539 +----------------------------------------------------+ 540 | Message Header | 541 +----------------------------------------------------+ 542 | Set | 543 +----------------------------------------------------+ 544 | Set | 545 +----------------------------------------------------+ 546 ... 547 +----------------------------------------------------+ 548 | Set | 549 +----------------------------------------------------+ 551 Figure B: IPFIX Message Format 552 Following are some examples of IPFIX Messages: 554 1. An IPFIX Message consisting of interleaved Template, Data, and 555 Options Template Sets, shown in Figure C. Here, Template and 556 Options Template Sets are transmitted "on demand", before the 557 first Data Set they define the structure of. 559 +--------+--------------------------------------------------------+ 560 | | +----------+ +---------+ +-----------+ +---------+ | 561 |Message | | Template | | Data | | Options | | Data | | 562 | Header | | Set | | Set | ... | Template | | Set | | 563 | | | | | | | Set | | | | 564 | | +----------+ +---------+ +-----------+ +---------+ | 565 +--------+--------------------------------------------------------+ 567 Figure C: IPFIX Message, Example 1 569 2. An IPFIX Message consisting entirely of Data Sets, sent after the 570 appropriate Template Records have been defined and transmitted to 571 the Collecting Process, shown in Figure D. 573 +--------+----------------------------------------------+ 574 | | +---------+ +---------+ +---------+ | 575 |Message | | Data | | Data | | Data | | 576 | Header | | Set | ... | Set | ... | Set | | 577 | | +---------+ +---------+ +---------+ | 578 +--------+----------------------------------------------+ 580 Figure D: IPFIX Message, Example 2 582 3. An IPFIX Message consisting entirely of Template and Options 583 Template Sets, shown in Figure E. Such a message can be used to 584 define or redefine Templates and Options Templates in bulk. 586 +--------+-------------------------------------------------+ 587 | | +----------+ +----------+ +----------+ | 588 |Message | | Template | | Template | | Options | | 589 | Header | | Set | ... | Set | ... | Template | | 590 | | | | | | | Set | | 591 | | +----------+ +----------+ +----------+ | 592 +--------+-------------------------------------------------+ 594 Figure E: IPFIX Message, Example 3 596 3.1. Message Header Format 598 The format of the IPFIX Message Header is shown in Figure F. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Version Number | Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Export Time | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Sequence Number | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Observation Domain ID | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure F: IPFIX Message Header Format 614 Each Message Header field is exported in big-endian byte order. The 615 fields are defined as follows: 617 Version 619 Version of IPFIX to which this Message conforms. The value of this 620 field is 0x000a for the current version, incrementing by one the 621 version used in the NetFlow services export version 9 [RFC3954]. 623 Length 625 Total length of the IPFIX Message, measured in octets, including 626 Message Header and Set(s). 628 Export Time 630 Time at which the IPFIX Message Header leaves the Exporter, 631 expressed in seconds since the UNIX epoch of 1 January 1970 at 632 00:00 UTC, encoded as an unsigned 32-bit integer. 634 Sequence Number 636 Incremental sequence counter modulo 2^32 of all IPFIX Data Records 637 sent in the current stream from the current Observation Domain by 638 the Exporting Process. Each SCTP Stream counts sequence numbers 639 separately, while all messages in a TCP connection or UDP 640 transport session are considered to be part of the same stream. 641 This value SHOULD be used by the Collecting Process to identify 642 whether any IPFIX Data Records have been missed. Template and 643 Options Template Records do not increase the Sequence Number. 645 Observation Domain ID 647 A 32-bit identifier of the Observation Domain that is locally 648 unique to the Exporting Process. The Exporting Process uses the 649 Observation Domain ID to uniquely identify to the Collecting 650 Process the Observation Domain that metered the Flows. It is 651 RECOMMENDED that this identifier also be unique per IPFIX Device. 652 Collecting Processes SHOULD use the Transport Session and the 653 Observation Domain ID field to separate different export streams 654 originating from the same Exporter. The Observation Domain ID 655 SHOULD be 0 when no specific Observation Domain ID is relevant for 656 the entire IPFIX Message, for example, when exporting the 657 Exporting Process Statistics, or in case of a hierarchy of 658 Collectors when aggregated Data Records are exported. 660 3.2. Field Specifier Format 662 Vendors need the ability to define proprietary Information Elements, 663 because, for example, they are delivering a pre-standards product, or 664 the Information Element is, in some way, commercially sensitive. 665 This section describes the Field Specifier format for both 666 IANA-registered Information Elements [IPFIX-IANA] and enterprise- 667 specific Information Elements. 669 The Information Elements are identified by the Information Element 670 identifier. When the Enterprise bit is set to 0, the corresponding 671 Information Element appears in [IPFIX-IANA], and the Enterprise 672 Number MUST NOT be present. When the Enterprise bit is set to 1, the 673 corresponding Information Element identifier identified an 674 enterprise-specific Information Element; the Enterprise Number MUST 675 be present. An example of this is shown in Section A.2.2. 677 The Field Specifier format is shown in Figure G. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |E| Information Element ident. | Field Length | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Enterprise Number | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Figure G: Field Specifier Format 689 Where: 691 E 693 Enterprise bit. This is the first bit of the Field Specifier. If 694 this bit is zero, the Information Element Identifier identifies an 695 Information Element in [IPFIX-IANA], and the four-octet Enterprise 696 Number field MUST NOT be present. If this bit is one, the 697 Information Element identifier identifies an enterprise-specific 698 Information Element, and the Enterprise Number field MUST be 699 present. 701 Information Element identifier 703 A numeric value that represents the Information Element. Refer to 704 [IPFIX-IANA]. 706 Field Length 708 The length of the corresponding encoded Information Element, in 709 octets. Refer to [IPFIX-IANA]. The field length may be smaller 710 than that in [IPFIX-IANA] if the reduced size encoding is used 711 (see Section 6.2). The value 65535 is reserved for variable- 712 length Information Elements (see Section 7). 714 Enterprise Number 716 IANA enterprise number [PEN-IANA] of the authority defining the 717 Information Element identifier in this Template Record. 719 3.3. Set and Set Header Format 721 A Set is a generic term for a collection of records that have a 722 similar structure. There are three different types of Sets: Template 723 Sets, Options Template Sets, and Data Sets. Each of these Sets 724 consists of a Set Header and one or more records. The Set Format and 725 the Set Header Format are defined in the following sections. 727 3.3.1. Set Format 729 A Set has the format shown in Figure H. The record types can be 730 either Template Records, Options Template Records, or Data Records. 731 The record types MUST NOT be mixed within a Set. 733 +--------------------------------------------------+ 734 | Set Header | 735 +--------------------------------------------------+ 736 | record | 737 +--------------------------------------------------+ 738 | record | 739 +--------------------------------------------------+ 740 ... 741 +--------------------------------------------------+ 742 | record | 743 +--------------------------------------------------+ 744 | Padding (opt.) | 745 +--------------------------------------------------+ 747 Figure H: Set Format 749 Set Header 751 The Set Header Format is defined in Section 3.3.2. 753 Record 755 One of the record Formats: Template Record, Options Template 756 Record, or Data Record Format. 758 Padding 760 The Exporting Process MAY insert some padding octets, so that the 761 subsequent Set starts at an aligned boundary. For security 762 reasons, the padding octet(s) MUST be composed of zero (0) valued 763 octets. The padding length MUST be shorter than any allowable 764 record in this Set. If padding of the IPFIX Message is desired in 765 combination with very short records, then the padding Information 766 Element 'paddingOctets' can be used for padding records such that 767 their length is increased to a multiple of 4 or 8 octets. Because 768 Template Sets are always 4-octet aligned by definition, padding is 769 only needed in case of other alignments e.g., on 8-octet 770 boundaries. 772 3.3.2. Set Header Format 774 Every Set contains a common header. This header is defined in Figure 775 I. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Set ID | Length | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Figure I: Set Header Format 785 Each Set Header field is exported in big-endian format. The fields 786 are defined as follows: 788 Set ID 790 Identifies the Set. A value of 2 is reserved for Template Sets. 791 A value of 3 is reserved for Options Template Sets. Values from 4 792 to 255 are reserved for future use. Values 256 and above are used 793 for Data Sets. The Set ID values of 0 and 1 are not used, for 794 historical reasons [RFC3954]. 796 Length 798 Total length of the Set, in octets, including the Set Header, all 799 records, and the optional padding. Because an individual Set MAY 800 contain multiple records, the Length value MUST be used to 801 determine the position of the next Set. 803 3.4. Record Format 805 IPFIX defines three record formats, defined in the next sections: the 806 Template Record Format, the Options Template Record Format, and the 807 Data Record Format. 809 3.4.1. Template Record Format 811 One of the essential elements in the IPFIX record format is the 812 Template Record. Templates greatly enhance the flexibility of the 813 record format because they allow the Collecting Process to process 814 IPFIX Messages without necessarily knowing the interpretation of all 815 Data Records. A Template Record contains any combination of 816 IANA-assigned and/or enterprise-specific Information Element 817 identifiers. 819 The format of the Template Record is shown in Figure J. It consists 820 of a Template Record Header and one or more Field Specifiers. The 821 definition of the Field Specifiers is given in Figure G above. 823 +--------------------------------------------------+ 824 | Template Record Header | 825 +--------------------------------------------------+ 826 | Field Specifier | 827 +--------------------------------------------------+ 828 | Field Specifier | 829 +--------------------------------------------------+ 830 ... 831 +--------------------------------------------------+ 832 | Field Specifier | 833 +--------------------------------------------------+ 835 Figure J: Template Record Format 837 The format of the Template Record Header is shown in Figure K. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Template ID (> 255) | Field Count | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 Figure K: Template Record Header Format 847 The Template Record Header Field Definitions are as follows: 849 Template ID 851 Each Template Record is given a unique Template ID in the range 852 256 to 65535. This uniqueness is local to the Transport Session 853 and Observation Domain that generated the Template ID. Since 854 Template IDs are used as Set IDs in the Sets they describe (see 855 section 3.4.3), values 0-255 are reserved for special Set types 856 (e.g. Template Sets themselves), and Templates and Options 857 Templates (see section 3.4.2) cannot share Template IDs within a 858 Transport Session and Observation Domain. There are no constraints 859 regarding the order of the Template ID allocation. As Exporting 860 Processes are free to allocate Template IDs as they see fit, 861 Collecting Processes MUST NOT assume incremental Template IDs, or 862 anything about the contents of a Template based on its Template ID 863 alone. 865 Field Count 867 Number of fields in this Template Record. 869 The example in Figure L shows a Template Set with mixed IANA-assigned 870 and enterprise-specific Information Elements. It consists of a Set 871 Header, a Template Header, and several Field Specifiers. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Set ID = 2 | Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Template ID = 256 | Field Count = N | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 |1| Information Element id. 1.1 | Field Length 1.1 | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Enterprise Number 1.1 | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 |0| Information Element id. 1.2 | Field Length 1.2 | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | ... | ... | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |1| Information Element id. 1.N | Field Length 1.N | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Enterprise Number 1.N | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Template ID = 257 | Field Count = M | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |0| Information Element id. 2.1 | Field Length 2.1 | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 |1| Information Element id. 2.2 | Field Length 2.2 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Enterprise Number 2.2 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | ... | ... | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |1| Information Element id. 2.M | Field Length 2.M | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Enterprise Number 2.M | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Padding (opt) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Figure L: Template Set Example 911 Information Element Identifiers 1.2 and 2.1 appear in [IPFIX-IANA] 912 (Enterprise bit = 0) and, therefore, do not need an Enterprise Number 913 to identify them. 915 3.4.2. Options Template Record Format 917 Thanks to the notion of scope, The Options Template Record gives the 918 Exporter the ability to provide additional information to the 919 Collector that would not be possible with Flow Records alone. 921 See Section 4 for specific Options Templates used for reporting 922 metadata about IPFIX Exporting and Metering Processes. 924 3.4.2.1. Scope 926 The scope, which is only available in the Options Template Set, gives 927 the context of the reported Information Elements in the Data 928 Records. 930 The scope is one or more Information Elements, specified in the 931 Options Template Record. Collecting Processes SHOULD support as 932 scope, at minimum, the observationDomainId, exportingProcessId, 933 meteringProcessId, templateId, lineCardId, exporterIPv4Address, 934 exporterIPv6Address, and ingressInterface Information Elements. The 935 IPFIX protocol doesn't prevent the use of any Information Elements 936 for scope. However, some Information Element types don't make sense 937 if specified as scope; for example, the counter Information Elements. 939 The IPFIX Message Header already contains the Observation Domain ID. 940 If not zero, this Observation Domain ID can be considered as an 941 implicit scope for the Data Records in the IPFIX Message. 943 Multiple Scope Fields MAY be present in the Options Template Record, 944 in which case, the composite scope is the combination of the scopes. 945 For example, if the two scopes are meteringProcessId and templateId, 946 the combined scope is this Template for this Metering Process. If a 947 different order of Scope Fields would result in a Record having a 948 different semantic meaning, then the order of Scope Fields MUST be 949 preserved by the Exporting Process. For example, in the context of 950 PSAMP [RFC5476], if the first scope defines the filtering function, 951 while the second scope defines the sampling function, the order of 952 the scope is important. Applying the sampling function first, 953 followed by the filtering function, would lead to potentially 954 different Data Records than applying the filtering function first, 955 followed by the sampling function. 957 3.4.2.2. Options Template Record Format 959 An Options Template Record contains any combination of IANA-assigned 960 and/or enterprise-specific Information Element identifiers. 962 The format of the Options Template Record is shown in Figure M. It 963 consists of an Options Template Record Header and one or more Field 964 Specifiers. The definition of the Field Specifiers is given in 965 Figure G above. 967 +--------------------------------------------------+ 968 | Options Template Record Header | 969 +--------------------------------------------------+ 970 | Field Specifier | 971 +--------------------------------------------------+ 972 | Field Specifier | 973 +--------------------------------------------------+ 974 ... 975 +--------------------------------------------------+ 976 | Field Specifier | 977 +--------------------------------------------------+ 979 Figure M: Options Template Record Format 981 The format of the Options Template Record Header is shown in Figure 982 N. 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Template ID (> 255) | Field Count | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Scope Field Count | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 Figure N: Options Template Record Header Format 994 The Options Template Record Header Field Definitions are as follows: 996 Template ID 998 Each Options Template Record is given a unique Template ID in the 999 range 256 to 65535. This uniqueness is local to the Transport 1000 Session and Observation Domain that generated the Template ID. 1001 Since Template IDs are used as Set IDs in the sets they describe 1002 (see section 3.4.3), values 0-255 are reserved for special Set 1003 types (e.g. Template Sets themselves), and Templates and Options 1004 Templates cannot share Template IDs within a Transport Session and 1005 Observation Domain. There are no constraints regarding the order 1006 of the Template ID allocation. As Exporting Processes are free to 1007 allocate Template IDs as they see fit, Collecting Processes MUST 1008 NOT assume incremental Template IDs, or anything about the 1009 contents of an Options Template based on its Template ID alone. 1011 Field Count 1013 Number of all fields in this Options Template Record, including 1014 the Scope Fields. 1016 Scope Field Count 1018 Number of scope fields in this Options Template Record. The Scope 1019 Fields are normal Fields except that they are interpreted as scope 1020 at the Collector. A scope field count of N specifies that the 1021 first N Field Specifiers in the Template Record are Scope Fields. 1022 The Scope Field Count MUST NOT be zero. 1024 The example in Figure O shows an Options Template Set with mixed 1025 IANA-assigned and enterprise-specific Information Elements. It 1026 consists of a Set Header, a Options Template Header, and several 1027 Field Specifiers. 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Set ID = 3 | Length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Template ID = 258 | Field Count = N + M | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Scope 2 Field Length | ... | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | ... |1| Scope N Infor. Element Id. | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Scope N Field Length | Scope N Enterprise Number ... 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Option 1 Field Length | Option 1 Enterprise Number ... 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 ... Option 1 Enterprise Number | ... | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | ... |0| Option M Infor. Element Id. | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Option M Field Length | Padding (optional) | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Figure O: Options Template Set Example 1059 3.4.3. Data Record Format 1061 The Data Records are sent in Data Sets. The format of the Data 1062 Record is shown in Figure P. It consists only of one or more Field 1063 Values. The Template ID to which the Field Values belong is encoded 1064 in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 1066 +--------------------------------------------------+ 1067 | Field Value | 1068 +--------------------------------------------------+ 1069 | Field Value | 1070 +--------------------------------------------------+ 1071 ... 1072 +--------------------------------------------------+ 1073 | Field Value | 1074 +--------------------------------------------------+ 1076 Figure P: Data Record Format 1078 Note that Field Values do not necessarily have a length of 16 bits. 1079 Field Values are encoded according to their data type specified in 1080 [RFC5102bis]. 1082 Interpretation of the Data Record format can be done only if the 1083 Template Record corresponding to the Template ID is available at the 1084 Collecting Process. 1086 The example in Figure Q shows a Data Set. It consists of a Set Header 1087 and several Field Values. 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Set ID = Template ID | Length | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Record 1 - Field Value 3 | ... | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Record 2 - Field Value 3 | ... | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Record 3 - Field Value 3 | ... | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | ... | Padding (optional) | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Figure Q: Data Set, containing Data Records 1111 4. Specific Reporting Requirements 1113 Some specific Options Templates and Options Template Records are 1114 necessary to provide extra information about the Flow Records and 1115 about the Metering Process. 1117 The Options Template and Options Template Records defined in these 1118 subsections, which impose some constraints on the Metering Process 1119 and Exporting Process implementations, MAY be implemented. If 1120 implemented, the specific Options Templates SHOULD be implemented as 1121 specified in these subsections. 1123 The minimum set of Information Elements is always specified in these 1124 Specific IPFIX Options Templates. Nevertheless, extra Information 1125 Elements may be used in these specific Options Templates. 1127 The Collecting Process MUST check the possible combinations of 1128 Information Elements within the Options Template Records to correctly 1129 interpret the following Options Templates. 1131 4.1. The Metering Process Statistics Options Template 1133 The Metering Process Statistics Options Template specifies the 1134 structure of a Data Record for reporting Metering Process statistics. 1135 It SHOULD contain the following Information Elements; see [IPFIX- 1136 IANA] for their definitions 1137 (scope) observationDomainId 1138 This Information Element MUST be defined as a 1139 Scope Field, and MUST be present unless the 1140 Observation Domain ID of the enclosing 1141 Message is non-zero. 1143 (scope) meteringProcessId 1144 If present, this Information Element MUST be 1145 defined as a Scope Field. 1147 exportedMessageTotalCount 1149 exportedFlowRecordTotalCount 1151 exportedOctetTotalCount 1153 The Exporting Process SHOULD export the Data Record specified by the 1154 Metering Process Statistics Options Template on a regular basis or 1155 based on some export policy. This periodicity or export policy 1156 SHOULD be configurable. 1158 Note that if several Metering Processes are available on the Exporter 1159 Observation Domain, the Information Element meteringProcessId MUST be 1160 specified as an additional Scope Field. 1162 4.2. The Metering Process Reliability Statistics Options Template 1164 The Metering Process Reliability Options Template specifies the 1165 structure of a Data Record for reporting lack of reliability in the 1166 Metering Process. It SHOULD contain the following Information 1167 Elements defined in [IPFIX-IANA]: 1169 (scope) observationDomainId 1170 This Information Element MUST be defined as a 1171 Scope Field, and MUST be present unless the 1172 Observation Domain ID of the enclosing 1173 Message is non-zero. 1175 (scope) meteringProcessId 1176 If present, this Information Element MUST be 1177 defined as a Scope Field. 1179 ignoredPacketTotalCount 1181 ignoredOctetTotalCount 1182 time first packet ignored 1183 The timestamp of the first packet that was 1184 ignored by the Metering Process. For this 1185 timestamp, any of the following timestamp 1186 Information Elements can be used: 1187 observationTimeSeconds, 1188 observationTimeMilliseconds, 1189 observationTimeMicroseconds, or 1190 observationTimeNanoseconds. 1192 time last packet ignored 1193 The timestamp of the last packet that was 1194 ignored by the Metering Process. For this 1195 timestamp, any of the following timestamp 1196 Information Elements can be used: 1197 observationTimeSeconds, 1198 observationTimeMilliseconds, 1199 observationTimeMicroseconds, or 1200 observationTimeNanoseconds. 1202 The Exporting Process SHOULD export the Data Record specified by the 1203 Metering Process Reliability Statistics Options Template on a regular 1204 basis or based on some export policy. This periodicity or export 1205 policy SHOULD be configurable. 1207 Note that if several Metering Processes are available on the Exporter 1208 Observation Domain, the Information Element meteringProcessId MUST be 1209 specified as an additional Scope Field. 1211 Since the Metering Process Reliability Option Template contains two 1212 identical timestamp Information Elements, and since the order of the 1213 Information Elements in the Template Records is not guaranteed, the 1214 Collecting Process interprets the time interval of ignored packets as 1215 the range between the two values; see Section 5.2 for wraparound 1216 considerations. 1218 4.3. The Exporting Process Reliability Statistics Options Template 1220 The Exporting Process Reliability Options Template specifies the 1221 structure of a Data Record for reporting lack of reliability in the 1222 Exporting Process. It SHOULD contain the following Information 1223 Elements defined in [IPFIX-IANA]: 1225 (scope) Exporting Process ID 1226 The identifier of the Exporting Process for 1227 which reliability is reported. Any of the 1228 exporterIPv4Address, exporterIPv6Address, or 1229 exportingProcessId Information Elements can be 1230 used for this field. This Information Element 1231 MUST be defined as a Scope Field. 1233 notSentFlowTotalCount 1235 notSentPacketTotalCount 1237 notSentOctetTotalCount 1239 time first flow dropped 1240 The time at which the first Flow Record was 1241 dropped by the Exporting Process. For this 1242 timestamp, any of the following timestamp can be 1243 used: observationTimeSeconds, 1244 observationTimeMilliseconds, 1245 observationTimeMicroseconds, or 1246 observationTimeNanoseconds. 1248 time last flow dropped 1249 The time at which the last Flow Record was 1250 dropped by the Exporting Process. For this 1251 timestamp, any of the following timestamp can be 1252 used: observationTimeSeconds, 1253 observationTimeMilliseconds, 1254 observationTimeMicroseconds, or 1255 observationTimeNanoseconds. 1257 The Exporting Process SHOULD export the Data Record specified by the 1258 Exporting Process Reliability Statistics Options Template on a 1259 regular basis or based on some export policy. This periodicity or 1260 export policy SHOULD be configurable. 1262 Since the Exporting Process Reliability Option Template contains two 1263 identical timestamp Information Elements, and since the order of the 1264 Information Elements in the Template Records is not guaranteed, the 1265 Collecting Process interprets the time interval of ignored packets as 1266 the range between the two values; see Section 5.2 for wraparound 1267 considerations. 1269 4.4. The Flow Keys Options Template 1271 The Flow Keys Options Template specifies the structure of a Data 1272 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1273 Data Record extends a particular Template Record that is referenced 1274 by its templateId identifier. The Template Record is extended by 1275 specifying which of the Information Elements contained in the 1276 corresponding Data Records describe Flow properties that serve as 1277 Flow Keys of the reported Flow. 1279 The Flow Keys Options Template SHOULD contain the following 1280 Information Elements that are defined in [IPFIX-IANA]: 1282 (scope) templateId This Information Element MUST be defined as a 1283 Scope Field. 1285 flowKeyIndicator 1287 5. Timing Considerations 1289 5.1 IPFIX Message Header Export Time and Flow Record Time 1291 The IPFIX Message Header Export Time field is the time at which the 1292 IPFIX Message Header leaves the Exporter, using the same encoding as 1293 the dateTimeSeconds abstract data type [RFC5102bis], i.e., expressed 1294 in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded 1295 as an unsigned 32-bit integer. 1297 Certain time-related Information Elements may be expressed as an 1298 offset from this Export Time. For example, Data Records requiring a 1299 microsecond precision can export the flow start and end times with 1300 the flowStartMicroseconds and flowEndMicroseconds Information 1301 Elements, which encode the absolute time in microseconds in terms of 1302 the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An 1303 alternate solution is to export the flowStartDeltaMicroseconds and 1304 flowEndDeltaMicroseconds Information Elements in the Data Record, 1305 which respectively report the flow start and end time as negative 1306 offsets from the Export Time, as an unsigned 32-bit integer. This 1307 latter solution lowers the export bandwidth requirement, saving four 1308 bytes per timestamp, while increasing the load on the Exporter, as 1309 the Exporting Process must calculate the flowStartDeltaMicroseconds 1310 and flowEndDeltaMicroseconds of every single Data Record before 1311 exporting the IPFIX Message. 1313 It must be noted that timestamps based on the Export Time impose some 1314 time constraints on the Data Records contained within the IPFIX 1315 Message. In the example of flowStartDeltaMicroseconds and 1316 flowEndDeltaMicroseconds Information Elements, the Data Record can 1317 only contain records with timestamps within 71 minutes of the Export 1318 Time. Otherwise, the 32-bit counter would not be sufficient to 1319 contain the flow start time offset. 1321 5.2 Supporting Timestamp Wraparound 1323 The dateTimeSeconds abstract data type [RFC5102bis] and the Export 1324 Time Message Header field (Section 3.1) are encoded as 32-bit 1325 unsigned integers, expressed as seconds since the UNIX epoch, 1 1326 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will 1327 wrap around on 7 February 2106 at 06:28:16 UTC. 1329 In order to support continued use of the IPFIX Protocol beyond this 1330 date, Exporting Processes SHOULD export dateTimeSeconds values and 1331 the Export Time Message Header field as the number of seconds since 1332 the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting 1333 Processes SHOULD use the current date, or other contextual 1334 information, to properly interpret dateTimeSeconds values and the 1335 Export Time Message Header field. 1337 There are similar considerations for the NTP-based 1338 dateTimeMicroseconds and dateTimeNanoseconds abstract data types 1339 [RFC5102bis]. Exporting Processes SHOULD export dateTimeMicroseconds 1340 and dateTimeNanoseconds values as if the NTP Era [RFC5905] is 1341 implicit; Collecting Processes SHOULD use the current date, or other 1342 contextual information, to determine the NTP Era in order to properly 1343 interpret dateTimeMicroseconds and dateTimeNanoseconds values in 1344 received Data Records. 1346 The dateTimeMilliseconds abstract data type will wrap around in 1347 approximately 500 billion years; the specification of the behavior of 1348 this abstract data type after that time is left as a subject of a 1349 future revision of this specification. 1351 The long-term storage of files [RFC5655] for archival purposes is 1352 affected by timestamp wraparound, as the use of the current date to 1353 interpret timestamp values in files stored on the order of multiple 1354 decades in the past may lead to incorrect values; therefore, it is 1355 RECOMMENDED that such files be stored with contextual information to 1356 assist in the interpretation of these timestamps. 1358 6. Linkage with the Information Model 1360 As with values in the IPFIX Message Header and Set Header, values of 1361 all Information Elements [RFC5102bis], except for those of the string 1362 and octetArray data types, are encoded in canonical format in network 1363 byte order (also known as big-endian byte ordering). 1365 6.1. Encoding of IPFIX Data Types 1367 The following sections define the encoding of the data types 1368 specified in [RFC5102bis]. 1370 6.1.1. Integral Data Types 1372 Integral data types -- octet, signed8, unsigned16, signed16, 1373 unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded 1374 using the default canonical format in network byte order. Signed 1375 Integral data types are represented in two's complement notation. 1377 6.1.2. Address Types 1379 Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be 1380 encoded the same way as the integral data types, as six, four, and 1381 sixteen octets in network byte order, respectively. 1383 6.1.3. float32 1385 The float32 data type MUST be encoded as an IEEE single-precision 1386 32-bit floating point-type, as specified in [IEEE.754.1985], in 1387 network byte order. 1389 6.1.4. float64 1391 The float64 data type MUST be encoded as an IEEE double-precision 64- 1392 bit floating point-type, as specified in [IEEE.754.1985], in network 1393 byte order. 1395 6.1.5. boolean 1397 The boolean data type is specified according to the TruthValue in 1398 [RFC2579]. It is encoded as a single-octet integer, as in Section 1399 6.1.1., with the value 1 for true and a value 2 for false. Every 1400 other value is undefined. 1402 6.1.6. string and octetArray 1404 The data type string represents a finite length string of valid 1405 characters of the Unicode character encoding set. The string data 1406 type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as 1407 an array of zero or more octets using an Information Element of fixed 1408 or variable length. IPFIX Exporting Processes MUST NOT send IPFIX 1409 Messages containing ill-formed UTF-8 string values for Information 1410 Elements of the string data type; Collecting Processes SHOULD detect 1411 and ignore such values. See [UTF8-EXPLOIT] for background on this 1412 issue. 1414 The data type octetArray has no encoding rules; it represents a raw 1415 array of zero or more octets, with the interpretation of the octets 1416 defined in the Information Element definition. 1418 6.1.7. dateTimeSeconds 1420 The data type dateTimeSeconds is an unsigned 32-bit integer in 1421 network byte order containing the number of seconds since the UNIX 1422 epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 1423 dateTimeSeconds is encoded identically to the IPFIX Message Header 1424 Export Time field. It can represent dates between 1 January 1970 and 1425 7 February 2106 without wraparound; see section 5.2 for wraparound 1426 considerations. 1428 6.1.8. dateTimeMilliseconds 1430 The data type dateTimeMilliseconds is an unsigned 64-bit integer in 1431 network byte order, containing the number of milliseconds since the 1432 UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It 1433 can represent dates beginning on 1 January 1970 for approximately the 1434 next 500 billion years without wraparound. 1436 6.1.9 dateTimeMicroseconds 1438 The data type dateTimeMicroseconds is a 64-bit field encoded 1439 according to the NTP Timestamp format as defined in section 6 of 1440 [RFC5905]. This field is made up of two unsigned 32-bit integers in 1441 network byte order, Seconds and Fraction. The Seconds field is the 1442 number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. 1443 The Fraction field is the fractional number of seconds in units of 1444 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1445 dates beginning between 1 January 1900 and 8 February 2036 in the 1446 current NTP Era; see section 5.2 for wraparound considerations. 1448 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1449 identical encoding. The dateTimeMicroseconds data type is intended 1450 only to represent timestamps of microsecond precision. Therefore, the 1451 bottom 11 bits of the fraction field SHOULD be zero and MUST be 1452 ignored for all Information Elements of this data type (as 2^11 x 233 1453 picoseconds = .477 microseconds). 1455 6.1.10 dateTimeNanoseconds 1457 The data type dateTimeNanoseconds is a 64-bit field encoded according 1458 to the NTP Timestamp format as defined in section 6 of [RFC5905]. 1459 This field is made up of two unsigned 32-bit integers in network byte 1460 order, Seconds and Fraction. The Seconds field is the number of 1461 seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The 1462 Fraction field is the fractional number of seconds in units of 1463 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1464 dates beginning between 1 January 1900 and 8 February 2036 in the 1465 current NTP Era; see section 5.2 for wraparound considerations. 1467 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1468 identical encoding. There is no restriction on the interpretation of 1469 the Fraction field for the dateTimeNanoseconds data type. 1471 6.2. Reduced Size Encoding 1473 Information Elements encoded as signed, unsigned, or float data types 1474 MAY be encoded using fewer octets than those implied by their type in 1475 the information model definition, based on the assumption that the 1476 smaller size is sufficient to carry any value the Exporter may need 1477 to deliver. This reduces the network bandwidth requirement between 1478 the Exporter and the Collector. Note that the Information Element 1479 definitions [IPFIX-IANA] always define the maximum encoding size. 1481 For instance, the information model defines octetDeltaCount as an 1482 unsigned64 type, which would require 64 bits. However, if the 1483 Exporter will never locally encounter the need to send a value larger 1484 than 4294967295, it may chose to send the value instead as an 1485 unsigned32. 1487 This behavior is indicated by the Exporter by specifying a size in 1488 the Template with a smaller length than that associated with the 1489 assigned type of the Information Element. In the example above, the 1490 Exporter would place a length of 4 versus 8 in the Template. 1492 Reduced size encoding MAY be be applied to the following integer 1493 types: unsigned64, signed64, unsigned32, signed32, unsigned16, and 1494 signed16. The signed versus unsigned property of the reported value 1495 MUST be preserved. The reduction in size can be to any number of 1496 octets smaller than the original type if the data value still fits, 1497 i.e., so that only leading zeroes are dropped. For example, an 1498 unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). 1500 Reduced size encoding MAY be used to reduce float64 to float32. The 1501 float32 not only has a reduced number range, but due to the smaller 1502 mantissa, is also less precise. In this case, the float64 would be 1503 reduced in size to 4 octets. 1505 Reduced size encoding MUST NOT be applied to any other data type 1506 defined in [RFC5102bis] that implies a fixed length, as these types 1507 either have internal structure (such as ipv4Address or 1508 dateTimeMicroseconds) or restricted ranges that are not suitable for 1509 reduced length encoding (such as dateTimeMilliseconds). 1511 Information Elements of type octetArray and string may be exported 1512 using any length, subject to restrictions on length specific to each 1513 Information Element, as noted in that Information Element's 1514 description. 1516 7. Variable-Length Information Element 1518 The IPFIX Template mechanism is optimized for fixed-length 1519 Information Elements [RFC5102bis]. Where an Information Element has 1520 a variable length, the following mechanism MUST be used to carry the 1521 length information for both the IANA and enterprise-specific 1522 Information Elements. 1524 In the Template Set, the Information Element Field Length is recorded 1525 as 65535. This reserved length value notifies the Collecting Process 1526 that length of the Information Element will be carried in the 1527 Information Element content itself. 1529 In most cases, the length of the Information Element will be less 1530 than 255 octets. The following length-encoding mechanism optimizes 1531 the overhead of carrying the Information Element length in this 1532 majority case. The length is carried in the octet before the 1533 Information Element, as shown in Figure R. 1535 0 1 2 3 1536 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 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Length (< 255)| Information Element | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | ... continuing as needed | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Figure R: Variable-Length Information Element (length < 255 octets) 1545 The length may also be encoded into 3 octets before the Information 1546 element allowing the length of the Information Element to be greater 1547 than or equal to 255 octets. In this case, first octet of the Length 1548 field MUST be 255, and the length is carried in the second and third 1549 octets, as shown in Figure S. 1551 0 1 2 3 1552 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 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | 255 | Length (0 to 65535) | IE | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | ... continuing as needed | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Figure S: Variable-Length Information Element (length 0 to 65535 1560 octets) 1562 The octets carrying the length (either the first or the first three 1563 octets) MUST NOT be included in the length of the Information 1564 Element. 1566 8. Template Management 1568 This section describes the management of Templates and Options 1569 Templates at the Exporting and Collecting Processes. The goal of 1570 Template management is to ensure, to the extent possible, that the 1571 Exporting Process and Collecting Process have a consistent view of 1572 the Templates and Options Templates used to encode and decode the 1573 Records sent from the Exporting Process to the Collecting Process. 1574 Achieving this goal is complicated somewhat by two factors: 1. the 1575 need to support the reuse of Template IDs within a Transport Session 1576 and 2. the need to support unreliable transmission for Templates when 1577 UDP is used as the transport protocol for IPFIX Messages. 1579 The Template Management mechanisms defined in this section apply to 1580 IPFIX Messages export on SCTP, TCP, or UDP. Additional considerations 1581 specific to SCTP and UDP transport are given in sections 8.3 and 8.4, 1582 respectively. 1584 The Exporting Process assigns and maintains Template IDs per 1585 Transport Session and Observation Domain. A newly created Template 1586 Record is assigned an unused Template ID by the Exporting Process. 1587 The Collecting Process MUST store all received Template Record 1588 information for the duration of each Transport Session until reuse or 1589 withdrawal as in section 8.1, or expiry over UDP as in section 8.4, 1590 so that it can interpret the corresponding Data Records. 1592 The Collecting Process MUST NOT assume that the Template IDs from a 1593 given Exporting Process refer to the same Templates as they did in 1594 previous Transport Sessions from the same Exporting Process; a 1595 Collecting Process MUST NOT use Templates from one Transport Session 1596 to decode Data Sets in a subsequent Transport Session. 1598 If a specific Information Element is required by a Template, but is 1599 not present in observed packets, the Exporting Process MAY choose to 1600 export Flow Records without this Information Element in a Data Record 1601 described by a new Template. 1603 If an Information Element is required more than once in a Template, 1604 the different occurrences of this Information Element SHOULD follow 1605 the logical order of their treatments by the Metering Process. For 1606 example, if a selected packet goes through two hash functions, and if 1607 the two hash values are sent within a single Template, the first 1608 occurrence of the hash value should belong to the first hash function 1609 in the Metering Process. For example, when exporting the two source 1610 IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address 1611 Information Element occurrence should be the IPv4 address of the 1612 outer header, while the second occurrence should be the address of 1613 the inner header. Collecting Processes MUST properly handle Templates 1614 with multiple identical Information Elements. 1616 The Exporting Process SHOULD transmit the Template Set and Options 1617 Template Set in advance of any Data Sets that use that (Options) 1618 Template ID, to help ensure that the Collector has the Template 1619 Record before receiving the first Data Record. Data Records that 1620 correspond to a Template Record MAY appear in the same and/or 1621 subsequent IPFIX Message(s). However, a Collecting Process MUST NOT 1622 assume that the Data Set and the associated Template Set (or Options 1623 Template Set) are exported in the same IPFIX Message. 1625 Though a Collecting Process normally receives Template Records from 1626 the Exporting Process before receiving Data Records, this is not 1627 always the case, e.g. in case of reordering or Collecting Process 1628 restart over UDP. In these cases, the Collecting Process MAY buffer 1629 Data Records for which it has no Templates to wait for Template 1630 Records describing them; however, note that in the presence of 1631 Template withdrawal and redefinition (Section 8.1) this may lead to 1632 incorrect interpretation of Data Records. 1634 Different Observation Domains within a Transport Session MAY use the 1635 same Template ID value to refer to different Templates; Collecting 1636 Processes MUST properly handle this case. 1638 Options Templates and Templates which are related or interdependent 1639 (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent 1640 together in the same IPFIX Message. 1642 8.1. Template Withdrawal and Redefinition 1644 Templates that will not be used further by an Exporting Process MAY 1645 be withdrawn by sending a Template Withdrawal. After receiving a 1646 Template Withdrawal, a Collecting Process MUST stop using the 1647 Template to interpret subsequently-exported Data Sets. Note that this 1648 mechanism does not apply when UDP is used to transport IPFIX 1649 Messages; for this case, see Section 8.4. 1651 A Template Withdrawal consists of a Template Record for the Template 1652 ID to be withdrawn, with a Field Count of 0. The format of a Template 1653 Withdrawal is shown in Figure T. 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Set ID = (2 or 3) | Length = 16 | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | Template ID N | Field Count = 0 | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Template ID ... | Field Count = 0 | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Template ID M | Field Count = 0 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 Figure T: Template Withdrawal Format 1669 The Set ID field MUST contain the value 2 for Template Set Withdrawal 1670 and the value 3 for Options Template Set Withdrawal. Multiple 1671 Template IDs MAY be withdrawn with a single Template Withdrawal, in 1672 that case, padding MAY be used. 1674 Template Withdrawals MAY appear interleaved with Template Sets, 1675 Options Template Sets, and Data Sets within an IPFIX Message. In this 1676 case, the Templates and Template Withdrawals shall be taken to take 1677 effect in the order in which they appear in the IPFIX Message. An 1678 Exporting Process SHOULD NOT send a Template Withdrawal until 1679 sufficient time has elapsed to allow receipt and processing of any 1680 Data Records described by the withdrawn Templates; see Section 8.2 on 1681 sequencing of Template management actions. 1683 The end of a Transport Session implicitly withdraws all the Templates 1684 used within the Transport Session, and Templates must be resent 1685 during subsequent Transport Sessions between an Exporting Process and 1686 Collecting Process. This applies to SCTP and TCP only; see sections 1687 8.4 and 10.3.4 for a discussion of Transport Session and Template 1688 lifetime over UDP. 1690 All Templates for a given Observation Domain MAY also be withdrawn 1691 using an All Templates Withdrawal, shown in Figure U. All Options 1692 Templates for a given Observation Domain MAY likewise be withdrawn 1693 using an All Options Templates Withdrawal, shown in Figure 3. 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Set ID = 2 | Length = 8 | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Template ID = 2 | Field Count = 0 | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 Figure U: All Templates Withdrawal Set Format 1705 0 1 2 3 1706 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 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Set ID = 3 | Length = 8 | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Template ID = 3 | Field Count = 0 | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Figure V: All Options Templates Withdrawal Set Format 1715 Template IDs MAY be reused for new Templates by sending a new 1716 Template Record or Options Template Record for a given Template ID 1717 after withdrawing the Template. 1719 If a Collecting Process receives a Template Withdrawal for a Template 1720 or Options Template it does not presently have stored, this indicates 1721 a malfunctioning or improperly-implemented Exporting Process. The 1722 continued receipt and interpretation of Data Records is still 1723 possible, but it MUST ignore the Template Withdrawal and SHOULD log 1724 the error. 1726 If a Collecting Process receives a new Template Record or Options 1727 Template Record for an already-allocated Template ID, and that 1728 Template or Options Template is identical to the already-received 1729 Template or Options Template, it SHOULD log the retransmission; 1730 however, this is not an error condition, as it does not affect the 1731 interpretation of data records. 1733 If a Collecting Process receives a new Template Record or Options 1734 Template Record for an already-allocated Template ID, and that 1735 Template or Options Template is different from the already-received 1736 Template or Options Template, this indicates a malfunctioning or 1737 improperly-implemented Exporting Process. The continued receipt and 1738 unambiguous interpretation of Data Records for this Template ID is no 1739 longer possible, the Collecting Process SHOULD log the error; further 1740 Collecting Process actions are out of scope of this specification. 1742 8.2 Sequencing Template Management Actions 1744 Since there is no guarantee of the ordering of exported IPFIX 1745 Messages across SCTP Streams or over UDP, an Exporting Process MUST 1746 sequence all Template management actions (i.e., Template Records 1747 defining new Templates and Template Withdrawals withdrawing them) 1748 using the Export Time field in the IPFIX Message Header. 1750 An Exporting Process MUST NOT export a Data Set described by a new 1751 Template in an IPFIX Message with an Export Time before the Export 1752 Time of the IPFIX Message containing that Template. If a new Template 1753 and a Data Set described by it appear in the same IPFIX Message, the 1754 Template Set containing the Template MUST appear before the Data Set 1755 in the Message. 1757 An Exporting Process MUST NOT export any Data Sets described by a 1758 withdrawn Template in IPFIX Messages with an Export Time after the 1759 Export Time of the IPFIX Message containing the Template Withdrawal 1760 withdrawing that Template. 1762 Put another way, a Template describes Data Records contained in IPFIX 1763 Messages with an Export Time between the Export Time of the IPFIX 1764 Message containing the Template Record and either the Export Time of 1765 the IPFIX Message containing the Template Withdrawal withdrawing it 1766 or the end of the Transport Session, inclusive. 1768 Even if sent in-order, IPFIX Messages containing Template management 1769 actions could arrive at the Collecting Process out-of-order, i.e. if 1770 sent via UDP or via different SCTP streams. Given this, Template 1771 Withdrawals and subsequent reuse of Template IDs can significantly 1772 complicate the problem of determining Template lifetimes at the 1773 Collecting Process. A Collecting Process MAY implement a buffer and 1774 use Export Time information to disambiguate the order of Template 1775 management actions. This buffer, if implemented, SHOULD be 1776 configurable to impart a delay on the order of the maximum reordering 1777 delay experienced at the Collecting Process. Note, in this case, that 1778 the Collecting Process' clock is irrelevant: it is only comparing the 1779 Export Times of Messages to each other. 1781 8.3. Additional considerations for Template Management over SCTP 1783 The specifications in this section apply only to SCTP; in case of 1784 contradiction with specifications in Sections 8 or 8.1, this section 1785 takes precedence. 1787 Template Sets and Options Template Sets MAY be sent on any SCTP 1788 stream. Data Sets sent on a given SCTP stream MAY be represented by 1789 Template Records exported on any SCTP stream. 1791 Template Sets and Options Template Sets MUST be sent reliably, using 1792 SCTP ordered delivery. 1794 Template Withdrawals MAY be sent on any SCTP stream. Template 1795 Withdrawals MUST be sent reliably, using SCTP ordered delivery. 1796 Template IDs MAY be reused by sending a Template Withdrawal and/or a 1797 new Template Record on a different SCTP stream than the stream on 1798 which the original Template was sent. 1800 Additional Template Management considerations are given in [RFC6526], 1801 which specifies an extension to explicitly link Templates with SCTP 1802 streams. In exchange for more restrictive rules on the assignment of 1803 Template Records to SCTP streams, this extension allows fast, 1804 reliable reuse of Template IDs and estimation of Data Record loss per 1805 Template. 1807 8.4. Additional considerations for Template Management over UDP 1809 The specifications in this section apply only to UDP; in case of 1810 contradiction with specifications in Sections 8 or 8.1, this section 1811 takes precedence. 1813 Since UDP provides no method for reliable transmission of Templates, 1814 Exporting Processes using UDP as the Transport Protocol MUST 1815 periodically retransmit each active Template at regular intervals. 1816 The Template retransmission interval MUST be configurable, as via the 1817 the templateRefreshTimeout and optionsTemplateRefreshTimeout defined 1818 in [RFC6728]. Default settings for these values are deployment- and 1819 application-specific. 1821 Before exporting any Data Records described by a given Template 1822 Record or Options Template Record, especially in the case of Template 1823 ID reuse as in section 8.1, the Exporting Process SHOULD send 1824 multiple copies of the Template Record in separate IPFIX Message, in 1825 order to help ensure the Collecting Process has received it. 1827 In order to minimize resource requirements for Templates which are no 1828 longer being used by the Exporting Process, the Collecting Process 1829 MAY associate a lifetime with each Template received in a UDP 1830 Transport Session. Templates not refreshed by the Exporting Process 1831 within the lifetime can then be discarded by the Collecting Process. 1832 The Template lifetime at the Collecting Process MAY be exposed by a 1833 configuration parameter, or MAY be derived from observation of the 1834 interval of periodic Template retransmissions from the Exporting 1835 Process. In this latter case, the Template lifetime SHOULD default to 1836 at least 3 times the observed retransmission rate. 1838 Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting 1839 Processes exporting via UDP, and MUST be ignored by Collecting 1840 Processes collecting via UDP. Template IDs MAY be reused by Exporting 1841 Processes by exporting a new Template for the Template ID after 1842 waiting at least 3 times the retransmission rate. Note that Template 1843 ID reuse may lead to incorrect interpretation of Data Records if the 1844 retransmission and lifetime are not properly configured. 1846 When a Collecting Process receives a new Template Record or Options 1847 Template Record via UDP for an already-allocated Template ID, and 1848 that Template or Options Template is identical to the already- 1849 received Template or Options Template, it SHOULD NOT log the 1850 retransmission, as this is the normal operation of Template refresh 1851 over UDP. 1853 When a Collecting Process receives a new Template Record or Options 1854 Template Record for an already-allocated Template ID, and that 1855 Template or Options Template is different from the already-received 1856 Template or Options Template, the Collecting Process MUST replace the 1857 Template or Options Template for that Template ID with the newly- 1858 received Template or Options Template. This is the normal operation 1859 of Template ID reuse over UDP. 1861 As Template IDs are unique per UDP session and per Observation 1862 Domain, at any given time, the Collecting Process SHOULD maintain the 1863 following for all the current Template Records and Options Template 1864 Records: . 1868 9. The Collecting Process's Side 1870 This section describes the handling of the IPFIX Protocol at the 1871 Collecting Process common to all Transport Protocols. Additional 1872 considerations for SCTP and UDP are given in Sections 9.1 and 9.2 1873 respectively. Template management at Collecting Processes is covered 1874 in Section 8. 1876 The Collecting Process MUST listen for association requests / 1877 connections to start new Transport Sessions from the Exporting 1878 Process. 1880 The Collecting Process MUST note the Information Element identifier 1881 of any Information Element that it does not understand and MAY 1882 discard that Information Element from received Data Records. 1884 The Collecting Process MUST accept padding in Data Records and 1885 Template Records. The padding size is the Set Length minus the size 1886 of the Set Header (4 octets for the Set ID and the Set Length), 1887 modulo the Record size deduced from the Template Record. 1889 The IPFIX protocol has a Sequence Number field in the Export header 1890 that increases with the number of IPFIX Data Records in the IPFIX 1891 Message. A Collector can detect out-of-sequence, dropped, or 1892 duplicate IPFIX Messages by tracking the Sequence Number. A 1893 Collector SHOULD provide a logging mechanism for tracking out-of- 1894 sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be 1895 due to Exporter resource exhaustion where it cannot transmit messages 1896 at their creation rate, an Exporting Process reset, congestion on the 1897 network link between the Exporter and Collector, Collector resource 1898 exhaustion where it cannot process the IPFIX Messages at their 1899 arrival rate, out-of-order packet reception, duplicate packet 1900 reception, or an attacker injecting false messages. 1902 If the Collecting Process receives a malformed IPFIX Message it MUST 1903 discard the IPFIX Message and SHOULD log the error. A malformed IPFIX 1904 Message is one that cannot be interpreted due to nonsensical length 1905 values (e.g., a variable length Information Element longer than its 1906 enclosing Set, a Set longer than its enclosing IPFIX Message, an 1907 IPFIX Message shorter than an IPFIX Message Header) or a reserved 1908 Version value (which may indicate a future version of IPFIX is being 1909 used for export, but practically occurs most often when non-IPFIX 1910 data is sent to an IPFIX Collecting Process). Note that non-zero Set 1911 padding does not constitute a malformed IPFIX Message. 1913 9.1. Additional considerations for SCTP Collecting Processes 1915 As an Exporting Process may request and support more than one stream 1916 per SCTP association, the Collecting Process MUST support the opening 1917 of multiple SCTP streams. 1919 9.2. Additional considerations for UDP Collecting Processes 1921 A Transport Session for IPFIX Messages transported over UDP is 1922 defined from the point of view of the Exporting Process, and roughly 1923 corresponds to the time during which a given Exporting Process sends 1924 IPFIX Messages over UDP to a given Collecting Process. Since this is 1925 difficult to detect at the Collecting Process, the Collecting Process 1926 MAY discard all Transport Session state after no IPFIX Messages are 1927 received from a given Exporting Process within a given Transport 1928 Session during a configurable idle timeout. 1930 The Collecting Process SHOULD accept Data Records without the 1931 associated Template Record (or other definitions such as Common 1932 Properties) required to decode the Data Record. If the Template 1933 Records or other definitions have not been received at the time Data 1934 Records are received, the Collecting Process MAY store the Data 1935 Records for a short period of time and decode them after the Template 1936 Records or other definitions are received, comparing Export Times of 1937 IPFIX Messages containing the Template Records with those containing 1938 the Data Records as in Section 8.2. Note that this mechanism may lead 1939 to incorrectly interpreted records in the presence of Template ID 1940 reuse or other identifiers with limited lifetimes. 1942 10. Transport Protocol 1944 The IPFIX Protocol Specification has been designed to be transport 1945 protocol independent. Note that the Exporter can export to multiple 1946 Collecting Processes using independent transport protocols. 1948 The IPFIX Message Header 16-bit Length field limits the length of an 1949 IPFIX Message to 65535 octets, including the header. A Collecting 1950 Process MUST be able to handle IPFIX Message lengths of up to 65535 1951 octets. 1953 10.1. Transport Compliance and Transport Usage 1955 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 1956 MUST be implemented by all compliant implementations. UDP [UDP] MAY 1957 also be implemented by compliant implementations. TCP [TCP] MAY also 1958 be implemented by compliant implementations. 1960 SCTP should be used in deployments where Exporters and Collectors are 1961 communicating over links that are susceptible to congestion. SCTP is 1962 capable of providing any required degree of reliability when used 1963 with the PR-SCTP extension. 1965 TCP may be used in deployments where Exporters and Collectors 1966 communicate over links that are susceptible to congestion, but SCTP 1967 is preferred due to its ability to limit back pressure on Exporters 1968 and its message versus stream orientation. 1970 UDP may be used, although it is not a congestion-aware protocol. 1971 However, in this case the IPFIX traffic between Exporter and 1972 Collector must be separately contained or provisioned to minimize the 1973 risk of congestion-related loss. 1975 By default, the Collecting Process listens for connections on SCTP, 1976 TCP, and/or UDP port 4739. By default, the Collecting Process listens 1977 for secure connections on SCTP, TCP, and/or UDP port 4740 (refer to 1978 the Security Considerations section). By default, the Exporting 1979 Process attempts to connect to one of these ports. It MUST be 1980 possible to configure both the Exporting and Collecting Processes to 1981 use different ports than the default. 1983 10.2. SCTP 1985 This section describes how IPFIX is transported over SCTP [RFC4960] 1986 using the PR-SCTP [RFC3758] extension. 1988 10.2.1. Congestion Avoidance 1990 The SCTP transport protocol provides the required level of congestion 1991 avoidance by design. 1993 SCTP detects congestion in the end-to-end path between the IPFIX 1994 Exporting Process and the IPFIX Collecting Process, and limits the 1995 transfer rate accordingly. When an IPFIX Exporting Process has 1996 records to export, but detects that transmission by SCTP is 1997 temporarily impossible, it can either wait until sending is possible 1998 again, or it can decide to drop the record. In the latter case, the 1999 dropped export data SHOULD be accounted for, so that the amount of 2000 dropped export data can be reported using the mechanism in Section 2001 4.3. 2003 10.2.2. Reliability 2005 The SCTP transport protocol is by default reliable, but has the 2006 capability to deliver messages with partial reliability [RFC3758]. 2008 Using reliable SCTP messages for the IPFIX export is not in itself a 2009 guarantee that all Data Records will be delivered. If there is 2010 congestion on the link from the Exporting Process to the Collecting 2011 Process, or if a significant number of retransmissions are required, 2012 the send queues on the Exporting Process may fill up; the Exporting 2013 Process MAY either suspend, export, or discard the IPFIX Messages. 2014 If Data Records are discarded the IPFIX Sequence Numbers used for 2015 export MUST reflect the loss of data. 2017 10.2.3. MTU 2019 SCTP provides the required IPFIX Message fragmentation service based 2020 on path MTU discovery. 2022 10.2.4. Association Establishment and Shutdown 2024 The IPFIX Exporting Process initiates an SCTP association with the 2025 IPFIX Collecting Process. The Exporting Process MAY establish more 2026 than one association (connection "bundle" in SCTP terminology) to the 2027 Collecting Process. 2029 An Exporting Process MAY support more than one active association to 2030 different Collecting Processes (including the case of different 2031 Collecting Processes on the same host). 2033 When an Exporting Process is shut down, it SHOULD shut down the SCTP 2034 association. 2036 When a Collecting Process no longer wants to receive IPFIX Messages, 2037 it SHOULD shut down its end of the association. The Collecting 2038 Process SHOULD continue to receive and process IPFIX Messages until 2039 the Exporting Process has closed its end of the association. 2041 When a Collecting Process detects that the SCTP association has been 2042 abnormally terminated, it MUST continue to listen for a new 2043 association establishment. 2045 When an Exporting Process detects that the SCTP association to the 2046 Collecting Process is abnormally terminated, it SHOULD try to 2047 re-establish the association. 2049 Association timeouts SHOULD be configurable. 2051 10.2.5. Failover 2053 If the Collecting Process does not acknowledge the attempt by the 2054 Exporting Process to establish an association, the Exporting Process 2055 should retry using the SCTP exponential backoff feature. The 2056 Exporter MAY log an alarm if the time to establish the association 2057 exceeds a specified threshold, configurable on the Exporter. 2059 If Collecting Process failover is supported by the Exporting Process, 2060 a second SCTP association MAY be opened in advance. 2062 10.2.6. Streams 2064 An Exporting Process MAY request more than one SCTP stream per 2065 association. Each of these streams may be used for the transmission 2066 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 2067 Template Sets. 2069 Depending on the requirements of the application, the Exporting 2070 Process may send Data Sets with full or partial reliability, using 2071 ordered or out-of-order delivery, over any SCTP stream established 2072 during SCTP Association setup. 2074 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 2075 per Section 4 of the PR-SCTP [RFC3758] specification when using 2076 partial reliability to transmit IPFIX Messages containing only Data 2077 Sets. 2079 However, Exporting Processes SHOULD mark such IPFIX Messages for 2080 retransmission for as long as resource or other constraints allow. 2082 10.3. UDP 2084 This section describes how IPFIX is transported over UDP [UDP]. 2086 10.3.1. Congestion Avoidance 2088 UDP has no integral congestion-avoidance mechanism. Its use over 2089 congestion-sensitive network paths is therefore not recommended. UDP 2090 MAY be used in deployments where Exporters and Collectors always 2091 communicate over dedicated links that are not susceptible to 2092 congestion, i.e., links that are over-provisioned compared to the 2093 maximum export rate from the Exporters. 2095 10.3.2. Reliability 2097 UDP is not a reliable transport protocol, and cannot guarantee 2098 delivery of messages. IPFIX Messages sent from the Exporting Process 2099 to the Collecting Process using UDP may therefore be lost. UDP MUST 2100 NOT be used unless the application can tolerate some loss of IPFIX 2101 Messages. 2103 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 2104 Data Records by looking at the discontinuities in the IPFIX Sequence 2105 Number. In the case of UDP, the IPFIX Sequence Number contains the 2106 total number of IPFIX Data Records sent for the UDP Transport Session 2107 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 2108 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 2109 by tracking the Sequence Number. 2111 Exporting Processes exporting IPFIX Messages via UDP MUST include a 2112 valid UDP checksum [UDP] in UDP datagrams including IPFIX messages. 2114 10.3.3. MTU 2116 The maximum size of exported messages MUST be configured such that 2117 the total packet size does not exceed the path MTU. If the path MTU 2118 is unknown, a maximum packet size of 512 octets SHOULD be used. 2120 10.3.4. Session Establishment and Shutdown 2122 As UDP is a connectionless protocol, there is no real session 2123 establishment or shutdown for IPFIX over UDP. An Exporting Process 2124 starts sending IPFIX Messages to a Collecting Process at one point in 2125 time, and stops sending them at another point in time. This can lead 2126 to some complications in Template management, which are outlined in 2127 Section 8.4 above. 2129 10.3.5. Failover and Session Duplication 2131 Because UDP is not a connection-oriented protocol, the Exporting 2132 Process is unable to determine from the transport protocol that the 2133 Collecting Process is no longer able to receive the IPFIX Messages. 2134 Therefore, it cannot invoke a failover mechanism. However, the 2135 Exporting Process MAY duplicate the IPFIX Message to several 2136 Collecting Processes. 2138 10.4. TCP 2140 This section describes how IPFIX is transported over TCP [TCP]. 2142 10.4.1. Congestion Avoidance 2144 TCP controls the rate at which data can be sent from the Exporting 2145 Process to the Collecting Process, using a mechanism that takes into 2146 account both congestion in the network and the capabilities of the 2147 receiver. 2149 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2150 Messages at the rate that the Metering Process generates them, either 2151 because of congestion in the network or because the Collecting 2152 Process cannot handle IPFIX Messages fast enough. As long as 2153 congestion is transient, the Exporting Process can buffer IPFIX 2154 Messages for transmission. But such buffering is necessarily limited, 2155 both because of resource limitations and because of timeliness 2156 requirements, so ongoing and/or severe congestion may lead to a 2157 situation where the Exporting Process is blocked. 2159 When an Exporting Process has Data Records to export but the 2160 transmission buffer is full, and it wants to avoid blocking, it can 2161 decide to drop some Data Records. The dropped Data Records MUST be 2162 accounted for, so that the number of lost records can later be 2163 reported as in Section 4.3. 2165 10.4.2. Reliability 2167 TCP ensures reliable delivery of data from the Exporting Process to 2168 the Collecting Process. 2170 10.4.3. MTU 2172 As TCP offers a stream service instead of a datagram or sequential 2173 packet service, IPFIX Messages transported over TCP are instead 2174 separated using the Length field in the IPFIX Message Header. The 2175 Exporting Process can choose any valid length for exported IPFIX 2176 Messages, as TCP handles segmentation. 2178 However, if an Exporting Process exports data from multiple 2179 Observation Domains, it should be careful to choose IPFIX Message 2180 lengths appropriately to minimize head-of-line blocking between 2181 different Observation Domains. Multiple TCP connections MAY be used 2182 to avoid head-of-line blocking between different Observation Domains. 2184 10.4.4. Connection Establishment and Shutdown 2186 The IPFIX Exporting Process initiates a TCP connection to the 2187 Collecting Process. An Exporting Process MAY support more than one 2188 active connection to different Collecting Processes (including the 2189 case of different Collecting Processes on the same host). 2191 The Exporter MAY log an alarm if the time to establish the connection 2192 exceeds a specified threshold, configurable on the Exporter. 2194 When an Exporting Process is shut down, it SHOULD shut down the TCP 2195 connection. 2197 When a Collecting Process no longer wants to receive IPFIX Messages, 2198 it SHOULD close its end of the connection. The Collecting Process 2199 SHOULD continue to read IPFIX Messages until the Exporting Process 2200 has closed its end. 2202 When a Collecting Process detects that the TCP connection to the 2203 Exporting Process has terminated abnormally, it MUST continue to 2204 listen for a new connection. 2206 When an Exporting Process detects that the TCP connection to the 2207 Collecting Process has terminated abnormally, it SHOULD try to 2208 re-establish the connection. Connection timeouts and retry schedules 2209 SHOULD be configurable. In the default configuration, an Exporting 2210 Process MUST NOT attempt to establish a connection more frequently 2211 than once per minute. 2213 10.4.5. Failover 2215 If the Collecting Process does not acknowledge an attempt by the 2216 Exporting Process to establish a connection, TCP will automatically 2217 retry connection establishment using exponential backoff. The 2218 Exporter MAY log an alarm if the time to establish the association 2219 exceeds a specified threshold, configurable on the Exporter. 2221 If Collecting Process failover is supported by the Exporting Process, 2222 a second TCP connection MAY be opened in advance. 2224 11. Security Considerations 2226 The security considerations for the IPFIX protocol have been derived 2227 from an analysis of potential security threats, as discussed in the 2228 "Security Considerations" section of IPFIX requirements [RFC3917]. 2229 The requirements for IPFIX security are as follows: 2231 1. IPFIX must provide a mechanism to ensure the confidentiality of 2232 IPFIX data transferred from an Exporting Process to a Collecting 2233 Process, in order to prevent disclosure of Flow Records 2234 transported via IPFIX. 2236 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2237 data transferred from an Exporting Process to a Collecting 2238 Process, in order to prevent the injection of incorrect data or 2239 control information (e.g., Templates) into an IPFIX Message 2240 stream. 2242 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2243 and Exporting Processes, to prevent the collection of data from an 2244 unauthorized Exporting Process or the export of data to an 2245 unauthorized Collecting Process. 2247 Because IPFIX can be used to collect information for network 2248 forensics and billing purposes, attacks designed to confuse, disable, 2249 or take information from an IPFIX collection system may be seen as a 2250 prime objective during a sophisticated network attack. 2252 An attacker in a position to inject false messages into an IPFIX 2253 Message stream can either affect the application using IPFIX (by 2254 falsifying data), or the IPFIX Collecting Process itself (by 2255 modifying or revoking Templates, or changing options); for this 2256 reason, IPFIX Message integrity is important. 2258 The IPFIX Messages themselves may also contain information of value 2259 to an attacker, including information about the configuration of the 2260 network as well as end-user traffic and payload data, so care must be 2261 taken to confine their visibility to authorized users. When an 2262 Information Element containing end-user payload information is 2263 exported, it SHOULD be transmitted to the Collecting Process using a 2264 means that secures its contents against eavesdropping. Suitable 2265 mechanisms include the use of either a direct point-to-point 2266 connection or the use of an encryption mechanism. It is the 2267 responsibility of the Collecting Process to provide a satisfactory 2268 degree of security for this collected data, including, if necessary, 2269 anonymization of any reported data. 2271 11.1. Applicability of TLS and DTLS 2273 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2274 Security (DTLS) [RFC6347] were designed to provide the 2275 confidentiality, integrity, and authentication assurances required by 2276 the IPFIX protocol, without the need for pre-shared keys. 2278 With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC6347] 2279 MUST be implemented. If UDP is selected as the IPFIX transport 2280 protocol, DTLS [RFC6347] MUST be implemented. If TCP is selected as 2281 the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. 2283 Note that DTLS is selected as the security mechanism for SCTP. 2284 Though TLS bindings to SCTP are defined in [RFC3436], they require 2285 all communication to be over reliable, bidirectional streams, and 2286 require one TLS connection per stream. This arrangement is not 2287 compatible with the rationale behind the choice of SCTP as an IPFIX 2288 transport protocol. 2290 Note that using DTLS [RFC6347] has a vulnerability, i.e., a true man 2291 in the middle may attempt to take data out of an association and fool 2292 the sender into thinking that the data was actually received by the 2293 peer. In generic TLS for SCTP (and/or TCP), this is not possible. 2294 This means that the removal of a message may become hidden from the 2295 sender or receiver. Another vulnerability of using SCTP with DTLS is 2296 that someone could inject SCTP control information to shut down the 2297 SCTP association, effectively generating a loss of IPFIX Messages if 2298 those are buffered outside of the SCTP association. Techniques such 2299 as [RFC6083] could be used to overcome these vulnerabilities. 2301 When using DTLS over SCTP, the Exporting Process MUST ensure that 2302 each IPFIX Message is sent over the same SCTP stream that would be 2303 used when sending the same IPFIX Message directly over SCTP. Note 2304 that DTLS may send its own control messages on stream 0 with full 2305 reliability; however, this will not interfere with the processing of 2306 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2307 consumes its own control messages before passing IPFIX Messages up to 2308 the application layer. 2310 When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] 2311 SHOULD be used, especially on long-lived Transport Sessions, to 2312 ensure that the association remains active. 2314 11.2. Usage 2316 The IPFIX Exporting Process initiates the communication to the IPFIX 2317 Collecting Process, and acts as a TLS or DTLS client according to 2318 [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a 2319 TLS or DTLS server. The DTLS client opens a secure connection on the 2320 SCTP port 4740 of the DTLS server if SCTP is selected as the 2321 transport protocol. The TLS client opens a secure connection on the 2322 TCP port 4740 of the TLS server if TCP is selected as the transport 2323 protocol. The DTLS client opens a secure connection on the UDP port 2324 4740 of the DTLS server if UDP is selected as the transport 2325 protocol. 2327 11.3. Mutual Authentication 2329 When using TLS or DTLS, IPFIX Exporting Processes and IPFIX 2330 Collecting Processes SHOULD be identified by a certificate containing 2331 the DNS-ID identifier as in Section 6.4 of [RFC6125]; the inclusion 2332 of Common Names (CN-IDs) in certificates identifying IPFIX Exporting 2333 Processes or Collecting Processes is NOT RECOMMENDED. 2335 To prevent man-in-the-middle attacks from impostor Exporting or 2336 Collecting Processes, the acceptance of data from an unauthorized 2337 Exporting Process, or the export of data to an unauthorized 2338 Collecting Process, mutual authentication MUST be used for both TLS 2339 and DTLS. Exporting Processes MUST verify the reference identifiers 2340 of the Collecting Processes they are exporting IPFIX messages to 2341 against those stored in the certificates. Likewise, Collecting 2342 Processes MUST verify the reference identifiers of the Exporting 2343 Processes they are receiving IPFIX Messages from against those stored 2344 in the certificates. Exporting Processes MUST NOT export to non- 2345 verified Collecting Processes, and Collecting Processes MUST NOT 2346 accept IPFIX Messages from non-verified Exporting Processes. 2348 Exporting Processes and Collecting Processes MUST support the 2349 verification of certificates against an explicitly authorized list of 2350 peer certificates identified by Common Name, and SHOULD support the 2351 verification of reference identifiers by matching the DNS-ID or CN-ID 2352 with a DNS lookup of the peer. 2354 IPFIX Exporting Processes and Collecting Processes MUST use non-NULL 2355 ciphersuites for authentication, integrity, and confidentiality. 2356 IPFIX Exporting Processes and Collecting Processes MUST support TLS 2357 version 1.1 and SHOULD support TLS version 1.2 [RFC5246]; Exporting 2358 and Collecting Processes MUST NOT request, offer, or use any version 2359 of SSL, or any version of TLS prior to 1.1, due to known security 2360 vulnerabilities in prior versions of the protocol; see Appendix E of 2361 [RFC5246] for more information. 2363 11.4. Protection against DoS Attacks 2365 An attacker may mount a denial-of-service (DoS) attack against an 2366 IPFIX collection system either directly, by sending large amounts of 2367 traffic to a Collecting Process, or indirectly, by generating large 2368 amounts of traffic to be measured by a Metering Process. 2370 Direct DoS attacks can also involve state exhaustion, whether at the 2371 transport layer (e.g., by creating a large number of pending 2372 connections), or within the IPFIX Collecting Process itself (e.g., by 2373 sending Flow Records pending Template or scope information, a large 2374 amount of Options Template Records, etc.). 2376 SCTP mandates a cookie-exchange mechanism designed to defend against 2377 SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN 2378 cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be 2379 used by any Collecting Process accepting TCP connections. DTLS also 2380 provides cookie exchange to protect against DTLS server state 2381 exhaustion. 2383 The reader should note that there is no way to prevent fake IPFIX 2384 Message processing (and state creation) for UDP & SCTP communication. 2385 The use of TLS and DTLS can obviously prevent the creation of fake 2386 states, but they are themselves prone to state exhaustion attacks. 2387 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2388 DTLS (like limiting the number of new TLS or DTLS session per second 2389 to a sensible number). 2391 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2392 at which new connections or associations will be opened by the 2393 Collecting Process, the rate at which IPFIX Messages will be accepted 2394 by the Collecting Process, and adaptively limiting the amount of 2395 state kept, particularly records waiting on Templates. These rate 2396 and state limits MAY be provided by a Collecting Process; if 2397 provided, the limits SHOULD be user configurable. 2399 Additionally, an IPFIX Collecting Process can eliminate the risk of 2400 state exhaustion attacks from untrusted nodes by requiring TLS or 2401 DTLS mutual authentication, causing the Collecting Process to accept 2402 IPFIX Messages only from trusted sources. 2404 With respect to indirect denial of service, the behavior of IPFIX 2405 under overload conditions depends on the transport protocol in use. 2406 For IPFIX over TCP, TCP congestion control would cause the flow of 2407 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2408 system. SCTP improves upon this situation somewhat, as some IPFIX 2409 Messages would continue to be received by the Collecting Process due 2410 to the avoidance of head-of-line blocking by SCTP's multiple streams 2411 and partial reliability features, possibly affording some visibility 2412 of the attack. The situation is similar with UDP, as some datagrams 2413 may continue to be received at the Collecting Process, effectively 2414 applying sampling to the IPFIX Message stream, implying that some 2415 forensics may be left. 2417 To minimize IPFIX Message loss under overload conditions, some 2418 mechanism for service differentiation could be used to prioritize 2419 IPFIX traffic over other traffic on the same link. Alternatively, 2420 IPFIX Messages can be transported over a dedicated network. In this 2421 case, care must be taken to ensure that the dedicated network can 2422 handle the expected peak IPFIX Message traffic. 2424 11.5. When DTLS or TLS Is Not an Option 2426 The use of DTLS or TLS might not be possible in some cases due to 2427 performance issues or other operational concerns. 2429 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2430 and Collecting Processes can fall back on using IP source addresses 2431 to authenticate their peers. A policy of allocating Exporting 2432 Process and Collecting Process IP addresses from specified address 2433 ranges, and using ingress filtering to prevent spoofing, can improve 2434 the usefulness of this approach. Again, completely segregating IPFIX 2435 traffic on a dedicated network, where possible, can improve security 2436 even further. In any case, the use of open Collecting Processes 2437 (those that will accept IPFIX Messages from any Exporting Process 2438 regardless of IP address or identity) is discouraged. 2440 Modern TCP and SCTP implementations are resistant to blind insertion 2441 attacks (see [RFC4960], [RFC6528]); however, UDP offers no such 2442 protection. For this reason, IPFIX Message traffic transported via 2443 UDP and not secured via DTLS SHOULD be protected via segregation to a 2444 dedicated network. 2446 11.6. Logging an IPFIX Attack 2448 IPFIX Collecting Processes MUST detect potential IPFIX Message 2449 insertion or loss conditions by tracking the IPFIX Sequence Number, 2450 and SHOULD provide a logging mechanism for reporting out-of-sequence 2451 messages. Note that an attacker may be able to exploit the handling 2452 of out-of-sequence messages at the Collecting Process, so care should 2453 be taken in handling these conditions. For example, a Collecting 2454 Process that simply resets the expected Sequence Number upon receipt 2455 of a later Sequence Number could be temporarily blinded by deliberate 2456 injection of later Sequence Numbers. 2458 IPFIX Exporting and Collecting Processes SHOULD log any connection 2459 attempt that fails due to authentication failure, whether due to 2460 being presented an unauthorized or mismatched certificate during TLS 2461 or DTLS mutual authentication, or due to a connection attempt from an 2462 unauthorized IP address when TLS or DTLS is not in use. 2464 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2465 SCTP association reset or TCP connection reset. 2467 11.7. Securing the Collector 2469 The security of the Collector and its implementation is important to 2470 achieve overall security; however, a complete set of security 2471 guidelines for Collector implementation is outside the scope of this 2472 document. 2474 As IPFIX uses length-prefix encodings, Collector implementors should 2475 take care to ensure detection of and proper operation despite 2476 inconsistent values that could impact IPFIX Message decoding. 2477 Specifically, IPFIX Message, Set, and variable-length Information 2478 Element lengths must be checked for consistency to avoid buffer- 2479 sizing vulnerabilities. 2481 Collector implementors should also pay special attention to UTF-8 2482 encoding of string datatypes, as vulnerabilities may exist in the 2483 interpretation of ill-formed UTF-8 values; see Section 6.1.6. 2485 12. IANA Considerations 2487 On publication of this document, IANA will update the IPFIX 2488 Information Element Registry [IPFIX-IANA] to update all references to 2489 RFC5101 to point to this document, instead. 2491 This document has no further actions for IANA; the text below is 2492 explanatory. 2494 IPFIX Messages use two fields with assigned values. These are the 2495 IPFIX Version Number, indicating which version of the IPFIX Protocol 2496 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2497 the type for each set of information within an IPFIX Message. 2499 The Information Elements used by IPFIX, and sub-registries of 2500 Information Element values, are managed by IANA [IPFIX-IANA], as are 2501 the Private Enterprise Numbers used by enterprise-specific 2502 Information Elements [PEN-IANA]. This document makes no changes to 2503 these registries. 2505 The IPFIX Version Number value of 0x000a (10) is reserved for the 2506 IPFIX protocol specified in this document. Set ID values of 0 and 1 2507 are not used, for historical reasons [RFC3954]. The Set ID value of 2508 2 is reserved for the Template Set. The Set ID value of 3 is 2509 reserved for the Options Template Set. All other Set ID values from 2510 4 to 255 are reserved for future use. Set ID values above 255 are 2511 used for Data Sets. 2513 New assignments in either IPFIX Version Number or IPFIX Set ID 2514 assignments require a Standards Action [RFC5226], i.e., they are to 2515 be made via Standards Track RFCs approved by the IESG. 2517 Appendix A. IPFIX Encoding Examples 2519 This appendix, which is a not a normative reference, contains IPFIX 2520 encoding examples. 2522 Let's consider the example of an IPFIX Message composed of a 2523 Template Set, a Data Set (which contains three Data Records), an 2524 Options Template Set and a Data Set (which contains 2 Data Records 2525 related to the previous Options Template Record). 2527 IPFIX Message: 2529 +--------+------------------------------------------. . . 2530 | | +--------------+ +------------------+ 2531 |Message | | Template | | Data | 2532 | Header | | Set | | Set | . . . 2533 | | | (1 Template) | | (3 Data Records) | 2534 | | +--------------+ +------------------+ 2535 +--------+------------------------------------------. . . 2537 . . .-------------------------------------------+ 2538 +------------------+ +------------------+ | 2539 | Options | | Data | | 2540 . . . | Template Set | | Set | | 2541 | (1 Template) | | (2 Data Records) | | 2542 +------------------+ +------------------+ | 2543 . . .-------------------------------------------+ 2545 A.1. Message Header Example 2547 The Message Header is composed of: 2548 0 1 2 3 2549 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 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Version = 0x000a | Length = 152 | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Export Time | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | Sequence Number | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | Observation Domain ID | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 A.2. Template Set Examples 2562 A.2.1. Template Set Using IANA Information Elements 2564 We want to report the following Information Elements: 2566 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], 2567 with a length of 4 octets 2569 - The IPv4 destination IP address: destinationIPv4Address in 2570 [IPFIX-IANA], with a length of 4 octets 2572 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2573 [IPFIX-IANA], with a length of 4 octets 2575 - The number of packets of the Flow: packetDeltaCount in 2576 [IPFIX-IANA], with a length of 4 octets 2578 - The number of octets of the Flow: octetDeltaCount in 2579 [IPFIX-IANA], with a length of 4 octets 2581 Therefore, the Template Set will be composed of the following: 2583 0 1 2 3 2584 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 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | Set ID = 2 | Length = 28 octets | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | Template ID 256 | Field Count = 5 | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 |0| sourceIPv4Address = 8 | Field Length = 4 | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 |0| destinationIPv4Address = 12 | Field Length = 4 | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 |0| packetDeltaCount = 2 | Field Length = 4 | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 |0| octetDeltaCount = 1 | Field Length = 4 | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 A.2.2. Template Set Using Enterprise-Specific Information Elements 2603 We want to report the following Information Elements: 2605 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], with 2606 a length of 4 octets 2608 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2609 IANA], with a length of 4 octets 2611 - An enterprise-specific Information Element representing 2612 proprietary information, with a type of 15 and a length of 4 2614 - The number of packets of the Flow: packetDeltaCount in [IPFIX- 2615 IANA], with a length of 4 octets 2617 - The number of octets of the Flow: octetDeltaCount in [IPFIX-IANA], 2618 with a length of 4 octets 2620 Therefore, the Template Set will be composed of the following: 2622 0 1 2 3 2623 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 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | Set ID = 2 | Length = 32 octets | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | Template ID 257 | Field Count = 5 | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 |0| sourceIPv4Address = 8 | Field Length = 4 | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 |0| destinationIPv4Address = 12 | Field Length = 4 | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 |1| Information Element Id. = 15| Field Length = 4 | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Enterprise number | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 |0| packetDeltaCount = 2 | Field Length = 4 | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 |0| octetDeltaCount = 1 | Field Length = 4 | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 A.3. Data Set Example 2644 In this example, we report the following three Flow Records: 2646 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2647 | | | Number | Number 2648 ------------------------------------------------------------------ 2649 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2650 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2651 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2653 0 1 2 3 2654 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 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | Set ID = 256 | Length = 64 | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | 192.0.2.12 | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 | 192.0.2.254 | 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2662 | 192.0.2.1 | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | 5009 | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | 5344385 | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | 192.0.2.27 | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | 192.0.2.23 | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 | 192.0.2.2 | 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | 748 | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | 388934 | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | 192.0.2.56 | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | 192.0.2.65 | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | 192.0.2.3 | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | 5 | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | 6534 | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 Note that padding is not necessary in this example. 2691 A.4. Options Template Set Examples 2693 A.4.1. Options Template Set Using IANA Information Elements 2695 Per line card (the router being composed of two line cards), we want 2696 to report the following Information Elements: 2698 - Total number of IPFIX Messages: exportedMessageTotalCount [IPFIX- 2699 IANA], with a length of 2 octets 2701 - Total number of exported Flows: exportedFlowRecordTotalCount 2702 [IPFIX-IANA], with a length of 2 octets 2704 The line card, which is represented by the lineCardId Information 2705 Element [IPFIX-IANA], is used as the Scope Field. 2707 Therefore, the Options Template Set will be: 2709 0 1 2 3 2710 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 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | Set ID = 3 | Length = 24 | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 | Template ID 258 | Field Count = 3 | 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | Scope Field Count = 1 |0| lineCardId = 141 | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Field Length = 2 | Padding | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 A.4.2. Options Template Set Using Enterprise-Specific Information 2726 Elements 2728 Per line card (the router being composed of two line cards), we want 2729 to report the following Information Elements: 2731 - Total number of IPFIX Messages: exportedMessageTotalCount 2732 [IPFIX-IANA], with a length of 2 octets 2734 - An enterprise-specific number of exported Flows, with a type of 2735 42 and a length of 4 octets 2737 The line card, which is represented by the lineCardId Information 2738 Element [IPFIX-IANA], is used as the Scope Field. 2740 The format of the Options Template Set is as follows: 2742 0 1 2 3 2743 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 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Set ID = 3 | Length = 28 | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 | Template ID 259 | Field Count = 3 | 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 | Scope Field Count = 1 |0| lineCardId = 141 | 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Field Length = 2 |1|Information Element Id. = 42 | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | Field Length = 4 | Enterprise number ... 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 ... Enterprise number | Padding | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2762 In this example, we want to export the same information as in the 2763 example in Section A.4.1: 2765 - Total number of IPFIX Messages: exportedMessageTotalCount 2766 [IPFIX-IANA], with a length of 2 octets 2768 - Total number of exported Flows: exportedFlowRecordTotalCount 2769 [IPFIX-IANA], with a length of 2 octets 2771 But this time, the information pertains to a proprietary scope, 2772 identified by enterprise-specific Information Element number 123. 2774 The format of the Options Template Set is now as follows: 2776 0 1 2 3 2777 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 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Set ID = 3 | Length = 28 | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | Template ID 260 | Field Count = 3 | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | Scope 1 Field Length = 4 | Enterprise Number ... 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | Field Length = 2 | Padding | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 A.4.4. Data Set Using an Enterprise-Specific Scope 2796 In this example, we report the following two Data Records: 2798 Enterprise field 123 | IPFIX Message | Exported Flow Records 2799 ------------------------------------------------------------------- 2800 1 | 345 | 10201 2801 2 | 690 | 20402 2803 0 1 2 3 2804 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 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | Set ID = 260 | Length = 20 | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | 1 | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | 345 | 10201 | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | 2 | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | 690 | 20402 | 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 A.5. Variable-Length Information Element Examples 2819 A.5.1. Example of Variable-Length Information Element with Length 2820 Inferior to 255 Octets 2822 0 1 2 3 2823 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 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | 5 | 5 octet Information Element | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 A.5.2. Example of Variable-Length Information Element with 3 Octet 2831 Length Encoding 2833 0 1 2 3 2834 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 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | 255 | 1000 | IE ... | 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 | 1000 octet Information Element | 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 : ... : 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | ... IE | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 References 2847 Normative References 2849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2850 Requirement Levels", BCP 14, RFC 2119, March 1997. 2852 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2853 Layer Security over Stream Control Transmission 2854 Protocol", RFC 3436, December 2002. 2856 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2857 10646", RFC 3629, November 2003. 2859 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2860 Conrad, "Stream Control Transmission Protocol (SCTP) 2861 Partial Reliability Extension", RFC 3758, May 2004. 2863 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 2864 Protocol", RFC 4960, September 2007. 2866 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2867 an IANA Considerations Section in RFCs", BCP 26, RFC 2868 5226, May 2008. 2870 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2871 Security (TLS) Protocol Version 1.2", RFC 5246, August 2872 2008. 2874 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 2875 W. Kasch, "Network Time Protocol Version 4: Protocol 2876 and Algorithms Specification", RFC 5905, June 2010 2878 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2879 Verification of Domain-Based Application Service 2880 Identity within Internet Public Key Infrastructure 2881 Using X.509 (PKIX) Certificates in the Context of 2882 Transport Layer Security (TLS)", RFC 6125, March 2011. 2884 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 2885 Layer Security Version 1.2", RFC 6347, January 2012. 2887 [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., 2888 "Transport Layer Security (TLS) and Datagram Transport 2889 Layer Security (DTLS) Heartbeat Extension", RFC 6520, 2890 February 2012. 2892 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2893 RFC 793, September 1981. 2895 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2896 August 1980. 2898 [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. 2899 Meyer, "Information Model for IP Flow Information 2900 Export", draft-claise-ipfix-information-model- 2901 rfc5102bis-01.txt, Work in Progress, October 2011. 2903 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 2905 Informative References 2907 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2908 "Textual Conventions for SMIv2", STD 58, RFC 2579, 2909 April 1999. 2911 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2912 Jacobson, "RTP: A Transport Protocol for Real-Time 2913 Applications", STD 64, RFC 3550, July 2003. 2915 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2916 "Requirements for IP Flow Information Export (IPFIX)", 2917 RFC 3917, October 2004. 2919 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 2920 Export Version 9", RFC 3954, October 2004. 2922 [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP 2923 Flow Information Export (IPFIX)", RFC 5103, January 2924 2008. 2926 [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP 2927 Flow Information Export (IPFIX) Protocol for the 2928 Exchange of IP Traffic Flow Information", RFC 5101, 2929 January 2008. 2931 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 2932 Flow Information Export (IPFIX) Implementation 2933 Guidelines", RFC5153, April 2008 2935 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 2936 Quittek, "Architecture for IP Flow Information 2937 Export", RFC5470, March 2009. 2939 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 2940 "IP Flow Information Export (IPFIX) Applicability", 2941 RFC5472, March 2009. 2943 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 2944 for IP Flow Information Export (IPFIX) Testing", 2945 RFC5471, March 2009. 2947 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2948 Redundancy in IP Flow Information Export (IPFIX) and 2949 Packet Sampling (PSAMP) Reports", RFC5473, March 2009. 2951 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, 2952 A., Grossglauser, M., and J. Rexford, "A Framework for 2953 Packet Selection and Reporting", RFC 5474, March 2009. 2955 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet 2956 Sampling (PSAMP) Protocol Specifications", RFC5476, 2957 March 2009. 2959 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and 2960 G. Carle, "Information Model for Packet Sampling 2961 Exports", RFC 5477, March 2009. 2963 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2964 "Exporting Type Information for IP Flow Information 2965 Export (IPFIX) Information Elements", RFC 5610, July 2966 2009. 2968 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2969 Wagner, "Specification of the IP Flow Information 2970 Export (IPFIX) File Format", RFC 5655, October 2009. 2972 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 2973 Transport Layer Security (DTLS) for Stream Control 2974 Transmission Protocol (SCTP)", RFC6083, January 2011. 2976 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 2977 "Export of Structured Data in IP Flow Information 2978 Export (IPFIX)", RFC6313, July 2011. 2980 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 2981 "IP Flow Information Export (IPFIX) Mediation: 2982 Framework", RFC6183, April 2011. 2984 [RFC6526] Claise, B., Aitken, P., Johnson, A. and G. Muenz, 2985 "IPFIX Export per SCTP Stream", RFC 6526, March 2012. 2987 [RFC6528] Gont, F. and S. Bellovin, "Defending Against Sequence 2988 Number Attacks", RFC 6528, February 2012. 2990 [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 2991 "Definitions of Managed Objects for IP Flow 2992 Information Export", RFC 6615, June 2012. 2994 [RFC6727] Dietz, T. Ed., Claise, B., and J. Quittek, 2995 "Definitions of Managed Objects for Packet Sampling", 2996 RFC 6727, October 2012. 2998 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration 2999 Data Model for IPFIX and PSAMP", RFC 6728, October 3000 2012. 3002 [PEN-IANA] IANA Private Enterprise Numbers registry 3003 http://www.iana.org/assignments/enterprise-numbers. 3005 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 3006 Technology - Portable Operating System Interface, 3007 IEEE, 2008. 3009 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 3010 "Standard for Binary Floating-Point Arithmetic", IEEE 3011 Standard 754, August 1985. 3013 [UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report 3014 #36: Unicode Security Considerations", The Unicode 3015 Consortium, July 2012. 3017 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 3018 "Specification of the Protocol for IPFIX Mediations", 3019 draft-ietf-ipfix-mediation-protocol-03, Work in 3020 Progress, January 2013. 3022 Acknowledgments 3024 We would like to thank Ganesh Sadasivan, as well, for his significant 3025 contribution during the initial phases of the protocol specification. 3026 Additional thanks to Juergen Quittek for the coordination job within 3027 IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, and Andrew Johnson for 3028 the thorough reviews; Randall Stewart and Peter Lei for their SCTP 3029 expertise and contributions; Martin Djernaes for the first essay on 3030 the SCTP section; Michael Behringer and Eric Vyncke for their advice 3031 and knowledge in security; Michael Tuexen for his help regarding the 3032 DTLS section; Elisa Boschi for her contribution regarding the 3033 improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff 3034 Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David 3035 Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, and 3036 many more, for the technical reviews and feedback. 3038 Authors' Addresses 3040 Benoit Claise (Ed.) 3041 Cisco Systems, Inc. 3042 De Kleetlaan 6a b1 3043 1831 Diegem 3044 Belgium 3046 Phone: +32 2 704 5622 3047 EMail: bclaise@cisco.com 3049 Brian Trammell (Ed.) 3050 Swiss Federal Institute of Technology Zurich 3051 Gloriastrasse 35 3052 8092 Zurich 3053 Switzerland 3055 Phone: +41 44 632 70 13 3056 EMail: trammell@tik.ee.ethz.ch 3058 Paul Aitken 3059 Cisco Systems, Inc. 3060 96 Commercial Quay 3061 Commercial Street, Edinburgh EH6 6LX 3062 United Kingdom 3064 Phone: +44 131 561 3616 3065 Email: paitken@cisco.com 3067 Contributors' Addresses 3069 Stewart Bryant 3070 Cisco Systems, Inc. 3071 250, Longwater, 3072 Green Park, 3073 Reading, RG2 6GB, 3074 United Kingdom 3076 Phone: +44 (0)20 8824-8828 3077 EMail: stbryant@cisco.com 3079 Simon Leinen 3080 SWITCH 3081 Werdstrasse 2 3082 P.O. Box 3083 8021 Zurich 3084 Switzerland 3086 Phone: +41 44 268 1536 3087 EMail: simon.leinen@switch.ch 3089 Thomas Dietz 3090 NEC Europe Ltd. 3091 NEC Laboratories Europe 3092 Network Research Division 3093 Kurfuersten-Anlage 36 3094 69115 Heidelberg 3095 Germany 3097 Phone: +49 6221 4342-128 3098 EMail: Thomas.Dietz@nw.neclab.eu