idnits 2.17.1 draft-ietf-ipfix-protocol-21.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 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2685. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Finally, note that the Scope Field Count MAY NOT be zero. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Scope Field Count Number of scope fields in this Options Template Record. The Scope Fields are normal Fields except that they are interpreted as Scope at the Collector. The Scope Field Count MAY NOT be zero. == 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: The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable. A suitable default value is 5 seconds after the last Data Record has been sent. -- 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 (April 2006) is 6580 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) == Missing Reference: 'RFC1305' is mentioned on line 1282, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Missing Reference: 'RFC 2434' is mentioned on line 2202, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) -- Unexpected draft version: The latest known version of draft-ietf-ipfix-arch is -02, but you're referring to -09. -- Possible downref: Normative reference to a draft: ref. 'IPFIX-ARCH' == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-11 ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1948 (Obsoleted by RFC 6528) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-06 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-02 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 13 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-21.txt Cisco Systems 4 Expires: October 27, 2006 April 2006 6 IPFIX Protocol Specification 8 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on October 27, 2006. 31 Copyright Notice 33 Copyright (C) The Internet Society (2006). 35 Abstract 37 This document specifies the IPFIX protocol that serves for 38 transmitting IP traffic flow information over the network. In order 39 to transmit IP traffic flow information from an exporting process to 40 an information collecting process, a common representation of flow 41 data and a standard means of communicating them is required. This 42 document describes how the IPFIX data and templates records are 43 carried over a congestion-aware transport protocol from an IPFIX 44 exporting process to an IPFIX collecting process. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction..................................................4 55 1.1 IPFIX Documents Overview.....................................4 56 2. Terminology....................................................5 57 2.1 Terminology Summary Table...................................10 58 3. IPFIX Message Format..........................................10 59 3.1 Message Header Format.......................................12 60 3.2 Field Specifier Format......................................13 61 3.3 Set and Set Header Format...................................15 62 3.3.1 Set Format...............................................15 63 3.3.2 Set Header Format........................................16 64 3.4 Record Format...............................................16 65 3.4.1 Template Record Format...................................17 66 3.4.2 Options Template Record Format...........................19 67 3.4.2.1 Scope...................................................19 68 3.4.2.2 Options Template Record Format..........................20 69 3.4.3 Data Record Format.......................................22 70 4. Specific Reporting Requirements...............................23 71 4.1 The Metering Process Statistics Option Template.............24 72 4.2 The Metering Process Reliability Statistics Option Template.25 73 4.3 The Exporting Process Reliability Statistics Option Template26 74 4.4 The Flow Keys Option Template...............................27 75 5. IPFIX Message Header "Export Time" and Flow Record Time.......28 76 6. Linkage with the Information Model............................28 77 6.1 Encoding of IPFIX Data Types................................29 78 6.1.1 Integral Data Types......................................29 79 6.1.2 Address Types............................................29 80 6.1.3 float32..................................................29 81 6.1.4 float64..................................................29 82 6.1.5 boolean..................................................29 83 6.1.6 string and octetarray....................................30 84 6.1.7 dateTimeseconds..........................................30 85 6.1.8 dateTimeMilliseconds.....................................30 86 6.1.9 dateTimeNanoseconds......................................30 87 6.1.10 dateTimeMicroseconds.....................................30 88 6.2 Reduced Size Encoding of Integer and Float Types............30 90 7. Variable Length Information Element...........................31 91 8. Template Management...........................................33 92 9. The Collecting Process's Side.................................36 93 10. Transport Protocol...........................................38 94 10.1 Transport Compliance and Transport Usage...................38 95 10.2 SCTP.......................................................39 96 10.2.1 Congestion Avoidance.....................................39 97 10.2.2 Reliability..............................................39 98 10.2.3 MTU......................................................39 99 10.2.4 Exporting Process........................................40 100 10.2.4.1 Association Establishment...............................40 101 10.2.4.2 Association Shutdown....................................40 102 10.2.4.3 Stream..................................................41 103 10.2.4.4 Template Management.....................................42 104 10.2.5 Collecting Process.......................................42 105 10.2.6 Failover.................................................42 106 10.3 UDP........................................................42 107 10.3.1 Congestion Avoidance.....................................42 108 10.3.2 Reliability..............................................42 109 10.3.3 MTU......................................................43 110 10.3.4 Port Numbers.............................................43 111 10.3.5 Exporting Process........................................43 112 10.3.6 Template Management......................................43 113 10.3.7 Collecting Process.......................................44 114 10.3.8 Failover.................................................45 115 10.4 TCP........................................................45 116 10.4.1 Connection Management....................................45 117 10.4.1.1 Connection Establishment................................45 118 10.4.1.2 Graceful Connection Release.............................45 119 10.4.1.3 Restarting Interrupted Connections......................46 120 10.4.1.4 Failover................................................46 121 10.4.2 Data Transmission........................................46 122 10.4.2.1 IPFIX Message Encoding..................................46 123 10.4.2.2 Templates...............................................47 124 10.4.2.3 Congestion Handling and Reliability.....................47 125 11. Security Considerations......................................48 126 11.1 IPsec Usage................................................49 127 11.1.1 Selectors................................................49 128 11.1.2 Mode.....................................................49 129 11.1.3 Key Management...........................................49 130 11.1.4 Security Policy..........................................49 131 11.1.5 Authentication...........................................50 132 11.1.6 Availability.............................................50 133 11.2 TLS Usage..................................................50 134 11.3 Protection against DoS attacks.............................50 135 11.4 When IPsec or TLS is not an option.........................51 136 11.5 Logging an IPFIX Attack....................................51 137 12. IANA Considerations..........................................52 138 13. Appendix A...................................................52 139 13.1 Message Header Example.....................................53 140 13.2 Template Set Examples......................................53 141 13.2.1 Template Set using IETF specified Information Elements...53 142 13.2.2 Template Set using Enterprise Specific Information 143 Elements.........................................................54 144 13.3 Data Set Example...........................................55 145 13.4 Options Template Set Examples..............................56 146 13.4.1 Options Template Set using IETF specified Information 147 Elements.........................................................56 148 13.4.2 Options Template Set using enterprise-specific 149 Information Elements.............................................57 150 13.4.3 Options Template Set using an enterprise-specific scope..58 151 13.4.4 Data Set using an enterprise-specific scope..............59 152 13.5 Variable length Information Element examples...............59 153 13.5.1 Example of Variable Length Information Element with 154 Length inferior to 255 octets....................................59 155 13.5.2 Example of Variable Length Information Element with 156 Length 255 to 65535 octets.......................................59 157 14. References...................................................60 158 14.1 Normative References.......................................60 159 14.2 Informative References.....................................61 160 15. Acknowledgments..............................................61 162 1. Introduction 164 A data network with IP traffic, primarily consists of IP Flows 165 passing through the network elements of the network. It is often 166 interesting, useful or even a requirement to have access to 167 information about these flows that pass through the network elements 168 for administrative or other purposes. The IPFIX collecting process 169 should be able to receive the flow information passing through 170 multiple network elements within the data network. This requires 171 uniformity in the method of representing the flow information and 172 the means of communicating the flows from the network elements to 173 the collection point. This document specifies the protocol to 174 achieve these aforementioned requirements. This document specifies 175 in detail the representation of different flows, the additional data 176 required for flow interpretation, packet format, transport 177 mechanisms used, security concerns, etc. 179 1.1 IPFIX Documents Overview 181 The IPFIX protocol provides network administrators with access to IP 182 flow information. The architecture for the export of measured IP 183 flow information out of an IPFIX exporting process to a collecting 184 process is defined in [IPFIX-ARCH], per the requirements defined in 185 [RFC3917]. This document specifies how IPFIX data record and 186 templates are carried via a congestion-aware transport protocol from 187 IPFIX exporting processes to IPFIX collecting process. IPFIX has a 188 formal description of IPFIX information elements, their name, type 189 and additional semantic information, as specified in [IPFIX-INFO]. 190 Finally [IPFIX-AS] describes what type of applications can use the 191 IPFIX protocol and how they can use the information provided. It 192 furthermore shows how the IPFIX framework relates to other 193 architectures and frameworks. 195 2. Terminology 197 The definitions of the basic terms like IP Traffic Flow, Exporting 198 Process, Collecting Process, Observation Points, etc. are 199 semantically identical with those found in the IPFIX requirements 200 document [RFC3917]. Some of the terms have been expanded for more 201 clarity when defining the protocol. Additional terms required for 202 the protocol has also been defined. Definitions in this document 203 and in [IPFIX-ARCH] are equivalent, except that definitions which 204 are only relevant to the IPFIX protocol only appear here. 206 The terminology summary table in Section 2.1 gives a quick overview 207 of the relationships between some of the different terms defined. 209 Observation Point 211 An Observation Point is a location in the network where IP packets 212 can be observed. Examples include: a line to which a probe is 213 attached, a shared medium, such as an Ethernet-based LAN, a single 214 port of a router, or a set of interfaces (physical or logical) of a 215 router. 217 Note that every Observation Point is associated with an Observation 218 Domain (defined below), and that one Observation Point may be a 219 superset of several other Observation Points. For example one 220 Observation Point can be an entire line card. That would be the 221 superset of the individual Observation Points at the line card's 222 interfaces. 224 Observation Domain 225 An Observation Domain is the largest set of Observation Points for 226 which Flow information can be aggregated by a Metering Process. For 227 example, a router line card may be an Observation Domain if it is 228 composed of several interfaces, each of which is an Observation 229 Point. In the IPFIX Message it generates, the Observation Domain 230 includes its Observation Domain ID, which is unique per Exporting 231 Process. That way, the Collecting Process can identify the specific 232 Observation Domain from the Exporter that sends the IPFIX Messages. 233 Every Observation Point is associated with an Observation Domain. 235 IP Traffic Flow or Flow 237 There are several definitions of the term 'flow' being used by the 238 Internet community. Within the context of IPFIX we use the 239 following definition: 241 A Flow is defined as a set of IP packets passing an Observation 242 Point in the network during a certain time interval. All packets 243 belonging to a particular Flow have a set of common properties. 244 Each property is defined as the result of applying a function to the 245 values of: 247 1. one or more packet header field (e.g. destination IP address), 248 transport header field (e.g. destination port number), or 249 application header field (e.g. RTP header fields [RFC1889]) 251 2. one or more characteristics of the packet itself (e.g. number 252 of MPLS labels, etc...) 254 3. one or more of fields derived from packet treatment (e.g. next 255 hop IP address, the output interface, etc...) 257 A packet is defined to belong to a Flow if it completely satisfies 258 all the defined properties of the Flow. 260 This definition covers the range from a Flow containing all packets 261 observed at a network interface to a Flow consisting of just a 262 single packet between two applications. It includes packets 263 selected by a sampling mechanism. 265 Flow Key 267 Each of the fields which 268 1. Belong to the packet header (e.g. destination IP address) 270 2. Are a property of the packet itself (e.g. packet length) 272 3. Are derived from packet treatment (e.g. AS number) 274 and which are used to define a Flow are termed Flow Keys. 276 Flow Record 278 A Flow Record contains information about a specific Flow that was 279 observed at an Observation Point. A Flow Record contains measured 280 properties of the Flow (e.g. the total number of bytes for all the 281 Flow's packets) and usually characteristic properties of the Flow 282 (e.g. source IP address). 284 Metering Process 286 The Metering Process generates Flow Records. Inputs to the process 287 are packet headers and characteristics observed at an Observation 288 Point, and packet treatment at the Observation Point (for example 289 the selected output interface). 291 The Metering Process consists of a set of functions that includes 292 packet header capturing, timestamping, sampling, classifying, and 293 maintaining Flow Records. 295 The maintenance of Flow Records may include creating new records, 296 updating existing ones, computing Flow statistics, deriving further 297 Flow properties, detecting Flow expiration, passing Flow Records to 298 the Exporting Process, and deleting Flow Records. 300 Exporting Process 302 The Exporting Process sends Flow Records to one or more Collecting 303 Processes. The Flow Records are generated by one or more Metering 304 Processes. 306 Exporter 308 A device which hosts one or more Exporting Processes is termed an 309 Exporter. 311 IPFIX Device 313 An IPFIX Device hosts at least one Observation Point, a Metering 314 Process and an Exporting Process. 316 Collecting Process 318 A Collecting Process receives Flow Records from one or more 319 Exporting Processes. The Collecting Process might process or store 320 received Flow Records, but such actions are out of scope for this 321 document. 323 Collector 325 A device which hosts one or more Collecting Processes is termed a 326 Collector. 328 Template 330 Template is an ordered sequence of pairs, used to 331 completely specify the structure and semantics of a particular set 332 of information that needs to be communicated from an IPFIX Device to 333 a Collector. Each Template is uniquely identifiable by means of a 334 Template ID. 336 IPFIX Message 338 An IPFIX Message is a message originating at the Exporting Process 339 that carries the IPFIX records of this Exporting Process and whose 340 destination is a Collecting Process. An IPFIX Message is 341 encapsulated at the transport layer. 343 Message Header 345 The Message Header is the first part of an IPFIX Message, which 346 provides basic information about the message such as the IPFIX 347 version, length of the message, message sequence number, etc. 349 Template Record 351 A Template Record defines the structure and interpretation of fields 352 in a Data Record. 354 Data Record 356 A Data Record is a record that contains values of the parameters 357 corresponding to a Template Record. 359 Options Template Record 361 An Options Template Record is a Template Record that defines the 362 structure and interpretation of fields in a Data Record, including 363 defining how to scope the applicability of the Data Record. 365 Set 367 Set is a generic term for a collection of records that have a 368 similar structure. In an IPFIX Message, one or more Sets follow the 369 Message Header. 371 There are three different types of Sets: Template Set, Options 372 Template Set, and Data Set. 374 Template Set 376 A Template Set is a collection of one or more Template Records that 377 have been grouped together in an IPFIX Message. 379 Options Template Set 381 An Options Template Set is a collection of one or more Options 382 Template Records that have been grouped together in an IPFIX 383 Message. 385 Data Set 387 A Data Set is one or more Data Records, of the same type, that are 388 grouped together in an IPFIX Message. Each Data Record is 389 previously defined by a Template Record or an Options Template 390 Record. 392 Information Element 394 An Information Element is a protocol and encoding independent 395 description of an attribute which may appear in an IPFIX Record. 396 The IPFIX information model [IPFIX-INFO] defines the base set of 397 Information Elements for IPFIX. The type associated with an 398 Information Element indicates constraints on what it may contain and 399 also determines the valid encoding mechanisms for use in IPFIX. 401 2.1 Terminology Summary Table 403 +------------------+---------------------------------------------+ 404 | | Contents | 405 | +--------------------+------------------------+ 406 | Set | Template | Record | 407 +------------------+--------------------+------------------------+ 408 | Data Set | / | Data Record(s) | 409 +------------------+--------------------+------------------------+ 410 | Template Set | Template Record(s) | / | 411 +------------------+--------------------+------------------------+ 412 | Options Template | Options Template | / | 413 | Set | Record(s) | | 414 +------------------+--------------------+------------------------+ 416 Figure A: Terminology Summary Table 418 A Data Set is composed of Data Record(s). No Template Record is 419 included. A Template Record or an Options Template Record defines 420 the Data Record. 422 A Template Set contains only Template Record(s). 424 An Options Template Set contains only Options Template Record(s). 426 3. IPFIX Message Format 428 An IPFIX Message consists of a Message Header followed by one or 429 more Sets. The Sets can be any of the possible three types: Data 430 Set, Template Set or Options Template Set. 432 The format of the IPFIX Message is shown in Figure B. 434 +----------------------------------------------------+ 435 | Message Header | 436 +----------------------------------------------------+ 437 | Set | 438 +----------------------------------------------------+ 439 | Set | 440 +----------------------------------------------------+ 441 ... 442 +----------------------------------------------------+ 443 | Set | 444 +----------------------------------------------------+ 446 Figure B: IPFIX Message format 448 The Exporter MUST code all binary integers of the Message Header and 449 the different Sets in network byte order (also known as the big- 450 endian byte ordering). 452 Following are some examples of IPFIX Messages: 454 1. An IPFIX Message consisting of interleaved Template, Data, and 455 Options Template Sets - A newly created Template is exported as soon 456 as possible. So if there is already an IPFIX Message with a Data 457 Set that is being prepared for export, the Template and Option 458 Template Sets are interleaved with this information, subject to 459 availability of space. 461 +--------+--------------------------------------------------------+ 462 | | +----------+ +---------+ +-----------+ +---------+ | 463 |Message | | Template | | Data | | Options | | Data | | 464 | Header | | Set | | Set | ... | Template | | Set | | 465 | | | | | | | Set | | | | 466 | | +----------+ +---------+ +-----------+ +---------+ | 467 +--------+--------------------------------------------------------+ 469 Figure C: IPFIX Message example 1 471 2. An IPFIX Message consisting entirely of Data Sets - After the 472 appropriate Template Records have been defined and transmitted to 473 the Collecting Process, the majority of IPFIX Messages consist 474 solely of Data Sets. 476 +--------+----------------------------------------------+ 477 | | +---------+ +---------+ +---------+ | 478 |Message | | Data | | Data | | Data | | 479 | Header | | Set | ... | Set | ... | Set | | 480 | | +---------+ +---------+ +---------+ | 481 +--------+----------------------------------------------+ 482 Figure D: IPFIX Message example 2 484 3. An IPFIX Message consisting entirely of Template and Options 485 Template Sets. 487 +--------+-------------------------------------------------+ 488 | | +----------+ +----------+ +----------+ | 489 |Message | | Template | | Template | | Options | | 490 | Header | | Set | ... | Set | ... | Template | | 491 | | | | | | | Set | | 492 | | +----------+ +----------+ +----------+ | 493 +--------+-------------------------------------------------+ 495 Figure E: IPFIX Message example 3 497 3.1 Message Header Format 499 The format of the IPFIX Message Header is shown in Figure F. 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Version Number | Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Export Time | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sequence Number | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Observation Domain ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure F: IPFIX Message Header format 515 Message Header Field Descriptions 517 Version 518 Version of Flow Record format exported in this message. The 519 value of this field is 0x000a for the current version, 520 incrementing by one the version used in the NetFlow services 521 export version 9 [RFC3954]. 523 Length 524 Total length of the IPFIX Message, measured in octets, 525 including Message Header and Set(s). 527 Export Time 528 Time in seconds since 0000 UTC Jan 1st 1970, at which the 529 IPFIX Message Header leaves the Exporter. 531 Sequence Number 532 Incremental sequence counter modulo 2^32 of all IPFIX Data 533 Records sent on this stream from the current Observation 534 Domain by the Exporting Process. This value SHOULD be used 535 by the Collecting Process to identify whether any IPFIX Data 536 Records have been missed. Template and Options Template 537 Records do not increase the Sequence Number. 539 Observation Domain ID 540 A 32-bit identifier of the Observation Domain that is 541 locally unique to the Exporting Process. The Exporting 542 Process uses the Observation Domain ID to uniquely identify 543 to the Collecting Process the Observation Domain that 544 metered the Flows. Collecting Processes SHOULD use the 545 combination of the Exporter (exporterIPv4Address, 546 exporterIPv6Address, or exportingProcessId) and the 547 Observation Domain ID field to separate different export 548 streams originating from the same Exporting Process. The 549 Observation Domain ID SHOULD be 0 when no specific 550 Observation Domain ID is relevant for the entire IPFIX 551 Message. For example, when exporting the Exporting Process 552 Statistics, or in case of hierarchy of Collector when 553 aggregated data records are exported. 555 3.2 Field Specifier Format 557 Vendors need the ability to define proprietary Information Elements, 558 because, for example, they are delivering a pre-standards product, 559 or the Information Element is in some way commercially sensitive. 560 This section describes the Field Specifier format for both IETF 561 specified Information Elements [IPFIX-INFO] and enterprise-specific 562 Information Elements. 564 The Information Elements are identified by the Information Element 565 identifier. When the Enterprise bit is set to 0, the corresponding 566 Information Element identifier will report an IETF specified 567 Information Element, and the Enterprise Number MUST NOT be present. 569 When the Enterprise bit is set to 1, the corresponding Information 570 Element identifier will report an enterprise-specific Information 571 Element and the Enterprise Number MUST be present. An example of 572 this is shown in section 13.4.2 574 The Field Specifier format is shown in Figure G. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |E| Information Element ident. | Field Length | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Enterprise Number | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure G: Field Specifier format 586 Where: 588 E 589 Enterprise bit. This is the first bit of the Field 590 Specifier. If this bit is zero, the Information Element 591 Identifier identifies an IETF specified Information Element, 592 and the four octet Enterprise Number field MUST NOT be 593 present. If this bit is one, the Information Element 594 identifier identifies an enterprise-specific Information 595 Element, and the Enterprise Number filed MUST be present. 597 Information Element identifier 598 A numeric value that represents the type of the Information 599 Element. Refer to [IPFIX-INFO]. 601 Field Length 602 The length of the corresponding encoded Information Element, 603 in octets. Refer to [IPFIX-INFO]. The field length may be 604 smaller than the definition in [IPFIX-INFO] if reduced size 605 encoding is used (see section 6.2). The value 65535 is 606 reserved for variable length Information Element (see 607 section 7). 609 Enterprise Number 610 IANA enterprise number [PEN] of the authority defining the 611 Information Element identifier in this Template Record. 613 3.3 Set and Set Header Format 615 A Set is a generic term for a collection of records that have a 616 similar structure. There are three different types of Sets: 617 Template Sets, Options Template Sets, and Data Sets. Each of these 618 Sets consists of a Set Header and one or more Records. The Set 619 Format and the Set Header Format are defined in the following 620 sections. 622 3.3.1 Set Format 624 A Set has the format shown in figure H. The records types can be 625 either Template Records, Options Template Records or Data Records. 626 The record types MUST NOT be mixed within a Set. 628 +--------------------------------------------------+ 629 | Set Header | 630 +--------------------------------------------------+ 631 | record | 632 +--------------------------------------------------+ 633 | record | 634 +--------------------------------------------------+ 635 ... 636 +--------------------------------------------------+ 637 | record | 638 +--------------------------------------------------+ 639 | Padding (opt.) | 640 +--------------------------------------------------+ 642 Figure H: Set Format 644 The Set Field Definitions are as follows: 646 Set Header 647 The Set Header Format is defined in section 3.3.2. 649 Record 650 One of the Record Formats: Template Record or Options Template 651 Record or Data Record Format. 653 Padding 654 The Exporting Process MAY insert some padding octets, so that 655 the subsequent Set starts at an aligned boundary. For 656 security reasons, the padding octet(s) MUST be composed of 657 zero (0) valued octets. The padding length MUST be shorter 658 than any allowable Record in this Set. If padding of the 659 IPFIX Message is desired in combination with very short 660 Records, then the padding Information Element 'paddingOctets' 661 [IPFIX-INFO] can be used for padding Records such that their 662 length is increased to a multiple of 4 or 8 octets. Because 663 Template Sets are always 4-octet aligned by definition, 664 padding is only needed in case of other alignments e.g. on 8- 665 octet boundaries. 667 3.3.2 Set Header Format 669 Every Set contains a common header. This header is defined in figure 670 I. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Set ID | Length | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure I: Set Header Format 680 The Set Header Field Definitions are as follows: 682 Set ID 683 Set ID value identifies the Set. A value of 2 is reserved for 684 the Template Set. A value of 3 is reserved for the Option 685 Template Set. All other values from 4 to 255 are reserved 686 for future use. Values above 255 are used for Data Sets. The 687 Set ID values of 0 and 1 are not used for historical reasons 688 [RFC3954]. 690 Length 691 Total length of the Set in octets including the Set Header, 692 all records and the optional padding. Because an individual 693 Set MAY contain multiple records, the Length value MUST be 694 used to determine the position of the next Set. 696 3.4 Record Format 697 IPFIX defines three record formats, defined in the next sections: 698 the Template Record Format, the Options Template Record Format and 699 the Data Record Format. 701 3.4.1 Template Record Format 703 One of the essential elements in the IPFIX record format is the 704 Template Record. Templates greatly enhance the flexibility of the 705 record format because they allow the Collecting Process to process 706 IPFIX Messages without necessarily knowing the interpretation of all 707 Data Records. A Template Record contains any combination of IANA- 708 assigned and/or enterprise-specific Information Elements 709 identifiers. 711 The format of the Template Record is shown in Figure J. It consists 712 of a Template Record Header and one or more Field Specifiers. The 713 definition of the Field Specifiers is given in figure G above. 715 +--------------------------------------------------+ 716 | Template Record Header | 717 +--------------------------------------------------+ 718 | Field Specifier | 719 +--------------------------------------------------+ 720 | Field Specifier | 721 +--------------------------------------------------+ 722 ... 723 +--------------------------------------------------+ 724 | Field Specifier | 725 +--------------------------------------------------+ 727 Figure J: Template Record Format 729 The format of the Template Record Header is shown in Figure K. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Template ID (> 255) | Field Count | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Figure K: Template Record Header Format 739 The Template Record Header Field Definitions are as follows: 741 Template ID 742 Each of the newly generated Template Records is given a unique 743 Template ID. This uniqueness is local to the Observation 744 Domain that generated the Template ID. Template IDs 0-255 are 745 reserved for Template Sets, Options Template Sets, and other 746 reserved Sets yet to be created. Template IDs of Data Sets 747 are numbered from 256 to 65535. There are no constraints 748 regarding the order of the Template ID allocation. 750 Field Count 751 Number of fields in this Template Record. 753 The example in Figure L shows a Template Set with mixed standard and 754 enterprise-specific Information Elements. It consists of Set Header, 755 Template Header and several Field Specifiers. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Set ID = 2 | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Template ID = 256 | Field Count = N | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |1| Information Element id. 1.1 | Field Length 1.1 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Enterprise Number 1.1 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |0| Information Element id. 1.2 | Field Length 1.2 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | ... | ... | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 |1| Information Element id. 1.N | Field Length 1.N | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Enterprise Number 1.N | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Template ID = 257 | Field Count = M | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |0| Information Element id. 2.1 | Field Length 2.1 | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |1| Information Element id. 2.2 | Field Length 2.2 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Enterprise Number 2.2 | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | ... | ... | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 |1| Information Element id. 2.M | Field Length 2.M | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Enterprise Number 2.M | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Padding (opt) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Figure L: Template Set Example 795 Information Element Identifiers 1.2 and 2.1 are defined by the IETF 796 (Enterprise bit = 0) and therefore do not need an Enterprise Number 797 to identify them. 799 3.4.2 Options Template Record Format 801 Thanks to the notion of scope, The Options Template Record gives the 802 Exporter the ability to provide additional information to the 803 Collector which would not be possible with Flow Records alone. 805 One Options Template Record example is the "Flow Keys", which 806 reports the Flow Keys for a template, which is defined as the scope. 807 Another example is the "Template configuration", which reports the 808 configuration sampling parameter(s) for the template, which is 809 defined as the scope. 811 3.4.2.1 Scope 813 The scope, which is only available in the Options Template Set, 814 gives the context of the reported Information Elements in the Data 815 Records. Note that the IPFIX Message Header already contains the 816 Observation Domain ID (the identifier of the Observation Domain). If 817 not zero, this Observation Domain ID can be considered as an 818 implicit scope for the Data Records in the IPFIX Message. The 819 Observation Domain ID MUST be zero when the IPFIX Message contains 820 data records with different Observation Domain ID values defined as 821 scopes. 823 Multiple scope fields MAY be present in the Options Template Record, 824 in which case, the composite scope is the combination of the scopes. 825 For example, if the two scopes are defined as "metering process" and 826 "template", the combined scope is this template for this metering 827 process. The order of the scope fields, as defined in the Options 828 Template Record, is irrelevant in this case. However, if the order 829 of the scope fields in the Options Template Record is relevant, the 830 order of the scope fields MUST be used. For example, if the first 831 scope defines the filtering function, while the second scope defines 832 the sampling function, the order of the scope is important. Applying 833 the sampling function first, followed by the filtering function, 834 would lead to potentially different Data Records than applying the 835 filtering function first, followed by the sampling function. In 836 this case, the Collector deduces the function order by looking at 837 the order of the scope in the Options Template Record. 839 The scope is an Information Element specified in the IPFIX 840 Information Model [IPFIX-INFO]. An IPFIX compliant implementation 841 of the Collecting Process SHOULD support this minimum set of 842 Information Elements as scope: LineCardId, TemplateId, 843 exporterIPv4Address, exporterIPv6Address, and ingressInterface. 844 Note that other Information Elements such as meteringProcessId, 845 exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX 846 protocol doesn't prevent the use of any Information Elements for 847 scope. However some Information Element types don't make sense if 848 specifed as scope. For example: the counter Information Elements. 850 Finally, note that the Scope Field Count MAY NOT be zero. 852 3.4.2.2 Options Template Record Format 854 An Options Template Record contains any combination of IANA-assigned 855 and/or enterprise-specific Information Elements identifiers. 857 The format of the Options Template Record is shown in Figure M. It 858 consists of an Options Template Record Header and one or more Field 859 Specifiers. The definition of the Field Specifiers is given in 860 figure G above. 862 +--------------------------------------------------+ 863 | Options Template Record Header | 864 +--------------------------------------------------+ 865 | Field Specifier | 866 +--------------------------------------------------+ 867 | Field Specifier | 868 +--------------------------------------------------+ 869 ... 870 +--------------------------------------------------+ 871 | Field Specifier | 872 +--------------------------------------------------+ 874 Figure M: Options Template Record Format 876 The format of the Options Template Record Header is shown in Figure 877 N. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Template ID (> 255) | Field Count | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Scope Field Count | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure N: Options Template Record Header Format 889 The Options Template Record Header Field Definitions are as follows: 891 Template ID 892 Template ID of this Options Template Record. This value is 893 greater than 255. 895 Field Count 896 Number of all fields in this Options Template Record, 897 including the Scope Fields. 899 Scope Field Count 900 Number of scope fields in this Options Template Record. The 901 Scope Fields are normal Fields except that they are 902 interpreted as Scope at the Collector. The Scope Field Count 903 MAY NOT be zero. 905 The example in Figure O shows an Option Template Set with mixed IETF 906 and enterprise-specific Information Elements. It consists of Set 907 Header, Option Template Header and several Field Specifiers. 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Set ID = 3 | Length | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Template ID = 258 | Field Count = N + M | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Scope 2 Field Length | ... | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | ... |1| Scope N Infor. Element Id. | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Scope N Field Length | Scope N Enterprise Number ... 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Option 1 Field Length | Option 1 Enterprise Number ... 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 ... Option 1 Enterprise Number | ... | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | ... |0| Option M Infor. Element Id. | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Option M Field Length | Padding (optional) | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Figure O: Option Template Set Example 939 3.4.3 Data Record Format 941 The Data Records are sent in Data Sets. The format of the Data 942 Record is shown in Figure P. It consists only of one or more Field 943 Values. The Template ID to which the Field Values belong is encoded 944 in the Set Header field "Set ID" i.e., "Set ID" = "Template ID". 946 +--------------------------------------------------+ 947 | Field Value | 948 +--------------------------------------------------+ 949 | Field Value | 950 +--------------------------------------------------+ 951 ... 952 +--------------------------------------------------+ 953 | Field Value | 954 +--------------------------------------------------+ 955 Figure P: Data Record Format 957 Note that Field Values do not necessarily have a length of 16 bits. 958 Field Values are encoded according to their data type specified in 959 [IPFIX-INFO]. 961 Interpretation of the Data Record format can be done only if the 962 Template Record corresponding to the Template ID is available at the 963 Collecting Process. 965 The example in Figure Q shows a Data Set. It consists of a Set 966 Header several Field Values. 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Set ID = Template ID | Length | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Record 1 - Field Value 3 | ... | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Record 2 - Field Value 3 | ... | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Record 3 - Field Value 3 | ... | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | ... | Padding (optional) | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Figure Q: Data Set, containing Data Records 990 4. Specific Reporting Requirements 992 Some specific Options Templates and Options Template Records are 993 necessary to provide extra information about the Flow Records and 994 about the Metering Process. 996 The Option Template and Options Template Records defined in these 997 sub-sections, which impose some constraints on the Metering Process 998 and Exporting Process implementations, MAY be implemented. If 999 implemented, the specific Option Templates SHOULD be implemented as 1000 specified in these sub-sections. 1002 The minimum set of Information Elements is always specified in these 1003 Specific IPFIX Options Templates. Nevertheless, extra Information 1004 Elements may be used in these specific Options Templates. 1006 4.1 The Metering Process Statistics Option Template 1008 The Metering Process Statistics Option Template specifies the 1009 structure of a Data Record for reporting Metering Process 1010 statistics. It SHOULD contain the following Information Elements 1011 that are defined in [IPFIX-INFO]: 1013 sourceId An identifier of an Observation Domain 1014 that is locally unique to the Exporting 1015 Process. This Information Element MUST 1016 be defined as a Scope Field. 1018 exportedMessageTotalCount 1019 The total number of IPFIX Messages 1020 that the Exporting Process successfully 1021 sent to the Collecting Process since 1022 the Exporting Process re- 1023 initialization. 1025 exportedFlowTotalCount The total number of Flow Records that 1026 the Exporting Process successfully sent 1027 to the Collecting Process since the 1028 Exporting Process re-initialization. 1030 exportedOctetTotalCount The total number of octets that the 1031 Exporting Process successfully sent to 1032 the Collecting Process since the 1033 Exporting Process re-initialization. 1035 The Exporting Process SHOULD export the Data Record specified by the 1036 Metering Process Statistics Option Template on a regular basis or 1037 based on some export policy. This periodicity or export policy 1038 SHOULD be configurable. 1040 Note that if several Metering Processes are available on the 1041 Exporter Observation Domain, the Information Element 1042 meteringProcessId MUST be specified as an additional Scope Field. 1044 4.2 The Metering Process Reliability Statistics Option Template 1046 The Metering Process Reliability Option Template specifies the 1047 structure of a Data Record for reporting lack of reliability in the 1048 Metering Process. It SHOULD contain the following Information 1049 Elements that are defined in [IPFIX-INFO]: 1051 sourceId An identifier of an Observation Domain 1052 that is locally unique to the Exporting 1053 Process. This Information Element MUST 1054 be defined as a Scope Field. 1056 ignoredPacketTotalCount The total number of IP packets that the 1057 Metering Process did not process. 1059 ignoredOctetTotalCount The total number of octets in observed 1060 IP packets that the Metering Process 1061 did not process. 1063 time first ignored The time stamp of the first IP packet 1064 that was ignored by the Metering 1065 Process. For this time stamp, any of 1066 the "flowStart" time stamp Information 1067 Elements flowStartMilliseconds, 1068 flowStartMicroseconds, 1069 flowStartNanoseconds, and 1070 flowStartDeltaMicroseconds can be used. 1072 time last ignored The time stamp of the last IP packet 1073 that was ignored by the Metering 1074 Process. For this time stamp, any of 1075 the "flowEnd" time stamp Information 1076 Elements flowEndMilliseconds, 1077 flowEndMicroseconds, 1078 flowEndNanoseconds, and 1079 flowEndDeltaMicroseconds can be used. 1081 The Exporting Process SHOULD export the Data Record specified by the 1082 Metering Process Reliability Statistics Option Template on a regular 1083 basis or based on some export policy. This periodicity or export 1084 policy 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.3 The Exporting Process Reliability Statistics Option Template 1092 The Exporting Process Reliability Option Template specifies the 1093 structure of a Data Record for reporting lack of reliability in the 1094 Exporting process. It SHOULD contain the following Information 1095 Elements that are defined in [IPFIX-INFO]: 1097 Exporting Process ID The identifier of the Exporting Process 1098 for which lack of reliability is 1099 reported. There are three Information 1100 Elements specified in [IPFIX-INFO] that 1101 can be used for this purpose: 1102 exporterIPv4Address, 1103 exporterIPv6Address, or 1104 exportingProcessId. This 1105 Information Element MUST be defined 1106 as a Scope Field. 1108 notSentFlowTotalCount The total number of Flows that were 1109 generated by the Metering Process and 1110 but dropped by the Metering Process or 1111 by the Exporting Process instead of 1112 sending it to the Collecting Process. 1114 notSentPacketTotalCount The total number of packets in Flow 1115 Records that were generated by the 1116 Metering Process and but dropped by 1117 the Metering Process or by the 1118 Exporting Process instead of sending 1119 it to the Collecting Process. 1121 notSentOctetTotalCount The total number of octets in packets 1122 in Flow Records that were generated by 1123 the Metering Process and but dropped 1124 by the Metering Process or by the 1125 Exporting Process instead of sending 1126 it to the Collecting Process. 1128 time first flow dropped The time stamp of the first Flow 1129 was dropped by the Metering 1130 Process. For this time stamp, any of 1131 the "flowStart" time stamp Information 1132 Elements flowStartMilliseconds, 1133 flowStartMicroseconds, 1134 flowStartNanoseconds, and 1135 flowStartDeltaMicroseconds can be used. 1137 time last flow dropped The time stamp of the last IP packet 1138 that was ignored by the Metering 1139 Process. For this time stamp, any of 1140 the "flowEnd" time stamp Information 1141 Elements flowEndMilliseconds, 1142 flowEndMicroseconds, 1143 flowEndNanoseconds, and 1144 flowEndDeltaMicroseconds can be used. 1146 The Exporting Process SHOULD export the Data Record specified by the 1147 Exporting Process Reliability Statistics Option Template on a 1148 regular basis or based on some export policy. This periodicity or 1149 export policy SHOULD be configurable. 1151 4.4 The Flow Keys Option Template 1153 The Flow Keys Option Template specifies the structure of a Data 1154 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1155 Data Record extends a particular Template Record that is referenced 1156 by its templateId identifier. The Template Record is extended by 1157 specifying which of the Information Elements contained in the 1158 corresponding Data Records describe Flow properties that server as 1159 Flow Keys of the reported Flow. 1161 The Flow Keys Option Template SHOULD contain the following 1162 Information Elements that are defined in [IPFIX-INFO]: 1164 templateId An identifier of a Template that 1165 locally unique to the Exporting 1166 Process. This Information 1167 Element MUST be defined as a Scope 1168 Field. 1170 flowKeyIndicator Bitmap with the positions of the Flow 1171 Keys in the Data Records. 1173 5. IPFIX Message Header "Export Time" and Flow Record Time 1175 The IPFIX Message Header "Export Time" field is the time in seconds 1176 since 0000 UTC Jan 1st, 1970, at which the IPFIX Message Header 1177 leaves the Exporter. The time-related Information Elements 1178 specified in [IPFIX-INFO] MAY use this "Export Time" as base time 1179 and specify an offset relative to it, instead of using a common base 1180 time, such as 0000 UTC Jan 1st, 1970. All Information Elements that 1181 do not have their base time defined by their data type, MUST have 1182 the base time clearly specified in their description. 1184 For example, Data Records requiring a microsecond precision can 1185 export the flow start and end times with the flowStartMicroseconds 1186 and flowEndMicroseconds Information Elements [IPFIX-INFO], 1187 containing the time since 0000 UTC Jan 1st 1970. An alternate 1188 solution is to export the flowStartDeltaMicroseconds and 1189 flowEndDeltaMicroseconds Information Elements [IPFIX-INFO] in the 1190 Data Record, which respectively report the flow start and end time 1191 offsets compared to the IPFIX Message Header "Export Time". The 1192 latter solution lowers the export bandwidth requirement while it 1193 increases the load on the Exporter as the Exporting Process must 1194 calculate the flowStartDeltaMicroseconds and 1195 flowEndDeltaMicroseconds of every single Data Record before 1196 exporting the IPFIX Message. 1198 It must be noted that using time-related Information Elements with 1199 offset times compared to the IPFIX Message Header "Export Time" 1200 imposes some time constraints on the Data Records contained in the 1201 IPFIX Message. In the example of flowStartDeltaMicroseconds and 1202 flowEndDeltaMicroseconds Information Elements [IPFIX-INFO], the Data 1203 Record must be exported within a maximum of 71 minutes after its 1204 creation. Otherwise, the 32-bits counter would not be sufficient to 1205 contain the flow start time offset. 1207 6. Linkage with the Information Model 1208 The Information Elements [IPFIX-INFO] MUST be sent in canonical 1209 format in network byte order (also known as the big-endian byte 1210 ordering). 1212 6.1 Encoding of IPFIX Data Types 1214 The following sections will define the encoding of the data types 1215 specified in [IPFIX-INFO]. 1217 6.1.1 Integral Data Types 1219 Integral data types - octet, signed8, unsigned16, signed16, 1220 unsigned32, signed32, signed64 and unsigned64 - MUST be encoded 1221 using the default canonical format in network byte order. Signed 1222 Integral data types are represented in two's complement notation. 1224 6.1.2 Address Types 1226 Address types - macAddress, ipv4Address and ipv6Address - MUST be 1227 encoded the same way as the integral data types. The macAddress is 1228 treated as a 6-octet integer, the ipv4Address as a 4-octet integer 1229 and the ipv6Address as a 16-octet integer. 1231 6.1.3 float32 1233 The float32 data type MUST be encoded as an IEEE single-precision 32- 1234 bit floating point-type, as specified in [IEEE.754.1985]. 1236 6.1.4 float64 1238 The float64 data type MUST be encoded as an IEEE double-precision 1239 64-bit floating point-type, as specified in [IEEE.754.1985]. 1241 6.1.5 boolean 1243 The boolean data type is specified according to the TruthValue in 1244 [RFC2579]: that is an integer with the value 1 for true and a value 1245 2 for false. Every other value is undefined. The boolean data type 1246 MUST be encoded in a single octet. 1248 6.1.6 string and octetarray 1250 The data type string represents a finite length string of valid 1251 characters of the Unicode character encoding set. The string data 1252 type MUST be encoded in UTF-8 format. The string is sent as an 1253 array of octets using an information element of fixed or variable 1254 length. The length of the information element specifies the length 1255 of the octetarray. 1257 6.1.7 dateTimeseconds 1259 The data type dateTimeseconds represents a time value in units of 1260 seconds normalised to the GMT timezone. It MUST be encoded in a 32- 1261 bit integer containing the number of seconds since 0000 UTC Jan 1st 1262 1970. The 32-bit integer allows the time encoding up to 136 years. 1264 6.1.8 dateTimeMilliseconds 1266 The data type dateTimeMilliseconds represents a time value in units 1267 of milliseconds normalized to the GMT timezone. It MUST be encoded 1268 in a 64-bit integer containing the number of milliseconds since 0000 1269 UTC Jan 1st 1970. 1271 6.1.9 dateTimeNanoseconds 1273 The data type of dateTimeNanoseconds represents a time value in 1274 units of nanoseconds normalized to the GMT timezone. It MUST be 1275 encoded in a 64-bit integer according to the NTP format given in 1276 [RFC1305]. 1278 6.1.10 dateTimeMicroseconds 1280 The data type dateTimeMicroseconds represents a time value in units 1281 of microseconds normalized to the GMT timezone. It MUST be encoded 1282 in a 64-bit integer according to the NTP format given in [RFC1305]. 1284 6.2 Reduced Size Encoding of Integer and Float Types 1286 Information Elements containing integer, string, float, and 1287 octetarray types in the information model MAY be encoded using 1288 fewer octets than those implied by their type in the information 1289 model definition [IPFIX-INFO], based on the assumption that the 1290 smaller size is sufficient to carry any value the Exporter may need 1291 to deliver. This reduces the network bandwidth requirement 1292 between the Exporter and the Collector. Note that the Information 1293 Element definitions [IPFIX-INFO] will always define the maximum 1294 encoding size. 1296 For instance the information model [IPFIX-INFO] defines byteCount as 1297 an unsigned64 type, which would require 64-bits. However if the 1298 Exporter will never locally encounter the need to send a value 1299 larger than 4294967295, it may chose to send the value instead as an 1300 unsigned32. For example, a core router would require an unsigned64 1301 byteCount while an unsigned32 might be sufficient for an access 1302 router. 1304 This behavior is indicated by the Exporter by specifying a type size 1305 with a smaller length than that associated with the assigned type of 1306 the Information Element. In the example above the Exporter would 1307 place a length of 4 versus 8 in the template. 1309 If reduced sizing is used, it MUST only be applied to the following 1310 integer types: unsigned64, signed64, unsigned32, signed32, 1311 unsigned16, signed16. The signed versus unsigned property of the 1312 reported value MUST be preserved. The reduction in size can be to 1313 any number of octets smaller than the original type if the data 1314 value still fits, i.e. so that only leading zeroes are dropped. For 1315 example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, 1316 or 1 octet(s). 1318 Reduced sizing can also be used to reduce float64 to float32. The 1319 float32 not only has a reduced number range, but due to the smaller 1320 mantissa is also less precise. 1322 The reduced size encoding MUST NOT be applied to 1323 dateTimeMicroseconds or to dateTimeNanoseconds because these 1324 represent an inherent structure that would be destroyed by using 1325 less than the original number of bytes. 1327 7. Variable Length Information Element 1329 The IPFIX template mechanism is optimized for fixed length 1330 Information Elements [IPFIX-INFO]. Where an Information Element has 1331 a variable length the following mechanism MUST be used to carry the 1332 length information, for both the IETF and proprietary Information 1333 Elements. 1335 In the Template Set the Information Element Field Length is recorded 1336 as 65535. This reserved length value notifies the Collecting 1337 Process that length of the Information Element will be carried in 1338 the Information Element content itself. 1340 In most cases the length of the Information Element will be less 1341 than 255 octets. The following length encoding mechanism optimizes 1342 the overhead of carrying the Information Element length in this 1343 majority case. The length is carried in the octet before the 1344 Information Element, as shown in Figure R. 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Length (< 255)| Information element | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | ... continuing as needed | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure R: Variable Length Information Element (length < 255 octets) 1356 If the length of the Information Element is greater than or equal to 1357 255 octets, the length is encoded into 3 octets before the 1358 Information Element. The first octet is 255 and the length is 1359 carried in the second and third octets, as shown in Figure S. 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | 255 | Length (0 to 65535) | IE | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | ... continuing as needed | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 Figure S: Variable Length Information Element 1370 (length 0 to 65535) octets 1372 The octets carrying the length (either the first or the first three 1373 octets) MUST NOT be included in the length of the Information 1374 Element. 1376 8. Template Management 1378 This section describes Template management when using SCTP and PR- 1379 SCTP as the transport protocol. Any necessary changes to Template 1380 management specifically related to TCP or UDP transport protocols 1381 are specified in section 10. 1383 The Exporting Process assigns and maintains the Template IDs for the 1384 Exporter's Observation Domains. A newly created Template Record is 1385 assigned an unused Template ID by the Exporting Process. 1387 If a specific Information Element is required by a Template but is 1388 not available in observed packets, the Exporting Process MAY choose 1389 to export Flow Records without this Information Element in a Data 1390 Record defined by a new Template. 1392 If an Information Element is required more than once in Template, 1393 the different occurrences of this Information Element SHOULD follow 1394 the logical order of their treatments by the Metering Process. For 1395 example, if a selected packet goes through two hash functions, and 1396 if the two hash values are sent within a single template, the first 1397 occurrence of the hash value should belong to the first hash 1398 function in the Metering Process. For example, when exporting the 1399 two source IP ddresses of an IPv4 in IPv4 packets, the first 1400 sourceIPv4Address Information Element occurrence should be the IPv4 1401 address of the outer header, while the second occurrence should be 1402 the inner header one. 1404 Template Sets and Option Template Sets MUST be only sent once on 1405 SCTP stream zero with full reliability. As such, the Collecting 1406 Process MUST store the Template Record information for the duration 1407 of the association so that it can interpret the corresponding Data 1408 Records that are received in subsequent Data Sets. 1410 New Template Records SHOULD be transmitted as soon as they are 1411 created. The Exporting Process MAY transmit the Template Set and 1412 Options Template Set in advance of any Data Sets that use that 1413 (Options) Template ID, to ensure that the Collector has the Template 1414 Record before receiving the first Data Record. Data Records that 1415 correspond to a Template Record MAY appear in the same and/or 1416 subsequent IPFIX Message(s). 1418 A Template ID MUST be unique per Observation Domain. Different 1419 Observation Domains from the same Exporter may use the same Template 1420 ID value to refer to different Templates. 1422 The Templates that are not used anymore SHOULD be deleted. Before 1423 reusing a Template ID, the Template MUST be deleted. In order to 1424 delete an allocated Template, the Template is withdrawn through the 1425 use of a Template Withdraw Message. 1427 The Template Withdraw Message MUST not be sent until sufficient time 1428 has elapsed to allow the Collecting Process to receive and process 1429 the last Data Record using this Template information. This time MUST 1430 be configurable. A suitable default value is 5 seconds after the 1431 last Data Record has been sent. 1433 The Template ID from a withdrawn Template MUST NOT be reused until 1434 sufficient time has elapsed to allow for the Collecting Process to 1435 receive and process the Template withdraw message. 1437 A Template Withdraw Message is a Template Record for that Template ID 1438 with a Field Count of 0. The format of the Template Withdrawal 1439 Message is shown in figure T. 1441 0 1 2 3 1442 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 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Set ID = (2 or 3) | Length = 16 | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Template ID N | Field Count = 0 | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Template ID ... | Field Count = 0 | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Template ID M | Field Count = 0 | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Figure T: Template Withdrawal Message format 1455 The Set ID field MUST contain the value 2 for Template Set 1456 withdrawal and the value 3 for Options Template Set withdrawal. 1457 Multiple Template IDs MAY be withdrawn with a single Template 1458 Withdrawal Message: in that case, padding MAY be used. 1460 The Template Withdraw Message withdraws the Template IDs for the 1461 Observation Domain ID specified in the IPFIX Message header. 1463 The Template Withdraw Message MUST NOT contain new Template or 1464 Options Template Records. 1466 If the measurement parameters change, the Template MUST be withdrawn 1467 (using a Template Withdraw Message and a new Template definition) or 1468 an unused Template ID MUST be used. Examples of the measurement 1469 changes are: a new sampling rate, a new flow expiration process, a 1470 new filtering definition, etc. If a Template is changed, a Template 1471 Withdraw Message MUST be sent to delete the Template. 1473 When the Exporting Process restarts, due to the SCTP association 1474 shutdown, all Template assignments are lost and Template IDs MUST be 1475 re-assigned. 1477 If the Metering Process restarts, the Exporting Process MUST either 1478 reuse the previously assigned Template ID for each Template, or it 1479 MUST withdraw the previously issued Template IDs by sending Template 1480 Withdraw Message(s) before reusing them. 1482 A Template Withdrawal Message to withdraw all Templates for the 1483 Observation Domain ID specified in the IPFIX Message header MAY be 1484 used. Its format is shown in figure U. 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Set ID = 2 | Length = 8 | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Template ID = 2 | Field Count = 0 | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 Figure U: All Data Templates Withdrawal Message format 1496 A Template Withdrawal Message to withdraw all Options Templates for 1497 the Observation Domain ID specified in the IPFIX Message header MAY 1498 be used. Its format is shown in figure V. 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Set ID = 3 | Length = 8 | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Template ID = 3 | Field Count = 0 | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Figure V: All Options Templates Withdrawal Message format 1510 When the SCTP association restarts, the Exporting Process MUST 1511 resend all the Template Records. 1513 9. The Collecting Process's Side 1515 This section describes the Collecting Process when using SCTP and 1516 PR-SCTP as the transport protocol. Any necessary changes to the 1517 Collecting Process specifically related to TCP or UDP transport 1518 protocols are specified in section 10. 1520 The Collecting Process SHOULD listen for a new association request 1521 from the Exporting Process. The Exporting Process will request a 1522 number of streams to use for export. A Collecting Process MUST 1523 support at least two inbound streams per association. An Exporting 1524 Process MAY ask for and support more than two streams. 1526 If the Collecting Process receives a malformed IPFIX Message, it 1527 MUST reset the SCTP association, discard the IPFIX Message, and 1528 SHOULD log the error. 1530 Template Sets and Option Template Sets are only sent once. The 1531 Collecting Process MUST store the Template Record information for 1532 the duration of the association so that it can interpret the 1533 corresponding Data Records that are received in subsequent Data 1534 Sets. 1536 Template IDs are unique per Exporting Process and per Observation 1537 Domain. If the Collecting Process receives a Template which has 1538 already been received but which has not previously been withdrawn 1539 (i.e. a Template Record from the same Exporter Observation Domain 1540 with the same Template ID), then the Collecting Process MUST 1541 shutdown the association. 1543 When an SCTP association is closed, the Collecting Process MUST 1544 discard all templates received over that association and stop 1545 decoding IPFIX Messages that use those templates. 1547 The Collecting Process normally receives Template Records from the 1548 Exporting Process before receiving Data Records. The Data Records 1549 are then decoded and stored by the Collector. If the Template 1550 Records have not been received at the time Data Records are 1551 received, the Collecting Process MAY store the Data Records for a 1552 short period of time and decode them after the Template Records are 1553 received. A Collecting Process MUST NOT assume that the Data Set 1554 and the associated Template Set (or Options Template Set) are 1555 exported in the same IPFIX Message. 1557 The Collecting Process MUST note the Information Element identifier 1558 of any Information Element that it does not understand and MAY 1559 discard that Information Element from the Flow Record. 1561 The Collector MUST accept padding in Data Records and Template 1562 Records. The padding size is the Set Length minus the size of the 1563 Set Header (4 octets for the Set ID and the Set Length), modulo the 1564 Record size deduced from the Template Record. 1566 The IPFIX protocol has a Sequence Number field in the Export header 1567 which increases with the number of IPFIX Data Records in the IPFIX 1568 Message. A Collector may detect out of sequence, dropped, or 1569 duplicate IPFIX Messages by tracking the Sequence Number. A 1570 collector SHOULD provide a logging mechanism for tracking out of 1571 sequence IPFIX Messages. Such out of sequence IPFIX Messages may be 1572 due to Exporter resource exhaustion where it can not transmit 1573 messages at their creation rate, an Exporting Process reset, 1574 congestion on the network link between the Exporter and Collector, 1575 Collector resource exhaustion where it can not process the IPFIX 1576 Messages at their arrival rate, out of order packet reception, 1577 duplicate packet reception, or an attacker injecting false messages. 1579 If a Collecting Process receives a Template Withdraw Message, the 1580 Collecting Process MUST delete the corresponding Template Records 1581 associated with the specific Exporter and specific Observation 1582 Domain, and stop decoding IPFIX Messages that use the withdrawn 1583 Templates. 1585 If the Collecting Process receives a Template Withdraw message for a 1586 Template Record it has not received before, it MUST reset the SCTP 1587 association, discard the IPFIX Message, and SHOULD log the error as 1588 it does for malformed IPFIX Messages. 1590 A Collecting Process that receives IPFIX Messages from several 1591 Observation Domains from the same Exporter MUST be aware that the 1592 uniqueness of the Template ID is not guaranteed across Observation 1593 Domains. 1595 The Collector MUST support the use of Templates containing multiple 1596 occurrences of the similar Information Elements. 1598 10. Transport Protocol 1600 The IPFIX Protocol Specification has been designed to be transport 1601 protocol independent. Note that the Exporter can export to multiple 1602 Collecting Processes, using independent transport protocols. 1604 The IPFIX Message Header 16-bit Length field limits the length of a 1605 IPFIX Message to 65535 octets including the header. A Collecting 1606 Process MUST be able to handle IPFIX Message lengths of up to 65535 1607 octets. 1609 10.1 Transport Compliance and Transport Usage 1611 We need to differentiate between what must be implemented (so that 1612 operators can interoperably deploy compliant implementations from 1613 different vendors) and what should or could be used in various 1614 operational environments. We must also make sure that ALL 1615 implementations can operate in a congestion-aware and congestion 1616 avoidance mode. 1618 SCTP [RFC2960] and PR-SCTP [RFC3758] MUST be implemented by all 1619 compliant implementations. UDP [UDP] MAY also be implemented by 1620 compliant implementations. TCP [TCP] MAY also be implemented by 1621 compliant implementations. 1623 PR-SCTP SHOULD be used in deployments where Exporters and Collectors 1624 are communicating over links that are susceptible to congestion. 1625 PR-SCTP is capable of providing any required degree of reliability. 1627 TCP MAY be used in deployments where Exporters and Collectors 1628 communicate over links that are susceptible to congestion, but PR- 1629 SCTP is preferred, due to its ability to limit back pressure on 1630 Exporters and its message versus stream orientation. 1632 UDP MAY be used although it is not a congestion aware protocol. 1633 However, the IPFIX traffic between Exporter and Collector MUST 1634 remain wholly within the administrative domains of the operators. 1636 10.2 SCTP 1638 This section describes how IPFIX can be transported over SCTP 1639 [RFC2960] using the PR-SCTP [RFC3758] extension. 1641 10.2.1 Congestion Avoidance 1643 The SCTP transport protocol provides the required level of 1644 congestion avoidance by design. 1646 SCTP will detect congestion in the end-to-end path between 1647 the IPFIX Exporting Process and the IPFIX Collecting Process, 1648 and limit the transfer rate accordingly. When an IPFIX 1649 Exporting Process has records to export, but detects that 1650 transmission by SCTP is temporarily impossible, it can either 1651 wait until sending is possible again, or it can decide to drop the 1652 record. In the latter case, the dropped export data MUST 1653 be accounted for, so that the amount of dropped export data can be 1654 reported. 1656 10.2.2 Reliability 1658 The SCTP transport protocol is by default reliable, but has the 1659 capability to operate in unreliable and partially reliable modes 1660 [RFC3758]. 1662 Using reliable SCTP streams (referred to hereafter as "streams") for 1663 the IPFIX export is not in itself a guarantee that all Data Records 1664 are delivered. If there is congestion on the link from the 1665 Exporting Process to the Collecting Process, or if a significant 1666 number of retransmissions are required, the send queues on the 1667 Exporting Process may fill up: the Exporting Process MAY either 1668 suspend export or discard the IPFIX Messages. If Data Records are 1669 discarded the sequence numbers used for export MUST reflect the loss 1670 of data. 1672 10.2.3 MTU 1673 SCTP provides the required IPFIX Message fragmentation service based 1674 on path MTU discovery. 1676 10.2.4 Exporting Process 1678 10.2.4.1 Association Establishment 1680 The IPFIX Exporting Process SHOULD initiate an SCTP association with 1681 the IPFIX Collecting Process. By default, the Collecting Process 1682 listens for connections on SCTP port 4739. By default the Exporting 1683 Process tries to connect to this port. It MUST be possible to 1684 configure both the Exporting and Collecting Processes to use a 1685 different SCTP port. 1687 The Exporting Process MAY establish more than one associations 1688 (connection "bundle" in SCTP terminology) to the Collecting Process. 1690 An Exporting Process MAY support more than one active association 1691 to different Collecting Processes (including the case of different 1692 Collecting Processes on the same host). 1694 Each SCTP stream over which TLS [TLS] will be used MUST be 1695 established as a fully reliable bidirectional stream as required by 1696 RFC 3436 [RFC3436]. 1698 10.2.4.2 Association Shutdown 1700 When an Exporting Process is shutdown, it SHOULD shutdown the SCTP 1701 association. 1703 When a Collecting Process no longer wants to receive IPFIX 1704 Messages, it SHOULD shutdown its end of the association. The 1705 Collecting Process SHOULD continue to receive and process 1706 IPFIX Messages until the Exporting Process has closed its end of the 1707 association. 1709 If TLS [TLS] is used, the Process initiating association teardown 1710 SHOULD send a close_notify alert over each TLS stream before closing 1711 the SCTP association. 1713 When a Collecting Process detects that the SCTP association has been 1714 abnormally terminated, it MUST continue to listen for a new 1715 association establishment. 1717 When an Exporting Process detects that the SCTP association to the 1718 Collecting Process is abnormally terminated, it SHOULD try to re- 1719 establish the association. 1721 Association timeouts SHOULD be configurable. 1723 10.2.4.3 Stream 1725 An Exporting Process MUST request at least two outbound streams per 1726 association. The first stream (referred to as stream zero in the 1727 rest of this document), is used to send the Template Set and the 1728 Options Template Set. Stream zero MUST be fully reliable. Data 1729 Sets MUST NOT be sent on stream zero. 1731 Depending on the application requirement, the Exporting Process 1732 selects the mode (unreliable, partially reliable, or fully reliable) 1733 of the stream, used to send the Data Sets. Unreliable mode MAY be 1734 used where the application does not require reliable transmission 1735 and the use of a retransmission queue is impractical. Only fully 1736 reliable bidirectional streams are available if TLS [TLS] is used, 1737 as required by RFC 3436 [RFC3436]. 1739 An Exporter MAY use multiple streams to export Data Sets, in some 1740 cases different applications will have different requirements in 1741 terms of reliability. In such a case, the Observation Domain MUST 1742 use the same Observation Domain ID value on all of the multiple 1743 streams it uses. 1745 Data Sets from multiple Observation Domains MUST NOT be transmitted 1746 over the same stream; the Collecting Process should however verify 1747 that the Observation Domain ID values are the expected values. 1749 When Data Sets are exported over a partially reliable stream, they 1750 SHOULD be marked for retransmission as long as there is room in the 1751 SCTP send queues. However, if the queue overflows during times of 1752 congestion or other retransmission events, the oldest Data Record 1753 that has been transmitted and marked as partially reliable should be 1754 freed and marked to be skipped per the PR-SCTP [RFC3758] 1755 specification. The freed buffer space should then be re-used for 1756 the new Data Sets being exported. 1758 10.2.4.4 Template Management 1760 When the transport protocol is SCTP the default Template Management 1761 described in Section 8 is used. 1763 10.2.5 Collecting Process 1765 When the transport protocol is SCTP, the default Collector 1766 processing described in Section 9 is used. 1768 10.2.6 Failover 1770 If the Collecting Process does not acknowledge the attempt by the 1771 Exporting Process to establish an association the Exporting Process 1772 should retry using the SCTP exponential backoff feature. The 1773 Exporter MAY log an alarm if the time to establish the association 1774 exceeds a specified threshold, configurable on the Exporter. 1776 If Collecting Process failover is supported by the Exporting Process 1777 a second SCTP association MAY be opened in advance. 1779 10.3 UDP 1781 This section describes how IPFIX can be transported over UDP 1782 [UDP] 1784 10.3.1 Congestion Avoidance 1786 UDP has no integral congestion avoidance mechanism. Its use 1787 over congestion sensitive network paths is therefore deprecated. 1788 UDP MAY be used in deployments where Exporters and Collectors 1789 always communicate over dedicated links that are not susceptible 1790 to congestion. 1792 10.3.2 Reliability 1794 UDP is not a reliable transport protocol, and cannot guarantee 1795 delivery of messages. IPFIX Messages sent from the Exporting 1796 Process to the Collecting Process using UDP may therefore be lost. 1797 UDP MUST NOT be used unless the application can tolerate some 1798 loss of IPFIX Messages. 1800 The Collecting Process could deduce the loss and reordering of IPFIX 1801 Data Records by looking at the discontinuities in the IPFIX Message 1802 sequence number. In the case of UDP, the IPFIX Message sequence 1803 number contains the total number of IPFIX Data Records received for 1804 the UDP association, prior to the receipt of this IPFIX Message, 1805 modulo 2^32. IPFIX sequence number discontinuities SHOULD be logged. 1807 Templates sent from the Exporting Process to the Collecting 1808 Process using UDP as a transport MUST be resent at regular 1809 intervals in case previous copies were lost. Implementations 1810 MAY send templates using a reliable transport protocol, and 1811 send IPFIX Data Records using UDP as the transport protocol. 1813 10.3.3 MTU 1815 The maximum size of exported messages MUST be configured such that 1816 the total packet size does not exceed the path MTU. 1818 10.3.4 Port Numbers 1820 By default, the Collecting Process listens on the UDP port 4739. By 1821 default the Exporting Process tries to connect to this port. It 1822 MUST be possible to configure both the Exporting and Collecting 1823 Processes to use a different UDP port. 1825 10.3.5 Exporting Process 1827 The Exporting Process MAY duplicate the IPFIX Message to the several 1828 Collecting Processes. 1830 10.3.6 Template Management 1832 When IPFIX uses UDP as the transport protocol, Template Sets and 1833 Option Template Sets MUST be re-sent at regular intervals. The 1834 frequency of (Options) Template transmission MUST be configurable. 1835 New Template Records SHOULD be transmitted as soon as they are 1836 created, and SHOULD be transmitted before any associated Data Record 1837 is transmitted. 1839 In the event of configuration changes, the Exporting Process SHOULD 1840 send multiple copies of the new template definitions, in different 1841 IPFIX Messages, at an accelerated rate. In such a case, it MAY 1842 transmit the changed Template Record(s) and Options Template 1843 Record(s), without any data, in advance to help ensure that the 1844 Collector will have the correct template information before 1845 receiving the first data. 1847 If the Option Template scope is defined in another Template, then 1848 both Templates SHOULD be sent in the same IPFIX Message. For 1849 example: if a Flow Key Option Template (see section 4.4) is sent in 1850 an Option Template, then the associated Template SHOULD be sent in 1851 the same IPFIX Message. 1853 Following a configuration change that can modify the interpretation 1854 of the Data Records (for example, a sampling rate change) a new 1855 Template ID MUST be used and the old Template ID MUST NOT be reused 1856 until its lifetime (see section 10.3.7) has expired. 1858 Template Withdraw Messages SHOULD NOT be sent over UDP. 1860 10.3.7 Collecting Process 1862 The Collecting Process MUST associate a lifetime with each Template 1863 received via UDP. Templates not refreshed by the Exporting Process 1864 within the lifetime are expired at the Collecting Process. If the 1865 template is not refreshed by the Exporting Process before that 1866 lifetime has expired, the Collecting Process MUST discard the 1867 Template and any current and future associated Data Records. In 1868 which case, an alarm MUST be logged. The Collecting Process MUST 1869 NOT decode any further Data Records which are associated with the 1870 expired Template. If a Template is refreshed with a Template Record 1871 that differs from the previous received Template Record, the 1872 Collecting Process SHOULD log a warning and replace the previous 1873 received Template Record with the new one. The Template lifetime at 1874 the Collecting Process MUST be at least 3 times higher that the 1875 Template refresh timeout configured on the Exporting Process. 1877 At any given time the Collecting Process SHOULD maintain the 1878 following for all the current Template Records and Options Template 1879 Records: . 1882 The Collecting Process SHOULD accept Data Records without the 1883 associated Template Record. If the Template Records have not been 1884 received at the time Data Records are received, the Collecting 1885 Process SHOULD store the Data Records for a short period of time and 1886 decode them after the Template Records are received. The short 1887 period of time MUST be lower than the Template lifetime. 1889 10.3.8 Failover 1891 Because UDP is not a connection oriented protocol, the Exporting 1892 Process is unable to determine from the transport protocol that the 1893 Collecting Process is no longer able to receive the IFPIX Messages. 1894 Therefore, it can not invoke a failover mechanism. However, the 1895 Exporting Process MAY duplicate the IPFIX Message to several 1896 Collecting Processes. 1898 10.4 TCP 1900 This section describes how IPFIX can be transported over TCP [TCP]. 1902 10.4.1 Connection Management 1904 10.4.1.1 Connection Establishment 1906 The IPFIX Exporting Process initiates a TCP connection to the 1907 Collecting Process. By default, the Collecting Process listens for 1908 connections on TCP port 4739. By default the Exporting Process tries 1909 to connect to this port. It MUST be possible to configure both the 1910 Exporting Process and the Collecting Process to use a different TCP 1911 port. 1913 An Exporting Process MAY support more than one active connection to 1914 different Collecting Processes (including the case of different 1915 Collecting Processes on the same host). 1917 The Exporter MAY log an alarm if the time to establish the 1918 connection exceeds a specified threshold, configurable on the 1919 Exporter. 1921 10.4.1.2 Graceful Connection Release 1923 When an Exporting Process is shutdown, it SHOULD shutdown the TCP 1924 connection. If TLS [TLS] is used, the Exporting Process SHOULD send 1925 a close_notify alert before closing the TCP connection. 1927 When a Collecting Process no longer wants to receive IPFIX Messages, 1928 it SHOULD close its end of the connection. The Collecting Process 1929 SHOULD continue to read IPFIX Messages until the Exporting Process 1930 has closed its end. 1932 10.4.1.3 Restarting Interrupted Connections 1934 When a Collecting Process detects that the TCP connection to the 1935 Exporting Process has terminated abnormally, it MUST continue to 1936 listen for a new connection. 1938 When an Exporting Process detects that the TCP connection to the 1939 Collecting Process has terminated abnormally, it SHOULD try to re- 1940 establish the connection. Connection timeouts and retry schedules 1941 SHOULD be configurable. In the default configuration, an Exporting 1942 Process MUST NOT attempt to establish a connection more frequently 1943 than once per minute. 1945 10.4.1.4 Failover 1947 If the Collecting Process does not acknowledge the attempt by the 1948 Exporting Process to establish an connection it will retry using the 1949 TCP exponential backoff feature. 1951 If Collecting Process failover is supported by the Exporting Process 1952 a second TCP connection MAY be opened in advance. 1954 10.4.2 Data Transmission 1956 Once a TCP connection is established, and, if configured, TLS [TLS] 1957 usage has been negotiated, the Exporting Process starts sending 1958 IPFIX Messages to the Collecting Process. 1960 10.4.2.1 IPFIX Message Encoding 1962 IPFIX Messages are sent over the TCP connection without any special 1963 encoding. The Length field in the IPFIX Message header defines the 1964 end of each IPFIX Message and thus the start of the next IPFIX 1965 Message. This means that IPFIX Messages cannot be interleaved. 1967 In the case of TCP, the IPFIX Message sequence number contains the 1968 total number of IPFIX Data Records received for the TCP connection, 1969 prior to the receipt of this IPFIX Message, modulo 2^32. 1971 If an Exporting Process exports data from multiple Observation 1972 Domains, it should be careful to choose IPFIX Message lengths 1973 appropriately to minimize head-of-line blocking between different 1974 Observation Domains. Multiple TCP connections MAY be used to avoid 1975 head-of-line between different Observation Domains. 1977 10.4.2.2 Templates 1979 For each template, the Exporting Process MUST send the Template 1980 Record before exporting Data Records that refer to that template. 1982 A Collecting Process MUST record all Template and Options Template 1983 Records for the duration of the connection, as an Exporting Process 1984 is not required to re-export Template Records. 1986 When the TCP connection restarts, the Exporting Process MUST resend 1987 all the Template Records. 1989 When an TCP connection is closed, the Collecting Process MUST 1990 discard all templates received over that connection and stop 1991 decoding IPFIX Messages that use those templates. 1993 10.4.2.3 Congestion Handling and Reliability 1995 TCP ensures reliable delivery of data from the Exporting Process to 1996 the Collecting Process. TCP also controls the rate at which data 1997 can be sent from the Exporting Process to the Collecting Process, 1998 using a mechanism that takes into account both congestion in the 1999 network and the capabilities of the receiver. 2001 Therefore an IPFIX Exporting Process may not be able to send IPFIX 2002 Messages at the rate that the Metering Process generates it, either 2003 because of congestion in the network or because the Collecting 2004 Process cannot handle IPFIX Messages fast enough. As long as 2005 congestion is transient, the Exporting Process can buffer IPFIX 2006 Messages for transmission. But such buffering is necessarily 2007 limited, both because of resource limitations and because of 2008 timeliness requirements, so ongoing and/or severe congestion may 2009 lead to a situation where the Exporting Process is blocked. 2011 When an Exporting Process has Data Records to export but the 2012 transmission buffer is full, and it wants to avoid blocking, it can 2013 decide to drop some Data Records. The dropped Data Records MUST be 2014 accounted for, so that the amount can later be exported. 2016 When an Exporting Process finds that the rate at which records 2017 should be exported is consistently higher than the rate at which TCP 2018 sending permits, it should provide back pressure to the metering 2019 processes. The metering process could then adapt by temporarily 2020 reducing the amount of data it generates, for example using sampling 2021 or aggregation. 2023 11. Security Considerations 2025 Because IPFIX can be used to collect billing information and network 2026 forensics, confusing or blinding IPFIX must be seen as a prime 2027 objective during a sophisticated network attack. 2029 If an attacker is in a position to inject false messages into an 2030 IPFIX Message stream, this will allow them to send forged Data 2031 Records or Template Records. Forged Templates may impair the 2032 Collectors ability to process any further Flow Records. Forged Flow 2033 Records would have a direct effect on the application using the 2034 Flows, for example a billing system may generate incorrect billing 2035 information. Forged options may be able to alter the meaning of 2036 Flow Records, for example if the sample rate is changed. 2038 The IPFIX Messages themselves may contain information of value to an 2039 attacker, and thus care must be taken to confine their visibility to 2040 authorized users. 2042 IPFIX Messages can be secured using IPsec. Alternatively if IPFIX 2043 runs on top of SCTP or TCP, TLS [TLS] can be used. 2045 When an Information Element containing end-user payload information 2046 is exported, it SHOULD be transmitted to the Collecting Process 2047 using a means that secures its contents against eavesdropping. 2048 Suitable mechanisms include the use of either a direct point-to- 2049 point connection or the use of an encryption mechanism. It is the 2050 responsibility of the Collecting Process to provide a satisfactory 2051 degree of security for this collected data, including, if necessary, 2052 anonymization of any reported data. 2054 11.1 IPsec Usage 2056 To secure messages between the Exporter and the Collector an IPFIX 2057 implementation MAY use IPsec. To ensure interworking between 2058 Exporters and Collectors from different vendors, the following IPsec 2059 profile MUST be supported. This profile is derived from [USEIPSEC]. 2061 11.1.1 Selectors 2063 IPFIX runs between manually configured pairs of hosts on the UDP, 2064 TCP, or SCTP transport port 4739. The appropriate selector would be 2065 Exporter-Collector pairs and port number. 2067 Note that, if the Exporter is a router, a non-interface ("loopback") 2068 address should be used. 2070 11.1.2 Mode 2072 IPsec MUST be run in transport mode. The AH and ESP MUST be 2073 supported by an IPFIX implementation of IPsec. 2075 The Authentication Header (AH) [RFC2402] MUST be used if 2076 authentication is required. The Security Protocol (ESP) [RFC2406] 2077 must be used if there is a threat to the IPFIX Message content, or 2078 if that content is confidential. 2080 Normally in situations where the ESP was required the AH would also 2081 be required. If only ESP is used, the sender's IP address MUST be 2082 checked against the IP address asserted in the key management 2083 exchange. 2085 11.1.3 Key Management 2087 In many networks, manual key management will be sufficient, and this 2088 reduces the complexity of the Exporter, albeit at a cost of greater 2089 configuration complexity. Manual key management MUST be supported. 2090 If a replay attack is considered likely, an automated key management 2091 such as the IKE [IKE] key management system SHOULD be used. 2093 11.1.4 Security Policy 2095 Connections should be accepted only from designated peers. 2097 11.1.5 Authentication 2099 Given the number of IPFIX capable Exporters that are likely to be 2100 deployed by large ISPs, there will be circumstances where shared key 2101 mechanisms are not adequate. Where an automated key management 2102 system is used, certificate-based IKE SHOULD be supported. 2104 11.1.6 Availability 2106 It is accepted that IPsec will not be universally available in IPFIX 2107 Exporters, and that where it is available, there may be issues of 2108 throughput, which may itself raise security issues. In such 2109 circumstances the other security measures described in this document 2110 provide some threat mitigation. 2112 11.2 TLS Usage 2114 The IPFIX Exporter initiating a connection acts as a TLS client 2115 according to [TLS], and an IPFIX Collector that accepts a connection 2116 acts as a TLS server. If mutual authentication is required the 2117 Collector MUST request a certificate from the Exporter, and the 2118 Exporter MUST be prepared to supply a certificate on request. 2120 11.3 Protection against DoS attacks 2122 An attacker may directly mount a DoS attack by generating large 2123 amounts of traffic. If TCP is used for transport, then the Flow to 2124 the Collector would back off due to congestion and eventually stall, 2125 blinding the IPFIX system. An attack could then proceed without 2126 further observation. PR-SCTP will have a different pathology under 2127 such an attack. Stale data at the head of the queue will get 2128 flushed giving some visibility of the attack. In case of UDP, IPFIX 2129 would reduce to some sort of sampling, meaning that some forensics 2130 may be left. 2132 To avoid blinding of the IPFIX system some mechanism for service 2133 differentiation can be used to prioritize IPFIX traffic over user 2134 traffic. An alternative is to use a dedicated network for the 2135 transport of IPFIX Messages. By sending the IPFIX Messages over a 2136 dedicated network, IPFIX Message loss induced by user traffic 2137 congestion is minimized. However an attacker may trigger the 2138 generation of excessive IPFIX Messages, and to avoid information 2139 loss during such an attack the IPFIX network must be adequately 2140 sized. 2142 11.4 When IPsec or TLS is not an option 2144 The use of IPsec or TLS might not be possible in certain cases due 2145 to performance issues. 2147 Without IPsec or TLS the only way that an IPFIX Exporter, proxy or 2148 Collector can authenticate each other is by inspecting the IP source 2149 address of the packets carrying the IPFIX Messages and their 2150 transport acknowledgments. Useful protection is gained by 2151 allocating Exporter and Collector IP addresses from ranges that are 2152 excluded from use by user traffic and hence preventing spoofing 2153 attacks by ingress packet filtering. Where large numbers of 2154 Exporters, proxies and Collectors are used in a network, it may be 2155 tempting for the administrator to not impose source IP address 2156 restrictions but this leaves a proxy or Collector open to the 2157 reception of invalid information. The use of an open proxy or 2158 Collector is therefore discouraged. 2160 If IP address spoofing can not be prevented, some level of 2161 protection against an insertion attack is required. With a modern 2162 implementation of TCP with good ISN randomization [RFC1948] or SCTP 2163 insertion such attacks are difficult without the ability to snoop 2164 the packet Flow [RFC2960]. UDP is vulnerable to insertion attacks, 2165 and SHOULD be protected by the use of the address restriction 2166 mechanism described above. 2168 The use of a dedicated network prevents IPFIX Messages from being 2169 inspected by an external attacker. 2171 11.5 Logging an IPFIX Attack 2173 A Collector may detect problems by tracking the IPFIX Sequence 2174 Number and therefore SHOULD provide a logging mechanism for tracking 2175 out of sequence messages. Such out of sequence messages may not 2176 only be caused by network congestion or Exporter/Collector resource 2177 exhaustion but also by an attacker injecting false messages. 2179 Note that an attacker may be able to exploit the behavior of the 2180 Collector when it receives an out of sequence message. For example 2181 a Collector that simply resets the expected Sequence Number upon 2182 receipt of a later message would easily be temporarily blinded by 2183 deliberately injecting messages with a much larger Sequence Number. 2185 12. IANA Considerations 2187 Considerations for assigning them are discussed in this section, 2188 using the example policies as set out in the "Guidelines for IANA 2189 Considerations" document IANA-RFC [RFC2434]. 2191 IPFIX Messages use two fields with assigned values. These are the 2192 IPFIX Version Number, indicating which version of the IPFIX Protocol 2193 was used to export an IPFIX Message, and the IPFIX Set ID, 2194 indicating the type for each set of information within an IPFIX 2195 Message. Set ID values of 0 and 1 are not used for historical 2196 reasons [RFC3954]. A value of 2 is reserved for the Template Set. 2197 A value of 3 is reserved for the Option Template Set. All other 2198 values from 4 to 255 are reserved for future use. Values above 255 2199 are used for Data Sets. 2201 Changes in either IPFIX Version Number or IPFIX Set ID assignments 2202 require an Standards Action [RFC 2434], i.e. they are to be made via 2203 Standards Track RFCs approved by the IESG. 2205 13. Appendix A 2207 This appendix, which is a not a normative reference, contains IPFIX 2208 encoding examples. 2210 Let's consider the example of an IPFIX Message composed of a 2211 Template Set, a Data Set (which contains three Data Records), an 2212 Options Template Set and a Data Set (which contains 2 Data Records 2213 related to the previous Options Template Record). 2215 IPFIX Message: 2217 +--------+------------------------------------------. . . 2218 | | +--------------+ +------------------+ 2219 |Message | | Template | | Data | 2220 | Header | | Set | | Set | . . . 2221 | | | (1 Template) | | (3 Data Records) | 2222 | | +--------------+ +------------------+ 2223 +--------+------------------------------------------. . . 2225 . . .-------------------------------------------+ 2226 +------------------+ +------------------+ | 2227 | Options | | Data | | 2228 . . . | Template Set | | Set | | 2229 | (1 Template) | | (2 Data Records) | | 2230 +------------------+ +------------------+ | 2231 . . .-------------------------------------------+ 2233 13.1 Message Header Example 2235 The Message Header is composed of: 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Version = 0x000a | Length = 152 | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Export Time | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Sequence Number | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Observation Domain ID | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 13.2 Template Set Examples 2250 13.2.1 Template Set using IETF specified Information Elements 2252 We want to report the following Information Elements: 2254 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], 2255 with a length of 4 octets 2256 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2257 INFO], with a length of 4 octets 2259 - The next-hop IP address (IPv4): ipNextHopIPv4Address in [IPFIX- 2260 INFO], with a length of 4 octets 2262 - The number of packets of the Flow: inPacketDeltaCount in [IPFIX- 2263 INFO], with a length of 4 octets 2265 - The number of octets of the Flow: inOctetDeltaCount in [IPFIX- 2266 INFO], with a length of 4 octets 2267 Therefore, the Template Set will be composed of the following: 2269 0 1 2 3 2270 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 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | Set ID = 2 | Length = 28 octets | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Template ID 256 | Field Count = 5 | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 |0| sourceIPv4Address = 8 | Field Length = 4 | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 |0| destinationIPv4Address = 12 | Field Length = 4 | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 |0| inPacketDeltaCount = 2 | Field Length = 4 | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 |0| inOctetDeltaCount = 1 | Field Length = 4 | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 13.2.2 Template Set using Enterprise Specific Information Elements 2289 We want to report the following Information Elements: 2291 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], 2292 with a length of 4 octets 2294 - The IPv4 destination IP address: destinationIPv4Address in 2295 [IPFIX-INFO], with a length of 4 octets 2297 - An enterprise-specific Information Element representing 2298 proprietary information, with a type of 15 and a length of 4 2300 - The number of packets of the Flow: inPacketDeltaCount in 2301 [IPFIX-INFO], with a length of 4 octets 2303 - The number of octets of the Flow: inOctetDeltaCount in 2304 [IPFIX-INFO], with a length of 4 octets 2306 Therefore, the Template Set will be composed of the following: 2308 0 1 2 3 2309 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 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | Set ID = 2 | Length = 32 octets | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Template ID 257 | Field Count = 5 | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 |0| sourceIPv4Address = 8 | Field Length = 4 | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 |0| destinationIPv4Address = 12 | Field Length = 4 | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 |1| Information Element Id. = 15| Field Length = 4 | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Enterprise number | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 |0| inPacketDeltaCount = 2 | Field Length = 4 | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 |0| inOctetDeltaCount = 1 | Field Length = 4 | 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 13.3 Data Set Example 2330 In this example, we report the following three Flow Records: 2332 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2333 | | | Number | Number 2334 ------------------------------------------------------------------ 2335 198.18.1.12 | 198.18.2.254 | 198.18.1.1 | 5009 | 5344385 2336 198.18.1.27 | 198.18.2.23 | 198.18.1.2 | 748 | 388934 2337 198.18.1.56 | 198.18.2.65 | 198.18.1.3 | 5 | 6534 2339 0 1 2 3 2340 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 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Set ID = 256 | Length = 64 | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | 198.18.1.12 | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | 198.18.2.254 | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | 198.18.1.1 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | 5009 | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | 5344385 | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | 198.18.1.27 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | 198.18.2.23 | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | 198.18.1.2 | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | 748 | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | 388934 | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | 198.18.1.56 | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | 198.18.2.65 | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | 198.18.1.3 | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | 5 | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | 6534 | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Note that padding is not necessary in this example. 2377 13.4 Options Template Set Examples 2379 13.4.1 Options Template Set using IETF specified Information Elements 2381 Per line card (the router being composed of two line cards), we want 2382 to report the following Information Elements: 2384 - Total number of IPFIX Messages: exportedPacketCount 2385 [IPFIX-INFO], with a length of 2 octets 2387 - Total number of exported Flows: exportedFlowCount [IPFIX-INFO], 2388 with a length of 2 octets 2390 The line card, which is represented by the lineCardId Information 2391 Element [IPFIX-INFO], is used as the Scope Field. 2393 Therefore, the Options Template Set will be: 2395 0 1 2 3 2396 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 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Set ID = 3 | Length = 24 | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | Template ID 258 | Field Count = 3 | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | Scope Field Count = 1 |0| lineCardId = 141 | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | Scope 1 Field Length = 4 |0| exportedPacketCount = 41 | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 | Field Length = 2 |0| exportedFlowCount = 42 | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | Field Length = 2 | Padding | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 13.4.2 Options Template Set using enterprise-specific Information 2412 Elements 2413 Per line card (the router being composed of two line cards), we want 2414 to report the following Information Elements: 2416 - Total number of IPFIX Messages: exportedPacketCount 2417 [IPFIX-INFO], with a length of 2 octets 2419 - An enterprise-specific number of exported Flows, 2420 with a type of 42 and a length of 4 octets 2422 The line card, which is represented by the lineCardId Information 2423 Element [IPFIX-INFO], is used as the Scope Field. 2425 The format of the Options Template Set is as follows: 2427 0 1 2 3 2428 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 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Set ID = 3 | Length = 28 | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Template ID 259 | Field Count = 3 | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Scope Field Count = 1 |0| lineCardId = 141 | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Scope 1 Field Length = 4 |0| exportedPacketCount = 41 | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Field Length = 2 |1|Information Element Id. = 42 | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | Field Length = 4 | Enterprise number ... 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 ... Enterprise number | Padding | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 13.4.3 Options Template Set using an enterprise-specific scope 2447 In this example, we want to export the same information as in the 2448 example in section 13.4.1: 2450 - Total number of IPFIX Messages: exportedPacketCount 2451 [IPFIX-INFO], with a length of 2 octets 2453 - Total number of exported Flows: exportedFlowCount 2454 [IPFIX-INFO], with a length of 2 octets 2456 But this time, the information pertains to a proprietary scope, 2457 identified by enterprise-specific Information Element number 123. 2459 The format of the Options Template Set is now as follows: 2461 0 1 2 3 2462 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 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 | Set ID = 3 | Length = 28 | 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 | Template ID 260 | Field Count = 3 | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | Scope 1 Field Length = 4 | Enterprise Number ... 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 ... Enterprise Number |0| exportedPacketCount = 41 | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Field Length = 2 |0| exportedFlowCount = 42 | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Field Length = 2 | Padding | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 13.4.4 Data Set using an enterprise-specific scope 2481 In this example, we report the following two Data Records: 2483 Line Card ID | IPFIX Message | Exported Flow Records 2484 ------------------------------------------------------------------- 2485 Line Card 1 (lineCardId=1) | 345 | 10201 2486 Line Card 2 (lineCardId=2) | 690 | 20402 2488 0 1 2 3 2489 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 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | Set ID = 260 | Length = 20 | 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | 1 | 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | 345 | 10201 | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | 2 | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | 690 | 20402 | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 13.5 Variable length Information Element examples 2504 13.5.1 Example of Variable Length Information Element with Length 2505 inferior to 255 octets 2507 0 1 2 3 2508 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 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | 5 | 5 octet Information Element | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 13.5.2 Example of Variable Length Information Element with Length 255 2516 to 65535 octets 2518 0 1 2 3 2519 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 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | 255 | 1000 | IE ... | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | 1000 octet Information Element | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 : ... : 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | ... IE | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 14. References 2532 14.1 Normative References 2534 [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., Quittek, J., 2535 "Architecture Model for IP Flow Information Export" draft-ietf-ipfix- 2536 arch-09.txt, May 2005 2538 [IPFIX-INFO] Quittek, J., Bryant S., Claise, B., Meyer, J. 2539 "Information Model for IP Flow Information Export" draft-ietf-ipfix- 2540 info-11.txt, May 2005 2542 [UDP] Postel, J., "User Datagram Protocol" RFC 768, August 1980 2544 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL 2545 SPECIFICATION" RFC 793, September 1981 2547 [RFC1948] Bellovin, S., "Defending Against Sequence Number 2548 Attacks", RFC 1948, May 1996 2550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2551 Requirement Levels", BCP 14, RFC 2119, March 1997 2553 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header ", RFC 2554 2402, November 1998 2556 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 2557 (ESP)", RFC 2406, November 1998 2559 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 2560 IANA Considerations Section in RFCs", RFC 2434, October 1998. 2562 [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", 2563 RFC 2960, October 2000 2565 [RFC3436] Rescorla, E., Tuexen, M., "Transport Layer Security over 2566 Stream Control Transmission Protocol", RFC 3436, December 2002 2568 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Conrad, P. 2569 "Stream Control Transmission Protocol (SCTP) Partial Reliability 2570 Extension", RFC 3758, May 2004 2572 14.2 Informative References 2574 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 2575 RFC 2409, November 1998. 2577 [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., Claise, B., "IPFIX 2578 Applicability", draft-ietf-ipfix-as-06.txt, May 2005 2580 [PEN] IANA Private Enterprise Numbers registry 2581 http://www.iana.org/assignments/enterprise-numbers 2583 [USEIPSEC] Bellovin, S., Guidelines for Mandating the Use of IPsec, 2584 draft-bellovin-useipsec-02.txt, October 2003, work in progress. 2586 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2587 2246, January 1999. 2589 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 2590 "RTP: A Transport Protocol for Real-Time Applications ", RFC 1889, 2591 January 1996 2593 [RFC2579] McCloghrie, K., et al "Textual Conventions for SMIv2", RFC 2594 2579, April 1999 2596 [RFC3917] Quittek, J., Zseby, T., Claise, B., Zander, S., 2597 "Requirements for IP Flow Information Export" RFC 3917, October 2004 2599 [RFC3954] Claise, B., et al "Cisco Systems NetFlow Services Export 2600 Version 9", RFC 3954, October 2004 2602 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 2603 "Standard for Binary Floating-Point Arithmetic", IEEE 2604 Standard 754, August 1985. 2606 15. Acknowledgments 2608 We would like to thank the following persons: Juergen Quittek for 2609 the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave 2610 Plonka, and Paul Aitken for the thorough reviews; Randall Stewart 2611 and Peter Lei for their SCTP expertise; Martin Djernaes for the 2612 first essay on the SCTP section; Mark Fullmer, Sebastian Zander, 2613 Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, 2614 David Moore, Brian Trammell, Robert Lowe, Paul Calato, and many 2615 more, for the technical review and feedback. 2617 Authors' Addresses 2619 Benoit Claise 2620 Cisco Systems 2621 De Kleetlaan 6a b1 2622 1831 Diegem 2623 Belgium 2624 Phone: +32 2 704 5622 2625 E-mail: bclaise@cisco.com 2627 Stewart Bryant 2628 Cisco Systems, Inc. 2629 250, Longwater, 2630 Green Park, 2631 Reading, RG2 6GB, 2632 United Kingdom 2633 Phone: +44 (0)20 8824-8828 2634 Email: stbryant@cisco.com 2636 Ganesh Sadasivan 2637 Cisco Systems, Inc. 2638 170 W. Tasman Dr. 2639 San Jose, CA 95134 2640 USA 2641 Phone: +1 (408) 527-0251 2642 Email: gsadasiv@cisco.com 2644 Simon Leinen 2645 SWITCH 2646 Limmatquai 138 2647 P.O. Box 2648 CH-8021 Zurich 2649 Switzerland 2650 Phone: +41 1 268 1536 2651 EMail: simon@switch.ch 2653 Thomas Dietz 2654 NEC Europte Ltd. 2656 Network Laboratories 2657 Kurfuersten-Anlage 36 2658 69115 Heidelberg 2659 Germany 2660 Phone: +49 6221 90511-28 2661 Email: dietz@netlab.nec.de 2663 Intellectual Property Statement 2665 The IETF takes no position regarding the validity or scope of any 2666 Intellectual Property Rights or other rights that might be claimed 2667 to pertain to the implementation or use of the technology described 2668 in this document or the extent to which any license under such 2669 rights might or might not be available; nor does it represent that 2670 it has made any independent effort to identify any such rights. 2671 Information on the procedures with respect to rights in RFC 2672 documents can be found in BCP 78 and BCP 79. 2674 Copies of IPR disclosures made to the IETF Secretariat and any 2675 assurances of licenses to be made available, or the result of an 2676 attempt made to obtain a general license or permission for the use 2677 of such proprietary rights by implementers or users of this 2678 specification can be obtained from the IETF on-line IPR repository 2679 at http://www.ietf.org/ipr. 2681 The IETF invites any interested party to bring to its attention any 2682 copyrights, patents or patent applications, or other proprietary 2683 rights that may cover technology that may be required to implement 2684 this standard. Please address the information to the IETF at ietf- 2685 ipr@ietf.org. 2687 Disclaimer of Validity 2689 This document and the information contained herein are provided on 2690 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2691 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2692 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2693 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2694 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2697 Copyright Statement 2698 Copyright (C) The Internet Society (2006). 2699 This document is subject to the rights, licenses and restrictions 2700 contained in BCP 78, and except as set forth therein, the authors 2701 retain all their rights. 2703 Acknowledgment 2705 Funding for the RFC Editor function is currently provided by the 2706 Internet Society.