idnits 2.17.1 draft-ietf-ipfix-protocol-rfc5101bis-07.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 (May 23, 2013) is 3990 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: November 24, 2013 May 23, 2013 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of Flow Information 10 draft-ietf-ipfix-protocol-rfc5101bis-07 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 11.8. Privacy Considerations for Collected Data . . . . . . . . 54 139 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 140 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 56 141 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 56 142 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 57 143 A.2.1. Template Set Using IANA Information Elements . . . . . 57 144 A.2.2. Template Set Using Enterprise-Specific Information 145 Elements . . . . . . . . . . . . . . . . . . . . . . . 57 146 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 59 147 A.4. Options Template Set Examples . . . . . . . . . . . . . . 60 148 A.4.1. Options Template Set Using IANA Information Elements . 60 149 A.4.2. Options Template Set Using Enterprise-Specific 150 Information . . . . . . . . . . . . . . . . . . . . . 60 151 A.4.3. Options Template Set Using an Enterprise-Specific 152 Scope . . . . . . . . . . . . . . . . . . . . . . . . 61 153 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 62 154 A.5. Variable-Length Information Element Examples . . . . . . . 63 155 A.5.1. Example of Variable-Length Information Element with 156 Length . . . . . . . . . . . . . . . . . . . . . . . . 63 157 A.5.2. Example of Variable-Length Information Element with 158 3 Octet Length Encoding . . . . . . . . . . . . . . . 63 159 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 160 Normative References . . . . . . . . . . . . . . . . . . . . . . . 64 161 Informative References . . . . . . . . . . . . . . . . . . . . . . 65 162 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 68 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 164 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 69 166 1. Introduction 168 Traffic on a data network can be seen as consisting of flows passing 169 through network elements. It is often interesting, useful, or even 170 necessary to have access to information about these flows that pass 171 through the network elements for administrative or other purposes. A 172 Collecting Process should be able to receive the flow information 173 passing through multiple network elements within the data network. 174 This requires uniformity in the method of representing the flow 175 information and the means of communicating the flows from the network 176 elements to the collection point. This document specifies a protocol 177 to achieve these requirements. This document specifies in detail the 178 representation of different flows, the additional data required for 179 flow interpretation, packet format, transport mechanisms used, 180 security concerns, etc. 182 1.1. Changes since RFC 5101 184 This document obsoletes the Proposed Standard revision of the IPFIX 185 Protocol Specification [RFC5101]. The protocol specified by this 186 document is interoperable with the protocol as specified in 187 [RFC5101]. The following changes have been made to this document with 188 respect to the previous document: 190 - All outstanding technical and editorial errata on [RFC5101] have 191 been addressed. 193 - The encoding of the dateTimeSeconds, dateTimeMilliseconds, 194 dateTimeMicroseconds, and dateTimeNanoseconds data types, and the 195 related encoding of the IPFIX Message Header Export Time field, have 196 been clarified, especially with respect to the epoch upon which the 197 timestamp data types are based. 199 - A new Section 5.2 has been added to address wraparound of these 200 timestamp data types after they overflow in 2032 - 2038 CE (common 201 era). 203 - Clarifications on encoding, especially in Section 6: all IPFIX 204 values are encoded big-endian. 206 - Template management in section 8 has been simplified and clarified: 207 the specification has been relaxed with respect to [RFC5101], 208 especially concerning potential failures in Template ID reuse. 209 Additional corner cases in template management have been addressed. 210 The new template management language is interoperable with that in 211 [RFC5101] to the extent that the behavior was defined in the prior 212 specification. 214 - Section 11.3 (Mutual Authentication) has been improved to refer to 215 current practices in TLS mutual authentication; references to 216 Punycode were removed as these are covered in [RFC6125]. 218 - Editorial improvements, including structural changes to sections 8, 219 9, and 10 to improve readability. Behavior common to all transport 220 protocols has been separated out, with exceptions per transport 221 specifically noted. All template management language (on both 222 Exporting and Collecting Processes) has been unified in section 8. 224 1.2. IPFIX Documents Overview 226 The IPFIX protocol provides network administrators with access to IP 227 flow information. The architecture for the export of measured IP 228 flow information out of an IPFIX Exporting Process to a Collecting 229 Process is defined in [RFC5470], per the requirements defined in 231 [RFC3917]. This document specifies how IPFIX Data Records and 232 Templates are carried via a number of transport protocols from IPFIX 233 Exporting Processes to IPFIX Collecting Processes. 235 Four IPFIX optimizations/extensions are currently specified: a 236 bandwidth saving method for the IPFIX protocol in [RFC5473], an 237 efficient method for exporting bidirectional flows in [RFC5103], a 238 method for the definition and export of complex data structures in 239 [RFC6313], and the specification of the Protocol for IPFIX Mediations 240 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 242 A "file-based transport" for IPFIX, which defines how IPFIX Messages 243 can be stored in files for document-based workflows and for archival 244 purposes, is given in [RFC5655]. 246 IPFIX has a formal description of IPFIX Information Elements, their 247 name, type and additional semantic information, as specified in 248 [RFC5102bis]. The registry is maintained by IANA [IPFIX-IANA]. The 249 inline export of the Information Element type information is 250 specified in [RFC5610]. 252 The framework for packet selection and reporting [RFC5474] enables 253 network elements to select subsets of packets by statistical and 254 other methods, and to export a stream of reports on the selected 255 packets to a Collector. The set of packet selection techniques 256 (Sampling, Filtering, and hashing) standardized by PSAMP is described 257 in [ RFC5475]. The PSAMP protocol [RFC5476], which uses IPFIX as 258 export protocol, specifies the export of packet information from a 259 PSAMP Exporting Process to a PSAMP Collector. Instead of exporting 260 PSAMP Packet Reports, the stream of selected packets may also serve 261 as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP 262 has a formal description of its Information Elements, their name, 263 type, and additional semantic information. The PSAMP information 264 model is defined in [RFC5477]. 266 [RFC6615] specifies a MIB module for monitoring, and [RFC6728] 267 specifies a data model for configuring and monitoring IPFIX and PSAMP 268 compliant devices using the NETCONF protocol. [RFC6727] specifies the 269 PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module 270 defined in [RFC6615]. 272 In terms of development, [RFC5153] provides guidelines for the 273 implementation and use of the IPFIX protocol, while [RFC5471] 274 provides guidelines for testing. Finally, [RFC5472] describes what 275 type of applications can use the IPFIX protocol and how they can use 276 the information provided. It furthermore shows how the IPFIX 277 framework relates to other architectures and frameworks. 279 2. Terminology 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 283 "OPTIONAL" in this document are to be interpreted as described in RFC 284 2119 [RFC2119]. 286 The definitions of the basic terms like Traffic Flow, Exporting 287 Process, Collecting Process, Observation Points, etc. are 288 semantically identical to those found in the IPFIX requirements 289 document [RFC3917]. Some of the terms have been expanded for more 290 clarity when defining the protocol. Additional terms required for 291 the protocol have also been defined. Definitions in this document 292 and in [RFC5470] are equivalent; definitions that are only relevant 293 to the IPFIX protocol only appear here. 295 The terminology summary table in Section 2.1 gives a quick overview 296 of the relationships among some of the different terms defined. 298 Observation Point 300 An Observation Point is a location in the network where packets 301 can be observed. Examples include: a line to which a probe is 302 attached, a shared medium, such as an Ethernet-based LAN, a single 303 port of a router, or a set of interfaces (physical or logical) of 304 a router. 306 Note that every Observation Point is associated with an 307 Observation Domain (defined below), and that one Observation Point 308 may be a superset of several other Observation Points. For 309 example, one Observation Point can be an entire line card. That 310 would be the superset of the individual Observation Points at the 311 line card's interfaces. 313 Observation Domain 315 An Observation Domain is the largest set of Observation Points for 316 which Flow information can be aggregated by a Metering Process. 317 For example, a router line card may be an Observation Domain if it 318 is composed of several interfaces, each of which is an Observation 319 Point. In the IPFIX Message it generates, the Observation Domain 320 includes its Observation Domain ID, which is unique per Exporting 321 Process. That way, the Collecting Process can identify the 322 specific Observation Domain from the Exporter that sends the IPFIX 323 Messages. Every Observation Point is associated with an 324 Observation Domain. It is RECOMMENDED that Observation Domain IDs 325 also be unique per IPFIX Device. 327 Traffic Flow or Flow 329 There are several definitions of the term 'flow' being used by the 330 Internet community. Within the context of IPFIX we use the 331 following definition: 333 A Flow is defined as a set of packets or frames passing an 334 Observation Point in the network during a certain time interval. 335 All packets belonging to a particular Flow have a set of common 336 properties. Each property is defined as the result of applying a 337 function to the values of: 339 1. one or more packet header fields (e.g., destination IP 340 address), transport header fields (e.g., destination port 341 number), or application header fields (e.g., RTP header 342 fields [RFC3550]). 344 2. one or more characteristics of the packet itself (e.g., 345 number of MPLS labels, etc...). 347 3. one or more of fields derived from packet treatment (e.g., 348 next hop IP address, the output interface, etc...). 350 A packet is defined as belonging to a Flow if it completely 351 satisfies all the defined properties of the Flow. 353 Note that the set of packets represented by a Flow may be empty; 354 that is, a Flow may represent zero or more packets. As sampling is 355 a packet treatment, this definition includes packets selected by a 356 sampling mechanism. 358 Flow Key 360 Each of the fields that: 362 1. belong to the packet header (e.g., destination IP address), or 364 2. are a property of the packet itself (e.g., packet length), or 366 3. are derived from packet treatment (e.g., Autonomous System 367 (AS) number), 369 and that are used to define a Flow are termed Flow Keys. 371 Flow Record 373 A Flow Record contains information about a specific Flow that was 374 observed at an Observation Point. A Flow Record contains measured 375 properties of the Flow (e.g., the total number of bytes for all 376 the Flow's packets) and usually contains characteristic properties 377 of the Flow (e.g., source IP address). 379 Metering Process 381 The Metering Process generates Flow Records. Inputs to the 382 process are packet headers, characteristics, and packet treatment 383 observed at one or more Observation Points. 385 The Metering Process consists of a set of functions that includes 386 packet header capturing, timestamping, sampling, classifying, and 387 maintaining Flow Records. 389 The maintenance of Flow Records may include creating new records, 390 updating existing ones, computing Flow statistics, deriving 391 further Flow properties, detecting Flow expiration, passing Flow 392 Records to the Exporting Process, and deleting Flow Records. 394 Exporting Process 396 The Exporting Process sends IPFIX Messages to one or more 397 Collecting Processes. The Flow Records in the Messages are 398 generated by one or more Metering Processes. 400 Exporter 402 A device that hosts one or more Exporting Processes is termed an 403 Exporter. 405 IPFIX Device 407 An IPFIX Device hosts at least one Exporting Process. It may host 408 further Exporting Processes and arbitrary numbers of Observation 409 Points and Metering Processes. 411 Collecting Process 413 A Collecting Process receives IPFIX Messages from one or more 414 Exporting Processes. The Collecting Process might process or 415 store Flow Records received within these Messages, but such 416 actions are out of scope for this document. 418 Collector 420 A device that hosts one or more Collecting Processes is termed a 421 Collector. 423 Template 425 A Template is an ordered sequence of pairs used to 426 completely specify the structure and semantics of a particular set 427 of information that needs to be communicated from an IPFIX Device 428 to a Collector. Each Template is uniquely identifiable by means 429 of a Template ID. 431 IPFIX Message 433 An IPFIX Message is a message originating at the Exporting Process 434 that carries the IPFIX records of this Exporting Process and whose 435 destination is a Collecting Process. An IPFIX Message is 436 encapsulated at the transport layer. 438 Message Header 440 The Message Header is the first part of an IPFIX Message, which 441 provides basic information about the message, such as the IPFIX 442 version, length of the message, message sequence number, etc. 444 Template Record 446 A Template Record defines the structure and interpretation of 447 fields in a Data Record. 449 Data Record 451 A Data Record is a record that contains values of the parameters 452 corresponding to a Template Record. 454 Options Template Record 456 An Options Template Record is a Template Record that defines the 457 structure and interpretation of fields in a Data Record, including 458 defining how to scope the applicability of the Data Record. 460 Set 462 A Set is a collection of records that have a similar structure, 463 prefixed by a header. In an IPFIX Message, zero or more Sets 464 follow the Message Header. There are three different types of 465 Sets: Template Set, Options Template Set, and Data Set. 467 Template Set 469 A Template Set is a collection of one or more Template Records 470 that have been grouped together in an IPFIX Message. 472 Options Template Set 474 An Options Template Set is a collection of one or more Options 475 Template Records that have been grouped together in an IPFIX 476 Message. 478 Data Set 480 A Data Set is one or more Data Records, of the same type, that are 481 grouped together in an IPFIX Message. Each Data Record is 482 previously defined by a Template Record or an Options Template 483 Record. 485 Information Element 487 An Information Element is a protocol and encoding-independent 488 description of an attribute that may appear in an IPFIX Record. 489 The base set of Information Elements making up the IPFIX 490 information model [RFC5102bis] are described in the IANA IPFIX 491 Information Element Registry [IPFIX-IANA]. The type associated 492 with an Information Element indicates constraints on what it may 493 contain and also determines the valid encoding mechanisms for use 494 in IPFIX. 496 Transport Session 498 In Stream Control Transmission Protocol (SCTP), the transport 499 session is known as the SCTP association, which is uniquely 500 identified by the SCTP endpoints [RFC4960]; in TCP, the transport 501 session is known as the TCP connection, which is uniquely 502 identified by the combination of IP addresses and TCP ports used. 503 In UDP, the transport session is known as the UDP session, which 504 is uniquely identified by the combination of IP addresses and UDP 505 ports used. 507 2.1. Terminology Summary Table 509 +------------------+---------------------------------------------+ 510 | | contents | 511 | +--------------------+------------------------+ 512 | Set | Template | Record | 513 +------------------+--------------------+------------------------+ 514 | Data Set | / | Data Record(s) | 515 +------------------+--------------------+------------------------+ 516 | Template Set | Template Record(s) | / | 517 +------------------+--------------------+------------------------+ 518 | Options Template | Options Template | / | 519 | Set | Record(s) | | 520 +------------------+--------------------+------------------------+ 522 Figure A: Terminology Summary Table 524 A Data Set is composed of Data Record(s). No Template Record is 525 included. A Template Record or an Options Template Record defines 526 the Data Record. 528 A Template Set contains only Template Record(s). 530 An Options Template Set contains only Options Template Record(s). 532 3. IPFIX Message Format 534 An IPFIX Message consists of a Message Header, followed by zero or 535 more Sets. The Sets can be any of the possible three types: Data 536 Set, Template Set, or Options Template Set. 538 The format of the IPFIX Message is shown in Figure B. 540 +----------------------------------------------------+ 541 | Message Header | 542 +----------------------------------------------------+ 543 | Set | 544 +----------------------------------------------------+ 545 | Set | 546 +----------------------------------------------------+ 547 ... 548 +----------------------------------------------------+ 549 | Set | 550 +----------------------------------------------------+ 552 Figure B: IPFIX Message Format 553 Following are some examples of IPFIX Messages: 555 1. An IPFIX Message consisting of interleaved Template, Data, and 556 Options Template Sets, shown in Figure C. Here, Template and 557 Options Template Sets are transmitted "on demand", before the 558 first Data Set they define the structure of. 560 +--------+--------------------------------------------------------+ 561 | | +----------+ +---------+ +-----------+ +---------+ | 562 |Message | | Template | | Data | | Options | | Data | | 563 | Header | | Set | | Set | ... | Template | | Set | | 564 | | | | | | | Set | | | | 565 | | +----------+ +---------+ +-----------+ +---------+ | 566 +--------+--------------------------------------------------------+ 568 Figure C: IPFIX Message, Example 1 570 2. An IPFIX Message consisting entirely of Data Sets, sent after the 571 appropriate Template Records have been defined and transmitted to 572 the Collecting Process, shown in Figure D. 574 +--------+----------------------------------------------+ 575 | | +---------+ +---------+ +---------+ | 576 |Message | | Data | | Data | | Data | | 577 | Header | | Set | ... | Set | ... | Set | | 578 | | +---------+ +---------+ +---------+ | 579 +--------+----------------------------------------------+ 581 Figure D: IPFIX Message, Example 2 583 3. An IPFIX Message consisting entirely of Template and Options 584 Template Sets, shown in Figure E. Such a message can be used to 585 define or redefine Templates and Options Templates in bulk. 587 +--------+-------------------------------------------------+ 588 | | +----------+ +----------+ +----------+ | 589 |Message | | Template | | Template | | Options | | 590 | Header | | Set | ... | Set | ... | Template | | 591 | | | | | | | Set | | 592 | | +----------+ +----------+ +----------+ | 593 +--------+-------------------------------------------------+ 595 Figure E: IPFIX Message, Example 3 597 3.1. Message Header Format 599 The format of the IPFIX Message Header is shown in Figure F. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Version Number | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Export Time | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Sequence Number | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Observation Domain ID | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure F: IPFIX Message Header Format 615 Each Message Header field is exported in big-endian byte order. The 616 fields are defined as follows: 618 Version 620 Version of IPFIX to which this Message conforms. The value of this 621 field is 0x000a for the current version, incrementing by one the 622 version used in the NetFlow services export version 9 [RFC3954]. 624 Length 626 Total length of the IPFIX Message, measured in octets, including 627 Message Header and Set(s). 629 Export Time 631 Time at which the IPFIX Message Header leaves the Exporter, 632 expressed in seconds since the UNIX epoch of 1 January 1970 at 633 00:00 UTC, encoded as an unsigned 32-bit integer. 635 Sequence Number 637 Incremental sequence counter modulo 2^32 of all IPFIX Data Records 638 sent in the current stream from the current Observation Domain by 639 the Exporting Process. Each SCTP Stream counts sequence numbers 640 separately, while all messages in a TCP connection or UDP 641 transport session are considered to be part of the same stream. 642 This value SHOULD be used by the Collecting Process to identify 643 whether any IPFIX Data Records have been missed. Template and 644 Options Template Records do not increase the Sequence Number. 646 Observation Domain ID 648 A 32-bit identifier of the Observation Domain that is locally 649 unique to the Exporting Process. The Exporting Process uses the 650 Observation Domain ID to uniquely identify to the Collecting 651 Process the Observation Domain that metered the Flows. It is 652 RECOMMENDED that this identifier also be unique per IPFIX Device. 653 Collecting Processes SHOULD use the Transport Session and the 654 Observation Domain ID field to separate different export streams 655 originating from the same Exporter. The Observation Domain ID 656 SHOULD be 0 when no specific Observation Domain ID is relevant for 657 the entire IPFIX Message, for example, when exporting the 658 Exporting Process Statistics, or in case of a hierarchy of 659 Collectors when aggregated Data Records are exported. 661 3.2. Field Specifier Format 663 Vendors need the ability to define proprietary Information Elements, 664 because, for example, they are delivering a pre-standards product, or 665 the Information Element is, in some way, commercially sensitive. 666 This section describes the Field Specifier format for both 667 IANA-registered Information Elements [IPFIX-IANA] and enterprise- 668 specific Information Elements. 670 The Information Elements are identified by the Information Element 671 identifier. When the Enterprise bit is set to 0, the corresponding 672 Information Element appears in [IPFIX-IANA], and the Enterprise 673 Number MUST NOT be present. When the Enterprise bit is set to 1, the 674 corresponding Information Element identifier identified an 675 enterprise-specific Information Element; the Enterprise Number MUST 676 be present. An example of this is shown in Section A.2.2. 678 The Field Specifier format is shown in Figure G. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 |E| Information Element ident. | Field Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Enterprise Number | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure G: Field Specifier Format 690 Where: 692 E 694 Enterprise bit. This is the first bit of the Field Specifier. If 695 this bit is zero, the Information Element Identifier identifies an 696 Information Element in [IPFIX-IANA], and the four-octet Enterprise 697 Number field MUST NOT be present. If this bit is one, the 698 Information Element identifier identifies an enterprise-specific 699 Information Element, and the Enterprise Number field MUST be 700 present. 702 Information Element identifier 704 A numeric value that represents the Information Element. Refer to 705 [IPFIX-IANA]. 707 Field Length 709 The length of the corresponding encoded Information Element, in 710 octets. Refer to [IPFIX-IANA]. The field length may be smaller 711 than that in [IPFIX-IANA] if the reduced size encoding is used 712 (see Section 6.2). The value 65535 is reserved for variable- 713 length Information Elements (see Section 7). 715 Enterprise Number 717 IANA enterprise number [PEN-IANA] of the authority defining the 718 Information Element identifier in this Template Record. 720 3.3. Set and Set Header Format 722 A Set is a generic term for a collection of records that have a 723 similar structure. There are three different types of Sets: Template 724 Sets, Options Template Sets, and Data Sets. Each of these Sets 725 consists of a Set Header and one or more records. The Set Format and 726 the Set Header Format are defined in the following sections. 728 3.3.1. Set Format 730 A Set has the format shown in Figure H. The record types can be 731 either Template Records, Options Template Records, or Data Records. 732 The record types MUST NOT be mixed within a Set. 734 +--------------------------------------------------+ 735 | Set Header | 736 +--------------------------------------------------+ 737 | record | 738 +--------------------------------------------------+ 739 | record | 740 +--------------------------------------------------+ 741 ... 742 +--------------------------------------------------+ 743 | record | 744 +--------------------------------------------------+ 745 | Padding (opt.) | 746 +--------------------------------------------------+ 748 Figure H: Set Format 750 Set Header 752 The Set Header Format is defined in Section 3.3.2. 754 Record 756 One of the record Formats: Template Record, Options Template 757 Record, or Data Record Format. 759 Padding 761 The Exporting Process MAY insert some padding octets, so that the 762 subsequent Set starts at an aligned boundary. For security 763 reasons, the padding octet(s) MUST be composed of zero (0) valued 764 octets. The padding length MUST be shorter than any allowable 765 record in this Set. If padding of the IPFIX Message is desired in 766 combination with very short records, then the padding Information 767 Element 'paddingOctets' can be used for padding records such that 768 their length is increased to a multiple of 4 or 8 octets. Because 769 Template Sets are always 4-octet aligned by definition, padding is 770 only needed in case of other alignments e.g., on 8-octet 771 boundaries. 773 3.3.2. Set Header Format 775 Every Set contains a common header. This header is defined in Figure 776 I. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Set ID | Length | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Figure I: Set Header Format 786 Each Set Header field is exported in big-endian format. The fields 787 are defined as follows: 789 Set ID 791 Identifies the Set. A value of 2 is reserved for Template Sets. 792 A value of 3 is reserved for Options Template Sets. Values from 4 793 to 255 are reserved for future use. Values 256 and above are used 794 for Data Sets. The Set ID values of 0 and 1 are not used, for 795 historical reasons [RFC3954]. 797 Length 799 Total length of the Set, in octets, including the Set Header, all 800 records, and the optional padding. Because an individual Set MAY 801 contain multiple records, the Length value MUST be used to 802 determine the position of the next Set. 804 3.4. Record Format 806 IPFIX defines three record formats, defined in the next sections: the 807 Template Record Format, the Options Template Record Format, and the 808 Data Record Format. 810 3.4.1. Template Record Format 812 One of the essential elements in the IPFIX record format is the 813 Template Record. Templates greatly enhance the flexibility of the 814 record format because they allow the Collecting Process to process 815 IPFIX Messages without necessarily knowing the interpretation of all 816 Data Records. A Template Record contains any combination of 817 IANA-assigned and/or enterprise-specific Information Element 818 identifiers. 820 The format of the Template Record is shown in Figure J. It consists 821 of a Template Record Header and one or more Field Specifiers. The 822 definition of the Field Specifiers is given in Figure G above. 824 +--------------------------------------------------+ 825 | Template Record Header | 826 +--------------------------------------------------+ 827 | Field Specifier | 828 +--------------------------------------------------+ 829 | Field Specifier | 830 +--------------------------------------------------+ 831 ... 832 +--------------------------------------------------+ 833 | Field Specifier | 834 +--------------------------------------------------+ 836 Figure J: Template Record Format 838 The format of the Template Record Header is shown in Figure K. 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Template ID (> 255) | Field Count | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Figure K: Template Record Header Format 848 The Template Record Header Field Definitions are as follows: 850 Template ID 852 Each Template Record is given a unique Template ID in the range 853 256 to 65535. This uniqueness is local to the Transport Session 854 and Observation Domain that generated the Template ID. Since 855 Template IDs are used as Set IDs in the Sets they describe (see 856 section 3.4.3), values 0-255 are reserved for special Set types 857 (e.g. Template Sets themselves), and Templates and Options 858 Templates (see section 3.4.2) cannot share Template IDs within a 859 Transport Session and Observation Domain. There are no constraints 860 regarding the order of the Template ID allocation. As Exporting 861 Processes are free to allocate Template IDs as they see fit, 862 Collecting Processes MUST NOT assume incremental Template IDs, or 863 anything about the contents of a Template based on its Template ID 864 alone. 866 Field Count 868 Number of fields in this Template Record. 870 The example in Figure L shows a Template Set with mixed IANA-assigned 871 and enterprise-specific Information Elements. It consists of a Set 872 Header, a Template Header, and several Field Specifiers. 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Set ID = 2 | Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Template ID = 256 | Field Count = N | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 |1| Information Element id. 1.1 | Field Length 1.1 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Enterprise Number 1.1 | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 |0| Information Element id. 1.2 | Field Length 1.2 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | ... | ... | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |1| Information Element id. 1.N | Field Length 1.N | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Enterprise Number 1.N | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Template ID = 257 | Field Count = M | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |0| Information Element id. 2.1 | Field Length 2.1 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |1| Information Element id. 2.2 | Field Length 2.2 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Enterprise Number 2.2 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | ... | ... | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 |1| Information Element id. 2.M | Field Length 2.M | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Enterprise Number 2.M | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Padding (opt) | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure L: Template Set Example 912 Information Element Identifiers 1.2 and 2.1 appear in [IPFIX-IANA] 913 (Enterprise bit = 0) and, therefore, do not need an Enterprise Number 914 to identify them. 916 3.4.2. Options Template Record Format 918 Thanks to the notion of scope, The Options Template Record gives the 919 Exporter the ability to provide additional information to the 920 Collector that would not be possible with Flow Records alone. 922 See Section 4 for specific Options Templates used for reporting 923 metadata about IPFIX Exporting and Metering Processes. 925 3.4.2.1. Scope 927 The scope, which is only available in the Options Template Set, gives 928 the context of the reported Information Elements in the Data 929 Records. 931 The scope is one or more Information Elements, specified in the 932 Options Template Record. Collecting Processes SHOULD support as 933 scope, at minimum, the observationDomainId, exportingProcessId, 934 meteringProcessId, templateId, lineCardId, exporterIPv4Address, 935 exporterIPv6Address, and ingressInterface Information Elements. The 936 IPFIX protocol doesn't prevent the use of any Information Elements 937 for scope. However, some Information Element types don't make sense 938 if specified as scope; for example, the counter Information Elements. 940 The IPFIX Message Header already contains the Observation Domain ID. 941 If not zero, this Observation Domain ID can be considered as an 942 implicit scope for the Data Records in the IPFIX Message. 944 Multiple Scope Fields MAY be present in the Options Template Record, 945 in which case, the composite scope is the combination of the scopes. 946 For example, if the two scopes are meteringProcessId and templateId, 947 the combined scope is this Template for this Metering Process. If a 948 different order of Scope Fields would result in a Record having a 949 different semantic meaning, then the order of Scope Fields MUST be 950 preserved by the Exporting Process. For example, in the context of 951 PSAMP [RFC5476], if the first scope defines the filtering function, 952 while the second scope defines the sampling function, the order of 953 the scope is important. Applying the sampling function first, 954 followed by the filtering function, would lead to potentially 955 different Data Records than applying the filtering function first, 956 followed by the sampling function. 958 3.4.2.2. Options Template Record Format 960 An Options Template Record contains any combination of IANA-assigned 961 and/or enterprise-specific Information Element identifiers. 963 The format of the Options Template Record is shown in Figure M. It 964 consists of an Options Template Record Header and one or more Field 965 Specifiers. The definition of the Field Specifiers is given in 966 Figure G above. 968 +--------------------------------------------------+ 969 | Options Template Record Header | 970 +--------------------------------------------------+ 971 | Field Specifier | 972 +--------------------------------------------------+ 973 | Field Specifier | 974 +--------------------------------------------------+ 975 ... 976 +--------------------------------------------------+ 977 | Field Specifier | 978 +--------------------------------------------------+ 980 Figure M: Options Template Record Format 982 The format of the Options Template Record Header is shown in Figure 983 N. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Template ID (> 255) | Field Count | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Scope Field Count | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Figure N: Options Template Record Header Format 995 The Options Template Record Header Field Definitions are as follows: 997 Template ID 999 Each Options Template Record is given a unique Template ID in the 1000 range 256 to 65535. This uniqueness is local to the Transport 1001 Session and Observation Domain that generated the Template ID. 1002 Since Template IDs are used as Set IDs in the sets they describe 1003 (see section 3.4.3), values 0-255 are reserved for special Set 1004 types (e.g. Template Sets themselves), and Templates and Options 1005 Templates cannot share Template IDs within a Transport Session and 1006 Observation Domain. There are no constraints regarding the order 1007 of the Template ID allocation. As Exporting Processes are free to 1008 allocate Template IDs as they see fit, Collecting Processes MUST 1009 NOT assume incremental Template IDs, or anything about the 1010 contents of an Options Template based on its Template ID alone. 1012 Field Count 1014 Number of all fields in this Options Template Record, including 1015 the Scope Fields. 1017 Scope Field Count 1019 Number of scope fields in this Options Template Record. The Scope 1020 Fields are normal Fields except that they are interpreted as scope 1021 at the Collector. A scope field count of N specifies that the 1022 first N Field Specifiers in the Template Record are Scope Fields. 1023 The Scope Field Count MUST NOT be zero. 1025 The example in Figure O shows an Options Template Set with mixed 1026 IANA-assigned and enterprise-specific Information Elements. It 1027 consists of a Set Header, a Options Template Header, and several 1028 Field Specifiers. 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Set ID = 3 | Length | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Template ID = 258 | Field Count = N + M | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Scope 2 Field Length | ... | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | ... |1| Scope N Infor. Element Id. | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Scope N Field Length | Scope N Enterprise Number ... 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Option 1 Field Length | Option 1 Enterprise Number ... 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 ... Option 1 Enterprise Number | ... | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | ... |0| Option M Infor. Element Id. | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Option M Field Length | Padding (optional) | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Figure O: Options Template Set Example 1060 3.4.3. Data Record Format 1062 The Data Records are sent in Data Sets. The format of the Data 1063 Record is shown in Figure P. It consists only of one or more Field 1064 Values. The Template ID to which the Field Values belong is encoded 1065 in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 1067 +--------------------------------------------------+ 1068 | Field Value | 1069 +--------------------------------------------------+ 1070 | Field Value | 1071 +--------------------------------------------------+ 1072 ... 1073 +--------------------------------------------------+ 1074 | Field Value | 1075 +--------------------------------------------------+ 1077 Figure P: Data Record Format 1079 Note that Field Values do not necessarily have a length of 16 bits. 1080 Field Values are encoded according to their data type specified in 1081 [RFC5102bis]. 1083 Interpretation of the Data Record format can be done only if the 1084 Template Record corresponding to the Template ID is available at the 1085 Collecting Process. 1087 The example in Figure Q shows a Data Set. It consists of a Set Header 1088 and several Field Values. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Set ID = Template ID | Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Record 1 - Field Value 3 | ... | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Record 2 - Field Value 3 | ... | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Record 3 - Field Value 3 | ... | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | ... | Padding (optional) | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure Q: Data Set, containing Data Records 1112 4. Specific Reporting Requirements 1114 Some specific Options Templates and Options Template Records are 1115 necessary to provide extra information about the Flow Records and 1116 about the Metering Process. 1118 The Options Template and Options Template Records defined in these 1119 subsections, which impose some constraints on the Metering Process 1120 and Exporting Process implementations, MAY be implemented. If 1121 implemented, the specific Options Templates SHOULD be implemented as 1122 specified in these subsections. 1124 The minimum set of Information Elements is always specified in these 1125 Specific IPFIX Options Templates. Nevertheless, extra Information 1126 Elements may be used in these specific Options Templates. 1128 The Collecting Process MUST check the possible combinations of 1129 Information Elements within the Options Template Records to correctly 1130 interpret the following Options Templates. 1132 4.1. The Metering Process Statistics Options Template 1134 The Metering Process Statistics Options Template specifies the 1135 structure of a Data Record for reporting Metering Process statistics. 1136 It SHOULD contain the following Information Elements; see [IPFIX- 1137 IANA] for their definitions 1138 (scope) observationDomainId 1139 This Information Element MUST be defined as a 1140 Scope Field, and MUST be present unless the 1141 Observation Domain ID of the enclosing 1142 Message is non-zero. 1144 (scope) meteringProcessId 1145 If present, this Information Element MUST be 1146 defined as a Scope Field. 1148 exportedMessageTotalCount 1150 exportedFlowRecordTotalCount 1152 exportedOctetTotalCount 1154 The Exporting Process SHOULD export the Data Record specified by the 1155 Metering Process Statistics Options Template on a regular basis or 1156 based on some export policy. This periodicity or export policy 1157 SHOULD be configurable. 1159 Note that if several Metering Processes are available on the Exporter 1160 Observation Domain, the Information Element meteringProcessId MUST be 1161 specified as an additional Scope Field. 1163 4.2. The Metering Process Reliability Statistics Options Template 1165 The Metering Process Reliability Options Template specifies the 1166 structure of a Data Record for reporting lack of reliability in the 1167 Metering Process. It SHOULD contain the following Information 1168 Elements defined in [IPFIX-IANA]: 1170 (scope) observationDomainId 1171 This Information Element MUST be defined as a 1172 Scope Field, and MUST be present unless the 1173 Observation Domain ID of the enclosing 1174 Message is non-zero. 1176 (scope) meteringProcessId 1177 If present, this Information Element MUST be 1178 defined as a Scope Field. 1180 ignoredPacketTotalCount 1182 ignoredOctetTotalCount 1183 time first packet ignored 1184 The timestamp of the first packet that was 1185 ignored by the Metering Process. For this 1186 timestamp, any of the following timestamp 1187 Information Elements can be used: 1188 observationTimeSeconds, 1189 observationTimeMilliseconds, 1190 observationTimeMicroseconds, or 1191 observationTimeNanoseconds. 1193 time last packet ignored 1194 The timestamp of the last packet that was 1195 ignored by the Metering Process. For this 1196 timestamp, any of the following timestamp 1197 Information Elements can be used: 1198 observationTimeSeconds, 1199 observationTimeMilliseconds, 1200 observationTimeMicroseconds, or 1201 observationTimeNanoseconds. 1203 The Exporting Process SHOULD export the Data Record specified by the 1204 Metering Process Reliability Statistics Options Template on a regular 1205 basis or based on some export policy. This periodicity or export 1206 policy SHOULD be configurable. 1208 Note that if several Metering Processes are available on the Exporter 1209 Observation Domain, the Information Element meteringProcessId MUST be 1210 specified as an additional Scope Field. 1212 Since the Metering Process Reliability Option Template contains two 1213 identical timestamp Information Elements, and since the order of the 1214 Information Elements in the Template Records is not guaranteed, the 1215 Collecting Process interprets the time interval of ignored packets as 1216 the range between the two values; see Section 5.2 for wraparound 1217 considerations. 1219 4.3. The Exporting Process Reliability Statistics Options Template 1221 The Exporting Process Reliability Options Template specifies the 1222 structure of a Data Record for reporting lack of reliability in the 1223 Exporting Process. It SHOULD contain the following Information 1224 Elements defined in [IPFIX-IANA]: 1226 (scope) Exporting Process ID 1227 The identifier of the Exporting Process for 1228 which reliability is reported. Any of the 1229 exporterIPv4Address, exporterIPv6Address, or 1230 exportingProcessId Information Elements can be 1231 used for this field. This Information Element 1232 MUST be defined as a Scope Field. 1234 notSentFlowTotalCount 1236 notSentPacketTotalCount 1238 notSentOctetTotalCount 1240 time first flow dropped 1241 The time at which the first Flow Record was 1242 dropped by the Exporting Process. For this 1243 timestamp, any of the following timestamp can be 1244 used: observationTimeSeconds, 1245 observationTimeMilliseconds, 1246 observationTimeMicroseconds, or 1247 observationTimeNanoseconds. 1249 time last flow dropped 1250 The time at which the last Flow Record was 1251 dropped by the Exporting Process. For this 1252 timestamp, any of the following timestamp can be 1253 used: observationTimeSeconds, 1254 observationTimeMilliseconds, 1255 observationTimeMicroseconds, or 1256 observationTimeNanoseconds. 1258 The Exporting Process SHOULD export the Data Record specified by the 1259 Exporting Process Reliability Statistics Options Template on a 1260 regular basis or based on some export policy. This periodicity or 1261 export policy SHOULD be configurable. 1263 Since the Exporting Process Reliability Option Template contains two 1264 identical timestamp Information Elements, and since the order of the 1265 Information Elements in the Template Records is not guaranteed, the 1266 Collecting Process interprets the time interval of ignored packets as 1267 the range between the two values; see Section 5.2 for wraparound 1268 considerations. 1270 4.4. The Flow Keys Options Template 1272 The Flow Keys Options Template specifies the structure of a Data 1273 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1274 Data Record extends a particular Template Record that is referenced 1275 by its templateId identifier. The Template Record is extended by 1276 specifying which of the Information Elements contained in the 1277 corresponding Data Records describe Flow properties that serve as 1278 Flow Keys of the reported Flow. 1280 The Flow Keys Options Template SHOULD contain the following 1281 Information Elements that are defined in [IPFIX-IANA]: 1283 (scope) templateId This Information Element MUST be defined as a 1284 Scope Field. 1286 flowKeyIndicator 1288 5. Timing Considerations 1290 5.1 IPFIX Message Header Export Time and Flow Record Time 1292 The IPFIX Message Header Export Time field is the time at which the 1293 IPFIX Message Header leaves the Exporter, using the same encoding as 1294 the dateTimeSeconds abstract data type [RFC5102bis], i.e., expressed 1295 in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded 1296 as an unsigned 32-bit integer. 1298 Certain time-related Information Elements may be expressed as an 1299 offset from this Export Time. For example, Data Records requiring a 1300 microsecond precision can export the flow start and end times with 1301 the flowStartMicroseconds and flowEndMicroseconds Information 1302 Elements, which encode the absolute time in microseconds in terms of 1303 the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An 1304 alternate solution is to export the flowStartDeltaMicroseconds and 1305 flowEndDeltaMicroseconds Information Elements in the Data Record, 1306 which respectively report the flow start and end time as negative 1307 offsets from the Export Time, as an unsigned 32-bit integer. This 1308 latter solution lowers the export bandwidth requirement, saving four 1309 bytes per timestamp, while increasing the load on the Exporter, as 1310 the Exporting Process must calculate the flowStartDeltaMicroseconds 1311 and flowEndDeltaMicroseconds of every single Data Record before 1312 exporting the IPFIX Message. 1314 It must be noted that timestamps based on the Export Time impose some 1315 time constraints on the Data Records contained within the IPFIX 1316 Message. In the example of flowStartDeltaMicroseconds and 1317 flowEndDeltaMicroseconds Information Elements, the Data Record can 1318 only contain records with timestamps within 71 minutes of the Export 1319 Time. Otherwise, the 32-bit counter would not be sufficient to 1320 contain the flow start time offset. 1322 5.2 Supporting Timestamp Wraparound 1324 The dateTimeSeconds abstract data type [RFC5102bis] and the Export 1325 Time Message Header field (Section 3.1) are encoded as 32-bit 1326 unsigned integers, expressed as seconds since the UNIX epoch, 1 1327 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will 1328 wrap around on 7 February 2106 at 06:28:16 UTC. 1330 In order to support continued use of the IPFIX Protocol beyond this 1331 date, Exporting Processes SHOULD export dateTimeSeconds values and 1332 the Export Time Message Header field as the number of seconds since 1333 the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting 1334 Processes SHOULD use the current date, or other contextual 1335 information, to properly interpret dateTimeSeconds values and the 1336 Export Time Message Header field. 1338 There are similar considerations for the NTP-based 1339 dateTimeMicroseconds and dateTimeNanoseconds abstract data types 1340 [RFC5102bis]. Exporting Processes SHOULD export dateTimeMicroseconds 1341 and dateTimeNanoseconds values as if the NTP Era [RFC5905] is 1342 implicit; Collecting Processes SHOULD use the current date, or other 1343 contextual information, to determine the NTP Era in order to properly 1344 interpret dateTimeMicroseconds and dateTimeNanoseconds values in 1345 received Data Records. 1347 The dateTimeMilliseconds abstract data type will wrap around in 1348 approximately 500 billion years; the specification of the behavior of 1349 this abstract data type after that time is left as a subject of a 1350 future revision of this specification. 1352 The long-term storage of files [RFC5655] for archival purposes is 1353 affected by timestamp wraparound, as the use of the current date to 1354 interpret timestamp values in files stored on the order of multiple 1355 decades in the past may lead to incorrect values; therefore, it is 1356 RECOMMENDED that such files be stored with contextual information to 1357 assist in the interpretation of these timestamps. 1359 6. Linkage with the Information Model 1361 As with values in the IPFIX Message Header and Set Header, values of 1362 all Information Elements [RFC5102bis], except for those of the string 1363 and octetArray data types, are encoded in canonical format in network 1364 byte order (also known as big-endian byte ordering). 1366 6.1. Encoding of IPFIX Data Types 1368 The following sections define the encoding of the data types 1369 specified in [RFC5102bis]. 1371 6.1.1. Integral Data Types 1373 Integral data types -- octet, signed8, unsigned16, signed16, 1374 unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded 1375 using the default canonical format in network byte order. Signed 1376 Integral data types are represented in two's complement notation. 1378 6.1.2. Address Types 1380 Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be 1381 encoded the same way as the integral data types, as six, four, and 1382 sixteen octets in network byte order, respectively. 1384 6.1.3. float32 1386 The float32 data type MUST be encoded as an IEEE single-precision 1387 32-bit floating point-type, as specified in [IEEE.754.1985], in 1388 network byte order. 1390 6.1.4. float64 1392 The float64 data type MUST be encoded as an IEEE double-precision 64- 1393 bit floating point-type, as specified in [IEEE.754.1985], in network 1394 byte order. 1396 6.1.5. boolean 1398 The boolean data type is specified according to the TruthValue in 1399 [RFC2579]. It is encoded as a single-octet integer, as in Section 1400 6.1.1., with the value 1 for true and a value 2 for false. Every 1401 other value is undefined. 1403 6.1.6. string and octetArray 1405 The data type string represents a finite length string of valid 1406 characters of the Unicode character encoding set. The string data 1407 type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as 1408 an array of zero or more octets using an Information Element of fixed 1409 or variable length. IPFIX Exporting Processes MUST NOT send IPFIX 1410 Messages containing ill-formed UTF-8 string values for Information 1411 Elements of the string data type; Collecting Processes SHOULD detect 1412 and ignore such values. See [UTF8-EXPLOIT] for background on this 1413 issue. 1415 The data type octetArray has no encoding rules; it represents a raw 1416 array of zero or more octets, with the interpretation of the octets 1417 defined in the Information Element definition. 1419 6.1.7. dateTimeSeconds 1421 The data type dateTimeSeconds is an unsigned 32-bit integer in 1422 network byte order containing the number of seconds since the UNIX 1423 epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 1424 dateTimeSeconds is encoded identically to the IPFIX Message Header 1425 Export Time field. It can represent dates between 1 January 1970 and 1426 7 February 2106 without wraparound; see section 5.2 for wraparound 1427 considerations. 1429 6.1.8. dateTimeMilliseconds 1431 The data type dateTimeMilliseconds is an unsigned 64-bit integer in 1432 network byte order, containing the number of milliseconds since the 1433 UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It 1434 can represent dates beginning on 1 January 1970 for approximately the 1435 next 500 billion years without wraparound. 1437 6.1.9 dateTimeMicroseconds 1439 The data type dateTimeMicroseconds is a 64-bit field encoded 1440 according to the NTP Timestamp format as defined in section 6 of 1441 [RFC5905]. This field is made up of two unsigned 32-bit integers in 1442 network byte order, Seconds and Fraction. The Seconds field is the 1443 number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. 1444 The Fraction field is the fractional number of seconds in units of 1445 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1446 dates beginning between 1 January 1900 and 8 February 2036 in the 1447 current NTP Era; see section 5.2 for wraparound considerations. 1449 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1450 identical encoding. The dateTimeMicroseconds data type is intended 1451 only to represent timestamps of microsecond precision. Therefore, the 1452 bottom 11 bits of the fraction field SHOULD be zero and MUST be 1453 ignored for all Information Elements of this data type (as 2^11 x 233 1454 picoseconds = .477 microseconds). 1456 6.1.10 dateTimeNanoseconds 1458 The data type dateTimeNanoseconds is a 64-bit field encoded according 1459 to the NTP Timestamp format as defined in section 6 of [RFC5905]. 1460 This field is made up of two unsigned 32-bit integers in network byte 1461 order, Seconds and Fraction. The Seconds field is the number of 1462 seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The 1463 Fraction field is the fractional number of seconds in units of 1464 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1465 dates beginning between 1 January 1900 and 8 February 2036 in the 1466 current NTP Era; see section 5.2 for wraparound considerations. 1468 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1469 identical encoding. There is no restriction on the interpretation of 1470 the Fraction field for the dateTimeNanoseconds data type. 1472 6.2. Reduced Size Encoding 1474 Information Elements encoded as signed, unsigned, or float data types 1475 MAY be encoded using fewer octets than those implied by their type in 1476 the information model definition, based on the assumption that the 1477 smaller size is sufficient to carry any value the Exporter may need 1478 to deliver. This reduces the network bandwidth requirement between 1479 the Exporter and the Collector. Note that the Information Element 1480 definitions [IPFIX-IANA] always define the maximum encoding size. 1482 For instance, the information model defines octetDeltaCount as an 1483 unsigned64 type, which would require 64 bits. However, if the 1484 Exporter will never locally encounter the need to send a value larger 1485 than 4294967295, it may chose to send the value instead as an 1486 unsigned32. 1488 This behavior is indicated by the Exporter by specifying a size in 1489 the Template with a smaller length than that associated with the 1490 assigned type of the Information Element. In the example above, the 1491 Exporter would place a length of 4 versus 8 in the Template. 1493 Reduced size encoding MAY be be applied to the following integer 1494 types: unsigned64, signed64, unsigned32, signed32, unsigned16, and 1495 signed16. The signed versus unsigned property of the reported value 1496 MUST be preserved. The reduction in size can be to any number of 1497 octets smaller than the original type if the data value still fits, 1498 i.e., so that only leading zeroes are dropped. For example, an 1499 unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). 1501 Reduced size encoding MAY be used to reduce float64 to float32. The 1502 float32 not only has a reduced number range, but due to the smaller 1503 mantissa, is also less precise. In this case, the float64 would be 1504 reduced in size to 4 octets. 1506 Reduced size encoding MUST NOT be applied to any other data type 1507 defined in [RFC5102bis] that implies a fixed length, as these types 1508 either have internal structure (such as ipv4Address or 1509 dateTimeMicroseconds) or restricted ranges that are not suitable for 1510 reduced length encoding (such as dateTimeMilliseconds). 1512 Information Elements of type octetArray and string may be exported 1513 using any length, subject to restrictions on length specific to each 1514 Information Element, as noted in that Information Element's 1515 description. 1517 7. Variable-Length Information Element 1519 The IPFIX Template mechanism is optimized for fixed-length 1520 Information Elements [RFC5102bis]. Where an Information Element has 1521 a variable length, the following mechanism MUST be used to carry the 1522 length information for both the IANA and enterprise-specific 1523 Information Elements. 1525 In the Template Set, the Information Element Field Length is recorded 1526 as 65535. This reserved length value notifies the Collecting Process 1527 that length of the Information Element will be carried in the 1528 Information Element content itself. 1530 In most cases, the length of the Information Element will be less 1531 than 255 octets. The following length-encoding mechanism optimizes 1532 the overhead of carrying the Information Element length in this 1533 majority case. The length is carried in the octet before the 1534 Information Element, as shown in Figure R. 1536 0 1 2 3 1537 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 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Length (< 255)| Information Element | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | ... continuing as needed | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 Figure R: Variable-Length Information Element (length < 255 octets) 1546 The length may also be encoded into 3 octets before the Information 1547 element allowing the length of the Information Element to be greater 1548 than or equal to 255 octets. In this case, first octet of the Length 1549 field MUST be 255, and the length is carried in the second and third 1550 octets, as shown in Figure S. 1552 0 1 2 3 1553 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 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | 255 | Length (0 to 65535) | IE | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | ... continuing as needed | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 Figure S: Variable-Length Information Element (length 0 to 65535 1561 octets) 1563 The octets carrying the length (either the first or the first three 1564 octets) MUST NOT be included in the length of the Information 1565 Element. 1567 8. Template Management 1569 This section describes the management of Templates and Options 1570 Templates at the Exporting and Collecting Processes. The goal of 1571 Template management is to ensure, to the extent possible, that the 1572 Exporting Process and Collecting Process have a consistent view of 1573 the Templates and Options Templates used to encode and decode the 1574 Records sent from the Exporting Process to the Collecting Process. 1575 Achieving this goal is complicated somewhat by two factors: 1. the 1576 need to support the reuse of Template IDs within a Transport Session 1577 and 2. the need to support unreliable transmission for Templates when 1578 UDP is used as the transport protocol for IPFIX Messages. 1580 The Template Management mechanisms defined in this section apply to 1581 IPFIX Messages export on SCTP, TCP, or UDP. Additional considerations 1582 specific to SCTP and UDP transport are given in sections 8.3 and 8.4, 1583 respectively. 1585 The Exporting Process assigns and maintains Template IDs per 1586 Transport Session and Observation Domain. A newly created Template 1587 Record is assigned an unused Template ID by the Exporting Process. 1588 The Collecting Process MUST store all received Template Record 1589 information for the duration of each Transport Session until reuse or 1590 withdrawal as in section 8.1, or expiry over UDP as in section 8.4, 1591 so that it can interpret the corresponding Data Records. 1593 The Collecting Process MUST NOT assume that the Template IDs from a 1594 given Exporting Process refer to the same Templates as they did in 1595 previous Transport Sessions from the same Exporting Process; a 1596 Collecting Process MUST NOT use Templates from one Transport Session 1597 to decode Data Sets in a subsequent Transport Session. 1599 If a specific Information Element is required by a Template, but is 1600 not present in observed packets, the Exporting Process MAY choose to 1601 export Flow Records without this Information Element in a Data Record 1602 described by a new Template. 1604 If an Information Element is required more than once in a Template, 1605 the different occurrences of this Information Element SHOULD follow 1606 the logical order of their treatments by the Metering Process. For 1607 example, if a selected packet goes through two hash functions, and if 1608 the two hash values are sent within a single Template, the first 1609 occurrence of the hash value should belong to the first hash function 1610 in the Metering Process. For example, when exporting the two source 1611 IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address 1612 Information Element occurrence should be the IPv4 address of the 1613 outer header, while the second occurrence should be the address of 1614 the inner header. Collecting Processes MUST properly handle Templates 1615 with multiple identical Information Elements. 1617 The Exporting Process SHOULD transmit the Template Set and Options 1618 Template Set in advance of any Data Sets that use that (Options) 1619 Template ID, to help ensure that the Collector has the Template 1620 Record before receiving the first Data Record. Data Records that 1621 correspond to a Template Record MAY appear in the same and/or 1622 subsequent IPFIX Message(s). However, a Collecting Process MUST NOT 1623 assume that the Data Set and the associated Template Set (or Options 1624 Template Set) are exported in the same IPFIX Message. 1626 Though a Collecting Process normally receives Template Records from 1627 the Exporting Process before receiving Data Records, this is not 1628 always the case, e.g. in case of reordering or Collecting Process 1629 restart over UDP. In these cases, the Collecting Process MAY buffer 1630 Data Records for which it has no Templates to wait for Template 1631 Records describing them; however, note that in the presence of 1632 Template withdrawal and redefinition (Section 8.1) this may lead to 1633 incorrect interpretation of Data Records. 1635 Different Observation Domains within a Transport Session MAY use the 1636 same Template ID value to refer to different Templates; Collecting 1637 Processes MUST properly handle this case. 1639 Options Templates and Templates which are related or interdependent 1640 (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent 1641 together in the same IPFIX Message. 1643 8.1. Template Withdrawal and Redefinition 1645 Templates that will not be used further by an Exporting Process MAY 1646 be withdrawn by sending a Template Withdrawal. After receiving a 1647 Template Withdrawal, a Collecting Process MUST stop using the 1648 Template to interpret subsequently-exported Data Sets. Note that this 1649 mechanism does not apply when UDP is used to transport IPFIX 1650 Messages; for this case, see Section 8.4. 1652 A Template Withdrawal consists of a Template Record for the Template 1653 ID to be withdrawn, with a Field Count of 0. The format of a Template 1654 Withdrawal is shown in Figure T. 1656 0 1 2 3 1657 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 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | Set ID = (2 or 3) | Length = 16 | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Template ID N | Field Count = 0 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Template ID ... | Field Count = 0 | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Template ID M | Field Count = 0 | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 Figure T: Template Withdrawal Format 1670 The Set ID field MUST contain the value 2 for Template Set Withdrawal 1671 and the value 3 for Options Template Set Withdrawal. Multiple 1672 Template IDs MAY be withdrawn with a single Template Withdrawal, in 1673 that case, padding MAY be used. 1675 Template Withdrawals MAY appear interleaved with Template Sets, 1676 Options Template Sets, and Data Sets within an IPFIX Message. In this 1677 case, the Templates and Template Withdrawals shall be taken to take 1678 effect in the order in which they appear in the IPFIX Message. An 1679 Exporting Process SHOULD NOT send a Template Withdrawal until 1680 sufficient time has elapsed to allow receipt and processing of any 1681 Data Records described by the withdrawn Templates; see Section 8.2 on 1682 sequencing of Template management actions. 1684 The end of a Transport Session implicitly withdraws all the Templates 1685 used within the Transport Session, and Templates must be resent 1686 during subsequent Transport Sessions between an Exporting Process and 1687 Collecting Process. This applies to SCTP and TCP only; see sections 1688 8.4 and 10.3.4 for a discussion of Transport Session and Template 1689 lifetime over UDP. 1691 All Templates for a given Observation Domain MAY also be withdrawn 1692 using an All Templates Withdrawal, shown in Figure U. All Options 1693 Templates for a given Observation Domain MAY likewise be withdrawn 1694 using an All Options Templates Withdrawal, shown in Figure 3. 1696 0 1 2 3 1697 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 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Set ID = 2 | Length = 8 | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | Template ID = 2 | Field Count = 0 | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 Figure U: All Templates Withdrawal Set Format 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Set ID = 3 | Length = 8 | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Template ID = 3 | Field Count = 0 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 Figure V: All Options Templates Withdrawal Set Format 1716 Template IDs MAY be reused for new Templates by sending a new 1717 Template Record or Options Template Record for a given Template ID 1718 after withdrawing the Template. 1720 If a Collecting Process receives a Template Withdrawal for a Template 1721 or Options Template it does not presently have stored, this indicates 1722 a malfunctioning or improperly-implemented Exporting Process. The 1723 continued receipt and interpretation of Data Records is still 1724 possible, but it MUST ignore the Template Withdrawal and SHOULD log 1725 the error. 1727 If a Collecting Process receives a new Template Record or Options 1728 Template Record for an already-allocated Template ID, and that 1729 Template or Options Template is identical to the already-received 1730 Template or Options Template, it SHOULD log the retransmission; 1731 however, this is not an error condition, as it does not affect the 1732 interpretation of data records. 1734 If a Collecting Process receives a new Template Record or Options 1735 Template Record for an already-allocated Template ID, and that 1736 Template or Options Template is different from the already-received 1737 Template or Options Template, this indicates a malfunctioning or 1738 improperly-implemented Exporting Process. The continued receipt and 1739 unambiguous interpretation of Data Records for this Template ID is no 1740 longer possible, the Collecting Process SHOULD log the error; further 1741 Collecting Process actions are out of scope of this specification. 1743 8.2 Sequencing Template Management Actions 1745 Since there is no guarantee of the ordering of exported IPFIX 1746 Messages across SCTP Streams or over UDP, an Exporting Process MUST 1747 sequence all Template management actions (i.e., Template Records 1748 defining new Templates and Template Withdrawals withdrawing them) 1749 using the Export Time field in the IPFIX Message Header. 1751 An Exporting Process MUST NOT export a Data Set described by a new 1752 Template in an IPFIX Message with an Export Time before the Export 1753 Time of the IPFIX Message containing that Template. If a new Template 1754 and a Data Set described by it appear in the same IPFIX Message, the 1755 Template Set containing the Template MUST appear before the Data Set 1756 in the Message. 1758 An Exporting Process MUST NOT export any Data Sets described by a 1759 withdrawn Template in IPFIX Messages with an Export Time after the 1760 Export Time of the IPFIX Message containing the Template Withdrawal 1761 withdrawing that Template. 1763 Put another way, a Template describes Data Records contained in IPFIX 1764 Messages with an Export Time between the Export Time of the IPFIX 1765 Message containing the Template Record and either the Export Time of 1766 the IPFIX Message containing the Template Withdrawal withdrawing it 1767 or the end of the Transport Session, inclusive. 1769 Even if sent in-order, IPFIX Messages containing Template management 1770 actions could arrive at the Collecting Process out-of-order, i.e. if 1771 sent via UDP or via different SCTP streams. Given this, Template 1772 Withdrawals and subsequent reuse of Template IDs can significantly 1773 complicate the problem of determining Template lifetimes at the 1774 Collecting Process. A Collecting Process MAY implement a buffer and 1775 use Export Time information to disambiguate the order of Template 1776 management actions. This buffer, if implemented, SHOULD be 1777 configurable to impart a delay on the order of the maximum reordering 1778 delay experienced at the Collecting Process. Note, in this case, that 1779 the Collecting Process' clock is irrelevant: it is only comparing the 1780 Export Times of Messages to each other. 1782 8.3. Additional considerations for Template Management over SCTP 1784 The specifications in this section apply only to SCTP; in case of 1785 contradiction with specifications in Sections 8 or 8.1, this section 1786 takes precedence. 1788 Template Sets and Options Template Sets MAY be sent on any SCTP 1789 stream. Data Sets sent on a given SCTP stream MAY be represented by 1790 Template Records exported on any SCTP stream. 1792 Template Sets and Options Template Sets MUST be sent reliably, using 1793 SCTP ordered delivery. 1795 Template Withdrawals MAY be sent on any SCTP stream. Template 1796 Withdrawals MUST be sent reliably, using SCTP ordered delivery. 1797 Template IDs MAY be reused by sending a Template Withdrawal and/or a 1798 new Template Record on a different SCTP stream than the stream on 1799 which the original Template was sent. 1801 Additional Template Management considerations are given in [RFC6526], 1802 which specifies an extension to explicitly link Templates with SCTP 1803 streams. In exchange for more restrictive rules on the assignment of 1804 Template Records to SCTP streams, this extension allows fast, 1805 reliable reuse of Template IDs and estimation of Data Record loss per 1806 Template. 1808 8.4. Additional considerations for Template Management over UDP 1810 The specifications in this section apply only to UDP; in case of 1811 contradiction with specifications in Sections 8 or 8.1, this section 1812 takes precedence. 1814 Since UDP provides no method for reliable transmission of Templates, 1815 Exporting Processes using UDP as the Transport Protocol MUST 1816 periodically retransmit each active Template at regular intervals. 1817 The Template retransmission interval MUST be configurable, as via the 1818 the templateRefreshTimeout and optionsTemplateRefreshTimeout defined 1819 in [RFC6728]. Default settings for these values are deployment- and 1820 application-specific. 1822 Before exporting any Data Records described by a given Template 1823 Record or Options Template Record, especially in the case of Template 1824 ID reuse as in section 8.1, the Exporting Process SHOULD send 1825 multiple copies of the Template Record in separate IPFIX Message, in 1826 order to help ensure the Collecting Process has received it. 1828 In order to minimize resource requirements for Templates which are no 1829 longer being used by the Exporting Process, the Collecting Process 1830 MAY associate a lifetime with each Template received in a UDP 1831 Transport Session. Templates not refreshed by the Exporting Process 1832 within the lifetime can then be discarded by the Collecting Process. 1833 The Template lifetime at the Collecting Process MAY be exposed by a 1834 configuration parameter, or MAY be derived from observation of the 1835 interval of periodic Template retransmissions from the Exporting 1836 Process. In this latter case, the Template lifetime SHOULD default to 1837 at least 3 times the observed retransmission rate. 1839 Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting 1840 Processes exporting via UDP, and MUST be ignored by Collecting 1841 Processes collecting via UDP. Template IDs MAY be reused by Exporting 1842 Processes by exporting a new Template for the Template ID after 1843 waiting at least 3 times the retransmission rate. Note that Template 1844 ID reuse may lead to incorrect interpretation of Data Records if the 1845 retransmission and lifetime are not properly configured. 1847 When a Collecting Process receives a new Template Record or Options 1848 Template Record via UDP for an already-allocated Template ID, and 1849 that Template or Options Template is identical to the already- 1850 received Template or Options Template, it SHOULD NOT log the 1851 retransmission, as this is the normal operation of Template refresh 1852 over UDP. 1854 When a Collecting Process receives a new Template Record or Options 1855 Template Record for an already-allocated Template ID, and that 1856 Template or Options Template is different from the already-received 1857 Template or Options Template, the Collecting Process MUST replace the 1858 Template or Options Template for that Template ID with the newly- 1859 received Template or Options Template. This is the normal operation 1860 of Template ID reuse over UDP. 1862 As Template IDs are unique per UDP session and per Observation 1863 Domain, at any given time, the Collecting Process SHOULD maintain the 1864 following for all the current Template Records and Options Template 1865 Records: . 1869 9. The Collecting Process's Side 1871 This section describes the handling of the IPFIX Protocol at the 1872 Collecting Process common to all Transport Protocols. Additional 1873 considerations for SCTP and UDP are given in Sections 9.1 and 9.2 1874 respectively. Template management at Collecting Processes is covered 1875 in Section 8. 1877 The Collecting Process MUST listen for association requests / 1878 connections to start new Transport Sessions from the Exporting 1879 Process. 1881 The Collecting Process MUST note the Information Element identifier 1882 of any Information Element that it does not understand and MAY 1883 discard that Information Element from received Data Records. 1885 The Collecting Process MUST accept padding in Data Records and 1886 Template Records. The padding size is the Set Length minus the size 1887 of the Set Header (4 octets for the Set ID and the Set Length), 1888 modulo the Record size deduced from the Template Record. 1890 The IPFIX protocol has a Sequence Number field in the Export header 1891 that increases with the number of IPFIX Data Records in the IPFIX 1892 Message. A Collector can detect out-of-sequence, dropped, or 1893 duplicate IPFIX Messages by tracking the Sequence Number. A 1894 Collector SHOULD provide a logging mechanism for tracking out-of- 1895 sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be 1896 due to Exporter resource exhaustion where it cannot transmit messages 1897 at their creation rate, an Exporting Process reset, congestion on the 1898 network link between the Exporter and Collector, Collector resource 1899 exhaustion where it cannot process the IPFIX Messages at their 1900 arrival rate, out-of-order packet reception, duplicate packet 1901 reception, or an attacker injecting false messages. 1903 If the Collecting Process receives a malformed IPFIX Message it MUST 1904 discard the IPFIX Message and SHOULD log the error. A malformed IPFIX 1905 Message is one that cannot be interpreted due to nonsensical length 1906 values (e.g., a variable length Information Element longer than its 1907 enclosing Set, a Set longer than its enclosing IPFIX Message, an 1908 IPFIX Message shorter than an IPFIX Message Header) or a reserved 1909 Version value (which may indicate a future version of IPFIX is being 1910 used for export, but practically occurs most often when non-IPFIX 1911 data is sent to an IPFIX Collecting Process). Note that non-zero Set 1912 padding does not constitute a malformed IPFIX Message. 1914 9.1. Additional considerations for SCTP Collecting Processes 1916 As an Exporting Process may request and support more than one stream 1917 per SCTP association, the Collecting Process MUST support the opening 1918 of multiple SCTP streams. 1920 9.2. Additional considerations for UDP Collecting Processes 1922 A Transport Session for IPFIX Messages transported over UDP is 1923 defined from the point of view of the Exporting Process, and roughly 1924 corresponds to the time during which a given Exporting Process sends 1925 IPFIX Messages over UDP to a given Collecting Process. Since this is 1926 difficult to detect at the Collecting Process, the Collecting Process 1927 MAY discard all Transport Session state after no IPFIX Messages are 1928 received from a given Exporting Process within a given Transport 1929 Session during a configurable idle timeout. 1931 The Collecting Process SHOULD accept Data Records without the 1932 associated Template Record (or other definitions such as Common 1933 Properties) required to decode the Data Record. If the Template 1934 Records or other definitions have not been received at the time Data 1935 Records are received, the Collecting Process MAY store the Data 1936 Records for a short period of time and decode them after the Template 1937 Records or other definitions are received, comparing Export Times of 1938 IPFIX Messages containing the Template Records with those containing 1939 the Data Records as in Section 8.2. Note that this mechanism may lead 1940 to incorrectly interpreted records in the presence of Template ID 1941 reuse or other identifiers with limited lifetimes. 1943 10. Transport Protocol 1945 The IPFIX Protocol Specification has been designed to be transport 1946 protocol independent. Note that the Exporter can export to multiple 1947 Collecting Processes using independent transport protocols. 1949 The IPFIX Message Header 16-bit Length field limits the length of an 1950 IPFIX Message to 65535 octets, including the header. A Collecting 1951 Process MUST be able to handle IPFIX Message lengths of up to 65535 1952 octets. 1954 10.1. Transport Compliance and Transport Usage 1956 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 1957 MUST be implemented by all compliant implementations. UDP [UDP] MAY 1958 also be implemented by compliant implementations. TCP [TCP] MAY also 1959 be implemented by compliant implementations. 1961 SCTP should be used in deployments where Exporters and Collectors are 1962 communicating over links that are susceptible to congestion. SCTP is 1963 capable of providing any required degree of reliability when used 1964 with the PR-SCTP extension. 1966 TCP may be used in deployments where Exporters and Collectors 1967 communicate over links that are susceptible to congestion, but SCTP 1968 is preferred due to its ability to limit back pressure on Exporters 1969 and its message versus stream orientation. 1971 UDP may be used, although it is not a congestion-aware protocol. 1972 However, in this case the IPFIX traffic between Exporter and 1973 Collector must be separately contained or provisioned to minimize the 1974 risk of congestion-related loss. 1976 By default, the Collecting Process listens for connections on SCTP, 1977 TCP, and/or UDP port 4739. By default, the Collecting Process listens 1978 for secure connections on SCTP, TCP, and/or UDP port 4740 (refer to 1979 the Security Considerations section). By default, the Exporting 1980 Process attempts to connect to one of these ports. It MUST be 1981 possible to configure both the Exporting and Collecting Processes to 1982 use different ports than the default. 1984 10.2. SCTP 1986 This section describes how IPFIX is transported over SCTP [RFC4960] 1987 using the PR-SCTP [RFC3758] extension. 1989 10.2.1. Congestion Avoidance 1991 The SCTP transport protocol provides the required level of congestion 1992 avoidance by design. 1994 SCTP detects congestion in the end-to-end path between the IPFIX 1995 Exporting Process and the IPFIX Collecting Process, and limits the 1996 transfer rate accordingly. When an IPFIX Exporting Process has 1997 records to export, but detects that transmission by SCTP is 1998 temporarily impossible, it can either wait until sending is possible 1999 again, or it can decide to drop the record. In the latter case, the 2000 dropped export data SHOULD be accounted for, so that the amount of 2001 dropped export data can be reported using the mechanism in Section 2002 4.3. 2004 10.2.2. Reliability 2006 The SCTP transport protocol is by default reliable, but has the 2007 capability to deliver messages with partial reliability [RFC3758]. 2009 Using reliable SCTP messages for the IPFIX export is not in itself a 2010 guarantee that all Data Records will be delivered. If there is 2011 congestion on the link from the Exporting Process to the Collecting 2012 Process, or if a significant number of retransmissions are required, 2013 the send queues on the Exporting Process may fill up; the Exporting 2014 Process MAY either suspend, export, or discard the IPFIX Messages. 2015 If Data Records are discarded the IPFIX Sequence Numbers used for 2016 export MUST reflect the loss of data. 2018 10.2.3. MTU 2020 SCTP provides the required IPFIX Message fragmentation service based 2021 on path MTU discovery. 2023 10.2.4. Association Establishment and Shutdown 2025 The IPFIX Exporting Process initiates an SCTP association with the 2026 IPFIX Collecting Process. The Exporting Process MAY establish more 2027 than one association (connection "bundle" in SCTP terminology) to the 2028 Collecting Process. 2030 An Exporting Process MAY support more than one active association to 2031 different Collecting Processes (including the case of different 2032 Collecting Processes on the same host). 2034 When an Exporting Process is shut down, it SHOULD shut down the SCTP 2035 association. 2037 When a Collecting Process no longer wants to receive IPFIX Messages, 2038 it SHOULD shut down its end of the association. The Collecting 2039 Process SHOULD continue to receive and process IPFIX Messages until 2040 the Exporting Process has closed its end of the association. 2042 When a Collecting Process detects that the SCTP association has been 2043 abnormally terminated, it MUST continue to listen for a new 2044 association establishment. 2046 When an Exporting Process detects that the SCTP association to the 2047 Collecting Process is abnormally terminated, it SHOULD try to 2048 re-establish the association. 2050 Association timeouts SHOULD be configurable. 2052 10.2.5. Failover 2054 If the Collecting Process does not acknowledge the attempt by the 2055 Exporting Process to establish an association, the Exporting Process 2056 should retry using the SCTP exponential backoff feature. The 2057 Exporter MAY log an alarm if the time to establish the association 2058 exceeds a specified threshold, configurable on the Exporter. 2060 If Collecting Process failover is supported by the Exporting Process, 2061 a second SCTP association MAY be opened in advance. 2063 10.2.6. Streams 2065 An Exporting Process MAY request more than one SCTP stream per 2066 association. Each of these streams may be used for the transmission 2067 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 2068 Template Sets. 2070 Depending on the requirements of the application, the Exporting 2071 Process may send Data Sets with full or partial reliability, using 2072 ordered or out-of-order delivery, over any SCTP stream established 2073 during SCTP Association setup. 2075 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 2076 per Section 4 of the PR-SCTP [RFC3758] specification when using 2077 partial reliability to transmit IPFIX Messages containing only Data 2078 Sets. 2080 However, Exporting Processes SHOULD mark such IPFIX Messages for 2081 retransmission for as long as resource or other constraints allow. 2083 10.3. UDP 2085 This section describes how IPFIX is transported over UDP [UDP]. 2087 10.3.1. Congestion Avoidance 2089 UDP has no integral congestion-avoidance mechanism. Its use over 2090 congestion-sensitive network paths is therefore not recommended. UDP 2091 MAY be used in deployments where Exporters and Collectors always 2092 communicate over dedicated links that are not susceptible to 2093 congestion, i.e., links that are over-provisioned compared to the 2094 maximum export rate from the Exporters. 2096 10.3.2. Reliability 2098 UDP is not a reliable transport protocol, and cannot guarantee 2099 delivery of messages. IPFIX Messages sent from the Exporting Process 2100 to the Collecting Process using UDP may therefore be lost. UDP MUST 2101 NOT be used unless the application can tolerate some loss of IPFIX 2102 Messages. 2104 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 2105 Data Records by looking at the discontinuities in the IPFIX Sequence 2106 Number. In the case of UDP, the IPFIX Sequence Number contains the 2107 total number of IPFIX Data Records sent for the UDP Transport Session 2108 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 2109 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 2110 by tracking the Sequence Number. 2112 Exporting Processes exporting IPFIX Messages via UDP MUST include a 2113 valid UDP checksum [UDP] in UDP datagrams including IPFIX messages. 2115 10.3.3. MTU 2117 The maximum size of exported messages MUST be configured such that 2118 the total packet size does not exceed the path MTU. If the path MTU 2119 is unknown, a maximum packet size of 512 octets SHOULD be used. 2121 10.3.4. Session Establishment and Shutdown 2123 As UDP is a connectionless protocol, there is no real session 2124 establishment or shutdown for IPFIX over UDP. An Exporting Process 2125 starts sending IPFIX Messages to a Collecting Process at one point in 2126 time, and stops sending them at another point in time. This can lead 2127 to some complications in Template management, which are outlined in 2128 Section 8.4 above. 2130 10.3.5. Failover and Session Duplication 2132 Because UDP is not a connection-oriented protocol, the Exporting 2133 Process is unable to determine from the transport protocol that the 2134 Collecting Process is no longer able to receive the IPFIX Messages. 2135 Therefore, it cannot invoke a failover mechanism. However, the 2136 Exporting Process MAY duplicate the IPFIX Message to several 2137 Collecting Processes. 2139 10.4. TCP 2141 This section describes how IPFIX is transported over TCP [TCP]. 2143 10.4.1. Congestion Avoidance 2145 TCP controls the rate at which data can be sent from the Exporting 2146 Process to the Collecting Process, using a mechanism that takes into 2147 account both congestion in the network and the capabilities of the 2148 receiver. 2150 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2151 Messages at the rate that the Metering Process generates them, either 2152 because of congestion in the network or because the Collecting 2153 Process cannot handle IPFIX Messages fast enough. As long as 2154 congestion is transient, the Exporting Process can buffer IPFIX 2155 Messages for transmission. But such buffering is necessarily limited, 2156 both because of resource limitations and because of timeliness 2157 requirements, so ongoing and/or severe congestion may lead to a 2158 situation where the Exporting Process is blocked. 2160 When an Exporting Process has Data Records to export but the 2161 transmission buffer is full, and it wants to avoid blocking, it can 2162 decide to drop some Data Records. The dropped Data Records MUST be 2163 accounted for, so that the number of lost records can later be 2164 reported as in Section 4.3. 2166 10.4.2. Reliability 2168 TCP ensures reliable delivery of data from the Exporting Process to 2169 the Collecting Process. 2171 10.4.3. MTU 2173 As TCP offers a stream service instead of a datagram or sequential 2174 packet service, IPFIX Messages transported over TCP are instead 2175 separated using the Length field in the IPFIX Message Header. The 2176 Exporting Process can choose any valid length for exported IPFIX 2177 Messages, as TCP handles segmentation. 2179 However, if an Exporting Process exports data from multiple 2180 Observation Domains, it should be careful to choose IPFIX Message 2181 lengths appropriately to minimize head-of-line blocking between 2182 different Observation Domains. Multiple TCP connections MAY be used 2183 to avoid head-of-line blocking between different Observation Domains. 2185 10.4.4. Connection Establishment and Shutdown 2187 The IPFIX Exporting Process initiates a TCP connection to the 2188 Collecting Process. An Exporting Process MAY support more than one 2189 active connection to different Collecting Processes (including the 2190 case of different Collecting Processes on the same host). 2192 The Exporter MAY log an alarm if the time to establish the connection 2193 exceeds a specified threshold, configurable on the Exporter. 2195 When an Exporting Process is shut down, it SHOULD shut down the TCP 2196 connection. 2198 When a Collecting Process no longer wants to receive IPFIX Messages, 2199 it SHOULD close its end of the connection. The Collecting Process 2200 SHOULD continue to read IPFIX Messages until the Exporting Process 2201 has closed its end. 2203 When a Collecting Process detects that the TCP connection to the 2204 Exporting Process has terminated abnormally, it MUST continue to 2205 listen for a new connection. 2207 When an Exporting Process detects that the TCP connection to the 2208 Collecting Process has terminated abnormally, it SHOULD try to 2209 re-establish the connection. Connection timeouts and retry schedules 2210 SHOULD be configurable. In the default configuration, an Exporting 2211 Process MUST NOT attempt to establish a connection more frequently 2212 than once per minute. 2214 10.4.5. Failover 2216 If the Collecting Process does not acknowledge an attempt by the 2217 Exporting Process to establish a connection, TCP will automatically 2218 retry connection establishment using exponential backoff. The 2219 Exporter MAY log an alarm if the time to establish the association 2220 exceeds a specified threshold, configurable on the Exporter. 2222 If Collecting Process failover is supported by the Exporting Process, 2223 a second TCP connection MAY be opened in advance. 2225 11. Security Considerations 2227 The security considerations for the IPFIX protocol have been derived 2228 from an analysis of potential security threats, as discussed in the 2229 "Security Considerations" section of IPFIX requirements [RFC3917]. 2230 The requirements for IPFIX security are as follows: 2232 1. IPFIX must provide a mechanism to ensure the confidentiality of 2233 IPFIX data transferred from an Exporting Process to a Collecting 2234 Process, in order to prevent disclosure of Flow Records 2235 transported via IPFIX. 2237 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2238 data transferred from an Exporting Process to a Collecting 2239 Process, in order to prevent the injection of incorrect data or 2240 control information (e.g., Templates), or the duplication of 2241 Messages, in an IPFIX Message stream. 2243 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2244 and Exporting Processes, to prevent the collection of data from an 2245 unauthorized Exporting Process or the export of data to an 2246 unauthorized Collecting Process. 2248 Because IPFIX can be used to collect information for network 2249 forensics and billing purposes, attacks designed to confuse, disable, 2250 or take information from an IPFIX collection system may be seen as a 2251 prime objective during a sophisticated network attack. 2253 An attacker in a position to inject false messages into an IPFIX 2254 Message stream can either affect the application using IPFIX (by 2255 falsifying data), or the IPFIX Collecting Process itself (by 2256 modifying or revoking Templates, or changing options); for this 2257 reason, IPFIX Message integrity is important. 2259 The IPFIX Messages themselves may also contain information of value 2260 to an attacker, including information about the configuration of the 2261 network as well as end-user traffic and payload data, so care must be 2262 taken to confine their visibility to authorized users. When an 2263 Information Element containing end-user payload information is 2264 exported, it SHOULD be transmitted to the Collecting Process using a 2265 means that secures its contents against eavesdropping. Suitable 2266 mechanisms include the use of either a direct point-to-point 2267 connection assumed to be unavailable to attackers, or the use of an 2268 encryption mechanism. It is the responsibility of the Collecting 2269 Process to provide a satisfactory degree of security for this 2270 collected data, including, if necessary, encryption and/or 2271 anonymization of any reported data; see Section 11.8. 2273 11.1. Applicability of TLS and DTLS 2275 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2276 Security (DTLS) [RFC6347] were designed to provide the 2277 confidentiality, integrity, and authentication assurances required by 2278 the IPFIX protocol, without the need for pre-shared keys. 2280 With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC6347] 2281 MUST be implemented. If UDP is selected as the IPFIX transport 2282 protocol, DTLS [RFC6347] MUST be implemented. If TCP is selected as 2283 the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. 2285 Note that DTLS is selected as the security mechanism for SCTP. Though 2286 TLS bindings to SCTP are defined in [RFC3436], they require all 2287 communication to be over reliable, bidirectional streams, and require 2288 one TLS connection per stream. This arrangement is not compatible 2289 with the rationale behind the choice of SCTP as an IPFIX transport 2290 protocol. 2292 Note that using DTLS [RFC6347] has a vulnerability, i.e., a true man 2293 in the middle may attempt to take data out of an association and fool 2294 the sender into thinking that the data was actually received by the 2295 peer. In generic TLS for SCTP (and/or TCP), this is not possible. 2296 This means that the removal of a message may become hidden from the 2297 sender or receiver. Another vulnerability of using SCTP with DTLS is 2298 that someone could inject SCTP control information to shut down the 2299 SCTP association, effectively generating a loss of IPFIX Messages if 2300 those are buffered outside of the SCTP association. Techniques such 2301 as [RFC6083] could be used to overcome these vulnerabilities. 2303 When using DTLS over SCTP, the Exporting Process MUST ensure that 2304 each IPFIX Message is sent over the same SCTP stream that would be 2305 used when sending the same IPFIX Message directly over SCTP. Note 2306 that DTLS may send its own control messages on stream 0 with full 2307 reliability; however, this will not interfere with the processing of 2308 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2309 consumes its own control messages before passing IPFIX Messages up to 2310 the application layer. 2312 When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] 2313 SHOULD be used, especially on long-lived Transport Sessions, to 2314 ensure that the association remains active. 2316 11.2. Usage 2318 The IPFIX Exporting Process initiates the communication to the IPFIX 2319 Collecting Process, and acts as a TLS or DTLS client according to 2320 [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a 2321 TLS or DTLS server. The DTLS client opens a secure connection on the 2322 SCTP port 4740 of the DTLS server if SCTP is selected as the 2323 transport protocol. The TLS client opens a secure connection on the 2324 TCP port 4740 of the TLS server if TCP is selected as the transport 2325 protocol. The DTLS client opens a secure connection on the UDP port 2326 4740 of the DTLS server if UDP is selected as the transport 2327 protocol. 2329 11.3. Mutual Authentication 2331 When using TLS or DTLS, IPFIX Exporting Processes and IPFIX 2332 Collecting Processes SHOULD be identified by a certificate containing 2333 the DNS-ID identifier as in Section 6.4 of [RFC6125]; the inclusion 2334 of Common Names (CN-IDs) in certificates identifying IPFIX Exporting 2335 Processes or Collecting Processes is NOT RECOMMENDED. 2337 To prevent man-in-the-middle attacks from impostor Exporting or 2338 Collecting Processes, the acceptance of data from an unauthorized 2339 Exporting Process, or the export of data to an unauthorized 2340 Collecting Process, mutual authentication MUST be used for both TLS 2341 and DTLS. Exporting Processes MUST verify the reference identifiers 2342 of the Collecting Processes they are exporting IPFIX messages to 2343 against those stored in the certificates. Likewise, Collecting 2344 Processes MUST verify the reference identifiers of the Exporting 2345 Processes they are receiving IPFIX Messages from against those stored 2346 in the certificates. Exporting Processes MUST NOT export to non- 2347 verified Collecting Processes, and Collecting Processes MUST NOT 2348 accept IPFIX Messages from non-verified Exporting Processes. 2350 Exporting Processes and Collecting Processes MUST support the 2351 verification of certificates against an explicitly authorized list of 2352 peer certificates identified by Common Name, and SHOULD support the 2353 verification of reference identifiers by matching the DNS-ID or CN-ID 2354 with a DNS lookup of the peer. 2356 IPFIX Exporting Processes and Collecting Processes MUST use non-NULL 2357 ciphersuites for authentication, integrity, and confidentiality. 2358 IPFIX Exporting Processes and Collecting Processes MUST support TLS 2359 version 1.1 and SHOULD support TLS version 1.2 [RFC5246], including 2360 the mandatory cipher suite(s) in each version. Exporting and 2361 Collecting Processes MUST NOT request, offer, or use any version of 2362 SSL, or any version of TLS prior to 1.1, due to known security 2363 vulnerabilities in prior versions of the protocol; see Appendix E of 2365 [RFC5246] for more information. 2367 11.4. Protection against DoS Attacks 2369 An attacker may mount a denial-of-service (DoS) attack against an 2370 IPFIX collection system either directly, by sending large amounts of 2371 traffic to a Collecting Process, or indirectly, by generating large 2372 amounts of traffic to be measured by a Metering Process. 2374 Direct DoS attacks can also involve state exhaustion, whether at the 2375 transport layer (e.g., by creating a large number of pending 2376 connections), or within the IPFIX Collecting Process itself (e.g., by 2377 sending Flow Records pending Template or scope information, a large 2378 amount of Options Template Records, etc.). 2380 SCTP mandates a cookie-exchange mechanism designed to defend against 2381 SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN 2382 cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be 2383 used by any Collecting Process accepting TCP connections. DTLS also 2384 provides cookie exchange to protect against DTLS server state 2385 exhaustion. 2387 The reader should note that there is no way to prevent fake IPFIX 2388 Message processing (and state creation) for UDP & SCTP communication. 2389 The use of TLS and DTLS can obviously prevent the creation of fake 2390 states, but they are themselves prone to state exhaustion attacks. 2391 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2392 DTLS (like limiting the number of new TLS or DTLS session per second 2393 to a sensible number). 2395 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2396 at which new connections or associations will be opened by the 2397 Collecting Process, the rate at which IPFIX Messages will be accepted 2398 by the Collecting Process, and adaptively limiting the amount of 2399 state kept, particularly records waiting on Templates. These rate 2400 and state limits MAY be provided by a Collecting Process; if 2401 provided, the limits SHOULD be user configurable. 2403 Additionally, an IPFIX Collecting Process can eliminate the risk of 2404 state exhaustion attacks from untrusted nodes by requiring TLS or 2405 DTLS mutual authentication, causing the Collecting Process to accept 2406 IPFIX Messages only from trusted sources. 2408 With respect to indirect denial of service, the behavior of IPFIX 2409 under overload conditions depends on the transport protocol in use. 2410 For IPFIX over TCP, TCP congestion control would cause the flow of 2411 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2412 system. SCTP improves upon this situation somewhat, as some IPFIX 2413 Messages would continue to be received by the Collecting Process due 2414 to the avoidance of head-of-line blocking by SCTP's multiple streams 2415 and partial reliability features, possibly affording some visibility 2416 of the attack. The situation is similar with UDP, as some datagrams 2417 may continue to be received at the Collecting Process, effectively 2418 applying sampling to the IPFIX Message stream, implying that some 2419 forensics may be left. 2421 To minimize IPFIX Message loss under overload conditions, some 2422 mechanism for service differentiation could be used to prioritize 2423 IPFIX traffic over other traffic on the same link. Alternatively, 2424 IPFIX Messages can be transported over a dedicated network. In this 2425 case, care must be taken to ensure that the dedicated network can 2426 handle the expected peak IPFIX Message traffic. 2428 11.5. When DTLS or TLS Is Not an Option 2430 The use of DTLS or TLS might not be possible in some cases due to 2431 performance issues or other operational concerns. 2433 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2434 and Collecting Processes can fall back on using IP source addresses 2435 to authenticate their peers. A policy of allocating Exporting 2436 Process and Collecting Process IP addresses from specified address 2437 ranges, and using ingress filtering to prevent spoofing, can improve 2438 the usefulness of this approach. Again, completely segregating IPFIX 2439 traffic on a dedicated network, where possible, can improve security 2440 even further. In any case, the use of open Collecting Processes 2441 (those that will accept IPFIX Messages from any Exporting Process 2442 regardless of IP address or identity) is discouraged. 2444 Modern TCP and SCTP implementations are resistant to blind insertion 2445 attacks (see [RFC4960], [RFC6528]); however, UDP offers no such 2446 protection. For this reason, IPFIX Message traffic transported via 2447 UDP and not secured via DTLS SHOULD be protected via segregation to a 2448 dedicated network. 2450 11.6. Logging an IPFIX Attack 2452 IPFIX Collecting Processes MUST detect potential IPFIX Message 2453 insertion or loss conditions by tracking the IPFIX Sequence Number, 2454 and SHOULD provide a logging mechanism for reporting out-of-sequence 2455 messages. Note that an attacker may be able to exploit the handling 2456 of out-of-sequence messages at the Collecting Process, so care should 2457 be taken in handling these conditions. For example, a Collecting 2458 Process that simply resets the expected Sequence Number upon receipt 2459 of a later Sequence Number could be temporarily blinded by deliberate 2460 injection of later Sequence Numbers. 2462 IPFIX Exporting and Collecting Processes SHOULD log any connection 2463 attempt that fails due to authentication failure, whether due to 2464 being presented an unauthorized or mismatched certificate during TLS 2465 or DTLS mutual authentication, or due to a connection attempt from an 2466 unauthorized IP address when TLS or DTLS is not in use. 2468 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2469 SCTP association reset or TCP connection reset. 2471 11.7. Securing the Collector 2473 The security of the Collector and its implementation is important to 2474 achieve overall security; however, a complete set of security 2475 guidelines for Collector implementation is outside the scope of this 2476 document. 2478 As IPFIX uses length-prefix encodings, Collector implementors should 2479 take care to ensure detection of and proper operation despite 2480 inconsistent values that could impact IPFIX Message decoding. 2481 Specifically, IPFIX Message, Set, and variable-length Information 2482 Element lengths must be checked for consistency to avoid buffer- 2483 sizing vulnerabilities. 2485 Collector implementors should also pay special attention to UTF-8 2486 encoding of string datatypes, as vulnerabilities may exist in the 2487 interpretation of ill-formed UTF-8 values; see Section 6.1.6. 2489 11.8. Privacy Considerations for Collected Data 2491 Flow data exported by Exporting Processes, and collected by 2492 Collecting Processes, typically contains information about traffic on 2493 the observed network. This information may be personally identifiable 2494 and privacy-sensitive. The storage of this data must be protected via 2495 technical as well as policy means to ensure that the privacy of the 2496 users of the measured network is protected. A complete specification 2497 of such means is out of scope for this document, and specific to the 2498 application and storage technology used. 2500 12. IANA Considerations 2502 On publication of this document, IANA will update the IPFIX 2503 Information Element Registry [IPFIX-IANA] to update all references to 2504 RFC5101 to point to this document, instead. 2506 This document has no further actions for IANA; the text below is 2507 explanatory. 2509 IPFIX Messages use two fields with assigned values. These are the 2510 IPFIX Version Number, indicating which version of the IPFIX Protocol 2511 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2512 the type for each set of information within an IPFIX Message. 2514 The Information Elements used by IPFIX, and sub-registries of 2515 Information Element values, are managed by IANA [IPFIX-IANA], as are 2516 the Private Enterprise Numbers used by enterprise-specific 2517 Information Elements [PEN-IANA]. This document makes no changes to 2518 these registries. 2520 The IPFIX Version Number value of 0x000a (10) is reserved for the 2521 IPFIX protocol specified in this document. Set ID values of 0 and 1 2522 are not used, for historical reasons [RFC3954]. The Set ID value of 2523 2 is reserved for the Template Set. The Set ID value of 3 is 2524 reserved for the Options Template Set. All other Set ID values from 2525 4 to 255 are reserved for future use. Set ID values above 255 are 2526 used for Data Sets. 2528 New assignments in either IPFIX Version Number or IPFIX Set ID 2529 assignments require a Standards Action [RFC5226], i.e., they are to 2530 be made via Standards Track RFCs approved by the IESG. 2532 Appendix A. IPFIX Encoding Examples 2534 This appendix, which is a not a normative reference, contains IPFIX 2535 encoding examples. 2537 Let's consider the example of an IPFIX Message composed of a 2538 Template Set, a Data Set (which contains three Data Records), an 2539 Options Template Set and a Data Set (which contains 2 Data Records 2540 related to the previous Options Template Record). 2542 IPFIX Message: 2544 +--------+------------------------------------------. . . 2545 | | +--------------+ +------------------+ 2546 |Message | | Template | | Data | 2547 | Header | | Set | | Set | . . . 2548 | | | (1 Template) | | (3 Data Records) | 2549 | | +--------------+ +------------------+ 2550 +--------+------------------------------------------. . . 2552 . . .-------------------------------------------+ 2553 +------------------+ +------------------+ | 2554 | Options | | Data | | 2555 . . . | Template Set | | Set | | 2556 | (1 Template) | | (2 Data Records) | | 2557 +------------------+ +------------------+ | 2558 . . .-------------------------------------------+ 2560 A.1. Message Header Example 2562 The Message Header is composed of: 2563 0 1 2 3 2564 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 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Version = 0x000a | Length = 152 | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Export Time | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | Sequence Number | 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Observation Domain ID | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 A.2. Template Set Examples 2577 A.2.1. Template Set Using IANA Information Elements 2579 We want to report the following Information Elements: 2581 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], 2582 with a length of 4 octets 2584 - The IPv4 destination IP address: destinationIPv4Address in 2585 [IPFIX-IANA], with a length of 4 octets 2587 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2588 [IPFIX-IANA], with a length of 4 octets 2590 - The number of packets of the Flow: packetDeltaCount in 2591 [IPFIX-IANA], with a length of 4 octets 2593 - The number of octets of the Flow: octetDeltaCount in 2594 [IPFIX-IANA], with a length of 4 octets 2596 Therefore, the Template Set will be composed of the following: 2598 0 1 2 3 2599 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 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | Set ID = 2 | Length = 28 octets | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | Template ID 256 | Field Count = 5 | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 |0| sourceIPv4Address = 8 | Field Length = 4 | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 |0| destinationIPv4Address = 12 | Field Length = 4 | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 |0| packetDeltaCount = 2 | Field Length = 4 | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 |0| octetDeltaCount = 1 | Field Length = 4 | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 A.2.2. Template Set Using Enterprise-Specific Information Elements 2618 We want to report the following Information Elements: 2620 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], with 2621 a length of 4 octets 2623 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2624 IANA], with a length of 4 octets 2626 - An enterprise-specific Information Element representing 2627 proprietary information, with a type of 15 and a length of 4 2629 - The number of packets of the Flow: packetDeltaCount in [IPFIX- 2630 IANA], with a length of 4 octets 2632 - The number of octets of the Flow: octetDeltaCount in [IPFIX-IANA], 2633 with a length of 4 octets 2635 Therefore, the Template Set will be composed of the following: 2637 0 1 2 3 2638 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 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | Set ID = 2 | Length = 32 octets | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | Template ID 257 | Field Count = 5 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 |0| sourceIPv4Address = 8 | Field Length = 4 | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 |0| destinationIPv4Address = 12 | Field Length = 4 | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 |1| Information Element Id. = 15| Field Length = 4 | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | Enterprise number | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 |0| packetDeltaCount = 2 | Field Length = 4 | 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 |0| octetDeltaCount = 1 | Field Length = 4 | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 A.3. Data Set Example 2659 In this example, we report the following three Flow Records: 2661 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2662 | | | Number | Number 2663 ------------------------------------------------------------------ 2664 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2665 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2666 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2668 0 1 2 3 2669 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 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | Set ID = 256 | Length = 64 | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | 192.0.2.12 | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | 192.0.2.254 | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | 192.0.2.1 | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | 5009 | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | 5344385 | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | 192.0.2.27 | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | 192.0.2.23 | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | 192.0.2.2 | 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | 748 | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | 388934 | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | 192.0.2.56 | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | 192.0.2.65 | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | 192.0.2.3 | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | 5 | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | 6534 | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 Note that padding is not necessary in this example. 2706 A.4. Options Template Set Examples 2708 A.4.1. Options Template Set Using IANA Information Elements 2710 Per line card (the router being composed of two line cards), we want 2711 to report the following Information Elements: 2713 - Total number of IPFIX Messages: exportedMessageTotalCount [IPFIX- 2714 IANA], with a length of 2 octets 2716 - Total number of exported Flows: exportedFlowRecordTotalCount 2717 [IPFIX-IANA], with a length of 2 octets 2719 The line card, which is represented by the lineCardId Information 2720 Element [IPFIX-IANA], is used as the Scope Field. 2722 Therefore, the Options Template Set will be: 2724 0 1 2 3 2725 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 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Set ID = 3 | Length = 24 | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | Template ID 258 | Field Count = 3 | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Scope Field Count = 1 |0| lineCardId = 141 | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 | Field Length = 2 | Padding | 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 A.4.2. Options Template Set Using Enterprise-Specific Information 2741 Elements 2743 Per line card (the router being composed of two line cards), we want 2744 to report the following Information Elements: 2746 - Total number of IPFIX Messages: exportedMessageTotalCount 2747 [IPFIX-IANA], with a length of 2 octets 2749 - An enterprise-specific number of exported Flows, with a type of 2750 42 and a length of 4 octets 2752 The line card, which is represented by the lineCardId Information 2753 Element [IPFIX-IANA], is used as the Scope Field. 2755 The format of the Options Template Set is as follows: 2757 0 1 2 3 2758 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 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | Set ID = 3 | Length = 28 | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | Template ID 259 | Field Count = 3 | 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | Scope Field Count = 1 |0| lineCardId = 141 | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Field Length = 2 |1|Information Element Id. = 42 | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | Field Length = 4 | Enterprise number ... 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 ... Enterprise number | Padding | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2777 In this example, we want to export the same information as in the 2778 example in Section A.4.1: 2780 - Total number of IPFIX Messages: exportedMessageTotalCount 2781 [IPFIX-IANA], with a length of 2 octets 2783 - Total number of exported Flows: exportedFlowRecordTotalCount 2784 [IPFIX-IANA], with a length of 2 octets 2786 But this time, the information pertains to a proprietary scope, 2787 identified by enterprise-specific Information Element number 123. 2789 The format of the Options Template Set is now as follows: 2791 0 1 2 3 2792 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 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | Set ID = 3 | Length = 28 | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | Template ID 260 | Field Count = 3 | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | Scope 1 Field Length = 4 | Enterprise Number ... 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | Field Length = 2 | Padding | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 A.4.4. Data Set Using an Enterprise-Specific Scope 2811 In this example, we report the following two Data Records: 2813 Enterprise field 123 | IPFIX Message | Exported Flow Records 2814 ------------------------------------------------------------------- 2815 1 | 345 | 10201 2816 2 | 690 | 20402 2818 0 1 2 3 2819 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 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | Set ID = 260 | Length = 20 | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | 1 | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | 345 | 10201 | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | 2 | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | 690 | 20402 | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 A.5. Variable-Length Information Element Examples 2834 A.5.1. Example of Variable-Length Information Element with Length 2835 Inferior to 255 Octets 2837 0 1 2 3 2838 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 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | 5 | 5 octet Information Element | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 A.5.2. Example of Variable-Length Information Element with 3 Octet 2846 Length Encoding 2848 0 1 2 3 2849 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 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | 255 | 1000 | IE ... | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | 1000 octet Information Element | 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 : ... : 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 | ... IE | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 References 2862 Normative References 2864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2865 Requirement Levels", BCP 14, RFC 2119, March 1997. 2867 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2868 Layer Security over Stream Control Transmission 2869 Protocol", RFC 3436, December 2002. 2871 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2872 10646", RFC 3629, November 2003. 2874 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2875 Conrad, "Stream Control Transmission Protocol (SCTP) 2876 Partial Reliability Extension", RFC 3758, May 2004. 2878 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 2879 Protocol", RFC 4960, September 2007. 2881 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2882 an IANA Considerations Section in RFCs", BCP 26, RFC 2883 5226, May 2008. 2885 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2886 Security (TLS) Protocol Version 1.2", RFC 5246, August 2887 2008. 2889 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 2890 W. Kasch, "Network Time Protocol Version 4: Protocol 2891 and Algorithms Specification", RFC 5905, June 2010 2893 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 2894 Verification of Domain-Based Application Service 2895 Identity within Internet Public Key Infrastructure 2896 Using X.509 (PKIX) Certificates in the Context of 2897 Transport Layer Security (TLS)", RFC 6125, March 2011. 2899 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 2900 Layer Security Version 1.2", RFC 6347, January 2012. 2902 [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., 2903 "Transport Layer Security (TLS) and Datagram Transport 2904 Layer Security (DTLS) Heartbeat Extension", RFC 6520, 2905 February 2012. 2907 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2908 RFC 793, September 1981. 2910 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2911 August 1980. 2913 [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. 2914 Meyer, "Information Model for IP Flow Information 2915 Export", draft-claise-ipfix-information-model- 2916 rfc5102bis-01.txt, Work in Progress, October 2011. 2918 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 2920 Informative References 2922 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2923 "Textual Conventions for SMIv2", STD 58, RFC 2579, 2924 April 1999. 2926 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2927 Jacobson, "RTP: A Transport Protocol for Real-Time 2928 Applications", STD 64, RFC 3550, July 2003. 2930 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2931 "Requirements for IP Flow Information Export (IPFIX)", 2932 RFC 3917, October 2004. 2934 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 2935 Export Version 9", RFC 3954, October 2004. 2937 [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP 2938 Flow Information Export (IPFIX)", RFC 5103, January 2939 2008. 2941 [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP 2942 Flow Information Export (IPFIX) Protocol for the 2943 Exchange of IP Traffic Flow Information", RFC 5101, 2944 January 2008. 2946 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 2947 Flow Information Export (IPFIX) Implementation 2948 Guidelines", RFC5153, April 2008 2950 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 2951 Quittek, "Architecture for IP Flow Information 2952 Export", RFC5470, March 2009. 2954 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 2955 "IP Flow Information Export (IPFIX) Applicability", 2956 RFC5472, March 2009. 2958 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 2959 for IP Flow Information Export (IPFIX) Testing", 2960 RFC5471, March 2009. 2962 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2963 Redundancy in IP Flow Information Export (IPFIX) and 2964 Packet Sampling (PSAMP) Reports", RFC5473, March 2009. 2966 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, 2967 A., Grossglauser, M., and J. Rexford, "A Framework for 2968 Packet Selection and Reporting", RFC 5474, March 2009. 2970 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet 2971 Sampling (PSAMP) Protocol Specifications", RFC5476, 2972 March 2009. 2974 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and 2975 G. Carle, "Information Model for Packet Sampling 2976 Exports", RFC 5477, March 2009. 2978 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2979 "Exporting Type Information for IP Flow Information 2980 Export (IPFIX) Information Elements", RFC 5610, July 2981 2009. 2983 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2984 Wagner, "Specification of the IP Flow Information 2985 Export (IPFIX) File Format", RFC 5655, October 2009. 2987 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 2988 Transport Layer Security (DTLS) for Stream Control 2989 Transmission Protocol (SCTP)", RFC6083, January 2011. 2991 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 2992 "Export of Structured Data in IP Flow Information 2993 Export (IPFIX)", RFC6313, July 2011. 2995 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 2996 "IP Flow Information Export (IPFIX) Mediation: 2997 Framework", RFC6183, April 2011. 2999 [RFC6526] Claise, B., Aitken, P., Johnson, A. and G. Muenz, 3000 "IPFIX Export per SCTP Stream", RFC 6526, March 2012. 3002 [RFC6528] Gont, F. and S. Bellovin, "Defending Against Sequence 3003 Number Attacks", RFC 6528, February 2012. 3005 [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 3006 "Definitions of Managed Objects for IP Flow 3007 Information Export", RFC 6615, June 2012. 3009 [RFC6727] Dietz, T. Ed., Claise, B., and J. Quittek, 3010 "Definitions of Managed Objects for Packet Sampling", 3011 RFC 6727, October 2012. 3013 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration 3014 Data Model for IPFIX and PSAMP", RFC 6728, October 3015 2012. 3017 [PEN-IANA] IANA Private Enterprise Numbers registry 3018 http://www.iana.org/assignments/enterprise-numbers. 3020 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 3021 Technology - Portable Operating System Interface, 3022 IEEE, 2008. 3024 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 3025 "Standard for Binary Floating-Point Arithmetic", IEEE 3026 Standard 754, August 1985. 3028 [UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report 3029 #36: Unicode Security Considerations", The Unicode 3030 Consortium, July 2012. 3032 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 3033 "Specification of the Protocol for IPFIX Mediations", 3034 draft-ietf-ipfix-mediation-protocol-03, Work in 3035 Progress, January 2013. 3037 Acknowledgments 3039 We would like to thank Ganesh Sadasivan, as well, for his significant 3040 contribution during the initial phases of the protocol specification. 3041 Additional thanks to Juergen Quittek for the coordination job within 3042 IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, and Andrew Johnson for 3043 the thorough reviews; Randall Stewart and Peter Lei for their SCTP 3044 expertise and contributions; Martin Djernaes for the first essay on 3045 the SCTP section; Michael Behringer and Eric Vyncke for their advice 3046 and knowledge in security; Michael Tuexen for his help regarding the 3047 DTLS section; Elisa Boschi for her contribution regarding the 3048 improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff 3049 Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David 3050 Moore, Robert Lowe, Paul Calato, Andrew Feren, Gerhard Muenz, and 3051 many more, for the technical reviews and feedback. 3053 Authors' Addresses 3055 Benoit Claise (Ed.) 3056 Cisco Systems, Inc. 3057 De Kleetlaan 6a b1 3058 1831 Diegem 3059 Belgium 3061 Phone: +32 2 704 5622 3062 EMail: bclaise@cisco.com 3064 Brian Trammell (Ed.) 3065 Swiss Federal Institute of Technology Zurich 3066 Gloriastrasse 35 3067 8092 Zurich 3068 Switzerland 3070 Phone: +41 44 632 70 13 3071 EMail: trammell@tik.ee.ethz.ch 3073 Paul Aitken 3074 Cisco Systems, Inc. 3075 96 Commercial Quay 3076 Commercial Street, Edinburgh EH6 6LX 3077 United Kingdom 3079 Phone: +44 131 561 3616 3080 Email: paitken@cisco.com 3082 Contributors' Addresses 3084 Stewart Bryant 3085 Cisco Systems, Inc. 3086 250, Longwater, 3087 Green Park, 3088 Reading, RG2 6GB, 3089 United Kingdom 3091 Phone: +44 (0)20 8824-8828 3092 EMail: stbryant@cisco.com 3094 Simon Leinen 3095 SWITCH 3096 Werdstrasse 2 3097 P.O. Box 3098 8021 Zurich 3099 Switzerland 3101 Phone: +41 44 268 1536 3102 EMail: simon.leinen@switch.ch 3104 Thomas Dietz 3105 NEC Europe Ltd. 3106 NEC Laboratories Europe 3107 Network Research Division 3108 Kurfuersten-Anlage 36 3109 69115 Heidelberg 3110 Germany 3112 Phone: +49 6221 4342-128 3113 EMail: Thomas.Dietz@nw.neclab.eu