idnits 2.17.1 draft-trammell-ipfix-biflow-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 729. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 372: '... biflow export SHOULD assign the for...' RFC 2119 keyword, line 382: '... processes SHOULD switch to a templa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 19, 2006) is 6521 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) == Unused Reference: 'I-D.ietf-ipfix-reqs' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipfix-as' is defined on line 677, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-21 == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-11 == Outdated reference: A later version (-02) exists of draft-boschi-ipfix-reducing-redundancy-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.boschi-ipfix-reducing-redundancy' == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-08 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft CERT/NetSA 4 Expires: December 21, 2006 E. Boschi 5 Hitachi Europe 6 June 19, 2006 8 Bidirectional Flow Export using IPFIX 9 draft-trammell-ipfix-biflow-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes an efficient method for exporting 43 bidirectional flow (Biflow) information using the IP Flow Information 44 Export (IPFIX) protocol, representing each Biflow using a single Flow 45 Record. It proposes two alternatives for information model 46 extensions to support this method, for the consideration of the IPFIX 47 Working Group. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Biflow Semantics . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Existing Biflow Implementation Strategies . . . . . . . . . . 6 55 4.1. Two-Record Biflow Export using Record Adjacency . . . . . 6 56 4.2. Record Adjacency Example . . . . . . . . . . . . . . . . . 7 57 4.3. Key-Value Separation using commonPropertiesId . . . . . . 8 58 5. Single Record Biflows . . . . . . . . . . . . . . . . . . . . 9 59 5.1. New Reverse Information Elements . . . . . . . . . . . . . 10 60 5.2. Reverse Information Element Private Enterprise Number . . 10 61 5.3. Single Record Biflow Examples . . . . . . . . . . . . . . 12 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 70 Intellectual Property and Copyright Statements . . . . . . . . . . 18 72 1. Introduction 74 Many flow analysis tasks benefit from association of the upstream and 75 downstream flows of a bidirectional communication, e.g., separating 76 answered and unanswered TCP requests, calculating round trip times, 77 etc. Metering processes that are not part of an asymmetric routing 78 infrastructure, especially those deployed within a single Observation 79 Domain through which bidirectional traffic flows, are well positioned 80 to observe bidirectional flows (Biflows). In such topologies, the 81 total resource requirements for Biflow assembly are often lower if 82 the Biflows are assembled at the Metering Process as opposed to the 83 Collecting Process. IPFIX requires only information model extensions 84 to be complete as a solution for exporting Biflow data. 86 To that end, we propose a Single Record Biflow export method in 87 section 5 of this document. This method requires additional 88 Information Elements to represent the reverse direction of each 89 biflow; so Section 5 also presents two alternatives for policies that 90 may be used to allocate these Information Elements. This method is 91 motivated by an exploration of other possible methods of Biflow 92 export; indeed, IPFIX may currently be used to export Biflow data 93 without information model extensions at all, but the methods for 94 doing so have important drawbacks. We describe these methods, their 95 advantages, and their disadvantages in section 4. 97 2. Terminology 99 The terms in this section are in line with the Terminology section of 100 the IPFIX Protocol [I-D.ietf-ipfix-protocol]. 102 Flow: A Flow is a set of IP packets passing an Observation Point in 103 the network during a certain time interval. All packets belonging 104 to a particular Flow have a set of common properties. Each 105 property is defined as the result of applying a function to the 106 values of: 108 1. One or more packet header fields, transport header fields, or 109 application header fields. 111 2. One or more characteristics of the packet itself. 113 3. One or more fields derived from packet treatment. 115 A packet is said to belong to a Flow if it completely satisfies 116 all the defined properties of the Flow. This definition covers 117 the range from a Flow containing all packets observed at a network 118 interface to a Flow consisting of just a single packet between two 119 applications. It includes packets selected by a sampling 120 mechanism. 122 Flow Key: Each of the fields which 124 1. Belong to the packet header (e.g. destination IP address) 126 2. Are a property of the packet itself (e.g. packet length) 128 3. Are derived from packet treatment (e.g. AS number) 130 and which are used to define a Flow are termed Flow Keys. 132 Directional Key Field: A Directional Key Field is a single field in 133 a Flow Key as defined in the IPFIX Protocol [I-D.ietf-ipfix- 134 protocol] that is specifically associated with a single endpoint 135 of the flow. sourceIPv4Address and destinationTransportPort are 136 example directional key fields. 138 Non-directional Key Field: A Non-directional Key Field is a single 139 field within a Flow Key as defined in the IPFIX Protocol 140 [I-D.ietf-ipfix-protocol] that is not specifically associated with 141 either endpoint of the flow. protocolIdentifier is an example non- 142 directional key field. 144 Uniflow (unidirectional flow): A Uniflow is a Flow, as above, 145 restricted such that the Flow must be composed only of packets 146 sent from a single endpoint to another single endpoint. 148 Biflow (bidirectional flow): A Biflow is a Flow composed of packets 149 sent in both directions between two endpoints. A Biflow may also 150 be defined as composed from two Uniflows such that: 152 1. each Non-directional Key Field of each Uniflow is identical to 153 its counterpart in the other 155 2. each Directional Key Field of each Uniflow is identical to its 156 reverse direction counterpart in the other 158 3. Biflow Semantics 160 As stated in the Terminology section above, a Biflow is simply a Flow 161 representing packets flowing in both directions between two endpoints 162 on a network. There are compelling reasons to treat Biflows as 163 single entities within IPFIX. First, as most network communication 164 is inherently bidirectional, a Biflow-based data model more 165 accurately represents the behavior of the network, and enables easier 166 application of flow data to answering interesting questions about 167 network behavior. Second, exporting Biflow data can result in 168 improved export efficiency, by eliminating the duplication of Flow 169 Key data in an IPFIX message stream. 171 Considering Biflows as single entities does introduce some additional 172 semantic considerations within the IPFIX information model. When 173 handling Uniflows, the semantics of "source" and "destination" 174 Information Elements are clearly defined by the semantics of the 175 underlying packet header data. When grouping Biflows into single 176 IPFIX Data Records, the definitions of "source" and "destination" 177 become less clear. 179 The most basic method for classifying the two addresses in a Biflow 180 is to define the source and destination addresses of the flow as the 181 source and destination addresses of the packet initiating the flow, 182 respectively. This can be roughly approximated by a Metering Process 183 by simply assuming the first packet seen in a given Biflow is the 184 packet initiating the flow. Some metering technologies may improve 185 upon this method using some knowledge of the transport or application 186 protocols (e.g., TCP flags, DNS question/answer counts) to better 187 approximate the flow-initiating packet. These techniques are 188 especially useful when assembling Biflows from lossy packet sources. 190 Other methods of assigning direction exist. One alternate way to 191 classify Biflow addresses is by perimeter; in this method, the 192 Metering Process discriminates between "inside" and "outside" a 193 network of interest, and defines the source address as the address on 194 one side of this perimeter (generally the "outside" address; defining 195 source loosely as "attacker"). This approach is popular in security- 196 focused flow collection tools. 198 In any case, the design is the same: one of the Uniflow halves is 199 assumed to be in the "forward" direction, and one in the "reverse" 200 direction; which is the "forward" half is selected based upon some 201 characteristic of the connection itself. Note that as long as these 202 directions are assigned consistently, and there exists sufficient 203 information in the flow record for the Collecting Process to make its 204 own determination as to the flow's direction, the Metering Process' 205 assignment of flow direction is irrelevant. However, for the sake of 206 simplicity and consistency, we recommend the flow initiator method of 207 direction assignment. 209 Note that, by the definition of Observation Domain in section 2 of 210 the IPFIX Protocol [I-D.ietf-ipfix-protocol], Biflows may be composed 211 only of packets observed within the same Observation Domain. This 212 implies that Metering Processes that build Biflows out of Uniflow 213 halves must ensure that the two Uniflow halves were observed within 214 the same Observation Domain. 216 4. Existing Biflow Implementation Strategies 218 This section describes methods by which Biflow data may be presently 219 exported using IPFIX, without any IPFIX information model extensions. 220 We do not recommend these approaches, but present them in order to 221 explore the advantages and drawbacks of these methods to provide a 222 motivation for the proposed Single Record Biflow export method. 224 4.1. Two-Record Biflow Export using Record Adjacency 226 The simplest presently available way for an Exporting Process that 227 uses a Biflow-based internal data model to implement flow export 228 using IPFIX is simply to split the Biflow into two Uniflow records at 229 export time. The two Uniflow sides of the Biflow can then be placed 230 adjacent to each other in the IPFIX Message, with the initiating 231 Uniflow (the first Uniflow seen by the Metering Process) appearing in 232 the message first. This simple arrangement provides enough 233 information for a Collecting Process which uses a Biflow-based 234 internal data model to reassemble the Biflow without requiring any 235 computationally-intensive flow matching. When using this method the 236 order of the Uniflow records becomes crucial, and must be maintained 237 by both the Exporting and Collecting Processes. 239 This method does have the benefit of extreme simplicity. However, it 240 also has the disadvantage of extreme simplicity. It is not a 241 protocol so much as an informal arrangement; Collecting Processes 242 with Biflow-based internal data models cannot rely on the courtesy of 243 the Exporting Process to arrange Biflow halves adjacently in the flow 244 record stream and so must support computationally-intensive flow 245 matching anyway. No explicit association is made between the two 246 uniflow half records. It is also record space inefficient in that 247 every key field in the first Uniflow, whether directional or non- 248 directional, is duplicated in the second Uniflow record. 250 Additionally, because UDP and SCTP Unreliable transports may drop 251 and/or reorder packets, if these transports are used and the 252 Exporting Process is using record adjacency for biflow export, the 253 Exporting Process is responsible for ensuring that the two Flow 254 Records describing the two Uniflow halves are not divided by a 255 message boundary. 257 While the Record Adjacency method is simple, and is presently 258 available, its relative export size inefficiency and lack of any 259 actual association between Uniflows suggest the need for a better 260 Biflow export method. 262 4.2. Record Adjacency Example 264 Assuming that each Uniflow record is described by the following 265 simple template: 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Set ID = 2 | Length = 40 | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Template ID >= 256 | Field Count = 8 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |0| flowStartSeconds 150 | Field Length = 4 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |0| sourceIPv4Address 8 | Field Length = 4 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |0| destinationIPv4Address 12 | Field Length = 4 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |0| sourceTransportPort 7 | Field Length = 2 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |0| destinationTransportPort 11 | Field Length = 2 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |0| protocolIdentifier 4 | Field Length = 1 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |0| octetTotalCount 85 | Field Length = 4 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |0| packetTotalCount 86 | Field Length = 4 | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 1: Record Adjacency Template Set Example 291 a two-record adjacent Biflow counting octets and packets in a typical 292 HTTP transaction might look like the following: 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Set ID >= 256 | Length = 54 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | 2006-02-01 17:00:00 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | 192.0.2.2 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | 192.0.2.3 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | 32770 | 80 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | 6 | 18000 . . . 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 . . . | 65 . . . 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 . . . | 2006-02-01 17:00:01 . . . 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 . . . | 192.0.2.3 . . . 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 . . . | 192.0.2.2 . . . 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 . . . | 80 | 32770 . . . 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 . . . | 6 | 128000 . . . 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 . . . | 110 . . . 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 . . . | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2: Record Adjacency Data Set Example 326 Notice that this trivial example duplicates 13 bytes of key 327 information per Biflow. 329 4.3. Key-Value Separation using commonPropertiesId 331 The method described in Reducing Redundancy in IPFIX and PSAMP 332 Reports [I-D.boschi-ipfix-reducing-redundancy] can be used to improve 333 Biflow export bandwidth efficiency over the record adjacency method. 334 This method separates the export of information common to a set of 335 flow records from the export of the individual flow records, linking 336 them with an index, the commonPropertiesID Information Element. 338 For Biflow export, the Flow Keys and any other fields common to the 339 Biflow are exported within a data record defined by an Option 340 Template, containing a commonPropertiesID Information Element as 341 scope. This commonPropertiesID uniquely identifies that set of 342 properties and hence the Biflow itself. The individual Uniflow 343 properties are then exported using one Flow Record per direction, 344 each referencing the Biflow keys by the unique commonPopertiesID. 346 While this solution has the potential for significant bandwidth 347 efficiency gains, and is widely applicable to a variety of bandwidth- 348 reduction use cases, it is not yet an optimal method for Biflow 349 export. First, the management of the commonPropertiesID for each 350 biflow requires additional resources at both the Exporting Process 351 and the Collecting Process. Second, instead of two records per 352 Biflow as in the Record Adjacency method, the Reducing Redundancy 353 method requires three. The set headers required to switch between 354 common properties and specific properties templates also add slight 355 bandwidth overhead. 357 5. Single Record Biflows 359 The most direct method for exporting Biflows using IPFIX is to use a 360 single Flow Record to represent each Biflow. Each of these Flow 361 Records will contain the Flow Key fields once, and both forward and 362 reverse direction information elements for each non-key field. This 363 proposal requires extending the IPFIX Information Model to provide 364 for reverse value fields. This extension will cover most or all of 365 the information model, creating a "reverse" Information Element 366 counterpart to each presently defined "forward" Information Element, 367 because any Information Element that may be a non-key field in a 368 Biflow will require a counterpart. 370 The semantics of these single-record Biflows are outlined in section 371 3, above. Metering Process implementations using single-record 372 biflow export SHOULD assign the forward and reverse direction such 373 that the forward direction treats the flow initiator as source, to 374 the best ability of the metering process to determine the flow 375 initiator. 377 If a flow has no reverse direction -- that is, it is composed of a 378 single Uniflow without another Uniflow in response -- it may only be 379 represented as a single record Biflow if its only reverse value 380 fields are counters. This is because the IPFIX Information Model 381 makes no distinction between zeroes and null values. Exporting 382 processes SHOULD switch to a template containing no reverse 383 Information Elements when exporting flows without a reverse 384 direction. Note that Flow Records containing no directional key 385 fields (e.g., Flow Records representing aggregate octet counts by 386 protocolIdentifier) cannot, by definition, have a reverse direction. 388 We have identified two possible methods for extending the information 389 model to include the required reverse Information Elements. The 390 first and simpler method would be to add one new "reverse" 391 Information Element to the information model for each Information 392 Element subject to reversal in a single-record Biflow. The second 393 and more convenient method would be to assign a special Private 394 Enterprise Number (PEN) that creates a new reverse information 395 element number space. Note that the choice between these methods 396 impacts template representation of information elements only; the 397 Data Records in which single-record Biflows are exported are 398 identical with either assignment method. These methods are described 399 in more detail below. The intent is to select one of these two 400 methods; we present both here to promote discussion. 402 5.1. New Reverse Information Elements 404 As every Information Element in the information model that may appear 405 as a non-key field in a Flow Record is subject to reversal, and the 406 information model does not generally restrict Information Elements to 407 key or non-key roles, single-record biflow export will require a 408 great number of new reverse information elements. Only certain 409 identifiers (flowId, templateId, and sourceId, from section 5.1 in 410 the IPFIX Information Model [I-D.ietf-ipfix-info]), and metering and 411 export process properties (section 5.2 in the IPFIX Information Model 412 [I-D.ietf-ipfix-info]) are not subject to reversal. 414 The IPFIX Information Model has more than adequate number space for 415 official information element expansion - 32768 IANA-managed 416 information elements are available, of which less than 250 have been 417 allocated or reserved. The addition of fewer than 250 new reverse 418 elements would not place significant strain on available number 419 space. However, the additional reverse information elements are not 420 so much a discrete list of new Information Elements as a new 421 dimension in the information model. This increases the effort 422 required to manage the future extension of the IPFIX Information 423 Model, adding a new task to this process: that of evaluating the 424 reversibility of each new proposed Information Element and ensuring 425 that every new Information Element that should have a reverse 426 counterpart does. It also effectively reduces the available IANA- 427 managed information element number space by half. 429 A complete list of reverse IEs required to implement this method will 430 appear in a future revision of this draft if working group consensus 431 moves toward this method. 433 5.2. Reverse Information Element Private Enterprise Number 435 Concerns have been raised in past deliberations of the IPFIX Working 436 Group about adding information model dimensions; a real solution 437 would probably require protocol changes and hence is outside the 438 scope of this draft. However, another more elegant short term 439 solution may be possible by leveraging private enterprise information 440 elements. 442 Instead of defining multiple new reverse information elements, it 443 would also be possible to have IANA assign a single PEN to this 444 draft, and to define that PEN to signify "IPFIX Reverse Information 445 Element" (the Reverse PEN). This reverse PEN would serve as a 446 "reverse direction flag" in the template; each Information Element 447 number within this PEN space would be assigned to the reverse 448 counterpart of the corresponding IANA-assigned public Information 449 Element number. In other words, to generate a reverse information 450 element in a template corresponding to a given forward information 451 element, simply set the enterprise bit and define the Information 452 Element within the Reverse PEN space, as in the figure below. 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |0| flowStartSeconds 150 | Field Length = 4 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 forward | 459 | 460 reverse V 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |1| reverseFlowStartSeconds 150 | Field Length = 4 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | reverse PEN TBA | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 3: Example Mapping between Forward and Reverse IEs using 469 Reverse PEN 471 This approach has the advantage of flexibility. It treats a new 472 number space dimension explicitly as a dimension. New Information 473 Elements can be added freely to the IANA-managed space without 474 concern for whether a reverse element should also be added. Aside 475 from the initial allocation of an enterprise number for this purpose, 476 there is no additional maintenance overhead for supporting reverse 477 information elements in the information model. The approach is also 478 parallel with early proposals to add explicit information model 479 dimensioning in a future revision of the IPFIX Protocol. 481 The primary drawback of this method is that it may slightly abuse the 482 intent of the IANA Enterprise Number registry; this concern is 483 detailed in the IANA Considerations section below. 485 5.3. Single Record Biflow Examples 487 The following template describes a simple Biflow record equivalent to 488 the Record Adjacency example in section 4.2, using new information 489 elements for the reverse-direction fields; these new information 490 elements are denoted as TBA, as they have not been assigned by IANA. 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Set ID = 2 | Length = 52 | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Template ID >= 256 | Field Count = 11 | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |0| flowStartSeconds 150 | Field Length = 4 | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |0| reverseFlowStartSeconds TBA | Field Length = 4 | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |0| sourceIPv4Address 8 | Field Length = 4 | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |0| destinationIPv4Address 12 | Field Length = 4 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |0| sourceTransportPort 7 | Field Length = 2 | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 |0| destinationTransportPort 11 | Field Length = 2 | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |0| protocolIdentifier 4 | Field Length = 1 | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |0| octetTotalCount 85 | Field Length = 4 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |0| reverseOctetTotalCount TBA | Field Length = 4 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |0| packetTotalCount 86 | Field Length = 4 | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |0| reversePacketTotalCount TBA | Field Length = 4 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 4: Single Record Biflow Template Set with New IEs 522 The following template describes the same data record as the previous 523 one, but using the "IPFIX Reverse Information Element" PEN assigned 524 for the purpose of differentiating forward from reverse information 525 elements. This private enterprise number is denoted as TBA, as it 526 has not yet been assigned by IANA. 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Set ID = 2 | Length = 64 | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Template ID >= 256 | Field Count = 11 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |0| flowStartSeconds 150 | Field Length = 4 | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |1| reverseFlowStartSeconds 150 | Field Length = 4 | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | reverse PEN TBA | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |0| sourceIPv4Address 8 | Field Length = 4 | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 |0| destinationIPv4Address 12 | Field Length = 4 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |0| sourceTransportPort 7 | Field Length = 2 | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 |0| destinationTransportPort 11 | Field Length = 2 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |0| protocolIdentifier 4 | Field Length = 1 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |0| octetTotalCount 85 | Field Length = 4 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |1| reverseOctetTotalCount 85 | Field Length = 4 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | reverse PEN TBA | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 |0| packetTotalCount 86 | Field Length = 4 | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |1| reversePacketTotalCount 86 | Field Length = 4 | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | reverse PEN TBA | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 5: Single Record Biflow Template Set with Reverse PEN 564 Whether reverse information elements are assigned directly or 565 implicitly by private enterprise number, both templates above 566 describe the example single record Biflow below, which represents the 567 same typical HTTP transaction as in example 4.2. 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Set ID >= 256 | Length = 41 | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | 2006-02-01 17:00:00 | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | 2006-02-01 17:00:01 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | 192.0.2.2 | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | 192.0.2.3 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | 32770 | 80 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | 6 | 18000 . . . 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 . . . | 128000 . . . 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 . . . | 65 . . . 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 . . . | 110 . . . 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 . . . | 591 +-+-+-+-+-+-+-+-+ 593 Figure 6: Single Record Biflow Data Set 595 6. IANA Considerations 597 As specified in the IPFIX Information Model [I-D.ietf-ipfix-info], 598 IANA will create a new registry for IPFIX Information Element 599 Numbers. New assignments for IPFIX Information Elements will be 600 administered by IANA, on a First Come First Served basis, subject to 601 Expert Review as per RFC 2434 [RFC2434], i.e. review by one of a 602 group of expert designated by an IETF Operations and Management Area 603 Director. The group of experts must double check the Information 604 Element definitions against Information Elements already defined for 605 completeness, accuracy, redundancy, and conformance to the naming 606 conventions in the IPFIX Information Model [I-D.ietf-ipfix-info]. 607 Those experts will initially be drawn from the Working Group Chairs 608 and document editors of the IPFIX and PSAMP Working Groups, as noted 609 in the IPFIX Information Model [I-D.ietf-ipfix-info]. 611 This document proposes a set of new IPFIX Information Elements that 612 extend those already defined in the information model; depending on 613 the method selected to add these new Information Elements, either 614 each Information Element or a single Reverse PEN must be assigned by 615 IANA. Identifiers that have not yet been assigned by IANA are 616 denoted "TBA" (To Be Assigned) in this document. 618 If the consensus of the Working Group is to assign separate numbers 619 to each reverse-direction Information Element as in Section 5.1, each 620 of these reverse information elements will need to be assigned from 621 the IANA IPFIX Information Element Number registry. 623 If the consensus of the Working Group is to assign a single Reverse 624 PEN for reverse-direction Information Elements, this PEN will need to 625 be assigned from the IANA Enterprise Number registry. The authors 626 are in contact with IANA on this issue, and plan to have a PEN 627 assigned to this draft, with the authors themselves as point of 628 contact. A more definitive statement on the status of this Reverse 629 PEN will appear in the IANA Considerations section of the next 630 revision of this draft. 632 7. Security Considerations 634 The same security considerations as for the IPFIX Protocol [I-D.ietf- 635 ipfix-protocol] apply. 637 8. Open Issues 639 We must select one policy for allocating reverse information 640 elements. This single selection will appear in the next revision of 641 this document [bht, eb]. 643 9. Acknowledgements 645 We would like to thank Lutz Mark, Juergen Quittek, Andrew Johnson, 646 Paul Aitken, Benoit Claise, and Carsten Schmoll for their 647 contributions and comments. Special thanks to Michelle Cotton for 648 her assistance in navigating the IANA process for enterprise number 649 assignment. 651 10. References 653 10.1. Normative References 655 [I-D.ietf-ipfix-protocol] 656 Claise, B., "IPFIX Protocol Specification", 657 draft-ietf-ipfix-protocol-21 (work in progress), 658 April 2006. 660 [I-D.ietf-ipfix-info] 661 Quittek, J., "Information Model for IP Flow Information 662 Export", draft-ietf-ipfix-info-11 (work in progress), 663 September 2005. 665 [I-D.boschi-ipfix-reducing-redundancy] 666 Boschi, E. and L. Mark, "Reducing redundancy in IPFIX and 667 PSAMP reports", draft-boschi-ipfix-reducing-redundancy-01 668 (work in progress), March 2006. 670 10.2. Informative References 672 [I-D.ietf-ipfix-reqs] 673 Quittek, J., "Requirements for IP Flow Information 674 Export", draft-ietf-ipfix-reqs-16 (work in progress), 675 June 2004. 677 [I-D.ietf-ipfix-as] 678 Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-08 679 (work in progress), June 2006. 681 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 682 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 683 October 1998. 685 Authors' Addresses 687 Brian H. Trammell 688 CERT Network Situational Awareness 689 Software Engineering Institute 690 4500 Fifth Avenue 691 Pittsburgh, PA 15213 692 US 694 Phone: +1 412 268 9748 695 Email: bht@cert.org 697 Elisa Boschi 698 Hitachi Europe SAS 699 Immueble Le Theleme 700 1503 Route les Dolines 701 Valbonne 06560 702 France 704 Phone: +33 4 89874180 705 Email: elisa.boschi@hitachi-eu.com 707 Intellectual Property Statement 709 The IETF takes no position regarding the validity or scope of any 710 Intellectual Property Rights or other rights that might be claimed to 711 pertain to the implementation or use of the technology described in 712 this document or the extent to which any license under such rights 713 might or might not be available; nor does it represent that it has 714 made any independent effort to identify any such rights. Information 715 on the procedures with respect to rights in RFC documents can be 716 found in BCP 78 and BCP 79. 718 Copies of IPR disclosures made to the IETF Secretariat and any 719 assurances of licenses to be made available, or the result of an 720 attempt made to obtain a general license or permission for the use of 721 such proprietary rights by implementers or users of this 722 specification can be obtained from the IETF on-line IPR repository at 723 http://www.ietf.org/ipr. 725 The IETF invites any interested party to bring to its attention any 726 copyrights, patents or patent applications, or other proprietary 727 rights that may cover technology that may be required to implement 728 this standard. Please address the information to the IETF at 729 ietf-ipr@ietf.org. 731 Disclaimer of Validity 733 This document and the information contained herein are provided on an 734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 736 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 737 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 738 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 741 Copyright Statement 743 Copyright (C) The Internet Society (2006). This document is subject 744 to the rights, licenses and restrictions contained in BCP 78, and 745 except as set forth therein, the authors retain all their rights. 747 Acknowledgment 749 Funding for the RFC Editor function is currently provided by the 750 Internet Society.