idnits 2.17.1 draft-claise-ipfix-protocol-rfc5101bis-02.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 (October 26, 2011) is 4564 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 4347 (Obsoleted by RFC 6347) ** 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 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-01) exists of draft-claise-ipfix-information-model-rfc5102bis-00 -- Possible downref: Normative reference to a draft: ref. 'RFC5102bis' -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) == Outdated reference: A later version (-11) exists of draft-ietf-ipfix-configuration-model-10 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 October 26, 2011 5 Category: Standards Track 6 Expires: April 28, 2012 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of IP Traffic Flow Information 10 draft-claise-ipfix-protocol-rfc5101bis-02 12 Abstract 14 This document specifies the IP Flow Information Export (IPFIX) 15 protocol that serves for transmitting IP Traffic Flow information 16 over the network. In order to transmit IP Traffic Flow information 17 from an Exporting Process to an information Collecting Process, a 18 common representation of flow data and a standard means of 19 communicating them is required. This document describes how the 20 IPFIX Data and Template Records are carried over a number of 21 transport protocols from an IPFIX Exporting Process to an IPFIX 22 Collecting Process. This document obsoletes RFC 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 March 23, 2012. 41 Copyright Notice 43 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 6 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 11 62 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 12 63 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 13 64 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 15 65 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 16 66 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 16 67 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 17 68 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 18 69 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 18 70 3.4.2. Options Template Record Format . . . . . . . . . . . . 20 71 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 21 72 3.4.2.2. Options Template Record Format . . . . . . . . . . 22 73 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 24 74 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 25 75 4.1. The Metering Process Statistics Options Template . . . . . 25 76 4.2. The Metering Process Reliability Statistics Options 77 Template . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 4.3. The Exporting Process Reliability Statistics Options 79 Template . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 30 81 5. IPFIX Message Header Export Time and Flow Record Time . . . . 30 82 6. Linkage with the Information Model . . . . . . . . . . . . . . 31 83 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31 84 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31 85 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31 86 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31 87 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31 88 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 32 89 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 32 90 6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 33 91 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 33 92 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 33 93 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 33 94 6.2. Reduced Size Encoding of Integer and Float Types . . . . . 34 95 7. Variable-Length Information Element . . . . . . . . . . . . . 34 96 8. Template Management . . . . . . . . . . . . . . . . . . . . . 36 97 9. The Collecting Process's Side . . . . . . . . . . . . . . . . 39 98 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 41 99 10.1. Transport Compliance and Transport Usage . . . . . . . . 41 100 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 42 101 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 42 102 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 42 103 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 42 104 10.2.4. Exporting Process . . . . . . . . . . . . . . . . . . 43 105 10.2.4.1. Association Establishment . . . . . . . . . . . . 43 106 10.2.4.2. Association Shutdown . . . . . . . . . . . . . . 43 107 10.2.4.3. Stream . . . . . . . . . . . . . . . . . . . . . 43 108 10.2.4.4. Template Management . . . . . . . . . . . . . . . 44 109 10.2.5. Collecting Process . . . . . . . . . . . . . . . . . 44 110 10.2.6. Failover . . . . . . . . . . . . . . . . . . . . . . 44 111 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 112 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 44 113 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 45 114 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45 115 10.3.4. Port Numbers . . . . . . . . . . . . . . . . . . . . 45 116 10.3.5. Exporting Process . . . . . . . . . . . . . . . . . . 45 117 10.3.6. Template Management . . . . . . . . . . . . . . . . . 45 118 10.3.7. Collecting Process . . . . . . . . . . . . . . . . . 46 119 10.3.8. Failover . . . . . . . . . . . . . . . . . . . . . . 47 120 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 121 10.4.1. Connection Management . . . . . . . . . . . . . . . . 47 122 10.4.1.1. Connection Establishment . . . . . . . . . . . . 47 123 10.4.1.2. Graceful Connection Release . . . . . . . . . . . 48 124 10.4.1.3. Restarting Interrupted Connections . . . . . . . 48 125 10.4.1.4. Failover . . . . . . . . . . . . . . . . . . . . 48 126 10.4.2. Data Transmission . . . . . . . . . . . . . . . . . . 48 127 10.4.2.1. IPFIX Message Encoding . . . . . . . . . . . . . 48 128 10.4.2.2. Template Management . . . . . . . . . . . . . . . 49 129 10.4.2.3. Congestion Handling and Reliability . . . . . . . 49 130 10.4.3. Collecting Process . . . . . . . . . . . . . . . . . 51 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 132 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 53 133 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 54 134 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 54 135 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 54 136 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 56 137 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 56 138 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 57 139 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 140 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 58 141 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 58 142 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 59 143 A.2.1. Template Set Using IETF-Specified Information 144 Elements . . . . . . . . . . . . . . . . . . . . . . . 59 145 A.2.2. Template Set Using Enterprise-Specific Information 146 Elements . . . . . . . . . . . . . . . . . . . . . . . 59 147 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 61 148 A.4. Options Template Set Examples . . . . . . . . . . . . . . 62 149 A.4.1. Options Template Set Using IETF-Specified 150 Information Elements . . . . . . . . . . . . . . . . . 62 151 A.4.2. Options Template Set Using Enterprise-Specific 152 Information . . . . . . . . . . . . . . . . . . . . . 62 153 A.4.3. Options Template Set Using an Enterprise-Specific 154 Scope . . . . . . . . . . . . . . . . . . . . . . . . 63 155 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 64 156 A.5. Variable-Length Information Element Examples . . . . . . . 65 157 A.5.1. Example of Variable-Length Information Element with 158 Length . . . . . . . . . . . . . . . . . . . . . . . . 65 159 A.5.2. Example of Variable-Length Information Element with 160 3 Octet Length Encoding . . . . . . . . . . . . . . . 65 161 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 162 Normative References . . . . . . . . . . . . . . . . . . . . . . . 65 163 Informative References . . . . . . . . . . . . . . . . . . . . . . 66 164 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 68 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 167 DONE: 168 Errata ID: 1655 (technical) 169 Errata ID: 2791 (technical) 170 Errata ID: 2814 (editorial) 171 Errata ID: 1818 (editorial) 172 Errata ID: 2792 (editorial) 173 Errata ID: 2888 (editorial) 174 Errata ID: 2889 (editorial) 175 Errata ID: 2890 (editorial) 176 Errata ID: 2891 (editorial) 177 Errata ID: 2892 (editorial) 178 Errata ID: 2903 (editorial) 179 Errata ID: 2761 (editorial) 180 Errata ID: 2762 (editorial) 181 Errata ID: 2763 (editorial) 182 Errata ID: 2764 (editorial) 183 Errata ID: 2852 (editorial) 184 Errata ID: 2857 (editorial) 186 Update all references to RFC5102bis and to RFC5815bis 187 Section 8: "a new sampling rate" has been removed from the list of 188 examples that requires a new Template. 190 If the measurement parameters change such that a new Template is 191 required, the Template MUST be withdrawn (using a Template Withdraw 192 Message and a new Template definition) or an unused Template ID MUST 193 be used. Examples of the measurement changes are: a new sampling 194 rate, a new Flow expiration process, a new filtering definition, etc. 196 Updated the references 198 Updated the "Document overview" section. 200 Template and UDP: included the proposal at 201 http://www.ietf.org/mail-archive/web/ipfix/current/msg06051.html 203 "time first flow dropped" and "time last flow dropped" 204 inconsistency. See the discussion on the list. 206 Observation Domain Id: from "the same Exporting Process" to "the 207 same Exporter". See http://www.ietf.org/mail- 208 archive/web/ipfix/current/msg06078.html 210 Clarified the timestamps and updated the reference from RFC1305 to 211 RFC5905 213 TO DO: 214 Resolution to the template lifetime mechanism for UDP 216 RFC2026 section 4.1.2: "The requirement for at least two 217 independent and interoperable implementations applies to all of the 218 options and features of the specification. In cases in which one or 219 more options or features have not been demonstrated in at least two 220 interoperable implementations, the specification may advance to the 221 Draft Standard level only if those options or features are removed." 222 The interop report from Prague is at 223 http://www.ietf.org/proceedings/80/slides/ipfix-4.pdf Missing from 224 this interop (and therefore, every interop): 225 1. DTLS over SCTP or UDP (5101 sec. 11.1) 226 2. ANY advanced template handling, withdrawal, stream 227 separation, or reuse UDP template expiration (5101 sec. 228 10.3.6) template withdrawals (5101 sec. 8 para 8 et seq.) 229 3. SCTP export on any stream other than 0 (5101 sec 10.2.4.3) 231 1. Introduction 232 A data network with IP traffic primarily consists of IP flows passing 233 through the network elements. It is often interesting, useful, or 234 even required to have access to information about these flows that 235 pass through the network elements for administrative or other 236 purposes. The IPFIX Collecting Process should be able to receive the 237 flow information passing through multiple network elements within the 238 data network. This requires uniformity in the method of representing 239 the flow information and the means of communicating the flows from 240 the network elements to the collection point. This document 241 specifies the protocol to achieve these aforementioned requirements. 242 This document specifies in detail the representation of different 243 flows, the additional data required for flow interpretation, packet 244 format, transport mechanisms used, security concerns, etc. 246 1.1. IPFIX Documents Overview 248 The IPFIX protocol provides network administrators with access to IP 249 flow information. The architecture for the export of measured IP 250 flow information out of an IPFIX Exporting Process to a Collecting 251 Process is defined in [RFC5470], per the requirements defined in 252 [RFC3917]. This document specifies how IPFIX data records and 253 templates are carried via a number of transport protocols from IPFIX 254 Exporting Processes to IPFIX Collecting Processes. 256 Four IPFIX optimizations/extensions are currently specified: a 257 bandwidth saving method for the IPFIX protocol in [RFC5473], an 258 efficient method for exporting bidirectional flow in [RFC5103], a 259 method for the definition and export of complex data structures in 260 [RFC6313], and the specification of the Protocol for IPFIX Mediations 261 [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. 263 IPFIX has a formal description of IPFIX Information Elements, their 264 name, type and additional semantic information, as specified in 265 [RFC5102bis], with the export of the Information Element types 266 specified in [RFC5610]. 268 [IPFIX-CONF] specifies a data model for configuring and monitoring 269 IPFIX and PSAMP compliant devices using the NETCONF protocol, while 270 the [RFC5815bis] specifies a MIB module for monitoring. 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. 276 Finally, [RFC5472] describes what type of applications can use the 277 IPFIX protocol and how they can use the information provided. It 278 furthermore shows how the IPFIX framework relates to other 279 architectures and frameworks. 281 2. Terminology 283 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 284 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 285 document are to be interpreted as described in RFC 2119 [RFC2119]. 287 The definitions of the basic terms like IP Traffic Flow, Exporting 288 Process, Collecting Process, Observation Points, etc. are 289 semantically identical to those found in the IPFIX requirements 290 document [RFC3917]. Some of the terms have been expanded for more 291 clarity when defining the protocol. Additional terms required for 292 the protocol have also been defined. Definitions in this document 293 and in [RFC5470] are equivalent, except that definitions that are 294 only relevant to the IPFIX protocol only appear here. 296 The terminology summary table in Section 2.1 gives a quick overview 297 of the relationships between some of the different terms defined. 299 Observation Point 301 An Observation Point is a location in the network where IP packets 302 can be observed. Examples include: a line to which a probe is 303 attached, a shared medium, such as an Ethernet-based LAN, a single 304 port of a router, or a set of interfaces (physical or logical) of 305 a router. 307 Note that every Observation Point is associated with an 308 Observation Domain (defined below), and that one Observation Point 309 may be a superset of several other Observation Points. For 310 example, one Observation Point can be an entire line card. That 311 would be the superset of the individual Observation Points at the 312 line card's interfaces. 314 Observation Domain 316 An Observation Domain is the largest set of Observation Points for 317 which Flow information can be aggregated by a Metering Process. 318 For example, a router line card may be an Observation Domain if it 319 is composed of several interfaces, each of which is an Observation 320 Point. In the IPFIX Message it generates, the Observation Domain 321 includes its Observation Domain ID, which is unique per Exporting 322 Process. That way, the Collecting Process can identify the 323 specific Observation Domain from the Exporter that sends the IPFIX 324 Messages. Every Observation Point is associated with an 325 Observation Domain. It is RECOMMENDED that Observation Domain IDs 326 also be unique per IPFIX Device. 328 IP 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 IP packets passing an Observation 334 Point in the network during a certain time interval. All packets 335 belonging to a particular Flow have a set of common properties. 336 Each property is defined as the result of applying a function to 337 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 This definition covers the range from a Flow containing all 354 packets observed at a network interface to a Flow consisting of 355 just a single packet between two applications. It includes 356 packets selected by a sampling mechanism. 358 Flow Key 360 Each of the fields that: 362 1. belong to the packet header (e.g., destination IP address), 364 2. are a property of the packet itself (e.g., packet length), 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 characteristic properties of the 377 Flow (e.g., source IP address). 379 Metering Process 381 The Metering Process generates Flow Records. Inputs to the 382 process are packet headers and characteristics observed at an 383 Observation Point, and packet treatment at the Observation Point 384 (for example, the selected output interface). 386 The Metering Process consists of a set of functions that includes 387 packet header capturing, timestamping, sampling, classifying, and 388 maintaining Flow Records. 390 The maintenance of Flow Records may include creating new records, 391 updating existing ones, computing Flow statistics, deriving 392 further Flow properties, detecting Flow expiration, passing Flow 393 Records to the Exporting Process, and deleting Flow Records. 395 Exporting Process 397 The Exporting Process sends Flow Records to one or more Collecting 398 Processes. The Flow Records are generated by one or more Metering 399 Processes. 401 Exporter 403 A device that hosts one or more Exporting Processes is termed an 404 Exporter. 406 IPFIX Device 408 An IPFIX Device hosts at least one Exporting Process. It may host 409 further Exporting Processes and arbitrary numbers of Observation 410 Points and Metering Processes. 412 Collecting Process 414 A Collecting Process receives Flow Records from one or more 415 Exporting Processes. The Collecting Process might process or 416 store received Flow Records, but such actions are out of scope for 417 this document. 419 Collector 421 A device that hosts one or more Collecting Processes is termed a 422 Collector. 424 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 Set is a generic term for a collection of records that have a 463 similar structure. In an IPFIX Message, one or more Sets follow 464 the Message Header. 466 There are three different types of Sets: Template Set, Options 467 Template Set, and Data Set. 469 Template Set 471 A Template Set is a collection of one or more Template Records 472 that have been grouped together in an IPFIX Message. 474 Options Template Set 476 An Options Template Set is a collection of one or more Options 477 Template Records that have been grouped together in an IPFIX 478 Message. 480 Data Set 482 A Data Set is one or more Data Records, of the same type, that are 483 grouped together in an IPFIX Message. Each Data Record is 484 previously defined by a Template Record or an Options Template 485 Record. 487 Information Element 489 An Information Element is a protocol and encoding-independent 490 description of an attribute that may appear in an IPFIX Record. 491 The IPFIX information model [RFC5102bis] defines the base set of 492 Information Elements for IPFIX. The type associated with an 493 Information Element indicates constraints on what it may contain 494 and also determines the valid encoding mechanisms for use in 495 IPFIX. 497 Transport Session 499 In Stream Control Transmission Protocol (SCTP), the transport 500 session is known as the SCTP association, which is uniquely 501 identified by the SCTP endpoints [RFC4960]; in TCP, the transport 502 session is known as the TCP connection, which is uniquely 503 identified by the combination of IP addresses and TCP ports used. 504 In UDP, the transport session is known as the UDP session, which 505 is uniquely identified by the combination of IP addresses and UDP 506 ports used. 508 2.1. Terminology Summary Table 510 +------------------+---------------------------------------------+ 511 | | contents | 512 | +--------------------+------------------------+ 513 | Set | Template | record | 514 +------------------+--------------------+------------------------+ 515 | Data Set | / | Data Record(s) | 516 +------------------+--------------------+------------------------+ 517 | Template Set | Template Record(s) | / | 518 +------------------+--------------------+------------------------+ 519 | Options Template | Options Template | / | 520 | Set | Record(s) | | 521 +------------------+--------------------+------------------------+ 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 one 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 554 The Exporter MUST code all binary integers of the Message Header and 555 the different Sets in network-byte order (also known as the 556 big-endian byte ordering). 558 Following are some examples of IPFIX Messages: 560 1. An IPFIX Message consisting of interleaved Template, Data, and 561 Options Template Sets -- A newly created Template is exported as 562 soon as possible. So, if there is already an IPFIX Message with a 563 Data Set that is being prepared for export, the Template and 564 Options Template Sets are interleaved with this information, 565 subject to availability of space. 567 +--------+--------------------------------------------------------+ 568 | | +----------+ +---------+ +-----------+ +---------+ | 569 |Message | | Template | | Data | | Options | | Data | | 570 | Header | | Set | | Set | ... | Template | | Set | | 571 | | | | | | | Set | | | | 572 | | +----------+ +---------+ +-----------+ +---------+ | 573 +--------+--------------------------------------------------------+ 575 Figure C: IPFIX Message, Example 1 577 2. An IPFIX Message consisting entirely of Data Sets -- After the 578 appropriate Template Records have been defined and transmitted to 579 the Collecting Process, the majority of IPFIX Messages consist 580 solely of Data Sets. 582 +--------+----------------------------------------------+ 583 | | +---------+ +---------+ +---------+ | 584 |Message | | Data | | Data | | Data | | 585 | Header | | Set | ... | Set | ... | Set | | 586 | | +---------+ +---------+ +---------+ | 587 +--------+----------------------------------------------+ 589 Figure D: IPFIX Message, Example 2 591 3. An IPFIX Message consisting entirely of Template and Options 592 Template Sets. 594 +--------+-------------------------------------------------+ 595 | | +----------+ +----------+ +----------+ | 596 |Message | | Template | | Template | | Options | | 597 | Header | | Set | ... | Set | ... | Template | | 598 | | | | | | | Set | | 599 | | +----------+ +----------+ +----------+ | 600 +--------+-------------------------------------------------+ 602 Figure E: IPFIX Message, Example 3 604 3.1. Message Header Format 606 The format of the IPFIX Message Header is shown in Figure F. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Version Number | Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Export Time | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Sequence Number | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Observation Domain ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure F: IPFIX Message Header Format 622 Message Header Field Descriptions: 624 Version 626 Version of Flow Record format exported in this message. The value 627 of this field is 0x000a for the current version, incrementing by 628 one the version used in the NetFlow services export version 9 629 [RFC3954]. 631 Length 633 Total length of the IPFIX Message, measured in octets, including 634 Message Header and Set(s). 636 Export Time 638 Time at which the IPFIX Message Header leaves the Exporter, 639 expressed in seconds since the UNIX epoch of 1 January 1970 at 640 00:00 UTC, encoded as an unsigned 32-bit integer. 642 Sequence Number 644 Incremental sequence counter modulo 2^32 of all IPFIX Data Records 645 sent on this PR-SCTP stream from the current Observation Domain by 646 the Exporting Process. Check the specific meaning of this field 647 in the subsections of Section 10 when UDP or TCP is selected as 648 the transport protocol. This value SHOULD be used by the 649 Collecting Process to identify whether any IPFIX Data Records have 650 been missed. Template and Options Template Records do not 651 increase the Sequence Number. 653 Observation Domain ID 655 A 32-bit identifier of the Observation Domain that is locally 656 unique to the Exporting Process. The Exporting Process uses the 657 Observation Domain ID to uniquely identify to the Collecting 658 Process the Observation Domain that metered the Flows. It is 659 RECOMMENDED that this identifier also be unique per IPFIX Device. 660 Collecting Processes SHOULD use the Transport Session and the 661 Observation Domain ID field to separate different export streams 662 originating from the same Exporter. The Observation Domain ID 663 SHOULD be 0 when no specific Observation Domain ID is relevant for 664 the entire IPFIX Message, for example, when exporting the 665 Exporting Process Statistics, or in case of a hierarchy of 666 Collectors when aggregated Data Records are exported. 668 3.2. Field Specifier Format 670 Vendors need the ability to define proprietary Information Elements, 671 because, for example, they are delivering a pre-standards product, or 672 the Information Element is, in some way, commercially sensitive. 673 This section describes the Field Specifier format for both 674 IETF-specified Information Elements [RFC5102bis] and enterprise- 675 specific Information Elements. 677 The Information Elements are identified by the Information Element 678 identifier. When the Enterprise bit is set to 0, the corresponding 679 Information Element identifier will report an IETF-specified 680 Information Element, and the Enterprise Number MUST NOT be present. 681 When the Enterprise bit is set to 1, the corresponding Information 682 Element identifier will report an enterprise-specific Information 683 Element; the Enterprise Number MUST be present. An example of this 684 is shown in Section A.4.2. 686 The Field Specifier format is shown in Figure G. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |E| Information Element ident. | Field Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Enterprise Number | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure G: Field Specifier Format 698 Where: 700 E 702 Enterprise bit. This is the first bit of the Field Specifier. 703 If this bit is zero, the Information Element Identifier 704 identifies an IETF-specified Information Element, and the four- 705 octet Enterprise Number field MUST NOT be present. If this bit is 706 one, the Information Element identifier identifies an enterprise- 707 specific Information Element, and the Enterprise Number filed 708 MUST be present. 710 Information Element identifier 712 A numeric value that represents the type of Information Element. 713 Refer to [RFC5102bis]. 715 Field Length 717 The length of the corresponding encoded Information Element, in 718 octets. Refer to [RFC5102bis]. The field length may be smaller 719 than the definition in [RFC5102bis] if the reduced size encoding 720 is used (see Section 6.2). The value 65535 is reserved for 721 variable-length Information Elements (see Section 7). 723 Enterprise Number 725 IANA enterprise number [PEN] of the authority defining the 726 Information Element identifier in this Template Record. 728 3.3. Set and Set Header Format 730 A Set is a generic term for a collection of records that have a 731 similar structure. There are three different types of Sets: Template 732 Sets, Options Template Sets, and Data Sets. Each of these Sets 733 consists of a Set Header and one or more records. The Set Format and 734 the Set Header Format are defined in the following sections. 736 3.3.1. Set Format 738 A Set has the format shown in Figure H. The record types can be 739 either Template Records, Options Template Records, or Data Records. 740 The record types MUST NOT be mixed within a Set. 742 +--------------------------------------------------+ 743 | Set Header | 744 +--------------------------------------------------+ 745 | record | 746 +--------------------------------------------------+ 747 | record | 748 +--------------------------------------------------+ 749 ... 750 +--------------------------------------------------+ 751 | record | 752 +--------------------------------------------------+ 753 | Padding (opt.) | 754 +--------------------------------------------------+ 756 Figure H: Set Format 758 The Set Field Definitions are as follows: 760 Set Header 762 The Set Header Format is defined in Section 3.3.2. 764 Record 766 One of the record Formats: Template Record, Options Template 767 Record, or Data Record Format. 769 Padding 771 The Exporting Process MAY insert some padding octets, so that the 772 subsequent Set starts at an aligned boundary. For security 773 reasons, the padding octet(s) MUST be composed of zero (0) valued 774 octets. The padding length MUST be shorter than any allowable 775 record in this Set. If padding of the IPFIX Message is desired in 776 combination with very short records, then the padding Information 777 Element 'paddingOctets' [RFC5102bis] can be used for padding 778 records such that their length is increased to a multiple of 4 or 779 8 octets. Because Template Sets are always 4-octet aligned by 780 definition, padding is only needed in case of other alignments 781 e.g., on 8-octet boundaries. 783 3.3.2. Set Header Format 785 Every Set contains a common header. This header is defined in Figure 786 I. 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Set ID | Length | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Figure I: Set Header Format 796 The Set Header Field Definitions are as follows: 798 Set ID 800 Set ID value identifies the Set. A value of 2 is reserved for the 801 Template Set. A value of 3 is reserved for the Options Template 802 Set. All other values from 4 to 255 are reserved for future use. 803 Values above 255 are used for Data Sets. The Set ID values of 0 804 and 1 are not used for historical reasons [RFC3954]. 806 Length 808 Total length of the Set, in octets, including the Set Header, all 809 records, and the optional padding. Because an individual Set MAY 810 contain multiple records, the Length value MUST be used to 811 determine the position of the next Set. 813 3.4. Record Format 815 IPFIX defines three record formats, defined in the next sections: the 816 Template Record Format, the Options Template Record Format, and the 817 Data Record Format. 819 3.4.1. Template Record Format 821 One of the essential elements in the IPFIX record format is the 822 Template Record. Templates greatly enhance the flexibility of the 823 record format because they allow the Collecting Process to process 824 IPFIX Messages without necessarily knowing the interpretation of all 825 Data Records. A Template Record contains any combination of 826 IANA-assigned and/or enterprise-specific Information Elements 827 identifiers. 829 The format of the Template Record is shown in Figure J. It consists 830 of a Template Record Header and one or more Field Specifiers. The 831 definition of the Field Specifiers is given in Figure G above. 833 +--------------------------------------------------+ 834 | Template Record Header | 835 +--------------------------------------------------+ 836 | Field Specifier | 837 +--------------------------------------------------+ 838 | Field Specifier | 839 +--------------------------------------------------+ 840 ... 841 +--------------------------------------------------+ 842 | Field Specifier | 843 +--------------------------------------------------+ 845 Figure J: Template Record Format 847 The format of the Template Record Header is shown in Figure K. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Template ID (> 255) | Field Count | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure K: Template Record Header Format 856 The Template Record Header Field Definitions are as follows: 858 Template ID 860 Each of the newly generated Template Records is given a unique 861 Template ID. This uniqueness is local to the Transport Session 862 and Observation Domain that generated the Template ID. Template 863 IDs 0-255 are reserved for Template Sets, Options Template Sets, 864 and other reserved Sets yet to be created. Template IDs of Data 865 Sets are numbered from 256 to 65535. There are no constraints 866 regarding the order of the Template ID allocation. 868 Field Count 870 Number of fields in this Template Record. 872 The example in Figure L shows a Template Set with mixed standard and 873 enterprise-specific Information Elements. It consists of a Set 874 Header, a Template Header, and several Field Specifiers. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Set ID = 2 | Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Template ID = 256 | Field Count = N | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 |1| Information Element id. 1.1 | Field Length 1.1 | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Enterprise Number 1.1 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 |0| Information Element id. 1.2 | Field Length 1.2 | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | ... | ... | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |1| Information Element id. 1.N | Field Length 1.N | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Enterprise Number 1.N | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Template ID = 257 | Field Count = M | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |0| Information Element id. 2.1 | Field Length 2.1 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |1| Information Element id. 2.2 | Field Length 2.2 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Enterprise Number 2.2 | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | ... | ... | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 |1| Information Element id. 2.M | Field Length 2.M | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Enterprise Number 2.M | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Padding (opt) | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 Figure L: Template Set Example 914 Information Element Identifiers 1.2 and 2.1 are defined by the IETF 915 (Enterprise bit = 0) and, therefore, do not need an Enterprise Number 916 to identify them. 918 3.4.2. Options Template Record Format 920 Thanks to the notion of scope, The Options Template Record gives the 921 Exporter the ability to provide additional information to the 922 Collector that would not be possible with Flow Records alone. 924 One Options Template Record example is the "Flow Keys", which reports 925 the Flow Keys for a Template, which is defined as the scope. Another 926 example is the "Template configuration", which reports the 927 configuration sampling parameter(s) for the Template, which is 928 defined as the scope. 930 3.4.2.1. Scope 932 The scope, which is only available in the Options Template Set, gives 933 the context of the reported Information Elements in the Data Records. 934 Note that the IPFIX Message Header already contains the Observation 935 Domain ID (the identifier of the Observation Domain). If not zero, 936 this Observation Domain ID can be considered as an implicit scope for 937 the Data Records in the IPFIX Message. The Observation Domain ID 938 MUST be zero when the IPFIX Message contains Data Records with 939 different Observation Domain ID values defined as scopes. 941 Multiple Scope Fields MAY be present in the Options Template Record, 942 in which case, the composite scope is the combination of the scopes. 943 For example, if the two scopes are defined as "metering process" and 944 "template", the combined scope is this Template for this Metering 945 Process. The order of the Scope Fields, as defined in the Options 946 Template Record, is irrelevant in this case. However, if the order 947 of the Scope Fields in the Options Template Record is relevant, the 948 order of the Scope Fields MUST be used. For example, if the first 949 scope defines the filtering function, while the second scope defines 950 the sampling function, the order of the scope is important. Applying 951 the sampling function first, followed by the filtering function, 952 would lead to potentially different Data Records than applying the 953 filtering function first, followed by the sampling function. In this 954 case, the Collector deduces the function order by looking at the 955 order of the scope in the Options Template Record. 957 The scope is an Information Element specified in the IPFIX 958 Information Model [RFC5102bis]. An IPFIX-compliant implementation of 959 the Collecting Process SHOULD support this minimum set of Information 960 Elements as scope: LineCardId, TemplateId, exporterIPv4Address, 961 exporterIPv6Address, and ingressInterface. Note that other 962 Information Elements, such as meteringProcessId, exportingProcessId, 963 observationDomainId, etc. are also valid scopes. The IPFIX protocol 964 doesn't prevent the use of any Information Elements for scope. 965 However, some Information Element types don't make sense if specified 966 as scope; for example, the counter Information Elements. 968 Finally, note that the Scope Field Count MUST NOT be zero. 970 3.4.2.2. Options Template Record Format 972 An Options Template Record contains any combination of IANA-assigned 973 and/or enterprise-specific Information Elements identifiers. 975 The format of the Options Template Record is shown in Figure M. It 976 consists of an Options Template Record Header and one or more Field 977 Specifiers. The definition of the Field Specifiers is given in 978 Figure G above. 980 +--------------------------------------------------+ 981 | Options Template Record Header | 982 +--------------------------------------------------+ 983 | Field Specifier | 984 +--------------------------------------------------+ 985 | Field Specifier | 986 +--------------------------------------------------+ 987 ... 988 +--------------------------------------------------+ 989 | Field Specifier | 990 +--------------------------------------------------+ 992 Figure M: Options Template Record Format 994 The format of the Options Template Record Header is shown in Figure 995 N. 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Template ID (> 255) | Field Count | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Scope Field Count | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Figure N: Options Template Record Header Format 1007 The Options Template Record Header Field Definitions are as follows: 1009 Template ID 1011 Template ID of this Options Template Record. This value is greater 1012 than 255. 1014 Field Count 1016 Number of all fields in this Options Template Record, including the 1017 Scope Fields. 1019 Scope Field Count 1021 Number of scope fields in this Options Template Record. The Scope 1022 Fields are normal Fields except that they are interpreted as scope at 1023 the Collector. The Scope Field Count MUST NOT be zero. 1025 The example in Figure O shows an Options Template Set with mixed IETF 1026 and enterprise-specific Information Elements. It consists of a Set 1027 Header, an Options Template Header, and several Field Specifiers. 1029 0 1 2 3 1030 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Set ID = 3 | Length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Template ID = 258 | Field Count = N + M | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Scope 2 Field Length | ... | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | ... |1| Scope N Infor. Element Id. | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Scope N Field Length | Scope N Enterprise Number ... 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Option 1 Field Length | Option 1 Enterprise Number ... 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 ... Option 1 Enterprise Number | ... | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | ... |0| Option M Infor. Element Id. | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Option M Field Length | Padding (optional) | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Figure O: Options Template Set Example 1059 3.4.3. Data Record Format 1061 The Data Records are sent in Data Sets. The format of the Data 1062 Record is shown in Figure P. It consists only of one or more Field 1063 Values. The Template ID to which the Field Values belong is encoded 1064 in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 1066 +--------------------------------------------------+ 1067 | Field Value | 1068 +--------------------------------------------------+ 1069 | Field Value | 1070 +--------------------------------------------------+ 1071 ... 1072 +--------------------------------------------------+ 1073 | Field Value | 1074 +--------------------------------------------------+ 1076 Figure P: Data Record Format 1078 Note that Field Values do not necessarily have a length of 16 bits. 1079 Field Values are encoded according to their data type specified in 1080 [RFC5102bis]. 1082 Interpretation of the Data Record format can be done only if the 1083 Template Record corresponding to the Template ID is available at the 1084 Collecting Process. 1086 The example in Figure Q shows a Data Set. It consists of a Set Header 1087 and several Field Values. 1089 0 1 2 3 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Set ID = Template ID | Length | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Record 1 - Field Value 3 | ... | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Record 2 - Field Value 3 | ... | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Record 3 - Field Value 3 | ... | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | ... | Padding (optional) | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Figure Q: Data Set, Containing Data Records 1111 4. Specific Reporting Requirements 1113 Some specific Options Templates and Options Template Records are 1114 necessary to provide extra information about the Flow Records and 1115 about the Metering Process. 1117 The Options Template and Options Template Records defined in these 1118 subsections, which impose some constraints on the Metering Process 1119 and Exporting Process implementations, MAY be implemented. If 1120 implemented, the specific Options Templates SHOULD be implemented as 1121 specified in these subsections. 1123 The minimum set of Information Elements is always specified in these 1124 Specific IPFIX Options Templates. Nevertheless, extra Information 1125 Elements may be used in these specific Options Templates. 1127 The Collecting Process MUST check the possible combinations of 1128 Information Elements within the Options Template Records to correctly 1129 interpret the following Options Templates. 1131 4.1. The Metering Process Statistics Options Template 1133 The Metering Process Statistics Options Template specifies the 1134 structure of a Data Record for reporting Metering Process statistics. 1135 It SHOULD contain the following Information Elements that are 1136 defined in [RFC5102bis]: 1138 (scope) observationDomainId 1139 An identifier of an Observation Domain that 1140 is locally unique to the Exporting Process. 1141 This Information Element MUST be defined as a 1142 Scope Field. 1144 exportedMessageTotalCount 1145 The total number of IPFIX Messages that the 1146 Exporting Process successfully sent to the 1147 Collecting Process since the Exporting 1148 Process re-initialization. 1150 exportedFlowRecordTotalCount 1151 The total number of Flow Records that the 1152 Exporting Process successfully sent to the 1153 Collecting Process since the Exporting 1154 Process re-initialization. 1156 exportedOctetTotalCount 1157 The total number of octets that the Exporting 1158 Process successfully sent to the Collecting 1159 Process since the Exporting Process re- 1160 initialization. 1162 The Exporting Process SHOULD export the Data Record specified by the 1163 Metering Process Statistics Options Template on a regular basis or 1164 based on some export policy. This periodicity or export policy 1165 SHOULD be configurable. 1167 Note that if several Metering Processes are available on the Exporter 1168 Observation Domain, the Information Element meteringProcessId MUST be 1169 specified as an additional Scope Field. 1171 4.2. The Metering Process Reliability Statistics Options Template 1173 The Metering Process Reliability Options Template specifies the 1174 structure of a Data Record for reporting lack of reliability in the 1175 Metering Process. It SHOULD contain the following Information 1176 Elements that are defined in [RFC5102bis]: 1178 (scope) observationDomainId 1179 An identifier of an Observation Domain that 1180 is locally unique to the Exporting Process. 1181 This Information Element MUST be defined as a 1182 Scope Field. 1184 (scope) meteringProcessId 1185 The identifier of the Metering Process for 1186 which lack of reliability is reported. This 1187 Information Element MUST be defined as a 1188 Scope Field. 1190 ignoredPacketTotalCount 1191 The total number of IP packets that the 1192 Metering Process did not process. 1194 ignoredOctetTotalCount 1195 The total number of octets in observed IP 1196 packets that the Metering Process did not 1197 process. 1199 time first packet ignored 1200 The timestamp of the first IP packet that was 1201 ignored by the Metering Process. For this 1202 timestamp, any of the following timestamp can 1203 be used: observationTimeSeconds, 1204 observationTimeMilliseconds, 1205 observationTimeMicroseconds, or 1206 observationTimeNanoseconds. 1208 time last packet ignored 1209 The timestamp of the last IP packet that was 1210 ignored by the Metering Process. For this 1211 timestamp, any of the following timestamp can 1212 be used: observationTimeSeconds, 1213 observationTimeMilliseconds, 1214 observationTimeMicroseconds, or 1215 observationTimeNanoseconds. 1217 The Exporting Process SHOULD export the Data Record specified by the 1218 Metering Process Reliability Statistics Options Template on a regular 1219 basis or based on some export policy. This periodicity or export 1220 policy SHOULD be configurable. 1222 Note that if several Metering Processes are available on the Exporter 1223 Observation Domain, the Information Element meteringProcessId MUST be 1224 specified as an additional Scope Field. 1226 Since the Metering Process Reliability Option Template will logically 1227 contain two identical timestamp Information Elements, and since the 1228 order of the Information Elements in the Template Records is not 1229 guaranteed, the Collecting Process MUST determine which is the oldest 1230 and the most recent timestamp in order the determine the right 1231 semantic behind the time first packet ignored and time last packet 1232 ignored Information Elements. Note that the counters wrap-up for the 1233 timestamps SHOULD also be taken into account. 1235 4.3. The Exporting Process Reliability Statistics Options Template 1237 The Exporting Process Reliability Options Template specifies the 1238 structure of a Data Record for reporting lack of reliability in the 1239 Exporting process. It SHOULD contain the following Information 1240 Elements that are defined in [RFC5102bis]: 1242 (scope) Exporting Process ID 1243 The identifier of the Exporting Process for 1244 which lack of reliability is reported. There 1245 are three Information Elements specified in 1246 [RFC5102bis] that can be used for this purpose: 1247 exporterIPv4Address, exporterIPv6Address, or 1248 exportingProcessId. This Information Element 1249 MUST be defined as a Scope Field. 1251 notSentFlowTotalCount 1252 The total number of Flows that were generated by 1253 the Metering Process and dropped by the Metering 1254 Process or by the Exporting Process instead of 1255 being sent to the Collecting Process. 1257 notSentPacketTotalCount 1258 The total number of packets in Flow Records that 1259 were generated by the Metering Process and 1260 dropped by the Metering Process or by the 1261 Exporting Process instead of being sent to the 1262 Collecting Process. 1264 notSentOctetTotalCount 1265 The total number of octets in packets in Flow 1266 Records that were generated by the Metering 1267 Process and dropped by the Metering Process or 1268 by the Exporting Process instead of being sent 1269 to the Collecting Process. 1271 time first flow dropped 1272 The time at which the first Flow Record was 1273 dropped by the Exporting Process. For this 1274 timestamp, any of the following timestamp can be 1275 used: observationTimeSeconds, 1276 observationTimeMilliseconds, 1277 observationTimeMicroseconds, or 1278 observationTimeNanoseconds. 1280 time last flow dropped 1281 The time at which the last Flow Record was 1282 dropped by the Exporting Process. For this 1283 timestamp, any of the following timestamp can be 1284 used: observationTimeSeconds, 1285 observationTimeMilliseconds, 1286 observationTimeMicroseconds, or 1287 observationTimeNanoseconds. 1289 The Exporting Process SHOULD export the Data Record specified by the 1290 Exporting Process Reliability Statistics Options Template on a 1291 regular basis or based on some export policy. This periodicity or 1292 export policy SHOULD be configurable. 1294 Since the Exporting Process Reliability Option Template will 1295 logically contain two identical timestamp Information Elements, and 1296 since the order of the Information Elements in the Template Records 1297 is not guaranteed, the Collecting Process MUST determine which is the 1298 oldest and the most recent timestamp in order the determine the right 1299 semantic behind the time first packet ignored and time last packet 1300 ignored Information Elements. Note that the counters wrap-up for the 1301 timestamps SHOULD also be taken into account. 1303 4.4. The Flow Keys Options Template 1305 The Flow Keys Options Template specifies the structure of a Data 1306 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1307 Data Record extends a particular Template Record that is referenced 1308 by its templateId identifier. The Template Record is extended by 1309 specifying which of the Information Elements contained in the 1310 corresponding Data Records describe Flow properties that serve as 1311 Flow Keys of the reported Flow. 1313 The Flow Keys Options Template SHOULD contain the following 1314 Information Elements that are defined in [RFC5102bis]: 1316 (scope) templateId An identifier of a Template. This 1317 Information Element MUST be defined as a 1318 Scope Field. 1320 flowKeyIndicator Bitmap with the positions of the Flow Keys in 1321 the Data Records. 1323 5. IPFIX Message Header Export Time and Flow Record Time 1325 The IPFIX Message Header Export Time field is the time at which the 1326 IPFIX Message Header leaves the Exporter, expressed in seconds since 1327 the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded in an unsigned 1328 32-bit integer. 1330 Certain time-related Information Elements may be expressed as an 1331 offset from this Export Time. For example, Data Records requiring a 1332 microsecond precision can export the flow start and end times with 1333 the flowStartMicroseconds and flowEndMicroseconds Information 1334 Elements [RFC5102bis], which encode the absolute time in microseconds 1335 in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit 1336 field. An alternate solution is to export the 1337 flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information 1338 Elements [RFC5102bis] in the Data Record, which respectively report 1339 the flow start and end time as negative offsets from the Export Time, 1340 as an unsigned 32-bit integer. This latter solution lowers the export 1341 bandwidth requirement, saving two bytes per timestamp, while 1342 increasing the load on the Exporter, as the Exporting Process must 1343 calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 1344 of every single Data Record before exporting the IPFIX Message. 1346 It must be noted that timestamps based on the Export Time impose some 1347 time constraints on the Data Records contained within the IPFIX 1348 Message. In the example of flowStartDeltaMicroseconds and 1349 flowEndDeltaMicroseconds Information Elements [RFC5102bis], the Data 1350 Record can only contain records with timestamps within 71 minutes of 1351 the Export Time. Otherwise, the 32-bit counter would not be 1352 sufficient to contain the flow start time offset. 1354 6. Linkage with the Information Model 1356 The Information Elements [RFC5102bis] MUST be sent in canonical 1357 format in network-byte order (also known as the big-endian byte 1358 ordering). 1360 6.1. Encoding of IPFIX Data Types 1362 The following sections will define the encoding of the data types 1363 specified in [RFC5102bis]. 1365 6.1.1. Integral Data Types 1367 Integral data types -- octet, signed8, unsigned16, signed16, 1368 unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded 1369 using the default canonical format in network-byte order. Signed 1370 Integral data types are represented in two's complement notation. 1372 6.1.2. Address Types 1374 Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be 1375 encoded the same way as the integral data types. The macAddress is 1376 treated as a 6-octet integer, the ipv4Address as a 4-octet integer, 1377 and the ipv6Address as a 16-octet integer. 1379 6.1.3. float32 1381 The float32 data type MUST be encoded as an IEEE single-precision 1382 32-bit floating point-type, as specified in [IEEE.754.1985]. 1384 6.1.4. float64 1386 The float64 data type MUST be encoded as an IEEE double-precision 64- 1387 bit floating point-type, as specified in [IEEE.754.1985]. 1389 6.1.5. boolean 1391 The boolean data type is specified according to the TruthValue in 1392 [RFC2579]: it is an integer with the value 1 for true and a value 2 1393 for false. Every other value is undefined. The boolean data type 1394 MUST be encoded in a single octet. 1396 6.1.6. string and octetArray 1398 The data type string represents a finite length string of valid 1399 characters of the Unicode character encoding set. The string data 1400 type MUST be encoded in UTF-8 format. The string is sent as an array 1401 of octets using an Information Element of fixed or variable length. 1403 The length of the Information Element specifies the length of the 1404 octetArray. 1406 6.1.7. dateTimeSeconds 1408 The data type dateTimeSeconds is an unsigned 32 bit integer 1409 containing the number of seconds since the UNIX epoch, 1 January 1970 1410 at 00:00 UTC. dateTimeSeconds is encoded identically to the IPFIX 1411 Message Header Export Time field. It can represent dates between 1 1412 January 1970 and 8 February 2106. 1414 6.1.8. dateTimeMilliseconds 1416 The data type dateTimeMilliseconds is an unsigned 64-bit integer 1417 containing the number of milliseconds since the UNIX epoch, 1 January 1418 1970 at 00:00 UTC. It can represent dates beginning on 1 January 1970 1419 for approximately the next 500 billion years. 1421 6.1.9 dateTimeMicroseconds 1423 The data type dateTimeMicroseconds is a 64-bit field encoded 1424 according to the NTP Timestamp format as defined in section 6 of 1425 [RFC5905]. This field is made up of two unsigned 32-bit integers, 1426 Seconds and Fraction. The Seconds field is the number of seconds 1427 since the NTP epoch, 1 January 1900 at 00:00 UTC. The Fraction field 1428 is the fractional number of seconds in units of 1/(2^32) seconds 1429 (approximately 233 picoseconds). It can represent dates beginning 1430 between 1 January 1900 and 8 February 2036. 1432 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1433 identical encoding. The dataTimeMicroseconds data type is intended 1434 only to represent timestamps of microsecond precision. Therefore, the 1435 bottom 11 bits of the fraction field MAY contain any value and MUST 1436 be ignored for all Information Elements of this data type (as 2^11 x 1437 233 picoseconds = .477 microseconds). 1439 6.1.10 dateTimeNanoseconds 1441 The data type dateTimeNanoseconds is a 64-bit field encoded according 1442 to the NTP Timestamp format as defined in section 6 of [RFC5905]. 1443 This field is made up of two unsigned 32-bit integers, Seconds and 1444 Fraction. The Seconds field is the number of seconds since the NTP 1445 epoch, 1 January 1900 at 00:00 UTC. The Fraction field is the 1446 fractional number of seconds in units of 1/(2^32) seconds 1447 (approximately 233 picoseconds). It can represent dates beginning 1448 between 1 January 1900 and 8 February 2036. 1450 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1451 identical encoding. There is no restriction on the interpretation of 1452 the Fraction field for the dateTimeNanoseconds data type. 1454 6.2. Reduced Size Encoding of Integer and Float Types 1456 Information Elements containing integer, string, float, and 1457 octetArray types in the information model MAY be encoded using fewer 1458 octets than those implied by their type in the information model 1459 definition [RFC5102bis], based on the assumption that the smaller 1460 size is sufficient to carry any value the Exporter may need to 1461 deliver. This reduces the network bandwidth requirement between the 1462 Exporter and the Collector. Note that the Information Element 1463 definitions [RFC5102bis] will always define the maximum encoding 1464 size. 1466 For instance, the information model [RFC5102bis] defines byteCount as 1467 an unsigned64 type, which would require 64 bits. However, if the 1468 Exporter will never locally encounter the need to send a value larger 1469 than 4294967295, it may chose to send the value instead as an 1470 unsigned32. For example, a core router would require an unsigned64 1471 byteCount, while an unsigned32 might be sufficient for an access 1472 router. 1474 This behavior is indicated by the Exporter by specifying a type size 1475 with a smaller length than that associated with the assigned type of 1476 the Information Element. In the example above, the Exporter would 1477 place a length of 4 versus 8 in the Template. 1479 If reduced size encoding is used, it MUST only be applied to the 1480 following integer types: unsigned64, signed64, unsigned32, signed32, 1481 unsigned16, and signed16. The signed versus unsigned property of the 1482 reported value MUST be preserved. The reduction in size can be to 1483 any number of octets smaller than the original type if the data value 1484 still fits, i.e., so that only leading zeroes are dropped. For 1485 example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1486 1 octet(s). 1488 Reduced size encoding can also be used to reduce float64 to float32. 1489 The float32 not only has a reduced number range, but due to the 1490 smaller mantissa, is also less precise. 1492 The reduced size encoding MUST NOT be applied to dateTimeMicroseconds 1493 or to dateTimeNanoseconds because these represent an inherent 1494 structure that would be destroyed by using less than the original 1495 number of bytes. 1497 7. Variable-Length Information Element 1498 The IPFIX Template mechanism is optimized for fixed-length 1499 Information Elements [RFC5102bis]. Where an Information Element has 1500 a variable length, the following mechanism MUST be used to carry the 1501 length information for both the IETF and proprietary Information 1502 Elements. 1504 In the Template Set, the Information Element Field Length is recorded 1505 as 65535. This reserved length value notifies the Collecting Process 1506 that length of the Information Element will be carried in the 1507 Information Element content itself. 1509 In most cases, the length of the Information Element will be less 1510 than 255 octets. The following length-encoding mechanism optimizes 1511 the overhead of carrying the Information Element length in this 1512 majority case. The length is carried in the octet before the 1513 Information Element, as shown in Figure R. 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Length (< 255)| Information Element | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | ... continuing as needed | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Figure R: Variable-Length Information Element (length < 255 octets) 1525 The length may also be encoded into 3 octets before the Information 1526 element allowing the length of the Information Element to be greater 1527 than or equal to 255 octets. In this case, first octet of the Length 1528 field MUST be 255, and the length is carried in the second and third 1529 octets, as shown in Figure S. 1531 0 1 2 3 1532 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 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | 255 | Length (0 to 65535) | IE | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | ... continuing as needed | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Figure S: Variable-Length Information Element (length 0 to 65535 1540 octets) 1542 The octets carrying the length (either the first or the first three 1543 octets) MUST NOT be included in the length of the Information 1544 Element. 1546 8. Template Management 1548 This section describes Template Management when using SCTP and 1549 PR-SCTP as the transport protocol. Any necessary changes to Template 1550 Management specifically related to TCP or UDP transport protocols are 1551 specified in Section 10. 1553 The Exporting Process assigns and maintains the Template IDs per SCTP 1554 association for the Exporter's Observation Domains. A newly created 1555 Template Record is assigned an unused Template ID by the Exporting 1556 Process. 1558 If a specific Information Element is required by a Template, but is 1559 not available in observed packets, the Exporting Process MAY choose 1560 to export Flow Records without this Information Element in a Data 1561 Record defined by a new Template. 1563 If an Information Element is required more than once in a Template, 1564 the different occurrences of this Information Element SHOULD follow 1565 the logical order of their treatments by the Metering Process. For 1566 example, if a selected packet goes through two hash functions, and if 1567 the two hash values are sent within a single Template, the first 1568 occurrence of the hash value should belong to the first hash function 1569 in the Metering Process. For example, when exporting the two source 1570 IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address 1571 Information Element occurrence should be the IPv4 address of the 1572 outer header, while the second occurrence should be the inner header 1573 one. 1575 Template Sets and Options Template Sets may be sent on any SCTP 1576 stream. Template Sets and Options Template Sets MUST be sent 1577 reliably, using SCTP-ordered delivery. As such, the Collecting 1578 Process MUST store the Template Record information for the duration 1579 of the SCTP association so that it can interpret the corresponding 1580 Data Records that are received in subsequent Data Sets. 1582 The Exporting Process SHOULD transmit the Template Set and Options 1583 Template Set in advance of any Data Sets that use that (Options) 1584 Template ID, to help ensure that the Collector has the Template 1585 Record before receiving the first Data Record. Data Records that 1586 correspond to a Template Record MAY appear in the same and/or 1587 subsequent IPFIX Message(s). 1589 Different Observation Domains from the same SCTP association may use 1590 the same Template ID value to refer to different Templates. 1592 The Templates that are not used anymore SHOULD be deleted. Before 1593 reusing a Template ID, the Template MUST be deleted. In order to 1594 delete an allocated Template, the Template is withdrawn through the 1595 use of a Template Withdrawal Message. 1597 The Template Withdrawal Message MUST NOT be sent until sufficient 1598 time has elapsed to allow the Collecting Process to receive and 1599 process the last Data Record using this Template information. This 1600 time MUST be configurable. A suitable default value is 5 seconds 1601 after the last Data Record has been sent. 1603 The Template ID from a withdrawn Template MUST NOT be reused until 1604 sufficient time has elapsed to allow for the Collecting Process to 1605 receive and process the Template Withdrawal Message. 1607 A Template Withdrawal Message is a Template Record for that Template 1608 ID with a Field Count of 0. The format of the Template Withdrawal 1609 Message is shown in Figure T. 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Set ID = (2 or 3) | Length = 16 | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Template ID N | Field Count = 0 | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Template ID ... | Field Count = 0 | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Template ID M | Field Count = 0 | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 Figure T: Template Withdrawal Message Format 1625 The Set ID field MUST contain the value 2 for Template Set Withdrawal 1626 and the value 3 for Options Template Set Withdrawal. Multiple 1627 Template IDs MAY be withdrawn with a single Template Withdrawal 1628 Message, in that case, padding MAY be used. 1630 The Template Withdrawal Message withdraws the Template IDs for the 1631 Observation Domain ID specified in the IPFIX Message Header. 1633 The Template Withdrawal Message may be sent on any SCTP stream. The 1634 Template Withdrawal Message MUST be sent reliably, using SCTP-ordered 1635 delivery. 1637 The Template Withdrawal Message MUST NOT contain new Template or 1638 Options Template Records. 1640 If the measurement parameters change such that a new Template is 1641 required, the Template MUST be withdrawn (using a Template Withdrawal 1642 Message and a new Template definition) or an unused Template ID MUST 1643 be used. Examples of the measurement changes are: a new Flow 1644 expiration process, a new filtering definition, etc. 1646 When the SCTP association shuts down or the Exporting Process 1647 restarts, all Template assignments are lost and Template IDs MUST be 1648 reassigned. 1650 If the Metering Process restarts, the Exporting Process MUST either 1651 reuse the previously assigned Template ID for each Template, or it 1652 MUST withdraw the previously issued Template IDs by sending Template 1653 Withdrawal Message(s) before reusing them. 1655 A Template Withdrawal Message to withdraw all Templates for the 1656 Observation Domain ID specified in the IPFIX Message Header MAY be 1657 used. Its format is shown in Figure U. 1659 0 1 2 3 1660 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 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | Set ID = 2 | Length = 8 | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Template ID = 2 | Field Count = 0 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 Figure U: All Data Templates Withdrawal Message Format 1669 A Template Withdrawal Message to withdraw all Options Templates for 1670 the Observation Domain ID specified in the IPFIX Message Header MAY 1671 be used. Its format is shown in Figure V. 1673 0 1 2 3 1674 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 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Set ID = 3 | Length = 8 | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Template ID = 3 | Field Count = 0 | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Figure V: All Options Templates Withdrawal Message Format 1683 When the SCTP association restarts, the Exporting Process MUST resend 1684 all the Template Records. 1686 9. The Collecting Process's Side 1688 This section describes the Collecting Process when using SCTP and PR- 1689 SCTP as the transport protocol. Any necessary changes to the 1690 Collecting Process specifically related to TCP or UDP transport 1691 protocols are specified in Section 10. 1693 The Collecting Process SHOULD listen for a new association request 1694 from the Exporting Process. The Exporting Process will request a 1695 number of streams to use for export. An Exporting Process MAY 1696 request and support more than one stream per SCTP association. 1698 If the Collecting Process receives a malformed IPFIX Message, it MUST 1699 reset the SCTP association, discard the IPFIX Message, and SHOULD log 1700 the error. Note that non-zero Set padding does not constitute a 1701 malformed IPFIX Message. 1703 Template Sets and Options Template Sets are only sent once. The 1704 Collecting Process MUST store the Template Record information for the 1705 duration of the association so that it can interpret the 1706 corresponding Data Records that are received in subsequent Data Sets. 1708 Template IDs are unique per SCTP association and per Observation 1709 Domain. If the Collecting Process receives a Template that has 1710 already been received but that has not previously been withdrawn 1711 (i.e., a Template Record from the same Exporter Observation Domain 1712 with the same Template ID received on the SCTP association), then the 1713 Collecting Process MUST shut down the association. 1715 When an SCTP association is closed, the Collecting Process MUST 1716 discard all Templates received over that association and stop 1717 decoding IPFIX Messages that use those Templates. 1719 The Collecting Process normally receives Template Records from the 1720 Exporting Process before receiving Data Records. The Data Records 1721 are then decoded and stored by the Collector. If the Template 1722 Records have not been received at the time Data Records are received, 1723 the Collecting Process MAY store the Data Records for a short period 1724 of time and decode them after the Template Records are received. A 1725 Collecting Process MUST NOT assume that the Data Set and the 1726 associated Template Set (or Options Template Set) are exported in the 1727 same IPFIX Message. 1729 The Collecting Process MUST note the Information Element identifier 1730 of any Information Element that it does not understand and MAY 1731 discard that Information Element from the Flow Record. 1733 The Collector MUST accept padding in Data Records and Template 1734 Records. The padding size is the Set Length minus the size of the 1735 Set Header (4 octets for the Set ID and the Set Length), modulo the 1736 Record size deduced from the Template Record. 1738 The IPFIX protocol has a Sequence Number field in the Export header 1739 that increases with the number of IPFIX Data Records in the IPFIX 1740 Message. A Collector may detect out-of-sequence, dropped, or 1741 duplicate IPFIX Messages by tracking the Sequence Number. A 1742 Collector SHOULD provide a logging mechanism for tracking 1743 out-of-sequence IPFIX Messages. Such out-of-sequence IPFIX Messages 1744 may be due to Exporter resource exhaustion where it cannot transmit 1745 messages at their creation rate, an Exporting Process reset, 1746 congestion on the network link between the Exporter and Collector, 1747 Collector resource exhaustion where it cannot process the IPFIX 1748 Messages at their arrival rate, out-of-order packet reception, 1749 duplicate packet reception, or an attacker injecting false messages. 1751 If a Collecting Process receives a Template Withdrawal Message, the 1752 Collecting Process MUST delete the corresponding Template Records 1753 associated with the specific SCTP association and specific 1754 Observation Domain, and stop decoding IPFIX Messages that use the 1755 withdrawn Templates. 1757 If the Collecting Process receives a Template Withdrawal Message for 1758 a Template Record it has not received before on this SCTP 1759 association, it MUST reset the SCTP association, discard the IPFIX 1760 Message, and SHOULD log the error as it does for malformed IPFIX 1761 Messages. 1763 A Collecting Process that receives IPFIX Messages from several 1764 Observation Domains on the same Transport Session MUST be aware that 1765 the uniqueness of the Template ID is not guaranteed across 1766 Observation Domains. 1768 The Collector MUST support the use of Templates containing multiple 1769 occurrences of the similar Information Elements. 1771 10. Transport Protocol 1773 The IPFIX Protocol Specification has been designed to be transport 1774 protocol independent. Note that the Exporter can export to multiple 1775 Collecting Processes using independent transport protocols. 1777 The IPFIX Message Header 16-bit Length field limits the length of an 1778 IPFIX Message to 65535 octets, including the header. A Collecting 1779 Process MUST be able to handle IPFIX Message lengths of up to 65535 1780 octets. 1782 10.1. Transport Compliance and Transport Usage 1784 We need to differentiate between what must be implemented (so that 1785 operators can interoperably deploy compliant implementations from 1786 different vendors) and what should or could be used in various 1787 operational environments. We must also make sure that ALL 1788 implementations can operate in a congestion-aware and 1789 congestion-avoidance mode. 1791 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 1792 MUST be implemented by all compliant implementations. UDP [UDP] MAY 1793 also be implemented by compliant implementations. TCP [TCP] MAY also 1794 be implemented by compliant implementations. 1796 PR-SCTP SHOULD be used in deployments where Exporters and Collectors 1797 are communicating over links that are susceptible to congestion. 1798 PR-SCTP is capable of providing any required degree of reliability. 1800 TCP MAY be used in deployments where Exporters and Collectors 1801 communicate over links that are susceptible to congestion, but 1802 PR-SCTP is preferred due to its ability to limit back pressure on 1803 Exporters and its message versus stream orientation. 1805 UDP MAY be used, although it is not a congestion-aware protocol. 1806 However, the IPFIX traffic between Exporter and Collector MUST run in 1807 an environment where IPFIX traffic has been provisioned for, or is 1808 contained through some other means. 1810 10.2. SCTP 1812 This section describes how IPFIX can be transported over SCTP 1813 [RFC4960] using the PR-SCTP [RFC3758] extension. 1815 10.2.1. Congestion Avoidance 1817 The SCTP transport protocol provides the required level of congestion 1818 avoidance by design. 1820 SCTP will detect congestion in the end-to-end path between the IPFIX 1821 Exporting Process and the IPFIX Collecting Process, and limit the 1822 transfer rate accordingly. When an IPFIX Exporting Process has 1823 records to export, but detects that transmission by SCTP is 1824 temporarily impossible, it can either wait until sending is possible 1825 again, or it can decide to drop the record. In the latter case, the 1826 dropped export data MUST be accounted for, so that the amount of 1827 dropped export data can be reported. 1829 10.2.2. Reliability 1831 The SCTP transport protocol is by default reliable, but has the 1832 capability to deliver messages with partial reliability [RFC3758]. 1834 Using reliable SCTP messages for the IPFIX export is not in itself a 1835 guarantee that all Data Records will be delivered. If there is 1836 congestion on the link from the Exporting Process to the Collecting 1837 Process, or if a significant number of retransmissions are required, 1838 the send queues on the Exporting Process may fill up; the Exporting 1839 Process MAY either suspend, export, or discard the IPFIX Messages. 1840 If Data Records are discarded the IPFIX Sequence Numbers used for 1841 export MUST reflect the loss of data. 1843 10.2.3. MTU 1845 SCTP provides the required IPFIX Message fragmentation service based 1846 on path MTU discovery. 1848 10.2.4. Exporting Process 1850 10.2.4.1. Association Establishment 1852 The IPFIX Exporting Process SHOULD initiate an SCTP association with 1853 the IPFIX Collecting Process. By default, the Collecting Process 1854 listens for connections on SCTP port 4739. By default, the 1855 Collecting Process listens for secure connections on SCTP port 4740 1856 (refer to the Security Considerations section). By default, the 1857 Exporting Process tries to connect to one of these ports. It MUST be 1858 possible to configure both the Exporting and Collecting Processes to 1859 use a different SCTP port. 1861 The Exporting Process MAY establish more than one association 1862 (connection "bundle" in SCTP terminology) to the Collecting Process. 1864 An Exporting Process MAY support more than one active association to 1865 different Collecting Processes (including the case of different 1866 Collecting Processes on the same host). 1868 10.2.4.2. Association Shutdown 1870 When an Exporting Process is shut down, it SHOULD shut down the SCTP 1871 association. 1873 When a Collecting Process no longer wants to receive IPFIX Messages, 1874 it SHOULD shut down its end of the association. The Collecting 1875 Process SHOULD continue to receive and process IPFIX Messages until 1876 the Exporting Process has closed its end of the association. 1878 When a Collecting Process detects that the SCTP association has been 1879 abnormally terminated, it MUST continue to listen for a new 1880 association establishment. 1882 When an Exporting Process detects that the SCTP association to the 1883 Collecting Process is abnormally terminated, it SHOULD try to 1884 re-establish the association. 1886 Association timeouts SHOULD be configurable. 1888 10.2.4.3. Stream 1890 An Exporting Process MAY request more than one SCTP stream per 1891 association. Each of these streams may be used for the transmission 1892 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 1893 Template Sets. 1895 Depending on the requirements of the application, the Exporting 1896 Process may send Data Sets with full or partial reliability, using 1897 ordered or out-of-order delivery, over any SCTP stream established 1898 during SCTP Association setup. 1900 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 1901 per Section 4 of the PR-SCTP [RFC3758] specification when using 1902 partial reliability to transmit IPFIX Messages containing only Data 1903 Sets. 1905 However, Exporting Processes SHOULD mark such IPFIX Messages for 1906 retransmission for as long as resource or other constraints allow. 1908 10.2.4.4. Template Management 1910 When the transport protocol is SCTP, the default Template Management 1911 described in Section 8 is used. 1913 10.2.5. Collecting Process 1915 When the transport protocol is SCTP, the default Collector processing 1916 described in Section 9 is used. 1918 10.2.6. Failover 1920 If the Collecting Process does not acknowledge the attempt by the 1921 Exporting Process to establish an association, the Exporting Process 1922 should retry using the SCTP exponential backoff feature. The 1923 Exporter MAY log an alarm if the time to establish the association 1924 exceeds a specified threshold, configurable on the Exporter. 1926 If Collecting Process failover is supported by the Exporting Process, 1927 a second SCTP association MAY be opened in advance. 1929 10.3. UDP 1931 This section describes how IPFIX can be transported over UDP [UDP]. 1933 10.3.1. Congestion Avoidance 1935 UDP has no integral congestion-avoidance mechanism. Its use over 1936 congestion-sensitive network paths is therefore not recommended. UDP 1937 MAY be used in deployments where Exporters and Collectors always 1938 communicate over dedicated links that are not susceptible to 1939 congestion, i.e., over provisioned links compared to the maximum 1940 export rate from the Exporters. 1942 10.3.2. Reliability 1944 UDP is not a reliable transport protocol, and cannot guarantee 1945 delivery of messages. IPFIX Messages sent from the Exporting Process 1946 to the Collecting Process using UDP may therefore be lost. UDP MUST 1947 NOT be used unless the application can tolerate some loss of IPFIX 1948 Messages. 1950 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 1951 Data Records by looking at the discontinuities in the IPFIX Sequence 1952 Number. In the case of UDP, the IPFIX Sequence Number contains the 1953 total number of IPFIX Data Records sent for the UDP Transport Session 1954 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 1955 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 1956 by tracking the Sequence Number. Templates sent from the Exporting 1957 Process to the Collecting Process using UDP as a transport MUST be 1958 re-sent at regular intervals, in case previous copies were lost. 1960 10.3.3. MTU 1962 The maximum size of exported messages MUST be configured such that 1963 the total packet size does not exceed the path MTU. If the path MTU 1964 is unknown, a maximum packet size of 512 octets SHOULD be used. 1966 10.3.4. Port Numbers 1968 By default, the Collecting Process listens on the UDP port 4739. By 1969 default, the Collecting Process listens for secure connections on UDP 1970 port 4740 (refer to the "Security Considerations" section). By 1971 default, the Exporting Process tries to connect to one of these 1972 ports. It MUST be possible to configure both the Exporting and 1973 Collecting Processes to use a different UDP port. 1975 10.3.5. Exporting Process 1977 The Exporting Process MAY duplicate the IPFIX Message to the several 1978 Collecting Processes. 1980 10.3.6. Template Management 1982 When IPFIX uses UDP as the transport protocol, Template Sets and 1983 Options Template Sets MUST be re-sent at regular intervals. The 1984 frequency of the (Options) Template transmission MUST be 1985 configurable. The default value for the frequency of the (Options) 1986 Template transmission is 10 minutes. Note that the frequency of the 1987 (Options) Template transmission can be monitored and configured with 1988 the templateRefreshTimeout and optionsTemplateRefreshTimeout in 1989 [IPFIX-CONF]. The Exporting Process SHOULD transmit the Template Set 1990 and Options Template Set in advance of any Data Sets that use that 1991 (Options) Template ID to help ensure that the Collector has the 1992 Template Record before receiving the first Data Record. 1994 In the event of configuration changes, the Exporting Process SHOULD 1995 send multiple copies of the new Template definitions, in different 1996 IPFIX Messages, at an accelerated rate. In such a case, it SHOULD 1997 transmit the changed Template Record(s) and Options Template 1998 Record(s), without any data, in advance to help ensure that the 1999 Collector will have the correct Template information before receiving 2000 the first data. 2002 If the Options Template scope is defined in another Template, then 2003 both Templates SHOULD be sent in the same IPFIX Message. For 2004 example, if a Flow Key Options Template (see Section 4.4) is sent in 2005 an Options Template, then the associated Template SHOULD be sent in 2006 the same IPFIX Message. 2008 Following a configuration change that can modify the interpretation 2009 of the Data Records (for example, a sampling rate change) a new 2010 Template ID MUST be used, and the old Template ID MUST NOT be reused 2011 until its lifetime (see Section 10.3.7) has expired. 2013 If UDP is selected as the transport protocol, the Template Withdrawal 2014 Messages MUST NOT be used, as this method is inefficient due to the 2015 unreliable nature of UDP. 2017 10.3.7. Collecting Process 2019 The Collecting Process MUST associate a lifetime with each Template 2020 (or another definition of an identifier considered unique within the 2021 Transport Session) received via UDP. Templates (and similar 2022 definitions) not refreshed by the Exporting Process within the 2023 lifetime are expired at the Collecting Process. If the Template (or 2024 other definition) is not refreshed before that lifetime has expired, 2025 the Collecting Process MUST discard that definition and any current 2026 and future associated Data Records. In which case, an alarm MUST be 2027 logged. The Collecting Process MUST NOT decode any further Data 2028 Records that are associated with the expired Template. If a Template 2029 is refreshed with a Template Record that differs from the previously 2030 received Template Record, the Collecting Process SHOULD log a warning 2031 and replace the previously received Template Record with the new one. 2032 The Template lifetime at the Collecting Process MUST be at least 3 2033 times higher than the Template refresh timeout configured on the 2034 Exporting Process. 2036 Template IDs are unique per UDP session and per Observation Domain. 2037 At any given time, the Collecting Process SHOULD maintain the 2038 following for all the current Template Records and Options Template 2039 Records: . 2042 The Collecting Process SHOULD accept Data Records without the 2043 associated Template Record (or other definitions) required to decode 2044 the Data Record. If the Template Records (or other definitions such 2045 as Common Properties) have not been received at the time Data Records 2046 are received, the Collecting Process SHOULD store the Data Records 2047 for a short period of time and decode them after the Template Records 2048 (or other definitions) are received. The short period of time MUST 2049 be lower than the lifetime of definitions associated with identifiers 2050 considered unique within the UDP session. 2052 If the Collecting Process receives a malformed IPFIX Message, it MUST 2053 discard the IPFIX Message and SHOULD log the error. 2055 10.3.8. Failover 2057 Because UDP is not a connection-oriented protocol, the Exporting 2058 Process is unable to determine from the transport protocol that the 2059 Collecting Process is no longer able to receive the IPFIX Messages. 2060 Therefore, it cannot invoke a failover mechanism. However, the 2061 Exporting Process MAY duplicate the IPFIX Message to several 2062 Collecting Processes. 2064 10.4. TCP 2066 This section describes how IPFIX can be transported over TCP [TCP]. 2068 10.4.1. Connection Management 2070 10.4.1.1. Connection Establishment 2072 The IPFIX Exporting Process initiates a TCP connection to the 2073 Collecting Process. By default, the Collecting Process listens for 2074 connections on TCP port 4739. By default, the Collecting Process 2075 listens for secure connections on TCP port 4740 (refer to the 2076 Security Considerations section). By default, the Exporting Process 2077 tries to connect to one of these ports. It MUST be possible to 2078 configure both the Exporting Process and the Collecting Process to 2079 use a different TCP port. 2081 An Exporting Process MAY support more than one active connection to 2082 different Collecting Processes (including the case of different 2083 Collecting Processes on the same host). 2085 The Exporter MAY log an alarm if the time to establish the connection 2086 exceeds a specified threshold, configurable on the Exporter. 2088 10.4.1.2. Graceful Connection Release 2090 When an Exporting Process is shut down, it SHOULD shut down the TCP 2091 connection. 2093 When a Collecting Process no longer wants to receive IPFIX Messages, 2094 it SHOULD close its end of the connection. The Collecting Process 2095 SHOULD continue to read IPFIX Messages until the Exporting Process 2096 has closed its end. 2098 10.4.1.3. Restarting Interrupted Connections 2100 When a Collecting Process detects that the TCP connection to the 2101 Exporting Process has terminated abnormally, it MUST continue to 2102 listen for a new connection. 2104 When an Exporting Process detects that the TCP connection to the 2105 Collecting Process has terminated abnormally, it SHOULD try to 2106 re-establish the connection. Connection timeouts and retry schedules 2107 SHOULD be configurable. In the default configuration, an Exporting 2108 Process MUST NOT attempt to establish a connection more frequently 2109 than once per minute. 2111 10.4.1.4. Failover 2113 If the Collecting Process does not acknowledge the attempt by the 2114 Exporting Process to establish a connection, it will retry using the 2115 TCP exponential backoff feature. 2117 If Collecting Process failover is supported by the Exporting Process, 2118 a second TCP connection MAY be opened in advance. 2120 10.4.2. Data Transmission 2122 Once a TCP connection is established, the Exporting Process starts 2123 sending IPFIX Messages to the Collecting Process. 2125 10.4.2.1. IPFIX Message Encoding 2127 IPFIX Messages are sent over the TCP connection without any special 2128 encoding. The Length field in the IPFIX Message Header defines the 2129 end of each IPFIX Message and thus the start of the next IPFIX 2130 Message. This means that IPFIX Messages cannot be interleaved. 2132 In the case of TCP, the IPFIX Sequence Number contains the total 2133 number of IPFIX Data Records sent from this TCP connection, from the 2134 current Observation Domain by the Exporting Process, prior to the 2135 receipt of this IPFIX Message, modulo 2^32. 2137 If an Exporting Process exports data from multiple Observation 2138 Domains, it should be careful to choose IPFIX Message lengths 2139 appropriately to minimize head-of-line blocking between different 2140 Observation Domains. Multiple TCP connections MAY be used to avoid 2141 head-of-line between different Observation Domains. 2143 10.4.2.2. Template Management 2145 For each Template, the Exporting Process MUST send the Template 2146 Record before exporting Data Records that refer to that Template. 2148 Template IDs are unique per TCP connection and per Observation 2149 Domain. A Collecting Process MUST record all Template and Options 2150 Template Records for the duration of the connection, as an Exporting 2151 Process is not required to re-export Template Records. 2153 When the TCP connection restarts, the Exporting Process MUST resend 2154 all the Template Records. 2156 When a TCP connection is closed, the Collecting Process MUST discard 2157 all Templates received over that connection and stop decoding IPFIX 2158 Messages that use those Templates. 2160 The Templates that are not used anymore SHOULD be deleted. Before 2161 reusing a Template ID, the Template MUST be deleted. In order to 2162 delete an allocated Template, the Template is withdrawn through the 2163 use of a Template Withdrawal Message over the TCP connection. 2165 If the Collecting Process receives a malformed IPFIX Message, it MUST 2166 reset the TCP connection, discard the IPFIX Message, and SHOULD log 2167 the error. 2169 10.4.2.3. Congestion Handling and Reliability 2171 TCP ensures reliable delivery of data from the Exporting Process to 2172 the Collecting Process. TCP also controls the rate at which data can 2173 be sent from the Exporting Process to the Collecting Process, using a 2174 mechanism that takes into account both congestion in the network and 2175 the capabilities of the receiver. 2177 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2178 Messages at the rate that the Metering Process generates it, either 2179 because of congestion in the network or because the Collecting 2180 Process cannot handle IPFIX Messages fast enough. As long as 2181 congestion is transient, the Exporting Process can buffer IPFIX 2182 Messages for transmission. But such buffering is necessarily 2183 limited, both because of resource limitations and because of 2184 timeliness requirements, so ongoing and/or severe congestion may lead 2185 to a situation where the Exporting Process is blocked. 2187 When an Exporting Process has Data Records to export but the 2188 transmission buffer is full, and it wants to avoid blocking, it can 2189 decide to drop some Data Records. The dropped Data Records MUST be 2190 accounted for, so that the amount can later be exported. 2192 When an Exporting Process finds that the rate at which records should 2193 be exported is consistently higher than the rate at which TCP sending 2194 permits, it should provide back pressure to the Metering Processes. 2195 The Metering Process could then adapt by temporarily reducing the 2196 amount of data it generates, for example, using sampling or 2197 aggregation. 2199 10.4.3. Collecting Process 2201 The Collecting Process SHOULD listen for a new TCP connection from 2202 the Exporting Process. 2204 If the Collecting Process receives a malformed IPFIX Message, it MUST 2205 reset the TCP connection, discard the IPFIX Message, and SHOULD log 2206 the error. Note that non-zero Set padding does not constitute a 2207 malformed IPFIX Message. 2209 Template Sets and Options Template Sets are only sent once. The 2210 Collecting Process MUST store the Template Record information for the 2211 duration of the connection so that it can interpret the corresponding 2212 Data Records that are received in subsequent Data Sets. 2214 Template IDs are unique per TCP connection and per Observation 2215 Domain. If the Collecting Process receives a Template that has 2216 already been received but that has not previously been withdrawn 2217 (i.e., a Template Record from the same Exporter Observation Domain 2218 with the same Template ID received on the TCP connection), then the 2219 Collecting Process MUST shut down the connection. 2221 When a TCP connection is closed, the Collecting Process MUST discard 2222 all Templates received over that connection and stop decoding IPFIX 2223 Messages that use those Templates. 2225 If a Collecting Process receives a Template Withdrawal Message, the 2226 Collecting Process MUST delete the corresponding Template Records 2227 associated with the specific TCP connection and specific Observation 2228 Domain, and stop decoding IPFIX Messages that use the withdrawn 2229 Templates. 2231 If the Collecting Process receives a Template Withdrawal Message for 2232 a Template Record it has not received before on this TCP connection, 2233 it MUST reset the TCP association, discard the IPFIX Message, and 2234 SHOULD log the error as it does for malformed IPFIX Messages. 2236 11. Security Considerations 2238 The security considerations for the IPFIX protocol have been derived 2239 from an analysis of potential security threats, as discussed in the 2240 "Security Considerations" section of IPFIX requirements [RFC3917]. 2241 The requirements for IPFIX security are as follows: 2243 1. IPFIX must provide a mechanism to ensure the confidentiality of 2244 IPFIX data transferred from an Exporting Process to a Collecting 2245 Process, in order to prevent disclosure of Flow Records 2246 transported via IPFIX. 2248 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2249 data transferred from an Exporting Process to a Collecting 2250 Process, in order to prevent the injection of incorrect data or 2251 control information (e.g., Templates) into an IPFIX Message 2252 stream. 2254 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2255 and Exporting Processes, to prevent the collection of data from an 2256 unauthorized Exporting Process or the export of data to an 2257 unauthorized Collecting Process. 2259 Because IPFIX can be used to collect information for network 2260 forensics and billing purposes, attacks designed to confuse, disable, 2261 or take information from an IPFIX collection system may be seen as a 2262 prime objective during a sophisticated network attack. 2264 An attacker in a position to inject false messages into an IPFIX 2265 Message stream can either affect the application using IPFIX (by 2266 falsifying data), or the IPFIX Collecting Process itself (by 2267 modifying or revoking Templates, or changing options); for this 2268 reason, IPFIX Message integrity is important. 2270 The IPFIX Messages themselves may also contain information of value 2271 to an attacker, including information about the configuration of the 2272 network as well as end-user traffic and payload data, so care must be 2273 taken to confine their visibility to authorized users. When an 2274 Information Element containing end-user payload information is 2275 exported, it SHOULD be transmitted to the Collecting Process using a 2276 means that secures its contents against eavesdropping. Suitable 2277 mechanisms include the use of either a direct point-to-point 2278 connection or the use of an encryption mechanism. It is the 2279 responsibility of the Collecting Process to provide a satisfactory 2280 degree of security for this collected data, including, if necessary, 2281 anonymization of any reported data. 2283 11.1. Applicability of TLS and DTLS 2285 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2286 Security (DTLS) [RFC4347] were designed to provide the 2287 confidentiality, integrity, and authentication assurances required by 2288 the IPFIX protocol, without the need for pre-shared keys. 2290 With the mandatory SCTP and PR-SCTP transport protocols for IPFIX, 2291 DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX 2292 transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is 2293 selected as the IPFIX transport protocol, TLS [RFC5246] MUST be 2294 implemented. 2296 Note that DTLS is selected as the security mechanism for SCTP and PR- 2297 SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they 2298 require all communication to be over reliable, bidirectional streams, 2299 and require one TLS connection per stream. This arrangement is not 2300 compatible with the rationale behind the choice of SCTP as an IPFIX 2301 transport protocol. 2303 Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man 2304 in the middle may attempt to take data out of an association and fool 2305 the sender into thinking that the data was actually received by the 2306 peer. In generic TLS for SCTP (and/or TCP), this is not possible. 2307 This means that the removal of a message may become hidden from the 2308 sender or receiver. Another vulnerability of using PR-SCTP with DTLS 2309 is that someone could inject SCTP control information to shut down 2310 the SCTP association, effectively generating a loss of IPFIX Messages 2311 if those are buffered outside of the SCTP association. Techniques 2312 such as [RFC6083] could be used to overcome these vulnerabilities. 2314 When using DTLS over SCTP, the Exporting Process MUST ensure that 2315 each IPFIX Message is sent over the same SCTP stream that would be 2316 used when sending the same IPFIX Message directly over SCTP. Note 2317 that DTLS may send its own control messages on stream 0 with full 2318 reliability; however, this will not interfere with the processing of 2319 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2320 consumes its own control messages before passing IPFIX Messages up to 2321 the application layer. 2323 11.2. Usage 2325 The IPFIX Exporting Process initiates the communication to the IPFIX 2326 Collecting Process, and acts as a TLS or DTLS client according to 2327 [RFC5246] and [RFC4347], while the IPFIX Collecting Process acts as a 2328 TLS or DTLS server. The DTLS client opens a secure connection on the 2329 SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as 2330 the transport protocol. The TLS client opens a secure connection on 2331 the TCP port 4740 of the TLS server if TCP is selected as the 2332 transport protocol. The DTLS client opens a secure connection on the 2333 UDP port 4740 of the DTLS server if UDP is selected as the transport 2334 protocol. 2336 11.3. Authentication 2338 IPFIX Exporting Processes and IPFIX Collecting Processes are 2339 identified by the fully qualified domain name of the interface on 2340 which IPFIX Messages are sent or received, for purposes of X.509 2341 client and server certificates as in [RFC5280]. 2343 To prevent man-in-the-middle attacks from impostor Exporting or 2344 Collecting Processes, the acceptance of data from an unauthorized 2345 Exporting Process, or the export of data to an unauthorized 2346 Collecting Process, strong mutual authentication via asymmetric keys 2347 MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and 2348 Collecting Processes MUST verify the identity of its peer against its 2349 authorized certificates, and MUST verify that the peer's certificate 2350 matches its fully qualified domain name, or, in the case of SCTP, the 2351 fully qualified domain name of one of its endpoints. 2353 The fully qualified domain name used to identify an IPFIX Collecting 2354 Process or Exporting Process may be stored either in a subjectAltName 2355 extension of type dNSName, or in the most specific Common Name field 2356 of the Subject field of the X.509 certificate. If both are present, 2357 the subjectAltName extension is given preference. 2359 Internationalized domain names (IDN) in either the subjectAltName 2360 extension of type dNSName or the most specific Common Name field of 2361 the Subject field of the X.509 certificate MUST be encoded using 2362 Punycode [RFC3492] as described in [RFC5891], "Conversion 2363 Operations". 2365 11.4. Protection against DoS Attacks 2367 An attacker may mount a denial-of-service (DoS) attack against an 2368 IPFIX collection system either directly, by sending large amounts of 2369 traffic to a Collecting Process, or indirectly, by generating large 2370 amounts of traffic to be measured by a Metering Process. 2372 Direct denial-of-service attacks can also involve state exhaustion, 2373 whether at the transport layer (e.g., by creating a large number of 2374 pending connections), or within the IPFIX Collecting Process itself 2375 (e.g., by sending Flow Records pending Template or scope information, 2376 a large amount of Options Template Records, etc.). 2378 SCTP mandates a cookie-exchange mechanism designed to defend against 2379 SCTP state exhaustion denial-of-service attacks. Similarly, TCP 2380 provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN 2381 cookies SHOULD be used by any Collecting Process accepting TCP 2382 connections. DTLS also provides cookie exchange to protect against 2383 DTLS server state exhaustion. 2385 The reader should note that there is no way to prevent fake IPFIX 2386 Message processing (and state creation) for UDP & SCTP communication. 2387 The use of TLS and DTLS can obviously prevent the creation of fake 2388 states, but they are themselves prone to state exhaustion attacks. 2389 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2390 DTLS (like limiting the number of new TLS or DTLS session per second 2391 to a sensible number). 2393 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2394 at which new connections or associations will be opened by the 2395 Collecting Process, the rate at which IPFIX Messages will be accepted 2396 by the Collecting Process, and adaptively limiting the amount of 2397 state kept, particularly records waiting on Templates. These rate 2398 and state limits MAY be provided by a Collecting Process; if 2399 provided, the limits SHOULD be user configurable. 2401 Additionally, an IPFIX Collecting Process can eliminate the risk of 2402 state exhaustion attacks from untrusted nodes by requiring TLS or 2403 DTLS mutual authentication, causing the Collecting Process to accept 2404 IPFIX Messages only from trusted sources. 2406 With respect to indirect denial of service, the behavior of IPFIX 2407 under overload conditions depends on the transport protocol in use. 2408 For IPFIX over TCP, TCP congestion control would cause the flow of 2409 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2410 system. PR-SCTP improves upon this situation somewhat, as some IPFIX 2411 Messages would continue to be received by the Collecting Process due 2412 to the avoidance of head-of-line blocking by SCTP's multiple streams 2413 and partial reliability features, possibly affording some visibility 2414 of the attack. The situation is similar with UDP, as some datagrams 2415 may continue to be received at the Collecting Process, effectively 2416 applying sampling to the IPFIX Message stream, implying that some 2417 forensics may be left. 2419 To minimize IPFIX Message loss under overload conditions, some 2420 mechanism for service differentiation could be used to prioritize 2421 IPFIX traffic over other traffic on the same link. Alternatively, 2422 IPFIX Messages can be transported over a dedicated network. In this 2423 case, care must be taken to ensure that the dedicated network can 2424 handle the expected peak IPFIX Message traffic. 2426 11.5. When DTLS or TLS Is Not an Option 2428 The use of DTLS or TLS might not be possible in some cases due to 2429 performance issues or other operational concerns. 2431 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2432 and Collecting Processes can fall back on using IP source addresses 2433 to authenticate their peers. A policy of allocating Exporting 2434 Process and Collecting Process IP addresses from specified address 2435 ranges, and using ingress filtering to prevent spoofing, can improve 2436 the usefulness of this approach. Again, completely segregating IPFIX 2437 traffic on a dedicated network, where possible, can improve security 2438 even further. In any case, the use of open Collecting Processes 2439 (those that will accept IPFIX Messages from any Exporting Process 2440 regardless of IP address or identity) is discouraged. 2442 Modern TCP and SCTP implementations are resistant to blind insertion 2443 attacks (see [RFC1948], [RFC4960]); however, UDP offers no such 2444 protection. For this reason, IPFIX Message traffic transported via 2445 UDP and not secured via DTLS SHOULD be protected via segregation to a 2446 dedicated network. 2448 11.6. Logging an IPFIX Attack 2450 IPFIX Collecting Processes MUST detect potential IPFIX Message 2451 insertion or loss conditions by tracking the IPFIX Sequence Number, 2452 and SHOULD provide a logging mechanism for reporting out-of-sequence 2453 messages. Note that an attacker may be able to exploit the handling 2454 of out-of-sequence messages at the Collecting Process, so care should 2455 be taken in handling these conditions. For example, a Collecting 2456 Process that simply resets the expected Sequence Number upon receipt 2457 of a later Sequence Number could be temporarily blinded by deliberate 2458 injection of later Sequence Numbers. 2460 IPFIX Exporting and Collecting Processes SHOULD log any connection 2461 attempt that fails due to authentication failure, whether due to 2462 being presented an unauthorized or mismatched certificate during TLS 2463 or DTLS mutual authentication, or due to a connection attempt from an 2464 unauthorized IP address when TLS or DTLS is not in use. 2466 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2467 SCTP association reset or TCP connection reset. 2469 11.7. Securing the Collector 2471 The security of the Collector and its implementation is important to 2472 achieve overall security. However, it is outside the scope of this 2473 document. 2475 12. IANA Considerations 2477 IPFIX Messages use two fields with assigned values. These are the 2478 IPFIX Version Number, indicating which version of the IPFIX Protocol 2479 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2480 the type for each set of information within an IPFIX Message. 2482 The IPFIX Version Number value of 10 is reserved for the IPFIX 2483 protocol specified in this document. Set ID values of 0 and 1 are 2484 not used for historical reasons [RFC3954]. The Set ID value of 2 is 2485 reserved for the Template Set. The Set ID value of 3 is reserved for 2486 the Options Template Set. All other Set ID values from 4 to 255 are 2487 reserved for future use. Set ID values above 255 are used for Data 2488 Sets. 2490 New assignments in either IPFIX Version Number or IPFIX Set ID 2491 assignments require a Standards Action [RFC5226], i.e., they are to 2492 be made via Standards Track RFCs approved by the IESG. 2494 Appendix A. IPFIX Encoding Examples 2496 This appendix, which is a not a normative reference, contains IPFIX 2497 encoding examples. 2499 Let's consider the example of an IPFIX Message composed of a 2500 Template Set, a Data Set (which contains three Data Records), an 2501 Options Template Set and a Data Set (which contains 2 Data Records 2502 related to the previous Options Template Record). 2504 IPFIX Message: 2506 +--------+------------------------------------------. . . 2507 | | +--------------+ +------------------+ 2508 |Message | | Template | | Data | 2509 | Header | | Set | | Set | . . . 2510 | | | (1 Template) | | (3 Data Records) | 2511 | | +--------------+ +------------------+ 2512 +--------+------------------------------------------. . . 2514 . . .-------------------------------------------+ 2515 +------------------+ +------------------+ | 2516 | Options | | Data | | 2517 . . . | Template Set | | Set | | 2518 | (1 Template) | | (2 Data Records) | | 2519 +------------------+ +------------------+ | 2520 . . .-------------------------------------------+ 2522 A.1. Message Header Example 2524 The Message Header is composed of: 2525 0 1 2 3 2526 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 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Version = 0x000a | Length = 152 | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Export Time | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Sequence Number | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | Observation Domain ID | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 A.2. Template Set Examples 2539 A.2.1. Template Set Using IETF-Specified Information Elements 2541 We want to report the following Information Elements: 2543 - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], 2544 with a length of 4 octets 2546 - The IPv4 destination IP address: destinationIPv4Address in 2547 [RFC5102bis], with a length of 4 octets 2549 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2550 [RFC5102bis], with a length of 4 octets 2552 - The number of packets of the Flow: packetDeltaCount in 2553 [RFC5102bis], with a length of 4 octets 2555 - The number of octets of the Flow: octetDeltaCount in 2556 [RFC5102bis], with a length of 4 octets 2558 Therefore, the Template Set will be composed of the following: 2560 0 1 2 3 2561 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 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | Set ID = 2 | Length = 28 octets | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | Template ID 256 | Field Count = 5 | 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 |0| sourceIPv4Address = 8 | Field Length = 4 | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 |0| destinationIPv4Address = 12 | Field Length = 4 | 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 |0| packetDeltaCount = 2 | Field Length = 4 | 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 |0| octetDeltaCount = 1 | Field Length = 4 | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 A.2.2. Template Set Using Enterprise-Specific Information Elements 2580 We want to report the following Information Elements: 2582 - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with 2583 a length of 4 octets 2585 - The IPv4 destination IP address: destinationIPv4Address in 2586 [RFC5102bis], with a length of 4 octets 2588 - An enterprise-specific Information Element representing 2589 proprietary information, with a type of 15 and a length of 4 2591 - The number of packets of the Flow: packetDeltaCount in 2592 [RFC5102bis], with a length of 4 octets 2594 - The number of octets of the Flow: octetDeltaCount in [RFC5102bis], 2595 with a length of 4 octets 2597 Therefore, the Template Set will be composed of the following: 2599 0 1 2 3 2600 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 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 | Set ID = 2 | Length = 32 octets | 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | Template ID 257 | Field Count = 5 | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 |0| sourceIPv4Address = 8 | Field Length = 4 | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 |0| destinationIPv4Address = 12 | Field Length = 4 | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 |1| Information Element Id. = 15| Field Length = 4 | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Enterprise number | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 |0| packetDeltaCount = 2 | Field Length = 4 | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 |0| octetDeltaCount = 1 | Field Length = 4 | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 A.3. Data Set Example 2621 In this example, we report the following three Flow Records: 2623 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2624 | | | Number | Number 2625 ------------------------------------------------------------------ 2626 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2627 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2628 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2630 0 1 2 3 2631 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 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Set ID = 256 | Length = 64 | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | 192.0.2.12 | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | 192.0.2.254 | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | 192.0.2.1 | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | 5009 | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | 5344385 | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | 192.0.2.27 | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | 192.0.2.23 | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | 192.0.2.2 | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | 748 | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | 388934 | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | 192.0.2.56 | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | 192.0.2.65 | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | 192.0.2.3 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | 5 | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 | 6534 | 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 Note that padding is not necessary in this example. 2668 A.4. Options Template Set Examples 2670 A.4.1. Options Template Set Using IETF-Specified Information Elements 2672 Per line card (the router being composed of two line cards), we want 2673 to report the following Information Elements: 2675 - Total number of IPFIX Messages: exportedMessageTotalCount 2676 [RFC5102bis], with a length of 2 octets 2678 - Total number of exported Flows: exportedFlowRecordTotalCount 2679 [RFC5102bis], with a length of 2 octets 2681 The line card, which is represented by the lineCardId Information 2682 Element [RFC5102bis], is used as the Scope Field. 2684 Therefore, the Options Template Set will be: 2686 0 1 2 3 2687 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 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | Set ID = 3 | Length = 24 | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 | Template ID 258 | Field Count = 3 | 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Scope Field Count = 1 |0| lineCardId = 141 | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | Field Length = 2 | Padding | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 A.4.2. Options Template Set Using Enterprise-Specific Information 2703 Elements 2705 Per line card (the router being composed of two line cards), we want 2706 to report the following Information Elements: 2708 - Total number of IPFIX Messages: exportedMessageTotalCount 2709 [RFC5102bis], with a length of 2 octets 2711 - An enterprise-specific number of exported Flows, with a type of 2712 42 and a length of 4 octets 2714 The line card, which is represented by the lineCardId Information 2715 Element [RFC5102bis], is used as the Scope Field. 2717 The format of the Options Template Set is as follows: 2719 0 1 2 3 2720 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 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | Set ID = 3 | Length = 28 | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | Template ID 259 | Field Count = 3 | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Scope Field Count = 1 |0| lineCardId = 141 | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | Field Length = 2 |1|Information Element Id. = 42 | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Field Length = 4 | Enterprise number ... 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 ... Enterprise number | Padding | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2739 In this example, we want to export the same information as in the 2740 example in Section A.4.1: 2742 - Total number of IPFIX Messages: exportedMessageTotalCount 2743 [RFC5102bis], with a length of 2 octets 2745 - Total number of exported Flows: exportedFlowRecordTotalCount 2746 [RFC5102bis], with a length of 2 octets 2748 But this time, the information pertains to a proprietary scope, 2749 identified by enterprise-specific Information Element number 123. 2751 The format of the Options Template Set is now as follows: 2753 0 1 2 3 2754 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 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | Set ID = 3 | Length = 28 | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | Template ID 260 | Field Count = 3 | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | Scope 1 Field Length = 4 | Enterprise Number ... 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Field Length = 2 | Padding | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 A.4.4. Data Set Using an Enterprise-Specific Scope 2773 In this example, we report the following two Data Records: 2775 Enterprise field 123 | IPFIX Message | Exported Flow Records 2776 ------------------------------------------------------------------- 2777 1 | 345 | 10201 2778 2 | 690 | 20402 2780 0 1 2 3 2781 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 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Set ID = 260 | Length = 20 | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | 1 | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | 345 | 10201 | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | 2 | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | 690 | 20402 | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 A.5. Variable-Length Information Element Examples 2796 A.5.1. Example of Variable-Length Information Element with Length 2797 Inferior to 255 Octets 2799 0 1 2 3 2800 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 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 | 5 | 5 octet Information Element | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 A.5.2. Example of Variable-Length Information Element with 3 Octet 2808 Length Encoding 2810 0 1 2 3 2811 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 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 | 255 | 1000 | IE ... | 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | 1000 octet Information Element | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 : ... : 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 | ... IE | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 References 2824 Normative References 2826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2827 Requirement Levels", BCP 14, RFC 2119, March 1997. 2829 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, 2830 "Transport Layer Security over Stream Control 2831 Transmission Protocol", RFC 3436, December 2002. 2833 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of 2834 Unicode for Internationalized Domain Names in 2835 Applications (IDNA)", RFC 3492, March 2003. 2837 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2838 Conrad, "Stream Control Transmission Protocol (SCTP) 2839 Partial Reliability Extension", RFC 3758, May 2004. 2841 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport 2842 Layer Security", RFC 4347, April 2006. 2844 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 2845 Protocol", RFC 4960, September 2007. 2847 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2848 an IANA Considerations Section in RFCs", BCP 26, RFC 2849 5226, May 2008. 2851 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2852 Security (TLS) Protocol Version 1.2", RFC 5246, 2853 August 2008. 2855 [RFC5280] Cooper, D., Santesson, S., Farrell, S. Boeyen, S. 2856 Housley, R., and W. Polk, "Internet X.509 Public Key 2857 Infrastructure Certificate and Certificate Revocation 2858 List (CRL) Profile", RFC 5280, April 2008. 2860 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 2861 W. Kasch, "Network Time Protocol Version 4: Protocol 2862 and Algorithms Specification", RFC 5905, June 2010 2864 [RFC5891] J. Klensin, "Internationalized Domain Names in 2865 Applications (IDNA): Protocol", RFC 5891, August 2866 2010. 2868 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2869 RFC 793, September 1981. 2871 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2872 August 1980. 2874 [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and 2875 J. Meyer, "Information Model for IP Flow Information 2876 Export", draft-claise-ipfix-information-model- 2877 rfc5102bis-00.txt, Work in Progress, July 2011. 2879 Informative References 2881 [PEN] IANA Private Enterprise Numbers registry 2882 http://www.iana.org/assignments/enterprise-numbers. 2884 [RFC1948] Bellovin, S., "Defending Against Sequence Number 2885 Attacks", RFC 1948, May 1996. 2887 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2888 "Textual Conventions for SMIv2", STD 58, RFC 2579, 2889 April 1999. 2891 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2892 Jacobson, "RTP: A Transport Protocol for Real-Time 2893 Applications", STD 64, RFC 3550, July 2003. 2895 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2896 "Requirements for IP Flow Information Export 2897 (IPFIX)", RFC 3917, October 2004. 2899 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 2900 Export Version 9", RFC 3954, October 2004. 2902 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 2903 Export Using IP Flow Information Export (IPFIX)", RFC 2904 5103, January 2008. 2906 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 2907 Flow Information Export (IPFIX) Implementation 2908 Guidelines", RFC5153, April 2008 2910 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 2911 "Architecture for IP Flow Information Export", 2912 RFC5470, March 2009. 2914 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 2915 "IP Flow Information Export (IPFIX) Applicability", 2916 RFC5472, March 2009. 2918 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 2919 for IP Flow Information Export (IPFIX) Testing", 2920 RFC5471, March 2009 2922 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2923 Redundancy in IP Flow Information Export (IPFIX) and 2924 Packet Sampling (PSAMP) Reports", RFC5473, March 2009 2926 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2927 "Exporting Type Information for IP Flow Information 2928 Export (IPFIX) Information Elements", July 2009. 2930 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 2931 Transport Layer Security (DTLS) for Stream Control 2932 Transmission Protocol (SCTP)", RFC6083, January 2011. 2934 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 2935 "Export of Structured Data in IP Flow Information 2936 Export (IPFIX)", RFC6313, July 2011. 2938 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 2939 "IP Flow Information Export (IPFIX) Mediation: 2940 Framework", RFC6183, April 2011. 2942 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 2943 "Standard for Binary Floating-Point Arithmetic", IEEE 2944 Standard 754, August 1985. 2946 [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken, "Configuration 2947 Data Model for IPFIX and PSAMP", draft-ietf-ipfix- 2948 configuration-model-10, Work in Progress, July 2011. 2950 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 2951 "Specification of the Protocol for IPFIX Mediations", 2952 draft-claise-ipfix-mediation-protocol-04, Work in 2953 Progress, July 2011. 2955 [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 2956 "Definitions of Managed Objects for IP Flow 2957 Information Export", draft-dkcm-ipfix-rfc5815bis- 2958 00.txt, Work in Progress, October 2011. 2960 Acknowledgments 2962 We would like to thank the following persons: Ganesh Sadasivan for 2963 his significant contribution during the initial phases of the 2964 protocol specification; Juergen Quittek for the coordination job 2965 within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and 2966 Andrew Johnson for the thorough reviews; Randall Stewart and Peter 2967 Lei for their SCTP expertise and contributions; Martin Djernaes for 2968 the first essay on the SCTP section; Michael Behringer and Eric 2969 Vyncke for their advice and knowledge in security; Michael Tuexen for 2970 his help regarding the DTLS section; Elisa Boschi for her 2971 contribution regarding the improvement of SCTP sections; Mark 2972 Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter 2973 Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul 2974 Calato, and many more, for the technical reviews and feedback. 2976 Authors' Addresses 2978 Benoit Claise 2979 Cisco Systems 2980 De Kleetlaan 6a b1 2981 1831 Diegem 2982 Belgium 2983 Phone: +32 2 704 5622 2984 EMail: bclaise@cisco.com 2986 Stewart Bryant 2987 Cisco Systems, Inc. 2988 250, Longwater, 2989 Green Park, 2990 Reading, RG2 6GB, 2991 United Kingdom 2992 Phone: +44 (0)20 8824-8828 2993 EMail: stbryant@cisco.com 2995 Simon Leinen 2996 SWITCH 2997 Werdstrasse 2 2998 P.O. Box 2999 CH-8021 Zurich 3000 Switzerland 3001 Phone: +41 44 268 1536 3002 EMail: simon.leinen@switch.ch 3004 Thomas Dietz 3005 NEC Europe Ltd. 3006 NEC Laboratories Europe 3007 Network Research Division 3008 Kurfuersten-Anlage 36 3009 69115 Heidelberg 3010 Germany 3011 Phone: +49 6221 4342-128 3012 EMail: Thomas.Dietz@nw.neclab.eu 3014 Brian Trammell 3015 Swiss Federal Institute of Technology Zurich 3016 Gloriastrasse 35 3017 Zurich 3018 Switzerland 3019 Phone: +41 44 632 70 13 3020 EMail: trammell@tik.ee.ethz.ch