idnits 2.17.1 draft-ietf-ipfix-architecture-11.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1363. ** 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 184: '...n Domain. It is RECOMMENDED that Obse...' 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 6493 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) ** Downref: Normative reference to an Informational RFC: RFC 3917 (ref. '1') == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-08 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-10 == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-as (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '5') (Obsoleted by RFC 3550) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Flow Information Export WG G. Sadasivan 3 (ipfix) Cisco Systems, Inc. 4 Internet-Draft N. Brownlee 5 Expires: December 21, 2006 CAIDA | The University of Auckland 6 B. Claise 7 Cisco Systems, Inc. 8 J. Quittek 9 NEC Europe Ltd. 10 June 19, 2006 12 Architecture for IP Flow Information Export 13 draft-ietf-ipfix-architecture-11 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 21, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This memo defines the IP Flow Information eXport (IPFIX) architecture 47 for the selective monitoring of IP flows, and for the export of 48 measured IP flow information from an IPFIX device to a collector. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Examples of Flows . . . . . . . . . . . . . . . . . . . . . . 8 57 4. IPFIX Reference Model . . . . . . . . . . . . . . . . . . . . 10 58 5. IPFIX Functional and Logical Blocks . . . . . . . . . . . . . 11 59 5.1. Metering Process . . . . . . . . . . . . . . . . . . . . . 11 60 5.1.1. Flow Expiration . . . . . . . . . . . . . . . . . . . 12 61 5.1.2. Flow Export . . . . . . . . . . . . . . . . . . . . . 12 62 5.2. Observation Point . . . . . . . . . . . . . . . . . . . . 13 63 5.3. Selection Criteria for Packets . . . . . . . . . . . . . . 13 64 5.3.1. Sampling Functions, Si . . . . . . . . . . . . . . . . 14 65 5.3.2. Filter Functions, Fi . . . . . . . . . . . . . . . . . 14 66 5.4. Observation Domain . . . . . . . . . . . . . . . . . . . . 14 67 5.5. Exporting Process . . . . . . . . . . . . . . . . . . . . 15 68 5.6. Collecting Process . . . . . . . . . . . . . . . . . . . . 15 69 5.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Overview of the IPFIX Protocol . . . . . . . . . . . . . . . . 17 71 6.1. Information Model Overview . . . . . . . . . . . . . . . . 18 72 6.2. Flow Records . . . . . . . . . . . . . . . . . . . . . . . 18 73 6.3. Control Information . . . . . . . . . . . . . . . . . . . 18 74 6.4. Reporting Responsibilities . . . . . . . . . . . . . . . . 19 75 7. IPFIX Protocol Details . . . . . . . . . . . . . . . . . . . . 20 76 7.1. The IPFIX Basis Protocol . . . . . . . . . . . . . . . . . 20 77 7.2. IPFIX Protocol on the Collecting Process . . . . . . . . . 21 78 7.3. Support for Applications . . . . . . . . . . . . . . . . . 21 79 8. Export Models . . . . . . . . . . . . . . . . . . . . . . . . 21 80 8.1. Export with Reliable Control Connection . . . . . . . . . 21 81 8.2. Collector Failure Detection and Recovery . . . . . . . . . 22 82 8.3. Collector Redundancy . . . . . . . . . . . . . . . . . . . 22 83 9. IPFIX Flow Collection in Special Situations . . . . . . . . . 22 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 10.1. Data Security . . . . . . . . . . . . . . . . . . . . . . 24 86 10.1.1. Host-Based Security . . . . . . . . . . . . . . . . . 24 87 10.1.2. Authentication-only . . . . . . . . . . . . . . . . . 24 88 10.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . . 25 89 10.2. IPFIX End-point Authentication . . . . . . . . . . . . . . 25 90 10.3. IPFIX Overload . . . . . . . . . . . . . . . . . . . . . . 25 91 10.3.1. Denial of Service (DoS) Attack Prevention . . . . . . 26 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 11.1. Numbers used in the Protocol . . . . . . . . . . . . . . . 26 94 11.2. Numbers used in the Information Model . . . . . . . . . . 27 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 98 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 99 Appendix A. Changes/Issues from the -10 Draft . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . . . . 31 103 1. Introduction 105 There are several applications e.g., usage-based accounting, traffic 106 profiling, traffic engineering, attack/intrusion detection, QoS 107 monitoring, that require flow-based IP traffic measurements. It is 108 therefore important to have a standard way of exporting information 109 related to IP flows. This document defines an architecture for IP 110 traffic flow monitoring, measuring and exporting. It provides a 111 high-level description of an IPFIX device's key components and their 112 functions. 114 1.1. Document Scope 116 This document defines the architecture for IPFIX. Its main 117 objectives are to: 119 o Describe the key IPFIX architectural components, consisting of (at 120 least) IPFIX devices and collectors communicating using the IPFIX 121 protocol. 123 o Define the IPFIX architectural requirements, e.g., recovery, 124 security, etc. 126 o Describe the characteristics of the IPFIX protocol. 128 1.2. IPFIX Documents Overview 130 The IPFIX protocol provides network administrators with access to IP 131 flow information. This document specifies the architecture for the 132 export of measured IP flow information from an IPFIX exporting 133 process to a collecting process, per the requirements defined in 134 IPFIX-REQS [1]. The IPFIX protocol document IPFIX-PROTO [3] 135 specifies how IPFIX data records and templates are carried via a 136 congestion-aware transport protocol from IPFIX exporting process to 137 IPFIX collecting process. IPFIX has a formal description of IPFIX 138 information elements (fields), their name, type and additional 139 semantic information, as specified in IPFIX-INFO [2]. Finally 140 IPFIX-AS [4] describes what type of applications can use the IPFIX 141 protocol and how they can use the information provided. It 142 furthermore shows how the IPFIX framework relates to other 143 architectures and frameworks. 145 Note that the IPFIX system does not provide for remote configuration 146 of an IPFIX device. Instead, implementors must provide an effective 147 way to configure their IPFIX devices. 149 2. Terminology 151 The definitions of basic IPFIX terms such as IP Traffic Flow, 152 Exporting Process, Collecting Process, Observation Point, etc. are 153 semantically identical with those found in the IPFIX requirements 154 document IPFIX-REQS [1]. Some of the terms have been expanded for 155 more clarity when defining the protocol. Additional definitions 156 required for the architecture have also been defined. For the same 157 terms defined here and in IPFIX-PROTO [3] the definitions are 158 equivalent in both documents. 160 * Observation Point 162 An Observation Point is a location in the network where IP packets 163 can be observed. Examples include: a line to which a probe is 164 attached, a shared medium, such as an Ethernet-based LAN, a single 165 port of a router, or a set of interfaces (physical or logical) of 166 a router. 168 Note that every Observation Point is associated with an 169 Observation Domain (defined below), and that one Observation Point 170 may be a superset of several other Observation Points. For 171 example one Observation Point can be an entire line card. That 172 would be the superset of the individual Observation Points at the 173 line card's interfaces. 175 * Observation Domain 177 An Observation Domain is the largest set of Observation Points for 178 which Flow information can be aggregated by a Metering Process. 179 For example, a router line card may be an observation domain if it 180 is composed of several interfaces, each of which is an Observation 181 Point. Each Observation Domain presents itself to the Collecting 182 Process using an Observation Domain ID to identify the IPFIX 183 Messages it generates. Every Observation Point is associated with 184 an Observation Domain. It is RECOMMENDED that Observation Domain 185 IDs are also unique per IPFIX Device. 187 * IP Traffic Flow or Flow 189 There are several definitions of the term 'flow' being used by the 190 Internet community. Within the context of IPFIX we use the 191 following definition: 193 A Flow is defined as a set of IP packets passing an Observation 194 Point in the network during a certain time interval. All packets 195 belonging to a particular Flow have a set of common properties. 196 Each property is defined as the result of applying a function to 197 the values of: 199 1. One or more packet header fields (e.g. destination IP 200 address), transport header fields (e.g. destination port 201 number), or application header field (e.g. RTP header fields) 202 RTP-HDRF [5]. 204 2. One or more characteristics of the packet itself (e.g. number 205 of MPLS labels) 207 3. One or more fields derived from packet treatment (e.g. next 208 hop IP address, output interface) 210 A packet is said to belong to a Flow if it completely satisfies 211 all the defined properties of the Flow. 213 This definition covers the range from a Flow containing all 214 packets observed at a network interface to a Flow consisting of 215 just a single packet between two applications. It includes 216 packets selected by a sampling mechanism. 218 * Flow Key 220 Each of the fields which 222 1. Belong to the packet header (e.g. destination IP address) 224 2. Are a property of the packet itself (e.g. packet length) 226 3. Are derived from packet treatment (e.g. AS number) 228 and which are used to define a Flow are termed Flow Keys. 230 * Flow Record 232 A Flow Record contains information about a specific Flow that was 233 observed at an Observation Point. A Flow Record contains measured 234 properties of the Flow (e.g. the total number of bytes for all the 235 Flow's packets) and usually characteristic properties of the Flow 236 (e.g. source IP address). 238 * Metering Process 240 The Metering Process generates Flow Records. Inputs to the 241 process are packet headers and characteristics observed at an 242 Observation Point, and packet treatment at the Observation Point 243 (for example the selected output interface). 245 The Metering Process consists of a set of functions that includes 246 packet header capturing, timestamping, sampling, classifying, and 247 maintaining Flow Records. 249 The maintenance of Flow Records may include creating new records, 250 updating existing ones, computing Flow statistics, deriving 251 further Flow properties, detecting Flow expiration, passing Flow 252 Records to the Exporting Process, and deleting Flow Records. 254 * Exporting Process 256 An Exporting Process sends Flow Records to one or more Collecting 257 Processes. The Flow Records are generated by one or more Metering 258 Processes. 260 * Exporter 262 A device which hosts one or more Exporting Processes is termed an 263 Exporter. 265 * IPFIX Device 267 An IPFIX Device hosts at least one Exporting Process. It may host 268 further Exporting processes and arbitrary numbers of Observation 269 Points and Metering Process. 271 * Collecting Process 273 A Collecting Process receives Flow Records from one or more 274 Exporting Processes. The Collecting Process might process or 275 store received Flow Records, but such actions are out of scope for 276 this document. 278 * Collector 280 A device which hosts one or more Collecting Processes is termed a 281 Collector. 283 * Template 285 A Template is an ordered sequence of pairs, used to 286 completely specify the structure and semantics of a particular set 287 of information that needs to be communicated from an IPFIX Device 288 to a Collector. Each Template is uniquely identifiable by means 289 of a Template ID. 291 * Control Information, Data Stream 293 The information that needs to be exported from the IPFIX Device 294 can be classified into the following categories: 296 Control Information 298 This includes the Flow definition, selection criteria for 299 packets within the Flow sent by the Exporting Process, and 300 templates describing the data to be exported. Control 301 Information carries all the information needed for the end- 302 points to understand the IPFIX protocol, and specifically for 303 the Collector to understand and interpret the data sent by the 304 sending Exporter. 306 Data Stream 308 This includes Flow Records carrying the field values for the 309 various observed Flows at each of the Observation Points. 311 IPFIX Message 313 An IPFIX Message is a message originating at the Exporting Process 314 that carries the IPFIX records of this Exporting Process and whose 315 destination is a Collecting Process. An IPFIX Message is 316 encapsulated at the transport layer. 318 Information Element 320 An Information Element is a protocol and encoding independent 321 description of an attribute which may appear in an IPFIX Record. 322 The IPFIX information model IPFIX-INFO [2] defines the base set of 323 Information Elements for IPFIX. The type associated with an 324 Information Element indicates constraints on what it may contain 325 and also determines the valid encoding mechanisms for use in 326 IPFIX. 328 3. Examples of Flows 330 Some examples of Flows are listed below: 332 Example 1: The Flow Keys define the different fields by which Flows 333 are distinguished. The different combination of the field values 334 creates unique Flows. If {source IP address, destination IP address, 335 DSCP} are flow keys, then all of these are different Flows: 337 1. {192.0.2.1, 192.0.2.65, 4} 338 2. {192.0.2.23, 192.0.2.67, 4} 339 3. {192.0.2.23, 192.0.2.67, 2} 340 4. {192.0.2.129, 192.0.2.67, 4} 342 Example 2: A mask function can be applied to all the packets that 343 pass through an Observation Point, in order to aggregate some values. 344 This could be done by defining the set of Flow Keys as {source IP 345 address, destination IP address, DSCP} as in example 1 above, and 346 applying a function which masks out the least significant 6 bits of 347 the source IP address and destination IP address (i.e. the result is 348 a /26 address). The four Flows from example 1 would now be 349 aggregated into three Flows by merging the Flows 1 and 2 into a 350 single Flow: 352 1. {192.0.2.0/26, 192.0.2.64/26, 4} 353 2. {192.0.2.0/26, 192.0.2.64/26, 2} 354 3. {192.0.2.128/26, 192.0.2.64/26, 4} 356 Example 3: A filter defined by some Flow Key values can be applied on 357 all packets that pass the Observation Point, in order to select only 358 certain Flows. The filter is defined by choosing fixed values for 359 specific Keys from the packet. 361 All the packets that go from a customer network 192.0.2.0/26 to 362 another customer network 192.0.2.64/26 with DSCP value of 4 define a 363 Flow. All other combinations don't define a Flow and are not taken 364 into account. The three Flows from example 2 would now be reduced to 365 one Flow by filtering away the second and the third Flow, leaving 366 only {192.0.2.0/26, 192.0.2.64/26, 4}. 368 The above examples can be thought of as a function F() taking as 369 input {source IP address, destination IP address, DSCP}. The 370 function selects only the packets which satisfy all three of the 371 following conditions: 373 1. Mask out the least significant 6 bits of source IP address, match 374 against 192.0.2.0. 376 2. Mask out the least significant 6 bits of destination IP address, 377 match against 192.0.2.64. 379 3. Only accept DSCP value equal to 4. 381 Depending on the values of {source IP address, destination IP 382 address, DSCP} of the different observed packets, the Metering 383 Process function F() would choose/filter/aggregate different sets of 384 packets, which would create different Flows. For example, for 385 various combinations of values of {source IP address, destination IP 386 address, DSCP}, F(source IP address, destination IP address, DSCP) 387 would result in the definition of one or more Flows. 389 4. IPFIX Reference Model 391 The figure below shows the reference model for IPFIX. This figure 392 covers the various possible scenarios that can exist in an IPFIX 393 system. 395 +----------------+ +----------------+ 396 |[*Application 1]| ... |[*Application n]| 397 +--------+-------+ +-------+--------+ 398 ^ ^ 399 | | 400 + = = = = -+- = = = = + 401 ^ 402 | 403 +------------------------+ +-------+------------------+ 404 |IPFIX Exporter | | Collector(1) | 405 |[Exporting Process(es)] |<---------->| [Collecting Process(es)] | 406 +------------------------+ +--------------------------+ 407 .... .... 408 +------------------------+ +---------------------------+ 409 |IPFIX Device(i) | | Collector(j) | 410 |[Observation Point(s)] |<--------->| [Collecting Process(es)] | 411 |[Metering Process(es)] | +---->| [*Application(s)] | 412 |[Exporting Process(es)] | | +---------------------------+ 413 +------------------------+ . 414 .... . .... 415 +------------------------+ | +--------------------------+ 416 |IPFIX Device(m) | | | Collector(n) | 417 |[Observation Point(s)] |<----+---->| [Collecting Process(es)] | 418 |[Metering Process(es)] | | [*Application(s)] | 419 |[Exporting Process(es)] | +--------------------------+ 420 +------------------------+ 422 The various functional components are indicated within brackets []. 423 The functional components within [*] are not part of the IPFIX 424 architecture. The interfaces shown by "<----->" are defined by the 425 IPFIX architecture but those shown by "<= = = =>" are not. 427 Figure 3 428 The figure below shows a typical IPFIX Device where the IPFIX 429 components are shown in rectangular boxes. 431 +--------------------------------------------------+ 432 | IPFIX Device | 433 | +-----+ | 434 | +------- ... ------------+---------> | | 435 | | | | | | 436 | +----+----+ +----+----+ | | | 437 | |Metering | |Metering | | E | | 438 | |Process 1| |Process N| | x | | 439 | +---------+ +---------+ | p | | 440 | ^ ^ | o | | 441 | +------+--------+ +---------+------+ | r | | 442 | | Obsv Domain 1 | | Obsv Domain N | | t | | 443 | |+-----+-------+| |+-------+------+| | i | | 444 | ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| | n | | 445 | |+-------------+| |+--------------+| | g | | Export 446 Packets | +------^--------+ +---------^------+ | | | packets 447 --->----+--------+---------- ... ---------+ | | | to 448 In | | +---------> 449 | . . . . . | | |Collector 450 | | | | 451 | +------ ... -------------+---------> | | 452 | | | | | | 453 | +----+----+ +----+----+ | P | | 454 | |Metering | |Metering | | r | | 455 | |Process 1| |Process N| | o | | 456 | +---------+ +---------+ | c | | 457 | ^ ^ | e | | 458 | +------+--------+ +---------+------+ | s | | 459 | | Obsv Domain 1 | | Obsv Domain N | | s | | 460 | |+-----+-------+| |+-------+------+| | | | 461 | ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| | | | 462 | |+-------------+| |+--------------+| | | | 463 Packets | +------^--------+ +---------^------+ +-----+ | 464 --->----+--------+---------- ... ---------+ | 465 In | | 466 +--------------------------------------------------+ 468 Figure 4 470 5. IPFIX Functional and Logical Blocks 472 5.1. Metering Process 474 Every Observation Point in an IPFIX Device, participating in Flow 475 measurements, must be associated with at least one Metering Process. 476 Every packet coming into an Observation Point goes into each of the 477 Metering Processes associated with the Observation Point. Broadly, 478 each Metering Process observes the packets that pass an Observation 479 Point, does timestamping and classifies the packets into Flow(s) 480 based on the selection criteria. 482 The Metering Process is a functional block which manages all the 483 Flows generated from an Observation Domain. The typical functions of 484 a Metering Process may include: 486 o Maintain database(s) of all the Flow Records from an Observation 487 Domain. This includes creating new Flow Records, updating 488 existing ones, computing Flow Records statistics, deriving further 489 Flow properties, adding non-flow-specific information based on the 490 packet treatment (in some cases fields like AS numbers, router 491 state, etc.) 493 o Maintain statistics about the Metering Process itself, such as 494 Flow Records generated, packets observed, etc. 496 5.1.1. Flow Expiration 498 A Flow is considered to have expired under the following conditions: 500 1. If no packets belonging to the Flow have been observed for a 501 certain period of time. This time period should be configurable 502 at the Metering Process, with a minimum value of 0 seconds for 503 immediate expiration. Note that a zero timeout would report a 504 Flow as a sequence of single-packet Flows. 506 2. If the IPFIX Device experiences resource constraints, a Flow may 507 be prematurely expired (e.g. lack of memory to store Flow 508 Records) 510 3. For long-running Flows, the Metering Process should expire the 511 Flow on a regular basis or based on some expiration policy. This 512 periodicity or expiration policy should be configurable at the 513 Metering Process. When a long-running Flow is expired, its Flow 514 Record may still be maintained by the Metering Process so that 515 the Metering Process does not need to create a new Flow Record 516 for further observed packets of the same Flow. 518 5.1.2. Flow Export 520 The Exporting Process decides when and whether to export an expired 521 Flow. A Flow can be exported because it expired for any of the 522 reasons mentioned in Flow Expiration section. For example: the 523 Exporting Process exports a portion of the expired Flows every 'x' 524 seconds. 526 For long-lasting Flows, the Exporting Process should export the Flow 527 Records on a regular basis or based on some export policy. This 528 periodicity or export policy should be configurable at the Exporting 529 Process. 531 5.2. Observation Point 533 A Flow Record can be better analysed if the Observation Point from 534 which it was measured is known. As such it is recommended that IPFIX 535 Devices send this information to Collectors. In cases where there is 536 a single Observation Point or where the Observation Point information 537 is not relevant, the Metering Process may choose not to add the 538 Observation Point information to the Flow Records. 540 5.3. Selection Criteria for Packets 542 A Metering Process may define rules so that only certain packets 543 within an incoming stream of packets are chosen for measurement at an 544 Observation Point. This may be done by one of the two methods 545 defined below or a combination of them, in either order. A 546 combination of each of these methods can be adopted to select the 547 packets, i.e. one can define a set of methods {F1, S1, F2, S2, S3} 548 executed in a specified sequence at an Observation Point to select 549 particular Flows. 551 The figure below shows the operations which may be applied as part of 552 a typical Metering Process. 554 packet header capturing 555 | 556 timestamping 557 | 558 v 559 +----->+ 560 | | 561 | sampling Si (1:1 in case of no sampling) 562 | | 563 | filtering Fi (select all when no criteria) 564 | | 565 +------+ 566 | 567 v 568 Flows 570 Figure 5 571 Note that packets could be selected before or after any IP 572 processing, i.e., before there is any IP checksum validation, IP 573 filtering, etc, or after one or more of these steps. This has an 574 impact on what kinds of traffic (or erroneous conditions) IPFIX can 575 observe. It is recommended that packets are selected after their 576 checksums have been verified. 578 5.3.1. Sampling Functions, Si 580 A sampling function determines which packets within a stream of 581 incoming packets are selected for measurement, i.e. packets that 582 satisfy the sampling criteria for this Metering Process. 584 Example: sample every 100th packet that was received at an 585 Observation Point. 587 Choosing all the packets is a special case where the sampling rate is 588 1:1. 590 5.3.2. Filter Functions, Fi 592 A Filter Function selects only those incoming packets that satisfy a 593 function on fields defined by the packet header fields, fields 594 obtained while doing the packet processing, or properties of the 595 packet itself. 597 Example: Mask/Match of the fields that define a filter. A filter 598 might be defined as {Protocol == TCP, Destination Port between 80 and 599 120}. 601 Several such filters could be used in any sequence to select packets. 602 Note that packets selected by a (sequence of) filter functions may be 603 further classified by other filter functions, i.e. the selected 604 packets may belong to several Flows, any or all of which are 605 exported. 607 5.4. Observation Domain 609 The Observation Domain is a logical block that presents a single 610 identity for a group of Observation Points within an IPFIX Device. 611 Each {Observation Point, Metering Process} pair belongs to a single 612 Observation Domain. An IPFIX Device could have multiple Observation 613 Domains, each of which has a subset of the total set of Observation 614 Points in it. Each Observation Domain must carry a unique ID within 615 the context of an IPFIX Device. Note that in case of multiple 616 Observation Domains, a unique ID per Observation Domain must be 617 transmitted as a parameter to the Exporting Function. That unique ID 618 is referred to as the IPFIX Observation Domain ID. 620 5.5. Exporting Process 622 The Exporting Process is the functional block that sends data to one 623 or more IPFIX Collectors using the IPFIX protocol. On one side the 624 Exporting Process interfaces with Metering Process(es) to get Flow 625 Records, while on the other side it talks to a Collecting Process on 626 the Collector(s). 628 There may be additional rules defined within an Observation Domain so 629 that only certain Flow Records are exported. This may be done by 630 either one or a combination of Si, Fi, as described in the section on 631 "Selection Criteria for Packets". 633 Example: Only the Flow Records which meet the following selection 634 criteria are exported: 636 1. All Flow Records whose destination IP address matches 637 {192.0.33.5}. 639 2. Every other (i.e. sampling rate 1 in 2) Flow Record whose 640 destination IP address matches {192.0.11.30}. 642 5.6. Collecting Process 644 Collecting Processes use a Flow Record's Template ID to interpret 645 that Flow Record's Information Elements. To allow this, an IPFIX 646 Exporter must ensure that an IPFIX Collector knows the Template ID 647 for each incoming Flow Record. To interpret incoming Flow Records, 648 an IPFIX Collector may also need to know the function F() that was 649 used by the Metering Process for each Flow. 651 The functions of the Collecting Process must include: 653 o Identifying, accepting and decoding the IPFIX Messages from 654 different pairs. 656 o Storing the Control Information and Flow Records received from an 657 IPFIX Device. 659 At a high level, the Collecting Process: 661 1. Receives and stores the Control Information. 663 2. Decodes and stores the Flow Records using the Control 664 Information. 666 5.7. Summary 667 The figure below shows the functions performed in sequence by the 668 various functional blocks in an IPFIX Device. 670 Packet(s) coming in to Observation Point(s) 671 | | 672 v v 673 +----------------+-------------------------+ +-----+-------+ 674 | Metering Process on an | | | 675 | Observation Point | | | 676 | | | | 677 | packet header capturing | | | 678 | | |...| Metering | 679 | timestamping | | Process N | 680 | | | | | 681 | +----->+ | | | 682 | | | | | | 683 | | sampling Si (1:1 in case of no | | | 684 | | | sampling) | | | 685 | | filtering Fi (select all when | | | 686 | | | no criteria) | | | 687 | +------+ | | | 688 | | | | | 689 | | Timing out Flows | | | 690 | | Handle resource overloads | | | 691 +--------|---------------------------------+ +-----|-------+ 692 | | 693 Flow Records (identified by Observation Domain) Flow Records 694 | | 695 +---------+---------------------------------+ 696 | 697 +--------------------|----------------------------------------------+ 698 | | Exporting Process | 699 |+-------------------|-------------------------------------------+ | 700 || v IPFIX Protocol | | 701 ||+-----------------------------+ +----------------------------+| | 702 |||Rules for | |Functions || | 703 ||| Picking/sending Templates | |-Packetise selected Control || | 704 ||| Picking/sending Flow Records|->| & data Information into || | 705 ||| Encoding Template & data | | IPFIX export packets. || | 706 ||| Selecting Flows to export(*)| |-Handle export errors || | 707 ||+-----------------------------+ +----------------------------+| | 708 |+----------------------------+----------------------------------+ | 709 | | | 710 | exported IPFIX Messages | 711 | | | 712 | +------------+-----------------+ | 713 | | Anonymise export packet(*) | | 714 | +------------+-----------------+ | 715 | | | 716 | +------------+-----------------+ | 717 | | Transport Protocol | | 718 | +------------+-----------------+ | 719 | | | 720 +-----------------------------+-------------------------------------+ 721 | 722 v 723 IPFIX export packet to Collector 725 (*) indicates that the block is optional. 727 Figure 6 729 6. Overview of the IPFIX Protocol 731 An IPFIX Device consists of a set of co-operating processes that 732 implement the functional blocks described in the previous section. 733 Alternatively, an IPFIX Device can be viewed simply as a network 734 entity which implements the IPFIX protocol. At the IPFIX Device, the 735 protocol functionality resides in the Exporting Process. The IPFIX 736 Exporting Process gets Flow Records from a Metering Process, and 737 sends them to the Collector(s). 739 At a high level, an IPFIX Device performs the following tasks: 741 1. Encode Control Information into Templates. 743 2. Encode packets observed at the Observation Points into Flow 744 Records. 746 3. Packetise the selected Templates and Flow Records into IPFIX 747 Messages. 749 4. Send IPFIX Messages to the Collector. 751 The IPFIX protocol communicates information from an IPFIX Exporter to 752 an IPFIX Collector. That information includes not only Flow Records, 753 but also information about the Metering Process. Such information 754 (referred to as Control Information) includes details of the data 755 fields in Flow Records. It may also include statistics from the 756 Metering Process, such as the number of packets lost (i.e. not 757 metered). 759 For details of the IPFIX protocol please refer to IPFIX-PROTO [3]. 761 6.1. Information Model Overview 763 The IP Flow Information eXport (IPFIX) protocol serves for 764 transmitting information related to measured IP traffic over the 765 Internet. The protocol specification in IPFIX-PROTO [3] defines how 766 Information Elements are transmitted. For Information Elements, it 767 specifies the encoding of a set of basic data types. However, the 768 list of fields that can be transmitted by the protocol, such as Flow 769 attributes (source IP address, number of packets, etc.) and 770 information about the Metering and Exporting Process (packet 771 Observation Point, sampling rate, Flow timeout interval, etc.), is 772 not specified in IPFIX-PROTO [3]. Instead, it is defined in the 773 IPFIX Information Model document IPFIX-INFO [2]. 775 The Information Model provides a complete description of the 776 properties of every IPFIX Information Element. It does this by 777 specifying each element's name, Field Type, data type, etc., and 778 providing a description of each element. Element descriptions give 779 the semantics of the element, i.e. say how it is derived from a Flow 780 or other information available within an IPFIX Device. 782 6.2. Flow Records 784 The following rules provide guidelines to be followed while encoding 785 the Flow Records information: 787 A Flow Record contains enough information so that the Collecting 788 Process can identify the corresponding . 791 The Exporting Process encodes a given Information Element (as 792 specified in IPFIX-INFO [2]), based on the encoding standards 793 prescribed by IPFIX-PROTO [3]. 795 6.3. Control Information 797 The following rules provide guidelines to be followed while encoding 798 the Control Information: 800 o Per-Flow Control Information should be encoded such that the 801 Collecting Process can capture the structure and semantics of the 802 corresponding Flow data for each of the Flow Records exported by 803 the IPFIX Device. 805 o Configuration Control Information is conveyed to a Collector so 806 that its Collecting Process can capture the structure and 807 semantics of the corresponding configuration data. The 808 configuration data which is also Control Information should carry 809 additional information on the Observation Domain within which the 810 configuration takes effect. 812 For example, sampling using the same sampling algorithm, say 1 in 100 813 packets, is configured on two Observation Points O1 and O2. The 814 configuration in this case may be encoded as {ID, configuration 815 domain (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is 816 the Observation Domain ID for the domain containing O1 and O2. The 817 Observation Domain ID uniquely identifies this configuration, and 818 must be sent within the Flow Records in order to be able to match the 819 right configuration control information. 821 The Control Information is used by the Collecting Process to: 823 o Decode and interpret Flow Records. 825 o Understand the state of the Exporting Process. 827 Sending Control Information from the Exporting Process in a timely 828 and reliable manner is critical to the proper functioning of the 829 IPFIX Collecting Process. The following approaches may be taken for 830 the export of Control Information: 832 1. Send all the Control Information pertaining to Flow Records prior 833 to sending the Flow Records themselves. This includes any 834 incremental changes to the definition of the Flow Records. 836 2. Notify on a near real time basis the state of the IPFIX Device to 837 the Collecting Process. This includes all changes such as a 838 configuration change that affects the Flow behaviour, changes to 839 Exporting Process resources that alter export rates, etc., which 840 the Collector needs to be aware of. 842 3. Since it is vital that a Collecting Process maintains accurate 843 knowledge of the Exporter's state, the export of the Control 844 Information should be done such that it reaches the Collector 845 reliably. One way to achieve this is to send the Control 846 Information over a reliable transport. 848 6.4. Reporting Responsibilities 850 From time to time an IPFIX Device may not be able to observe all the 851 packets reaching one of its Observation Points. This could occur if 852 a Metering Process finds itself temporarily short of resources. For 853 example it might run out of packet buffers for IPFIX export. 855 In such situations, the IPFIX Device should attempt to count the 856 number of packet losses that have occurred, and report them to its 857 Collector(s). If it is not possible to count losses accurately, e.g. 858 when transport layer (i.e. non-IPFIX) errors are detected, the IPFIX 859 device should report this fact, and perhaps indicate the time period 860 during which some packets might not have been observed. 862 7. IPFIX Protocol Details 864 When the IPFIX Working Group was chartered there were existing common 865 practices in the area of Flow export, for example NetFlow, CRANE, 866 LFAP, RTFM, etc. IPFIX's charter required the Working Group to 867 consider those existing practices, and select the one that was the 868 closest fit to the IPFIX requirements IPFIX-REQS [1]. Additions or 869 modifications would then be made to the selected protocol to fit it 870 exactly into the IPFIX architecture. 872 7.1. The IPFIX Basis Protocol 874 The Working Group went through an extensive evaluation of the various 875 existing protocols that were available, weighing the level of 876 compliance with the requirements, and selected one of the candidates 877 as the basis for the IPFIX protocol. For more details of the 878 evaluation process please see IPFIX-EVAL [6]. 880 In the basis protocol Flow Records are defined by Templates, where a 881 Template is an ordered set of the Information Elements appearing in a 882 Flow Record, together with their field sizes within those records. 884 This approach provides the following advantages: 886 o Using the Template mechanism, new fields can be added to IPFIX 887 Flow Records without changing the structure of the export record 888 format. 890 o Templates that are sent to the Collecting Process carry structural 891 information about the exported Flow Record fields. Therefore, if 892 the Collector does not understand the semantics of new fields it 893 can ignore them, but still interpret the Flow Record. 895 o Because the template mechanism is flexible, it allows the export 896 of only the required fields from the Flows to the Collecting 897 Process. This helps to reduce the exported Flow data volume and 898 possibly provide memory savings at the Exporting Process and 899 Collecting Process. Sending only the required information can 900 also reduce network load. 902 7.2. IPFIX Protocol on the Collecting Process 904 The Collecting Process is responsible for: 906 1. Receiving and decoding Flow Records from the IPFIX Devices. 908 2. Reporting on the loss of Flow Records sent to the Collecting 909 Process by an IPFIX Exporting Process. 911 Complete details of the IPFIX protocol are given in IPFIX-PROTO [3]. 913 7.3. Support for Applications 915 Applications that use the information collected by IPFIX may be 916 Billing or Intrusion Detection sub-systems, etc. These applications 917 may be an integral part of the Collecting Process or they may be co- 918 located with the Collecting Process. The way by which these 919 applications interface with IPFIX systems to get the desired 920 information is out of scope for this document. 922 8. Export Models 924 8.1. Export with Reliable Control Connection 926 As mentioned in the IPFIX-REQS [1] document, an IPFIX Device must be 927 able to transport its Control Information and Data Stream over a 928 congestion-aware transport protocol. 930 If the network in which the IPFIX Device and Collecting Process are 931 located does not guarantee reliability, at least the Control 932 Information should be exported over a reliable transport. The Data 933 Stream may be exported over a reliable or unreliable transport 934 protocol. 936 Possible transport protocols include: 938 o SCTP: Supports reliable and unreliable transport. 940 o TCP: Provides reliable transport only. 942 o UDP: Provides unreliable transport only. Network operators would 943 need to avoid congestion by keeping traffic within their own 944 administrative domains. For example, one could use a dedicated 945 network (or Ethernet link) to carry IPFIX traffic from Exporter to 946 Collector. 948 8.2. Collector Failure Detection and Recovery 950 The transport connection (in the case of a connection oriented 951 protocol) is pre-configured between the IPFIX Device and the 952 Collector. The IPFIX protocol does not provide any mechanism for 953 configuring the Exporting and Collecting Processes. 955 Once connected, an IPFIX Collector receives Control Information and 956 uses that information to interpret Flow Records. The IPFIX Device 957 should set a keepalive (e.g. the keepalive timeout in the case of 958 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently 959 low value so that it can quickly detect a Collector failure. 961 Collector failure refers to the crash or restart of the Collecting 962 Process, or of the Collector itself. A Collector failure is detected 963 at the IPFIX Device by the break in the connection oriented transport 964 protocol session, depending on the transport protocol - the 965 connection timeout mechanisms differ. On detecting a keepalive 966 timeout in a single Collector scenario, the IPFIX Device should stop 967 sending Flow Records to the Collector and try to reestablish the 968 transport connection. If Collecting Process failover is supported by 969 the Exporting Process, backup session(s) may be opened in advance, 970 and Control Information sent to it. 972 There could be one or more secondary Collectors with priority 973 assigned to them. The primary Collector crash is detected at the 974 IPFIX Device. On detecting loss of connectivity, the IPFIX Device 975 opens a Data Stream with the secondary Collector of the next highest 976 priority. If that secondary was not opened in advance, both the 977 Control Information and Data Stream must be sent to it. That 978 Collector might then become the primary, or the Exporting Process 979 might try to reestablish the original session. 981 8.3. Collector Redundancy 983 Configuring redundant Collectors is an alternative to configuring 984 backup Collectors. In this model, all Collectors simultaneously 985 receive the Control Information and Data Streams. Multiple {Control 986 Information, Data Stream} pairs could be sent, each to a different 987 Collector from the same IPFIX Device. Since the IPFIX protocol 988 requires a congestion-aware transport, achieving redundancy using 989 multicast is not an option. 991 9. IPFIX Flow Collection in Special Situations 993 An IPFIX Device could be doing one or more of generating, receiving, 994 altering special types of traffic which are listed below. 996 Tunnel traffic: 998 The IPFIX Device could be the head, midpoint or endpoint of a 999 tunnel. In such cases the IPFIX Device could be handling GRE, 1000 IPinIP or UTI traffic. 1002 VPN traffic: 1004 The IPFIX Device could be a provider edge device which receives 1005 traffic from customer sites belonging to different Virtual Private 1006 Networks. 1008 Similarly, IPFIX could be implemented on devices which perform one or 1009 more of the following special services: 1011 o Explicitly drop packets. For example a device which provides 1012 firewall service drops packets based on some administrative 1013 policy. 1015 o Alter the values of fields used as IPFIX Flow Keys of interest. 1016 For example a device which provides NAT service can change source 1017 and/or destination IP address. 1019 In cases such as those listed above, there should be clear guidelines 1020 as to: 1022 o How and when to classify the packets as Flows in the IPFIX Device. 1024 o If multiple encapsulations are used to define Flows, how to convey 1025 the same fields (e.g. IP address) in different layers. 1027 o How to differentiate Flows based on different private domains. 1028 For example, overlapping IP addresses in Layer-3 VPNs. 1030 o What extra information needs be exported so that the Collector can 1031 make a clear interpretation of the received Flow Records. 1033 10. Security Considerations 1035 Flow information can be used for various purposes, such as usage 1036 accounting, traffic profiling, traffic engineering, and intrusion 1037 detection. The security requirement may differ significantly for 1038 such applications. To be able to satisfy the security needs of 1039 various IPFIX users, an IPFIX system must provide different levels of 1040 security protection. 1042 10.1. Data Security 1044 IPFIX data comprises Control Information and Data Stream generated by 1045 the IPFIX Device. 1047 The IPFIX data may exist in both the IPFIX Device and the Collector. 1048 In addition, the data is also transferred on the wire from the IPFIX 1049 Device to the Collector when it is exported. To provide security, 1050 the data should be protected from common network attacks. 1052 The protection of IPFIX data within the end system (IPFIX Device and 1053 Collector) is out of scope for this document. It is assumed that the 1054 end system operator will provide adequate security for the IPFIX 1055 data. 1057 The IPFIX architecture must allow different levels of protection to 1058 the IPFIX data on the wire. Wherever security functions are required 1059 it is recommended that users should leverage lower layers using 1060 either IPsec or TLS, if these can successfully satisfy the security 1061 requirement of IPFIX data protection. 1063 To protect the data on the wire, three levels of granularity should 1064 be supported; these are described in the following subsections. 1066 10.1.1. Host-Based Security 1068 Security may not be required when the transport between the IPFIX 1069 Device and the Collector is perceived as safe. This option allows 1070 the protocol to run most efficiently without extra overhead and an 1071 IPFIX system must support it. 1073 10.1.2. Authentication-only 1075 Authentication-only protection provides IPFIX users with the 1076 assurance of data integrity and authenticity. The data exchanged 1077 between the IPFIX Device and the Collector is protected by an 1078 authentication signature. Any modification of the IPFIX data will be 1079 detected by the recipient, resulting in discarding of the received 1080 data. However, the authentication-only option doesn't offer data 1081 confidentiality. 1083 The IPFIX user should not use authentication-only when sensitive or 1084 confidential information is being exchanged. An IPFIX solution 1085 should support this option. The authentication-only option should 1086 provide replay attack protection. One way to achieve this level of 1087 security would be: 1089 o IP Authentication Header 1091 10.1.3. Encryption 1093 Data encryption provides the best protection for IPFIX data. The 1094 IPFIX data is encrypted at the sender and only the intended recipient 1095 can decrypt and have access to the data. This option must be used 1096 when the transport between the IPFIX Device and the Collector are 1097 unsafe and the IPFIX data needs to be protected. It is recommended 1098 that the underlying transport layer's security functions be used for 1099 this purpose. Some means to achieve this level of security are: 1101 o Encapsulating Security Payload. 1103 o Transport Layer Security Protocol 1105 The data encryption option adds overhead to the IPFIX data transfer. 1106 It may limit the rate that an Exporter can report its Flow Records to 1107 the Collector due to the resource requirement for running encryption. 1109 10.2. IPFIX End-point Authentication 1111 It is important to make sure that the IPFIX Device is talking to the 1112 "right" Collector rather than to a masquerading Collector. The same 1113 logic also holds true from the Collector point of view, i.e. it may 1114 want to make sure it is collecting the Flow Records from the "right" 1115 IPFIX Device. An IPFIX system should allow the end point 1116 authentication capability so that either one-way or mutual 1117 authentication can be performed between the IPFIX Device and 1118 Collector. 1120 The IPFIX architecture should use any existing transport protection 1121 protocols such as TLS or IPsec to fulfil the authentication 1122 requirement. 1124 10.3. IPFIX Overload 1126 An IPFIX Device could become overloaded under various conditions. 1127 This may be because of exhaustion of internal resources used for Flow 1128 generation and/or export. Such overloading may cause loss of data 1129 from the Exporting Process, either from lack of export bandwidth 1130 (possibly caused by an unusually high number of observed Flows) or 1131 from network congestion in the path from Exporter to Collector. 1133 IPFIX Collectors should be able to detect the loss of exported Flow 1134 Records, and should at least record the number of lost Flow Records. 1136 10.3.1. Denial of Service (DoS) Attack Prevention 1138 Since one of the potential usages for IPFIX is for intrusion 1139 detection, it is important for the IPFIX architecture to support some 1140 kind of DoS resistance. 1142 10.3.1.1. Network Under Attack 1144 The Network itself may be under attack, resulting in an overwhelming 1145 number of IPFIX Messages. An IPFIX system should try to capture as 1146 much information as possible. However, when a large number of IPFIX 1147 Messages are generated in a short period of time, the IPFIX system 1148 may become overloaded. 1150 10.3.1.2. Generic DoS Attack on the IPFIX Device and Collector 1152 The IPFIX Device and Collector may be subject to generic DoS attacks, 1153 just as any system on any open network. These types of attacks are 1154 not IPFIX specific. Preventing and responding to such types of 1155 attacks are out of the scope of this document. 1157 10.3.1.3. IPFIX Specific DoS Attack 1159 There are some specific attacks on the IPFIX portion of the IPFIX 1160 Device or Collector: 1162 o The attacker could overwhelm the Collector with spoofed IPFIX 1163 export packets. One way to solve this problem is to periodically 1164 synchronise the sequence numbers of the Flow Records between the 1165 Exporting and Collecting Processes. 1167 o The attacker could provide false reports to the Collector by 1168 sending spoofed packets. 1170 The problems mentioned above can be solved to a large extent if the 1171 control packets are encrypted both ways, thereby providing more 1172 information that the Collector could use to identify and ignore 1173 spoofed data packets. 1175 11. IANA Considerations 1177 The IPFIX Architecture, as set out in this document, has two sets of 1178 assigned numbers, as outlined in the following subsections. 1180 11.1. Numbers used in the Protocol 1182 IPFIX Messages, as described in IPFIX-PROTO [3], use two fields with 1183 assigned values. These are the IPFIX Version Number, indicating 1184 which version of the IPFIX Protocol was used to export an IPFIX 1185 Message, and the IPFIX Set ID, indicating the type for each set of 1186 information within an IPFIX message. 1188 Values for the IPFIX Version Number and the IPFIX Set ID, together 1189 with the considerations for assigning them, are defined in IPFIX- 1190 PROTO [3] 1192 11.2. Numbers used in the Information Model 1194 Fields of the IPFIX protocol carry information about traffic 1195 measurement. They are modelled as elements of the IPFIX information 1196 model IPFIX-INFO [2]. Each Information Element describes a field 1197 which may appear in an IPFIX Message. Within an IPFIX message the 1198 field type is indicated by its Field Type. 1200 Values for the IPFIX Information Element IDs, together with the 1201 considerations for assigning them, are defined in IPFIX-INFO [2]. 1203 12. Acknowledgements 1205 The document editors wish to thank all the people contributing to the 1206 discussion of this document on the mailing list, and the design teams 1207 for many valuable comments. In particular, the following made 1208 significant contributions: 1210 Tanja Zseby 1211 Paul Calato 1212 Dave Plonka 1213 Jeffrey Meyer 1214 K.C.Norseth 1215 Vamsi Valluri 1216 Cliff Wang 1217 Ram Gopal 1218 Jc Martin 1219 Carter Bullard 1220 Reinaldo Penno 1221 Simon Leinen 1222 Kevin Zhang 1223 Paul Aitken 1224 Brian Trammell 1226 Special thanks to Dave Plonka for the multiple thorough reviews. 1228 13. References 1229 13.1. Normative References 1231 [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements 1232 for IP Flow Information Export", RFC RFC 3917, October 2004. 1234 [2] Meyer, J., Quittek, J., and S. Bryant, "IPFIX: Information 1235 Model", (work in progress), Internet Draft, 1236 draft-ietf-ipfix-info-08.txt, October 2004. 1238 [3] Claise, B., Bryant, S., Sadasivan, G., and M. Fullmer, "IPFIX: 1239 Protocol", (work in progress), Internet Draft, 1240 draft-ietf-ipfix-protocol-10.txt, December 2004. 1242 [4] Zseby, T., Boschi, E., Penno, R., Brownlee, N., and B. Claise, 1243 "IPFIX: Protocol", (work in progress), Internet Draft, 1244 draft-ietf-ipfix-as-05.txt, October 2004. 1246 13.2. Informative References 1248 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1249 "RTP: A Transport Protocol for Real-Time Applications", 1250 RFC 1889, January 1996. 1252 [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1253 Information Export", RFC 3955, October 2004. 1255 Appendix A. Changes/Issues from the -10 Draft 1257 IANA Considerations 1259 This section has been shortened, making the IPFIX Protocol and 1260 Information Model drafts the definitive documents for IANA. The 1261 material in this (Architecture) draft did not exactly match that 1262 in the other two drafts, and was therefore confusing. 1264 Packet selection 1266 Note added to section 5.3 (selection criteria) pointing out that 1267 packets could be selected before or after IP processing; "It is 1268 RCOMMENDED that packets are selected after their checksums have 1269 been verified." 1271 'Requirements' vs 'Architecture' 1272 Comment has been made that this draft is too open, i.e. "more like 1273 'requirements' rather than an 'architecture' document." The 1274 Working Group's approach has been to specify the minimum 1275 requirements needed to ensure that implementations can 1276 interoperate (e.g. SCTP transport must be implemented, in the 1277 Protocol and Information Model drafts, rather than here in the 1278 Architecture draft. 1280 IPFIX Specific DoS Attack 1282 Added text at end of section 10.3.1.3: "One way to solve this 1283 problem is to periodically synchronise the sequence numbers of the 1284 Flow Records between the Exporting and Collecting Processes." 1286 Editorial Improvements: 1288 Changed definition of "IPFIX Device" to match Protocol draft: An 1289 IPFIX Device hosts at least one Observation Point, at least one 1290 Metering Process and at least one Exporting Process. 1292 Changed figure 4 (at end of section 3) to show several Observation 1293 Domains, each with multiple Observation Points. 1295 Changed figure 6 (section 5.7) to say 'filtering' rather than 1296 'classifying' for consistency with figure 5 (section 5.3) 1298 Tidied up section 6.4, to remove ambiguities about 'transport 1299 layer.' 1301 Removed mention of 'TCP signed packet option' in section 10.1.2. 1303 Authors' Addresses 1305 Ganesh Sadasivan 1306 Cisco Systems, Inc. 1307 170 West Tasman Drive 1308 San Jose, CA 95134 1309 USA 1311 Phone: +1 408 527-0251 1312 Email: gsadasiv@cisco.com 1314 Nevil Brownlee 1315 CAIDA | The University of Auckland 1316 Private Bag 92019 1317 Auckland 1318 New Zealand 1320 Phone: +64 9 373 7599 x88941 1321 Email: n.brownlee@auckland.ac.nz 1323 Benoit Claise 1324 Cisco Systems, Inc. 1325 De Kleetlaan 6a b1 1326 1831 Diegem 1327 Belgium 1329 Phone: +32 2 704 5622 1330 Email: bclaise@cisco.com 1332 Juergen Quittek 1333 NEC Europe Ltd. 1334 Adenauerplatz 6 1335 69225 Heidelberg 1336 Germany 1338 Phone: +49 6221 90511-15 1339 Email: quittek@ccrle.nec.de 1341 Intellectual Property Statement 1343 The IETF takes no position regarding the validity or scope of any 1344 Intellectual Property Rights or other rights that might be claimed to 1345 pertain to the implementation or use of the technology described in 1346 this document or the extent to which any license under such rights 1347 might or might not be available; nor does it represent that it has 1348 made any independent effort to identify any such rights. Information 1349 on the procedures with respect to rights in RFC documents can be 1350 found in BCP 78 and BCP 79. 1352 Copies of IPR disclosures made to the IETF Secretariat and any 1353 assurances of licenses to be made available, or the result of an 1354 attempt made to obtain a general license or permission for the use of 1355 such proprietary rights by implementers or users of this 1356 specification can be obtained from the IETF on-line IPR repository at 1357 http://www.ietf.org/ipr. 1359 The IETF invites any interested party to bring to its attention any 1360 copyrights, patents or patent applications, or other proprietary 1361 rights that may cover technology that may be required to implement 1362 this standard. Please address the information to the IETF at 1363 ietf-ipr@ietf.org. 1365 Disclaimer of Validity 1367 This document and the information contained herein are provided on an 1368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1370 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1371 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1372 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1375 Copyright Statement 1377 Copyright (C) The Internet Society (2006). This document is subject 1378 to the rights, licenses and restrictions contained in BCP 78, and 1379 except as set forth therein, the authors retain all their rights. 1381 Acknowledgment 1383 Funding for the RFC Editor function is currently provided by the 1384 Internet Society.