idnits 2.17.1 draft-ietf-ipfix-protocol-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2858. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If UDP is selected as the transport protocol, the Template Withdraw Messages MUST not be used, as this method is inefficient due to the unreliable nature of UDP. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2007) is 6061 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 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPFIX working group 2 Internet Draft EDITOR: B. Claise 3 draft-ietf-ipfix-protocol-26.txt Cisco Systems, Inc. 4 Intended Status: Proposed Standard September 2007 5 Expires: March 3rd, 2008 7 Specification of the IPFIX Protocol for the Exchange 8 of IP Traffic Flow Information 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or 15 she becomes aware will be disclosed, in accordance with Section 16 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use 26 Internet-Drafts as reference material or to cite them other 27 than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed 33 at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 3rd, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies the IPFIX protocol that serves for 45 transmitting IP traffic flow information over the network. In order 46 to transmit IP traffic flow information from an exporting process to 47 an information collecting process, a common representation of flow 48 data and a standard means of communicating them is required. This 49 document describes how the IPFIX data and templates records are 50 carried over a number of transport protocols from an IPFIX exporting 51 process to an IPFIX collecting process. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 61 1. Introduction...................................................4 62 1.1 IPFIX Documents Overview.....................................5 63 2. Terminology....................................................5 64 2.1 Terminology Summary Table...................................10 65 3. IPFIX Message Format..........................................11 66 3.1 Message Header Format.......................................12 67 3.2 Field Specifier Format......................................14 68 3.3 Set and Set Header Format...................................15 69 3.3.1 Set Format...............................................15 70 3.3.2 Set Header Format........................................16 71 3.4 Record Format...............................................17 72 3.4.1 Template Record Format...................................17 73 3.4.2 Options Template Record Format...........................19 74 3.4.2.1 Scope...................................................19 75 3.4.2.2 Options Template Record Format..........................20 76 3.4.3 Data Record Format.......................................22 77 4. Specific Reporting Requirements...............................24 78 4.1 The Metering Process Statistics Option Template.............24 79 4.2 The Metering Process Reliability Statistics Option Template.25 80 4.3 The Exporting Process Reliability Statistics Option Template26 81 4.4 The Flow Keys Option Template...............................27 82 5. IPFIX Message Header "Export Time" and Flow Record Time.......28 83 6. Linkage with the Information Model............................28 84 6.1 Encoding of IPFIX Data Types................................29 85 6.1.1 Integral Data Types......................................29 86 6.1.2 Address Types............................................29 87 6.1.3 float32..................................................29 88 6.1.4 float64..................................................29 89 6.1.5 boolean..................................................29 90 6.1.6 string and octetarray....................................29 91 6.1.7 dateTimeSeconds..........................................30 92 6.1.8 dateTimeMilliseconds.....................................30 93 6.1.9 dateTimeMicroseconds.....................................30 94 6.1.10 dateTimeNanoseconds......................................30 95 6.2 Reduced Size Encoding of Integer and Float Types............30 96 7. Variable Length Information Element...........................31 97 8. Template Management...........................................32 98 9. The Collecting Process's Side.................................35 99 10. Transport Protocol...........................................37 100 10.1 Transport Compliance and Transport Usage...................37 101 10.2 SCTP.......................................................38 102 10.2.1 Congestion Avoidance.....................................38 103 10.2.2 Reliability..............................................39 104 10.2.3 MTU......................................................39 105 10.2.4 Exporting Process........................................39 106 10.2.4.1 Association Establishment...............................39 107 10.2.4.2 Association Shutdown....................................40 108 10.2.4.3 Stream..................................................40 109 10.2.4.4 Template Management.....................................40 110 10.2.5 Collecting Process.......................................41 111 10.2.6 Failover.................................................41 112 10.3 UDP........................................................41 113 10.3.1 Congestion Avoidance.....................................41 114 10.3.2 Reliability..............................................41 115 10.3.3 MTU......................................................42 116 10.3.4 Port Numbers.............................................42 117 10.3.5 Exporting Process........................................42 118 10.3.6 Template Management......................................42 119 10.3.7 Collecting Process.......................................43 120 10.3.8 Failover.................................................44 121 10.4 TCP........................................................44 122 10.4.1 Connection Management....................................44 123 10.4.1.1 Connection Establishment................................44 124 10.4.1.2 Graceful Connection Release.............................44 125 10.4.1.3 Restarting Interrupted Connections......................45 126 10.4.1.4 Failover................................................45 127 10.4.2 Data Transmission........................................45 128 10.4.2.1 IPFIX Message Encoding..................................45 129 10.4.2.2 Template Management.....................................46 130 10.4.2.3 Congestion Handling and Reliability.....................46 131 10.4.3 Collecting Process.......................................47 132 11. Security Considerations......................................48 133 11.1 Applicability of TLS and DTLS..............................49 134 11.2 Usage......................................................50 135 11.3 Authentication.............................................50 136 11.4 Protection against DoS attacks.............................51 137 11.5 When DTLS or TLS is not an option..........................52 138 11.6 Logging an IPFIX Attack....................................52 139 11.7 Securing the Collector.....................................53 140 12. IANA Considerations..........................................53 141 13. Appendix A...................................................53 142 13.1 Message Header Example.....................................54 143 13.2 Template Set Examples......................................54 144 13.2.1 Template Set using IETF specified Information Elements...54 145 13.2.2 Template Set using enterprise-specific Information 146 Elements.........................................................55 147 13.3 Data Set Example...........................................56 148 13.4 Options Template Set Examples..............................57 149 13.4.1 Options Template Set using IETF specified Information 150 Elements.........................................................57 151 13.4.2 Options Template Set using enterprise-specific 152 Information Elements.............................................58 153 13.4.3 Options Template Set using an enterprise-specific scope..59 154 13.4.4 Data Set using an enterprise-specific scope..............60 155 13.5 Variable length Information Element examples...............60 156 13.5.1 Example of Variable Length Information Element with 157 Length inferior to 255 octets....................................60 158 13.5.2 Example of Variable Length Information Element with 159 Length 255 to 65535 octets.......................................61 160 14. References...................................................61 161 14.1 Normative References.......................................61 162 14.2 Informative References.....................................62 163 15. Acknowledgments..............................................63 164 16. Intellectual Property Statement..............................64 165 17. Copyright Statement..........................................65 166 18. Disclaimer...................................................65 168 Changes compared to version 24: 169 EDITOR'S NOTE: this section must be removed by the RFC-editor 171 - 172 Remove the SCTP stream 0 restriction (transmission 173 of Templates over SCTP stream zero with reliable delivery 174 and the transmission of Data Records over separate streams) 175 - 176 Padding. 177 http://www3.ietf.org/proceedings/07jul/slides/ipfix-13.pdf 178 - 179 Previous version of the draft didn't specifiy very clearly 180 what to do for the TCP transport if a Template ID is reused within 181 the template expiry time. The section 10.4.3 has been added 182 - 183 Included the consensus from 184 http://www1.ietf.org/mail-archive/web/ipfix/current/msg03928.html 185 - 186 Small editorial changes 188 1. Introduction 190 A data network with IP traffic, primarily consists of IP Flows 191 passing through the network elements of the network. It is often 192 interesting, useful or even a requirement to have access to 193 information about these flows that pass through the network elements 194 for administrative or other purposes. The IPFIX collecting process 195 should be able to receive the flow information passing through 196 multiple network elements within the data network. This requires 198 uniformity in the method of representing the flow information and 199 the means of communicating the flows from the network elements to 200 the collection point. This document specifies the protocol to 201 achieve these aforementioned requirements. This document specifies 202 in detail the representation of different flows, the additional data 203 required for flow interpretation, packet format, transport 204 mechanisms used, security concerns, etc. 206 1.1 IPFIX Documents Overview 208 The IPFIX protocol provides network administrators with access to IP 209 flow information. The architecture for the export of measured IP 210 flow information out of an IPFIX exporting process to a collecting 211 process is defined in [IPFIX-ARCH], per the requirements defined in 212 [RFC3917]. This document specifies how IPFIX data records and 213 templates are carried via a number of transport protocols from IPFIX 214 exporting processes to IPFIX collecting process. IPFIX has a formal 215 description of IPFIX information elements, their name, type and 216 additional semantic information, as specified in [IPFIX-INFO]. 217 Finally [IPFIX-AS] describes what type of applications can use the 218 IPFIX protocol and how they can use the information provided. It 219 furthermore shows how the IPFIX framework relates to other 220 architectures and frameworks. 222 2. Terminology 224 The definitions of the basic terms like IP Traffic Flow, Exporting 225 Process, Collecting Process, Observation Points, etc. are 226 semantically identical with those found in the IPFIX requirements 227 document [RFC3917]. Some of the terms have been expanded for more 228 clarity when defining the protocol. Additional terms required for 229 the protocol has also been defined. Definitions in this document 230 and in [IPFIX-ARCH] are equivalent, except that definitions which 231 are only relevant to the IPFIX protocol only appear here. 233 The terminology summary table in Section 2.1 gives a quick overview 234 of the relationships between some of the different terms defined. 236 Observation Point 238 An Observation Point is a location in the network where IP packets 239 can be observed. Examples include: a line to which a probe is 240 attached, a shared medium, such as an Ethernet-based LAN, a single 241 port of a router, or a set of interfaces (physical or logical) of a 242 router. 244 Note that every Observation Point is associated with an Observation 245 Domain (defined below), and that one Observation Point may be a 246 superset of several other Observation Points. For example one 247 Observation Point can be an entire line card. That would be the 248 superset of the individual Observation Points at the line card's 249 interfaces. 251 Observation Domain 253 An Observation Domain is the largest set of Observation Points for 254 which Flow information can be aggregated by a Metering Process. For 255 example, a router line card may be an Observation Domain if it is 256 composed of several interfaces, each of which is an Observation 257 Point. In the IPFIX Message it generates, the Observation Domain 258 includes its Observation Domain ID, which is unique per Exporting 259 Process. That way, the Collecting Process can identify the specific 260 Observation Domain from the Exporter that sends the IPFIX Messages. 261 Every Observation Point is associated with an Observation Domain. . 262 It is RECOMMENDED that Observation Domain IDs are also unique per 263 IPFIX Device. 265 IP Traffic Flow or Flow 267 There are several definitions of the term 'flow' being used by the 268 Internet community. Within the context of IPFIX we use the 269 following definition: 271 A Flow is defined as a set of IP packets passing an Observation 272 Point in the network during a certain time interval. All packets 273 belonging to a particular Flow have a set of common properties. 274 Each property is defined as the result of applying a function to the 275 values of: 277 1. one or more packet header fields (e.g. destination IP 278 address), transport header fields (e.g. destination port number), 279 or application header fields (e.g. RTP header fields [RFC3550]) 281 2. one or more characteristics of the packet itself (e.g. number 282 of MPLS labels, etc...) 284 3. one or more of fields derived from packet treatment (e.g. next 285 hop IP address, the output interface, etc...) 287 A packet is defined to belong to a Flow if it completely satisfies 288 all the defined properties of the Flow. 290 This definition covers the range from a Flow containing all packets 291 observed at a network interface to a Flow consisting of just a 292 single packet between two applications. It includes packets 293 selected by a sampling mechanism. 295 Flow Key 297 Each of the fields which 299 1. Belong to the packet header (e.g. destination IP address) 301 2. Are a property of the packet itself (e.g. packet length) 303 3. Are derived from packet treatment (e.g. AS number) 305 and which are used to define a Flow are termed Flow Keys. 307 Flow Record 309 A Flow Record contains information about a specific Flow that was 310 observed at an Observation Point. A Flow Record contains measured 311 properties of the Flow (e.g. the total number of bytes for all the 312 Flow's packets) and usually characteristic properties of the Flow 313 (e.g. source IP address). 315 Metering Process 317 The Metering Process generates Flow Records. Inputs to the process 318 are packet headers and characteristics observed at an Observation 319 Point, and packet treatment at the Observation Point (for example 320 the selected output interface). 322 The Metering Process consists of a set of functions that includes 323 packet header capturing, timestamping, sampling, classifying, and 324 maintaining Flow Records. 326 The maintenance of Flow Records may include creating new records, 327 updating existing ones, computing Flow statistics, deriving further 328 Flow properties, detecting Flow expiration, passing Flow Records to 329 the Exporting Process, and deleting Flow Records. 331 Exporting Process 332 The Exporting Process sends Flow Records to one or more Collecting 333 Processes. The Flow Records are generated by one or more Metering 334 Processes. 336 Exporter 338 A device which hosts one or more Exporting Processes is termed an 339 Exporter. 341 IPFIX Device 343 An IPFIX Device hosts at least one Exporting Process. It may host 344 further Exporting processes and arbitrary numbers of Observation 345 Points and Metering Process. 347 Collecting Process 349 A Collecting Process receives Flow Records from one or more 350 Exporting Processes. The Collecting Process might process or store 351 received Flow Records, but such actions are out of scope for this 352 document. 354 Collector 356 A device which hosts one or more Collecting Processes is termed a 357 Collector. 359 Template 361 Template is a ordered sequence of pairs, used to 362 completely specify the structure and semantics of a particular set 363 of information that needs to be communicated from an IPFIX Device to 364 a Collector. Each Template is uniquely identifiable by means of a 365 Template ID. 367 IPFIX Message 369 An IPFIX Message is a message originating at the Exporting Process 370 that carries the IPFIX records of this Exporting Process and whose 371 destination is a Collecting Process. An IPFIX Message is 372 encapsulated at the transport layer. 374 Message Header 375 The Message Header is the first part of an IPFIX Message, which 376 provides basic information about the message such as the IPFIX 377 version, length of the message, message sequence number, etc. 379 Template Record 381 A Template Record defines the structure and interpretation of fields 382 in a Data Record. 384 Data Record 386 A Data Record is a record that contains values of the parameters 387 corresponding to a Template Record. 389 Options Template Record 391 An Options Template Record is a Template Record that defines the 392 structure and interpretation of fields in a Data Record, including 393 defining how to scope the applicability of the Data Record. 395 Set 397 Set is a generic term for a collection of records that have a 398 similar structure. In an IPFIX Message, one or more Sets follow the 399 Message Header. 401 There are three different types of Sets: Template Set, Options 402 Template Set, and Data Set. 404 Template Set 406 A Template Set is a collection of one or more Template Records that 407 have been grouped together in an IPFIX Message. 409 Options Template Set 411 An Options Template Set is a collection of one or more Options 412 Template Records that have been grouped together in an IPFIX 413 Message. 415 Data Set 417 A Data Set is one or more Data Records, of the same type, that are 418 grouped together in an IPFIX Message. Each Data Record is 419 previously defined by a Template Record or an Options Template 420 Record. 422 Information Element 424 An Information Element is a protocol and encoding independent 425 description of an attribute which may appear in an IPFIX Record. 426 The IPFIX information model [IPFIX-INFO] defines the base set of 427 Information Elements for IPFIX. The type associated with an 428 Information Element indicates constraints on what it may contain and 429 also determines the valid encoding mechanisms for use in IPFIX. 431 Transport Session 433 In SCTP, the transport session is known as the SCTP association, 434 which is uniquely identified by the SCTP endpoints [RFC2960]; in TCP, 435 the transport session is known as the TCP connection, which is 436 uniquely identified by the combination of IP addresses and TCP ports 437 used; In UDP, the transport session is known as the UDP session, 438 which is uniquely identified by the combination of IP addresses and 439 UDP ports used. 441 2.1 Terminology Summary Table 443 +------------------+---------------------------------------------+ 444 | | contents | 445 | +--------------------+------------------------+ 446 | Set | Template | record | 447 +------------------+--------------------+------------------------+ 448 | Data Set | / | Data Record(s) | 449 +------------------+--------------------+------------------------+ 450 | Template Set | Template Record(s) | / | 451 +------------------+--------------------+------------------------+ 452 | Options Template | Options Template | / | 453 | Set | Record(s) | | 454 +------------------+--------------------+------------------------+ 456 Figure A: Terminology Summary Table 458 A Data Set is composed of Data Record(s). No Template Record is 459 included. A Template Record or an Options Template Record defines 460 the Data Record. 462 A Template Set contains only Template Record(s). 464 An Options Template Set contains only Options Template Record(s). 466 3. IPFIX Message Format 468 An IPFIX Message consists of a Message Header followed by one or 469 more Sets. The Sets can be any of the possible three types: Data 470 Set, Template Set or Options Template Set. 472 The format of the IPFIX Message is shown in Figure B. 474 +----------------------------------------------------+ 475 | Message Header | 476 +----------------------------------------------------+ 477 | Set | 478 +----------------------------------------------------+ 479 | Set | 480 +----------------------------------------------------+ 481 ... 482 +----------------------------------------------------+ 483 | Set | 484 +----------------------------------------------------+ 486 Figure B: IPFIX Message format 488 The Exporter MUST code all binary integers of the Message Header and 489 the different Sets in network byte order (also known as the big- 490 endian byte ordering). 492 Following are some examples of IPFIX Messages: 494 1. An IPFIX Message consisting of interleaved Template, Data, and 495 Options Template Sets - A newly created Template is exported as soon 496 as possible. So if there is already an IPFIX Message with a Data 497 Set that is being prepared for export, the Template and Option 498 Template Sets are interleaved with this information, subject to 499 availability of space. 501 +--------+--------------------------------------------------------+ 502 | | +----------+ +---------+ +-----------+ +---------+ | 503 |Message | | Template | | Data | | Options | | Data | | 504 | Header | | Set | | Set | ... | Template | | Set | | 505 | | | | | | | Set | | | | 506 | | +----------+ +---------+ +-----------+ +---------+ | 507 +--------+--------------------------------------------------------+ 509 Figure C: IPFIX Message example 1 511 2. An IPFIX Message consisting entirely of Data Sets - After the 512 appropriate Template Records have been defined and transmitted to 513 the Collecting Process, the majority of IPFIX Messages consist 514 solely of Data Sets. 516 +--------+----------------------------------------------+ 517 | | +---------+ +---------+ +---------+ | 518 |Message | | Data | | Data | | Data | | 519 | Header | | Set | ... | Set | ... | Set | | 520 | | +---------+ +---------+ +---------+ | 521 +--------+----------------------------------------------+ 523 Figure D: IPFIX Message example 2 525 3. An IPFIX Message consisting entirely of Template and Options 526 Template Sets. 528 +--------+-------------------------------------------------+ 529 | | +----------+ +----------+ +----------+ | 530 |Message | | Template | | Template | | Options | | 531 | Header | | Set | ... | Set | ... | Template | | 532 | | | | | | | Set | | 533 | | +----------+ +----------+ +----------+ | 534 +--------+-------------------------------------------------+ 536 Figure E: IPFIX Message example 3 538 3.1 Message Header Format 540 The format of the IPFIX Message Header is shown in Figure F. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Version Number | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Export Time | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Sequence Number | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Observation Domain ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure F: IPFIX Message Header format 556 Message Header Field Descriptions 558 Version 559 Version of Flow Record format exported in this message. The 560 value of this field is 0x000a for the current version, 561 incrementing by one the version used in the NetFlow services 562 export version 9 [RFC3954]. 564 Length 565 Total length of the IPFIX Message, measured in octets, 566 including Message Header and Set(s). 568 Export Time 569 Time in seconds since 0000 UTC Jan 1st 1970, at which the 570 IPFIX Message Header leaves the Exporter. 572 Sequence Number 573 Incremental sequence counter modulo 2^32 of all IPFIX Data 574 Records sent on this PR-SCTP stream from the current 575 Observation Domain by the Exporting Process. Check the 576 specific meaning of this field in the sub-sections of 577 section 10 when UDP or TCP is selected as the transport 578 protocol. This value SHOULD be used by the Collecting 579 Process to identify whether any IPFIX Data Records have been 580 missed. Template and Options Template Records do not 581 increase the Sequence Number. 583 Observation Domain ID 584 A 32-bit identifier of the Observation Domain that is 585 locally unique to the Exporting Process. The Exporting 586 Process uses the Observation Domain ID to uniquely identify 587 to the Collecting Process the Observation Domain that 588 metered the Flows. It is RECOMMENDED that this identifier 589 is also unique per IPFIX Device. Collecting Processes 590 SHOULD use the Transport Session and the Observation Domain 591 ID field to separate different export streams originating 592 from the same Exporting Process. The Observation Domain ID 593 SHOULD be 0 when no specific Observation Domain ID is 594 relevant for the entire IPFIX Message. For example, when 595 exporting the Exporting Process Statistics, or in case of 596 hierarchy of Collector when aggregated data records are 597 exported. 599 3.2 Field Specifier Format 601 Vendors need the ability to define proprietary Information Elements, 602 because, for example, they are delivering a pre-standards product, 603 or the Information Element is in some way commercially sensitive. 604 This section describes the Field Specifier format for both IETF 605 specified Information Elements [IPFIX-INFO] and enterprise-specific 606 Information Elements. 608 The Information Elements are identified by the Information Element 609 identifier. When the Enterprise bit is set to 0, the corresponding 610 Information Element identifier will report an IETF specified 611 Information Element, and the Enterprise Number MUST NOT be present. 612 When the Enterprise bit is set to 1, the corresponding Information 613 Element identifier will report an enterprise-specific Information 614 Element and the Enterprise Number MUST be present. An example of 615 this is shown in section 13.4.2 617 The Field Specifier format is shown in Figure G. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |E| Information Element ident. | Field Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Enterprise Number | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure G: Field Specifier format 629 Where: 631 E 632 Enterprise bit. This is the first bit of the Field 633 Specifier. If this bit is zero, the Information Element 634 Identifier identifies an IETF specified Information Element, 635 and the four octet Enterprise Number field MUST NOT be 636 present. If this bit is one, the Information Element 637 identifier identifies an enterprise-specific Information 638 Element, and the Enterprise Number filed MUST be present. 640 Information Element identifier 641 A numeric value that represents the type of the Information 642 Element. Refer to [IPFIX-INFO]. 644 Field Length 645 The length of the corresponding encoded Information Element, 646 in octets. Refer to [IPFIX-INFO]. The field length may be 647 smaller than the definition in [IPFIX-INFO] if reduced size 648 encoding is used (see section 6.2). The value 65535 is 649 reserved for variable length Information Element (see 650 section 7). 652 Enterprise Number 653 IANA enterprise number [PEN] of the authority defining the 654 Information Element identifier in this Template Record. 656 3.3 Set and Set Header Format 658 A Set is a generic term for a collection of records that have a 659 similar structure. There are three different types of Sets: 660 Template Sets, Options Template Sets, and Data Sets. Each of these 661 Sets consists of a Set Header and one or more Records. The Set 662 Format and the Set Header Format are defined in the following 663 sections. 665 3.3.1 Set Format 667 A Set has the format shown in figure H. The records types can be 668 either Template Records, Options Template Records or Data Records. 669 The record types MUST NOT be mixed within a Set. 671 +--------------------------------------------------+ 672 | Set Header | 673 +--------------------------------------------------+ 674 | record | 675 +--------------------------------------------------+ 676 | record | 677 +--------------------------------------------------+ 678 ... 679 +--------------------------------------------------+ 680 | record | 681 +--------------------------------------------------+ 682 | Padding (opt.) | 683 +--------------------------------------------------+ 684 Figure H: Set Format 686 The Set Field Definitions are as follows: 688 Set Header 689 The Set Header Format is defined in section 3.3.2. 691 Record 692 One of the Record Formats: Template Record or Options Template 693 Record or Data Record Format. 695 Padding 696 The Exporting Process MAY insert some padding octets, so that 697 the subsequent Set starts at an aligned boundary. For 698 security reasons, the padding octet(s) MUST be composed of 699 zero (0) valued octets. The padding length MUST be shorter 700 than any allowable Record in this Set. If padding of the 701 IPFIX Message is desired in combination with very short 702 Records, then the padding Information Element 'paddingOctets' 703 [IPFIX-INFO] can be used for padding Records such that their 704 length is increased to a multiple of 4 or 8 octets. Because 705 Template Sets are always 4-octet aligned by definition, 706 padding is only needed in case of other alignments e.g. on 8- 707 octet boundaries. 709 3.3.2 Set Header Format 711 Every Set contains a common header. This header is defined in figure 712 I. 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Set ID | Length | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure I: Set Header Format 722 The Set Header Field Definitions are as follows: 724 Set ID 725 Set ID value identifies the Set. A value of 2 is reserved for 726 the Template Set. A value of 3 is reserved for the Option 727 Template Set. All other values from 4 to 255 are reserved 728 for future use. Values above 255 are used for Data Sets. The 729 Set ID values of 0 and 1 are not used for historical reasons 730 [RFC3954]. 732 Length 733 Total length of the Set in octets including the Set Header, 734 all records and the optional padding. Because an individual 735 Set MAY contain multiple records, the Length value MUST be 736 used to determine the position of the next Set. 738 3.4 Record Format 740 IPFIX defines three record formats, defined in the next sections: 741 the Template Record Format, the Options Template Record Format and 742 the Data Record Format. 744 3.4.1 Template Record Format 746 One of the essential elements in the IPFIX record format is the 747 Template Record. Templates greatly enhance the flexibility of the 748 record format because they allow the Collecting Process to process 749 IPFIX Messages without necessarily knowing the interpretation of all 750 Data Records. A Template Record contains any combination of IANA- 751 assigned and/or enterprise-specific Information Elements 752 identifiers. 754 The format of the Template Record is shown in Figure J. It consists 755 of a Template Record Header and one or more Field Specifiers. The 756 definition of the Field Specifiers is given in figure G above. 758 +--------------------------------------------------+ 759 | Template Record Header | 760 +--------------------------------------------------+ 761 | Field Specifier | 762 +--------------------------------------------------+ 763 | Field Specifier | 764 +--------------------------------------------------+ 765 ... 766 +--------------------------------------------------+ 767 | Field Specifier | 768 +--------------------------------------------------+ 770 Figure J: Template Record Format 772 The format of the Template Record Header is shown in Figure K. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Template ID (> 255) | Field Count | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Figure K: Template Record Header Format 782 The Template Record Header Field Definitions are as follows: 784 Template ID 785 Each of the newly generated Template Records is given a unique 786 Template ID. This uniqueness is local to the Transport 787 Session and Observation Domain that generated the Template ID. 788 Template IDs 0-255 are reserved for Template Sets, Options 789 Template Sets, and other reserved Sets yet to be created. 790 Template IDs of Data Sets are numbered from 256 to 65535. 791 There are no constraints regarding the order of the Template 792 ID allocation. 794 Field Count 795 Number of fields in this Template Record. 797 The example in Figure L shows a Template Set with mixed standard and 798 enterprise-specific Information Elements. It consists of Set Header, 799 Template Header and several Field Specifiers. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Set ID = 2 | Length | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Template ID = 256 | Field Count = N | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 |1| Information Element id. 1.1 | Field Length 1.1 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Enterprise Number 1.1 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 |0| Information Element id. 1.2 | Field Length 1.2 | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | ... | ... | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 |1| Information Element id. 1.N | Field Length 1.N | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Enterprise Number 1.N | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Template ID = 257 | Field Count = M | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 |0| Information Element id. 2.1 | Field Length 2.1 | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 |1| Information Element id. 2.2 | Field Length 2.2 | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Enterprise Number 2.2 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | ... | ... | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 |1| Information Element id. 2.M | Field Length 2.M | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Enterprise Number 2.M | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Padding (opt) | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Figure L: Template Set Example 839 Information Element Identifiers 1.2 and 2.1 are defined by the IETF 840 (Enterprise bit = 0) and therefore do not need an Enterprise Number 841 to identify them. 843 3.4.2 Options Template Record Format 845 Thanks to the notion of scope, The Options Template Record gives the 846 Exporter the ability to provide additional information to the 847 Collector which would not be possible with Flow Records alone. 849 One Options Template Record example is the "Flow Keys", which 850 reports the Flow Keys for a Template, which is defined as the scope. 851 Another example is the "Template configuration", which reports the 852 configuration sampling parameter(s) for the Template, which is 853 defined as the scope. 855 3.4.2.1 Scope 857 The scope, which is only available in the Options Template Set, 858 gives the context of the reported Information Elements in the Data 859 Records. Note that the IPFIX Message Header already contains the 860 Observation Domain ID (the identifier of the Observation Domain). If 861 not zero, this Observation Domain ID can be considered as an 862 implicit scope for the Data Records in the IPFIX Message. The 863 Observation Domain ID MUST be zero when the IPFIX Message contains 864 data records with different Observation Domain ID values defined as 865 scopes. 867 Multiple scope fields MAY be present in the Options Template Record, 868 in which case, the composite scope is the combination of the scopes. 869 For example, if the two scopes are defined as "metering process" and 870 "template", the combined scope is this Template for this metering 871 process. The order of the scope fields, as defined in the Options 872 Template Record, is irrelevant in this case. However, if the order 873 of the scope fields in the Options Template Record is relevant, the 874 order of the scope fields MUST be used. For example, if the first 875 scope defines the filtering function, while the second scope defines 876 the sampling function, the order of the scope is important. Applying 877 the sampling function first, followed by the filtering function, 878 would lead to potentially different Data Records than applying the 879 filtering function first, followed by the sampling function. In 880 this case, the Collector deduces the function order by looking at 881 the order of the scope in the Options Template Record. 883 The scope is an Information Element specified in the IPFIX 884 Information Model [IPFIX-INFO]. An IPFIX compliant implementation 885 of the Collecting Process SHOULD support this minimum set of 886 Information Elements as scope: LineCardId, TemplateId, 887 exporterIPv4Address, exporterIPv6Address, and ingressInterface. 888 Note that other Information Elements such as meteringProcessId, 889 exportingProcessId, observationDomainId, etc. are also valid scopes. 890 The IPFIX protocol doesn't prevent the use of any Information 891 Elements for scope. However some Information Element types don't 892 make sense if specifed as scope. For example: the counter 893 Information Elements. 895 Finally, note that the Scope Field Count MUST NOT be zero. 897 3.4.2.2 Options Template Record Format 899 An Options Template Record contains any combination of IANA-assigned 900 and/or enterprise-specific Information Elements identifiers. 902 The format of the Options Template Record is shown in Figure M. It 903 consists of an Options Template Record Header and one or more Field 904 Specifiers. The definition of the Field Specifiers is given in 905 figure G above. 907 +--------------------------------------------------+ 908 | Options Template Record Header | 909 +--------------------------------------------------+ 910 | Field Specifier | 911 +--------------------------------------------------+ 912 | Field Specifier | 913 +--------------------------------------------------+ 914 ... 915 +--------------------------------------------------+ 916 | Field Specifier | 917 +--------------------------------------------------+ 919 Figure M: Options Template Record Format 921 The format of the Options Template Record Header is shown in Figure 922 N. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Template ID (> 255) | Field Count | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Scope Field Count | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Figure N: Options Template Record Header Format 934 The Options Template Record Header Field Definitions are as follows: 936 Template ID 937 Template ID of this Options Template Record. This value is 938 greater than 255. 940 Field Count 941 Number of all fields in this Options Template Record, 942 including the Scope Fields. 944 Scope Field Count 945 Number of scope fields in this Options Template Record. The 946 Scope Fields are normal Fields except that they are 947 interpreted as Scope at the Collector. The Scope Field Count 948 MUST NOT be zero. 950 The example in Figure O shows an Option Template Set with mixed IETF 951 and enterprise-specific Information Elements. It consists of Set 952 Header, Option Template Header and several Field Specifiers. 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Set ID = 3 | Length | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Template ID = 258 | Field Count = N + M | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Scope 2 Field Length | ... | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | ... |1| Scope N Infor. Element Id. | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Scope N Field Length | Scope N Enterprise Number ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Option 1 Field Length | Option 1 Enterprise Number ... 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 ... Option 1 Enterprise Number | ... | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | ... |0| Option M Infor. Element Id. | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Option M Field Length | Padding (optional) | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Figure O: Option Template Set Example 984 3.4.3 Data Record Format 986 The Data Records are sent in Data Sets. The format of the Data 987 Record is shown in Figure P. It consists only of one or more Field 988 Values. The Template ID to which the Field Values belong is encoded 989 in the Set Header field "Set ID" i.e., "Set ID" = "Template ID". 991 +--------------------------------------------------+ 992 | Field Value | 993 +--------------------------------------------------+ 994 | Field Value | 995 +--------------------------------------------------+ 996 ... 997 +--------------------------------------------------+ 998 | Field Value | 999 +--------------------------------------------------+ 1001 Figure P: Data Record Format 1003 Note that Field Values do not necessarily have a length of 16 bits. 1004 Field Values are encoded according to their data type specified in 1005 [IPFIX-INFO]. 1007 Interpretation of the Data Record format can be done only if the 1008 Template Record corresponding to the Template ID is available at the 1009 Collecting Process. 1011 The example in Figure Q shows a Data Set. It consists of a Set 1012 Header several Field Values. 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Set ID = Template ID | Length | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Record 1 - Field Value 3 | ... | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Record 2 - Field Value 3 | ... | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Record 3 - Field Value 3 | ... | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | ... | Padding (optional) | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure Q: Data Set, containing Data Records 1036 4. Specific Reporting Requirements 1038 Some specific Options Templates and Options Template Records are 1039 necessary to provide extra information about the Flow Records and 1040 about the Metering Process. 1042 The Option Template and Options Template Records defined in these 1043 sub-sections, which impose some constraints on the Metering Process 1044 and Exporting Process implementations, MAY be implemented. If 1045 implemented, the specific Option Templates SHOULD be implemented as 1046 specified in these sub-sections. 1048 The minimum set of Information Elements is always specified in these 1049 Specific IPFIX Options Templates. Nevertheless, extra Information 1050 Elements may be used in these specific Options Templates. 1052 4.1 The Metering Process Statistics Option Template 1054 The Metering Process Statistics Option Template specifies the 1055 structure of a Data Record for reporting Metering Process 1056 statistics. It SHOULD contain the following Information Elements 1057 that are defined in [IPFIX-INFO]: 1059 observationDomainId An identifier of an Observation Domain 1060 that is locally unique to the Exporting 1061 Process. This Information Element MUST 1062 be defined as a Scope Field. 1064 exportedMessageTotalCount 1065 The total number of IPFIX Messages 1066 that the Exporting Process successfully 1067 sent to the Collecting Process since 1068 the Exporting Process re- 1069 initialization. 1071 exportedFlowTotalCount The total number of Flow Records that 1072 the Exporting Process successfully sent 1073 to the Collecting Process since the 1074 Exporting Process re-initialization. 1076 exportedOctetTotalCount The total number of octets that the 1077 Exporting Process successfully sent to 1078 the Collecting Process since the 1079 Exporting Process re-initialization. 1081 The Exporting Process SHOULD export the Data Record specified by the 1082 Metering Process Statistics Option Template on a regular basis or 1083 based on some export policy. This periodicity or export policy 1084 SHOULD be configurable. 1086 Note that if several Metering Processes are available on the 1087 Exporter Observation Domain, the Information Element 1088 meteringProcessId MUST be specified as an additional Scope Field. 1090 4.2 The Metering Process Reliability Statistics Option Template 1092 The Metering Process Reliability Option Template specifies the 1093 structure of a Data Record for reporting lack of reliability in the 1094 Metering Process. It SHOULD contain the following Information 1095 Elements that are defined in [IPFIX-INFO]: 1097 observationDomainId An identifier of an Observation Domain 1098 that is locally unique to the Exporting 1099 Process. This Information Element MUST 1100 be defined as a Scope Field. 1102 ignoredPacketTotalCount The total number of IP packets that the 1103 Metering Process did not process. 1105 ignoredOctetTotalCount The total number of octets in observed 1106 IP packets that the Metering Process 1107 did not process. 1109 time first ignored The time stamp of the first IP packet 1110 that was ignored by the Metering 1111 Process. For this time stamp, any of 1112 the "flowStart" time stamp Information 1113 Elements flowStartMilliseconds, 1114 flowStartMicroseconds, 1115 flowStartNanoseconds, and 1116 flowStartDeltaMicroseconds can be used. 1118 time last ignored The time stamp of the last IP packet 1119 that was ignored by the Metering 1120 Process. For this time stamp, any of 1121 the "flowEnd" time stamp Information 1122 Elements flowEndMilliseconds, 1123 flowEndMicroseconds, 1124 flowEndNanoseconds, and 1125 flowEndDeltaMicroseconds can be used. 1127 The Exporting Process SHOULD export the Data Record specified by the 1128 Metering Process Reliability Statistics Option Template on a regular 1129 basis or based on some export policy. This periodicity or export 1130 policy SHOULD be configurable. 1132 Note that if several Metering Processes are available on the 1133 Exporter Observation Domain, the Information Element 1134 meteringProcessId MUST be specified as an additional Scope Field. 1136 4.3 The Exporting Process Reliability Statistics Option Template 1138 The Exporting Process Reliability Option Template specifies the 1139 structure of a Data Record for reporting lack of reliability in the 1140 Exporting process. It SHOULD contain the following Information 1141 Elements that are defined in [IPFIX-INFO]: 1143 Exporting Process ID The identifier of the Exporting Process 1144 for which lack of reliability is 1145 reported. There are three Information 1146 Elements specified in [IPFIX-INFO] that 1147 can be used for this purpose: 1148 exporterIPv4Address, 1149 exporterIPv6Address, or 1150 exportingProcessId. This 1151 Information Element MUST be defined 1152 as a Scope Field. 1154 notSentFlowTotalCount The total number of Flows that were 1155 generated by the Metering Process and 1156 but dropped by the Metering Process or 1157 by the Exporting Process instead of 1158 sending it to the Collecting Process. 1160 notSentPacketTotalCount The total number of packets in Flow 1161 Records that were generated by the 1162 Metering Process and but dropped by 1163 the Metering Process or by the 1164 Exporting Process instead of sending 1165 it to the Collecting Process. 1167 notSentOctetTotalCount The total number of octets in packets 1168 in Flow Records that were generated by 1169 the Metering Process and but dropped 1170 by the Metering Process or by the 1171 Exporting Process instead of sending 1172 it to the Collecting Process. 1174 time first flow dropped The time stamp of the first Flow 1175 was dropped by the Metering 1176 Process. For this time stamp, any of 1177 the "flowStart" time stamp Information 1178 Elements flowStartMilliseconds, 1179 flowStartMicroseconds, 1180 flowStartNanoseconds, and 1181 flowStartDeltaMicroseconds can be used. 1183 time last flow dropped The time stamp of the last IP packet 1184 that was ignored by the Metering 1185 Process. For this time stamp, any of 1186 the "flowEnd" time stamp Information 1187 Elements flowEndMilliseconds, 1188 flowEndMicroseconds, 1189 flowEndNanoseconds, and 1190 flowEndDeltaMicroseconds can be used. 1192 The Exporting Process SHOULD export the Data Record specified by the 1193 Exporting Process Reliability Statistics Option Template on a 1194 regular basis or based on some export policy. This periodicity or 1195 export policy SHOULD be configurable. 1197 4.4 The Flow Keys Option Template 1199 The Flow Keys Option Template specifies the structure of a Data 1200 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1201 Data Record extends a particular Template Record that is referenced 1202 by its templateId identifier. The Template Record is extended by 1203 specifying which of the Information Elements contained in the 1204 corresponding Data Records describe Flow properties that server as 1205 Flow Keys of the reported Flow. 1207 The Flow Keys Option Template SHOULD contain the following 1208 Information Elements that are defined in [IPFIX-INFO]: 1210 templateId An identifier of a Template. This 1211 Information Element MUST be defined as 1212 a Scope Field. 1214 flowKeyIndicator Bitmap with the positions of the Flow 1215 Keys in the Data Records. 1217 5. IPFIX Message Header "Export Time" and Flow Record Time 1219 The IPFIX Message Header "Export Time" field is the time in seconds 1220 since 0000 UTC Jan 1st, 1970, at which the IPFIX Message Header 1221 leaves the Exporter. The time-related Information Elements 1222 specified in [IPFIX-INFO] MAY use this "Export Time" as base time 1223 and specify an offset relative to it, instead of using a common base 1224 time, such as 0000 UTC Jan 1st, 1970. All Information Elements that 1225 do not have their base time defined by their data type, MUST have 1226 the base time clearly specified in their description. 1228 For example, Data Records requiring a microsecond precision can 1229 export the flow start and end times with the flowStartMicroseconds 1230 and flowEndMicroseconds Information Elements [IPFIX-INFO], 1231 containing the time since 0000 UTC Jan 1st 1970. An alternate 1232 solution is to export the flowStartDeltaMicroseconds and 1233 flowEndDeltaMicroseconds Information Elements [IPFIX-INFO] in the 1234 Data Record, which respectively report the flow start and end time 1235 offsets compared to the IPFIX Message Header "Export Time". The 1236 latter solution lowers the export bandwidth requirement while it 1237 increases the load on the Exporter as the Exporting Process must 1238 calculate the flowStartDeltaMicroseconds and 1239 flowEndDeltaMicroseconds of every single Data Record before 1240 exporting the IPFIX Message. 1242 It must be noted that using time-related Information Elements with 1243 offset times compared to the IPFIX Message Header "Export Time" 1244 imposes some time constraints on the Data Records contained in the 1245 IPFIX Message. In the example of flowStartDeltaMicroseconds and 1246 flowEndDeltaMicroseconds Information Elements [IPFIX-INFO], the Data 1247 Record must be exported within a maximum of 71 minutes after its 1248 creation. Otherwise, the 32-bits counter would not be sufficient to 1249 contain the flow start time offset. 1251 6. Linkage with the Information Model 1252 The Information Elements [IPFIX-INFO] MUST be sent in canonical 1253 format in network byte order (also known as the big-endian byte 1254 ordering). 1256 6.1 Encoding of IPFIX Data Types 1258 The following sections will define the encoding of the data types 1259 specified in [IPFIX-INFO]. 1261 6.1.1 Integral Data Types 1263 Integral data types - octet, signed8, unsigned16, signed16, 1264 unsigned32, signed32, signed64 and unsigned64 - MUST be encoded 1265 using the default canonical format in network byte order. Signed 1266 Integral data types are represented in two's complement notation. 1268 6.1.2 Address Types 1270 Address types - macAddress, ipv4Address and ipv6Address - MUST be 1271 encoded the same way as the integral data types. The macAddress is 1272 treated as a 6-octet integer, the ipv4Address as a 4-octet integer 1273 and the ipv6Address as a 16-octet integer. 1275 6.1.3 float32 1277 The float32 data type MUST be encoded as an IEEE single-precision 32- 1278 bit floating point-type, as specified in [IEEE.754.1985]. 1280 6.1.4 float64 1282 The float64 data type MUST be encoded as an IEEE double-precision 1283 64-bit floating point-type, as specified in [IEEE.754.1985]. 1285 6.1.5 boolean 1287 The boolean data type is specified according to the TruthValue in 1288 [RFC2579]: that is an integer with the value 1 for true and a value 1289 2 for false. Every other value is undefined. The boolean data type 1290 MUST be encoded in a single octet. 1292 6.1.6 string and octetarray 1294 The data type string represents a finite length string of valid 1295 characters of the Unicode character encoding set. The string data 1296 type MUST be encoded in UTF-8 format. The string is sent as an 1297 array of octets using an information element of fixed or variable 1298 length. The length of the information element specifies the length 1299 of the octetarray. 1301 6.1.7 dateTimeSeconds 1303 The data type dateTimeseconds represents a time value in units of 1304 seconds normalised to the GMT timezone. It MUST be encoded in a 32- 1305 bit integer containing the number of seconds since 0000 UTC Jan 1st 1306 1970. The 32-bit integer allows the time encoding up to 136 years. 1308 6.1.8 dateTimeMilliseconds 1310 The data type dateTimeMilliseconds represents a time value in units 1311 of milliseconds normalized to the GMT timezone. It MUST be encoded 1312 in a 64-bit integer containing the number of milliseconds since 0000 1313 UTC Jan 1st 1970. 1315 6.1.9 dateTimeMicroseconds 1317 The data type dateTimeMicroseconds represents a time value in units 1318 of microseconds normalized to the GMT timezone. It MUST be encoded 1319 in a 64-bit integer according to the NTP format given in [RFC1305]. 1321 6.1.10 dateTimeNanoseconds 1323 The data type of dateTimeNanoseconds represents a time value in 1324 units of nanoseconds normalized to the GMT timezone. It MUST be 1325 encoded in a 64-bit integer according to the NTP format given in 1326 [RFC1305]. 1328 6.2 Reduced Size Encoding of Integer and Float Types 1330 Information Elements containing integer, string, float, and 1331 octetarray types in the information model MAY be encoded using 1332 fewer octets than those implied by their type in the information 1333 model definition [IPFIX-INFO], based on the assumption that the 1334 smaller size is sufficient to carry any value the Exporter may need 1335 to deliver. This reduces the network bandwidth requirement 1336 between the Exporter and the Collector. Note that the Information 1337 Element definitions [IPFIX-INFO] will always define the maximum 1338 encoding size. 1340 For instance the information model [IPFIX-INFO] defines byteCount as 1341 an unsigned64 type, which would require 64-bits. However if the 1342 Exporter will never locally encounter the need to send a value 1343 larger than 4294967295, it may chose to send the value instead as an 1344 unsigned32. For example, a core router would require an unsigned64 1345 byteCount while an unsigned32 might be sufficient for an access 1346 router. 1348 This behavior is indicated by the Exporter by specifying a type size 1349 with a smaller length than that associated with the assigned type of 1350 the Information Element. In the example above the Exporter would 1351 place a length of 4 versus 8 in the Template. 1353 If reduced sizing is used, it MUST only be applied to the following 1354 integer types: unsigned64, signed64, unsigned32, signed32, 1355 unsigned16, signed16. The signed versus unsigned property of the 1356 reported value MUST be preserved. The reduction in size can be to 1357 any number of octets smaller than the original type if the data 1358 value still fits, i.e. so that only leading zeroes are dropped. For 1359 example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, 1360 or 1 octet(s). 1362 Reduced sizing can also be used to reduce float64 to float32. The 1363 float32 not only has a reduced number range, but due to the smaller 1364 mantissa is also less precise. 1366 The reduced size encoding MUST NOT be applied to 1367 dateTimeMicroseconds or to dateTimeNanoseconds because these 1368 represent an inherent structure that would be destroyed by using 1369 less than the original number of bytes. 1371 7. Variable Length Information Element 1373 The IPFIX Template mechanism is optimized for fixed length 1374 Information Elements [IPFIX-INFO]. Where an Information Element has 1375 a variable length the following mechanism MUST be used to carry the 1376 length information, for both the IETF and proprietary Information 1377 Elements. 1379 In the Template Set the Information Element Field Length is recorded 1380 as 65535. This reserved length value notifies the Collecting 1381 Process that length of the Information Element will be carried in 1382 the Information Element content itself. 1384 In most cases the length of the Information Element will be less 1385 than 255 octets. The following length encoding mechanism optimizes 1386 the overhead of carrying the Information Element length in this 1387 majority case. The length is carried in the octet before the 1388 Information Element, as shown in Figure R. 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Length (< 255)| Information element | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | ... continuing as needed | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Figure R: Variable Length Information Element (length < 255 octets) 1400 If the length of the Information Element is greater than or equal to 1401 255 octets, the length is encoded into 3 octets before the 1402 Information Element. The first octet is 255 and the length is 1403 carried in the second and third octets, as shown in Figure S. 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | 255 | Length (0 to 65535) | IE | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | ... continuing as needed | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Figure S: Variable Length Information Element 1414 (length 0 to 65535) octets 1416 The octets carrying the length (either the first or the first three 1417 octets) MUST NOT be included in the length of the Information 1418 Element. 1420 8. Template Management 1422 This section describes Template management when using SCTP and PR- 1423 SCTP as the transport protocol. Any necessary changes to Template 1424 management specifically related to TCP or UDP transport protocols are 1425 specified in section 10. 1427 The Exporting Process assigns and maintains the Template IDs per SCTP 1428 association for the Exporter's Observation Domains. A newly created 1429 Template Record is assigned an unused Template ID by the Exporting 1430 Process. 1432 If a specific Information Element is required by a Template but is 1433 not available in observed packets, the Exporting Process MAY choose 1434 to export Flow Records without this Information Element in a Data 1435 Record defined by a new Template. 1437 If an Information Element is required more than once in Template, the 1438 different occurrences of this Information Element SHOULD follow the 1439 logical order of their treatments by the Metering Process. For 1440 example, if a selected packet goes through two hash functions, and if 1441 the two hash values are sent within a single Template, the first 1442 occurrence of the hash value should belong to the first hash function 1443 in the Metering Process. For example, when exporting the two source 1444 IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address 1445 Information Element occurrence should be the IPv4 address of the 1446 outer header, while the second occurrence should be the inner header 1447 one. 1449 Template Sets and Options Template Sets may be sent on any SCTP 1450 stream. Template Sets and Options Template Sets MUST be sent 1451 reliably, using SCTP ordered delivery. As such, the Collecting 1452 Process MUST store the Template Record information for the duration 1453 of the SCTP association so that it can interpret the corresponding 1454 Data Records that are received in subsequent Data Sets. 1456 The Exporting Process SHOULD transmit the Template Set and Options 1457 Template Set in advance of any Data Sets that use that (Options) 1458 Template ID, to help ensure that the Collector has the Template 1459 Record before receiving the first Data Record. Data Records that 1460 correspond to a Template Record MAY appear in the same and/or 1461 subsequent IPFIX Message(s). 1463 Different Observation Domains from the same SCTP association may use 1464 the same Template ID value to refer to different Templates. 1466 The Templates that are not used anymore SHOULD be deleted. Before 1467 reusing a Template ID, the Template MUST be deleted. In order to 1468 delete an allocated Template, the Template is withdrawn through the 1469 use of a Template Withdraw Message. 1471 The Template Withdraw Message MUST NOT be sent until sufficient time 1472 has elapsed to allow the Collecting Process to receive and process 1473 the last Data Record using this Template information. This time MUST 1474 be configurable. A suitable default value is 5 seconds after the 1475 last Data Record has been sent. 1477 The Template ID from a withdrawn Template MUST NOT be reused until 1478 sufficient time has elapsed to allow for the Collecting Process to 1479 receive and process the Template withdraw message. 1481 A Template Withdraw Message is a Template Record for that Template ID 1482 with a Field Count of 0. The format of the Template Withdrawal 1483 Message is shown in figure T. 1485 0 1 2 3 1486 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 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Set ID = (2 or 3) | Length = 16 | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Template ID N | Field Count = 0 | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Template ID ... | Field Count = 0 | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Template ID M | Field Count = 0 | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 Figure T: Template Withdrawal Message format 1499 The Set ID field MUST contain the value 2 for Template Set withdrawal 1500 and the value 3 for Options Template Set withdrawal. Multiple 1501 Template IDs MAY be withdrawn with a single Template Withdrawal 1502 Message: in that case, padding MAY be used. 1504 The Template Withdraw Message withdraws the Template IDs for the 1505 Observation Domain ID specified in the IPFIX Message header. 1507 The Template Withdraw Message may be sent on any SCTP stream. The 1508 Template Withdraw Message MUST be sent reliably, using SCTP ordered 1509 delivery. 1511 The Template Withdraw Message MUST NOT contain new Template or 1512 Options Template Records. 1514 If the measurement parameters change such that a new Template is 1515 required, the Template MUST be withdrawn (using a Template Withdraw 1516 Message and a new Template definition) or an unused Template ID MUST 1517 be used. Examples of the measurement changes are: a new sampling 1518 rate, a new flow expiration process, a new filtering definition, etc. 1520 When the SCTP association shuts down or the Exporting Process 1521 restarts, all Template assignments are lost and Template IDs MUST be 1522 re-assigned. 1524 If the Metering Process restarts, the Exporting Process MUST either 1525 reuse the previously assigned Template ID for each Template, or it 1526 MUST withdraw the previously issued Template IDs by sending Template 1527 Withdraw Message(s) before reusing them. 1529 A Template Withdrawal Message to withdraw all Templates for the 1530 Observation Domain ID specified in the IPFIX Message header MAY be 1531 used. Its format is shown in figure U. 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Set ID = 2 | Length = 8 | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Template ID = 2 | Field Count = 0 | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 Figure U: All Data Templates Withdrawal Message format 1543 A Template Withdrawal Message to withdraw all Options Templates for 1544 the Observation Domain ID specified in the IPFIX Message header MAY 1545 be used. Its format is shown in figure V. 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Set ID = 3 | Length = 8 | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Template ID = 3 | Field Count = 0 | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 Figure V: All Options Templates Withdrawal Message format 1557 When the SCTP association restarts, the Exporting Process MUST resend 1558 all the Template Records. 1560 9. The Collecting Process's Side 1562 This section describes the Collecting Process when using SCTP and 1563 PR-SCTP as the transport protocol. Any necessary changes to the 1564 Collecting Process specifically related to TCP or UDP transport 1565 protocols are specified in section 10. 1567 The Collecting Process SHOULD listen for a new association request 1568 from the Exporting Process. The Exporting Process will request a 1569 number of streams to use for export. An Exporting Process MAY 1570 request and support more than one stream per SCTP association. 1572 If the Collecting Process receives a malformed IPFIX Message, it 1573 MUST reset the SCTP association, discard the IPFIX Message, and 1574 SHOULD log the error. Note that non-zero Set padding does not 1575 constitute a malformed IPFIX Message. 1577 Template Sets and Option Template Sets are only sent once. The 1578 Collecting Process MUST store the Template Record information for 1579 the duration of the association so that it can interpret the 1580 corresponding Data Records that are received in subsequent Data 1581 Sets. 1583 Template IDs are unique per SCTP association and per Observation 1584 Domain. If the Collecting Process receives a Template which has 1585 already been received but which has not previously been withdrawn 1586 (i.e. a Template Record from the same Exporter Observation Domain 1587 with the same Template ID received on the SCTP association), then 1588 the Collecting Process MUST shutdown the association. 1590 When an SCTP association is closed, the Collecting Process MUST 1591 discard all Templates received over that association and stop 1592 decoding IPFIX Messages that use those Templates. 1594 The Collecting Process normally receives Template Records from the 1595 Exporting Process before receiving Data Records. The Data Records 1596 are then decoded and stored by the Collector. If the Template 1597 Records have not been received at the time Data Records are 1598 received, the Collecting Process MAY store the Data Records for a 1599 short period of time and decode them after the Template Records are 1600 received. A Collecting Process MUST NOT assume that the Data Set 1601 and the associated Template Set (or Options Template Set) are 1602 exported in the same IPFIX Message. 1604 The Collecting Process MUST note the Information Element identifier 1605 of any Information Element that it does not understand and MAY 1606 discard that Information Element from the Flow Record. 1608 The Collector MUST accept padding in Data Records and Template 1609 Records. The padding size is the Set Length minus the size of the 1610 Set Header (4 octets for the Set ID and the Set Length), modulo the 1611 Record size deduced from the Template Record. 1613 The IPFIX protocol has a Sequence Number field in the Export header 1614 which increases with the number of IPFIX Data Records in the IPFIX 1615 Message. A Collector may detect out of sequence, dropped, or 1616 duplicate IPFIX Messages by tracking the Sequence Number. A 1617 collector SHOULD provide a logging mechanism for tracking out of 1618 sequence IPFIX Messages. Such out of sequence IPFIX Messages may be 1619 due to Exporter resource exhaustion where it can not transmit 1620 messages at their creation rate, an Exporting Process reset, 1621 congestion on the network link between the Exporter and Collector, 1622 Collector resource exhaustion where it can not process the IPFIX 1623 Messages at their arrival rate, out of order packet reception, 1624 duplicate packet reception, or an attacker injecting false messages. 1626 If a Collecting Process receives a Template Withdraw Message, the 1627 Collecting Process MUST delete the corresponding Template Records 1628 associated with the specific SCTP association and specific 1629 Observation Domain, and stop decoding IPFIX Messages that use the 1630 withdrawn Templates. 1632 If the Collecting Process receives a Template Withdraw message for a 1633 Template Record it has not received before on this SCTP assocation, 1634 it MUST reset the SCTP association, discard the IPFIX Message, and 1635 SHOULD log the error as it does for malformed IPFIX Messages. 1637 A Collecting Process that receives IPFIX Messages from several 1638 Observation Domains on the same Transport Session MUST be aware that 1639 the uniqueness of the Template ID is not guaranteed across 1640 Observation Domains. 1642 The Collector MUST support the use of Templates containing multiple 1643 occurrences of the similar Information Elements. 1645 10. Transport Protocol 1647 The IPFIX Protocol Specification has been designed to be transport 1648 protocol independent. Note that the Exporter can export to multiple 1649 Collecting Processes, using independent transport protocols. 1651 The IPFIX Message Header 16-bit Length field limits the length of a 1652 IPFIX Message to 65535 octets including the header. A Collecting 1653 Process MUST be able to handle IPFIX Message lengths of up to 65535 1654 octets. 1656 10.1 Transport Compliance and Transport Usage 1657 We need to differentiate between what must be implemented (so that 1658 operators can interoperably deploy compliant implementations from 1659 different vendors) and what should or could be used in various 1660 operational environments. We must also make sure that ALL 1661 implementations can operate in a congestion-aware and congestion 1662 avoidance mode. 1664 SCTP [RFC2960] and [RFC3309] using the PR-SCTP extension specified 1665 in [RFC3758] MUST be implemented by all compliant implementations. 1666 UDP [UDP] MAY also be implemented by compliant implementations. TCP 1667 [TCP] MAY also be implemented by compliant implementations. 1669 PR-SCTP SHOULD be used in deployments where Exporters and Collectors 1670 are communicating over links that are susceptible to congestion. 1671 PR-SCTP is capable of providing any required degree of reliability. 1673 TCP MAY be used in deployments where Exporters and Collectors 1674 communicate over links that are susceptible to congestion, but PR- 1675 SCTP is preferred, due to its ability to limit back pressure on 1676 Exporters and its message versus stream orientation. 1678 UDP MAY be used although it is not a congestion aware protocol. 1679 However, the IPFIX traffic between Exporter and Collector MUST run 1680 in an environment where IPFIX traffic has been provisioned for or is 1681 contained through some other means. 1683 10.2 SCTP 1685 This section describes how IPFIX can be transported over SCTP 1686 [RFC2960] and [RFC3309] using the PR-SCTP [RFC3758] extension. 1688 10.2.1 Congestion Avoidance 1690 The SCTP transport protocol provides the required level of 1691 congestion avoidance by design. 1693 SCTP will detect congestion in the end-to-end path between 1694 the IPFIX Exporting Process and the IPFIX Collecting Process, 1695 and limit the transfer rate accordingly. When an IPFIX 1696 Exporting Process has records to export, but detects that 1697 transmission by SCTP is temporarily impossible, it can either 1698 wait until sending is possible again, or it can decide to drop the 1699 record. In the latter case, the dropped export data MUST 1700 be accounted for, so that the amount of dropped export data can be 1701 reported. 1703 10.2.2 Reliability 1705 The SCTP transport protocol is by default reliable, but has the 1706 capability to deliver messages with partial reliability [RFC3758]. 1708 Using reliable SCTP messages for the IPFIX export is not in itself a 1709 guarantee that all Data Records are delivered. If there is 1710 congestion on the link from the Exporting Process to the Collecting 1711 Process, or if a significant number of retransmissions are required, 1712 the send queues on the Exporting Process may fill up: the Exporting 1713 Process MAY either suspend export or discard the IPFIX Messages. If 1714 Data Records are discarded the IPFIX Sequence Numbers used for 1715 export MUST reflect the loss of data. 1717 10.2.3 MTU 1719 SCTP provides the required IPFIX Message fragmentation service based 1720 on path MTU discovery. 1722 10.2.4 Exporting Process 1724 10.2.4.1 Association Establishment 1726 The IPFIX Exporting Process SHOULD initiate an SCTP association with 1727 the IPFIX Collecting Process. By default, the Collecting Process 1728 listens for connections on SCTP port 4739. By default, the 1729 Collecting Process listens for secure connections on SCTP port 4740 1730 (refer to the Security Considerations section). By default the 1731 Exporting Process tries to connect to one of these ports. It MUST 1732 be possible to configure both the Exporting and Collecting Processes 1733 to use a different SCTP port. 1735 The Exporting Process MAY establish more than one association 1736 (connection "bundle" in SCTP terminology) to the Collecting Process. 1738 An Exporting Process MAY support more than one active association 1739 to different Collecting Processes (including the case of different 1740 Collecting Processes on the same host). 1742 10.2.4.2 Association Shutdown 1744 When an Exporting Process is shutdown, it SHOULD shutdown the SCTP 1745 association. 1747 When a Collecting Process no longer wants to receive IPFIX 1748 Messages, it SHOULD shutdown its end of the association. The 1749 Collecting Process SHOULD continue to receive and process 1750 IPFIX Messages until the Exporting Process has closed its end of the 1751 association. 1753 When a Collecting Process detects that the SCTP association has been 1754 abnormally terminated, it MUST continue to listen for a new 1755 association establishment. 1757 When an Exporting Process detects that the SCTP association to the 1758 Collecting Process is abnormally terminated, it SHOULD try to re- 1759 establish the association. 1761 Association timeouts SHOULD be configurable. 1763 10.2.4.3 Stream 1765 An Exporting Process MAY request more than one SCTP stream per 1766 association. Each of these streams may be used for the transmission 1767 of IPFIX Messages containing Data Sets, Template Sets, and/or 1768 Options Template Sets. 1770 Depending on the requirements of the application, the Exporting 1771 Process may send Data Sets with full or partial reliability, using 1772 ordered or out-of-order delivery, over any SCTP stream established 1773 during SCTP Association setup. 1775 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 1776 per Section 4 of the PR-SCTP [RFC3758] specification when using 1777 partial reliability to transmit IPFIX Messages containing only Data 1778 Sets. 1780 However, Exporting Processes SHOULD mark such IPFIX Messages for 1781 retransmission for as long as resource or other constraints allow. 1783 10.2.4.4 Template Management 1785 When the transport protocol is SCTP the default Template Management 1786 described in Section 8 is used. 1788 10.2.5 Collecting Process 1790 When the transport protocol is SCTP, the default Collector 1791 processing described in Section 9 is used. 1793 10.2.6 Failover 1795 If the Collecting Process does not acknowledge the attempt by the 1796 Exporting Process to establish an association the Exporting Process 1797 should retry using the SCTP exponential backoff feature. The 1798 Exporter MAY log an alarm if the time to establish the association 1799 exceeds a specified threshold, configurable on the Exporter. 1801 If Collecting Process failover is supported by the Exporting Process 1802 a second SCTP association MAY be opened in advance. 1804 10.3 UDP 1806 This section describes how IPFIX can be transported over UDP 1807 [UDP] 1809 10.3.1 Congestion Avoidance 1811 UDP has no integral congestion avoidance mechanism. Its use 1812 over congestion sensitive network paths is therefore not 1813 recommended. UDP MAY be used in deployments where Exporters and 1814 Collectors always communicate over dedicated links that are not 1815 susceptible to congestion, i.e. over provisioned links compared to 1816 the maximum export rate from the Exporters. 1818 10.3.2 Reliability 1820 UDP is not a reliable transport protocol, and cannot guarantee 1821 delivery of messages. IPFIX Messages sent from the Exporting 1822 Process to the Collecting Process using UDP may therefore be lost. 1823 UDP MUST NOT be used unless the application can tolerate some 1824 loss of IPFIX Messages. 1826 The Collecting Process SHOULD deduce the loss and reordering of 1827 IPFIX Data Records by looking at the discontinuities in the IPFIX 1828 Sequence Number. In the case of UDP, the IPFIX Sequence Number 1829 contains the total number of IPFIX Data Records sent for the UDP 1830 Transport Session, prior to the receipt of this IPFIX Message, 1831 modulo 2^32. A Collector SHOULD detect out of sequence, dropped, or 1832 duplicate IPFIX Messages by tracking the Sequence Number. 1834 Templates sent from the Exporting Process to the Collecting 1835 Process using UDP as a transport MUST be resent at regular 1836 intervals in case previous copies were lost. 1838 10.3.3 MTU 1840 The maximum size of exported messages MUST be configured such that 1841 the total packet size does not exceed the path MTU. If the path MTU 1842 is unknown, a maximum packet size of 512 octets SHOULD be used. 1844 10.3.4 Port Numbers 1846 By default, the Collecting Process listens on the UDP port 4739. By 1847 default, the Collecting Process listens for secure connections on UDP 1848 port 4740 (refer to the Security Considerations section). By default 1849 the Exporting Process tries to connect to one of these ports 1850 It MUST be possible to configure both the Exporting and Collecting 1851 Processes to use a different UDP port. 1853 10.3.5 Exporting Process 1855 The Exporting Process MAY duplicate the IPFIX Message to the several 1856 Collecting Processes. 1858 10.3.6 Template Management 1860 When IPFIX uses UDP as the transport protocol, Template Sets and 1861 Option Template Sets MUST be re-sent at regular intervals. The 1862 frequency of (Options) Template transmission MUST be configurable. 1863 The default value for the frequency of (Options) Template 1864 transmission is 10 minutes. The Exporting Process SHOULD transmit 1865 the Template Set and Options Template Set in advance of any Data 1866 Sets that use that (Options) Template ID, to help ensure that the 1867 Collector has the Template Record before receiving the first Data 1868 Record. 1870 In the event of configuration changes, the Exporting Process SHOULD 1871 send multiple copies of the new Template definitions, in different 1872 IPFIX Messages, at an accelerated rate. In such a case, it SHOULD 1873 transmit the changed Template Record(s) and Options Template 1874 Record(s), without any data, in advance to help ensure that the 1875 Collector will have the correct Template information before 1876 receiving the first data. 1878 If the Option Template scope is defined in another Template, then 1879 both Templates SHOULD be sent in the same IPFIX Message. For 1880 example: if a Flow Key Option Template (see section 4.4) is sent in 1881 an Option Template, then the associated Template SHOULD be sent in 1882 the same IPFIX Message. 1884 Following a configuration change that can modify the interpretation 1885 of the Data Records (for example, a sampling rate change) a new 1886 Template ID MUST be used and the old Template ID MUST NOT be reused 1887 until its lifetime (see section 10.3.7) has expired. 1889 If UDP is selected as the transport protocol, the Template Withdraw 1890 Messages MUST not be used, as this method is inefficient due to the 1891 unreliable nature of UDP. 1893 10.3.7 Collecting Process 1895 The Collecting Process MUST associate a lifetime with each 1896 Template (or another of definition of an identifier considered unique 1897 within the Transport Session) received via UDP. Templates (and 1898 similar definitions) not refreshed by the Exporting Process within 1899 the lifetime are expired at the Collecting Process. If the Template 1900 (or other definition) is not refreshed before that lifetime has 1901 expired, the Collecting Process MUST discard that definition and any 1902 current and future associated Data Records. In which case, an alarm 1903 MUST be logged. The Collecting Process MUST NOT decode any further 1904 Data Records which are associated with the expired Template. If a 1905 Template is refreshed with a Template Record that differs from the 1906 previous received Template Record, the Collecting Process SHOULD log 1907 a warning and replace the previous received Template Record with the 1908 new one. The Template lifetime at the Collecting Process MUST be at 1909 least 3 times higher than the Template refresh timeout configured on 1910 the Exporting Process. 1912 Template IDs are unique per UDP session and per Observation Domain. 1913 At any given time the Collecting Process SHOULD maintain the 1914 following for all the current Template Records and Options Template 1915 Records: . 1918 The Collecting Process SHOULD accept Data Records without the 1919 associated Template Record (or other definitions) required to decode 1920 the Data Record. If the Template Records (or other definitions such 1921 as Common Properties) have not been received at the time Data Records 1922 are received, the Collecting Process SHOULD store the Data Records 1923 for a short period of time and decode them after the Template Records 1924 (or other definitions) are received. The short period of time MUST 1925 be lower than the lifetime of definitions associated with identifiers 1926 considered unique within the UDP session. 1928 If the Collecting Process receives a malformed IPFIX Message, it MUST 1929 discard the IPFIX Message, and SHOULD log the error. 1931 10.3.8 Failover 1933 Because UDP is not a connection oriented protocol, the Exporting 1934 Process is unable to determine from the transport protocol that the 1935 Collecting Process is no longer able to receive the IFPIX Messages. 1936 Therefore, it can not invoke a failover mechanism. However, the 1937 Exporting Process MAY duplicate the IPFIX Message to several 1938 Collecting Processes. 1940 10.4 TCP 1942 This section describes how IPFIX can be transported over TCP [TCP]. 1944 10.4.1 Connection Management 1946 10.4.1.1 Connection Establishment 1948 The IPFIX Exporting Process initiates a TCP connection to the 1949 Collecting Process. By default, the Collecting Process listens for 1950 connections on TCP port 4739. By default, the Collecting Process 1951 listens for secure connections on TCP port 4740 (refer to the 1952 Security Considerations section). By default the Exporting Process 1953 tries to connect to one of these ports. It MUST be possible to 1954 configure both the Exporting Process and the Collecting Process to 1955 use a different TCP port. 1957 An Exporting Process MAY support more than one active connection to 1958 different Collecting Processes (including the case of different 1959 Collecting Processes on the same host). 1961 The Exporter MAY log an alarm if the time to establish the 1962 connection exceeds a specified threshold, configurable on the 1963 Exporter. 1965 10.4.1.2 Graceful Connection Release 1966 When an Exporting Process is shutdown, it SHOULD shutdown the TCP 1967 connection. 1969 When a Collecting Process no longer wants to receive IPFIX Messages, 1970 it SHOULD close its end of the connection. The Collecting Process 1971 SHOULD continue to read IPFIX Messages until the Exporting Process 1972 has closed its end. 1974 10.4.1.3 Restarting Interrupted Connections 1976 When a Collecting Process detects that the TCP connection to the 1977 Exporting Process has terminated abnormally, it MUST continue to 1978 listen for a new connection. 1980 When an Exporting Process detects that the TCP connection to the 1981 Collecting Process has terminated abnormally, it SHOULD try to re- 1982 establish the connection. Connection timeouts and retry schedules 1983 SHOULD be configurable. In the default configuration, an Exporting 1984 Process MUST NOT attempt to establish a connection more frequently 1985 than once per minute. 1987 10.4.1.4 Failover 1989 If the Collecting Process does not acknowledge the attempt by the 1990 Exporting Process to establish a connection it will retry using the 1991 TCP exponential backoff feature. 1993 If Collecting Process failover is supported by the Exporting Process 1994 a second TCP connection MAY be opened in advance. 1996 10.4.2 Data Transmission 1998 Once a TCP connection is established, the Exporting Process starts 1999 sending IPFIX Messages to the Collecting Process. 2001 10.4.2.1 IPFIX Message Encoding 2003 IPFIX Messages are sent over the TCP connection without any special 2004 encoding. The Length field in the IPFIX Message header defines the 2005 end of each IPFIX Message and thus the start of the next IPFIX 2006 Message. This means that IPFIX Messages cannot be interleaved. 2008 In the case of TCP, the IPFIX Sequence Number contains the total 2009 number of IPFIX Data Records sent from this TCP connection, from the 2010 current Observation Domain by the Exporting Process, prior to the 2011 receipt of this IPFIX Message, modulo 2^32. 2013 If an Exporting Process exports data from multiple Observation 2014 Domains, it should be careful to choose IPFIX Message lengths 2015 appropriately to minimize head-of-line blocking between different 2016 Observation Domains. Multiple TCP connections MAY be used to avoid 2017 head-of-line between different Observation Domains. 2019 10.4.2.2 Template Management 2021 For each Template, the Exporting Process MUST send the Template 2022 Record before exporting Data Records that refer to that Template. 2024 Template IDs are unique per TCP connection and per Observation 2025 Domain. A Collecting Process MUST record all Template and Options 2026 Template Records for the duration of the connection, as an Exporting 2027 Process is not required to re-export Template Records. 2029 When the TCP connection restarts, the Exporting Process MUST resend 2030 all the Template Records. 2032 When a TCP connection is closed, the Collecting Process MUST discard 2033 all Templates received over that connection and stop decoding IPFIX 2034 Messages that use those Templates. 2036 The Templates that are not used anymore SHOULD be deleted. Before 2037 reusing a Template ID, the Template MUST be deleted. In order to 2038 delete an allocated Template, the Template is withdrawn through the 2039 use of a Template Withdrawal Message over the TCP connection. 2041 If the Collecting Process receives a malformed IPFIX Message, it 2042 MUST reset the TCP connection, discard the IPFIX Message, and SHOULD 2043 log the error. 2045 10.4.2.3 Congestion Handling and Reliability 2047 TCP ensures reliable delivery of data from the Exporting Process to 2048 the Collecting Process. TCP also controls the rate at which data 2049 can be sent from the Exporting Process to the Collecting Process, 2050 using a mechanism that takes into account both congestion in the 2051 network and the capabilities of the receiver. 2053 Therefore an IPFIX Exporting Process may not be able to send IPFIX 2054 Messages at the rate that the Metering Process generates it, either 2055 because of congestion in the network or because the Collecting 2056 Process cannot handle IPFIX Messages fast enough. As long as 2057 congestion is transient, the Exporting Process can buffer IPFIX 2058 Messages for transmission. But such buffering is necessarily 2059 limited, both because of resource limitations and because of 2060 timeliness requirements, so ongoing and/or severe congestion may 2061 lead to a situation where the Exporting Process is blocked. 2063 When an Exporting Process has Data Records to export but the 2064 transmission buffer is full, and it wants to avoid blocking, it can 2065 decide to drop some Data Records. The dropped Data Records MUST be 2066 accounted for, so that the amount can later be exported. 2068 When an Exporting Process finds that the rate at which records 2069 should be exported is consistently higher than the rate at which TCP 2070 sending permits, it should provide back pressure to the metering 2071 processes. The metering process could then adapt by temporarily 2072 reducing the amount of data it generates, for example using sampling 2073 or aggregation. 2075 10.4.3 Collecting Process 2077 The Collecting Process SHOULD listen for a new TCP connection from 2078 the Exporting Process. 2080 If the Collecting Process receives a malformed IPFIX Message, it 2081 MUST reset the TCP connection, discard the IPFIX Message, and SHOULD 2082 log the error. Note that non-zero Set padding does not constitute a 2083 malformed IPFIX Message. 2085 Template Sets and Option Template Sets are only sent once. The 2086 Collecting Process MUST store the Template Record information for 2087 the duration of the connection so that it can interpret the 2088 corresponding Data Records that are received in subsequent Data 2089 Sets. 2091 Template IDs are unique per TCP connection and per Observation 2092 Domain. If the Collecting Process receives a Template which has 2093 already been received but which has not previously been withdrawn 2094 (i.e. a Template Record from the same Exporter Observation Domain 2095 with the same Template ID received on the TCP connection), then the 2096 Collecting Process MUST shutdown the connection. 2098 When a TCP connection is closed, the Collecting Process MUST discard 2099 all Templates received over that connection and stop decoding IPFIX 2100 Messages that use those Templates. 2102 If a Collecting Process receives a Template Withdraw Message, the 2103 Collecting Process MUST delete the corresponding Template Records 2104 associated with the specific TCP connection and specific Observation 2105 Domain, and stop decoding IPFIX Messages that use the withdrawn 2106 Templates. 2108 If the Collecting Process receives a Template Withdraw message for a 2109 Template Record it has not received before on this TCP connection, 2110 it MUST reset the TCP association, discard the IPFIX Message, and 2111 SHOULD log the error as it does for malformed IPFIX Messages. 2113 11. Security Considerations 2115 The security considerations for the IPFIX protocol have been derived 2116 from an analysis of potential security threats, as discussed in the 2117 security consideration section of IPFIX requirements [RFC3917]. The 2118 requirements for IPFIX security are as follows: 2120 1. IPFIX must provide a mechanism to ensure the confidentiality of 2121 IPFIX data transferred from an Exporting Process to a Collecting 2122 Process, in order to prevent disclosure of flow data transported 2123 via IPFIX. 2125 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2126 data transferred from an Exporting Process to a Collecting Process, 2127 in order to prevent the injection of incorrect data or control 2128 information (e.g. Templates) into an IPFIX Message stream. 2130 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2131 and Exporting Processes, to prevent the collection of data from an 2132 unauthorized Exporting Process, or the export of data to an 2133 unauthorized Collecting Process 2135 Because IPFIX can be used to collect information for network 2136 forensics and billing purposes, attacks designed to confuse, disable, 2137 or take information from an IPFIX collection system may be seen as a 2138 prime objective during a sophisticated network attack. 2140 An attacker in a position to inject false messages into an IPFIX 2141 Message stream can either affect the application using IPFIX (by 2142 falsifying data), or the IPFIX Collecting Process itself (by 2143 modifying or revoking Templates, or changing options); for this 2144 reason, IPFIX Message integrity is important. 2146 The IPFIX Messages themselves may also contain information of value 2147 to an attacker, including information about the configuration of the 2148 network as well as end-user traffic and payload data, so care must be 2149 taken to confine their visibility to authorized users. When an 2150 Information Element containing end-user payload information is 2151 exported, it SHOULD be transmitted to the Collecting Process using a 2152 means that secures its contents against eavesdropping. Suitable 2153 mechanisms include the use of either a direct point-to-point 2154 connection or the use of an encryption mechanism. It is the 2155 responsibility of the Collecting Process to provide a satisfactory 2156 degree of security for this collected data, including, if necessary, 2157 anonymization of any reported data. 2159 11.1 Applicability of TLS and DTLS 2161 TLS [RFC4346] and DTLS [RFC4347] were designed to provide the 2162 confidentiality, integrity, and authentication assurances required by 2163 the IPFIX protocol, without the need for pre-shared keys. 2165 With the mandatory SCTP and PR-SCTP transport protocols for IPFIX, 2166 DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX 2167 transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is 2168 selected as the IPFIX transport protocol, TLS [RFC4346] MUST be 2169 implemented. 2171 Note that DTLS is selected as the security mechanism for SCTP and 2172 PR-SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they 2173 require all communication to be over reliable, bi-directional 2174 streams, and require one TLS connection per stream. This arrangement 2175 is not compatible with the rationale behind the choice of SCTP as an 2176 IPFIX transport protocol. 2178 Note that using DTLS [RFC4347] has a vulnerability, i.e. a true man 2179 in the middle may attempt to take data out of an association and fool 2180 the sender into thinking that the data was actually received by the 2181 peer. In generic TLS for SCTP (and/or TCP) this is not possible. 2182 This means that the removal of a message may become hidden from the 2183 sender or receiver. Another vulnerability of using PR-SCTP with DTLS 2184 is that someone could inject SCTP control information to shut down 2185 the SCTP association, effectively generating a loss of IPFIX Messages 2186 if those are buffered outside of the SCTP association. In the future, 2187 techniques such as [dtls-for-sctp] could be used to overcome these 2188 vulnerabilities. 2190 When using DTLS over SCTP, the Exporting Process MUST ensure that 2191 each IPFIX Message is sent over the same SCTP stream that would be 2192 used when sending the same IPFIX Message directly over SCTP. Note 2193 that DTLS may send its own control messages on stream 0 with full 2194 reliability; however, this will not interfere with the processing of 2195 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2196 consumes its own control messages before passing IPFIX Messages up to 2197 the application layer. 2199 11.2 Usage 2201 The IPFIX Exporting Process initiates the communication to the IPFIX 2202 Collecting Process, and acts as a TLS or DTLS client according to 2203 [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a 2204 TLS or DTLS server. The DTLS client opens a secure connection on the 2205 SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as 2206 the transport protocol. The TLS client opens a secure connection on 2207 the TCP port 4740 of the TLS server if TCP is selected as the 2208 transport protocol. The DTLS client opens a secure connection on the 2209 UDP port 4740 of the DTLS server if UDP is selected as the transport 2210 protocol. 2212 11.3 Authentication 2214 IPFIX Exporting Processes and IPFIX Collecting Processes are 2215 identified by the fully-qualified domain name of the interface on 2216 which IPFIX Messages are sent or received, for purposes of X.509 2217 client and server certificates as in [RFC3280]. 2219 To prevent man-in-the-middle attacks from impostor Exporting or 2220 Collecting Processes, the acceptance of data from an unauthorized 2221 Exporting Process, or the export of data to an unauthorized 2222 Collecting Process, strong mutual authentication via asymmetric keys 2223 MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and 2224 Collecting Processes MUST verify the identity of its peer against its 2225 authorized certificates, and MUST verify that the peer's certificate 2226 matches its fully-qualified domain name, or, in the case of SCTP, the 2227 fully-qualified domain name of one of its endpoints. 2229 The fully-qualified domain name used to identify an IPFIX Collecting 2230 Process or Exporting Process may be stored either in a subjectAltName 2231 extension of type dNSName, or in the most specific Common Name field 2232 of the Subject field of the X.509 certificate. If both are present, 2233 the subjectAltName extension is given preference. 2235 11.4 Protection against DoS attacks 2237 An attacker may mount a denial of service attack against an IPFIX 2238 collection system either directly, by sending large amounts of 2239 traffic to a Collecting Process, or indirectly, by generating large 2240 amounts of traffic to be measured by a Metering Process. 2242 Direct denial of service attacks can also involve state exhaustion, 2243 whether at the transport layer (e.g., by creating a large number of 2244 pending connections), or within the IPFIX Collecting Process itself 2245 (e.g., by sending Flow Records pending Template or Scope information, 2246 a large amount of Options Template Records, etc.) 2248 SCTP mandates a cookie exchange mechanism designed to defend against 2249 SCTP state exhaustion denial of service attacks. Similarly, TCP 2250 provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN 2251 cookies SHOULD be used by any Collecting Process accepting TCP 2252 connections. DTLS also provides cookie exchange to protect against 2253 DTLS server state exhaustion. 2255 The reader should note that there is no way to prevent fake IPFIX 2256 Message processing (and state creation) for UDP & SCTP communication. 2257 The use of TLS and DTLS can obviously prevent the creation of fake 2258 states but they are themselves prone to state exhaustion attacks. 2259 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2260 DTLS (like limiting the number of new TLS or DTLS session per second 2261 to a sensible number). 2263 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2264 at which new connections or associations will be opened by the 2265 Collecting Process, the rate at which IPFIX Messages will be accepted 2266 by the Collecting Process, and adaptively limiting the amount of 2267 state kept, particularly records waiting on Templates. These rate 2268 and state limits MAY be provided by a Collecting Process; if 2269 provided, the limits SHOULD be user-configurable. 2271 Additionally, an IPFIX Collecting Process can eliminate the risk of 2272 state exhaustion attacks from untrusted nodes by requiring TLS or 2273 DTLS mutual authentication, causing the Collecting Process to accept 2274 IPFIX Messages only from trusted sources. 2276 With respect to indirect denial of service, the behavior of IPFIX 2277 under overload conditions depends on the transport protocol in use. 2278 For IPFIX over TCP, TCP congestion control would cause the flow of 2279 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2280 system. PR-SCTP improves upon this situation somewhat, as some IPFIX 2281 Messages would continue to be received by the Collecting Process due 2282 to the avoidance of head-of-line blocking by SCTP's multiple streams 2283 and partial reliability features, possibly affording some visibility 2284 of the attack. The situation is similar with UDP, as some datagrams 2285 may continue to be received at the Collecting Process, effectively 2286 applying sampling to the IPFIX Message stream, implying that some 2287 forensics may be left. 2289 To minimize IPFIX Message loss under overload conditions, some 2290 mechanism for service differentiation could be used to prioritize 2291 IPFIX traffic over other traffic on the same link. Alternatively, 2292 IPFIX Messages can be transported over a dedicated network. In this 2293 case, care must be taken to ensure that the dedicated network can 2294 handle the expected peak IPFIX Message traffic. 2296 11.5 When DTLS or TLS is not an option 2298 The use of DTLS or TLS might not be possible in some cases due to 2299 performance issues or other operational concerns. 2301 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2302 and Collecting Processes can fall back on using IP source addresses 2303 to authenticate their peers. A policy of allocating Exporting 2304 Process and Collecting Process IP addresses from specified address 2305 ranges, and using ingress filtering to prevent spoofing, can improve 2306 the usefulness of this approach. Again, completely segregating IPFIX 2307 traffic on a dedicated network, where possible, can improve security 2308 even further. In any case, the use of open Collecting Processes 2309 (those which will accept IPFIX Messages from any Exporting Process 2310 regardless of IP address or identity) is discouraged. 2312 Modern TCP and SCTP implementations are resistent to blind insertion 2313 attacks (see [RFC1948], [RFC2960]); however, UDP offers no such 2314 protection. For this reason, IPFIX Message traffic transported via 2315 UDP and not secured via DTLS SHOULD be protected via segregation to a 2316 dedicated network. 2318 11.6 Logging an IPFIX Attack 2320 IPFIX Collecting Processes MUST detect potential IPFIX Message 2321 insertion or loss conditions by tracking the IPFIX Sequence Number, 2322 and SHOULD provide a logging mechanism for reporting out of sequence 2323 messages. Note that an attacker may be able to exploit the handling 2324 of out of sequence messages at the Collecting Process, so care should 2325 be taken in handling these conditions. For example, a Collecting 2326 Process that simply resets the expected Sequence Number upon receipt 2327 of a later Sequence Number could be temporarily blinded by deliberate 2328 injection of later Sequence Numbers. 2330 IPFIX Exporting and Collecting Processes SHOULD log any connection 2331 attempt that fails due to authentication failure, whether due to 2332 being presented an unauthorized or mismatched certificate during TLS 2333 or DTLS mutual authentication, or due to a connection attempt from an 2334 unauthorized IP address when TLS or DTLS are not in use. 2336 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2337 SCTP association reset or TCP connection reset. 2339 11.7 Securing the Collector 2341 The security of the Collector and its implementation is important to 2342 achieve overall security. However, it is outside the scope of this 2343 document. 2345 12. IANA Considerations 2347 IPFIX Messages use two fields with assigned values. These are the 2348 IPFIX Version Number, indicating which version of the IPFIX Protocol 2349 was used to export an IPFIX Message, and the IPFIX Set ID, 2350 indicating the type for each set of information within an IPFIX 2351 Message. 2353 The IPFIX Version Number value of 10 is reserved for the IPFIX 2354 Protocol specified in this document. Set ID values of 0 and 1 are 2355 not used for historical reasons [RFC3954]. The Set ID value of 2 is 2356 reserved for the Template Set. The Set ID value of 3 is reserved 2357 for the Option Template Set. All other Set ID values from 4 to 255 2358 are reserved for future use. Set ID values above 255 are used for 2359 Data Sets. 2361 New assignments in either IPFIX Version Number or IPFIX Set ID 2362 assignments require a Standards Action [RFC2434], i.e. they are to 2363 be made via Standards Track RFCs approved by the IESG. 2365 13. Appendix A 2367 This appendix, which is a not a normative reference, contains IPFIX 2368 encoding examples. 2370 Let's consider the example of an IPFIX Message composed of a 2371 Template Set, a Data Set (which contains three Data Records), an 2372 Options Template Set and a Data Set (which contains 2 Data Records 2373 related to the previous Options Template Record). 2375 IPFIX Message: 2377 +--------+------------------------------------------. . . 2378 | | +--------------+ +------------------+ 2379 |Message | | Template | | Data | 2380 | Header | | Set | | Set | . . . 2381 | | | (1 Template) | | (3 Data Records) | 2382 | | +--------------+ +------------------+ 2383 +--------+------------------------------------------. . . 2385 . . .-------------------------------------------+ 2386 +------------------+ +------------------+ | 2387 | Options | | Data | | 2388 . . . | Template Set | | Set | | 2389 | (1 Template) | | (2 Data Records) | | 2390 +------------------+ +------------------+ | 2391 . . .-------------------------------------------+ 2393 13.1 Message Header Example 2395 The Message Header is composed of: 2396 0 1 2 3 2397 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 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Version = 0x000a | Length = 152 | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Export Time | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Sequence Number | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | Observation Domain ID | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 13.2 Template Set Examples 2410 13.2.1 Template Set using IETF specified Information Elements 2412 We want to report the following Information Elements: 2414 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], 2415 with a length of 4 octets 2416 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2417 INFO], with a length of 4 octets 2418 - The next-hop IP address (IPv4): ipNextHopIPv4Address in [IPFIX- 2419 INFO], with a length of 4 octets 2421 - The number of packets of the Flow: inPacketDeltaCount in [IPFIX- 2422 INFO], with a length of 4 octets 2424 - The number of octets of the Flow: inOctetDeltaCount in [IPFIX- 2425 INFO], with a length of 4 octets 2427 Therefore, the Template Set will be composed of the following: 2429 0 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Set ID = 2 | Length = 28 octets | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Template ID 256 | Field Count = 5 | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 |0| sourceIPv4Address = 8 | Field Length = 4 | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 |0| destinationIPv4Address = 12 | Field Length = 4 | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 |0| inPacketDeltaCount = 2 | Field Length = 4 | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 |0| inOctetDeltaCount = 1 | Field Length = 4 | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 13.2.2 Template Set using enterprise-specific Information Elements 2449 We want to report the following Information Elements: 2451 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], 2452 with a length of 4 octets 2454 - The IPv4 destination IP address: destinationIPv4Address in 2455 [IPFIX-INFO], with a length of 4 octets 2457 - An enterprise-specific Information Element representing 2458 proprietary information, with a type of 15 and a length of 4 2460 - The number of packets of the Flow: inPacketDeltaCount in 2461 [IPFIX-INFO], with a length of 4 octets 2463 - The number of octets of the Flow: inOctetDeltaCount in 2464 [IPFIX-INFO], with a length of 4 octets 2466 Therefore, the Template Set will be composed of the following: 2468 0 1 2 3 2469 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 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | Set ID = 2 | Length = 32 octets | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Template ID 257 | Field Count = 5 | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 |0| sourceIPv4Address = 8 | Field Length = 4 | 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 |0| destinationIPv4Address = 12 | Field Length = 4 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 |1| Information Element Id. = 15| Field Length = 4 | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Enterprise number | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 |0| inPacketDeltaCount = 2 | Field Length = 4 | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 |0| inOctetDeltaCount = 1 | Field Length = 4 | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 13.3 Data Set Example 2490 In this example, we report the following three Flow Records: 2492 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2493 | | | Number | Number 2494 ------------------------------------------------------------------ 2495 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2496 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2497 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2499 0 1 2 3 2500 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 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 | Set ID = 256 | Length = 64 | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | 192.0.2.12 | 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | 192.0.2.254 | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | 192.0.2.1 | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | 5009 | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | 5344385 | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | 192.0.2.27 | 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | 192.0.2.23 | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | 192.0.2.2 | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | 748 | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | 388934 | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 | 192.0.2.56 | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | 192.0.2.65 | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | 192.0.2.3 | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | 5 | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | 6534 | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Note that padding is not necessary in this example. 2537 13.4 Options Template Set Examples 2539 13.4.1 Options Template Set using IETF specified Information Elements 2541 Per line card (the router being composed of two line cards), we want 2542 to report the following Information Elements: 2544 - Total number of IPFIX Messages: exportedPacketCount 2545 [IPFIX-INFO], with a length of 2 octets 2547 - Total number of exported Flows: exportedFlowCount [IPFIX-INFO], 2548 with a length of 2 octets 2550 The line card, which is represented by the lineCardId Information 2551 Element [IPFIX-INFO], is used as the Scope Field. 2553 Therefore, the Options Template Set will be: 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Set ID = 3 | Length = 24 | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Template ID 258 | Field Count = 3 | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Scope Field Count = 1 |0| lineCardId = 141 | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | Scope 1 Field Length = 4 |0| exportedPacketCount = 41 | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Field Length = 2 |0| exportedFlowCount = 42 | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Field Length = 2 | Padding | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 13.4.2 Options Template Set using enterprise-specific Information 2572 Elements 2573 Per line card (the router being composed of two line cards), we want 2574 to report the following Information Elements: 2576 - Total number of IPFIX Messages: exportedPacketCount 2577 [IPFIX-INFO], with a length of 2 octets 2579 - An enterprise-specific number of exported Flows, 2580 with a type of 42 and a length of 4 octets 2582 The line card, which is represented by the lineCardId Information 2583 Element [IPFIX-INFO], is used as the Scope Field. 2585 The format of the Options Template Set is as follows: 2587 0 1 2 3 2588 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 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | Set ID = 3 | Length = 28 | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | Template ID 259 | Field Count = 3 | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Scope Field Count = 1 |0| lineCardId = 141 | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | Scope 1 Field Length = 4 |0| exportedPacketCount = 41 | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | Field Length = 2 |1|Information Element Id. = 42 | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | Field Length = 4 | Enterprise number ... 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 ... Enterprise number | Padding | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 13.4.3 Options Template Set using an enterprise-specific scope 2608 In this example, we want to export the same information as in the 2609 example in section 13.4.1: 2611 - Total number of IPFIX Messages: exportedPacketCount 2612 [IPFIX-INFO], with a length of 2 octets 2614 - Total number of exported Flows: exportedFlowCount 2615 [IPFIX-INFO], with a length of 2 octets 2617 But this time, the information pertains to a proprietary scope, 2618 identified by enterprise-specific Information Element number 123. 2620 The format of the Options Template Set is now as follows: 2622 0 1 2 3 2623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | Set ID = 3 | Length = 28 | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | Template ID 260 | Field Count = 3 | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2629 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Scope 1 Field Length = 4 | Enterprise Number ... 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 ... Enterprise Number |0| exportedPacketCount = 41 | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | Field Length = 2 |0| exportedFlowCount = 42 | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | Field Length = 2 | Padding | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 13.4.4 Data Set using an enterprise-specific scope 2643 In this example, we report the following two Data Records: 2645 Line Card ID | IPFIX Message | Exported Flow Records 2646 ------------------------------------------------------------------- 2647 Line Card 1 (lineCardId=1) | 345 | 10201 2648 Line Card 2 (lineCardId=2) | 690 | 20402 2650 0 1 2 3 2651 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 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | Set ID = 260 | Length = 20 | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | 1 | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | 345 | 10201 | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | 2 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | 690 | 20402 | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 13.5 Variable length Information Element examples 2666 13.5.1 Example of Variable Length Information Element with Length 2667 inferior to 255 octets 2669 0 1 2 3 2670 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 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 | 5 | 5 octet Information Element | 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 13.5.2 Example of Variable Length Information Element with Length 255 2678 to 65535 octets 2680 0 1 2 3 2681 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 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | 255 | 1000 | IE ... | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | 1000 octet Information Element | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 : ... : 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | ... IE | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 14. References 2694 14.1 Normative References 2696 [IPFIX-INFO] Quittek, J., Bryant S., Claise, B., Meyer, J. 2697 "Information Model for IP Flow Information Export" draft-ietf-ipfix- 2698 info-15, February 2007 2700 [UDP] Postel, J., "User Datagram Protocol" RFC 768, August 1980 2702 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL 2703 SPECIFICATION" RFC 793, September 1981 2705 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2706 Specification, Implementation and Analysis", RFC 1305, May 1992 2708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2709 Requirement Levels", BCP 14, RFC 2119, March 1997 2711 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 2712 IANA Considerations Section in RFCs", RFC 2434, October 1998. 2714 [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", 2715 RFC 2960, October 2000 2717 [RFC3309] Steon, J., Stewart, R., Otis, D. "Stream Control 2718 Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2719 2002 2721 [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D. "Internet X.509 2722 Public Key Infrastructure Certificate and Certificate Revocation List 2723 (CRL) Profile", RFC 3280, April 2002 2725 [RFC3436] Rescorla, E., Tuexen, M., "Transport Layer Security over 2726 Stream Control Transmission Protocol", RFC 3436, December 2002 2728 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. 2729 "Stream Control Transmission Protocol (SCTP) Partial Reliability 2730 Extension", RFC 3758, May 2004 2732 [RFC4346] Dierks, T. and C. Allen, "The TLS Protocol Version 1.1", 2733 RFC 4346, April 2006. 2735 [RFC4347] Rescola, E., Modadugy, N. "Datagram Transport Layer 2736 Security", RFC 4347, April 2006 2738 14.2 Informative References 2740 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., 2741 "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- 2742 architecture-12, September 2006 2744 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX 2745 Applicability", draft-ietf-ipfix-as-12.txt, June 2007 2747 [PEN] IANA Private Enterprise Numbers registry 2748 http://www.iana.org/assignments/enterprise-numbers 2750 [RFC1948] Bellovin, S., "Defending Against Sequence Number 2751 Attacks", RFC 1948, May 1996 2753 [RFC2579] McCloghrie, K., et al "Textual Conventions for SMIv2", RFC 2754 2579, April 1999 2756 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., 2757 "Requirements for IP Flow Information Export" RFC 3917, October 2004 2759 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 2760 "RTP: A Transport Protocol for Real-Time Applications ", RFC 3550, 2761 July 2003 2763 [RFC3954] Claise, B., et al "Cisco Systems NetFlow Services Export 2764 Version 9", RFC 3954, October 2004 2766 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 2767 "Standard for Binary Floating-Point Arithmetic", IEEE 2768 Standard 754, August 1985 2770 [dtls-for-sctp], Tuexen, M., Hohendorf, C., Rescola, E., "Datagram 2771 Transport Layer Security for Stream Control Transmission Protocol", 2772 draft-tuexen-dtls-for-sctp-01.txt, October 2006 2774 15. Acknowledgments 2776 We would like to thank the following persons: Ganesh Sadasivan for 2777 his significant contribution during the initial phases of the 2778 protocol specification, Juergen Quittek for the coordination job 2779 within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, 2780 and Andrew Johnson for the thorough reviews; Randall Stewart and 2781 Peter Lei for their SCTP expertise and contributions; Martin 2782 Djernaes for the first essay on the SCTP section; Michael Behringer 2783 and Eric Vyncke for their advices and knowledge in security; Michael 2784 Tuexen for his help regarding the DTLS section; Elisa Boschi for her 2785 contribution regarding the improvement of SCTP sections; Mark 2786 Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter 2787 Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul 2788 Calato, and many more, for the technical review and feedback. 2790 Authors' Addresses 2792 Benoit Claise 2793 Cisco Systems 2794 De Kleetlaan 6a b1 2795 1831 Diegem 2796 Belgium 2797 Phone: +32 2 704 5622 2798 E-mail: bclaise@cisco.com 2800 Stewart Bryant 2801 Cisco Systems, Inc. 2802 250, Longwater, 2803 Green Park, 2804 Reading, RG2 6GB, 2805 United Kingdom 2806 Phone: +44 (0)20 8824-8828 2807 Email: stbryant@cisco.com 2809 Simon Leinen 2810 SWITCH 2811 Limmatquai 138 2812 P.O. Box 2813 CH-8021 Zurich 2814 Switzerland 2815 Phone: +41 1 268 1536 2816 EMail: simon@switch.ch 2818 Thomas Dietz 2819 NEC Europte Ltd. 2820 Network Laboratories 2821 Kurfuersten-Anlage 36 2822 69115 Heidelberg 2823 Germany 2824 Phone: +49 6221 90511-28 2825 Email: dietz@netlab.nec.de 2827 Brian H. Trammell 2828 CERT Network Situational Awareness 2829 Software Engineering Institute 2830 4500 Fifth Avenue 2831 Pittsburgh, PA 15213 2832 United States 2833 Phone: +1 412 268 9748 2834 Email: bht@cert.org 2836 16. Intellectual Property Statement 2838 The IETF takes no position regarding the validity or scope of 2839 any Intellectual Property Rights or other rights that might be 2840 claimed to pertain to the implementation or use of the 2841 technology described in this document or the extent to which any 2842 license under such rights might or might not be available; nor 2843 does it represent that it has made any independent effort to 2844 identify any such rights. Information on the procedures with 2845 respect to rights in RFC documents can be found in BCP 78 and 2846 BCP 79. 2847 Copies of IPR disclosures made to the IETF Secretariat and any 2848 assurances of licenses to be made available, or the result of an 2849 attempt made to obtain a general license or permission for the 2850 use of such proprietary rights by implementers or users of this 2851 specification can be obtained from the IETF on-line IPR 2852 repository at http://www.ietf.org/ipr. 2854 The IETF invites any interested party to bring to its attention 2855 any copyrights, patents or patent applications, or other 2856 proprietary rights that may cover technology that may be 2857 required to implement this standard. Please address the 2858 information to the IETF at ietf-ipr@ietf.org. 2860 17. Copyright Statement 2862 Copyright (C) The IETF Trust (2007). 2864 This document is subject to the rights, licenses and 2865 restrictions contained in BCP 78, and except as set forth 2866 therein, the authors retain all their rights. 2868 18. Disclaimer 2870 This document and the information contained herein are provided 2871 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2872 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 2873 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 2874 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2875 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2876 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 2877 OR FITNESS FOR A PARTICULAR PURPOSE.