idnits 2.17.1 draft-ietf-ipfix-file-03.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2496. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 24, 2008) is 5663 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-05) exists of draft-ietf-ipfix-exporting-type-02 ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft E. Boschi 4 Intended status: Standards Track Hitachi Europe 5 Expires: April 27, 2009 L. Mark 6 Fraunhofer IFAM 7 T. Zseby 8 Fraunhofer FOKUS 9 A. Wagner 10 ETH Zurich 11 October 24, 2008 13 Specification of the IPFIX File Format 14 draft-ietf-ipfix-file-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 27, 2009. 41 Abstract 43 This document describes a file format for the storage of flow data 44 based upon the IPFIX Protocol. It proposes a set of requirements for 45 flat-file, binary flow data file formats, then specifies the IPFIX 46 File format to meet these requirements based upon IPFIX Messages. 47 This IPFIX File format is designed to facilitate interoperability and 48 reusability among a wide variety of flow storage, processing, and 49 analysis tools. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Record Format Flexibility . . . . . . . . . . . . . . . . 10 60 5.2. Self Description . . . . . . . . . . . . . . . . . . . . . 10 61 5.3. Data Compression . . . . . . . . . . . . . . . . . . . . . 11 62 5.4. Indexing and Searching . . . . . . . . . . . . . . . . . . 11 63 5.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 12 64 5.6. Creator Authentication and Confidentiality . . . . . . . . 12 65 5.7. Anonymization and Obfuscation . . . . . . . . . . . . . . 13 66 5.8. Session Auditability and Replayability . . . . . . . . . . 13 67 5.9. Performance Characteristics . . . . . . . . . . . . . . . 14 68 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6.1. Storage of IPFIX-collected Flow Data . . . . . . . . . . . 14 70 6.2. Storage of NetFlow V9-collected Flow Data . . . . . . . . 14 71 6.3. Testing IPFIX Collecting Processes . . . . . . . . . . . . 15 72 6.4. IPFIX Device Diagnostics . . . . . . . . . . . . . . . . . 15 73 7. Detailed File Format Specification . . . . . . . . . . . . . . 16 74 7.1. File Reader Specification . . . . . . . . . . . . . . . . 16 75 7.2. File Writer Specification . . . . . . . . . . . . . . . . 17 76 7.3. Specific File Writer Use Cases . . . . . . . . . . . . . . 18 77 7.3.1. Collocating a File Writer with a Collecting Process . 18 78 7.3.2. Collocating a File Writer with a Metering Process . . 19 79 7.3.3. Using IPFIX Files for Archival Storage . . . . . . . . 20 80 7.3.4. Using IPFIX Files as Documents . . . . . . . . . . . . 20 81 7.3.5. Using IPFIX Files for Testing . . . . . . . . . . . . 21 82 7.3.6. Writing IPFIX Files for Device Diagnostics . . . . . . 21 83 8. File Format Metadata Specification . . . . . . . . . . . . . . 21 84 8.1. Recommended Options Templates for IPFIX Files . . . . . . 22 85 8.1.1. Message Checksum Options Template . . . . . . . . . . 22 86 8.1.2. File Time Window Options Template . . . . . . . . . . 22 87 8.1.3. Export Session Details Options Template . . . . . . . 23 88 8.1.4. Message Details Options Template . . . . . . . . . . . 25 89 8.2. Recommended Information Elements for IPFIX Files . . . . . 27 90 8.2.1. collectionTimeMilliseconds . . . . . . . . . . . . . . 28 91 8.2.2. exportSctpStreamId . . . . . . . . . . . . . . . . . . 28 92 8.2.3. maxExportSeconds . . . . . . . . . . . . . . . . . . . 28 93 8.2.4. maxFlowEndMicroseconds . . . . . . . . . . . . . . . . 29 94 8.2.5. maxFlowEndMilliseconds . . . . . . . . . . . . . . . . 29 95 8.2.6. maxFlowEndNanoseconds . . . . . . . . . . . . . . . . 29 96 8.2.7. maxFlowEndSeconds . . . . . . . . . . . . . . . . . . 30 97 8.2.8. messageMD5Checksum . . . . . . . . . . . . . . . . . . 30 98 8.2.9. messageScope . . . . . . . . . . . . . . . . . . . . . 31 99 8.2.10. minExportSeconds . . . . . . . . . . . . . . . . . . . 31 100 8.2.11. minFlowStartMicroseconds . . . . . . . . . . . . . . . 31 101 8.2.12. minFlowStartMilliseconds . . . . . . . . . . . . . . . 32 102 8.2.13. minFlowStartNanoseconds . . . . . . . . . . . . . . . 32 103 8.2.14. minFlowStartSeconds . . . . . . . . . . . . . . . . . 33 104 8.2.15. opaqueOctets . . . . . . . . . . . . . . . . . . . . . 33 105 8.2.16. sessionScope . . . . . . . . . . . . . . . . . . . . . 33 106 9. Recommended Error Resilience Strategies . . . . . . . . . . . 34 107 9.1. Compression Error Resilience . . . . . . . . . . . . . . . 34 108 9.2. Encryption Error Resilience . . . . . . . . . . . . . . . 35 109 10. Recommended File Integration Strategies . . . . . . . . . . . 36 110 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files . . . . . . 36 111 10.2. Encapsulation of IPFIX Files within Other File Formats . . 36 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 114 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 115 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39 117 14.2. Informative References . . . . . . . . . . . . . . . . . . 39 118 Appendix A. Example IPFIX File . . . . . . . . . . . . . . . . . 40 119 A.1. Example Options Templates . . . . . . . . . . . . . . . . 42 120 A.2. Example Supplemental Options Data . . . . . . . . . . . . 44 121 A.3. Example Message Checksum . . . . . . . . . . . . . . . . . 46 122 A.4. File Example Data Set . . . . . . . . . . . . . . . . . . 47 123 A.5. Complete File Example . . . . . . . . . . . . . . . . . . 47 124 Appendix B. Applicability of IPFIX Files to NetFlow V9 flow 125 storage . . . . . . . . . . . . . . . . . . . . . . . 49 126 B.1. Comparing NetFlow V9 to IPFIX . . . . . . . . . . . . . . 49 127 B.1.1. Message Header Format . . . . . . . . . . . . . . . . 49 128 B.1.2. Set Header Format . . . . . . . . . . . . . . . . . . 50 129 B.1.3. Template Format . . . . . . . . . . . . . . . . . . . 51 130 B.1.4. Information Model . . . . . . . . . . . . . . . . . . 51 131 B.1.5. Template Management . . . . . . . . . . . . . . . . . 51 132 B.1.6. Transport . . . . . . . . . . . . . . . . . . . . . . 51 133 B.2. A Method for Transforming NetFlow V9 messages to IPFIX . . 52 134 B.3. NetFlow V9 Transformation Example . . . . . . . . . . . . 53 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 136 Intellectual Property and Copyright Statements . . . . . . . . . . 57 138 1. Introduction 140 This document specifies a file format based upon IPFIX, designed to 141 facilitate interoperability and reusability among a wide variety of 142 flow storage, processing, and analysis tools. It begins with an 143 overview of the IPFIX File format, and a quick summary of how IPFIX 144 Files work in Section 3. The detailed specification of the IPFIX 145 File format appears in Section 7; this section includes general 146 specifications for IPFIX File Readers and IPFIX File Writers and 147 specific recommendations for common situations in which they are 148 used. The format makes use of the IPFIX Options mechanism for 149 additional file metadata, in order to avoid requiring any protocol 150 extensions, and to minimize the effort required to adapt IPFIX 151 implementations to use the file format; a detailed definition of the 152 Options Templates used for storage metadata appears in Section 8. 154 Section 9 and Section 10 provide specific recommendations for error 155 resilience during long-term storage and integration of IPFIX File 156 data with other formats. Appendix A contains a detailed example 157 IPFIX File. These sections are intended to give additional 158 information to implementors of IPFIX Files. 160 The IPFIX File format was designed to be applicable to a wide variety 161 of flow storage situations; the motivation behind its creation is 162 described in Section 4. The document outlines of the set of 163 requirements the format is designed to meet in Section 5, and 164 explores the applicability of such a format to various specific 165 application areas in Section 6. These sections are intended to give 166 background on the development of IPFIX Files. 168 1.1. IPFIX Documents Overview 170 "Specification of the IPFIX Protocol for the Exchange of IP Traffic 171 Flow Information" [RFC5101] and its associated documents define the 172 IPFIX Protocol, which provides network engineers and administrators 173 with access to IP traffic flow information. 175 "Architecture for IP Flow Information Export" [I-D.ietf-ipfix-arch] 176 defines the architecture for the export of measured IP flow 177 information out of an IPFIX Exporting Process to an IPFIX Collecting 178 Process, and the basic terminology used to describe the elements of 179 this architecture, per the requirements defined in "Requirements for 180 IP Flow Information Export" [RFC3917]. [RFC5101] then covers the 181 details of the method for transporting IPFIX Data Records and 182 Templates via a congestion-aware transport protocol from an IPFIX 183 Exporting Process to an IPFIX Collecting Process. 185 "Information Model for IP Flow Information Export" [RFC5102] 186 describes the Information Elements used by IPFIX, including details 187 on Information Element naming, numbering, and data type encoding. 189 "IPFIX Applicability" [I-D.ietf-ipfix-as] describes the various 190 applications of the IPFIX protocol and their use of information 191 exported via IPFIX, and relates the IPFIX architecture to other 192 measurement architectures and frameworks. 194 In addition, "Exporting Type Information for IPFIX Information 195 Elements" [I-D.ietf-ipfix-exporting-type] specifies a method for 196 encoding Information Model properties within an IPFIX Message stream. 198 This document references [RFC5101] and the architecture document for 199 terminology, defines IPFIX File Writer and IPFIX File Reader in terms 200 of the IPFIX Exporting Processes and IPFIX Collecting Process 201 definitions from [RFC5101], and extends the IPFIX Information Model 202 defined in [RFC5102] to provide new Information Elements for IPFIX 203 File metadata. It uses the method described in "Exporting Type 204 Information for IPFIX Information Elements" 205 [I-D.ietf-ipfix-exporting-type] document to support the self- 206 description of IPFIX Files containing enterprise-specific Information 207 Elements. 209 2. Terminology 211 This section defines terminology related to the IPFIX File Format. 212 In addition, terms used in this document that are defined in the 213 Terminology section of [RFC5101] are to be interpreted as defined 214 there. 216 IPFIX File: An IPFIX File is a serialized stream of IPFIX Messages; 217 this stream may be stored on a filesystem or transported using any 218 technique customarily used for files. Any IPFIX Message stream 219 that would be considered valid when transported one or more of the 220 specified IPFIX transports (SCTP, TCP, or UDP) as defined in 221 [RFC5101] is considered an IPFIX File. However, this document 222 extends that definition with recommendations on the construction 223 of IPFIX Files that meet the requirements identified in Section 5. 225 IPFIX File Reader: An IPFIX File Reader is a process which reads 226 IPFIX Files from a filesystem. An IPFIX File Reader operates as 227 an IPFIX Collecting Process as specified in [RFC5101], except as 228 modified by this document. 230 IPFIX File Writer: An IPFIX File Writer is a process which writes 231 IPFIX Files to a filesystem. An IPFIX File Writer operates as an 232 IPFIX Exporting Process as specified in [RFC5101], except as 233 modified by this document. 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in [RFC2119]. 239 3. Design Overview 241 An IPFIX File is simply a data stream containing one or more IPFIX 242 Messages serialized to some filesystem. Though any set of valid 243 IPFIX Messages can be serialized into an IPFIX File, the 244 specification includes guidelines designed to ease storage and 245 retrieval of flow data using the IPFIX File format. 247 IPFIX Files contain only IPFIX Messages; any file metadata such as 248 checksums or export session details are stored using Options within 249 the IPFIX Message. This design has several advantages, including 250 complete compatibility with the IPFIX Protocol on the wire and free 251 manipulability of IPFIX Files through concatenation, appending, and 252 splitting (on IPFIX Message boundaries). A schematic of a typical 253 IPFIX File is shown below: 255 +=======================================+ 256 | IPFIX File | 257 | +===================================+ | 258 | | IPFIX Message | | 259 | | +-------------------------------+ | | 260 | | | IPFIX Message Header | | | 261 | | +-------------------------------+ | | 262 | | +-------------------------------+ | | 263 | | | Options Template Set | | | 264 | | | Options Template Record | | | 265 | | | . . . | | | 266 | | +-------------------------------+ | | 267 | | +-------------------------------+ | | 268 | | | Template Set | | | 269 | | | Template Record | | | 270 | | | . . . | | | 271 | | +-------------------------------+ | | 272 | +===================================+ | 273 | | IPFIX Message | | 274 | | +-------------------------------+ | | 275 | | | IPFIX Message Header | | | 276 | | +-------------------------------+ | | 277 | | +-------------------------------+ | | 278 | | | Data Set | | | 279 | | | Data Record | | | 280 | | | . . . | | | 281 | | +-------------------------------+ | | 282 | | +-------------------------------+ | | 283 | | | Data Set | | | 284 | | | Data Record | | | 285 | | | . . . | | | 286 | | +-------------------------------+ | | 287 | | . . . | | 288 | +===================================+ | 289 | . . . | 290 +=======================================+ 292 Figure 1: Typical File Structure 294 4. Motivation 296 There is a wide variety of applications for the file-based storage of 297 IP flow data, across a continuum of time scales. Tools used in the 298 analysis of flow data and creation of analysis products often use 299 files as a convenient unit of work, with an ephemeral lifetime. A 300 set of flows relevant to a security investigation may be stored in a 301 file for the duration of that investigation, and further exchanged 302 among incident handlers via email or within an external incident 303 handling workflow application. Sets of flow data relevant to 304 Internet measurement research may be published as files, much as 305 libpcap packet trace files are, to provide common datasets for the 306 repeatability of research efforts; these files would have lifetimes 307 measured in months or years. Operational flow measurement systems 308 also have a need for long-term, archival storage of flow data, either 309 as a primary flow data repository, or as a backing tier for online 310 storage in a relational database management system (RDBMS). 312 The variety of applications of flow data, and the variety of 313 presently deployed storage approaches, indicates the need for a 314 standard approach to flow storage with applicability across the 315 continuum of time scales over which flow data is stored. A storage 316 format based around flat files would best address the variety of 317 storage requirements. While much work has been done on structured 318 storage via RDBMS, relational database systems are not a good basis 319 for format standardization owing to the fact that their internal data 320 structures are generally private to a single implementation and 321 subject to change for internal reasons. Also, there are a wide 322 variety of operations available on flat files, and external tools and 323 standards can be leveraged to meet file-based flow storage 324 requirements. Further, flow data is often not very semantically 325 complicated, and is managed in very high volume; therefore, an RDBMS- 326 based flow storage system would not benefit much from the advantages 327 of relational database technology. 329 The simplest way to create a new file format is simply to serialize 330 some internal data model to disk, with either textual or binary 331 representation of data elements, and some framing strategy for 332 delimiting fields and records. "Ad-hoc" file formats such as this 333 have several important disadvantages. They impose the semantics of 334 the data model from which they are derived on the file format, and as 335 such, they are difficult to extend, describe, and standardize. 337 Indeed, one de facto standard for the storage of flow data is one of 338 these ad-hoc formats. A common method of storing data collected via 339 Cisco NetFlow is to serialize a stream of raw NetFlow datagrams into 340 files. These NetFlow PDU files consist of a collection of header- 341 prefixed blocks (corresponding to the datagrams as received on the 342 wire) containing fixed-length binary flow records. NetFlow V5, V7, 343 and V8 data may be mixed within a given file, as the header on each 344 datagram defines the NetFlow version of the records following. While 345 this NetFlow PDU file format has all the disadvantages of an ad-hoc 346 format, and is not extensible to data models other than that defined 347 by Cisco NetFlow, it is at least reasonably well-understood due to 348 its ubiquity. 350 Over the past decade XML markup has emerged as a new "universal" 351 representation format for structured data. It is intended to be 352 human-readable; indeed, that is one reason for its rapid adoption. 353 However XML has limited usefulness for representing network flow 354 data. Network flow data has a simple, repetitive, non-hierarchical 355 structure that does not benefit much from XML. An XML representation 356 of flow data would be an essentially flat list of the attributes and 357 their values for each flow record. 359 The XML approach to data encoding is very heavyweight when compared 360 to binary flow encoding. XML's use of start- and end-tags, and 361 plain-text encoding of the actual values, leads to significant 362 inefficiency in encoding size. Typical network traffic datasets can 363 contain millions or billions of flows per hour of traffic 364 represented. Any increase in storage size per record can have 365 dramatic impact on flow data storage and transfer sizes. While data 366 compression algorithms can partially remove the redundancy introduced 367 by XML encoding, they introduce additional overhead of their own. 369 A further problem is that XML processing tools require a full XML 370 parser. XML parsers are fully general and therefore complex, 371 resource-intensive and relatively slow, introducing significant 372 processing time overhead for large network-flow datasets. In 373 contrast, parsers for typical binary flow data encodings are simply 374 structured, since they only need to parse a very small header and 375 then have complete knowledge of all following fields for the 376 particular flow. These can then be read in a very efficient linear 377 fashion. 379 This leads us to propose the IPFIX Message format as the basis for a 380 new flow data file format. The IPFIX working group, in defining the 381 IPFIX Protocol, has already defined an information model and data 382 formatting rules for representation of flow data. Especially at 383 shorter time scales, when a file is a unit of data interchange, the 384 filesystem may be viewed as simply another IPFIX Message transport 385 between processes. This format is especially well suited to 386 representing flow data, as it was designed specifically for flow data 387 export; it is easily extensible unlike ad-hoc serialization, and 388 compact unlike XML. In addition, IPFIX is an IETF standard for the 389 export and collection of flow data; using a common format for storage 390 and analysis at the collection side allows implementors to use 391 substantially the same information model and data formatting 392 implementation for transport as well as storage. 394 5. Requirements 396 In this section, we outline a proposed set of requirements 398 [SAINT2007] for any persistent storage format for flow data. First 399 and foremost, a flow data file format should support storage across 400 the continuum of time scales important to flow storage applications. 401 Each of the requirements enumerated in the sections below is broadly 402 applicable to flow storage applications, though each may be more 403 important at certain time scales. For each, we first identify the 404 requirement, then explain how the IPFIX Message format addresses it, 405 or briefly outline the changes that must be made in order for an 406 IPFIX-based file format to meet the requirement. 408 5.1. Record Format Flexibility 410 Due to the wide variety of flow attributes collected by different 411 network flow attribute measurement systems, the ideal flow storage 412 format will not impose a single data model or a specific record type 413 on the flows it stores. The file format must be flexible and 414 extensible; that is, it must support the definition of multiple 415 record types within the file itself, and must be able to support new 416 field types for data within the records in a graceful way. 418 IPFIX provides record format flexibility through the use of Templates 419 to describe each Data Record, through the use of an IANA Registry to 420 define its Information Elements, and through the use of enterprise- 421 specific Information Elements. 423 5.2. Self Description 425 Archived data may be read at a time in the future where any external 426 reference to the meaning of the data may be lost. The ideal flow 427 storage format should be self-describing; that is, a process reading 428 flow data from storage should be able to properly interpret the 429 stored flows without reference to anything other than standard 430 sources (e.g., the standards document describing the file format) and 431 the stored flow data itself. 433 The IPFIX Message format is partially self-describing; that is, IPFIX 434 Templates containing only IANA-assigned Information Elements can be 435 completely interpreted according to the IPFIX Information Model 436 without additional external data. 438 However, Templates containing private information elements lack 439 detailed type and semantic information; a Collecting Process 440 receiving Data Records described by a Template containing enterprise- 441 specific Information Elements it does not understand can only treat 442 the data contained within those Information Elements as octet arrays. 443 To be fully self-describing, enterprise-specific Information Elements 444 must be additionally described via IPFIX Options according to the 445 Information Element Type Options Template defined in "Exporting Type 446 Information for IPFIX Information Elements" 447 [I-D.ietf-ipfix-exporting-type]. 449 5.3. Data Compression 451 Regardless of the representation format, flow data describing traffic 452 on real networks tends to be highly compressible. Compression tends 453 to improve the scalability of flow collection systems, by reducing 454 the disk storage and I/O bandwidth requirement for a given workload. 455 The ideal flow storage format should support applications which wish 456 to leverage this fact by supporting compression of stored data. 458 The IPFIX Message format has no support for data compression, as the 459 IPFIX protocol was designed for speed and simplicity of export. Of 460 course, any flat file is readily compressible using a wide variety of 461 external data compression tools, formats, and algorithms; therefore, 462 this requirement can be met externally. 464 However, a couple of simple optimizations can be made by File Writers 465 to increase the integrity and usability of compressed IPFIX data; 466 these are outlined in Section 9.1. 468 5.4. Indexing and Searching 470 Binary, record stream oriented file formats natively support only one 471 form of searching, sequential scan in file order. By choosing the 472 order of records in a file carefully (e.g., by flow end time), a file 473 can be indexed by a single key. 475 Beyond this, properly addressing indexing is an application-specific 476 problem, as it inherently involves tradeoffs between storage 477 complexity and retrieval speed, and requirements vary widely based on 478 time scales and the types of queries used from site to site. 479 However, a generic standard flow storage format may provide limited 480 direct support for indexing and searching. 482 The ideal flow storage format will support a limited table of 483 contents facility noting that the records in a file contain data 484 relating only to certain keys or values of keys, in order to keep 485 multi-file search implementations from having to scan a file for data 486 it does not contain. 488 The IPFIX Message format has no direct support for indexing. 489 However, the technique described in "Reducing Redundancy in IPFIX and 490 PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy] can be used to 491 describe the contents of a file in a limited way. Additionally, as 492 flow data is often sorted and divided by time, the start and end time 493 of the flows in a file may be declared using the File Time Window 494 Options Template defined in Section 8.1.2. 496 5.5. Data Integrity 498 When storing flow data for archival purposes, it is important to 499 ensure that hardware or software faults do not introduce errors into 500 the data over time. The ideal flow storage format will support the 501 detection and correction of encoding-level errors in the data. 503 Note that more advanced error correction is best handled at a layer 504 below that addressed by this document. Error correction is a topic 505 well addressed by the storage industry in general (e.g. by RAID and 506 other technologies), and by specifying a flow storage format based 507 upon files, we can leverage these features to meet this requirement. 509 However, the ideal flow storage format will be resilient against 510 errors, providing an internal facility for the detection of errors 511 and the ability to isolate errors to as few data records as possible. 513 Note that this requirement interacts with the choice of data 514 compression or encryption algorithm. The use of block compression 515 algorithms can serve to isolate errors to a single compression block, 516 unlike stream compressors, which may fail to resynchronize after a 517 single bit error, invalidating the entire message stream. Similarly, 518 the use of a stream cipher can serve to isolate errors in the 519 plaintext without amplifying them as, for example, a cipher in CBC 520 mode can. See the "Recommended Compression Error Resilience 521 Strategy" and "Recommended Encryption Error Resilience Strategy" 522 sections below for more on this interaction. 524 The IPFIX Message format does not support data integrity assurance. 525 It is assumed that advanced error correction will be provided 526 externally. For simple error detection support, checksums may be 527 attached to messages via IPFIX Options according to the Message 528 Checksum Options Template defined in Section 8.1.1. 530 5.6. Creator Authentication and Confidentiality 532 Archival storage of flow data may also require assurance that no 533 unauthorized entity can read or modify the stored data. Asymmetric- 534 key cryptography can be applied to this problem, by signing flow data 535 with the private key of the creator, and encrypting it with the 536 public keys of those authorized to read it. The ideal flow storage 537 format will support the encryption and signing of flow data. 539 As with error correction, this problem has been addressed well at a 540 layer below that addressed by this document. Instead of specifying a 541 particular choice of encryption technology, we can leverage the fact 542 that existing cryptographic technologies work quite well on data 543 stored in files to meet this requirement. 545 Beyond support for the use of TLS for transport over TCP or DTLS for 546 transport over SCTP or UDP, both of which provide transient 547 authentication and confidentiality, the IPFIX protocol does not 548 support this requirement directly. It is assumed that this 549 requirement will be met externally. 551 5.7. Anonymization and Obfuscation 553 To ensure the privacy of individuals and organizations at the 554 endpoints of communications represented by flow records, it is often 555 necessary to obfuscate or anonymize stored and exported flow data. 556 The ideal flow storage format will provide for a notation that a 557 given information element on a given record type represents 558 anonymized, rather than real, data. 560 The IPFIX Protocol presently has no support for anonymization 561 notation. It should be noted that anonymization is one of the 562 requirements given for IPFIX in [RFC3917]. The decision to qualify 563 this requirement with 'MAY' and not 'MUST' in the requirements 564 document, and its subsequent lack of specification in the current 565 version of the IPFIX protocol, is due to the fact that anonymization 566 algorithms are still an open area of research, and that there 567 currently exist no standardized methods for anonymization. 569 No support is presently defined in [RFC5101] or this IPFIX-based File 570 Format for anonymization, as anonymization notation is an area of 571 open work for the IPFIX working group. 573 5.8. Session Auditability and Replayability 575 Certain use cases for archival flow storage require the storage of 576 collection infrastructure details alongside the data itself. These 577 details include information about how and when data was received, and 578 where it was received from, and are useful for auditing as well as 579 for the replaying received data for testing purposes. 581 The IPFIX Protocol contains no direct support for auditability and 582 replayability, though the IPFIX Information Model does define various 583 Information Elements required to represent collection infrastructure 584 details. These details may be stored in IPFIX Files using the Export 585 Session Details Options Template defined in Section 8.1.3 and the 586 Message Details Options Template defined in Section 8.1.4. 588 5.9. Performance Characteristics 590 The ideal standard flow storage format will not have a significant 591 negative impact on the performance of the application generating or 592 processing flow data stored in the format. This is a non-functional 593 requirement, but it is important to note that a standard that implies 594 a significant performance penalty is unlikely to be widely 595 implemented and adopted. 597 An examination of the IPFIX Protocol would seem to suggest that 598 implementations of it are not particularly prone to slowness; indeed, 599 a template-based data representation is more easily subject to 600 optimization for common cases than representations that embed 601 structural information directly in the data stream (e.g. XML). 602 However, a full analysis of the impact of using IPFIX Messages as a 603 basis for flow data storage on read/write performance will require 604 more implementation experience and performance measurement. 606 6. Applicability 608 This section describes the specific applicability of IPFIX Files to 609 various use cases. IPFIX Files are particularly useful in a flow 610 collection and processing infrastructure using IPFIX for flow export. 611 We explore the applicability and provide guidelines for using IPFIX 612 files for the storage of flow data collected by IPFIX Collecting 613 Processes and NetFlow V9 collectors, the testing of IPFIX Collecting 614 Processes, and diagnostics of IPFIX Devices. 616 6.1. Storage of IPFIX-collected Flow Data 618 IPFIX Files can naturally be used to store flow data collected by an 619 IPFIX Collecting Process; indeed, this was one of the primary initial 620 motivations behind the file format described within this document. 621 Using IPFIX Files as such provides a single, standard, well- 622 understood encoding to be used for flow data on disk and on the wire, 623 and allows IPFIX implementations to leverage substantially the same 624 code for flow export and flow storage. In addition, the storage of 625 single Transport Sessions in IPFIX Files is particularly important 626 for network measurement research, allowing repeatability of 627 experiments by providing a format for the storage and exchange of 628 IPFIX flow trace data much as the libpcap format is used for 629 experiments on packet trace data. 631 6.2. Storage of NetFlow V9-collected Flow Data 633 Although the IPFIX protocol is based on the Cisco Netflow Services, 634 Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged 635 since work began on IPFIX. However, since the NetFlow V9 information 636 model is a compatible subset of the IPFIX information model, it is 637 possible to use IPFIX files to store collected NetFlow V9 flow data. 638 This approach may be particularly useful in multi-vendor, multi- 639 protocol collection infrastructures using both NetFlow V9 and IPFIX 640 to export flow data. 642 The applicability of IPFIX Files to this use case is outlined in 643 Appendix B. 645 6.3. Testing IPFIX Collecting Processes 647 IPFIX Files can be used to store IPFIX Messages for the testing of 648 IPFIX Collecting Processes. A variety of test cases may be stored in 649 IPFIX Files. First, IPFIX data collected in real network 650 environments and stored in an IPFIX File can be used as input to 651 check the behavior of new or extended implementations of IPFIX 652 Collectors. Furthermore, IPFIX Files can be used to validate the 653 operation of a given IPFIX Collecting Process in a new environment, 654 i.e., to test with recorded IPFIX data from the target network before 655 installing the Collecting Process in the network. 657 The IPFIX File format can also be used to store artificial, non- 658 compliant reference messages for specific Collecting Process test 659 cases. Examples for such test cases are sets of IPFIX records with 660 undefined Information Elements, Data Records described by missing 661 Templates, or incorrectly framed Messages or Data Sets. 662 Representative error handling test cases are defined in "IPFIX 663 Testing" [I-D.ietf-ipfix-testing]. 665 Furthermore, fast replay of IPFIX Messages stored in a file can be 666 used for stress/load tests (e.g., high rate of incoming Data Records, 667 large Templates with high Information Element counts), as described 668 in "IPFIX Testing" [I-D.ietf-ipfix-testing]. The provisioning and 669 use of a set of reference files for testing simplifies the 670 performance of tests and increases the comparability of test results. 672 6.4. IPFIX Device Diagnostics 674 As an IPFIX File can be used store any collection of flows, the 675 format may also be used for dumping and storing various types of flow 676 data for IPFIX Device diagnostics (e.g., the open flow cache of a 677 Metering Process or the flow backlog of an Exporting or Collecting 678 Process at the time of a process reset or crash). File-based storage 679 is preferable to remote transmission in such error-recovery 680 situations. 682 7. Detailed File Format Specification 684 Any valid serialized IPFIX Message stream MUST be accepted by a File 685 Reader as a valid IPFIX File. In this way, the filesystem is simply 686 treated as another IPFIX transport alongside SCTP, TCP, and UDP, 687 albeit a potentially high-latency transport, as the File Reader and 688 File Writer do not necessarily run at the same time. 690 This section specifies the detailed actions of File Readers and File 691 Writers in handling IPFIX Files, and further specifies actions of 692 File Writers in specific use cases. Unless otherwise specified 693 herein, IPFIX File Writers MUST behave as IPFIX Exporting Processes, 694 and IPFIX File Readers MUST behave as IPFIX Collecting Processes, 695 where appropriate. 697 7.1. File Reader Specification 699 An IPFIX File Reader MUST act as an IPFIX Collecting Process as 700 specified in [RFC5101], except as modified by this document. 702 An IPFIX File Reader MUST accept as valid any serialized IPFIX 703 Message stream that would be considered valid by one or more of the 704 other defined IPFIX transport layers. Practically, this means that 705 the union of IPFIX Template management features supported by SCTP, 706 TCP, and UDP MUST be supported in IPFIX Files. File Readers MUST: 708 o accept IPFIX Messages containing Template Sets, Options Template 709 Sets, and Data Sets within the same message, as with IPFIX over 710 TCP or UDP; 712 o accept Template Sets that define Templates already defined within 713 the File, as may occur with retransmission of Templates when using 714 IPFIX over UDP as described in section 10.3.6 of [RFC5101]; 716 o resolve any conflict between a resent definition and a previous 717 definition by assuming that the new Template replaces the old, as 718 consistent with Template expiration and ID reuse when using UDP at 719 the IPFIX transport protocol; and 721 o accept Template Withdrawals as described in section 8 of 722 [RFC5101], provided that the Template to be withdrawn is defined, 723 as is the case with IPFIX over TCP and SCTP. 725 Considering the filesystem-as-transport view, in the general case an 726 IPFIX File SHOULD be treated as containing a single Transport Session 727 as defined by [RFC5101]. However, some applications may benefit from 728 the ability to treat a collection of IPFIX Files as a single 729 Transport Session; see especially Section 7.3.3 below. A File Reader 730 MAY be configurable to treat a collection of Files as a single 731 Transport Session. However, a File Reader MUST NOT treat a single 732 IPFIX File as containing multiple Transport Sessions. 734 If an IPFIX File uses the technique described in "Reducing Redundancy 735 in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy] AND 736 all of the non-Options Templates in the File contain the 737 commonPropertiesId Information Element, a File Reader MAY assume the 738 set of commonPropertiesId definitions provides a complete table of 739 contents for the File for searching purposes. 741 7.2. File Writer Specification 743 An IPFIX File Writer MUST act as an IPFIX Exporting Process as 744 specified in [RFC5101], except as modified by this document. This 745 section contains specifications for IPFIX File Writers in all 746 situations; specifications and recommendations for specific File 747 Writer use cases are found in below. 749 File Writers SHOULD store the Templates and Options required to 750 decode the data within the File in the File itself, unless modified 751 by the requirements of a specific use case in a subsection of 752 Section 7.3. In this way, a single IPFIX File generally contains a 753 single notional Transport Session as defined by [RFC5101]. 755 File Writers SHOULD emit each Template Set or Options Template Set to 756 appear in the File before any Data Set described by the Templates 757 within that Set, to ensure the File Reader can decode every Data Set 758 without waiting to process subsequent Templates or Options Templates. 760 File Writers SHOULD emit Data Records described by Options Templates 761 to appear in the File before any Data Records which depend on the 762 scopes defined by those options. 764 File Writers SHOULD use Template Withdrawals to withdraw Templates if 765 Template IDs need to be reused. Template Withdrawals SHOULD NOT be 766 used unless necessary to reuse Template IDs. 768 File Writers SHOULD write IPFIX Messages within an IPFIX File in 769 ascending Export Time order. 771 File Writers MAY write Data Records to an IPFIX File in any order. 772 However, File Writers that write flow records to an IPFIX File in 773 flowStartTime or flowEndTime order SHOULD be consistent in this 774 ordering within each File. 776 7.3. Specific File Writer Use Cases 778 The specifications in this section apply to specific situations. 779 Each section below extends or modifies the base File Writer 780 specification in Section 7.2. Considerations for collocation of a 781 File Writer with IPFIX Collecting Processes and Metering Processes 782 are given, as are specific guidelines for using IPFIX Files for 783 archival storage, or as documents. Also covered are the use of IPFIX 784 Files in the testing and diagnostics of IPFIX Devices. 786 7.3.1. Collocating a File Writer with a Collecting Process 788 When collocating a File Writer with an IPFIX Collecting Process for 789 archival storage of collected data in IPFIX Files as described in 790 Section 6.1, the following recommendations may improve the usefulness 791 of the stored data. 793 The simplest way for a File Writer to store the data collected in a 794 single Transport Session is to simply write the incoming IPFIX 795 Messages to an IPFIX File as they are collected. This approach has 796 several drawbacks. First, if the original Exporting Process did not 797 conform to the recommendations in Section 7.2 with respect to 798 Template and Data Record ordering, the written file can be difficult 799 to use later; in this case, File Writers MAY reorder records as 800 received in order to ensure that Templates appear before the Data 801 Records they describe. 803 A File Writer collocated with a Collecting Process that starts 804 writing data from a running Transport Session SHOULD write all the 805 Templates currently active within that Transport Session before 806 writing any Data Records described by them. 808 Also, the resulting IPFIX Files will lack information about the IPFIX 809 Transport Session used to export them, such as the network addresses 810 of the Exporting and Collecting Processes and the protocols used to 811 transport them. In this case, if information about the Transport 812 Session is required, the File Writer SHOULD store a single IPFIX 813 Transport Session in an IPFIX File and SHOULD record information 814 about the Transport Session using the Export Session Details Options 815 Template described in Section 8.1.3. 817 Additional per-Message information MAY be recorded by the File Writer 818 using the Message Details Options Template described in 819 Section 8.1.4. Per-Message information includes the time at which 820 each IPFIX Message was received at the Collecting Process, and can be 821 used to resend IPFIX Messages while keeping the original measurement 822 plane traffic profile. 824 When collocating a File Writer with a Collecting Process, the Export 825 Time of each Message SHOULD be the Export Time of the Message 826 received by the Collecting Process containing the first Data Record 827 in the Message. Note that File Writers storing IPFIX data collected 828 from an IPFIX Collecting Process using SCTP as the transport protocol 829 SHOULD interleave messages from multiple streams in order to preserve 830 Export Time order, and SHOULD reorder the written messages as 831 necessary to ensure that each Template Set or Options Template Set 832 appears in the File before any Data Set described by the Templates 833 within that Set. Template reordering MUST preserve the sequence of 834 Template Sets with Template Withdrawals in order to ensure 835 consistency of Templates. 837 Note that when adding additional information to IPFIX Messages 838 received from Collecting Processes (e.g. Message Checksum Options, 839 Message Detail Options), the File Writer SHOULD extend the length of 840 the Message for the additional data if possible; otherwise, the 841 Message SHOULD be split into two approximately equal-size Messages 842 aligned on a Data Set or Template Set boundary from the original 843 Message if possible; otherwise, the Message SHOULD be split into 844 approximately two equal size Messages aligned on a Data Record 845 boundary. Note that, since the MSS or MTU of most network links 846 (1500-9000 for common Ethernets) is smaller than the maximum IPFIX 847 Message size (65536) within an IPFIX File, it is expected that 848 message length extension will suffice in most circumstances. 850 7.3.2. Collocating a File Writer with a Metering Process 852 Note that File Writers may also be collocated directly with IPFIX 853 Metering Processes, for writing measured information directly to disk 854 without intermediate IPFIX Exporting or Collecting Processes. This 855 arrangement may be particularly useful when providing data to an 856 analysis environment with an IPFIX File based workflow, or when 857 testing Metering Processes during development. 859 When collocating a File Writer with a Metering Process, note that 860 Information Elements associated with Exporting or Collecting 861 Processes are meaningless, and SHOULD NOT appear in the Export 862 Session Details Options Template described in Section 8.1.3 or the 863 Message Details Options Template described in Section 8.1.4. 865 When collocating a File Writer with an Metering Process, the Export 866 Time of each Message SHOULD be the time at which the first Data 867 Record in the Message was received from the Metering Process. 869 7.3.3. Using IPFIX Files for Archival Storage 871 While in the general case File Writers should store one Transport 872 Session per IPFIX File, some applications storing large collections 873 of data over long periods of time may benefit from the ability to 874 treat a collection of IPFIX Files as a single Transport Session. A 875 File Writer MAY be configurable to write data from a single Transport 876 Session into multiple IPFIX Files; however, File Writers supporting 877 such a configuration option MUST provide a configuration option to 878 support one-file-per-session behavior for interoperability purposes. 880 File Writers compressing or encrypting archival data and File Readers 881 reading compressed or encrypted archival data SHOULD follow the 882 recommendations in Section 9. 884 7.3.4. Using IPFIX Files as Documents 886 When IPFIX Files are used as documents, to store a set of flows 887 relevant to query, investigation, or other common context, or for the 888 publication of traffic datasets relevant to network research, each 889 File MUST be readable as a single Transport Session, self-contained 890 and making no reference to metadata stored in separate Files, in 891 order to ensure interoperability. 893 When writing Files to be used as documents, File Writers MAY emit the 894 special Data Records described by Options Templates before any other 895 Data Records in the File in the following order to ease the 896 inspection and use of documents by File Readers: 898 o Time Window records described by the File Time Window Options 899 Template as defined in Section 8.1.2 below; followed by 901 o Information Element Type Records as described in "Exporting Type 902 Information for IPFIX Information Elements" 903 [I-D.ietf-ipfix-exporting-type]; followed by 905 o commonPropertiesId definitions as described in "Reducing 906 Redundancy in IPFIX and PSAMP Reports" 907 [I-D.ietf-ipfix-reducing-redundancy]; followed by 909 o Export Session details records described by the Export Session 910 Details Options Template as defined in Section 8.1.3 below. 912 The Export Time of each Message within a File used as a document 913 SHOULD be the time at which the Message was written by the File 914 Writer. 916 If an IPFIX File used as a document uses the technique described in 917 "Reducing Redundancy in IPFIX and PSAMP Reports" 918 [I-D.ietf-ipfix-reducing-redundancy] AND all of the non-Options 919 Templates in the File contain the commonPropertiesId Information 920 Element, a File Reader MAY assume the set of commonPropertiesId 921 definitions provides a complete table of contents for the File for 922 searching purposes. 924 7.3.5. Using IPFIX Files for Testing 926 IPFIX Files can be used for testing IPFIX Collecting Processes in two 927 ways. First, IPFIX Files can be used to store specific flow data for 928 regression and stress testing of Collectors; there are no special 929 considerations for IPFIX Files used in this way. 931 Second, IPFIX Files are useful for storing reference messages which 932 do not comply to the IPFIX Protocol in order to test the error 933 handling and recovery behavior of Collectors. Of course, IPFIX Files 934 intended to be used in this application necessarily MAY violate any 935 of the specifications in this document or in [RFC5101], and such 936 Files MUST NOT be transmitted to Collecting Processes or given as 937 input File Readers not under test. 939 Note that an extremely simple IPFIX Exporting Process may be crafted 940 for testing purposes by simply reading an IPFIX File and transmitting 941 it directly to a Collecting Process. Similarly, an extremely simple 942 Collecting Process may be crafted for testing purposes by simply 943 accepting connections and/or IPFIX Messages from Exporting Processes 944 and writing the session's message stream to an IPFIX File. 946 7.3.6. Writing IPFIX Files for Device Diagnostics 948 IPFIX Files can be used in the debugging of devices which use flow 949 data as internal state, as a common format for the representation of 950 flow tables. In such situations, the opaqueOctets information 951 element can be used to store additional non-IPFIX encoded, non-flow 952 information (e.g., stack backtraces, process state, etc.) within the 953 IPFIX File as in Section 10.1; the IPFIX flow table information could 954 also be embedded in a larger proprietary diagnostic format using 955 delimiters as in Section 10.2 957 8. File Format Metadata Specification 959 This section defines the Options Templates used for IPFIX File 960 metadata, and the Information Elements they require. 962 8.1. Recommended Options Templates for IPFIX Files 964 The following Options Templates allow IPFIX Message streams to meet 965 the requirements outlined above without extension to the message 966 format or protocol. They are defined in terms of existing 967 Information Elements defined in [RFC5102], the Information Elements 968 defined in "Exporting Type Information for IPFIX Information 969 Elements" [I-D.ietf-ipfix-exporting-type], as well as Information 970 Elements defined in Section 8.2. IPFIX File Readers and Writers 971 SHOULD support these Options Templates as defined below. 973 In addition, IPFIX File Readers and Writers SHOULD support the 974 Options Templates defined in "Exporting Type Information for IPFIX 975 Information Elements" [I-D.ietf-ipfix-exporting-type] in order to 976 support self-description of enterprise-specific Information Elements. 978 8.1.1. Message Checksum Options Template 980 The Message Checksum Options Template specifies the structure of a 981 Data Record for attaching an MD5 message checksum to an IPFIX 982 Message. An MD5 message checksum as described MAY be used if data 983 integrity is important to the application. The described Data Record 984 MUST appear only once per IPFIX Message, but MAY appear anywhere 985 within the Message. 987 This Options Template SHOULD contain the following Information 988 Elements: 990 +--------------------+----------------------------------------------+ 991 | IE | Description | 992 +--------------------+----------------------------------------------+ 993 | messageScope | A marker denoting this Option applies to the | 994 | [scope] | whole IPFIX Message; content is ignored. | 995 | | This Information Element MUST be defined as | 996 | | a Scope Field. | 997 | messageMD5Checksum | The MD5 checksum of the containing IPFIX | 998 | | Message. | 999 +--------------------+----------------------------------------------+ 1001 8.1.2. File Time Window Options Template 1003 The File Time Window Options Template specifies the structure of a 1004 Data Record for attaching a time window to an IPFIX File; this Data 1005 Record is referred to as a time window record. A time window record 1006 defines the earliest flow start time and the latest flow end time of 1007 the flow records within a File. One and only one time window record 1008 MAY appear within an IPFIX File if the time window information is 1009 available; a File Writer MUST NOT write more than one time window 1010 record to an IPFIX File. A File Writer that writes a time window 1011 record to a File MUST NOT write any Flow with a start time before the 1012 beginning of the window or an end time after the end of the window to 1013 that File. 1015 This Options Template SHOULD contain the following Information 1016 Elements: 1018 +---------------+---------------------------------------------------+ 1019 | IE | Description | 1020 +---------------+---------------------------------------------------+ 1021 | sessionScope | A marker denoting this Option applies to the | 1022 | [scope] | whole IPFIX Transport Session (i.e., the IPFIX | 1023 | | File in the common case); content is ignored. | 1024 | | This Information Element MUST be defined as a | 1025 | | Scope Field. | 1026 | minFlowStart* | Exactly one of minFlowStartSeconds, | 1027 | | minFlowStartMilliseconds, | 1028 | | minFlowStartMicroseconds, or | 1029 | | minFlowStartNanoseconds; SHOULD match the | 1030 | | precision of the accompanying maxFlowEnd* | 1031 | | Information Element. The start time of the | 1032 | | earliest flow in the Transport Session (i.e., | 1033 | | File). | 1034 | maxFlowEnd* | Exactly one of maxFlowEndSeconds, | 1035 | | maxFlowEndMilliseconds, maxFlowEndMicroseconds, | 1036 | | or maxFlowEndNanoseconds; SHOULD match the | 1037 | | precision of the accompanying minFlowStart* | 1038 | | Information Element. The end time of the latest | 1039 | | flow in the Transport Session (i.e., File). | 1040 +---------------+---------------------------------------------------+ 1042 8.1.3. Export Session Details Options Template 1044 The Export Session Details Options Template specifies the structure 1045 of a Data Record for recording the details of an IPFIX Transport 1046 Session in an IPFIX File. It is intended for use in storing a single 1047 complete IPFIX Transport Session in a single IPFIX File. The 1048 described Data Record SHOULD appear only once in a given IPFIX File. 1050 This Options Template SHOULD contain at least the following 1051 Information Elements, subject to applicability as noted on each 1052 Information Element: 1054 +----------------------------+--------------------------------------+ 1055 | IE | Description | 1056 +----------------------------+--------------------------------------+ 1057 | sessionScope [scope] | A marker denoting this Option | 1058 | | applies to the whole IPFIX Transport | 1059 | | Session (i.e., the IPFIX File in the | 1060 | | common case); content is ignored. | 1061 | | This Information Element MUST be | 1062 | | defined as a Scope Field. | 1063 | exporterIPv4Address | IPv4 address of the IPFIX Exporting | 1064 | | Process from which the Messages in | 1065 | | this Transport Session were | 1066 | | received. Present only for | 1067 | | Exporting Processes with an IPv4 | 1068 | | interface. For multi-homed SCTP | 1069 | | associations, this SHOULD be the | 1070 | | primary path endpoint address of the | 1071 | | Exporting Process. | 1072 | exporterIPv6Address | IPv6 address of the IPFIX Exporting | 1073 | | Process from which the Messages in | 1074 | | this Transport Session were | 1075 | | received. Present only for | 1076 | | Exporting Processes with an IPv6 | 1077 | | interface. For multi-homed SCTP | 1078 | | associations, this SHOULD be the | 1079 | | primary path endpoint address of the | 1080 | | Exporting Process. | 1081 | exporterTransportPort | The source port from which the | 1082 | | Messages in this Transport Session | 1083 | | were received. | 1084 | collectorIPv4Address | IPv4 address of the IPFIX Collecting | 1085 | | Process which received the Messages | 1086 | | in this Transport Session. Present | 1087 | | only for Collecting Processes with | 1088 | | an IPv4 interface. For multi-homed | 1089 | | SCTP associations, this SHOULD be | 1090 | | the primary path endpoint address of | 1091 | | the Collecting Process. | 1092 | collectorIPv6Address | IPv6 address of the IPFIX Collecting | 1093 | | Process which received the Messages | 1094 | | in this Transport Session. Present | 1095 | | only for Collecting Processes with | 1096 | | an IPv6 interface. For multi-homed | 1097 | | SCTP associations, this SHOULD be | 1098 | | the primary path endpoint address of | 1099 | | the Collecting Process. | 1100 | collectorTransportPort | The destination port on which the | 1101 | | Messages in this Transport Session | 1102 | | were received. | 1103 | collectorTransportProtocol | The IP Protocol Identifier of the | 1104 | | transport protocol used to transport | 1105 | | Messages within this Transport | 1106 | | Session. | 1107 | collectorProtocolVersion | The version of the export protocol | 1108 | | used to transport Messages within | 1109 | | this Transport Session. Applicable | 1110 | | only in mixed NetFlow V9-IPFIX | 1111 | | collection environments when storing | 1112 | | NetFlow V9 data in IPFIX Messages, | 1113 | | as in Appendix B | 1114 | minExportSeconds | The Export Time of the first Message | 1115 | | in the Transport Session. | 1116 | maxExportSeconds | The Export Time of the last Message | 1117 | | in the Transport Session. | 1118 +----------------------------+--------------------------------------+ 1120 8.1.4. Message Details Options Template 1122 The Message Details Options Template specifies the structure of a 1123 Data Record for attaching additional export details to an IPFIX 1124 Message. These details include the time at which a message was 1125 received and information about the export and collection 1126 infrastructure used to transport the Message. This Options Template 1127 also allows the storage of the export session metadata provided the 1128 Export Session Details Options Template, for storing information from 1129 multiple Transport Sessions in the same IPFIX File. 1131 This Options Template SHOULD contain at least the following 1132 Information Elements, subject to applicability as noted for each 1133 Information Element. Note that when used in conjunction with the 1134 Export Session Details Options Template, when storing a single 1135 complete IPFIX Transport Session in an IPFIX File, this Options 1136 Template SHOULD contain only the messageScope and 1137 collectionTimeMilliseconds Information Elements, and the 1138 exportSctpStreamId Information Element for Messages transported via 1139 SCTP. 1141 +----------------------------+--------------------------------------+ 1142 | IE | Description | 1143 +----------------------------+--------------------------------------+ 1144 | messageScope [scope] | A marker denoting this Option | 1145 | | applies to the whole IPFIX message; | 1146 | | content is ignored. This | 1147 | | Information Element MUST be defined | 1148 | | as a Scope Field. | 1149 | collectionTimeMilliseconds | The absolute time at which this | 1150 | | Message was received by the IPFIX | 1151 | | Collecting Process. | 1152 | exporterIPv4Address | IPv4 address of the IPFIX Exporting | 1153 | | Process from which this Message was | 1154 | | received. Present only for | 1155 | | Exporting Processes with an IPv4 | 1156 | | interface, and if this information | 1157 | | is not available via the Export | 1158 | | Session Details Options Template. | 1159 | | For multi-homed SCTP associations, | 1160 | | this SHOULD be the primary path | 1161 | | endpoint address of the Exporting | 1162 | | Process. | 1163 | exporterIPv6Address | IPv6 address of the IPFIX Exporting | 1164 | | Process this Message was received. | 1165 | | Present only for Exporting Processes | 1166 | | with an IPv6 interface, and if this | 1167 | | information is not available via the | 1168 | | Export Session Details Options | 1169 | | Template. For multi-homed SCTP | 1170 | | associations, this SHOULD be the | 1171 | | primary path endpoint address of the | 1172 | | Exporting Process. | 1173 | exporterTransportPort | The source port from which this | 1174 | | Message received. Present only if | 1175 | | this information is not available | 1176 | | via the Export Session Details | 1177 | | Options Template. | 1178 | collectorIPv4Address | IPv4 address of the IPFIX Collecting | 1179 | | Process which received this Message. | 1180 | | Present only for Collecting | 1181 | | Processes with an IPv4 interface, | 1182 | | and if this information is not | 1183 | | available via the Export Session | 1184 | | Details Options Template. For | 1185 | | multi-homed SCTP associations, this | 1186 | | SHOULD be the primary path endpoint | 1187 | | address of the Collecting Process. | 1188 | collectorIPv6Address | IPv6 address of the IPFIX Collecting | 1189 | | Process which received this Message. | 1190 | | Present only for Collecting | 1191 | | Processes with an IPv6 interface, | 1192 | | and if this information is not | 1193 | | available via the Export Session | 1194 | | Details Options Template. For | 1195 | | multi-homed SCTP associations, this | 1196 | | SHOULD be the primary path endpoint | 1197 | | address of the Collecting Process. | 1198 | collectorTransportPort | The destination port on which this | 1199 | | Message was received. Present only | 1200 | | if this information is not available | 1201 | | via the Export Session Details | 1202 | | Options Template. | 1203 | collectorTransportProtocol | The IP Protocol Identifier of the | 1204 | | transport protocol used to transport | 1205 | | this Message. Present only if this | 1206 | | information is not available via the | 1207 | | Export Session Details Options | 1208 | | Template. | 1209 | collectorProtocolVersion | The version of the export protocol | 1210 | | used to transport this Message. | 1211 | | Present only if necessary and if | 1212 | | this information is not available | 1213 | | via the Export Session Details | 1214 | | Options Template. | 1215 | exportSctpStreamId | The SCTP stream used to transport | 1216 | | this Message. Present only if the | 1217 | | Message was transported via SCTP. | 1218 +----------------------------+--------------------------------------+ 1220 8.2. Recommended Information Elements for IPFIX Files 1222 The following Information Elements are used by the Options Templates 1223 in Section 8.1 to allow IPFIX Message streams to meet the 1224 requirements outlined above without extension of the protocol. IPFIX 1225 File Readers and Writers SHOULD support these Information Elements as 1226 defined below. 1228 In addition, IPFIX File Readers and Writers SHOULD support the 1229 Information Elements defined in "Exporting Type Information for IPFIX 1230 Information Elements" [I-D.ietf-ipfix-exporting-type] in order to 1231 support full self-description of Information Elements. 1233 8.2.1. collectionTimeMilliseconds 1235 Description: The absolute timestamp at which the data within the 1236 scope containing this Information Element was received by a 1237 Collecting Process. This Information Element SHOULD be bound to 1238 its containing IPFIX Message via IPFIX Options and the 1239 messageScope Information Element, as defined below. 1241 Abstract Data Type: dateTimeMilliseconds 1243 ElementId: TBD1 1245 Status: current 1247 8.2.2. exportSctpStreamId 1249 Description: The value of the SCTP Stream Identifier used by the 1250 Exporting Process for exporting IPFIX Message data. This is 1251 carried in the Stream Identifier field of the header of the SCTP 1252 DATA chunk containing the IPFIX Message(s). 1254 Abstract Data Type: unsigned16 1256 Data Type Semantics: identifier 1258 ElementId: TBD2 1260 Status: current 1262 8.2.3. maxExportSeconds 1264 Description: The absolute Export Time of the latest IPFIX Message 1265 within the scope containing this Information Element. This 1266 Information Element SHOULD be bound to its containing IPFIX 1267 Transport Session via IPFIX Options and the sessionScope 1268 Information Element. 1270 Abstract Data Type: dateTimeSeconds 1272 ElementId: TBD3 1274 Status: current 1276 Units: seconds 1278 8.2.4. maxFlowEndMicroseconds 1280 Description: The latest absolute timestamp of the last packet 1281 within any Flow within the scope containing this Information 1282 Element, rounded up to the microsecond if necessary. This 1283 Information Element SHOULD be bound to its containing IPFIX 1284 Transport Session via IPFIX Options and the sessionScope 1285 Information Element. This Information Element SHOULD be used only 1286 in Transport Sessions containing Flow Records with microsecond- 1287 precision (or better) timestamp Information Elements. 1289 Abstract Data Type: dateTimeMicroeconds 1291 ElementId: TBD11 1293 Status: current 1295 Units: microseconds 1297 8.2.5. maxFlowEndMilliseconds 1299 Description: The latest absolute timestamp of the last packet 1300 within any Flow within the scope containing this Information 1301 Element, rounded up to the millisecond if necessary. This 1302 Information Element SHOULD be bound to its containing IPFIX 1303 Transport Session via IPFIX Options and the sessionScope 1304 Information Element. This Information Element SHOULD be used only 1305 in Transport Sessions containing Flow Records with millisecond- 1306 precision (or better) timestamp Information Elements. 1308 Abstract Data Type: dateTimeMilliseconds 1310 ElementId: TBD12 1312 Status: current 1314 Units: milliseconds 1316 8.2.6. maxFlowEndNanoseconds 1318 Description: The latest absolute timestamp of the last packet 1319 within any Flow within the scope containing this Information 1320 Element. This Information Element SHOULD be bound to its 1321 containing IPFIX Transport Session via IPFIX Options and the 1322 sessionScope Information Element. This Information Element SHOULD 1323 be used only in Transport Sessions containing Flow Records with 1324 nanosecond-precision timestamp Information Elements. 1326 Abstract Data Type: dateTimeNanoseconds 1328 ElementId: TBD13 1330 Status: current 1332 Units: nanoseconds 1334 8.2.7. maxFlowEndSeconds 1336 Description: The latest absolute timestamp of the last packet 1337 within any Flow within the scope containing this Information 1338 Element, rounded up to the second if necessary. This Information 1339 Element SHOULD be bound to its containing IPFIX Transport Session 1340 via IPFIX Options and the sessionScope Information Element. 1342 Abstract Data Type: dateTimeSeconds 1344 ElementId: TBD4 1346 Status: current 1348 Units: seconds 1350 8.2.8. messageMD5Checksum 1352 Description: The MD5 checksum of the IPFIX Message containing this 1353 record. This Information Element SHOULD be bound to its 1354 containing IPFIX Message via an options record and the 1355 messageScope Information Element, as defined below, and SHOULD 1356 appear only once in a given IPFIX Message. To calculate the value 1357 of this Information Element, first buffer the containing IPFIX 1358 Message, setting the value of this Information Element to all 1359 zeroes. Then caluclate the MD5 checksum of the resulting buffer 1360 as defined in [RFC1321], place the resulting value in this 1361 Information Element, and export the buffered message. 1363 Abstract Data Type: octetArray (16 bytes) 1365 ElementId: TBD5 1367 Status: current 1369 Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321] 1371 8.2.9. messageScope 1373 Description: The presence of this Information Element as scope in 1374 an Options Template signifies that the options described by the 1375 Template apply to the IPFIX Message that contains them. It is 1376 defined for general purpose message scoping of options, and 1377 proposed specifically to allow the attachment a checksum to a 1378 message via IPFIX Options. The value of this Information Element 1379 MUST be written as 0 by the File Writer or Exporting Process. The 1380 value of this Information Element MUST be ignored by the File 1381 Reader or the Collecting Process. 1383 Abstract Data Type: octet 1385 ElementId: TBD6 1387 Status: current 1389 8.2.10. minExportSeconds 1391 Description: The absolute Export Time of the earliest IPFIX Message 1392 within the scope containing this Information Element. This 1393 Information Element SHOULD be bound to its containing IPFIX 1394 Transport Session via an options record and the sessionScope 1395 Information Element. 1397 Abstract Data Type: dateTimeSeconds 1399 ElementId: TBD7 1401 Status: current 1403 Units: seconds 1405 8.2.11. minFlowStartMicroseconds 1407 Description: The earliest absolute timestamp of the first packet 1408 within any Flow within the scope containing this Information 1409 Element, rounded down to the microsecond if necessary. This 1410 Information Element SHOULD be bound to its containing IPFIX 1411 Transport Session via an options record and the sessionScope 1412 Information Element. This Information Element SHOULD be used only 1413 in Transport Sessions containing Flow Records with microsecond- 1414 precision (or better) timestamp Information Elements. 1416 Abstract Data Type: dateTimeMicroseconds 1418 ElementId: TBD14 1420 Status: current 1422 Units: microseconds 1424 8.2.12. minFlowStartMilliseconds 1426 Description: The earliest absolute timestamp of the first packet 1427 within any Flow within the scope containing this Information 1428 Element, rounded down to the millisecond if necessary. This 1429 Information Element SHOULD be bound to its containing IPFIX 1430 Transport Session via an options record and the sessionScope 1431 Information Element. This Information Element SHOULD be used only 1432 in Transport Sessions containing Flow Records with millisecond- 1433 precision (or better) timestamp Information Elements. 1435 Abstract Data Type: dateTimeMilliseconds 1437 ElementId: TBD15 1439 Status: current 1441 Units: milliseconds 1443 8.2.13. minFlowStartNanoseconds 1445 Description: The earliest absolute timestamp of the first packet 1446 within any Flow within the scope containing this Information 1447 Element. This Information Element SHOULD be bound to its 1448 containing IPFIX Transport Session via an options record and the 1449 sessionScope Information Element. This Information Element SHOULD 1450 be used only in Transport Sessions containing Flow Records with 1451 nanosecond-precision timestamp Information Elements. 1453 Abstract Data Type: dateTimeNanoseconds 1455 ElementId: TBD16 1457 Status: current 1459 Units: nanoseconds 1461 8.2.14. minFlowStartSeconds 1463 Description: The earliest absolute timestamp of the first packet 1464 within any Flow within the scope containing this Information 1465 Element, rounded down to the second if necessary. This 1466 Information Element SHOULD be bound to its containing IPFIX 1467 Transport Session via an options record and the sessionScope 1468 Information Element. 1470 Abstract Data Type: dateTimeSeconds 1472 ElementId: TBD8 1474 Status: current 1476 Units: seconds 1478 8.2.15. opaqueOctets 1480 Description: This Information Element is used to encapsulate non- 1481 IPFIX data into an IPFIX Message stream, for the purpose of 1482 allowing a non-IPFIX data processor to store a data stream inline 1483 within an IPFIX File. A Collecting Process or File Writer MUST 1484 NOT try to interpret this binary data. This Information Element 1485 differs from paddingOctets as its contents are meaningful in some 1486 non-IPFIX context, while the contents of paddingOctets MUST be 1487 0x00 and are intended only for Information Element alignment. 1489 Abstract Data Type: octet 1491 ElementId: TBD9 1493 Status: current 1495 8.2.16. sessionScope 1497 Description: The presence of this Information Element as scope in 1498 an Options Template signifies that the options described by the 1499 Template apply to the IPFIX Transport Session that contains them. 1500 Note that as all options are implicitly scoped to Transport 1501 Session and Observation Domain, this Information Element is 1502 equivalent to a "null" scope. It is defined for general purpose 1503 session scoping of options, and proposed specifically to allow the 1504 attachment of time window to an IPFIX File via IPFIX Options. The 1505 value of this Information Element MUST be written as 0 by the File 1506 Writer or Exporting Process. The value of this Information 1507 Element MUST be ignored by the File Reader or the Collecting 1508 Process. 1510 Abstract Data Type: octet 1512 ElementId: TBD10 1514 Status: current 1516 9. Recommended Error Resilience Strategies 1518 This section describes recommended methods for making IPFIX Files 1519 resilient to errors during storage. It is intended primarily for 1520 applications using IPFIX Files for long-term archival storage of flow 1521 data. 1523 9.1. Compression Error Resilience 1525 Note that, since any file may be compressed and decompressed with a 1526 variety of widely available tools implementing a variety of 1527 compression standards (both specified and de facto), compression of 1528 IPFIX File data can be accomplished externally. However, compression 1529 at the file level is not particularly resilient to errors; in the 1530 worst case, a single bit error in a stream-compressed file may result 1531 in the loss of the entire file. 1533 To limit the impact of errors on the recoverability of compressed 1534 data, we recommend the use of block compression where possible. 1535 Ideally, the block compression algorithm should support the 1536 identification and isolation of blocks containing errors; bzip2 is an 1537 example of such a block compressor. 1539 Since the block boundary of a block-compressed IPFIX File may fall in 1540 the middle of an IPFIX Message, resynchronization of an IPFIX Message 1541 stream by a File Reader after a compression error requires some care. 1542 The beginning of an IPFIX Message may be identified by its header 1543 signature (the Version field of the Message Header, 0x00 0x0A, 1544 followed by a 16-bit Message Length), but simply searching for the 1545 first occurance of the Version field is insufficient, since these two 1546 bytes may occur in valid IPFIX Template or Data Sets. 1548 Therefore, we propose the following algorithm for File Readers to 1549 resynchronize an IPFIX Message Stream after skipping a compressed 1550 block containing errors: 1552 1. Search after the error for the first occurrence of the octet 1553 string 0x00, 0x0A (the IPFIX Message Header Version field.) 1555 2. Treat this field as the beginning of a candidate IPFIX Message. 1556 Read the two bytes following the Version field as a Message 1557 Length, and seek to that offset from the beginning of the 1558 candidate IPFIX Message. 1560 3. If the first two octets after the candidate IPFIX Message are 1561 0x00, 0x0A (i.e., the IPFIX Message Header Version field of the 1562 next message in the stream), or if end-of-file is reached 1563 precisely at the end of the candidate IPFIX Message, presume that 1564 the candidate IPFIX Message is valid, and begin reading the IPFIX 1565 File from the start of the candidate IPFIX Message. 1567 4. If not, or if the seek reaches end-of-file or another block 1568 containing errors before finding the end of the candidate 1569 message, go back to step 1, starting the search two bytes from 1570 the start of the candidate IPFIX Message. 1572 The algorithm above will improperly identify a non-message as a 1573 message approximately 1 in 2^32 times, assuming random IPFIX data. 1574 It may be expanded to consider multiple candidate IPFIX Messages in 1575 order to increase reliability. 1577 In applications (e.g. archival storage) in which error resilience is 1578 very important, File Writers SHOULD use block compression algorithms, 1579 and MAY attempt to align IPFIX Messages within compression blocks to 1580 ease resynchronization after errors, if such is supported by the 1581 chosen block compressor. File Readers SHOULD use the 1582 resynchronization algorithm above to minimize data loss due to 1583 compression errors. 1585 9.2. Encryption Error Resilience 1587 File-level encryption has error resilience issues similar to file- 1588 level compression. Single bit errors in the encrypted data stream 1589 can result in unreadability of the entire remaining file, dependent 1590 on the encryption method used. The use of CBC (Cipher Block 1591 Chaining) mode, which suffers from this low error resilience, is 1592 relatively common. 1594 In applications (e.g. archival storage) in which error resilience is 1595 very important, File Writers SHOULD use a stream cipher, for example 1596 a block cipher in OFB (Output Feedback) mode (often referred to as 1597 stream mode) instead of modes like CBC when encrypting, since errors 1598 are not amplified by stream ciphers: A single-bit error in the 1599 ciphertext results in a single bit error in the plaintext. 1600 Alternatively File Writers SHOULD use any other cipher which can 1601 resynchronize after bit errors. An example is a block cipher in CBC 1602 mode that is reinitialized after a specific amount of data has been 1603 encrypted. The maximum data loss per bit-error is then up to the 1604 next reinitialization point. In this case, File Writers SHOULD also 1605 use the Message Checksum Options Template to attach a checksum to 1606 each IPFIX Message in the IPFIX File, in order to support the 1607 recognition of errors in the decrypted data. 1609 10. Recommended File Integration Strategies 1611 This section describes methods for integrating IPFIX File data with 1612 other file formats. 1614 10.1. Encapsulation of Non-IPFIX Data in IPFIX Files 1616 At times it may be useful to export or store non-IPFIX data inline in 1617 an IPFIX File or Message stream. To do this cleanly, this data must 1618 be encapsulated into IPFIX Messages so that an IPFIX File Reader or 1619 Collecting Process can handle it without any need to interpret it. 1620 At the same time, this data must not be changed during transmission 1621 or storage. The opaqueOctets Information Element as defined in 1622 Section 8.2.15 is provided for this encapsulation. 1624 Processing the encapsulated non-IPFIX data is left to a separate 1625 processing mechanisms that can identify encapsulated non-IPFIX data 1626 in an IPFIX message stream, but need not have any other IPFIX 1627 handling capability, except the ability to skip over all IPFIX 1628 messages that do not encapsulate non-IPFIX data. 1630 The Message Checksum Options Template, described in Section 8.1.1 may 1631 be used as a uniform mechanism to identify errors within encapsulated 1632 data. 1634 Note that this mechanism can only encapsulate data objects up to 1635 65,515 octets in length. If the space available in one IPFIX Message 1636 is not enough for the amount of data to be encapsulated, then the 1637 data must be broken into smaller segments that are encapsulated into 1638 consecutive IPFIX Messages. Any additional structuring or semantics 1639 of the raw data is outside the scope of IPFIX and must be implemented 1640 within the encapsulated binary data itself. Furthermore, the raw 1641 encapsulated data cannot be assumed by an IPFIX File Reader to have 1642 any specific format. 1644 10.2. Encapsulation of IPFIX Files within Other File Formats 1646 Consequently, it may also be useful to reverse the encapsulation, 1647 that is, to export or store IPFIX data inline within a non-IPFIX file 1648 or data stream. This makes sense when the other file format is not 1649 compatible with the encapsulation described above in Section 10.1. 1650 Generally speaking, the encapsulation here will be specific to the 1651 format of the containing file. For example, IPFIX Files may be 1652 embedded in XML elements using hex or Base64 encoding, or in raw 1653 binary files using start and end delimiters or some form of run- 1654 length encoding. As there are as many potential encapsulations here 1655 as there are potential file formats, the specifics of each are out of 1656 scope for this specification. 1658 11. Security Considerations 1660 The IPFIX File format itself does not directly introduce security 1661 issues. Rather it is used to store information which may for privacy 1662 or business reasons be considered sensitive. The file format must 1663 therefore provide appropriate procedures to guarantee the integrity 1664 and confidentiality of the stored information. 1666 The underlying protocol used to exchange the information that will be 1667 stored using the format proposed in this document must as well apply 1668 appropriate procedures to guarantee the integrity and confidentiality 1669 of the exported information. Such issues are addressed in [RFC5101]. 1671 Implementors of IPFIX File Writers which store data taken from an 1672 IPFIX Collecting Process using TLS or DTLS for transport security 1673 should note that IPFIX Files may present a potential breach of 1674 confidentiality if IPFIX data collected using TLS or DTLS is stored 1675 in unencrypted files, and should consider providing an external file 1676 encryption option to mitigate this risk. 1678 12. IANA Considerations 1680 This document specifies the creation of several new IPFIX Information 1681 Elements in the IPFIX Information Element registry located at 1682 http://www.iana.org/assignments/ipfix, as defined in Section 8.2 1683 above. IANA has assigned the following Information Element numbers 1684 for their respective Information Elements as specified below: 1686 o Information Element number TBD1 for the collectionTimeMilliseconds 1687 Information Element. 1689 o Information Element number TBD2 for the exportSctpStreamId 1690 Information Element. 1692 o Information Element number TBD3 for the maxExportSeconds 1693 Information Element. 1695 o Information Element number TBD11 for the maxFlowEndMicroseconds 1696 Information Element. 1698 o Information Element number TBD12 for the maxFlowEndMilliseconds 1699 Information Element. 1701 o Information Element number TBD13 for the maxFlowEndNanoseconds 1702 Information Element. 1704 o Information Element number TBD4 for the maxFlowEndSeconds 1705 Information Element. 1707 o Information Element number TBD5 for the messageMD5Checksum 1708 Information Element. 1710 o Information Element number TBD6 for the messageScope Information 1711 Element. 1713 o Information Element number TBD7 for the minExportSeconds 1714 Information Element. 1716 o Information Element number TBD14 for the minFlowStartMicroseconds 1717 Information Element. 1719 o Information Element number TBD15 for the minFlowStartMilliseconds 1720 Information Element. 1722 o Information Element number TBD16 for the minFlowStartNanoseconds 1723 Information Element. 1725 o Information Element number TBD8 for the minFlowStartSeconds 1726 Information Element. 1728 o Information Element number TBD9 for the opaqueOctets Information 1729 Element. 1731 o Information Element number TBD10 for the sessionScope Information 1732 Element. 1734 [NOTE for IANA: The text TBDn should be replaced with the respective 1735 assigned Information Element numbers where they appear in this 1736 document.] 1738 13. Acknowledgements 1740 Thanks to Maurizio Molina, Tom Kosnar, and Andreas Kind for technical 1741 assistance with the requirements for a standard flow storage format. 1742 Thanks to Benoit Claise, Paul Aitken, Andrew Johnson, and Gerhard 1743 Muenz for their reviews and feedback. 1745 14. References 1747 14.1. Normative References 1749 [RFC5101] Claise, B., "Specification of the IP Flow Information 1750 Export (IPFIX) Protocol for the Exchange of IP Traffic 1751 Flow Information", RFC 5101, January 2008. 1753 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1754 Meyer, "Information Model for IP Flow Information Export", 1755 RFC 5102, January 2008. 1757 [I-D.ietf-ipfix-exporting-type] 1758 Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1759 "Exporting Type Information for IPFIX Information 1760 Elements", draft-ietf-ipfix-exporting-type-02 (work in 1761 progress), July 2008. 1763 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1764 April 1992. 1766 14.2. Informative References 1768 [I-D.ietf-ipfix-arch] 1769 Sadasivan, G. and N. Brownlee, "Architecture Model for IP 1770 Flow Information Export", draft-ietf-ipfix-arch-02 (work 1771 in progress), October 2003. 1773 [I-D.ietf-ipfix-as] 1774 Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 1775 (work in progress), July 2007. 1777 [I-D.ietf-ipfix-reducing-redundancy] 1778 Boschi, E., "Reducing Redundancy in IP Flow Information 1779 Export (IPFIX) and Packet Sampling (PSAMP) Reports", 1780 draft-ietf-ipfix-reducing-redundancy-04 (work in 1781 progress), May 2007. 1783 [I-D.ietf-ipfix-testing] 1784 Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 1785 Flow Information eXport (IPFIX) Testing", 1786 draft-ietf-ipfix-testing-05 (work in progress), 1787 April 2008. 1789 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1790 9", RFC 3954, October 2004. 1792 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1793 "Requirements for IP Flow Information Export (IPFIX)", 1794 RFC 3917, October 2004. 1796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1797 Requirement Levels", BCP 14, RFC 2119, March 1997. 1799 [SAINT2007] 1800 Trammell, B., Boschi, E., Mark, L., and T. Zseby, 1801 "Requirements for a standardized flow storage solution", 1802 in Proceedings of the SAINT 2007 workshop on Internet 1803 Measurement Technology, Hiroshima, Japan, January 2007. 1805 Appendix A. Example IPFIX File 1807 In this section we will explore an example IPFIX File which 1808 demonstrates the various features of the IPFIX File format. This 1809 File contains flow records described by a single Template. This File 1810 also contains a File Time Window record to note the start and end 1811 time of the data, and an Export Session Details record to record 1812 collection infrastructure information. Each Message within this File 1813 also contains a Message Checksum record, as this File may be 1814 externally encrypted and/or stored as an archive. The structure of 1815 this File is shown in Figure 2. 1817 +=================================================+ 1818 | IPFIX Message seq. 0 | 1819 | +---------------------------------------------+ | 1820 | | Template Set (id 2) 1 rec | | 1821 | | Data Tmpl. id 256 | | 1822 | +---------------------------------------------+ | 1823 | | Options Template Set (id 3) 3 recs | | 1824 | | File Time Window Opt. Tmpl. id 257 | | 1825 | | Message Checksum Opt. Tmpl. id 259 | | 1826 | | Export Session Details Opt. Tmpl. id 258 | | 1827 | +---------------------------------------------+ | 1828 | | Data Set (id 259) [Message Checksum] 1 rec | | 1829 | +---------------------------------------------+ | 1830 +=================================================+ 1831 | IPFIX Message seq. 1 | 1832 | +---------------------------------------------+ | 1833 | | Data Set (id 257) [File Time Window] 1 rec | | 1834 | +---------------------------------------------+ | 1835 | | Data Set (id 258) [Export Session] 1 rec | | 1836 | +---------------------------------------------+ | 1837 | | Data Set (id 259) [Message Checksum] 1 rec | | 1838 | +---------------------------------------------+ | 1839 +=================================================+ 1840 | IPFIX Message seq. 4 | 1841 | +---------------------------------------------+ | 1842 | | Data Set (id 256) 50 recs | | 1843 | | contains flow data | | 1844 | +---------------------------------------------+ | 1845 | | Data Set (id 259) [Message Checksum] 1 rec | | 1846 | +---------------------------------------------+ | 1847 +=================================================+ 1848 | IPFIX Message seq. 55 | 1849 | . . . | 1851 Figure 2: File Example Structure 1853 The Template describing the data records contains a flow start 1854 timestamp, an IPv4 5-tuple, and packet and octet total counts. The 1855 Template Set defining this is as shown in Figure 3 below: 1857 1 2 3 1858 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 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Set ID = 2 | Length = 40 | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Template ID = 256 | Field Count = 8 | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 |0| flowStartSeconds = 150 | Field Length = 4 | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 |0| sourceIPv4Address = 8 | Field Length = 4 | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 |0| dest.IPv4Address = 12 | Field Length = 4 | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 |0| sourceTransportPort = 7 | Field Length = 2 | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 |0| dest.TransportPort = 11 | Field Length = 2 | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 |0| protocolIdentifier = 4 | Field Length = 1 | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 |0| octetTotalCount = 85 | Field Length = 4 | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 |0| packetTotalCount = 86 | Field Length = 4 | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 Figure 3: File Example Data Template 1883 A.1. Example Options Templates 1885 This is followed by an Options Template Set containing the Options 1886 Templates required to read the File: the File Time Window Options 1887 Template defined in Section 8.1.2 above, the Export Session Details 1888 Options Template defined in Section 8.1.3 above, and the Message 1889 Checksum Options Template defined in Section 8.1.1 above. This 1890 Options Template Set is shown in Figure 4 and Figure 5 below: 1892 1 2 3 1893 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 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Set ID = 3 | Length = 80 | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Template ID = 257 | Field Count = 3 | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Scope Field Count = 1 |0| sessionScope = TBD10 | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Field Length = 1 |0| minFlowStartSeconds = TBD8 | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Field Length = 4 |0| maxFlowEndSeconds = TBD4 | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Field Length = 4 | Template ID = 259 | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Field Count = 2 | Scope Field Count = 1 | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 |0| messageScope = TBD6 | Field Length = 1 | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 |0| messageMD5Checksum = TBD5 | Field Length = 16 | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 Figure 4: File Example Options Templates (Time Window and Checksum) 1915 1 2 3 1916 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 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Template ID = 258 | Field Count = 9 | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Scope Field Count = 1 |0| sessionScope = TBD10 | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Field Length = 1 |0| exporterIPv4Address = 130 | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Field Length = 4 |0| collectorIPv4Address = 211 | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Field Length = 4 |0| exporterTransportPort = 217 | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | Field Length = 2 |0| col.TransportPort = 216 | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Field Length = 2 |0| col.TransportProtocol = 215 | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Field Length = 1 |0| col.ProtocolVersion = 214 | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | Field Length = 1 |0| minExportSeconds = TBD7 | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | Field Length = 4 |0| maxExportSeconds = TBD3 | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 | Field Length = 4 | set padding (2 octets) | 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 Figure 5: File Example Options Templates, Continued (Session Details) 1943 A.2. Example Supplemental Options Data 1945 Following the Templates required to decode the File is the 1946 supplemental IPFIX Options information used to describe the File's 1947 contents and type information. First comes the File Time Window 1948 record; it notes that the File contains data from 9 October 2007 1949 between 00:01:13 and 23:56:27 UTC, and appears as in Figure 6: 1951 1 2 3 1952 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 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | Set ID = 257 | Length = 13 | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | sessionScope | minFlowStartSeconds 1957 | 0 | 2007-10-09 00:01:13 UTC . . . 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | maxFlowEndSeconds 1960 . . . | 2007-10-09 23:56:27 UTC . . . 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | 1963 . . . | 1964 +-+-+-+-+-+-+-+-+ 1966 Figure 6: File Example Time Window 1968 This is followed by information about how the data in the File was 1969 collected, in the Export Session Details record. This record notes 1970 that the session stored in this File was sent via SCTP from an 1971 exporter at 192.0.2.30 port 32769 to an collector at 192.0.2.40 port 1972 4739, and contains messages exported between 00:01:57 and 23:57:12 1973 UTC on 9 October 2007; it is represented in its Data Set as in 1974 Figure 7: 1976 1 2 3 1977 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 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | Set ID = 258 | Length = 27 | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | sessionScope | exporterIPv4Address 1982 | 0 | 192.0.2.30 . . . 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | collectorIPv4Address 1985 . . . | 192.0.2.31 . . . 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | exporterTransportPort | cTPort 1988 . . . | 32769 | 4739 . . . 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | cTProtocol | cPVersion | 1991 . . . | 132 | 10 | . . . 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 minExportSeconds | 1994 . . . 2007-10-09 00:01:57 UTC | . . . 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 maxExportSeconds | 1997 . . . 2007-10-09 23:57:12 UTC | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 Figure 7: File Example Export Session Details 2002 A.3. Example Message Checksum 2004 Each IPFIX Message within the File is completed with a Message 2005 Checksum record; the structure of this record within its Data Set is 2006 as in Figure 8: 2008 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 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Set ID = 259 | Length = 24 | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | messageScope | | 2013 | 0 | | 2014 +-+-+-+-+-+-+-+-+ | 2015 | messageMD5Checksum | 2016 | (16 byte MD5 checksum of options message) | 2017 | | 2018 | | 2019 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | | set padding (3 octets) | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 Figure 8: File Example Message Checksum 2025 A.4. File Example Data Set 2027 After the Templates and supplemental Options information comes the 2028 data itself. The first record of an example Data Set is shown with 2029 its message and set headers in Figure 9: 2031 1 2 3 2032 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 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Version = 10 | Length = 1296 | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Export Time = 2007-10-09 00:01:57 UTC | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Sequence Number = 4 | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 | Observation Domain ID = 1 | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | Set ID = 256 | Length = 1254 | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | flowStartSeconds | 2045 | 2007-10-09 00:01:13 UTC | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | sourceIPv4Address | 2048 | 192.0.2.2 | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | destinationIPv4Address | 2051 | 192.0.2.3 | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | sourceTransportPort | destinationTransportPort | 2054 | 32770 | 80 | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | protocolId | totalOctetCount 2057 | 6 | 18000 . . . 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | totalPacketCount 2060 . . . | 65 . . . 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | (49 more records) 2063 . . . | 2064 +-+-+-+-+-+-+-+-+ 2066 Figure 9: File Example Data Set 2068 A.5. Complete File Example 2070 Bringing together the examples above and adding message headers as 2071 appropriate, a hex dump of the first 317 bytes of the example Gile 2072 constructed above would appear as in the annotated Figure 10 below. 2074 [EDITOR'S NOTE: In this figure, xx refers to unassigned IANA IE 2075 numbers as in the IANA Considerations section above; cs refers to 2076 message checksum bytes that depend on the rest of the message 2077 contents. These will have to be replaced if we keep this example 2078 once the IE numbers are assigned.] 2080 0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01 2081 [^ first message header (length 160 bytes) --> 2082 16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04 2083 [^ data template set --> 2084 32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01 2086 48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03 2087 [^ opt template set --> 2088 64: 00 01 xx xx 00 01 xx xx 00 04 xx xx 00 04 01 03 2090 80: 00 02 00 01 xx xx 00 01 xx xx 00 10 01 02 00 09 2092 96: 00 01 xx xx 00 01 00 82 00 04 00 D3 00 04 00 D9 2094 112: 00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 xx xx 2096 128: 00 04 xx xx 00 04 00 00|01 03 00 18 00 cs cs cs 2097 [^ checksum record --> 2098 144: cs cs cs cs cs cs cs cs cs cs cs cs cs 00 00 00 2100 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 2101 [^ second message header (length 80 bytes) --> 2102 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 2103 [^ time window rec -> [ session detail rec ^ --> 2104 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 2106 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 cs 2107 [ message checksum rec ^ --> 2108 240: cs cs cs cs cs cs cs cs cs cs cs cs cs cs cs 00 2110 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 2111 [^ third message header (length 1296 bytes) --> 2112 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 2113 [^ set hdr ][^ first data rec --> 2114 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 2116 Figure 10: File Example Hex Dump 2118 Appendix B. Applicability of IPFIX Files to NetFlow V9 flow storage 2120 As the IPFIX Message format is nearly a superset of the NetFlow V9 2121 packet format, IPFIX Files can be used for store NetFlow V9 data 2122 relatively easily. This section describes a method for doing so. 2123 The differences between the two protocols are outlined in 2124 Appendix B.1 below. A simple, lightweight, message-for-message 2125 translation method for transforming V9 Packets into IPFIX Messages 2126 for storage within IPFIX Files is described in Appendix B.2. An 2127 example of this translation method is given in Appendix B.3. 2129 B.1. Comparing NetFlow V9 to IPFIX 2131 With a few caveats, the IPFIX Protocol is a superset of the NetFlow 2132 V9 protocol, having evolved from it largely through a process of 2133 feature addition to bring it into compliance with the IPFIX 2134 Requirements and the needs of stakeholders within the IPFIX Working 2135 Group. This appendix outlines the differences between the two 2136 protocols. It is informative only, and presented as an exploration 2137 of the two protocols to motivate the usage of IPFIX Files to store 2138 V9-collected flow data. 2140 B.1.1. Message Header Format 2142 Both NetFlow V9 and IPFIX use streams of messages prefixed by a 2143 message header, though the message header differs significantly 2144 between the two. Note that in NetFlow V9 terminology, these messages 2145 are called packets, and messages must be delimited by datagram 2146 boundaries. IPFIX does not have this constraint. The header formats 2147 are detailed below: 2149 0 1 2 3 2150 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 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Version Number | Count | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | sysUpTime | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | UNIX Secs | 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Sequence Number | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Source ID | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 Figure 11: NetFlow V9 Packet Header Format 2165 0 1 2 3 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Version Number | Length | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Export Time | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Sequence Number | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Observation Domain ID | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 Figure 12: IPFIX Message Header Format 2179 Version Number: The IPFIX Version Number MUST be 10, while the 2180 NetFlow V9 Version Number MUST be 9. 2182 Length vs. Count: The Count field in the NetFlow V9 packet header 2183 counts records in the message (including Data and Template 2184 Records), while the Length field in the IPFIX Message Header 2185 counts octets in the message. Note that this implies that NetFlow 2186 V9 collectors must rely on datagram boundaries or some other 2187 external delimeter; or otherwise must completely consume a message 2188 before finding its end. 2190 System Uptime: System uptime in milliseconds is exported in the 2191 NetFlow V9 packet header. This field is not present in the IPFIX 2192 Message Header, and must be exported using an IPFIX Option if 2193 required. 2195 Export Time: Aside from being called UNIX Secs in the NetFlow V9 2196 packet header specification, the export time in seconds since 1 2197 January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX 2198 message headers. 2200 Sequence Number: The NetFlow V9 Sequence Number counts packets, 2201 while the IPFIX Sequence Number counts records in Data Sets. Both 2202 are scoped to Observation Domain. 2204 Observation Domain ID: Similarly, the NetFlow V9 sourceID has 2205 become the IPFIX Observation Domain ID. 2207 B.1.2. Set Header Format 2209 Set headers are identical between NetFlow V9 and IPFIX; that is, each 2210 Set (FlowSet in NetFlow V9 terminology) is prefixed by a 4-byte set 2211 header containing the Set ID and the length of the set in octets. 2213 Note that the special Set IDs are different between IPFIX and NetFlow 2214 V9. IPFIX Template Sets are identified by Set ID 2, while NetFlow V9 2215 Template FlowSets are identified by Set ID 0. Similarly, IPFIX 2216 Options Template Sets are identified by Set ID 3, while NetFlow V9 2217 Options Template FlowSets are identified by Set ID 1. 2219 Both protocols reserve Set IDs 0-255, and use Set IDs 256-65535 for 2220 Data Sets (or FlowSets, in NetFlow V9 terminology). 2222 B.1.3. Template Format 2224 Template FlowSets in NetFlow V9 support a subset of functionality of 2225 those in IPFIX. Specifically, NetFlow V9 does not have any support 2226 for vendor-specific Information Elements as IPFIX does, so there is 2227 no enterprise bit or facility for associating a private enterprise 2228 number with an information element. NetFlow V9 also does not support 2229 variable-length fields. 2231 Options Template FlowSets in NetFlow V9 are similar to Options 2232 Template Sets in IPFIX in the same way. 2234 B.1.4. Information Model 2236 The NetFlow V9 field type definitions are a compatible subset of, and 2237 have evolved in concert with, the IPFIX Information Model. IPFIX 2238 Information Element identifiers in the range 1-127 are defined by the 2239 IPFIX Information Model [RFC5102] to be compatible with the 2240 corresponding NetFlow V9 field types. 2242 B.1.5. Template Management 2244 NetFlow V9 has no concept of a Transport Session as in IPFIX, as 2245 NetFlow V9 was designed with a connectionless transport in mind. 2246 Template IDs are therefore scoped to an Exporting Process lifetime 2247 (i.e., an Exporting Process instance between restarts). There is no 2248 facility in NetFlow V9 as in IPFIX for Template withdrawal or 2249 Template ID reuse. Template retransmission at the Exporter works as 2250 in UDP-based IPFIX Exporting Processes. 2252 B.1.6. Transport 2254 In practice, though NetFlow V9 is designed to be transport- 2255 independent, it is transported only over UDP. There is no facility 2256 as in IPFIX for full connection-oriented transport without datagram 2257 boundaries, due to the use of a record count field as opposed to a 2258 message length field in the packet header. There is no support in 2259 NetFlow V9 for transport layer security via TLS or DTLS. 2261 B.2. A Method for Transforming NetFlow V9 messages to IPFIX 2263 This appendix describes a method for transforming NetFlow V9 Packets 2264 into IPFIX Messages, which can be used to store NetFlow V9 data in 2265 IPFIX Files. A process transforming NetFlow V9 Packets into IPFIX 2266 Messages must handle the fact that NetFlow V9 Packets and IPFIX 2267 Messages are framed differently, that sequence numbering works 2268 differently, and that the NetFlow V9 field type definitions are only 2269 compatible with the IPFIX Information Model below Information Element 2270 identifier 128. 2272 For each incoming NetFlow V9 packet, the transformation process must: 2274 1. Verify that the Version field of the packet header is 9. 2276 2. Verify that the Sequence Number field of the packet header is 2277 valid. 2279 3. Scan the packet to: 2281 1. verify that it contains no Templates with field types outside 2282 the range 1-127; 2284 2. verify that it contains no FlowSets with Set IDs between 2 2285 and 255 inclusive; 2287 3. verify that it contains the number of records in FlowSets, 2288 Template FlowSets, and Options Template FlowSets declared in 2289 the Count field of the packet header; and 2291 4. count the number of records in Data FlowSets for calculating 2292 the IPFIX Sequence Number. 2294 4. Calculate a Sequence Number for each IPFIX Observation Domain by 2295 storing the last Sequence Number sent for each Observation Domain 2296 plus the count of records in Data FlowSets in the previous step 2297 to be sent as the Sequence Number for the IPFIX Message following 2298 this one within that Observation Domain. 2300 5. Generate a new IPFIX Message Header with: 2302 1. a Version field of 10; 2304 2. a Length field with the number of octets in the IPFIX 2305 Message, generally available by subtracting 4 from the length 2306 of the NetFlow V9 packet as returned from the transport layer 2307 (accounting for the difference in message header lengths); 2309 3. the Sequence Number calculated for this message by the 2310 Sequence Number calculation step; and 2312 4. Export Time and Observation Domain ID taken from the UNIX 2313 secs and Source ID fields of the NetFlow V9 packet header, 2314 respectively. 2316 6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message 2317 after the header. Replace Set ID 0 with Set ID 2 for Template 2318 Sets, and Set ID 1 with Set ID 3 for Options Template Sets. 2320 Note that this process loses system uptime information; if such 2321 information is required, the transformation process will have to 2322 export that information using IPFIX Options. This may require a more 2323 sophisticated transformation process structure. 2325 B.3. NetFlow V9 Transformation Example 2327 The following two figures show a single NetFlow V9 packet with 2328 templates and the corresponding IPFIX Message, exporting a single 2329 flow record representing 60,303 octets sent from 192.0.2.2 to 2330 192.0.2.3. This would be the 3rd packet exported in Observation 2331 Domain 33 from the NetFlow V9 exporter, containing records starting 2332 with the 12th record (packet and record sequence numbers count from 2333 0). 2335 The ** symbol in the IPFIX example shows those fields that required 2336 modification from the NetFlow V9 packet by the transformation 2337 process. 2339 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 | Version = 9 | Count = 2 | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Uptime = 3750405 ms (1:02:30.405) | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Sequence Number = 2 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Observation Domain ID = 33 | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Set ID = 0 | Set Length = 20 | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Template ID = 256 | Field Count = 3 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 | IPV4_SRC_ADDR = 8 | Field Length = 4 | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | IPV4_DST_ADDR = 12 | Field Length = 4 | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | IN_BYTES = 1 | Field Length = 4 | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | Set ID = 256 | Set Length = 16 | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | IPV4_SRC_ADDR | 2365 | 192.0.2.2 | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | IPV4_DST_ADDR | 2368 | 192.0.2.3 | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | IN_BYTES | 2371 | 60303 | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 Figure 13: Example NetFlow V9 Packet 2375 1 2 3 2376 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 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | ** Version = 10 | ** Length = 52 | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | ** Sequence Number = 11 | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Observation Domain ID = 33 | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | ** Set ID = 2 | Set Length = 20 | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Template ID = 256 | Field Count = 3 | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 |0| sourceIPv4Address = 8 | Field Length = 4 | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 |0| destinationIPv4Address = 12 | Field Length = 4 | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 |0| octetDeltaCount = 1 | Field Length = 4 | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | Set ID = 256 | Set Length = 16 | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | sourceIPv4Address | 2399 | 192.0.2.2 | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | destinationIPv4Address | 2402 | 192.0.2.3 | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | octetDeltaCount | 2405 | 60303 | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 Figure 14: Corresponding Example IPFIX Message 2410 Authors' Addresses 2412 Brian Trammell 2413 Hitachi Europe 2414 c/o ETH Zurich 2415 Gloriastrasse 35 2416 8092 Zurich 2417 Switzerland 2419 Phone: +41 44 632 70 13 2420 Email: brian.trammell@hitachi-eu.com 2421 Elisa Boschi 2422 Hitachi Europe 2423 c/o ETH Zurich 2424 Gloriastrasse 35 2425 8092 Zurich 2426 Switzerland 2428 Phone: +41 44 632 70 57 2429 Email: elisa.boschi@hitachi-eu.com 2431 Lutz Mark 2432 Fraunhofer IFAM 2433 Weiner Str. 12 2434 38259 Bremen 2435 Germany 2437 Phone: +49 421 2246206 2438 Email: lutz.mark@ifam.fraunhofer.de 2440 Tanja Zseby 2441 Fraunhofer Institute for Open Communication Systems 2442 Kaiserin-Augusta-Allee 31 2443 10589 Berlin 2444 Germany 2446 Phone: +49 30 3463 7153 2447 Email: tanja.zseby@fokus.fraunhofer.de 2449 Arno Wagner 2450 ETH Zurich 2451 Gloriastrasse 35 2452 8092 Zurich 2453 Switzerland 2455 Phone: +41 44 632 70 04 2456 Email: arno@wagner.name 2458 Full Copyright Statement 2460 Copyright (C) The IETF Trust (2008). 2462 This document is subject to the rights, licenses and restrictions 2463 contained in BCP 78, and except as set forth therein, the authors 2464 retain all their rights. 2466 This document and the information contained herein are provided on an 2467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2469 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2470 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2471 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2474 Intellectual Property 2476 The IETF takes no position regarding the validity or scope of any 2477 Intellectual Property Rights or other rights that might be claimed to 2478 pertain to the implementation or use of the technology described in 2479 this document or the extent to which any license under such rights 2480 might or might not be available; nor does it represent that it has 2481 made any independent effort to identify any such rights. Information 2482 on the procedures with respect to rights in RFC documents can be 2483 found in BCP 78 and BCP 79. 2485 Copies of IPR disclosures made to the IETF Secretariat and any 2486 assurances of licenses to be made available, or the result of an 2487 attempt made to obtain a general license or permission for the use of 2488 such proprietary rights by implementers or users of this 2489 specification can be obtained from the IETF on-line IPR repository at 2490 http://www.ietf.org/ipr. 2492 The IETF invites any interested party to bring to its attention any 2493 copyrights, patents or patent applications, or other proprietary 2494 rights that may cover technology that may be required to implement 2495 this standard. Please address the information to the IETF at 2496 ietf-ipr@ietf.org.